Ce que la gouvernance de l’IA exige réellement

La gouvernance de l’IA échoue quand elle est rédigée comme une prose de politique et confiée à une équipe qui n’a aucun moyen de la mettre en œuvre. Elle fonctionne quand elle est spécifiée comme des exigences d’ingénierie que le système doit satisfaire avant sa mise en production.

Les acheteurs d’entreprise lisent le chapitre gouvernance deux fois. Ils ont vu ce qui se passe quand un modèle non gouverné atteint la production : une décision que personne ne peut expliquer, une exposition de données que personne n’a journalisée, un régulateur qui réclame des preuves qui n’existent pas. La gouvernance, c’est la façon de s’assurer que rien de tout cela ne devienne votre histoire.

Trois exigences, rédigées pour des ingénieurs

Surveillance

Le système doit émettre en continu des signaux de dérive, de coût, de latence et de comportement, avec des alertes avant que les utilisateurs ne remarquent un problème. « Nous surveillerons le modèle » n’est pas une exigence. « La latence P95, le coût en jetons par requête, le taux de refus et la dérive de la distribution des sorties sont suivis par flux de travail avec des seuils d’alerte » en est une.

Évaluation

Il doit exister une suite d’évaluation propre à la tâche qui s’exécute avant chaque mise en production et de façon planifiée en production. Un changement de modèle qui dégrade la qualité doit faire échouer la compilation, pas apparaître comme une plainte client trois semaines plus tard.

Journalisation d’audit

Chaque décision lourde de conséquences doit être inscrite dans un journal immuable, avec les entrées, les sorties, la version du modèle et la trace du raisonnement. C’est ce qui transforme le « faites-nous confiance » en « voici la preuve ».

La gouvernance est intégrée au système, pas documentée après coup.

Cartographiez les contrôles pendant que le système tourne

SOC 2 et ISO 27001 ne sont pas forcément une course de dernière minute avant un audit. Quand le système est conçu pour émettre des preuves, journaux d’accès, historiques de changements, résultats d’évaluation, la conformité devient une requête sur des données que vous collectez déjà. Cartographiez chaque contrôle vers le signal qui le satisfait, et l’audit devient un rapport plutôt qu’une fouille.

Traitez les régressions comme des incidents

L’échec de gouvernance le plus fréquent après le lancement est la régression silencieuse : quelqu’un change un modèle ou modifie un prompt, la qualité baisse, et personne ne s’en aperçoit avant que ça compte. La discipline qui l’empêche est simple à énoncer et difficile à contourner : chaque changement de modèle ou de prompt relance le harnais d’évaluation avant la mise en production, et un échec bloque celle-ci.