Audit à l'échelle de l'entreprise de la responsabilité, de l'autorité, de l'exécution, de la surveillance et des preuves dans les systèmes d'agents IA. Un audit de production suit l'ensemble du système d'exploitation autour d'un agent : l'objectif commercial, le modèle et l'orchestration, les identités humaines et non humaines, l'autorité déléguée, les données et les outils, les décisions politiques, les approbations, les changements d'état, les résultats commerciaux, surveillance, incidents, versions, restauration, conservation et vérification indépendante. La méthode ci-dessous donne aux équipes d'audit interne, de conformité, de risque de modèle, de sécurité et d'exploitation une structure de travail sur le terrain tout en préservant leurs responsabilités distinctes.
Cadre d'audit des agents d'IA d'entreprise du domaine 12
Utilisez ce tableau pour définir l'univers d'audit, attribuer des demandes de preuves et rédiger des procédures. Chaque ligne nécessite une population définie, un propriétaire nommé, un contrôle testable, un enregistrement source de vérité et une condition d'échec explicite avant le début du travail sur le terrain.
| Domaine d'audit | Question de l'auditeur | Propriétaire responsable | Contrôle à tester | Preuves requises | Signal de défaillance | Où dans KLA / guide plus profond |
|---|---|---|---|---|---|---|
| 1. Inventaire et portée | Quels agents, versions, environnements, processus, décisions et dépendances se trouvent dans la population ? | Propriétaire de l'entreprise | Rapprochement de l'inventaire et approbation des limites | Inventaire des agents, schéma des processus, flux de données, registre des dépendances, décomptes de population | Agent inconnu, environnement manquant, population non rapprochée | Agent Registry ; guide de conformité |
| 2. Responsabilité et obligation de rendre compte | À qui appartiennent les résultats, les opérations de contrôle, l'acceptation des risques et les mesures correctives ? | Propriétaire de l'entreprise | Propriété nommée et autorité d'approbation | Matrice de responsabilité, chartes de rôle, approbations, propriétaires de problèmes | Responsabilité partagée, rôle vacant, propriétaire sans autorité | Agent Registry ; Control Mapping |
| 3. Identité et délégation | Chaque action peut-elle être liée à un agent, à un principal parrain et à une délégation ? | Propriétaire de l'identité | Identité unique et délégation étendue | Enregistrements d'identité, revendications de jeton, chaîne de délégation, étendue de session | Identifiant partagé, identité orpheline, principal non lié | Agent Registry ; guide des autorisations |
| 4. Autorisations, outils et limites des données | L'agent pourrait-il lire ou modifier les ressources au-delà de son objectif approuvé ? | Propriétaire de l'application | Politique de moindre privilège au moment de l'action | Subventions effectives, Tool Catalog entrée, Data Boundaries, verdicts politiques | Large portée, contournement direct, outil non enregistré, combinaison de subventions toxiques | Tool Catalog ; Data Boundaries ; KLA Policy Engine |
| 5. Classification des risques et assurance pré-production | L'utilisation a-t-elle été classée et testée par rapport à son impact et à son contexte réels ? | Propriétaire du risque | Classification documentée et porte de libération | Évaluation de l'impact, modèle de menace, plan d'évaluation, seuils d'acceptation | Classification non prise en charge, test manquant, seuil d'échec annulé | Control Mapping ; Assurance Center |
| 6. Application de la politique d'exécution | La politique approuvée a-t-elle été évaluée avant chaque action consécutive ? | Propriétaire du contrôle | Autoriser, refuser ou faire remonter la décision en ligne | Version de la stratégie, règles correspondantes, Decision Request, réception de l'action | L'action précède le verdict, la stratégie obsolète, le contournement de l'application | Policy Builder ; KLA Policy Engine ; Piste d'audit ; guide gouverner un agent Sources : source |
| 7. Approbation humaine et escalade | Un évaluateur autorisé a-t-il reçu suffisamment de preuves et fait preuve de jugement ? | Propriétaire des opérations | Approbation et escalade basées sur les risques | Decision Request, instantané de l'autorité, preuves présentées, justification, horodatages | Timbre en caoutchouc, autorité expirée, approbation tardive, justification manquante | Decision Desk ; autonomie responsable |
| 8. Tracé d'exécution et résultats commerciaux | L'auditeur peut-il retracer l'intention à travers les effets des outils et le résultat final ? | Propriétaire du processus | Corrélation de bout en bout et rapprochement des résultats | Lineage Record, parcours, appels d'outils, état avant/après, enregistrement des résultats | Corrélation rompue, effet secondaire non enregistré, inadéquation des résultats | Lineage Explorer ; guide des pistes d'audit |
| 9. Assurance continue et gestion du changement | Les changements ont-ils déclenché une réévaluation, une surveillance et un déploiement contrôlé ? | Propriétaire de l'ingénierie | Approbation de la version, détection de dérive, tests déclenchés par un changement | Diff de version, résultats des tests, enregistrement de déploiement, alertes d'assurance, correction | Modification non approuvée, dérive silencieuse, échec de contrôle non résolu | Agents ; Assurance Center ; guide de surveillance |
| 10. Réponse aux incidents, révocation et restauration | L'organisation pourrait-elle contenir l'agent et annuler les actions affectées ? | Propriétaire de l'incident | Procédure d'élimination, de révocation, de confinement, de notification et de restauration | Chronologie de l'incident, révocation des informations d'identification, restauration, liste des cas concernés | Poursuite de l'exécution, portée incomplète, échec de la restauration | Centre de sécurité ; Agents ; Evidence Room |
| 11. Intégrité, conservation et vérification indépendante des preuves | Les preuves sont-elles complètes, inviolables, conservées et testables de manière indépendante ? | Propriétaire des enregistrements | Rapprochement de la population, scellement, conservation, test du vérificateur | Manifeste, hachages, signatures, chaîne de conservation, politique de conservation, conservation légale | Échec de hachage, enregistrement manquant, source mutable, conservation expirée | Evidence Room ; Sealed Evidence Bundle ; Pack de contrôle ; preuve inviolable; ensemble d'échantillons Sources : source source |
| 12. Dépendances multi-agents et tierces | Les agents, modèles, outils, protocoles et fournisseurs délégués sont-ils à l'intérieur du périmètre d'audit ? | Propriétaire du service | Approbation des dépendances et transfert authentifié | Inventaire du fournisseur, contrats, versions, messages inter-agents, rapports de contrôle | Sous-agent opaque, message non authentifié, composant non pris en charge | Agent Registry ; Tool Catalog ; OWASP crosswalk |
Définir les limites du système avant l'activité d'échantillonnage
Commencez par le résultat commercial et tracez vers l'intérieur. La limite inclut tous les composants qui peuvent influencer une action ou sa preuve : configuration de l'agent, modèle, versions d'invite et d'orchestration, mémoire, sources de récupération, identités d'utilisateur et de service, délégation, politique, outils, systèmes en aval, réviseurs humains, surveillance, processus d'incident et magasins de preuves. Incluez les sous-agents et les tiers chaque fois que leurs résultats peuvent modifier la décision finale, l'autorité disponible ou l'exhaustivité du dossier.
Construisez une population réconciliable. Le NIST AI RMF 1.0 est un cadre volontaire final pour l'IA au sens large, et GOVERN 1.6 supports maintient un inventaire des systèmes d'IA pour la gestion des risques. Pour le travail d'audit sur le terrain, étendez cet inventaire aux versions, déploiements, types de décision, environnements, outils, sources de données, propriétaires, niveaux de risque, historique des incidents et emplacements des preuves.
Rédigez l'énoncé des limites en tant qu'artefact d'audit et obtenez l'approbation du propriétaire de l'entreprise. Une déclaration utile nomme le processus audité, les événements de début et de fin, les agents et versions inclus, la période de production, la population de décisions, les juridictions, les composants exclus avec raisons, les données en amont, les actions en aval, les rôles humains et chaque dépendance externe. Les changements de portée au cours du travail sur le terrain nécessitent une modification datée et une analyse d’impact pour l’échantillon.
- Clés de population : ID d'agent, ID de version, environnement, ID de processus, type de décision, résultat, niveau de risque et plage de dates.
- Limite d'autorité : principal parrain, identité de l'agent, étendues déléguées, outils autorisés, limites de ressources, objectif, durée et seuils d'approbation.
- Limite d'exécution : chaque appel de modèle, appel d'outil, transfert inter-agents, verdict de politique, Decision Request, changement d'état, notification et résultat commercial.
- Limite des preuves : système d'enregistrement pour chaque artefact, classe de conservation, méthode de scellement, vérificateur, conservation légale et lacune de collection connue.
Définir la responsabilité et séparer quatre disciplines d'assurance
Désigner un propriétaire d'entreprise responsable du système d'agents et de ses résultats. Nommer les propriétaires techniques de l'agent, du modèle, des intégrations, de l'identité, des données et de l'infrastructure des preuves ; nommer les propriétaires de contrôle pour la politique, l’approbation, la surveillance, la réponse aux incidents et la conservation. Chaque propriétaire a besoin de l'autorité nécessaire pour arrêter un déploiement, accepter un risque défini dans les limites déléguées, financer des mesures correctives et répondre à une exception.
Le Modèle à trois lignes de l'IIA attribue la propriété et la gestion des risques aux rôles de première ligne, l'expertise et les défis aux rôles de deuxième ligne, et une assurance indépendante et objective à l'audit interne. Appliquez ces rôles à l’audit des agents sans les transformer en trois départements fixes. L'audit interne préserve son indépendance en évitant les décisions de propriété du contrôle et d'approbation de la direction pour le système qu'il audite ultérieurement.
Quatre disciplines apportent des preuves différentes. Leurs travaux peuvent être réutilisés lorsque la portée, la période, les critères, la compétence et l'indépendance sont documentés. Leurs conclusions restent distinctes.
| Discipline | Objectif principal | Procédure | Preuves | Conclusion |
|---|---|---|---|---|
| Évaluation du modèle | Mesurer le comportement par rapport à des tâches et des critères de risque définis | Tests de référence, de scénario, d'équipe rouge, de sous-groupe et de régression | Ensemble de données/version, méthode, seuils, résultats, limites | Performance dans les conditions testées |
| Tests de sécurité | Trouver des chemins exploitables à travers les objectifs, les outils, l'identité, la mémoire, le code et les dépendances | Modélisation des menaces, tests contradictoires, examen de la configuration, validation des exploits | Modèle de menace, cas de test, trace des exploits, gravité, nouveau test de remédiation | Exposition à la sécurité pour la portée testée |
| Audit de conformité | Évaluer les critères juridiques, réglementaires, contractuels et politiques définis | Test de conception, échantillon d'efficacité opérationnelle, inspection des preuves, réexécution | Matrice de critères, population, échantillon, documents de travail, exceptions, réponse de la direction | Conformité ou exception par rapport aux critères énoncés |
| Assurance opérationnelle | Vérifier que les contrôles continuent de fonctionner pendant les changements de production | Signaux continus, alertes de seuil, rapprochements, examen ciblé, suivi des mesures correctives | Événements de contrôle, alertes d'assurance, examen du propriétaire, preuves de clôture de problème | État actuel du contrôle et exposition non résolue |
Exécuter les procédures de conception, de publication, d'exécution et périodiques
Traitez le programme d'audit comme un cycle de vie. Le [NIST Generative AI Profile] volontaire final (https://doi.org/10.6028/NIST.AI.600-1) suggère de conserver l'historique des tests, des évaluations, des validations et des vérifications, en utilisant des critères de publication mesurables, en documentant l'approbation, en effectuant une évaluation continue et en définissant des procédures de désactivation. Appliquez les pratiques dans lesquelles l'agent utilise l'IA générative, puis ajoutez des procédures d'identité, de délégation, d'outil, de politique, d'approbation et multi-agents spécifiques à l'agent. Sources : source
Le IMDA Model AI Governance Framework pour Agentic AI v1.5 de Singapour est un guide de vie volontaire publié. Il prend en charge la définition des limites de fonctionnement et des politiques d'autorisation avant le déploiement, l'évaluation des composants et du comportement de bout en bout, la surveillance après le déploiement, la gestion des incidents et la réévaluation des modifications apportées aux modèles, outils, autorisations et processus.
| Étape | Procédures requises | Population de preuves | Critère de réussite |
|---|---|---|---|
| Temps de conception | Limite, objectif, propriété, classification des risques, impact évaluation, modèle de menace, modèle d'identité, outil et Data Boundaries, conception d'approbation, schéma de preuve | Enregistrements de conception et spécification de contrôle approuvée | Chaque risque important est mappé à un champ de propriétaire, de contrôle, de test et de preuve |
| Délai de publication | Tests de régression et contradictoires, simulation de politique, autorisation examen, examen des dépendances, test d'exhaustivité des preuves, répétition de restauration, approbation | Version candidate, suite de tests, exceptions, approbations | Seuils réussis ; les exceptions acceptées sont autorisées, datées et délimitées |
| Exécution | Application des politiques en ligne, routage des décisions, liaison d'identité, capture de preuves, détection d'anomalies, limites de taux et de valeur, confinement | Toutes les actions de production et événements de contrôle | Les actions consécutives entraînent un verdict préalable et sont terminées Lineage Record |
| Périodique | Rapprochement de la population, échantillon basé sur le risque, recertification d'accès, examen de la qualité de l'approbation, analyse de la dérive et des résultats, suivi des incidents, tests de rétention et de vérification | Période définie plus toutes les strates d'exception obligatoires | Les exceptions sont quantifiées, détenues, corrigés et reflétés dans la conclusion de l'audit |
Sélectionner des échantillons par risque, type de décision, anomalie, chemin d'approbation et changement de système
Établir l'exhaustivité avant de choisir les cas. Réconciliez les événements commerciaux d'origine, les exécutions d'agents, les décisions politiques, les Decision Request, les effets en aval et les enregistrements de preuves scellés. Les différences deviennent des exceptions ou une limitation de portée ; ils ne peuvent pas disparaître lors de la sélection d’échantillons.
Utilisez un échantillon reproductible basé sur le risque avec une base de référence aléatoire. Enregistrez la requête de population, l'heure d'extraction, les systèmes sources, les filtres, la graine aléatoire, la logique de sélection, les remplacements et le réviseur. Préservez la population congelée avec des hachages afin qu'un deuxième examinateur puisse régénérer le même échantillon.
- Risque : inclut les cas d'impact, de valeur, de privilège, de sensibilité, d'irréversibilité et de personnes affectées les plus élevés.
- Type de décision : couvre chaque élément autoriser, refuser, faire remonter, ignorer, annuler et obtenir un résultat sans action.
- Anomalie : incluent les contournements de contrôle, les refus de stratégie suivis d'une exécution, les tentatives répétées, les séquences d'outils inhabituelles, les alertes de dérive, les pics de latence et les résultats aberrants.
- Chemin d'approbation : inclut les actions autonomes, les approbations ordinaires, les escalades, les remplacements, l'utilisation de bris de vitre, les demandes expirées et la réaffectation des réviseurs.
- Modification du système : inclut le premier et le dernier cas concernant les modifications de modèle, d'invite, de stratégie, d'autorisation, d'outil, de données, d'orchestrateur, de version et de déploiement.
- Référence de base aléatoire : sélectionnez parmi la population restante pour détecter les défaillances ordinaires que les filtres de risque peuvent manquer.
Audit travaillé : une action d'un agent de décision de prêt réglementé
Supposons qu'une banque de détail de l'UE utilise un agent pour rassembler les données de la demande, appeler un modèle de risque de crédit, appliquer la politique de prêt, acheminer les cas limites vers un souscripteur et rédiger le résultat d'approbation ou de refus. Un système d'IA destiné à évaluer la solvabilité d'une personne physique ou à établir une cote de crédit relève de l'annexe III, point 5(b) de la loi de l'UE sur l'IA et est présumé à haut risque en vertu de l'article 6(2), sous réserve des règles spécifiques de l'article 6(3) ; le profilage dans le cadre d’une utilisation visée à l’Annexe III reste à haut risque. L'audit enregistre le rôle de déployeur spécifique de la banque et le rôle de fournisseur du fournisseur de modèles en vertu de l'article 3, puis teste les contrôles applicables de chaque partie.
Pour un système à haut risque, l'article 12 de de la [Loi de l'UE sur l'IA] (https://eur-lex.europa.eu/eli/reg/2024/1689/oj) exige une capacité technique de journalisation automatique des événements pendant la durée de vie du système afin de prendre en charge la traçabilité, la surveillance après commercialisation et les enquêtes. L'article 14 requiressource une capacité de surveillance humaine efficace proportionnée au risque, à l'autonomie et au contexte, tandis que l'article 26(2) exige que le déployeur attribue la supervision à des personnes possédant les compétences, la formation, l'autorité et le soutien nécessaires. La procédure pas à pas convertit ces obligations conditionnelles en tests de preuve pour une décision. Sources : source
| Étape | Contrôle attendu | Artefact | Procédure d'audit | Condition de défaillance |
|---|---|---|---|---|
| 1. Établir le dossier | La demande entre dans le processus de prêt approuvé et reçoit un identifiant de parcours unique | Événement de candidature, identifiant de parcours, code d'objet, type de décision, niveau de risque | Tracer l'événement commercial dans la population d'agents et l'enregistrement scellé | Dossier manquant, identifiant en double, incompatibilité d'objectif |
| 2. Lier l'identité et l'autorité | L'identité de l'agent, le principal parrain, la session et la délégation sont actuelles et étendues | Revendications d'identité, enregistrement de délégation, instantané d'autorité, expiration | Réexécuter l'autorité effective à l'horodatage de l'événement | Identité partagée, autorisation expirée, portée excédentaire |
| 3. Récupérer les données autorisées | Data Boundaries limiter les sources, les enregistrements, les champs, la géographie et l'objectif | Références de source, hachage de requête, ID/version de limite, enregistrement de rédaction | Comparer les enregistrements consultés avec la limite approuvée et les journaux sources | Source non approuvée, champ excédentaire, provenance manquante |
| 4. Modèle d'appel et outils | Les versions approuvées du modèle, de l'invite, de l'orchestrateur et de l'outil s'exécutent avec des entrées limitées | ID de version, hachages d'entrée/sortie, versions Tool Catalog, reçus d'appel | Résolvez chaque version et comparez la séquence d'appel avec la version approuvée | Version non approuvée, outil caché, entrée mutable |
| 5. Appliquer la stratégie | KLA Policy Engine évalue l'action avant l'exécution | ID/version de la stratégie, règles correspondantes, verdict d'autorisation/refus/escalade, horodatage | Réexécuter la décision de stratégie avec les entrées et la version enregistrées | Le verdict suit l'action, non-concordance des règles, contourner |
| 6. Obtenir une décision humaine | Itinéraires de cas limites ou exceptionnels vers un souscripteur agréé | Decision Request, preuves présentées, autorité de l'examinateur, justification, temps de décision | Inspecter la suffisance des preuves et valider de manière indépendante l'autorité de l'examinateur | Tampon en caoutchouc, justification manquante, évaluateur non autorisé |
| 7. Valider le résultat | L'action approuvée de l'outil correspond à la politique et à la décision humaine | Demande/réponse de l'outil, hachages d'état avant/après, référence du système de prêt | Tracer l'écriture finale dans le système bancaire et comparer le montant, les conditions et le statut | Le résultat diffère, effet secondaire supplémentaire, reçu manquant |
| 8. Notifier et préserver le remède | L'avis requis, l'itinéraire de révision, l'escalade et le chemin de correction restent liés au dossier | Enregistrement de l'avis, codes de motif, événement d'appel ou de révision manuelle, enregistrement de correction | Inspecter la livraison et tracer toute contestation ultérieure jusqu'à la résolution | Avis non livré, chemin de révision interrompu, correction non résolue |
| 9. Scellez et vérifiez les preuves | Evidence Room scelle l'enregistrement complet et le vérificateur teste l'intégrité | Sealed Evidence Bundle, manifeste, hachages, signature, chaîne de possession | Recalcule les hachages, valide la signature et rapproche le manifeste des événements sources | Échec de hachage, Artefact omis, clé inconnue |
| 10. Rejouer la décision | Lineage Explorer résout les versions, les entrées, la politique, l'approbation et les effets | Rejouer l'enregistrement, l'archive de version, les résultats déterministes ou la tolérance documentée | Réexécuter la politique et la séquence d'outils dans un environnement contrôlé | Version manquante, divergence inexpliquée, effet secondaire dangereux en direct |
Matrice de responsabilité pour la propriété du contrôle et l'assurance indépendante
Gardez la matrice compacte et spécifique à la décision. Un propriétaire d'entreprise responsable signe la portée, l'acceptation des risques et le plan de remédiation. Les propriétaires techniques et de contrôle responsables exploitent les contrôles. Les fonctions de risque, de conformité, de sécurité, de confidentialité, juridiques et de risque de modèle relèvent de leurs mandats. L'audit interne définit son propre champ d'application, exécute des procédures indépendantes et rend compte de ses conclusions à l'organe directeur approprié.
| Activité | Responsable | Responsable | Consulté/contesté par | Preuve de responsabilité |
|---|---|---|---|---|
| Approuver l'objectif, l'appétit pour le risque, et utilisation en production | Propriétaire de l'entreprise | Propriétaires des produits et des processus | Risque, conformité, juridique, sécurité | Approbation et conditions d'utilisation signées |
| Agent de conception, modèle, outils et contrôles des données | Propriétaire technique | Ingénierie, modèle, identité, données, propriétaires de plateforme | Risques, sécurité, confidentialité, propriétaires de contrôle | Spécifications de conception et de contrôle approuvées |
| Politique d'exploitation, approbation, surveillance et incidents | Propriétaire des opérations | Propriétaires de contrôle et équipes d'astreinte | Risque, conformité, opérations de sécurité | Événements de contrôle, journaux d'examen, enregistrements d'incidents |
| Approuver la version, le déploiement, l'exception et la restauration | Propriétaire de l'entreprise | Responsable de la version et propriétaire technique | Propriétaires du contrôle, du risque, de la sécurité et de la validation du modèle | Enregistrement de décision avec les résultats et les conditions des tests |
| Conserver et vérifier les preuves | Propriétaire des enregistrements | Propriétaires de la plateforme de preuves et du système source | Juridique, confidentialité, contrôles internes | Calendrier de conservation, résultats du vérificateur, conservations légales |
| Fournir une conclusion d'audit indépendant | Responsable de l'audit ou délégué du comité d'audit | Équipe de mission d'audit interne | Spécialistes en la matière avec garanties d'indépendance | Plan d'audit, documents de travail, rapport et suivi approuvés |
Schéma de preuves minimum pour les journaux d'audit des agents IA, les rediffusions et les preuves d'action
Un parcours rejouable nécessite des identifiants stables, un contexte versionné, des résultats de contrôle, une autorité humaine, des effets commerciaux et des métadonnées d'intégrité. Le AI Agent Audit Log Schema téléchargeable fournit le contrat de machine indépendant du fournisseur et des exemples signés. Le guide des pistes d'audit des agents AI explique les couches de preuves, la méthodologie des preuves inviolables couvre l'intégrité et l'échantillon Evidence Room montre la forme de l'exportation.
Stockez les valeurs sensibles conformément aux contrôles de confidentialité et de sécurité approuvés. Le schéma d'audit peut conserver une valeur protégée, une référence stable ou un hachage selon l'objectif du champ. L'auditeur vérifie si la déclaration soutient l'assertion déclarée et peut être résolue dans le cadre d'un examen autorisé.
| Groupe de champs | Champs minimum | Test d'audit |
|---|---|---|
| Enregistrement et corrélation | record_id, occurred_at, environment, tenant_id, process_id, journey_id, correlation_id | Unicité, ordre d'horodatage, rapprochement de la population |
| Agent et version | agent_id, agent_release_id, model_id, model_version, orchestrator_version, prompt_template_version | Résoudre chaque version en un artefact immuable approuvé |
| Principal et délégation | agent_identity_id, sponsoring_principal_id, delegated_by, session_id, authority_snapshot_id, expires_at | Réexécuter l'autorité effective au moment de l'événement |
| Objectif et risque | Purpose_code, decision_type, risk_tier, regulatory_classification, classification_basis_version | Comparer l'objectif et la classification avec la portée approuvée |
| Provenance des données | input_reference[], source_hash[], retrieval_query_hash, data_boundary_id, redaction_profile_id | Trace chaque entrée de matériau jusqu'à une source et une limite autorisées |
| Action de l'outil | tool_id, tool_version, action, resource_scope, requested_args_hash, response_hash, effect_id | Faire correspondre l'autorité demandée, l'appel réel, la réponse et l'effet secondaire |
| Décision politique | policy_id, policy_version, policy_decision, matched_rule_ids[], exception_id, evaluated_at | Réexécuter le verdict et confirmer qu'il précède l'exécution |
| Décision humaine | decision_request_id, reviewer_id, reviewer_role, presented_evidence_hash, decision, rationale, decided_at | Valider l'autorité, les preuves présentées, le calendrier et la justification |
| Résultat et récupération | outcome, before_state_hash, after_state_hash, external_reference, incident_id, rollback_id, revocation_event_id | Réconcilier les résultats enregistrés avec le système d'entreprise et l'historique de récupération |
| Intégrité et conservation | evidence_hash, previous_record_hash, bundle_manifest_hash, signature_key_id, sealed_at, retention_class, legal_hold_id | Recalculer les hachages, valider la signature et la chaîne, inspecter la rétention et la conservation |
Tester les droits d'accès, la délégation et les dépendances multi-agents
[AI Agent Standards Initiative] du NIST(https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative) est une feuille de route active couvrant les normes, les protocoles, l'identité, autorisation, sécurité, interopérabilité et évaluation. Il ne s'agit pas d'une norme définitive. Le [document conceptuel d'identité et d'autorisation NCCoE] (https://www.nccoe.nist.gov/sites/default/files/2026-02/accelerating-the-adoption-of-software-and-ai-agent-identity-and-authorization-concept-paper.pdf) reste une ébauche et étudie l'identité non humaine, la délégation limitée, le moindre privilège, la journalisation des actions, la provenance, la non-répudiation et les enregistrements inviolables. Utilisez-le pour affiner les questions d'audit et qualifier les critères de contrôles définis par l'organisation. Sources : source source
Testez la chaîne d'autorité complète : le principal humain ou organisationnel parrain, l'identité de l'agent, la portée déléguée, l'objectif, la fenêtre de temps, la capacité de l'outil, les limites de ressources et d'action, les seuils d'approbation, le chemin d'exception, le chemin de révocation et l'autorité réellement observée lors de l'exécution. Le Guide des autorisations de l'agent AI fournit un modèle de contrôle plus approfondi.
Pour les systèmes multi-agents, authentifiez et autorisez chaque transfert, préservez les identités d'envoi et de réception, validez l'intégrité et la sémantique des messages, propagez l'objectif et les contraintes, limitez la délégation des sous-agents et rapprochez le résultat final de chaque composant contributeur. Les OWASP Top 10 pour Agentic Applications 2026 sont des conseils publiés pour les praticiens et une taxonomie de sécurité ; il couvre l'abus d'identité et de privilèges, l'utilisation abusive d'outils, la mémoire, la communication inter-agents, les pannes en cascade et les agents malveillants. Il ne s’agit pas d’une norme ou d’une certification formelle.
- Test d'identité : chaque acteur non humain est unique, actif, détenu et se distingue des personnes et des agents pairs.
- Test de délégation : l'autorité déléguée est liée à un principal, un objectif, une portée, une durée et un événement de révocation approuvés.
- Test d'accès effectif : les octrois de source, les contraintes de stratégie, l'application des outils et les actions observées se réconcilient à l'horodatage de l'événement.
- Test tiers : les contrats, l'inventaire des services, les versions, les chemins d'accès, les tâches liées aux incidents, la disponibilité des preuves et les contrôles de résiliation couvrent la dépendance.
- Test multi-agent : chaque message contient un expéditeur authentifié, un destinataire prévu, des preuves d'intégrité, des limites de contexte et une corrélation avec le parcours final.
Définir la cadence d'audit et l'assurance continue par déclencheur
Le rapport final du NIST [Défis de la surveillance des systèmes d'IA déployés] (https://doi.org/10.6028/NIST.AI.800-4) explique que la surveillance post-déploiement peut détecter les problèmes de fiabilité, les dérives et les conséquences involontaires, tandis que les objectifs et les méthodes de surveillance dépendent du système, du contexte, des signaux disponibles et des acteurs. Il ne prescrit pas de cadence, de schéma minimum ou de seuil universel. Définissez la cadence en fonction de l'impact, de l'autonomie, du volume, du taux de changement, de l'historique des incidents, de la détectabilité, des obligations légales et de la qualité des preuves. Sources : source
L'assurance continue fournit des signaux de contrôle de l'ensemble de la population à la direction et des populations ciblées aux équipes de deuxième ligne et d'audit interne. L'audit interne valide toujours l'exhaustivité des sources, la conception des contrôles, la logique d'alerte, l'examen par le propriétaire, la correction et l'indépendance avant de s'appuyer sur ces signaux. Le guide de surveillance post-commercialisation fournit une structure de surveillance plus approfondie.
| Déclencheur ou intervalle | Procédure | Propriétaire principal | Preuve d'audit |
|---|---|---|---|
| Avant la première utilisation en production | Complète 12-examen de la conception et de l'état de préparation du domaine | Propriétaires commerciaux et techniques | Limites approuvées, contrôles, tests, preuves, restauration |
| Chaque version matérielle ou modification des limites | Régression, simulation de politique, examen des autorisations et des dépendances, test des preuves | Propriétaire de la version | Différence de version, résultats de test, approbation, conditions de déploiement |
| Exécution continue | Politique, approbation, identité, anomalie, résultat et signaux d'intégrité des preuves | Propriétaires du contrôle | Événements de contrôle, alertes d'assurance, lien d'incident |
| Revue hebdomadaire ou mensuelle des opérations | Exceptions, remplacements, modèles de refus, alertes non résolues, restaurations | Propriétaire des opérations | Examiner le dossier, les décisions et les plans de remédiation |
| Revue trimestrielle des risques | Recertification d'accès, analyse des résultats, tests d'échantillons, changements de fournisseurs | Entreprises et propriétaires des risques | Recertification, exemples de documents de travail, acceptation des risques |
| Cycle d'audit annuel ou basé sur les risques | Tests indépendants de portée, de conception et d'efficacité opérationnelle, suivi | Audit interne | Plan d'audit, documents de travail, rapport, clôture vérifiée |
| Incident ou échec important du contrôle | Confinement, population affectée complète, cause première, rollback, nouveau test de contrôle | Propriétaire de l'incident | Dossier d'incident, liste des cas concernés, récupération et nouveau test des preuves |
Appliquer les critères réglementaires et normatifs avec l'état actuel
Aucune norme d'auditabilité finale, spécifique à l'agent, de bout en bout, n'a été vérifiée à la date du 14 juillet 2026 source révision. NIST AI RMF 1.0 est un cadre volontaire final pour la gestion des risques liés à l'IA dans l'ensemble des technologies et des secteurs. La NIST AI Agent Standards Initiative est une feuille de route, et son travail sur l'identité et l'autorisation reste un projet de document conceptuel. Les équipes d’audit ont donc besoin d’une pile de critères documentés adaptés au système et à l’engagement.
Le Cadre de gouvernance de l'IA modèle IMDA pour l'IA agentique v1.5 est un guide de vie volontaire publié. Le OWASP Agentic Top 10 est un guide de sécurité publié pour les praticiens et une taxonomie des risques. Les deux fournissent des critères utiles spécifiques à l’agent, et aucun des deux ne constitue une norme de certification.
ISO/IEC 42001:2023 spécifie les exigences relatives à un système de gestion organisationnel de l'IA. Un audit de certification peut évaluer la conformité de l'AIMS dans son périmètre déclaré. Le certificat ne certifie pas un modèle, un agent, une décision, un résultat ou un ensemble de données individuel comme étant sûr, précis, équitable, sécurisé, éthique ou licite ; vérifier l'organisme de certification, l'accréditation, les sites, les exclusions, la validité et la déclaration d'applicabilité.
La loi européenne sur l'IA s'applique en fonction du rôle de l'opérateur, de l'objectif prévu et de la classification des risques. Le fournisseur et le déployeur sont des rôles distincts et dépendants des faits en vertu de l'article 3, et l'article 25 can transfère la responsabilité du fournisseur après un changement de marque, une modification substantielle ou un changement d'objectif qui rend un système à haut risque. Les agents d’IA ne présentent pas automatiquement un risque élevé ; appliquer l'article 6 et Annexe I ou III au système, au but et aux faits réels.
Pour les systèmes à haut risque, l'article 12 requi concerne la capacité technique d'enregistrement automatique des événements pendant la durée de vie du système. L'article 19 requioblige les fournisseurs à conserver sous leur contrôle les journaux générés automatiquement pendant au moins six mois, sauf disposition contraire d'une autre loi applicable. L'article 26(6) donne aux déployeurs la même règle de six mois pour les journaux sous leur contrôle, tandis que l'article 26 also couvre le respect des instructions, l'attribution d'une surveillance compétente et autorisée, la surveillance des opérations et l'action en cas de risques ou d'incidents graves. Ces obligations ne créent pas une règle universelle de conservation de six mois pour chaque agent ou chaque journal.
Les colégislateurs de l'UE ont adopté l'Omnibus numérique sur l'IA en juin 2026 : le Parlement européen a approuvé le texte le 16 juin 2026 et le Conseil a donné son approbation finale le 29 juin 2026, enregistré dans le Adoption finale du Conseil avis. Le [texte final adopté] (https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CONSIL%3APE_30_2026_REV_1) définit 2 décembre 2027 pour article 6(2)/Annexe III des systèmes autonomes à haut risque et 2 août 2028 pour Article 6(1)/Annexe I systèmes intégrés aux produits. L'article 50 transles obligations parentales conservent leur 2 août 2026 date. Sources : source source
Traiter les preuves incomplètes et nuancer la conclusion de l'audit
La suffisance des preuves nécessite la pertinence, la fiabilité, l'exhaustivité, l'intégrité, l'actualité et la traçabilité jusqu'à la population et l'affirmation. Documentez quelle partie a produit chaque artefact, quel système fait autorité, comment il a été extrait, s'il peut être modifié, comment l'échantillon est lié à la population et si un examinateur indépendant peut répéter la procédure.
Classez chaque lacune avant de conclure : un échec de contrôle, un enregistrement manquant, un échec d'intégrité, un artefact tiers indisponible, une expiration de conservation, une limitation de population ou une exclusion de la portée de l'audit. Effectuez des procédures alternatives lorsqu’elles répondent à la même assertion. Les exemples incluent la réexécution du système source, la réconciliation des états en aval, la validation de signature indépendante, la confirmation d'une partie externe ou le test d'une population affectée plus large.
Indiquez la limitation dans le rapport avec le domaine concerné, la période, la population, l'assertion, les alternatives tentées, l'incertitude résiduelle, le risque, le propriétaire responsable, la remédiation et la date d'échéance. Une conclusion nuancée identifie les domaines fiables et la limite exacte autour de l’assurance non étayée. Une clause de non-responsabilité ou une déclaration de la direction ne peut pas remplacer les preuves d'exploitation manquantes.
| Condition des preuves | Procédure alternative | Traitement de conclusion |
|---|---|---|
| La population ne réconcilie pas | Reconstruire à partir des systèmes d'origine et en aval ; tester tous les cas sans correspondance | Limitation de la portée sur l'exhaustivité jusqu'à réconciliation |
| La version de la politique ou de la version n'est pas disponible | Inspecter l'archive, l'artefact de déploiement, le manifeste signé et l'historique des sources | Aucune conclusion de réexécution pour les cas concernés si la version reste non résolue |
| Justification de l'approbation ou autorité manquante | Inspecter les dossiers d'identité, l'historique Decision Desk et la confirmation du réviseur | Contrôler l'exception ; la confirmation seule ne prouve pas le jugement contemporain |
| La validation du hachage, de la signature ou de la chaîne échoue | Recalculer à partir des artefacts faisant autorité et inspecter l'historique des clés et de la garde | Exception d'intégrité dans le segment de groupe ou de chaîne concerné |
| Preuve de sous-agent tiers indisponible | Inspecter le contrat, le rapport indépendant, les enregistrements de passerelle, les reçus d'entrée/sortie et le rapprochement des résultats | Conclusion nuancée sur la dépendance opaque et les assertions affectées |
| La conservation a expiré avant l'audit | Inspecter le calendrier approuvé, les conservations légales, les enregistrements sources survivants et les résultats en aval | Limitation de la période et constatation du contrôle de conservation lorsque les critères exigeaient la conservation |
Foire aux questions
Que couvre un audit d'agent IA ?
Il couvre l'ensemble du système de production autour de l'agent : inventaire, propriétaires responsables, identités, délégation, autorisations, données et outils, classification des risques, tests de version, politique d'exécution, décisions humaines, Execution Lineage, résultats, changements, incidents, intégrité des preuves, conservation et tiers. L’audit teste à la fois la conception des contrôles et l’efficacité opérationnelle sur une population réconciliée.
Comment puis-je auditer et rejouer les décisions des agents IA à l'aide des journaux de données d'entreprise ?
Corrélez les événements commerciaux, les versions d'agent et de modèle, les références de données, les appels d'outils, les verdicts de politique, les approbations et les changements d'état en aval sous des ID stables. Geler les versions et les références d'entrée, vérifier le manifeste des preuves, réexécuter la décision politique et rejouer les effets des outils dans un environnement contrôlé ; le workflow Lineage Explorer montre la séquence gouvernée.
Comment créer des pistes d'audit pour les actions des agents IA ?
Capturez des enregistrements de manière synchrone lors des événements d'identité, de récupération, de politique, d'approbation, d'outil, de résultat, d'incident et de restauration. Scellez-les dans un manifeste avec des hachages, des signatures, des données de chaîne de traçabilité et des métadonnées de conservation, puis rapprochez chaque action avec les systèmes d'origine et en aval ; consultez le Guide des pistes d'audit des agents AI.
De quelles pistes d'audit ai-je besoin pour assurer la conformité des agents IA en vertu de la loi européenne sur l'IA ?
L'exigence dépend du rôle et de la classification. Pour les systèmes à haut risque, l'article 12 de de la Loi de l'UE sur l'IA exige une capacité technique pour les journaux d'événements automatiques pendant toute la durée de vie du système ; Les articles 19 et 26(6) exigent respectivement que les fournisseurs et les déployeurs conservent sous leur contrôle les journaux générés automatiquement pendant au moins six mois, sauf disposition contraire d'une autre loi applicable. Cette règle ne s’applique pas universellement à chaque agent IA ou à chaque journal.
Comment auditer et certifier les droits d'accès des agents IA ?
Auditez le principal parrain, l'identité de l'agent, la délégation, les subventions effectives, les limites des outils et des ressources, l'objectif, la durée, les conditions d'approbation, l'utilisation observée, la révocation et les preuves de recertification. Le document d'identité et d'autorisation du NIST reste un projet, et ISO/IEC 42001 certifie un système de gestion organisationnelle étendu par l'intermédiaire d'un organisme de certification ; ni l'un ni l'autre ne fournit de certificat universel pour les droits d'accès d'un agent individuel.
À quelle fréquence un système d'agent IA doit-il être audité ?
Audit avant la première utilisation en production, après des modifications matérielles, sur un cycle périodique basé sur les risques et après des incidents ou des échecs de contrôle des matériaux. L'assurance continue doit surveiller l'ensemble de la population entre les audits ; le [rapport de surveillance NIST] final (https://doi.org/10.6028/NIST.AI.800-4) confirme que la surveillance dépend du contexte du système et ne prescrit pas une cadence universelle. Sources : source
Que se passe-t-il lorsque les preuves d'audit d'un agent IA sont incomplètes ?
Classez l'écart, quantifiez la population affectée, effectuez des procédures alternatives et enregistrez l'incertitude résiduelle. Le rapport doit qualifier l'assertion, la période ou la dépendance concernée et attribuer une correction ; la représentation de la direction ne remplace pas les preuves d’exploitation contemporaines.
Points clés à retenir
Un audit défendable d'agent d'IA commence par une limite et une population complètes, attribue un propriétaire d'entreprise responsable, teste les contrôles tout au long du cycle de vie, échantillonne les actions consécutives et anormales, rejoue le Execution Lineage et qualifie chaque conclusion qui manque de preuves suffisantes. Utilisez l'Agent Audit Readiness Assessment pour noter les 12 domains, puis inspectez l'exemple Sealed Evidence Bundle pour comparer vos dossiers avec un ensemble de preuves vérifiables de manière indépendante.