La partie responsable d'un agent d'IA est la personne qui a le pouvoir d'approuver son objectif commercial, de définir ses limites de fonctionnement, d'accepter ses résultats et d'arrêter son utilisation. Dans la plupart des entreprises, il s'agit du propriétaire responsable du processus métier. Les rôles techniques, de modèle, de données, de sécurité, d'outil, de politique, d'approbation, d'opérations, de conformité, d'audit et de fournisseur comportent des responsabilités définies autour de ce propriétaire. La responsabilité suit les limites de l'autorité et du contrôle à travers chaque action, version, incident, changement et dépendance externe.
Qui est responsable d'un agent IA en production
Désigner un propriétaire de processus métier responsable de l'utilisation de la production et de ses résultats. Le sponsor exécutif est propriétaire de l'appétit pour le risque, du financement et du pouvoir d'escalade de l'entreprise. Le produit agent ou le propriétaire technique possède l'intégrité technique et les versions contrôlées. Tous les autres rôles possèdent une décision, un contrôle, un artefact ou une conclusion indépendante spécifique. Un contrat avec un fournisseur modifie la répartition du travail tandis que le propriétaire de l'entreprise reste responsable du processus exploité sous l'autorité de l'entreprise.
Tracez la responsabilité à travers quatre frontières : qui autorise l'objectif, qui peut modifier le système, qui peut autoriser ou arrêter une action et qui accepte l'impact commercial qui en résulte. Enregistrez chaque limite avec une personne nommée, une autorité déléguée, des critères de décision, une source de preuves, un chemin de remontée et des dates d'entrée en vigueur. Des comités partagés peuvent conseiller et approuver au sein d'une charte ; chaque décision nécessite toujours un rôle responsable nommé.
Utilisez le cadre d'audit des agents IA d'entreprise pour tester cette matrice dans le cadre du système de production plus large. L'Agent Audit Readiness Assessment vérifie si la propriété, l'autorité, les contrôles et les preuves sont prêts pour un examen indépendant.
- Objectif et résultats : le propriétaire du processus métier approuve l'utilisation prévue, les personnes concernées, les mesures des résultats, l'acceptation des risques et le retrait.
- Construire et modifier : les propriétaires techniques, de modèles, de données, d'identité, d'outils et de politiques approuvent les composants et les limites de leurs mandats.
- Autorité d'action : les propriétaires de politiques définissent les règles de routage, les approbateurs humains nommés décident des cas consécutifs et les opérations peuvent contenir l'exécution.
- Assurance : les fonctions de deuxième ligne contestent dans le cadre de leurs mandats, tandis que l'audit interne choisit son périmètre et fournit une conclusion indépendante.
Matrice de responsabilité des agents IA par défaut tout au long du cycle de vie
Utilisez cette matrice par défaut lorsqu'une entreprise exploite un agent au sein d'un processus métier. Responsable signifie l’autorité de décision finale pour l’activité répertoriée. Responsable signifie contrôler le fonctionnement et la livraison. Les rôles consultés apportent une expertise ou un défi formel. Les rôles informés reçoivent la décision et ses conditions. Chaque ligne a un rôle responsable pour son périmètre de décision défini.
La matrice est un contrôle de départ. Les variantes du modèle opérationnel ci-dessous remplacent les missions spécifiques où l'architecture, l'approvisionnement, la propriété des outils ou l'approbation humaine obligatoire modifient les limites de l'autorité.
| Étape du cycle de vie | Responsable | Responsable | Consulté/contesté par | Informé | Preuve de responsabilité |
|---|---|---|---|---|---|
| Conception | Propriétaire du processus commercial responsable | Propriétaire du produit/technique de l'agent ; propriétaire du modèle ou de l’assurance IA ; données, IAM/sécurité, Tool Catalog et propriétaires de politiques/contrôles | Conformité/juridique/confidentialité ; propriétaire tiers/fournisseur ; opérations | Commanditaire exécutif ; audit interne à travers l'univers d'audit | Approbation de l'objectif et des limites, architecture, évaluations d'impact et de risque, charte de rôle, spécification de contrôle |
| Approbation | Propriétaire du processus commercial responsable | Propriétaire du produit/technique de l'agent et propriétaire de la politique/contrôle assembler le paquet de décision | Assurance du modèle ou de l'IA ; données; GIA/sécurité ; conformité/juridique/confidentialité ; opérations | Commanditaire exécutif ; les propriétaires de contrôle concernés ; audit interne via le reporting des risques | Décision d'utilisation en production, conditions acceptées, exceptions, identité de l'approbateur, justification datée |
| Version | Propriétaire du produit/technique de l'agent | Propriétaires de l'ingénierie, du modèle, des données, de l'IAM/sécurité, des outils et des politiques/contrôles | Propriétaire du processus métier ; assurance du modèle ou de l’IA ; opérations ; conformité/juridique/confidentialité | Sponsor exécutif ; des approbateurs humains nommés ; propriétaire tiers/fournisseur | Manifeste de version, résultats des tests, stratégie Simulation, examen des autorisations, résultat de la restauration, approbation |
| Exécution | Propriétaire du processus métier responsable | Opérations ; propriétaire de la politique/du contrôle ; approbateur humain nommé ; propriétaires techniques, de données, d'identité et d'outils | Assurance du modèle ou de l'IA ; conformité/juridique/confidentialité ; propriétaire tiers/fournisseur | Sponsor exécutif ; audit interne via des rapports convenus | Decision Requests, verdicts politiques, reçus d'outils, Lineage Records, rapprochements des résultats, revues de contrôle |
| Incident | Commandant des opérations et des incidents | Intervenants techniques, IAM/sécurité, données, outils, politique/contrôle, fournisseur et communication | Propriétaire du processus métier ; conformité/juridique/confidentialité ; modèle ou assurance IA | Sponsor exécutif ; des approbateurs humains nommés ; audit interne selon le protocole | Enregistrement des commandes d'incident, population de cas affectés, confinement, notifications, récupération, cause première, nouveau test |
| Modification | Propriétaire du processus commercial responsable | Propriétaire du produit/technique de l'agent et chaque propriétaire dont les limites changent | Assurance du modèle ou de l'IA ; opérations ; conformité/juridique/confidentialité ; propriétaire tiers/fournisseur | Sponsor exécutif ; des approbateurs humains nommés ; audit interne via le reporting des risques | Modification de la classification, différence de dépendance, réévaluation, résultats de régression, conditions, approbation de la version |
| Retraite | Propriétaire du processus commercial responsable | Agent produit/propriétaire technique ; opérations ; propriétaires de données, d'identité, d'outils, de politiques et de fournisseurs | Conformité/juridique/confidentialité ; propriétaire des dossiers ; modèle ou assurance IA | Sponsor exécutif ; les utilisateurs ; audit interne à travers l'univers d'audit | Décision de retrait, révocation d'accès, fermeture de dépendance, disposition des données, preuves conservées, rapprochement des résultats |
Chartes de rôle pour tous les 13 AI rôles de gouvernance d'agent
Un nom de rôle devient utile lorsqu'il comporte cinq tâches complètes : décisions détenues, contrôles opérés, preuves produites, événements d'escalade et limite que le rôle conserve. Placez une personne nommée, un délégué, une date d'effet et une sauvegarde sur chaque ligne. Les postes vacants et les affectations qui se chevauchent constituent des exceptions de contrôle jusqu'à ce que le propriétaire du processus métier responsable les résolve.
Une personne peut occuper plusieurs rôles dans une petite organisation. La preuve doit néanmoins démontrer quel rôle la personne a exercé pour chaque décision et où les garanties d'indépendance s'appliquent.
| Rôle | Décisions qui leur appartiennent | Contrôles qu'ils opèrent | Preuves qu'ils doivent produire | Événements nécessitant une escalade | Limite qu'ils ne peuvent pas déléguer |
|---|---|---|---|---|---|
| Sponsor exécutif | Appétence pour le risque de l'entreprise, financement, priorité stratégique, plafond d'exception de la direction et arrêt du programme | Forum de gouvernance de la direction, limites d'acceptation des risques, allocation des ressources et rapports du conseil d'administration | Mandat approuvé, appétit pour le risque, décisions de financement, décisions d'exception et mises à jour de l'organe directeur | Manque d'appétit pour le risque, préjudice matériel, défaillance du contrôle systémique, propriété non résolue ou ressources insuffisantes | Responsabilité exécutive du mandat, des ressources et de l'escalade dans le cadre de la charte du sponsor |
| Propriétaire du processus commercial responsable | Utilisation prévue, approbation de la production, critères de résultat, conditions d'exploitation, acceptation des risques, priorité de remédiation et retrait | Contrôles des processus, examen des résultats, restrictions d'utilisation, gouvernance des exceptions et recertification du propriétaire | Énoncé d'objectif, schéma de processus, approbation, matrice de responsabilité, examen des résultats, acceptation des risques et preuves de clôture | Impact inattendu sur la personne affectée, dépassement de seuil, contournement du contrôle, dérive d'objectif, incident ou poste vacant du propriétaire | Responsabilité du processus, de ses décisions, de l'impact sur les clients ou les employés et du recours aux fournisseurs |
| Propriétaire du produit/agent technique | Architecture, composants approuvés, acceptation technique, contenu de la version, conditions de déploiement, recommandation de restauration et correction technique | Gestion des versions, portes de génération et de publication, contrôles d'intégration, gestion de la configuration, observabilité et confinement technique | Architecture et flux de données, manifeste de version, résultats de tests, inventaire des dépendances, runbook et enregistrement de restauration | Composant non approuvé, seuil d'échec, comportement instable, dépendance cachée, manque de preuves ou déploiement dangereux | Intégrité technique, inventaire exactitude, reproductibilité et divulgation véridique des limites |
| Propriétaire de l'assurance du modèle ou de l'IA | Méthode d'évaluation, ensembles de données, seuils, conclusion de validation, limites, portée du nouveau test et exception d'assurance | Évaluation indépendante, équipe rouge, tests de sous-groupes et de régression, examen de la dérive et suivi des résultats | Plan d'évaluation, ensemble de données et enregistrement de version, résultats, limitations, conclusion de validation et preuves de nouveau test | Défaillance du seuil, dérive du matériau, conception de test invalide, nouveau mode de défaillance, couverture faible ou limitation non résolue | Intégrité, portée, méthodes, limitations et indépendance de la conclusion d'assurance |
| Propriétaire des données | Sources approuvées, objectif autorisé, seuils de qualité, accès sur le terrain, lignée, conservation, correction et disposition | Qualité des données, provenance, Data Boundaries, minimisation, conservation, correction et rapprochement des sources | Inventaire source, approbation des données, résultats de qualité, lignage, enregistrement d'accès, calendrier de conservation et historique de correction | Source non autorisée, violation de la qualité, écart de provenance, exposition de données sensibles, données obsolètes ou conflit de suppression | Aptitude, utilisation autorisée, provenance et cycle de vie des données dans le domaine du propriétaire |
| IAM/sécurité propriétaire | Conception de l'identité, modèle de délégation, accès effectif, exceptions de sécurité, cycle de vie des informations d'identification, révocation et accès d'urgence | Identités uniques, moindre privilège, authentification, autorisation, limites de session, gestion des secrets, détection et révocation | Enregistrements d'identité, instantanés d'autorité, examens d'accès, modèle de menace, tests de sécurité, exceptions et événements de révocation | Identité partagée ou orpheline, élévation de privilèges, informations d'identification compromises, octroi toxique, contournement ou exploit actif | Intégrité de l'identité, autorité déléguée, posture de sécurité et révocation en temps opportun |
| Tool Catalog propriétaire | Admission de l'outil, affectation du propriétaire, actions approuvées, interface et état de la version, contrat de preuve, suspension et suppression | Complétude du catalogue, attestation de l'outil, schémas d'action, mappage des autorisations, révision de la version, état de santé et désactivation | Tool Catalog entrée, approbation du propriétaire, définition de l'action et de la portée, historique des versions, résultat des tests, reçus et dossier de suspension | Outil non enregistré, poste vacant du propriétaire, dérive de schéma, version non prise en charge, écart de réception, action excessive ou dépendance dangereuse | exhaustivité et état actuel de l'inventaire des outils régis et de son contrat de preuve |
| Propriétaire de la stratégie/du contrôle | Objectif de contrôle, règles de stratégie, seuils, routage des décisions, critères d'exception, test de contrôle et acceptation de la correction | Création de stratégie, simulation, flux de travail d'approbation, évaluation d'exécution, expiration d'exception, surveillance de contrôle et recertification | Spécification de contrôle, version de stratégie, résultats de simulation, verdicts, exceptions, révisions et tests de correction | Contournement de stratégie, règle obsolète, règle conflictuelle, verdict inexpliqué, expiration d'exception ou échec de contrôle | Intention de contrôle, précision des règles, critères de décision et comptabilisation complète des exceptions |
| Approbateur humain nommé | Approuver, refuser, renvoyer ou faire remonter chaque décision consécutive assignée au sein de l'autorité documentée | Examen des preuves, vérification des conflits, vérification de l'autorité, capture des justifications, traitement des délais et escalade | Decision Request, preuves présentées, instantané de l'autorité, décision, justification, horodatage et enregistrement de l'escalade | Preuves insuffisantes, conflit d'autorité, manipulation suspectée, conflit de politique, risque de délai ou impact au-delà du mandat | Exercice personnel de jugement et justification contemporaine de la décision assignée |
| Commandant des opérations et de l'incident | Intervention en cours d'exécution, classification de l'incident, séquence de confinement, restriction de service, récupération et retour à l'opération | Surveillance, tri des alertes, intervention sur appel, procédures d'arrêt et de révocation, rapprochement des cas concernés, récupération et exercices | Examen opérationnel, historique des alertes, chronologie des incidents, décisions de commandement, population affectée, preuve de récupération et enseignements tirés | Exécution non confinée, impact sur les services matériels ou les résultats, alerte répétée, perte de preuves, échec de récupération ou déclencheur de notification | Commande des incidents, comptabilité de confinement, critères de récupération et communication précise de l'état |
| Conformité/juridique/confidentialité | Critères applicables, situation juridique et de confidentialité, besoin d'évaluation, garanties contractuelles, obligations de notification et avis de dépôt formel | Inventaire réglementaire, cartographie des contrôles, examen de la confidentialité et de l'impact, surveillance des modifications juridiques, flux de notification et problème de problème | Mémo de critères, évaluations, cartographie des contrôles, conditions contractuelles, conseils, notifications, dépôts et enregistrement des modifications juridiques | Modification de la loi ou des directives, nouvelle juridiction ou objectif, impact sur les droits, incident sur la vie privée, contact avec le régulateur ou interprétation contestée | Conseils professionnels, mises en demeure, décisions de privilège et escalade dans le cadre du mandat attribué |
| Audit interne | Univers d'audit, portée de la mission, critères, échantillonnage, fiabilité, notation des constatations, conclusion, reporting et vérification de suivi | Planification indépendante, demandes de preuves, tests de population, échantillonnage, réexécution, examen des documents de travail, rapports et suivi | Évaluation des risques, plan d'audit, enregistrement de population et d'échantillon, documents de travail, exceptions, rapport et clôture vérifiée | Limitation de la portée, dérogation de la direction, échec de l'intégrité des preuves, découverte importante, menace à l'indépendance ou correction en retard | Portée, procédures, conclusion et reporting direct de l'audit indépendant et objectif |
| Propriétaire tiers/fournisseur | Sélection des fournisseurs, diligence raisonnable, contrôles contractuels, acceptation du service, réponse aux performances, accès aux preuves, sortie et remplacement | Inventaire des fournisseurs, diligence raisonnable, examen des contrats et des SLA, examen des services, suivi des problèmes, collecte de preuves et sortie tests | Diligence raisonnable, calendrier des contrats et des responsabilités, rapports de service, incidents, preuves de contrôle, avis de modification et enregistrement de sortie | Échec du contrôle du fournisseur, sous-traitant opaque, changement de service, refus de preuves, incident, violation du SLA, risque de concentration ou résiliation | Relation commerciale, application du contrat, responsabilité du fournisseur et chemin de sortie exécutable |
Variez la matrice pour quatre modèles opérationnels d'agents d'IA
Un RACI universel masque les différences matérielles en matière de contrôle et d'autorité. Enregistrez un remplacement spécifique au scénario à côté de la matrice par défaut, identifiez chaque cellule modifiée et approuvez la variation avant utilisation en production. Le propriétaire responsable du processus métier signe la version complète.
Les quatre modèles ci-dessous couvrent les limites de production communes. Chaque modèle préserve la responsabilité nommée tout en déplaçant la responsabilité technique, d'outil, de fournisseur ou de décision de cas vers le rôle avec le contrôle réel.
| Modèle opérationnel | Modèle de responsabilité | Changements de responsabilité | Preuves requises | Limite à préserver |
|---|---|---|---|---|
| Agent construit en interne | Le propriétaire du processus métier est propriétaire de l'objectif et des résultats ; le propriétaire du produit/technique de l'agent est propriétaire de l'architecture et des versions | Les propriétaires du modèle interne, des données, de l'IAM/sécurité, des outils, des politiques et des opérations exploitent la pile de contrôle complète ; le propriétaire du fournisseur couvre uniquement les modèles ou services externes | Origine de la source et de la construction, architecture, inventaire des composants, tests, approbation de la version, modèle d'autorité, enregistrements d'exécution et preuve de restauration | L'entreprise conserve le contrôle direct de la conception, de l'accès, de la publication, du fonctionnement, des preuves et du retrait |
| Agent du fournisseur intégré dans un processus métier | Le propriétaire du processus métier de l'entreprise est propriétaire de l'utilisation et des résultats ; le propriétaire tiers/fournisseur est propriétaire de la relation fournisseur ; le fournisseur est propriétaire de la portée de son système sous contrat | L'entreprise configure l'objectif, les données, l'accès, les outils, la politique, l'examen humain, la surveillance, les incidents et la sortie ; le fournisseur fournit des contrôles techniques contractuels, des avis de modification et des preuves | Évaluation des rôles spécifiques aux faits, calendrier des responsabilités, inventaire du système et des sous-traitants, enregistrement de configuration, preuves de service, incidents, avis de modification et test de sortie | L'entreprise conserve l'autorité sur le déploiement, les décisions des personnes concernées, les conditions de fonctionnement, le confinement et l'acceptation des fournisseurs |
| Processus multi-agents avec plusieurs propriétaires d'outils | Un propriétaire de processus métier est propriétaire du résultat final ; un agent propriétaire du produit/technique possède l'orchestration ; chaque propriétaire d'outil est propriétaire de sa limite d'action | Les propriétaires d'agents d'envoi et de réception sécurisent chaque transfert ; Tool Catalog et les propriétaires IAM/sécurité rapprochent les identités, les autorisations, les versions, les reçus et les limites déléguées à travers le graphique | Graphique des dépendances, propriétaires d'agents et d'outils, transferts authentifiés, propagation des objectifs, instantanés d'autorité, réceptions d'outils, confinement des échecs et parcours de bout en bout | Les sous-agents et les outils reçoivent une autorité limitée ; le résultat final se rapproche de chaque action contributive et propriétaire |
| Décision conséquente avec approbation humaine obligatoire | Le propriétaire du processus métier est propriétaire du cadre de processus et de résultats ; l'approbateur humain nommé est propriétaire de la décision individuelle d'approbation, de refus, de retour ou de remontée | Le propriétaire de la politique/du contrôle achemine chaque cas dans le champ d'application ; le propriétaire technique empêche l'exécution avant une décision valable ; les opérations surveillent les files d'attente, l'autorité, l'expiration et les tentatives de contournement | Decision Request, les preuves présentées, les versions de politique et d'autorité, l'identité du réviseur, la justification, l'horodatage, la réception de l'action finale et l'historique des dérogations | L'approbateur nommé conserve le jugement du cas ; le propriétaire du processus métier conserve la responsabilité en matière de politique, de personnel, de qualité des résultats et de remédiation |
Exemple concret : responsabilité d'un parcours de décision de prêt réglementé
Supposons qu'une banque de détail européenne utilise un agent pour rassembler les données de candidature, appeler un modèle de risque de crédit, appliquer une politique de prêt, acheminer chaque recommandation à un souscripteur pour approbation obligatoire et rédiger le résultat final. Un système d'IA destiné à évaluer la solvabilité d'une personne physique ou à établir une cote de crédit est répertorié à 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 de l'article 6(3); le profilage dans le cadre d’une utilisation visée à l’Annexe III reste à haut risque.
Cet exemple traite le fournisseur de modèle et d'agent comme fournisseur et la banque comme déployeur sur la base des faits indiqués. Le tableau suit le même parcours utilisé dans le cadre d'audit d'entreprise et change le point de vue de la procédure d'audit à la responsabilité nommée. Chaque étape se termine par un artefact et une condition d’escalade.
| Étape du parcours | Décision responsable | Exécution responsable | Consulté/contesté par | Preuve | Condition d'escalade |
|---|---|---|---|---|---|
| 1. Approuver l'objectif et les limites | Le propriétaire du processus métier approuve l'utilisation du crédit, les clients, les résultats, les limites et l'approbation obligatoire | Le propriétaire technique/produit de l'agent documente le système et les limites du processus | Commanditaire exécutif ; assurance du modèle ; conformité/juridique/confidentialité ; données; IAM/sécurité | Approbation de l'objectif, base de classification, schéma des processus, matrice de responsabilité et conditions | Objectif peu clair, classification non prise en charge, impact sur les droits, propriétaire manquant ou risque résiduel inacceptable |
| 2. Accepter le système du fournisseur | Le tiers/propriétaire du fournisseur accepte le fournisseur au sein de l'autorité commerciale approuvée | Le propriétaire du fournisseur coordonne la diligence raisonnable ; les propriétaires techniques et d'assurance testent le service | Propriétaire du processus métier ; conformité/juridique/confidentialité ; GIA/sécurité ; données; assurance du modèle | Évaluation du rôle, diligence raisonnable, calendrier du contrat, preuves du fournisseur, liste des sous-traitants et plan de sortie | Refus de preuves, lacune de contrôle non résolue, dépendance opaque, lacune contractuelle importante ou échec du test de sortie |
| 3. Lier l'identité, les données et les outils | Les propriétaires de données, IAM/sécurité et Tool Catalog approuvent leurs limites respectives | Le propriétaire technique configure les identités approuvées, Data Boundaries et les actions des outils | Propriétaire de politique/contrôle ; conformité/juridique/confidentialité ; opérations | Instantanés d'identité et d'autorité, approbation des données, Tool Catalog entrées, versions, étendues et tests | Privilège excessif, source non approuvée, outil non enregistré, propriétaire manquant ou reçu incomplet |
| 4. Approuver la version | Le propriétaire technique/produit de l'agent approuve la version technique | Les propriétaires d'ingénierie et de composants créent, testent et préparent la version | Propriétaire du processus métier ; assurance du modèle ; données; GIA/sécurité ; outil; politique; opérations | Manifeste de publication, évaluation, simulation de politique, examen des accès, test des preuves et résultat de la restauration | Seuil d'échec, objectif modifié, exception non résolue, manque de preuves ou échec de la restauration |
| 5. Assembler l'application | Le propriétaire du processus métier est propriétaire du contrôle de saisie des dossiers | Les propriétaires techniques et des données effectuent la récupération dans les limites approuvées | IAM/sécurité ; conformité/juridique/confidentialité ; opérations | ID de voyage, références de source, hachages de requête et de source, version de limite et enregistrement de rédaction | Cas manquant ou en double, données interdites, non-concordance de limite, source obsolète ou écart de provenance |
| 6. Invoquer le modèle et appliquer la stratégie | Le propriétaire de la stratégie/du contrôle est propriétaire du verdict de routage ; le propriétaire technique est propriétaire de l'intégrité d'exécution | Les propriétaires techniques, de modèles, de données et d'outils exécutent les versions approuvées et capturent les reçus | Assurance du modèle ; GIA/sécurité ; Propriétaire du processus métier | ID de modèle et de version, hachages d'entrée et de sortie, version de stratégie, règles correspondantes, verdict et horodatages | Version non approuvée, contournement de stratégie, conflit de règles, action excessive de l'outil ou dépassement de seuil |
| 7. Décider du cas consécutif | L'approbateur humain nommé est propriétaire de la décision du cas ; Le propriétaire du processus métier est propriétaire du cadre de résultats | Le souscripteur examine les preuves et approuve, refuse, renvoie ou fait remonter dans les limites de l'autorité | Propriétaire de la politique/du contrôle ; conformité/juridique/confidentialité ; assurance du modèle | Decision Request, preuves présentées, instantané de l'autorité, décision, justification et moment de la décision | Preuves insuffisantes, conflit entre évaluateurs, autorité expirée, signal de manipulation ou impact au-delà du mandat |
| 8. Valider et communiquer le résultat | Le propriétaire du processus métier est propriétaire du résultat final du processus | Les propriétaires des opérations et des outils techniques rédigent la décision approuvée et émettent la communication requise | Approbateur humain nommé ; conformité/juridique/confidentialité ; propriétaire de la politique/du contrôle | Référence d'approbation, demande et réponse de l'outil, état avant et après, notification et itinéraire de révision | Inadéquation des résultats, effet secondaire supplémentaire, échec de notification, itinéraire de révision interrompu ou reçu manquant |
| 9. Surveiller et répondre | Le commandant des opérations et des incidents est propriétaire des décisions en cas d'incident. | Les propriétaires des opérations, techniques, IAM/sécurité, données, outils, politiques et fournisseurs enquêtent et contiennent | propriétaire des processus métier ; assurance du modèle ; conformité/juridique/confidentialité | Surveillance des résultats, alertes, liste des cas concernés, chronologie des incidents, confinement, récupération et nouveau test | Dérive matérielle, exception répétée, impact sur les droits, exposition des données, action incontrôlée ou perte de preuves |
| 10. Modification ou retrait | Le propriétaire du processus métier approuve la modification de l'utilisation ou le retrait ; le propriétaire technique approuve la version | Le propriétaire technique et tous les propriétaires de contrôle concernés réévaluent, publient, révoquent, archivent ou mettent hors service | Sponsor exécutif ; assurance du modèle ; conformité/juridique/confidentialité ; propriétaire du vendeur ; opérations | Évaluation du changement, nouvelle matrice, tests, approbation, révocations, disposition des données et preuves conservées | Changement d'objectif, modification substantielle, perte de dépendance, échec de la réévaluation ou fermeture incomplète |
Responsabilité du fournisseur et du déployeur dans l'exemple de prêt
La EU AI Act définit le fournisseur et le déployeur à travers les faits. En vertu de l'article 3(3), un fournisseur développe ou fait développer un système d'IA et le met sur le marché ou le met en service sous son propre nom ou sa propre marque. En vertu de l'article 3(4), un déployeur utilise un système d'IA sous son autorité en dehors de son activité personnelle non professionnelle. Dans cet exemple, le vendeur est le fournisseur et la banque est le déployeur du système fourni et de l'utilisation déclarée.
Article 25 can modifie le rôle de fournisseur pour un système à haut risque lorsqu'un déployeur ou un autre tiers applique son propre nom ou sa propre marque, apporte une modification substantielle ou change l'objectif prévu de sorte que le système devient à haut risque. L'article 26 duties s'applique aux déployeurs de systèmes à haut risque et couvre l'utilisation conformément aux instructions, l'attribution d'une surveillance humaine compétente et autorisée, la surveillance opérationnelle, l'action et le reporting en cas de risque ou d'incident grave, et la conservation des journaux générés automatiquement sous le contrôle du déployeur pendant au moins six mois, sauf disposition contraire d'une autre loi applicable.
| Limite ou événement | Fournisseur en tant que fournisseur dans cet exemple | Banque en tant que déployeur dans cet exemple | Preuve à conserver | Base juridique |
|---|---|---|---|---|
| Classification des rôles | Développe ou fait développer le système et le fournit sous le nom ou la marque du fournisseur | Utilise le système sous l'autorité de la banque pour le processus de crédit | Évaluation du rôle, identité du système, objectif prévu, noms et marques, contrat et approbation | Article 3(3)–(4) |
| Instructions et conditions de fonctionnement | Définit la portée du système fourni, les instructions, les limitations déclarées et la configuration prise en charge | Utilise le système à haut risque conformément aux instructions et documente toute condition de fonctionnement ou exception | Instructions et version, configuration des banques, procédure de fonctionnement, exceptions et approbation du propriétaire | Article 26(1) |
| Supervision humaine | Fournit la capacité du système à haut risque pour une surveillance efficace dans la conception fournie | Attribue la supervision aux personnes possédant les compétences, la formation, l'autorité et le soutien nécessaires | Conception de la supervision, attribution des rôles, formation, autorité, Decision Requests, justifications et dérogations | Articles 14(1)–(4) et 26(2) |
| Surveillance, risque et incident grave | Reçoit et agit sur les rapports bancaires dans le cadre du prestataire et du périmètre contractuel | Surveille le fonctionnement et prend les mesures nécessaires et prend les mesures nécessaires pour signaler lorsqu'un risque ou un incident grave survient | Examen de la surveillance, enregistrements des risques et des incidents, notification des fournisseurs, réponse, confinement et suivi | Article 26(1)–(6) |
| Journaux sous le contrôle de chaque partie | Conserve les journaux des systèmes à haut risque générés automatiquement sous le contrôle du fournisseur pendant au moins six mois, sous réserve des autres lois applicables | Conserve les journaux générés automatiquement sous le contrôle du déployeur pendant au moins six mois, sous réserve des autres lois applicables | Inventaire des journaux, mappage de contrôle, calendrier de conservation, juridique remplacement, enregistrement d'accès et preuve de suppression | Articles 19(1) et 26(6) |
| Rebranding, modification substantielle ou changement d'objectif | La position du fournisseur d'origine change pour le système spécifique conformément à l'article 25 conditions et règles de coopération | La banque peut devenir fournisseur du système à haut risque lorsque les conditions de l'article 25(1) sont remplies | Évaluation des changements, enregistrement de la marque et de l'objet, analyse des modifications, accord écrit, accès technique et approbation du nouveau rôle | Article 25(1)–(5) |
Conserver le statut juridique actuel joint au dossier de responsabilité
Règlement (UE) 2024/1689 is loi en vigueur avec application progressive. L'Omnibus numérique sur l'IA le modifie en tant que Règlement (UE) 2026/1744, qui définit 2 décembre 2027 pour Article 6(2)/Annexe III systèmes autonomes à haut risque et 2 août 2028 pour Article 6(1)/Annexe I Systèmes intégrés aux produits.
Le Parlement a approuvé le texte le 16 juin 2026, le Conseil l'a adopté le 29 juin 2026 et l'acte a été signé le 8 juillet 2026. Il a été publié au Journal officiel le 24 juillet 2026 (JO L du 2026/1744, 24.7.2026) et entre en vigueur le 27 juillet 2026, soit le troisième jour après sa publication. Enregistrez les deux instruments dans le registre de responsabilité et lisez les dates modifiées du texte consolidé du règlement (UE) 2024/1689 before en les utilisant dans une conclusion juridique.
Maintenir l'audit interne indépendant de la responsabilité de la direction
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, le soutien, la surveillance et la remise en question aux rôles de deuxième ligne, ainsi qu'une assurance et des conseils indépendants et objectifs à l'audit interne. Les lignes décrivent les rôles et peuvent couvrir plusieurs départements.
La direction conserve la conception, l'approbation, l'exploitation, la propriété du contrôle, l'acceptation des risques et les mesures correctives de l'agent. L'audit interne définit son propre champ d'application, ses propres critères, son échantillonnage, ses procédures, ses notes, ses conclusions, son itinéraire de reporting et son suivi. Le travail de conseil nécessite des garanties documentées chaque fois qu’il pourrait affecter l’indépendance ultérieure.
| Groupe de rôles | Possède | Produit | Limite de confiance en matière d'audit interne |
|---|---|---|---|
| Gestion de première ligne | Entreprise résultats, fonctionnement des agents, conception et fonctionnement des contrôles, incidents, acceptation des risques et mesures correctives | Approbations, enregistrements d'exécution, examens de contrôle, incidents, résultats, exceptions et preuves de mesures correctives | Les preuves de gestion sont soumises à des tests d'exhaustivité, d'intégrité et d'efficacité opérationnelle |
| Rôles de deuxième ligne | Expertise, normes, support, surveillance et contestation dans le cadre des mandats de risque, de conformité, de sécurité, de confidentialité et d'assurance des modèles | Évaluations, dossiers de contestation, surveillance, exceptions, opinions et escalades | Le degré d'objectivité, de compétence, de portée, de période et de fiabilité de la source détermine la fiabilité |
| Audit interne | Plan d'audit indépendant, portée, critères, procédures, conclusion, reporting et suivi vérifié | Enregistrements de population et d'échantillons, documents de travail, conclusions, rapports et vérification de clôture | L'audit interne préserve l'indépendance et évite l'approbation de la direction ou la propriété de contrôle pour le système audité |
Associer la responsabilité aux preuves opérationnelles dans KLA
Une matrice de responsabilité devient opérationnelle lorsque chaque propriétaire nommé peut pointer vers un contrôle actuel et une source de vérité. La cartographie du produit ci-dessous relie la décision de propriété, l'action d'exécution, l'enregistrement de reconstruction, l'examen en cours et les preuves conservées sans modifier la responsabilité sous-jacente.
| Besoin en matière de responsabilité | Surface KLA | Historique d'exploitation |
|---|---|---|
| Nom de la propriété de l'agent, versions approuvées, état et processus responsable | Agent Registry | Propriétaire de l'agent, historique des versions, état d'approbation, limite opérationnelle et statut de retrait |
| Nommer chaque propriétaire d'outil et régir les actions, les étendues, les versions et l'état | Tool Catalog | Propriétaire de l'outil, contrat d'action, limite d'autorisation, version, exigence de réception et état de suspension |
| Définir les objectifs de contrôle, les règles, les seuils, le routage et les exceptions | Policy Builder | Politique propriétaire, version approuvée, résultats de simulation, règles, seuils et cycle de vie des exceptions |
| Acheminer les cas consécutifs vers une personne nommée avec l'autorité actuelle | Decision Desk | Decision Request, preuves présentées, autorité de réviseur, décision, justification et horodatage |
| Reconstruisez le parcours et inspectez l'enregistrement de contrôle chronologique | Lineage Explorer + Audit Trail | Identité, entrées, appels de modèle et d'outil, verdicts de politique, décisions humaines, effets et événements corrélés |
| Examiner l'état, la dérive, les résultats, les alertes et les mesures correctives du contrôle | Assurance Center | Alerte d'assurance, examen du propriétaire, population affectée, plan de remédiation, nouveau test et fermeture |
| Conserver les artefacts prêts à être examinés et les packages vérifiables de manière indépendante | Evidence Room | Matrice de responsabilité, approbations, évaluations, manifestes, métadonnées d'intégrité, rapports et preuves de cas conservées |
Testez si la responsabilité de l'agent IA est réelle
Un conseil d'administration, un régulateur ou un auditeur interne peut poser ces questions et exiger un propriétaire nommé ainsi qu'un artefact contemporain pour chaque réponse. Un organigramme, le nom d’un comité ou la déclaration d’un fournisseur laisse à lui seul la responsabilité non prouvée.
- 1. Un propriétaire de processus métier nommé est-il responsable de l'objectif de l'agent, de l'utilisation de la production, des résultats, des incidents, des modifications et du retrait ?
- 2. Ce propriétaire peut-il arrêter l'agent, restreindre ses limites d'exploitation, financer la correction et expliquer chaque exception acceptée ?
- 3. Chaque version, stratégie, source de données, identité, outil et dépendance de fournisseur a-t-elle un propriétaire actuel avec autorité d'approbation ?
- 4. L'organisation peut-elle retracer chaque action consécutive jusqu'à l'agent, le principal parrain, le verdict politique, la décision humaine nommée, l'effet de l'outil et le résultat commercial ?
- 5. Les quatre variantes pertinentes du modèle opérationnel apparaissent-elles dans la matrice approuvée, avec chaque affectation modifiée et limite conservée documentée ?
- 6. Chaque approbateur humain nommé peut-il prouver son autorité actuelle, les preuves examinées, l'état du conflit, la décision, la justification et le calendrier de l'affaire ?
- 7. Le commandant de l'incident peut-il identifier l'ensemble de la population affectée, révoquer l'autorité, contenir l'exécution, récupérer en toute sécurité, informer les parties requises et prouver que les tests ont été effectués ?
- 8. Chaque changement de modèle matériel, d'invite, de politique, d'autorisation, d'outil, de données, de processus ou de fournisseur déclenche-t-il une réévaluation et une nouvelle décision d'approbation ?
- 9. Les rôles de fournisseur et de déployeur sont-ils documentés à partir du nom réel, de l'autorité, de l'objectif, de la modification et des faits de fonctionnement, avec l'article 25 changes réévalué ?
- 10. L'audit interne a-t-il un accès indépendant aux populations complètes, aux dossiers sources, aux spécialistes, aux rapports de l'organe directeur et aux preuves de suivi ?
Foire aux questions
Qui est responsable lorsqu'un agent IA commet une erreur ?
Le propriétaire du processus métier responsable est propriétaire de l'utilisation de la production et des résultats commerciaux. Le commandant de l'incident est responsable des décisions de confinement et de récupération, tandis que les propriétaires techniques, de modèles, de données, de sécurité, d'outils, de politiques, d'approbation et de fournisseurs répondent des contrôles définis. L'enregistrement de l'incident doit identifier la limite défaillante, le propriétaire responsable, la population affectée, les mesures correctives et l'escalade exécutive.
Quelle est la différence entre la responsabilité du fournisseur et celle du déployeur ?
En vertu de l'article 3 de de la [Loi de l'UE sur l'IA] (https://eur-lex.europa.eu/eli/reg/2024/1689/oj), un fournisseur développe ou fait développer un système et le met sur le marché ou le met en service sous son nom ou sa marque ; un déployeur utilise un système sous son autorité en dehors de son activité personnelle non professionnelle. L'article 25 can modifie le rôle du fournisseur après un changement de marque, une modification substantielle ou un changement d'objectif qui rend le système à haut risque. L'article 26 assigns impose des obligations d'exploitation conditionnelles aux déployeurs de systèmes à haut risque. Sources : source
La responsabilité d'un agent IA peut-elle être déléguée à un fournisseur ?
Un fournisseur peut assumer des responsabilités contractuelles en matière de conception, de service, de contrôle, d'incident, de changement et de preuve. Le propriétaire du processus métier de l'entreprise conserve la responsabilité de l'utilisation de l'agent au sein du processus de l'entreprise, y compris les conditions de fonctionnement, les décisions des personnes concernées, l'examen des résultats, l'autorité de confinement, l'acceptation du fournisseur et la sortie. Mettez les deux périmètres dans le contrat et la matrice de responsabilité interne.
Que possède l'audit interne pour les agents IA ?
L'audit interne est propriétaire de son univers d'audit, de la portée de sa mission, de ses critères, de son échantillonnage, de ses décisions de confiance, de ses procédures, de ses constatations, de ses conclusions, de ses rapports et de sa vérification de suivi. La direction est propriétaire de l'agent, des contrôles, des approbations, de l'acceptation des risques, de l'exploitation, des incidents et des mesures correctives. Cette séparation prend en charge le rôle d'assurance indépendant et objectif décrit par le [Modèle à trois lignes de l'IIA] (https://www.theiia.org/en/resources/statements-of-position#threelines). Sources : source
Qui approuve une décision conséquente d'un agent IA ?
Un approbateur humain nommé décide du cas individuel dans le cadre d'une autorité documentée lorsque l'approbation humaine est obligatoire. Le propriétaire du processus métier est propriétaire du cadre décisionnel, du personnel, de la qualité des résultats et des mesures correctives. Le propriétaire de la politique/du contrôle est propriétaire des critères de routage et le propriétaire technique garantit que l'exécution attend un enregistrement de décision valide.
Comment la responsabilité devrait-elle fonctionner dans un système multi-agents ?
Nommez un propriétaire de processus métier pour le résultat final et un propriétaire technique pour l'orchestration. Attribuez un propriétaire à chaque agent, outil, identité, limite de données, stratégie et dépendance au fournisseur. Authentifiez chaque transfert, propagez l'objectif et les limites déléguées, conservez les reçus d'action, limitez les échecs en cascade et rapprochez le parcours final avec chaque propriétaire et effet contributeur.
Points clés à retenir
La responsabilité de l'agent IA devient défendable lorsqu'un propriétaire de processus métier détient l'autorité sur les résultats et que chaque décision de cycle de vie, contrôle d'exécution, artefact, escalade et limite conservée a un propriétaire nommé. Appliquez la variation spécifique au scénario, tracez un parcours conséquent, documentez les faits du fournisseur et du déployeur, et préservez l'indépendance de l'audit interne. Utilisez le cadre d'audit des agents Enterprise AI pour un travail complet sur le terrain et l'évaluation de l'état de préparation à l'audit des agents pour identifier la propriété, l'autorité, les contrôles et les preuves manquants.