Un propriétaire responsable ne peut pas expliquer une action d'IA que l'architecture ne permet pas de retracer. Le problème devient sérieux lorsque l'IA passe de la génération de contenu à la modification de l'état de l'entreprise. Prenons un agent de service à la clientèle qui reçoit une demande de remboursement. Il consulte le compte, vérifie la politique, calcule un montant et appelle le système de paiement.
Le registre d'IA peut clairement identifier le propriétaire d'affaires. Cela nous indique qui est responsable du système.
Cela n'explique pas pourquoi cet agent précis était autorisé à émettre ce remboursement précis pour ce client précis. Pour répondre à cette question, l'organisation doit retracer autre chose :
À chaque étape, l'architecture doit préserver l'identité, l'autorité déléguée, les permissions, l'application des contrôles et les preuves.
Passer de la propriété à l'autorité
Les organisations savent déjà attribuer la propriété. Les applications ont des propriétaires. Les processus ont des responsables. Les données ont des intendants. Les risques relèvent de dirigeants responsables. Ces concepts demeurent importants.
Mais la propriété et l'autorité ne sont pas la même chose. Un propriétaire peut être responsable d'un système d'IA alors que le système lui-même fonctionne au moyen de plusieurs agents, services, API et plateformes d'entreprise. L'action peut se trouver à plusieurs étapes techniques de la personne qui en est ultimement responsable.
Cela crée un autre problème de gouvernance. L'organisation doit préserver la relation entre la personne qui a accordé l'autorité et l'action qui a finalement été exécutée.
Le modèle n'est plus l'unité de gouvernance la plus importante dès que le système peut agir.
L'autorité devient l'un des éléments que l'architecture doit gouverner.
Six décisions d'architecture
1. Préserver l'identité de chaque acteur
La première exigence est la traçabilité. Lorsqu'un employé demande à un agent d'exécuter une tâche, l'activité qui en résulte ne devrait pas simplement laisser croire que l'employé a lui-même effectué manuellement toutes les actions en aval. L'architecture doit préserver à la fois le mandant à l'origine de la demande et l'acteur qui exécute l'action.
Cette distinction devient plus importante lorsque des agents en appellent d'autres. Le parcours d'exécution pertinent peut comprendre :
- l'utilisateur à l'origine de la demande
- l'orchestrateur
- l'agent spécialisé
- l'identité de service
- l'outil
- l'application cible
Ces acteurs n'ont pas nécessairement besoin de comptes distincts semblables à ceux des personnes dans chaque plateforme. Ils doivent toutefois demeurer distinguables dans le dossier d'exécution.
Ces récits de responsabilité ne sont pas équivalents.
2. Autoriser les actions, pas seulement les systèmes
Les permissions d'entreprise traditionnelles sont souvent générales. Cet utilisateur peut-il accéder au CRM? Ce service peut-il se connecter à la plateforme financière? Cet agent peut-il utiliser l'API des ressources humaines?
Pour les systèmes agentiques, ce niveau d'autorisation est souvent trop large. Une même plateforme d'entreprise peut permettre à un agent de :
- consulter un dossier client
- modifier les coordonnées
- mettre à jour un dossier
- émettre un remboursement
- annuler un service
- exporter de l'information
- déclencher un autre flux
Ces actions n'ont pas les mêmes conséquences. La question d'architecture la plus utile est la suivante : quelle action cet agent peut-il exécuter, sous quelle autorité et dans quelles conditions?
Un agent peut être autorisé à consulter un compte client et à calculer une recommandation de remboursement. Il peut être autorisé à émettre des remboursements sous un seuil défini. Un montant plus élevé peut exiger une autre étape d'autorisation. L'exportation de renseignements sur les clients peut être entièrement interdite. Le modèle de permissions doit refléter les conséquences d'affaires, pas seulement la connectivité technique.
3. Encadrer l'autorité déléguée
Les systèmes agentiques délégueront de plus en plus de travail. Un agent coordonnateur peut demander à un autre agent de récupérer de l'information, d'interpréter un document ou d'exécuter une tâche spécialisée. La délégation elle-même n'est pas le problème. L'élévation implicite des privilèges l'est. Supposons que l'agent A puisse lire des renseignements sur les clients sans pouvoir modifier les dossiers. Il délègue du travail à l'agent B. Si l'agent B possède des permissions permanentes plus larges, le système ne devrait pas permettre automatiquement à l'agent A d'accomplir indirectement ce qui lui est interdit directement.
Si l'utilisateur a délégué un accès en lecture, que l'agent est techniquement capable d'écrire et que la politique permet l'écriture seulement après une approbation supplémentaire, le résultat doit tout de même être une autorité en lecture seule. L'architecture doit appliquer l'intersection, et non la permission la plus large disponible quelque part dans la chaîne.
4. Faire intervenir une autorisation au point de conséquence
Dans le numéro 03 de The Governed Stack, j'ai soutenu que la supervision humaine devrait être conçue comme une boucle de contrôle plutôt que comme une exigence d'approbation générale. Les systèmes agentiques ajoutent une autre question d'architecture : où, dans la chaîne d'autorité, ce contrôle doit-il s'activer? Demander à une personne d'approuver chaque étape de l'agent élimine une grande partie de la valeur de l'automatisation. Autoriser automatiquement chaque action crée le problème inverse.
La frontière utile est généralement la conséquence. Un agent peut, de façon autonome, récupérer de l'information, comparer des options, préparer une recommandation, valider les champs requis et remplir une ébauche. Mais l'action suivante peut modifier un dossier d'entreprise, engager des fonds, communiquer à l'externe ou créer une autre conséquence importante. À ce point, l'autorité requise peut changer.
L'approbation n'est pas présente parce que l'IA intervient. Elle est présente parce que l'autorité requise pour l'action suivante dépasse celle qui a été déléguée au système. Cette distinction produit des contrôles qui peuvent survivre aux changements de modèles, de fournisseurs et de plateformes agentiques.
5. Préserver les preuves de décision, pas seulement les journaux
La plupart des plateformes d'entreprise produisent déjà des journaux techniques. Cela ne signifie pas qu'elles peuvent expliquer une action médiée par l'IA. Un journal peut indiquer qu'une API a été appelée, qu'un jeton a été émis, qu'un modèle a répondu ou qu'un dossier a changé. C'est utile.
Mais la responsabilité exige davantage de contexte. Pour une action importante, l'organisation peut devoir reconstituer :
- qui a lancé la tâche
- quel agent l'a exécutée
- quelle autorité a été déléguée
- quel outil a été invoqué
- quelle décision de politique s'est appliquée
- quel contexte pertinent a été utilisé
- si une approbation supplémentaire a eu lieu
- quelle action a été prise
- quel résultat a suivi
L'objectif n'est pas une journalisation illimitée. C'est la reconstitution de la décision.
Ces dossiers doivent être reliés par un contexte de corrélation ou de traçage commun. Les opérations disposent ainsi d'un parcours d'exécution et la gouvernance, d'une chaîne de preuves.
L'observabilité nous indique ce qui s'est produit. Les preuves de gouvernance aident à expliquer pourquoi l'action était permise.
6. Traiter les changements d'autorité comme des événements de gouvernance
Les systèmes d'IA peuvent changer de façon importante sans changer de modèle. Donnez un autre outil à un agent. Permettez-lui d'écrire là où il pouvait seulement lire. Augmentez son seuil financier. Connectez une autre source de données. Retirez une approbation humaine. Permettez-lui d'invoquer un autre agent.
Aucun de ces changements ne paraît nécessairement spectaculaire dans un processus conventionnel de mise en production. Du point de vue de la responsabilité, ils peuvent transformer fondamentalement le système. Le processus de gouvernance devrait donc définir des déclencheurs de changement d'autorité.
- nouvel accès à une application ou à un outil
- permission de lecture devenant une permission d'écriture
- limites de transaction plus élevées
- accès à de nouvelles catégories de données
- retrait d'un point d'autorisation humaine
- ajout d'agents en aval
- fenêtres d'exécution autonome plus longues
- permission de communiquer à l'externe
- permission d'entreprendre des actions irréversibles
Ces changements devraient déclencher une réévaluation lorsqu'ils modifient de façon importante ce que le système est autorisé à faire. Le modèle peut demeurer inchangé. La limite d'autorité, elle, change.
Ce que cela signifie dans l'architecture
La chaîne d'autorité ne doit pas exister uniquement dans un diagramme de gouvernance. Elle doit survivre à l'exécution.
Initiateur
Une personne ou un système en amont demande un résultat.
Mandat délégué
La demande établit ce que l'agent est autorisé à faire dans ce contexte.
Permission effective
La plateforme évalue l'autorité déléguée, les droits de l'agent et la politique applicable.
Décision de politique
L'action est permise, refusée, restreinte ou soumise à une escalade.
Exécution de l'outil
L'action permise est exécutée dans le système d'entreprise.
Événement de preuve
L'identité, l'autorité, la décision de politique, l'action et le résultat sont consignés sous une trace commune.
Ces capacités peuvent déjà exister dans les systèmes d'identité, les passerelles d'API, les plateformes d'orchestration, les moteurs de politiques, les applications d'entreprise et les outils d'observabilité. L'exigence architecturale est plus importante que le choix du produit : la décision de gouvernance doit atteindre le parcours d'exécution.
Un exemple pratique : émettre un remboursement
Revenons à l'agent de remboursement.
L'agent peut examiner le dossier, calculer le montant et préparer la transaction. Mais sa permission effective ne lui permet pas de l'exécuter. Le flux est soumis à une escalade. Un superviseur autorise le remboursement de 180 $. L'outil de paiement reçoit l'autorisation renforcée et exécute l'action.
- Demande de l'employé
- Agent
- Remboursement proposé
- Seuil d'autorisation
- Approbation du superviseur
- API de paiement
- Transaction terminée
La fiche de la chaîne de responsabilité
Utilisez une ligne pour chaque action importante qu'un système d'IA peut exécuter.
| Champ | Question |
|---|---|
| Action | Que peut réellement faire le système? |
| Conséquence d'affaires | Qu'est-ce qui change si l'action réussit? |
| Initiateur | Qui ou quoi lance l'action? |
| Acteur exécutant | Quel agent, service ou outil l'exécute? |
| Source de l'autorité | Qui a accordé l'autorité? |
| Mandat délégué | Quelle autorité a été accordée pour cette tâche précise? |
| Permission effective | Que peut réellement faire l'agent après l'application de la politique et de ses droits? |
| Limite interdite | Que l'agent ne doit-il jamais faire? |
| Délégation | Un autre agent peut-il exécuter une partie de l'action? |
| Déclencheur d'approbation | Qu'est-ce qui exige une autorisation renforcée? |
| Point d'application | Où cette décision est-elle appliquée techniquement? |
| Preuves | Qu'est-ce qui prouve ce qui s'est produit et pourquoi? |
| Autorité d'arrêt | Qui peut suspendre ou révoquer la capacité? |
| Déclencheur de réévaluation | Quel changement exige une nouvelle revue de la décision? |
Cette fiche ne doit pas devenir un autre document de gouvernance volumineux. Pour de nombreux systèmes, la cartographie d'une action importante de bout en bout révélera davantage qu'une autre politique de dix pages.
La gouvernance entre dans le parcours d'exécution
La première génération de gouvernance de l'IA s'est beaucoup concentrée sur les documents. Politiques. Principes. Inventaires. Évaluations. Ils demeurent nécessaires.
Les systèmes capables d'agir créent une exigence supplémentaire. La gouvernance doit de plus en plus atteindre le point où l'action se produit. L'identité doit être reliée à l'autorité. L'autorité doit être reliée aux permissions. Les permissions doivent demeurer limitées pendant la délégation. Les actions importantes doivent recevoir le bon niveau d'autorisation. Et le parcours d'exécution doit produire des preuves.
Cela ne signifie pas que les équipes de gouvernance doivent devenir des ingénieurs d'exécution. Cela signifie que la gouvernance et l'architecture ont besoin d'objets communs sur lesquels raisonner.
Pour les systèmes agentiques, la chaîne d'autorité est l'un de ces objets. Dès qu'un logiciel peut agir au nom de l'organisation, savoir qui possède le système n'est que le début.
La responsabilité doit suivre l'action.
Si une action importante ne peut être retracée de l'autorité jusqu'aux preuves, la Revue de décision IA peut révéler cet écart avant la production.
Portée
Cet article fournit des orientations pratiques en architecture et en gouvernance. Les contrôles d'identité, d'autorisation, de preuve et de supervision appropriés dépendent de l'action, de ses conséquences et des obligations de l'organisation.
Vous souhaitez recevoir une note pratique sur la gouvernance chaque mois?