Un agent d'IA doit être approuvé avant son exécution lorsque l'action proposée dépasse le seuil d'autorité, de conséquence, de réversibilité, de données, de nouveauté, de confiance ou d'impact en aval d'une organisation. Les actions de routine au sein d'une autorité explicite peuvent être autorisées. Une action autorisée avec un signal de révision peut donner lieu à un avertissement. Une exception conséquente doit s’arrêter pour un humain autorisé. Une action interdite, non autorisée, mal formée, obsolète ou invérifiable doit cesser.
Ce guide répond à la question opérationnelle à travers les secteurs. Il utilise allow, warn, require_approval et block comme modèle de décision pratique pour les actions individuelles des agents. L'article 14 guide de la loi européenne sur l'IA (/blog/eu-ai-act-article-14-human-oversight-requirements) couvre la tâche distincte menée par la réglementation : la mise en œuvre des capacités de surveillance humaine requises pour les systèmes d'IA à haut risque. Ce guide contient des informations générales, à jour en date du 28 juillet 2026, et ne remplace pas les conseils juridiques, de risque ou techniques.
Sources : source
La règle d'approbation des quatre résultats
Évaluez l'effet secondaire proposé avant qu'il n'atteigne l'outil ou le système en aval. Appliquez toutes les règles pertinentes, puis conservez le résultat le plus fort. Un blocage ne peut pas être affaibli par une règle d'autorisation de contrepartie, et une approbation requise ne peut pas disparaître parce que le montant se trouve être inférieur à un seuil financier.
Le résultat décrit le comportement d'exécution. allow libère l'action au sein de l'autorité actuelle. warn le libère et crée un suivi défini. require_approval conserve l'action exacte jusqu'à ce qu'un humain autorisé décide. bloquer empêche l'action d'atteindre l'effet secondaire gouverné.
| Résultat | À utiliser quand | Comportement d'exécution | Exceptions et préséance |
|---|---|---|---|
| autoriser | L'action est routine, au sein d'une autorité déléguée, à faible conséquence, réversible, utilise des données approuvées, provient d'une version connue et a un contexte complet. | Exécuter et conserver l'action ordinaire et l'enregistrement de la politique. | Tout remplacement de déclencheur de blocage, d'approbation ou d'avertissement est autorisé. Le contexte d’identité, de politique ou de preuve manquant n’est jamais autorisé par défaut. |
| avertir | L'action reste autorisée et réversible mais est proche d'un seuil, inhabituelle, nouvellement observée ou sélectionnée pour un échantillonnage d'assurance. | Exécutez, enregistrez le signal et acheminez le suivi défini sans conserver l'effet secondaire. | Utilisez require_approval lorsqu'un retard après l'exécution laisserait un effet important ou difficile à inverser. Utilisez block lorsque l’autorité ou le contexte requis est absent. |
| require_approval | L'action est importante, difficile à annuler, affectant les droits, proche d'une limite d'autorité, sensible, nouvelle, peu fiable ou susceptible de créer un effet significatif en aval. | Conserve l'action exacte et le jeu de paramètres. Reprenez uniquement après l'approbation d'un réviseur éligible avant l'expiration et que le contexte lié reste actuel. | Un réviseur ne peut pas approuver une action interdite. Une demande expirée ou substantiellement modifiée nécessite une nouvelle évaluation et un nouveau Decision Request. |
| bloquer | L'action est interdite, en dehors de l'autorité, cible une limite de données interdite, échoue à un contrôle obligatoire, comporte un contexte non valide ou ne peut pas être évaluée ou mise en évidence en toute sécurité. | Arrêtez-vous avant l'effet secondaire gouverné et enregistrez la raison. | Modifiez l'action ou la politique via le processus de changement régi. L’autorité de bris de verre doit être une voie politique distincte, limitée dans le temps, avec ses propres preuves et un examen rétrospectif. |
Mappez les sept entrées d'approbation à la stratégie
Les seuils appartiennent à l'organisation propriétaire de l'action. Commencez par un inventaire d’actions et définissez des bandes testables pour les sept entrées. Le montant financier à lui seul est insuffisant : une modification de droits d’une valeur nulle ou la divulgation de données restreintes peut comporter plus de risques qu’un transfert réversible important entre comptes contrôlés.
Conservez les entrées sous forme de règles distinctes. Un score combiné peut cacher un fait décisif. Une destination interdite doit rester bloquée même si toutes les autres entrées semblent routinières.
| Entrée | Autoriser ou avertir la bande | Exiger une bande d'approbation | Bloquer la bande |
|---|---|---|---|
| Risque et droits affectés | Faible conséquence dans le cadre de l'objectif approuvé ; avertir d'une anomalie limitée. | Conséquence importante pour le client, le travailleur, le patient, le citoyen, la sécurité ou la conformité. | Utilisation interdite, risque résiduel inacceptable ou action en dehors de l'objectif approuvé. |
| Montant ou exposition | Dans une limite explicite par action, par jour et par destination. | Proche ou supérieur à une limite du fabricant, ou un seuil d'exposition global est franchi. | Au-dessus des limites absolues d'autorité, de liquidité, de sanctions ou de contrepartie. |
| Réversibilité | Lecture, brouillon, simulation ou mise à jour interne réversible et fiable. | Communication externe, paiement, suppression, dépôt, modification des droits ou voie d'indemnisation coûteuse. | Aucun chemin de récupération sécurisé pour les conditions actuelles. |
| Sensibilité des données | Champs approuvés à l'intérieur de la limite de données attribuée. | Accès restreint aux données, divulgation, exportation, risque de réidentification ou nouveau destinataire. | Catégorie, destination, objectif, région interdits ou autorité légale manquante. |
| Nouveauté et changement | Version, outil, itinéraire, destination et modèle de fonctionnement connus. | Nouvelle rampe de version, première utilisation d'un outil ou d'une destination, séquence inhabituelle ou changement de configuration de matériau. | Composant non approuvé, destination inconnue ou version invérifiable. |
| Confiance et qualité des preuves | Bande de confiance validée avec des preuves de source complètes et actuelles. | Score limite, sources contradictoires, preuves non obligatoires manquantes ou signal non distribué. | Preuves obligatoires manquantes, obsolètes au-delà de la politique, entrées mal formées ou absence de base de décision fiable. |
| Impact en aval | Effet interne limité sans engagement externe. | Crée un engagement juridique, financier, de sécurité, client, opérationnel ou multi-système. | L'effet en cascade ou incontrôlé, la dépendance interdite ou le confinement ne peuvent pas être confirmés. |
Humain dans la boucle, sur la boucle et aux commandes
Ces étiquettes décrivent les modalités de fonctionnement. Il s’agit de termes de conception utiles et ne constituent pas des résultats définis par la loi de l’UE sur l’IA. Choisissez l’arrangement qui donne à la personne responsable suffisamment de temps, de contexte et d’autorité pour prendre le risque d’action.
| Disposition | Rôle humain | Meilleur ajustement | Test de contrôle |
|---|---|---|---|
| L'humain dans la boucle | Décide d'une action spécifique proposée avant son effet secondaire. | Actions consécutives, difficiles à annuler, exceptionnelles ou affectant les droits. | L'action reste suspendue jusqu'à ce que la bonne personne examine le contexte lié et prenne une décision avant l'expiration. |
| L'humain dans la boucle | Surveille l'exécution limitée et peut intervenir, mettre en pause, inverser ou escalader. | Activité matérielle mais réversible avec une détection fiable et une fenêtre d'intervention testée. | Un exercice réaliste prouve que la personne peut détecter la condition et atteindre l'état de sécurité avant que le préjudice ne devienne important. |
| L'humain aux commandes | Possède le mandat, la tolérance au risque, la politique, les limites d'exploitation, l'autorité d'arrêt, le redémarrage et la responsabilité. | Chaque système d'agent déployé, y compris les systèmes dont les actions de routine ne font pas l'objet d'un examen individuel. | Les propriétaires nommés peuvent changer d'autorité, suspendre le système, demander un examen, entendre des appels et prouver ces décisions. |
Utiliser la séparation maker-checker pour les actions consécutives
Le créateur crée ou sponsorise la demande. Pour une action d'agent, l'enregistrement du créateur doit identifier l'agent, son propriétaire responsable, le mandant demandeur et l'effet secondaire exact proposé. Le vérificateur est une personne distincte et qualifiée ayant autorité pour cette classe d'action. Le vérificateur examine les preuves et choisit d'approuver, de rejeter, de demander des modifications ou de faire remonter la demande.
Appliquer la séparation au moment de la décision. Un nom de groupe dans une définition de workflow ne prouve pas que la personne qui a agi était éligible ou indépendante. Résolvez l’identité actuelle, le rôle, la délégation, les conflits et l’origine de la demande lorsque la décision est prise.
- Lier la demande. Hachez ou liez d'une autre manière l'action, les paramètres, la destination, les entrées de politique et les preuves du réviseur afin que l'approbation ne puisse pas être relue pour une demande modifiée.
- Résoudre l'éligibilité. Vérifiez l'identité de l'évaluateur, son rôle actif, sa limite d'autorité, son statut de formation et tout conflit ou relation avec le demandeur.
- Rendre un jugement indépendant possible. Afficher les faits sources, l'incertitude, les limites, les raisons politiques, les alternatives et les conséquences en aval sans présélectionner l'approbation.
- Enregistrez une décision. Capturez l'identité, l'instantané du rôle, la décision, la raison, la référence de justification, l'heure et les preuves digèrent le vérificateur.
- Revalider avant la publication. Rejeter l'approbation périmée lorsque l'action, la preuve, la politique, l'identité, l'autorité, la destination ou l'état commercial pertinent ont changé.
- Joignez le résultat. Conservez le reçu d'exécution réel et l'effet en aval sous les mêmes identifiants d'exécution et de décision.
Donnez à l'examinateur le contexte nécessaire pour décider
Un Decision Request utile répond à la décision dans un court récit, avec des détails structurés disponibles pour vérification. L’examinateur doit comprendre ce qui va se passer, pourquoi la politique a acheminé l’action, quels faits restent incertains, quelle autorité ils détiennent et quand la demande devient obsolète.
| Contexte | Contenu utile minimum | Pourquoi cela modifie la décision |
|---|---|---|
| Action et conséquence | Action exacte, cible, paramètres importants, partie affectée, systèmes en aval et effet commercial attendu. | L'examinateur voit l'engagement qu'il autorise. |
| Identité et autorité | Principal demandeur, agent, propriétaire responsable, rôle de réviseur requis, limite d'autorité et règle de vérificateur de fabricant. | L'examinateur peut vérifier si la demande et la décision sont autorisées. |
| Résultat de la stratégie | Résultat, règles correspondantes, codes de motif, version de la stratégie, valeurs évaluées et alternatives sûres. | L'examinateur voit pourquoi l'action s'est interrompue et quelles contraintes restent contraignantes. |
| Preuves et incertitudes | Références des sources, fraîcheur, faits manquants ou contradictoires, confiance, limites et aides à l'interprétation. | L'examinateur peut contester la recommandation et reconnaître un biais d'automatisation. |
| Temps et récupération | Heure demandée, expiration, niveau de service, voie d'escalade, réversibilité, voie de compensation et procédure d'état sûr. | L'examinateur connaît la fenêtre de décision et le coût du retard ou de l'erreur. |
Définir les niveaux de service, l'expiration, la délégation et la réaffectation
Un niveau de service est un objectif opérationnel. L'expiration est une limite d'autorisation. Déterminez à la fois les conséquences, la réversibilité, la volatilité des preuves et le temps disponible pour prévenir les dommages. Aucune durée universelle ne convient à chaque action.
Un arrêt d'urgence doit rester immédiatement disponible pour un opérateur agréé et ne doit pas attendre derrière une file d'attente d'approbation. Pour les demandes ordinaires, les exemples de bandes ci-dessous sont des points de départ pour un atelier politique. Remplacez-les par des valeurs spécifiques au système et testez-les dans des conditions réelles de dotation en personnel.
- Délégation : accorde à une personne nommée une classe d'action, une limite de valeur, un environnement, une période d'effet et un itinéraire d'escalade restreints. Préserver qui a délégué l’autorité.
- Réaffectation : nécessite un remplacement éligible, enregistre le cessionnaire précédent et la raison, et conserve les preuves originales et l'expiration visibles.
- Expiration : invalide la capacité d'approbation. Ne transformez jamais le délai d’attente en approbation implicite.
- Obsolescence : expire plus tôt lorsque les intrants matériels, la politique, l'identité, la destination, la quantité ou les paramètres demandés changent.
- Contrôle indisponible : maintenez ou bloquez conformément à la politique de fermeture en cas d'échec de l'action et contactez l'opérateur responsable.
| Classe | Exemple de cible de réponse | Comportement à l'expiration | Action de file d'attente |
|---|---|---|---|
| Confinement d'urgence | Action immédiate de l'opérateur ; page le rôle d'incident responsable. | L'autorité d'arrêt est de courte durée et la récupération nécessite une approbation actuelle distincte. | Contournez la file d'attente ordinaire par le chemin d'incident régi et préservez les preuves de bris de verre. |
| Décision préalable à l'exécution consécutive | Minutes ou heures, en fonction de la fenêtre de maintien en toute sécurité. | Rejeter l'exécution à l'expiration. Réévaluez et émettez un nouveau Decision Request. | Transférer avant l'expiration à un vérificateur faisant autant ou plus autorité. |
| Exception matérielle réversible | Heures dans la journée d'exploitation. | Expire lorsque les preuves ou l'état de l'entreprise ne peuvent plus être traités comme étant actuels. | Réaffecter avec l'historique complet ; conserver le cessionnaire original et la raison. |
| Revue d'assurance non bloquante | Objectif de jours ouvrés défini. | Fermez ou faites remonter l'élément de révision sans modifier l'action déjà autorisée. | Suivre l'examen en retard comme un échec d'assurance. |
Concevez les dérogations, les appels et les arrêts d'urgence comme des chemins distincts.
Une dérogation modifie une décision ou un résultat sous une autorité explicite. Un appel demande à un autre rôle autorisé de réviser une décision. Un arrêt d'urgence interrompt le fonctionnement actif ou en attente et amène le système dans un état sûr défini. La combinaison des trois boutons d’administration en un seul obscurcit l’autorité, le timing et les preuves.
| Chemin | Autorité et calendrier | Preuves requises |
|---|---|---|
| Remplacer | Autorité nommée pour le groupe d'action, avec un motif et toute règle de deux personnes. Évaluez avant l’exécution de l’action modifiée. | Résultat initial, décision de remplacement, référence d'autorité, code de raison, justification, liaison d'action, heure et état résultant. |
| Appel | Un rôle indépendant de la décision initiale lorsque la politique l'exige. Définissez l’état intérimaire sûr et l’objectif de réponse. | Demande et décision originales, appelant, motifs, réviseur d'appel désigné, preuves examinées, résultat, réparation et notification. |
| Arrêt d'urgence | L'opérateur agréé peut agir immédiatement. La récupération fait suite à une approbation distincte après vérification du confinement. | Acteur d'arrêt, raison, heure, portée, propagation, travail annulé et en vol, action d'identification, résidu en aval, état sûr et approbation de redémarrage. |
Reconnaître les modes d'échec du flux de travail d'approbation
Un écran d'approbation peut exister lorsque le contrôle échoue. Testez le chemin complet depuis la création de la demande jusqu'à l'effet en aval, y compris les pannes, les tentatives, les pics de charge de travail et la récupération.
- Approbation automatique : les évaluateurs approuvent trop rapidement ou répètent des raisons identiques. Mesurer la latence, l'accord, les remplacements et la charge des réviseurs ; utiliser des échantillons indépendants.
- Auto-approbation : le demandeur, le sponsor de l'agent ou l'opérateur en conflit peut approuver. Résoudre les identités et les conflits au moment de la décision.
- Approbation périmée : les preuves, le montant, la destination, la politique ou les paramètres changent après examen. Liez et revalidez la demande avant l’exécution.
- Attente orpheline : aucun réviseur éligible n'est propriétaire de l'élément ou la file d'attente le perd. Surveillez l’affectation, l’ancienneté, l’escalade et l’expiration pour contrôler l’état de santé.
- Relecture ou exécution en double : une approbation libère plusieurs appels ou une nouvelle tentative répète l'effet secondaire. Utilisez des décisions à usage unique et des clés d’idempotence.
- Effet partiel en aval : une action en plusieurs étapes échoue après un engagement externe. Enregistrez chaque effet et exécutez le chemin de compensation ou d’incident.
- Preuve écrite trop tard : l'effet secondaire se produit avant que la politique ou l'enregistrement d'approbation ne soit durable. Échec fermé lorsque l’enregistrement requis ne peut pas être écrit.
- Faux arrêt : l'interface indique arrêté pendant que les travailleurs, les files d'attente, les informations d'identification ou les tentatives continuent. Testez la propagation et réconciliez chaque opération en vol.
Exemple pratique : une disposition de crédit synthétique
Le Schéma du journal d’audit de l’agent IA public comprend un enregistrement synthétique complet pour un agent d'évaluation du crédit proposant une mise à jour de disposition EUR 24,000. L’exemple montre comment l’approbation est liée à l’effet réel en aval. Les figures et les identités sont synthétiques.
| Étape | Enregistrement observé | Signification du contrôle |
|---|---|---|
| Demande | Un agent d'évaluation du crédit propose credit.application.set_disposition pour une application tokenisée dans un crédit restreint de l'UE. Frontière. | Les versions d'action, d'objectif, de ressource, de montant, d'environnement, de version d'agent, de modèle, d'invite et d'orchestrateur demandées sont liées à une seule exécution. |
| Politique | Version de la politique 4.2.1 matches manual-review-above-20000 et renvoie require_approval avec la raison montant_requires_senior_underwriter. | Le 24,000 amount EUR dépasse la limite du fabricant. L’exécution reste conservée pour le rôle senior_underwriter requis. |
| Contexte du réviseur | Le Decision Request contient le contexte exact de l'action, le résultat de la politique, la portée des données restreintes, les versions des composants et un résumé des preuves présentées. | Le vérificateur peut vérifier la demande et détecter une substitution ultérieure du paquet de preuves. |
| Expiration | La demande est créée à 09:14:29 UTC et expire à 10:14:29 UTC. | L'autorité d'approbation dure une heure. L’exécution après ce point nécessite une demande nouvellement évaluée. |
| Décision | Un souscripteur principal authentifié par la main-d'œuvre approuve à 09 :14 :31 UTC avec un motif vérifié_application_evidence et une référence de justification. | L'enregistrement lie l'examinateur, le rôle requis, la décision, le motif, le résumé des preuves et le temps. |
| Exécution | L'appel de l'outil gouverné démarre après l'approbation, utilise une clé d'idempotence et réussit avec les résumés d'arguments et de résultats. | L'approbation précède l'effet secondaire de l'outil et ne peut libérer que l'action liée. |
| Effet en aval | L'enregistrement synthétique des services bancaires de base indique credit_disposition_updated avec des résumés avant et après l'état. | Le chemin d'approbation comporte un enregistrement explicite des résultats commerciaux après la décision politique. |
| Preuve | La lignée ordonnée rejoint les événements de demande, de politique, d'approbation, d'outil et d'achèvement. L’enregistrement relie les artefacts de stratégie et d’outil et contient un résultat de vérification d’intégrité valide. | Un auditeur peut tester l'ordre, l'identité, la liaison des actions, le résultat et l'intégrité des enregistrements. L’exhaustivité des sources reste un test d’assurance distinct. |
Utilisez un schéma de preuves minimum
Utilisez des identifiants stables et des champs lisibles par machine afin qu'un réviseur ou un auditeur puisse joindre la décision à l'exécution sans s'appuyer sur des horodatages ou des captures d'écran. KLA publie un Schéma JSON, exemples et vérificateur indépendant du fournisseur pour cet enregistrement.
| Groupe de preuves | Champs minimum | Question répondue |
|---|---|---|
| Enveloppe et portée | version_schéma, identifiant_événement, arrivé_à, enregistré_at, séquence, corrélation_id, exécution_id, organisation, environnement, classe de conservation | Quels enregistrements et limites opérationnelles sont en cours de révision ? |
| Acteurs et versions | demandeur, agent, responsable_propriétaire, utilisateur délégué ou identité de service, agent Release, modèle, invite, orchestrateur | Qui ou quoi a agi, sous la responsabilité de qui, en utilisant quelles versions ? |
| Action demandée | action, objectif, ressource, limite des données, montant le cas échéant, destination, request_at, résumé des arguments | Quel effet secondaire exact a été proposé ? |
| Politique | décision_id, politique_id et version, stratégie et résumés d'entrées, autoriser ou avertir ou exiger_approbation ou bloquer, règles correspondantes, codes de raison, évalué_at | Pourquoi le contrôle a-t-il produit ce résultat ? |
| Approbation | request_id, request_at, expires_at, require_role, résumé des preuves présentées, réviseur, décision, motif, référence de justification, decide_at, réaffectation, dérogation ou appel en cas d'utilisation | Un humain éligible a-t-il pris une décision sur les preuves actuelles avant l'exécution ? |
| Exécution et effet | outil et version, clé d'idempotence, heure de début et de fin, résumé des résultats, références d'effet en aval, résumés avant et après, résultat commercial, référence d'annulation ou d'incident | Qu'est-ce qui a été exécuté et qu'est-ce qui a changé en dehors du plan de contrôle ? |
| Lignée et intégrité | ID d'événement ordonnés, manifestes de preuves et résumés d'artefacts, traitement de la confidentialité, hachage de l'enregistrement, signature, statut de vérification et codes d'échec | L'enregistrement peut-il être relu, traité correctement et vérifié pour les changements ? |
Comment KLA implémente le chemin de contrôle d'approbation
Le KLA Control Plane régit les actions des agents instrumentés. KLA Policy Engine évalue un appel d'outil proposé par rapport aux règles publiées et renvoie allow, warn, require_approval ou block. Un résultat require_approval contient l'appel proposé et crée un Decision Request pour Decision Desk. Un bloc empêche l'appel gouverné d'atteindre l'outil.
Pour les Decision Request du plan de contrôle, Decision Desk vérifie l'autorisation de décision, le rôle de réviseur requis, l'état en attente, l'identité du demandeur et du fabricant et l'heure d'échéance. Il empêche les demandeurs et les créateurs enregistrés de décider de leur propre demande et rejette, approuve ou rejette les actions après le délai imparti. Un vérificateur éligible peut faire remonter une demande en retard. Il enregistre l'acteur décisionnel, l'instantané du rôle, le résultat, la raison et l'heure. Ces contrôles de séparation et d'expiration reposent sur la demande portant les identités actuelles du fabricant et une heure d'échéance. Assurez-vous que chaque chemin de production les fournit et testez le chemin de contrôle complet.
Lineage Explorer et Audit Trail exposent les enregistrements de stratégie, de décision humaine et d'exécution. Evidence Room peut regrouper les enregistrements sélectionnés dans un Sealed Evidence Bundle avec des signatures, des hachages d'artefacts et une racine Merkle qui prend en charge les contrôles d'intégrité hors ligne. L'organisation possède toujours la classification des actions, la compétence des réviseurs, la dotation en personnel, l'analyse juridique, l'instrumentation complète, l'exhaustivité des sources, l'intervention sur chaque travailleur et système en aval, ainsi que la conception de l'état sûr.
Références techniques
Lire les contrats de composants et le dossier d'exécution joint derrière le chemin d'approbation décrit ici.
Sources primaires et fraîcheur
Examen des sources terminé 28 juillet 2026. [L'article 14 de la loi européenne sur l'IA] (https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-14) exige une surveillance humaine efficace des systèmes d'IA et de la surveillance des noms à haut risque, une sensibilisation aux biais d'automatisation, une interprétation, une négligence, un remplacement, une inversion, une intervention et des capacités d'interruption sûres. L'article 26(2) exige que les déployeurs de systèmes à haut risque confient la surveillance à des personnes possédant les compétences, la formation, l'autorité et le soutien nécessaires. Le considérant 73 explique le rôle d'une intervention éclairée et des contraintes opérationnelles intégrées. Sources : source source source
Règlement (UE) 2026/1744 a modifié les dates d'application des règles à haut risque du chapitre III en 2 décembre 2027 pour les systèmes de l'article 6(2) et de l'annexe III et 2 août 2028 pour les systèmes de l'article 6(1) et de l'annexe I. Il n'a pas remplacé le texte de l'contrôle de l’article 14.
Le NIST AI RMF Core appelle à des rôles différenciés entre l'homme et l'IA, à des processus de surveillance documentés, à un examen indépendant et à des mécanismes d'appel, de dérogation, de mise hors service, de réponse aux incidents et de récupération. [Annexe C du NIST] (https://airc.nist.gov/airmf-resources/airmf/appendices/app-c-ai-risk-management-and-human-ai-interaction/) note que la nécessité d'une surveillance humaine dépend du contexte. Le Principe de l'IA de l'OCDE sur les valeurs centrées sur l'humain appelle à l'intervention humaine et à des garanties de surveillance adaptées au contexte et à l'état de l'art. Sources : source source source
Le tableau à quatre résultats, le cadre à sept entrées, les exemples de niveau de service et le schéma de preuves de ce guide sont des modèles de mise en œuvre. Ils ne comportent aucun seuil juridique universel. Reconfirmez la loi applicable, les directives réglementaires, les règles du secteur, les faits du système et le texte source actuel avant de vous y fier.
Foire aux questions
Quelles actions d'un agent IA nécessitent l'approbation humaine ?
Exiger l'approbation lorsqu'une action est importante, difficile à annuler, affectant les droits, sensible, nouvelle, proche d'une limite d'autorité, peu fiable ou capable de créer un effet significatif en aval. Bloquez les actions interdites, non autorisées, obsolètes, mal formées ou invérifiables.
Quelle est la différence entre un humain dans la boucle, un humain dans la boucle et un humain aux commandes ?
L'humain dans la boucle décide d'une action spécifique avant l'exécution. L'humain en boucle surveille l'activité limitée et peut intervenir dans une fenêtre testée. L'humain aux commandes possède le mandat, les limites, les politiques, l'autorité d'arrêt, le redémarrage et la responsabilité du système.
Comment la séparation créateur-vérificateur devrait-elle fonctionner pour un agent IA ?
Identifiez l'agent, le propriétaire responsable et le donneur d'ordre demandeur en tant que côté fabricant. Acheminez la demande liée exacte vers un vérificateur qualifié distinct. Vérifiez l'identité, le rôle actuel, l'autorité, la délégation et les conflits lorsque le vérificateur le décide, puis revalidez la demande avant l'exécution.
De quel contexte un évaluateur d'agent IA a-t-il besoin ?
Afficher l'action et la conséquence exactes, l'identité du demandeur et de l'agent, les limites d'autorité, le résultat et les raisons de la politique, les preuves et la fraîcheur de la source, l'incertitude et les limites, les alternatives, l'expiration, l'itinéraire d'escalade et le chemin de récupération.
Quand une approbation doit-elle expirer ?
Expirer l'approbation à la fin de la fenêtre de conservation sécurisée ou lorsque des preuves matérielles, la politique, l'identité, l'autorité, la destination, le montant, les paramètres ou l'état de l'entreprise changent. Une requête expirée ne doit pas être exécutée ; évaluez à nouveau l'action et émettez une nouvelle demande.
Un humain peut-il annuler une décision de blocage ?
Un réviseur ne doit pas convertir une action interdite en une approbation dans la même demande. Une exception d’urgence légitime nécessite une voie politique distincte, étroite et limitée dans le temps, avec une autorité nommée, une raison, des preuves, des limites de confinement et un examen rétrospectif.
Comment les appels et les arrêts d'urgence devraient-ils fonctionner ?
Acheminez un appel vers le rôle indépendant défini par la politique et maintenez le système dans un état provisoire sûr. Laissez un opérateur autorisé appeler immédiatement un arrêt d'urgence, enregistrer la propagation et les résidus et exiger une approbation actuelle distincte avant le redémarrage.
Qu'est-ce qui prouve que l'approbation a eu lieu avant l'exécution ?
Utilisez un enregistrement corrélé avec les événements de demande, de stratégie, d'approbation, d'outil et d'achèvement ordonnés. Liez l'action et les preuves avec des résumés, l'autorité de révision du dossier et l'expiration, utilisez une clé d'idempotence, joignez le reçu en aval et vérifiez l'intégrité du dossier.
Points clés à retenir
Un contrôle d'approbation utile donne à chaque action consécutive un résultat clair, maintient la demande exacte en attente lorsqu'un jugement est requis, donne au vérificateur suffisamment de contexte et d'autorité, expire les décisions obsolètes et attache le véritable effet en aval au dossier de preuve. Téléchargez le playbook du workflow d'approbation des agents IA pour définir les règles d'une action, puis testez le chemin complet dans des conditions normales, expirées, réaffectées, dupliquées, de panne et d'arrêt d'urgence.