Les points essentiels

  • Gouverner commence par inventorier les agents, leurs propriétaires, données, outils et environnements.[1][2]
  • Chaque agent doit avoir une identité distincte, des droits minimaux et un responsable métier.[3][4]
  • Le niveau de contrôle dépend des conséquences de l’action, pas de la sophistication du modèle.[1][2]
  • Journaux, évaluations et procédure d’arrêt doivent exister avant l’ouverture des actions sensibles.[1][2]
  • Les obligations applicables doivent être qualifiées au cas par cas avec les fonctions juridique, sécurité et protection des données.[1][2]

Gouverner l’action, pas seulement le modèle

Un agent peut lire, décider, appeler un outil et modifier un système. Sa gouvernance doit donc couvrir le chemin complet, depuis la demande jusqu’à l’effet produit, plutôt qu’un simple choix de fournisseur de modèle.[1][2]

Le premier livrable utile est un registre vivant : finalité, propriétaire, utilisateurs, données, outils, droits, niveau d’autonomie, tests, incidents et date de revue.[1][2]

Une gouvernance proportionnée aux conséquences

Classer les usages par risque permet d’éviter deux extrêmes : bloquer une aide interne à faible conséquence ou laisser agir un système sur un processus sensible sans preuve suffisante.[1][2]

La classification doit considérer les personnes affectées, la réversibilité, le volume, les données, l’engagement financier ou contractuel et les possibilités de recours.[1][2]

Les contrôles à relier à chaque agent

Un agent exploitable associe un objectif borné, un contexte, des outils autorisés et des conditions d’arrêt. Le modèle ne constitue qu’une partie du système : identités, intégrations, validations et journaux déterminent ce qu’il peut réellement faire.[1][2]

Le comportement doit être évalué sur des dossiers représentatifs, y compris les entrées incomplètes et les indisponibilités. Une démonstration réussie ne suffit pas à établir la robustesse du dispositif.[1][2]

  • Fiche d’identité avec finalité, version, propriétaire et contacts.[1][2]
  • Compte technique propre, permissions minimales et secrets renouvelables.[1][2]
  • Sources autorisées, responsables et règles de conservation.[1][2]
  • Limites de temps, coût, nombre d’étapes et volume d’actions.[1][2]
  • Journal des entrées utiles, décisions, outils, validations et sorties.[1][2]
  • Arrêt, révocation des accès, reprise manuelle et notification d’incident.[1][2]

Répartir les responsabilités

Métier

Il définit le résultat acceptable, les exceptions, les personnes affectées et le niveau de service attendu.[1][2]

Technique et exploitation

Ils conçoivent l’intégration, la surveillance, la reprise, les changements de version et le support.[1][2]

Sécurité et données

Ils examinent identités, flux, fournisseurs, conservation, accès et réponse aux incidents.[1][2]

Juridique, conformité et direction

Ils qualifient les exigences applicables, les responsabilités, le recours et l’acceptation des risques résiduels.[1][2]

Shadow AI, droits dormants et responsabilité diffuse

L’autonomie déplace une partie du travail de l’exécution vers la conception et la surveillance. Le risque ne se résume pas à une réponse fausse : il inclut aussi la mauvaise action, sa répétition, l’accès à une donnée indue et l’impossibilité de reconstituer une décision.[1][2]

  • Agents créés sans inscription au registre.[1][2]
  • Jetons personnels utilisés dans un processus collectif.[1][2]
  • Outils ajoutés après validation sans nouvelle revue.[1][2]
  • Mémoire ou journaux conservant plus de données que nécessaire.[1][2]
  • Alertes nombreuses sans personne chargée de les traiter.[1][2]
  • Fournisseur, intégrateur et client supposant chacun que l’autre contrôle le risque.[1][2]

Adapter le contrôle au niveau d’action

Adapter le contrôle au niveau d’action
NiveauExempleContrôle minimum
ObservationAnalyser sans produire d’effetDonnées bornées et évaluation
PropositionPréparer une réponse ou une décisionRevue humaine informée
Action réversibleCréer un brouillon ou une tâcheDroits limités, journal et annulation
Action externeEnvoyer ou modifier un dossierValidation selon seuil et surveillance
Action sensibleEngagement, paiement ou décision sur une personneAnalyse renforcée ; autonomie parfois inadaptée

Ce que recouvre la gouvernance d’un agent IA

Un agent agit : sa gouvernance dépasse celle d’un chatbot

Une réponse conversationnelle peut déjà avoir des conséquences, mais un agent ajoute le choix et l’appel d’outils. Il faut donc gouverner identités, permissions, paramètres, répétitions, effets, journaux et reprise en plus du modèle et du contenu.

Les produits grand public sous contrainte donnent un signal, pas une recette

Une fonctionnalité déployée dans un domaine sensible montre l’importance de la limitation, de l’information, de la validation et du recours. Elle ne prouve pas que son architecture, son cadre ou ses contrôles peuvent être copiés dans une entreprise.[1][2]

Choisir un niveau d’autonomie proportionné

Humain dans la boucle

Une personne approuve avant l’action. Elle doit voir les sources, les paramètres et les effets, disposer d’un temps suffisant et pouvoir refuser. Cette modalité convient aux engagements et changements difficiles à annuler.[1][2]

Humain sur la boucle

L’agent exécute dans un cadre borné et une personne intervient sur alerte ou seuil. Ce modèle exige des anomalies détectables, une surveillance actionnable et une annulation réellement testée.[1][2]

Autonomie bornée

Elle peut convenir aux actions de faible conséquence, réversibles et bien observées. Droits, montants, horaires, volume, nombre d’étapes et durée limitent l’exposition.[3][4]

Cartographier chaque usage par niveau de risque

Classez la donnée, les personnes affectées, la réversibilité, le volume, l’effet financier ou contractuel et le recours. Un même agent peut combiner plusieurs niveaux selon l’outil ou l’action.[1][2]

Poser les garde-fous techniques avant le déploiement

Moindre privilège et accès juste-à-temps

Attribuez un compte technique distinct, uniquement les opérations nécessaires et, lorsque possible, une durée courte. Évitez de réutiliser le jeton personnel ou administrateur d’un salarié.[1][2]

Sandbox et séparation des environnements

Testez avec des données représentatives mais protégées, des destinations non productives et des actions simulées. La promotion vers la production suit une revue et des identités différentes.

Limites d’itérations, de coût et d’action

Plafonnez le nombre d’étapes, les appels, les montants, la fréquence et les destinations. Une limite doit déclencher une sortie claire ou un transfert, pas une nouvelle boucle.[1][2]

Journalisation, observabilité et bouton d’arrêt

Les équipes doivent reconstituer demande, version, sources, outils, validations et effets sans conserver plus de données que nécessaire. L’arrêt révoque les accès et oriente les tâches en cours vers une reprise connue.[1][2]

Superviser humainement les actions sensibles

Une validation humaine ne protège que si la personne est informée et peut agir. L’interface présente le dossier, les sources, la proposition, l’incertitude, les systèmes affectés et la possibilité d’annulation. Le volume doit rester compatible avec une revue réelle.[1][2]

Définir les actions toujours soumises à validation

Paiement, engagement contractuel, communication publique sensible, suppression, modification de droits ou décision touchant une personne sont des candidats à une validation forte ou à l’absence d’autonomie selon le contexte.[3][4]

Éviter la fatigue d’approbation

Regroupez les alertes, automatisez les contrôles déterministes et mesurez la vitesse de validation. Une série de clics instantanés indique que le mécanisme n’apporte plus le contrôle attendu.[1][2]

Attribuer rôles, responsabilités et identité machine

Une gouvernance collaborative avec un responsable clair

Métier, DSI, sécurité, protection des données, juridique et direction contribuent selon l’usage. Cette collaboration ne doit pas diluer la responsabilité : le propriétaire métier et l’exploitant technique sont nommés.[1][2]

Traiter chaque agent comme une identité à part entière

Compte, propriétaire, droits, secrets, environnements, date de revue et procédure de révocation sont enregistrés. Les actions ne doivent pas être indistinguables de celles d’un utilisateur humain.[3][4]

Revoir les droits à chaque extension

Ajouter un outil, une source, un pays ou une nouvelle action modifie le périmètre de risque. La revue ne se limite pas à la première mise en production.[1][2]

Reprendre la main sur le shadow AI

Un canal de déclaration sans sanction immédiate aide à découvrir les agents, automatisations, comptes et connecteurs créés hors processus. L’objectif initial est de protéger les personnes et les données puis d’offrir une voie approuvée, pas de pousser les usages dans la clandestinité.[1][2]

  • Inventorier comptes et intégrations autorisés.[1][2]
  • Analyser les besoins couverts par les outils non déclarés.[1][2]
  • Révoquer immédiatement les accès manifestement dangereux.[1][2]
  • Migrer les usages utiles vers des comptes administrés.[1][2]
  • Former sur les données et les actions interdites.[1][2]
  • Suivre les nouveaux connecteurs et dépenses.[1][2]

Articuler NIST AI RMF, ISO 42001 et règlement européen sur l’IA

Des cadres aux finalités différentes

Un cadre de gestion des risques, un système de management certifiable et une réglementation ne sont pas interchangeables. L’organisation peut utiliser leurs pratiques conjointement sans prétendre que l’un remplace les obligations de l’autre.[1][2]

Documenter RGPD et AI Act selon le cas réel

Finalité, rôle, données, catégorie du système, information, supervision et recours doivent être qualifiés avec les fonctions compétentes. Le nom du fournisseur ou une certification ne suffit pas à conclure.[1][2]

Choisir le cadre qui soutient les décisions

Commencez par les exigences applicables, puis utilisez les cadres pour organiser inventaire, risques, responsabilités, preuves et amélioration. Évitez une collection de contrôles sans propriétaire ni lien avec l’usage.

Auditer avant la production puis piloter en continu

Audit préalable

Vérifiez finalité, données, identités, outils, tests, actions interdites, supervision, arrêt, incident, fournisseurs et coût. Exécutez des cas hostiles, incomplets et hors périmètre.

Revue après changement

Une nouvelle version, source, permission ou règle peut créer une régression. Rejouez les tests concernés et comparez le résultat avant ouverture complète.[1][2]

Preuves pour audit interne ou contrôle

Conservez registre, décisions, versions, évaluations, revues de droits, incidents, corrections et preuves de supervision avec des durées proportionnées. La preuve doit être exploitable, pas seulement accumulée.

Mesurer la maturité

Suivez couverture du registre, propriétaires nommés, droits revus, tests de panne, délai d’arrêt, incidents et décisions clôturées. Une maturité élevée se voit dans la capacité à corriger et arrêter.[1][2]

Installer une gouvernance en six étapes

Le premier déploiement doit rester réversible. Il commence en observation ou en proposition, passe à une exécution limitée lorsque les critères sont atteints, puis s’étend uniquement sur la base de résultats documentés.[1][2]

  • Recenser agents officiels et usages non déclarés sans sanctionner le signalement.[1][2]
  • Nommer propriétaire métier et exploitant technique.[1][2]
  • Cartographier données, outils, fournisseurs et personnes affectées.[1][2]
  • Classer le risque et choisir le niveau d’autonomie.[1][2]
  • Vérifier tests, journaux, arrêt et reprise avant ouverture.[1][2]
  • Réexaminer après incident, extension ou changement important.[1][2]

Mesurer la maturité de gouvernance

Les gains annoncés dans un prototype sont des hypothèses. La mesure utile part d’une référence avant projet, compte le temps de correction et les coûts récurrents, puis distingue activité produite et résultat métier.[1][2]

  • Part des agents inscrits et dotés d’un propriétaire.[1][2]
  • Part des accès individuels et revus.[1][2]
  • Couverture des tests et des scénarios de panne.[1][2]
  • Délai de détection, d’arrêt et de reprise.[1][2]
  • Incidents, quasi-incidents et actions hors périmètre.[1][2]
  • Décisions de revue documentées et suivies.[1][2]

Questions fréquentes

Par où commencer la gouvernance des agents ?

Par l’inventaire des usages, outils, données, droits et responsables. On ne peut pas contrôler ce qui n’est pas visible.[3][4]

Qui est responsable d’un agent ?

Plusieurs fonctions contribuent, mais un propriétaire métier et un exploitant technique doivent être explicitement nommés.[1][2]

Quelles actions garder sous validation humaine ?

Celles dont l’erreur est difficilement réversible ou affecte fortement une personne, un engagement, un paiement, un droit ou la réputation.[3][4]

Comment détecter le shadow AI ?

Offrez un canal de déclaration simple, examinez les intégrations et accès autorisés, et distinguez découverte des usages et sanction.[1][2]

Quels journaux conserver ?

Ceux nécessaires pour reconstituer entrées, version, outils, validations, sorties et erreurs, avec minimisation, protection et durée justifiée.[1][2]

Quel cadre réglementaire appliquer ?

Cela dépend de l’usage, du rôle de l’organisation, des données et des personnes affectées. Faites qualifier le dispositif plutôt que supposer qu’un label fournisseur suffit.[1][2]

Sources

  1. AI Risk Management FrameworkNational Institute of Standards and Technology. Publié le . Consulté le . 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667
  2. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence ProfileNational Institute of Standards and Technology. Publié le . Consulté le . 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667
  3. AI Act regulatory frameworkCommission européenne. Consulté le . 123456
  4. Navigating the AI ActCommission européenne. Consulté le . 123456

Poursuivre votre lecture