Boîte à outils de gouvernance de l’IA

Voici un ensemble d’artefacts prêts à adapter pour le travail de gouvernance que teste le Domaine 3 : un modèle opérationnel, une RACI, un formulaire d’admission de cas d’usage, un registre des risques, une matrice niveau-de-risque-vers-contrôles, une politique de classification des outils, des checklists de lancement et d’incident, et un jeu de due diligence fournisseur. C’est une préparation indépendante, pas un framework de conformité officiel d’AWS — adaptez chaque artefact à vos propres obligations réglementaires avant de vous y fier. L’examen bêta AIB-C01 ne vous demande pas de configurer tout cela ; il vous demande de reconnaître quelle structure, quel contrôle ou quelle responsabilité convient à un scénario. Tout ce qui suit reste à ce niveau de décision.

La boîte à outils en un coup d’œil

   Use case ──▶ INTAKE FORM ──▶ RISK CLASSIFICATION ──▶ CONTROL SET
                    │                    │                   │
                    │                    ▼                   ▼
                    │              RISK REGISTER        HUMAN OVERSIGHT
                    │              (owned rows)         + MONITORING
                    ▼                                        │
              OPERATING MODEL (who decides) ◀── RACI ────────┤
                    │                                        ▼
                    ▼                                 LAUNCH READINESS
              TOOL CLASSIFICATION                          │
              (approved/blocked/eval)                      ▼
                                                    INCIDENT RESPONSE

Chaque artefact répond à une question de gouvernance différente. Lisez le schéma de haut en bas : l’admission capture la demande, la classification fixe le niveau, le niveau pilote le jeu de contrôles, le modèle opérationnel et la RACI disent qui décide, et les procédures de lancement et d’incident bouclent la boucle.

1. Modèle opérationnel de gouvernance de l’IA

La gouvernance échoue de deux façons opposées : un comité unique qui devient un goulot d’étranglement, ou aucune instance du tout, de sorte que les décisions se prennent par accident. Le modèle opérationnel nomme un petit nombre d’instances, donne à chacune des droits de décision clairs, et fixe une cadence. Il correspond directement à la tâche 3.2.1 (représentation transversale et responsabilité claire).

La règle de conception est l’autorité déléguée par niveau : les cas d’usage à faible risque passent au niveau du groupe de travail pour que la gouvernance n’étrangle pas le volume, tandis que les cas d’usage à haut risque remontent au conseil. Une instance qui ne peut pas dire non n’est pas une instance de gouvernance ; la colonne « ne peut pas décider » de chaque ligne est délibérée.

2. RACI sur le cycle de vie de l’IA

Une RACI empêche les deux défaillances classiques de responsabilité : chacun suppose que quelqu’un d’autre détient un contrôle, ou une seule personne est responsable de tout et donc de rien. Responsible fait le travail, Accountable détient le résultat (exactement un par ligne), Consulted donne un avis avant, Informed est informé après.

Le signal d’examen : quand un énoncé dit « personne n’était clairement responsable de X après le lancement », le correctif est un A nommé dans la ligne monitoring ou incident — pas un nouvel outil. Notez que l’approbation des données relève du propriétaire des données, pas du propriétaire métier qui veut les utiliser ; cette séparation est ce qui empêche une équipe de valider ses propres données à la volée.

3. Formulaire d’admission de cas d’usage

L’admission est l’endroit le moins cher pour dire non. Un formulaire structuré oblige une proposition à énoncer son résultat, ses données et son risque avant que quiconque dépense de l’argent, et il alimente la priorisation (tâche 2.1.3) et la classification (tâche 3.2.4).

• Sponsor et propriétaire métier — un individu nommé, pas une équipe.
• Problème et référence actuelle — ce que le processus coûte ou prend aujourd’hui, mesuré (lien vers les méthodes de référence de la KPI Library).
• Résultat proposé et cible — la métrique précise qui devrait bouger, et de combien.
• Pourquoi l’IA, et non des règles — le test déterministe-vs-IA (tâche 1.2.1) ; si la logique est fixe, c’est un moteur de règles.
• Données requises — sources, sensibilité, propriété, possibilité de sortie de l’organisation, état de qualité.
• Conséquence d’une sortie erronée — réversible ou non, qui est concerné, réglementé ou non.
• Point de supervision humaine (human-in-the-loop) — où une personne relit avant qu’une action soit prise.
• Orientation build / buy / partner — avec un coût et un calendrier approximatifs.
• Critères de succès et d’arrêt — les chiffres qui vous feraient passer à l’échelle, mettre en pause ou arrêter.

Une proposition qui ne peut pas remplir « conséquence d’une sortie erronée » et « critères d’arrêt » n’est pas prête pour une décision budgétaire. C’est le portillon d’admission qui fait son travail.

4. Modèle de registre des risques avec lignes travaillées

Le registre est le document vivant que l’examen attend d’exister avant la production, pas après un incident. Chaque ligne nomme un propriétaire, une probabilité et un impact, le contrôle actuel et une notation résiduelle. Ces lignes travaillées couvrent les catégories de risque que liste le guide (précision, confidentialité, sécurité, PI, réglementaire, réputationnel, main-d’œuvre).

Le point pédagogique est que probabilité × impact pilote le niveau, le niveau pilote le contrôle, et la notation résiduelle est ce que le conseil de gouvernance valide réellement — pas le risque brut. Une ligne sans propriétaire nommé n’est pas un risque géré.

5. Matrice niveau-de-risque vers jeu-de-contrôles

C’est l’artefact qui transforme « appliquer un framework de classification des risques » (tâche 3.2.4) en quelque chose qu’un lecteur peut utiliser demain. Classez le cas d’usage par conséquence et par portée, puis lisez le jeu de contrôles le long de la ligne. Il reflète la logique par niveaux de l’EU AI Act et du NIST AI RMF sans citer de numéros d’article, ce qui est exactement le niveau que teste l’examen.

La colonne de supervision porte la distinction centrale de l’examen : human-in-the-loop signifie qu’une personne approuve avant l’action, human-on-the-loop signifie qu’une personne surveille et peut intervenir, et human-in-command signifie qu’une personne peut passer outre et arrêter. Plus la conséquence est grande, plus vous montez cette échelle.

6. Politique de classification des outils IA — la réponse au shadow AI

La tâche 1.2.4 est explicite : une classification transparente des outils en approved / blocked / under evaluation (approuvé / bloqué / en évaluation) est la réponse concrète au shadow AI. Tout interdire fait passer l’usage dans la clandestinité ; tout approuver abandonne le contrôle. La politique nomme les états et les critères qui font passer un outil de l’un à l’autre.

        request ──▶ UNDER EVALUATION ──▶ APPROVED (scoped)
                          │                   │
                     hard criterion      term change /
                        fails              incident
                          ▼                   ▼
                        BLOCKED  ◀────────────┘
                          │
                     re-request ──▶ UNDER EVALUATION

Le signal d’examen pour le shadow AI est toujours visibilité plus voie sanctionnée, jamais une interdiction générale.

7. Checklist de préparation au lancement

Avant qu’un cas d’usage ne passe en production, le sponsor confirme chaque élément. Cela opérationnalise le « envision → launch » de l’AWS CAF et la transition vers un niveau de production de la tâche 4.4.5.

• Niveau de risque attribué et jeu de contrôles appliqué.
• Métrique de référence capturée avant la mise en service (vous ne pourrez pas revendiquer de valeur plus tard sans elle).
• Point de supervision humaine défini et doté pour le niveau choisi.
• Guardrails / content filters configurés et testés contre des entrées connues comme mauvaises.
• Monitoring et détection de dérive en place avec propriétaire nommé et seuils d’alerte.
• Kill switch et voie de rollback testés ; un message d’attente prêt.
• Runbook d’incident rédigé et le propriétaire de réponse (RACI A) briefé.
• Conditions des données, résidence et rétention confirmées ; indemnité fournisseur au dossier.
• Critères de succès et d’arrêt validés par le comité de pilotage.
• Communication à la main-d’œuvre envoyée ; le personnel concerné sait ce qui change.

8. Plan de réponse aux incidents pour les défaillances d’IA

Les incidents d’IA diffèrent des pannes informatiques classiques : le système reste « up » tout en produisant une sortie nuisible, biaisée ou erronée. Le plan nomme les phases et les propriétaires.

9. Jeu de questions de due diligence fournisseur

Le build-buy-partner (tâche 2.1.2) aboutit généralement à buy ou partner, ce qui fait de l’examen du fournisseur un contrôle de gouvernance, pas une formalité d’achat. Posez à chaque fournisseur :

Le discriminant d’une question de sélection de fournisseur est rarement le prix ; c’est généralement une réponse sur l’usage des données, l’indemnité ou la résidence qu’un fournisseur moins cher ne peut pas donner.

10. Comment les contrôles propres à AWS se projettent sur ces artefacts

L’examen ne vous demande pas de configurer un contrôle AWS, mais il attend que vous reconnaissiez quelle capacité AWS soutient quel artefact de gouvernance. Restez au niveau de la correspondance.

L’idée la plus testée de ce tableau : aucun service managé n’enlève la responsabilité du client quant à l’usage du système et à l’adéquation de sa sortie à l’objectif. Guardrails et Clarify sont des outils qui soutiennent vos contrôles ; ils ne remplacent pas le modèle opérationnel, le classement par niveaux et la supervision humaine que vous détenez.

Points clés

• La gouvernance est un ensemble d’instances avec des droits de décision et une cadence, pas un comité unique ; déléguez les niveaux faibles pour ne pas étrangler le volume.
• Chaque risque géré et chaque activité du cycle de vie a exactement un propriétaire responsable — le correctif à « personne ne le détenait » est un nom, pas un outil.
• Classez d’abord : le niveau pilote les approbations, le mode de supervision, la cadence de monitoring, la documentation et l’escalade.
• On répond au shadow AI par une politique transparente approved / blocked / under-evaluation avec une voie sanctionnée et un substitut à tout ce qui est bloqué.
• Capturez la référence avant le lancement et rédigez le runbook d’incident avant d’en avoir besoin.
• La due diligence fournisseur — usage des données, entraînement, rétention, résidence, indemnité, preuves, roadmap — est un contrôle de gouvernance, pas de la paperasse.
• AWS Guardrails, Clarify, Model Monitor et AI Service Cards soutiennent ces artefacts ; la responsabilité partagée maintient chez vous la responsabilité du cas d’usage et de l’adéquation.