Résumé
Le volume 7 maintient le programme Web AI-Ready honnête après son lancement. La gouvernance fait la différence entre un programme de normes utile et une pile de revendications obsolètes. Chaque nouveau mécanisme doit passer par un examen de maturité, des mises à jour des sources, des artefacts machine, des tests, des notes de version et des vérifications de traduction avant de devenir un support public actuel.
Contrat de mise en œuvre d’agent
Lorsqu’un utilisateur envoie un agent vers ce guide Web AI-Ready, la mission consiste àappliquer la stratégie au site cible, au référentiel ou au package de publication de l’utilisateur. Traitez UAIX comme norme de référence et liste de contrôle. Ne copiez pas le contenu de la page UAIX dans le site cible, ne créez pas de page sur les conseils de UAIX et ne publiez pas d’explication « AI-Ready Web » à moins que l’utilisateur ne demande explicitement cette sortie.
L’ensemble de preuves attendu du site cible est concret: manifeste public, découverte .well-known, inventaire des itinéraires, résultat de préparation, robots.txt, plan du site, llms.txt, données structurées, limites de support visibles, vérifications ciblées et sortie du package ou du fichier racine lorsque la publication est demandée.
| Étape de l’agent | Faire la véritable mise en œuvre | Ne fais pas ça |
|---|---|---|
| Résoudre la cible | Identifiez le domaine cible, la racine du dépôt, les routes publiques, le système de build, le CMS, le package de déploiement, le chemin de sortie du fichier racine et les preuves actuelles avant de procéder à la modification. | Supposons que UAIX.org soit le site cible, résumez cette page ou créez une nouvelle page de conseils car cette page a été fournie à titre de référence. |
| Auditer le site existant | Vérifiez les HTML humains, les en-têtes, les métadonnées, les URLs canoniques, les robots, les plans de site, les schémas, les fichiers.well-known, les fichiers llms, les API, les inventaires d’itinéraires, les enregistrements de préparation, l’accessibilité, la confidentialité et les limites de support. | Ignorez l’audit du site cible et reformulez uniquement les définitions AEO/GEO/SEO. |
| Mettre en œuvre des améliorations | Mettez à jour les pages du site cible, la navigation, les données structurées, les fichiers de découverte, l’inventaire des itinéraires, les enregistrements de préparation, les preuves publiques, la copie AEO/GEO/SEO, les conseils de non-opération, les chemins de révision et les fichiers racine du package de publication là où l’audit montre des lacunes. | Utilisez des mots-clés, masquez, ajoutez du texte caché réservé aux robots, injectez des invites pour les modèles, fabriquez des citations ou créez des pages de porte synthétiques. |
| Vérifier et emballer | Exécutez les vérifications ciblées du site, enregistrez les fichiers et les itinéraires modifiés, nommez les vérifications et les bloqueurs ignorés et fournissez les fichiers racine, le ZIP racine ou le package de publication demandés lorsque l’utilisateur demande une sortie déployable. | Réclamez la préparation, la certification, l’approbation, les gains de classement, la publication en direct ou l’autorité d’un agent sans preuve. |
Registre d’échéance
| Statut | Utilisez-le pour | Exemples | Règle UAIX |
|---|---|---|---|
| Ligne de base stable | Exigences qui doivent être mises en œuvre avant toute réclamation spécifique à un agent. | WCAG 2.2, sémantique HTML, HTTP sémantique, robots.txt, plan du site, JSON schéma, OpenAPI, détails du problème, contexte de trace, JSON-LD. | Peut être une langue requise lorsque cela est pertinent et testé. |
| Actuel en option | Capacités utiles avec des implémentations réelles mais adoption spécifique à l’environnement. | MCP dans les hôtes compatibles, A2A là où pris en charge, flux principaux non humains signés, représentations alternatives structurées. | Étiquette comme prise en charge uniquement lorsque la mise en œuvre locale dispose de preuves publiques. |
| Proposition ou congrès communautaire | Signaux de découverte ou de politique utiles qui ne sont pas des normes Web formelles. | Terminologie AEO/GEO, llms.txt, miroirs de démarque, fichiers de préférences d’agent, signaux de droits de style TDMRep. | Utiliser comme signaux consultatifs et jamais comme seule source d’autorité. |
| Piste de recherche | Idées à surveiller sans réclamations de support actuelles. | Déclarations d’outils WebMCP/natifs du navigateur, découverte d’agents basée sur DNS, informations d’identification commerciales d’agents autonomes au-delà des API publiées. | Conservez le langage de la feuille de route jusqu’à ce que les spécifications, les implémentations, les tests et les preuves de version existent. |
| Non pris en charge | Les réclamations UAIX ne doivent pas impliquer. | Exécution du runtime hébergé, écritures automatiques dans le référentiel, validation des informations d’identification cachées, certification, approbation, preuve de sécurité, preuve de conscience. | Bloquez ou réécrivez la réclamation. |
Feuille de route
| Fenêtre | Livrables | Grille |
|---|---|---|
| 30 premiers jours | Publiez les pages sources en 7 volumes, les actifs de la machine JSON, l’inventaire des itinéraires, les tests et les preuves de transfert. | Les tests source réussissent; aucune demande d’assistance en direct tant que la construction et le téléchargement du package ne sont pas terminés. |
| Jours 31-90 | Ajoutez l’automatisation de l’accessibilité des pages rendues, des exemples OpenAPI/API, des guides de démarrage du framework et un contrôle qualité de traduction. | Examen manuel de l’accessibilité et de la confidentialité terminé. |
| Mois 3-6 | Ajoutez une interface utilisateur plus riche du validateur de préparation, un package d’exportation de preuves, des extraits de référence WordPress et ASP.NET Core et une bibliothèque anti-modèle. | Le schéma de sortie du validateur et les exemples restent alignés sur les pages publiques. |
| Mois 6-12 | Suivez l’adoption de MCP/A2A, faites évoluer les profils de capacités, affinez les conseils en matière d’identité/délégation et ajoutez des tableaux de bord d’opérations. | Seuls les mécanismes dont la mise en œuvre est prouvée deviennent un soutien actuel. |
| Mois 12-24 | Évaluez les API d’agent natif du navigateur, les modèles de délégation commerciale, les signaux de préférence en matière de droits et les commentaires d’interopérabilité externes. | Les idées de recherche restent planifiées jusqu’à ce que les normes, les implémentations, les tests et les preuves rendues publiques soient d’accord. |
Processus d’examen des réclamations
- Nommez la réclamation et le profil concerné.
- Identifiez la norme stable, la mise en œuvre actuelle, la proposition ou la source de recherche qui la sous-tend.
- Mettez à jour ensemble la page humaine, l’artefact machine, le validateur/test, la note de version, l’état de la feuille de route et la source de traduction.
- Exécutez des contrôles automatisés et enregistrez les contrôles ignorés avec leurs raisons.
- Publier uniquement après examen par le propriétaire et existence de packages/preuves en direct.
Gouvernance de la sécurité et de la confidentialité
La publication Web AI-Ready ne doit jamais exposer les informations d’identification, les points de terminaison privés, les données privées des clients, les invites cachées, les journaux de production non publics ou les allégations juridiques/de sécurité non prises en charge. Le programme suit le comportement de non-opération UAIX: lorsqu’une requête franchit l’autorité déclarée, le site renvoie un chemin de révision sécurisé au lieu d’essayer de s’exécuter.
Références principales en matière de gouvernance
- Cadre de gestion des risques liés à l’IA du NISTpour le langage des risques et le cadrage de la gouvernance.
- OWASP Top 10 pour les applications LLMpour les risques de sécurité des agents courants et des applications LLM.
- Travail communautaire du protocole de réservation W3C TDMpour le contexte de préférence d’exploration de texte et de données, traité comme une entrée de signal de droits plutôt que comme une autorisation complète.
Gouvernance lisible par machine
- Registre des exigences JSONIdentificateurs d’exigences ARW stables, tests, preuves et anti-modèles.
- Registre d’échéance JSONMécanismes actuels stables, spécifiques à la configuration, de proposition, de recherche et non pris en charge.
- Inventaire des itinéraires JSONFaits d’audit source/en direct, limite de publication et plan d’exposition des itinéraires.
- Schéma du manifeste du site AI-ReadyDéclaration portable pour la découverte, les capacités, les politiques, les preuves et les limites de support.
- Exemple de manifeste de site AI-ReadyExemple concret à saveur UAIX sans revendiquer l’exécution du runtime hébergé.
- Schéma des résultats de préparationModèle de résultat d’évaluation pour les contrôles automatisés et les preuves d’examen manuel.
- Exemple de résultat de préparationExemple de paquet de notation avec des avertissements, des bloqueurs et aucune demande de certification.