Gouvernance de l’IAPour les conseils d’administration, DSI et responsables des risques
Une gouvernance de l’IA qui répond au régulateur, pas au tableau de bord.
La gouvernance de l’IA est l’ensemble des politiques appliquées, des rôles de supervision et des registres d’audit qui permettent à une entreprise de faire tourner l’IA en production et d’en répondre. Pas un cadre dans une présentation, un système de contrôle qui s’exécute à chaque tâche.
La gouvernance est une architecture, pas un document.
La gouvernance de l’IA décide quel modèle exécute une tâche, quel humain valide, et ce qui est journalisé au moment même où cela se produit. 3 composants la rendent applicable, pas seulement déclarative.
Moteur de politiques
Décide, au moment de chaque tâche, quel modèle s’exécute, sous quelle résidence des données, avec quelle approbation requise avant la livraison du résultat. Le point d’application que les auditeurs examinent en premier.
Boucle de contrôle humain
Une personne nommée relit, annule ou arrête un résultat avant qu’il n’atteigne une décision à conséquence. Appliqué à chaque tâche au titre de l’article 14, pas documenté après coup.
Piste d’audit prête pour le conseil
Un registre de chaque action de l’IA, généré au moment où elle se produit, en ajout seul, rattaché à l’humain qui l’a vérifiée. La forme qu’un conseil remet à un régulateur sans préparation.
Ce que contient la piste d’audit, dessinée.
Chaque action devient un enregistrement, et chaque enregistrement porte l’empreinte du précédent. Un régulateur reçoit un export délimité de la chaîne ; le conseil reçoit un rapport construit à partir des mêmes enregistrements.
- Plan de preuve et d’auditC2 dans l’architecture de référence v1.0 : un enregistrement par action.
- Enregistrements #4124 à #4127Ajout seul, 9 champs chacun ; #4127 est l’action de cet exemple.
- Liens de hachageChaque enregistrement porte le hachage du précédent : une modification ou une suppression rompt la chaîne de façon visible.
- Export pour le régulateurUn extrait ciblé pour un système et une période, livré avec les hachages de la chaîne (sceau).
- Rapport au conseilConstruit à partir de la piste ; chaque chiffre renvoie à ses enregistrements.
Version texte
Le plan de preuve et d’audit porte 4 enregistrements, #4124 à #4127, chacun relié au précédent par son hachage. En dessous, la zone de supervision reçoit un export pour le régulateur portant les hachages de la chaîne sous sceau, et un rapport au conseil construit à partir des mêmes enregistrements.
Ces 3 composants forment une propriété d’une architecture plus large : la couche d’exploitation de l’IA. Voir la définition complète de la couche d’exploitation de l’IA
Les rôles, les droits de décision, les contrôles et la preuve de cette gouvernance sont publiés sous la forme d’un cadre versionné qu’un tiers peut tester. Lire l’Enterprise AI Governance Framework
Un tableau de bord note le risque. Il n’arrête pas une tâche.
Le marché de la gouvernance est saturé de 2 types de produits : des logiciels qui cataloguent le risque, et des cabinets qui recommandent un framework. Ni l’un ni l’autre ne fait tourner le processus métier, ni l’un ni l’autre ne répond quand un régulateur appelle.
Pas un tableau de bord GRC
Une plateforme GRC catalogue les systèmes d’IA et note le risque selon un calendrier. Elle ne décide pas, en temps réel, quel modèle exécute une tâche, ni n’arrête celui qui ne le devrait pas.
Pas un framework de conseil
Les cabinets de conseil recommandent un framework, puis s’en vont. La différence se voit le jour où un régulateur demande qui applique la politique, pas qui l’a rédigée.
Pas une checklist de conformité
Les guides génériques recyclent le texte réglementaire en une liste à cocher une fois. La gouvernance n’est pas un formulaire classé et oublié, c’est un contrôle qui s’exécute à chaque tâche.
Le même test s’applique au travail de stratégie : une recommandation n’est pas une couche d’exploitation de l’IA. Quand choisir Hikari Blue, et quand ne pas le faire
L’EU AI Act nomme le déployeur, pas le fournisseur du modèle.
Le Digital Omnibus a déplacé les obligations à haut risque au 2 décembre 2027. Les obligations de transparence de l’article 50 s’appliquent depuis le 2 août 2026 ; celles des modèles à usage général depuis le 2 août 2025, sous le contrôle de la Commission depuis le 2 août 2026. Selon notre lecture, le calendrier a bougé et l’exposition non : chaque obligation opérationnelle incombe toujours à qui fait tourner le processus métier en production, pas à l’entreprise qui a entraîné le modèle.
Article 9 · Gestion des risques
Gestion continue du risque sur tout le cycle de vie du système, pas une évaluation ponctuelle avant lancement. Le moteur de politiques applique le point de contrôle où le risque se crée réellement : la tâche.
Article 12 · Journalisation
Les systèmes à haut risque génèrent des journaux automatiquement pendant toute leur durée de vie. Une API de modèle ne le fait pas pour votre processus métier. La couche qui tourne en dessous, si.
Article 14 · Contrôle humain
Une personne nommée relit, annule ou arrête un résultat avant qu’il n’atteigne une décision à conséquence. La boucle de supervision est calibrée sur le risque de la tâche, fixée avant déploiement.
Article 26 · Devoirs du déployeur
La surveillance et le contrôle humain incombent au déployeur, pas au fournisseur du modèle. L’obligation revient à qui fait tourner le processus métier, sans exception pour un secteur régulé.
L’architecture de référence complète derrière ces contrôles est publiée. Voir la page Engineering Voir comment nous opérons
La gouvernance se livre avec le processus qu’elle gouverne : AI‑Enabled Operations, porté par un pod IA sur site. Pour les fonds de private equity : le Portfolio AI Program.
- Piste d’audit de l’IA : définition et correspondance avec l’AI Act Les 9 champs de l’enregistrement, rattachés aux articles 12, 19 et 26, avec les dates fixées par l’omnibus numérique.
- La maîtrise de l’IA et l’article 4 de l’AI Act L’obligation telle que réécrite en juillet 2026, qui elle couvre, qui la contrôle et les traces qui montrent qu’elle est respectée.
- L’AI Act pour les entreprises suisses Quand le règlement européen atteint une entreprise établie en Suisse, dans quel rôle et à partir de quelle date.
- La communication FINMA 08/2024 sur l’IA, attente par attente Les 7 domaines examinés par la FINMA chez les assujettis, et le contrôle et la preuve qui répondent à chacun.
Les questions que posent réellement les conseils et les directions des risques.
Qu’exige réellement la gouvernance de l’IA au titre de l’EU AI Act ?
Pour les systèmes à haut risque : article 9 sur la gestion des risques, article 12 sur la journalisation automatique, article 14 sur le contrôle humain et article 26 sur la surveillance par le déployeur, applicables à partir du 2 décembre 2027 après le report du Digital Omnibus de juillet 2026. Les obligations de transparence de l’article 50 s’appliquent depuis le 2 août 2026, celles des modèles à usage général depuis le 2 août 2025 (sous le contrôle de la Commission depuis le 2 août 2026), et les articles 4 et 5 depuis le 2 février 2025. Aucun n’est satisfait par un document de politique. Chacun exige un contrôle qui s’exécute dans le processus métier, pas un rapport rédigé après coup.
En quoi est-ce différent de l’achat d’une plateforme GRC ou de gouvernance de l’IA ?
Une plateforme GRC catalogue vos systèmes d’IA et évalue le risque selon un calendrier. Elle ne décide pas, en temps réel, quel modèle exécute une tâche donnée, ni n’arrête celui qui ne le devrait pas. Hikari Blue conçoit et exploite la couche d’application sur laquelle la plateforme repose, et en reste responsable en production.
Qui est responsable quand le système d’IA se trompe ?
Un associé désigné, par écrit, par mission. Les practices Hikari Blue signent le travail, pas un logo ni une équipe commerciale. Quand un régulateur ou un conseil demande qui a approuvé un déploiement, il y a un nom pour répondre, et une piste d’audit derrière. Le modèle de practice
Combien de temps avant qu’un conseil ne voie cela fonctionner ?
30 minutes suffisent pour cartographier la couche de gouvernance sur un processus métier déjà en production, avec la piste d’audit qu’un régulateur demanderait. Le conseil repart avec le schéma. Aucun pilote n’est requis avant que le premier livrable n’existe.
Voir la couche de gouvernance appliquée à vos propres processus métier.
30 minutes avec un associé désigné. Nous cartographions le moteur de politiques et la piste d’audit sur un processus métier que vous faites déjà tourner, avec le registre que votre régulateur demanderait. Vous repartez avec le schéma, que nous travaillions ensemble ou non.
- Un processus métier que vous exploitez déjà, projeté sur le moteur de règles
- L’enregistrement que demanderait votre régulateur
- Un schéma que vous gardez, que nous travaillions ensemble ou non