DECISION TOOLKIT · MODÈLE OPÉRATOIRE DE GOUVERNANCE
Faire varier l’intensité des contrôles avec la conséquence
Le risque n’est pas une propriété du nom d’un modèle. Il dépend de la conséquence du workflow, de l’autorité accordée au système et de la capacité de l’organisation à détecter et inverser une erreur.
rédaction, recherche, travail interne à faible impact
outil approuvé · responsabilité utilisateur · logs légersjugement professionnel ou contenu externe
jeu d’évaluation · relecteur · sortie traçableécrit dans des systèmes ou affecte des clients
moindre privilège · appels validés · confirmationdroits, sécurité, finance ou décisions réglementées
approbation formelle · assurance indépendante · exercice incidentCréer un fast track pour les usages faibles risques ; réserver la gouvernance la plus forte aux workflows capables de causer un dommage matériel.
La gouvernance IA échoue lorsqu’elle reste un document de politique. Les équipes doivent savoir quels systèmes existent, ce qu’ils peuvent faire, quels contrôles s’appliquent et quelles preuves sont requises avant la mise en production d’un usage plus risqué.
Un cadre opératoire doit rendre le chemin sûr évident. Il doit aussi rester proportionné : si chaque usage subit le même processus lourd, la gouvernance pousse le travail dans l’ombre.
Établir l’inventaire des systèmes
Commencez par les systèmes IA, pas seulement par les fournisseurs approuvés. Documentez propriétaire business, utilisateurs, workflow, catégories de données, modèles, intégrations, frontière de déploiement et impact décisionnel. Incluez l’IA intégrée aux logiciels existants et les outils non sanctionnés lorsqu’ils sont matériels.
Cet inventaire devient le plan de contrôle pour la classification, l’assurance et la réponse à incident. Il doit évoluer via les processus d’achat et d’engineering plutôt que dépendre d’une enquête annuelle.
Classer le risque au niveau du workflow
Le même modèle peut soutenir des activités à risque faible ou élevé. Classez l’usage réel selon sensibilité des données, exposition utilisateur, autonomie, réversibilité, conséquence d’une décision et capacité à détecter l’erreur.
Une structure pratique utilise quatre niveaux :
- Assist — productivité interne à faible impact, avec responsabilité humaine.
- Inform — les sorties influencent un jugement professionnel ou un contenu externe.
- Act — le système agit dans des systèmes connectés ou affecte des clients.
- Critical — droits, sécurité, finance ou décisions réglementées peuvent être touchés.
Le niveau détermine approbation, évaluation, monitoring et escalade.
Concevoir les contrôles sur tout le cycle
Les contrôles dépassent le comportement du modèle : limitation de finalité, accès légal aux données, identités et permissions, conditions fournisseurs, gestion des prompts et contextes, évaluations, supervision humaine, logs, incidents et gestion du changement.
| Domaine | Preuve minimale |
|---|---|
| Données | catégories, source, base d’accès, rétention et résidence |
| Sécurité | threat model, frontières de confiance, permissions et tests d’abus |
| Qualité | évaluations représentatives et seuils d’acceptation |
| Supervision | responsable de décision et voie d’intervention nommés |
| Opérations | monitoring, rollback, incidents et changements |
| Fournisseur | conditions, sous-traitants, changements de modèle et sortie |
Traiter l’IA générative comme une nouvelle surface d’attaque
Prompt injection, mauvais usage des tools, exfiltration, retrieval non sûr, agents sur-permissionnés et contexte empoisonné sont des risques système. Un simple appel à la prudence ne les résout pas.
Modélisez la chaîne complète : utilisateur, interface, orchestration, tools, retrieval, modèle, consommateurs de sorties et services externes. Réduisez les privilèges, validez les appels d’outils, isolez le contenu non fiable et créez des confirmations explicites pour les actions conséquentes.
Rendre les preuves réutilisables
L’assurance devient coûteuse lorsque chaque projet invente ses documents. Définissez des templates communs pour fiches système, data flows, rapports d’évaluation, acceptation du risque et production readiness. Les contrôles de plateforme doivent produire automatiquement des preuves lorsque c’est possible.
Les instances de gouvernance peuvent alors se concentrer sur les exceptions et décisions, pas sur la collecte de captures d’écran.
Attribuer les droits de décision
Chaque système requiert un responsable business pour sa finalité et ses résultats, un responsable technique pour l’implémentation et les opérations, et un responsable risque pour l’acceptation des contrôles. Juridique, sécurité, protection des données et achats apportent leur expertise ; ils ne doivent pas devenir propriétaires par défaut de chaque résultat IA.
Le test final est opérationnel : l’équipe sait-elle ce qu’elle peut faire, un dirigeant voit-il les risques acceptés et l’organisation peut-elle réagir vite lorsque le comportement ou le fournisseur change ? Si oui, la gouvernance est devenue une infrastructure d’exécution.