Cadre de gouvernance · v1.0 · 25 septembre 2026

Enterprise AI Governance Framework

Ce cadre est le modèle opérationnel de gouvernance qui tourne sur l'AI operating layer : rôles, droits de décision, contrôles, preuve et cadence. Il transforme l'architecture de référence en décisions dont quelqu'un répond. Il s'adresse aux conseils d'administration, DSI, RSSI, directeurs des risques, DPO, auditeurs internes et à tout déployeur qui porte des obligations au titre de l'EU AI Act.

Comment citer ce document

0 · Statut et conventions

Un modèle de gouvernance public et versionné, testable par un tiers.

L'AI Operating Layer Reference Architecture spécifie ce que la couche doit faire. Ce cadre spécifie qui décide, qui répond, et quelle preuve établit que chaque décision a été prise.

Dans ce document, « nous » désigne Hikari Blue, la firme qui installe ce cadre sur les missions de ses clients puis le leur remet. Le mot « doit » marque une exigence ; le mot « devrait » marque une pratique qu'un déployeur peut remplacer par un équivalent consigné.

La page gouvernance de l'IA explique pourquoi la gouvernance est une architecture. Ce document est le cadre versionné et citable auquel cette page renvoie : identifiants, responsables, cadences et critères de réussite.

Les ancrages réglementaires citent le règlement (UE) 2024/1689, l'EU AI Act, sur EUR-Lex (ouvre dans un nouvel onglet), et le règlement (UE) 2016/679, le RGPD, sur EUR-Lex (ouvre dans un nouvel onglet). Le calendrier d'application de l'AI Act est suivi sur la page de définition, afin que ce cadre reste valide quand le calendrier bouge.

1 · Principes

Huit principes, chacun rattaché à une propriété d'architecture ou à une obligation légale.

Un principe qui ne correspond à rien d'applicable est une déclaration de valeurs. Chaque principe ci-dessous nomme le plan de l'architecture de référence qui l'applique, ou l'obligation qui l'exige.

  1. 01

    Gouverner l'action, pas le modèle

    La gouvernance s'applique à chaque tâche qu'exécute un modèle ou un agent, parce que l'EU AI Act place les obligations opérationnelles sur le déployeur qui fait tourner le workflow (article 26).

  2. 02

    Pas de politique sans point d'application

    Chaque règle écrite doit correspondre à une politique évaluée à l'exécution par le plan politique et gouvernance, faute de quoi elle est consignée comme un écart ouvert.

  3. 03

    La preuve naît au moment de l'action

    Le plan preuve et audit écrit l'enregistrement au moment où l'action a lieu, ce que l'article 12 entend par enregistrement automatique tout au long du cycle de vie du système.

  4. 04

    Un humain nommé par décision à enjeu

    Un vérificateur nommé approuve, rejette ou corrige les sorties à enjeu. Cela donne effet au contrôle humain de l'article 14 de l'AI Act, et à la limite que pose l'article 22 du RGPD aux décisions exclusivement automatisées concernant une personne.

  5. 05

    Arrêter coûte peu, redémarrer est délibéré

    Tout opérateur ou vérificateur nommé peut arrêter par le plan de contrôle, tandis que le redémarrage exige le responsable des risques IA, conformément à l'obligation de l'article 14 de pouvoir interrompre un système par une procédure d'arrêt.

  6. 06

    Le choix du fournisseur est une décision gouvernée et réversible

    Le plan routage et exécution fait du choix du modèle une configuration consignée, ce qui garde sous contrôle la concentration sur des tiers prestataires TIC, comme l'attendent DORA et NIS2.

  7. 07

    La souveraineté s'applique charge par charge

    Les corridors de résidence et la garde des clés sont déclarés par charge et appliqués à l'exécution, ce qui donne à l'analyse d'impact de l'article 35 du RGPD des faits plutôt que des intentions.

  8. 08

    La gouvernance se transfère avec la couche

    Les rôles, les contrôles et la preuve passent à l'équipe du client selon un plan daté, parce que le modèle d'exploitation de l'architecture de référence se termine avec le client aux commandes de la couche.

2 · Rôles et droits de décision

Sept rôles, un nom responsable par décision.

Le cadre définit des rôles, pas des intitulés de poste. Une même personne peut tenir plusieurs rôles dans un petit déploiement, à une exception près : un vérificateur n'approuve jamais une sortie d'un workflow dont il est propriétaire.

  • Conseil d'administration

    Fixe l'appétence au risque IA, approuve les classes de cas d'usage que l'entreprise accepte et reçoit le rapport trimestriel au conseil. Il peut demander les enregistrements derrière n'importe quel chiffre.

  • Dirigeant responsable

    Un membre nommé du comité exécutif qui répond de l'IA en production. Il signe le rapport au conseil, porte les notifications au régulateur et arbitre entre la pression métier et le risque.

  • Responsable des risques IA

    Propriétaire, en deuxième ligne, du jeu de politiques, de la classification des risques et du registre des incidents. Il détient l'autorité de redémarrer tout système après un arrêt.

  • Propriétaire du système

    Propriétaire métier, en première ligne, d'un workflow. Il possède ses agents, ses choix de routage, ses notices d'utilisation et la désignation de ses vérificateurs humains.

  • Vérificateur humain

    Une personne nommée et formée qui approuve, rejette ou corrige une sortie à enjeu. La décision est inscrite dans l'enregistrement, avec l'identité et le motif.

  • Opérateur

    L'équipe qui fait tourner la couche : déploiement des politiques, changements de modèle, astreinte, exercices de kill switch. Pendant une mission, elle peut nous inclure ; après le transfert, c'est l'équipe du client.

  • Fournisseur de modèles

    Un prestataire externe de modèles de fondation, gouverné comme un tiers prestataire TIC. Il fournit des notices d'utilisation et reçoit les informations d'incident ; il ne porte jamais les obligations du déployeur.

3 · Droits de décision

Dix décisions, chacune avec un rôle responsable.

Le tableau suit la convention RACI : un rôle est redevable, un rôle exécute, les autres sont consultés avant ou informés après. Deux noms redevables sur une même décision, c'est n'en avoir aucun.

Décision Redevable Exécutant Consulté · Informé
Fixer l'appétence au risque IA et les classes de cas d'usage acceptées Conseil d'administration Dirigeant responsable C : responsable des risques IA, DPO, RSSI · I : audit interne
Approuver la mise en production d'un workflow Dirigeant responsable Propriétaire du système C : responsable des risques IA, DPO, RSSI · I : conseil, par le rapport au conseil
Fixer ou modifier une politique ou un corridor de résidence Responsable des risques IA Opérateur C : DPO, RSSI · I : propriétaire du système
Choisir ou changer de fournisseur de modèles Propriétaire du système Opérateur C : responsable des risques IA, RSSI · I : fournisseur de modèles
Créer une identité d'agent et son périmètre d'outils Propriétaire du système Opérateur C : RSSI · I : responsable des risques IA
Approuver, rejeter ou corriger une sortie à enjeu Vérificateur humain Vérificateur humain C : propriétaire du système · I : consigné dans la piste
Déclencher le kill switch Tout opérateur ou vérificateur nommé Opérateur I : propriétaire du système, responsable des risques IA, dirigeant responsable
Redémarrer après un arrêt Responsable des risques IA Opérateur C : propriétaire du système · I : dirigeant responsable
Notifier un incident au régulateur ou au fournisseur Dirigeant responsable Responsable des risques IA C : DPO, RSSI, juridique · I : conseil, fournisseur de modèles
Émettre le rapport trimestriel au conseil Dirigeant responsable Responsable des risques IA C : audit interne · I : conseil

L'audit interne reste indépendant de chaque ligne sur laquelle il est consulté : il teste les contrôles, il ne les opère jamais. La répartition entre première ligne, deuxième ligne et audit interne suit le modèle des trois lignes de l'Institute of Internal Auditors (2020). Le rôle du DPO et son indépendance découlent des articles 37 à 39 du RGPD.

4.1 · Catalogue des contrôles · Domaine P

Quinze contrôles en quatre domaines. Domaine P : politique et choix des modèles.

Chaque contrôle porte un identifiant stable, un énoncé, l'artefact qui le prouve, un responsable, une cadence et son ancrage réglementaire. Un auditeur teste un contrôle en demandant l'artefact, jamais une présentation à son sujet.

  • GOV-P-01 · Registre et classification des cas d'usage

    Énoncé. Chaque cas d'usage de l'IA est enregistré et classé avant la construction, y compris s'il est à haut risque et si une analyse d'impact sur les droits fondamentaux s'applique.

    Preuve. Le registre des cas d'usage, avec la justification de classement signée par le responsable des risques IA.

    Responsable et cadence. Responsable des risques IA ; à l'entrée, revu chaque trimestre.

    Point d'ancrage réglementaire. AI Act, articles 26 et 27 ; article 9 lorsque l'entreprise construit elle-même un système à haut risque.

  • GOV-P-02 · Politique en code

    Énoncé. Chaque règle portant sur le modèle, les données et l'approbation est une politique versionnée évaluée à l'exécution ; une règle écrite sans point d'application est consignée comme un écart.

    Preuve. Le dépôt des politiques, son historique de versions et l'approbation de chaque version.

    Responsable et cadence. Responsable des risques IA pour le contenu, opérateur pour le déploiement ; à chaque modification, revu chaque trimestre.

    Point d'ancrage réglementaire. AI Act, article 9 sur la gestion des risques et article 26 sur les obligations du déployeur.

  • GOV-P-03 · Choix des modèles et maîtrise des changements

    Énoncé. Chaque classe de tâches déclare un modèle principal, un repli et un corridor de résidence ; tout changement est une modification de configuration approuvée et consignée dans la piste.

    Preuve. La table de routage, le catalogue de modèles et les entrées de changement dans la piste.

    Responsable et cadence. Propriétaire du système ; à chaque modification, avec une revue trimestrielle des fournisseurs.

    Point d'ancrage réglementaire. DORA, gestion du risque lié aux tiers prestataires TIC ; NIS2, mesures de sécurité de la chaîne d'approvisionnement.

  • GOV-P-04 · Notice d'utilisation et transparence

    Énoncé. Le déployeur détient la notice d'utilisation du fournisseur, opère chaque workflow dans son cadre et informe les personnes concernées lorsque le règlement l'exige.

    Preuve. Un dossier de notice d'utilisation par système et les textes d'information présentés aux personnes concernées.

    Responsable et cadence. Propriétaire du système ; à l'intégration et à chaque changement de version du modèle.

    Point d'ancrage réglementaire. AI Act, article 13 sur la transparence et article 26 sur l'utilisation conforme à la notice.

4.2 · Catalogue des contrôles · Domaine D

Domaine D : données et souveraineté.

Trois contrôles maintiennent les données là où l'entreprise a décidé qu'elles résident, et tiennent les données personnelles hors de la piste elle-même.

  • GOV-D-01 · Corridor de résidence par charge

    Énoncé. Chaque charge déclare où se trouvent calcul, stockage, inférence et clés ; la couche refuse et journalise tout appel hors corridor.

    Preuve. La carte de résidence et le journal des refus.

    Responsable et cadence. RSSI, avec le DPO consulté ; appliqué à chaque action, refus revus chaque semaine.

    Point d'ancrage réglementaire. RGPD, article 35 ; postures de résidence sectorielles publiées dans le Trust Center

  • GOV-D-02 · Analyses d'impact avant la production

    Énoncé. Tout traitement à haut risque de données personnelles fait l'objet d'une analyse d'impact relative à la protection des données ; les déployeurs concernés réalisent une analyse d'impact sur les droits fondamentaux avant la première utilisation.

    Preuve. Des analyses signées, rattachées à l'entrée du registre des cas d'usage qu'elles couvrent.

    Responsable et cadence. DPO pour l'AIPD, responsable des risques IA pour la FRIA ; avant la production et à chaque changement substantiel.

    Point d'ancrage réglementaire. RGPD, article 35 ; AI Act, article 27.

  • GOV-D-03 · Entrées par référence

    Énoncé. La piste stocke les entrées par référence ou par empreinte, et les charges sensibles tournent avec zéro donnée en clair côté serveur lorsque le registre des décisions d'architecture l'exige.

    Preuve. Des échantillons d'enregistrements ne montrant que des références, et le registre des décisions d'architecture.

    Responsable et cadence. RSSI ; appliqué à chaque action, échantillonné chaque trimestre.

    Point d'ancrage réglementaire. RGPD, article 35, mesures qui répondent aux risques identifiés.

4.3 · Catalogue des contrôles · Domaine A

Domaine A : autorisation et arrêt des agents.

Quatre contrôles rendent chaque agent attribuable, borné, supervisé quand l'enjeu le justifie, et arrêtable en une seule action.

  • GOV-A-01 · Une identité par agent

    Énoncé. Chaque agent détient sa propre identité issue du fournisseur d'identité de l'entreprise, jamais un compte de service partagé, et figure au registre des agents.

    Preuve. Le registre des agents, rapproché du fournisseur d'identité.

    Responsable et cadence. Propriétaire du système ; à la création, rapproché chaque semaine.

    Point d'ancrage réglementaire. AI Act, article 12 sur la traçabilité et article 26 sur la surveillance par le déployeur.

  • GOV-A-02 · Périmètre et budget déclarés

    Énoncé. Les outils, les données et les dépenses de chaque agent sont déclarés ; tout appel hors de ce périmètre est refusé avant exécution et journalisé avec la version de la politique qui s'est déclenchée.

    Preuve. La matrice des permissions et le journal des refus.

    Responsable et cadence. RSSI ; appliqué à chaque action, refus revus chaque semaine.

    Point d'ancrage réglementaire. NIS2, mesures de gestion des risques de cybersécurité, dont le contrôle d'accès.

  • GOV-A-03 · Vérification humaine des sorties à enjeu

    Énoncé. Les sorties au-dessus d'un seuil d'enjeu déclaré attendent un vérificateur nommé, qui les approuve, les rejette ou les corrige avant qu'elles ne produisent effet.

    Preuve. Le champ de vérification humaine de chaque enregistrement, et le dossier de compétence du vérificateur.

    Responsable et cadence. Le propriétaire du système désigne, le vérificateur exécute ; à chaque action.

    Point d'ancrage réglementaire. AI Act, articles 14 et 26 ; RGPD, article 22.

  • GOV-A-04 · Chemin d'arrêt et exercice

    Énoncé. Chaque agent, modèle et workflow peut être arrêté en une seule action par un opérateur ou un vérificateur nommé ; le redémarrage exige le responsable des risques IA.

    Preuve. Le runbook du kill switch et l'historique de ses exercices, avec les temps d'arrêt mesurés.

    Responsable et cadence. Opérateur ; à chaque événement, exercice chaque trimestre.

    Point d'ancrage réglementaire. AI Act, article 14 sur la procédure d'arrêt ; article 26 sur la suspension de l'utilisation lorsqu'un risque apparaît.

4.4 · Catalogue des contrôles · Domaine E

Domaine E : preuve et reporting.

Quatre contrôles font de la piste une preuve pour un régulateur, un conseil et un auditeur, sans assemblage manuel.

  • GOV-E-01 · Piste en ajout seul et chaînée

    Énoncé. Chaque action écrit un enregistrement portant les neuf champs de l'architecture de référence, chaîné par empreinte et conservé au moins pendant la durée légale minimale.

    Preuve. La piste elle-même et le résultat quotidien de vérification de la chaîne.

    Responsable et cadence. Opérateur ; écrit à chaque action, vérifié chaque jour.

    Point d'ancrage réglementaire. AI Act, article 12 sur la journalisation ; article 26 sur la conservation des journaux par les déployeurs, au moins six mois.

  • GOV-E-02 · Registres de maîtrise de l'IA datés

    Énoncé. Chaque personne qui opère ou vérifie détient un registre de maîtrise de l'IA daté et résolu par rôle avant que l'accès ne lui soit accordé.

    Preuve. Des registres de formation rattachés aux identités des registres des agents et des opérateurs.

    Responsable et cadence. Dirigeant responsable ; avant l'accès, renouvelé chaque année.

    Point d'ancrage réglementaire. AI Act, article 4 sur la maîtrise de l'IA.

  • GOV-E-03 · Surveillance et registre des incidents

    Énoncé. L'exploitation est surveillée au regard de seuils déclarés ; chaque incident ouvre un enregistrement avec sa décision de notification pour chaque régime.

    Preuve. Le registre des incidents et les notifications envoyées aux régulateurs et aux fournisseurs.

    Responsable et cadence. Responsable des risques IA ; surveillé chaque jour, consigné à chaque incident.

    Point d'ancrage réglementaire. AI Act, article 26 sur la surveillance par le déployeur et article 72 sur la surveillance après commercialisation par le fournisseur ; notification des incidents au titre de DORA, NIS2 et du RGPD.

  • GOV-E-04 · Rapport trimestriel au conseil

    Énoncé. Un rapport trimestriel est construit à partir de la piste, et chaque chiffre qu'il contient renvoie aux enregistrements qu'il agrège.

    Preuve. Le rapport au conseil signé et le procès-verbal du conseil qui l'a reçu.

    Responsable et cadence. Dirigeant responsable ; chaque trimestre.

    Point d'ancrage réglementaire. DORA, responsabilité de l'organe de direction pour le risque TIC ; AI Act, article 26 sur la surveillance.

Le catalogue correspond aux quatre contrôles C1 à C4 de l'architecture de référence. Le domaine P repose sur C1, le domaine D sur C3, le domaine A sur C4 et le domaine E sur C2. Pour une trajectoire de certification de système de management, les mêmes contrôles s'inscrivent dans ISO/IEC 42001:2023 et dans la fonction Govern du NIST AI Risk Management Framework 1.0.

5 · Preuve et reporting

Trois documents, tous construits à partir de la piste, aucun écrit à la main.

L'enregistrement à neuf champs de l'architecture de référence est la seule source primaire. Le rapport au conseil, l'export régulateur et le registre des incidents en sont des vues, si bien que chaque chiffre se rattache aux actions qu'il compte.

Document Ce qu'il contient Champs d'enregistrement utilisés
Rapport trimestriel au conseil Les workflows en production et leur classe de risque. Les agents par identité et par propriétaire. La répartition des modèles par fournisseur et par corridor. Les refus de politique, les corrections humaines et leur tendance. Les exercices de kill switch avec les temps d'arrêt. Les incidents et les notifications. Les écarts de contrôle ouverts, chacun avec un responsable et une date. Les neuf, agrégés. Chaque chiffre renvoie aux enregistrements qu'il compte, si bien qu'un administrateur peut demander la preuve sous-jacente.
Export régulateur Les enregistrements bruts d'un système sur une période, avec les versions de politique, le registre des agents et les registres de maîtrise de l'IA en vigueur à ce moment. Les neuf, non agrégés. Les empreintes de la chaîne voyagent avec le fichier, si bien que le destinataire vérifie l'intégrité sans avoir à faire confiance à l'expéditeur.
Registre d'incident L'heure de détection, le périmètre, l'action d'arrêt et l'heure d'arrêt, la décision de notification pour chaque régime, la cause racine, le correctif, le test de non-régression et une note de retour d'expérience signée par une personne nommée. Une référence à la plage d'enregistrements concernés de la piste, jamais une copie. L'identité de l'acteur, le modèle et sa version, la politique appliquée et l'horodatage localisent la défaillance.

Les fenêtres de notification prévues par le RGPD, DORA et NIS2 sont cartographiées à l'avance pour chaque mission et publiées dans le Trust Center. Notre socle de mission conserve la piste selon le contrat, douze mois au minimum, au-dessus du plancher de six mois de l'article 26.

6 · Cadence

Cinq rythmes, de chaque action à chaque année.

Une gouvernance qui ne se réunit qu'une fois par trimestre revoit de l'histoire. Le cadre tourne à cinq rythmes, et le plus rapide n'exige aucune réunion.

Cadence Ce qui se passe Qui
À chaque action Politique évaluée, corridor appliqué, périmètre vérifié, enregistrement écrit, vérification recueillie lorsqu'elle est requise. La couche, automatiquement ; les vérificateurs humains sur les sorties à enjeu.
Chaque jour Chaîne d'empreintes vérifiée, seuils de surveillance revus, incidents ouverts triés. Opérateur d'astreinte ; responsable des risques IA en cas de dépassement.
Chaque semaine Refus de politique, refus de résidence et corrections revus ; registre des agents rapproché du fournisseur d'identité. Propriétaires des systèmes avec l'opérateur ; RSSI sur les refus de périmètre.
Chaque trimestre Rapport au conseil émis, exercice de kill switch mené, revue des fournisseurs tenue, politiques et classes de cas d'usage réapprouvées. Dirigeant responsable, responsable des risques IA, conseil.
Chaque année Appétence au risque redéfinie, registres de maîtrise de l'IA renouvelés, version du cadre revue, test indépendant du catalogue des contrôles. Conseil, dirigeant responsable, audit interne.

7 · Modèle de maturité

Quatre niveaux, chacun franchi sur preuve, pas sur déclaration.

Chaque niveau a des critères de réussite qu'un auditeur interne peut vérifier à partir d'artefacts. Les niveaux suivent les six phases de mission : Diagnostic, Architecture, Build, Governance, Adoption, Run.

Niveau Critères de réussite Phases
1 · Pilote Le registre des cas d'usage existe et classe chaque cas. Le dirigeant responsable et le responsable des risques IA sont nommés. Le tableau des droits de décision est signé pour un workflow. Diagnostic, Architecture
2 · Gouverné Les politiques tournent en code avec des points d'application. Chaque agent a sa propre identité. La piste écrit des enregistrements chaînés à neuf champs. Un exercice de kill switch est consigné. L'AIPD et la FRIA sont signées là où elles s'appliquent. Build, Governance
3 · Opéré Les opérateurs et vérificateurs du client travaillent en poste avec des registres de maîtrise de l'IA datés. Les cadences hebdomadaire et trimestrielle ont tourné au moins une fois. Le premier rapport au conseil est émis à partir de la piste. Adoption
4 · Transféré L'équipe du client fait tourner chaque contrôle sans aide du prestataire, y compris un changement de fournisseur et un exercice de kill switch à partir du seul runbook. L'audit interne a testé le catalogue. Run

Le niveau 4 correspond au test 06, la répétition du transfert, du protocole de due diligence. Un client qui s'arrête au niveau 3 détient toujours le code, les runbooks et la preuve : la propriété se transfère dès le premier jour, la maturité mesure qui sait les faire tourner. Les six phases en détail

8 · Trajectoire d'adoption

Quatre-vingt-dix jours, trois blocs, un premier workflow.

Le cadre s'installe sur un workflow déjà en production, puis s'étend. Chaque bloc se clôt sur des artefacts, si bien que l'avancement se mesure en preuves plutôt qu'en réunions.

  1. 01

    Jours 1 à 30 · Cartographier et attribuer

    Enregistrer et classer les cas d'usage, nommer le dirigeant responsable et le responsable des risques IA, et signer le tableau des droits de décision pour le premier workflow.

    Livrables : registre des cas d'usage, classification des risques, droits de décision signés, architecture cible, liste des écarts au regard des quinze contrôles. Sortie au niveau de maturité 1.

  2. 02

    Jours 31 à 60 · Appliquer et consigner

    Traduire les politiques en code, donner à chaque agent son identité et son périmètre, démarrer la piste chaînée et mener le premier exercice de kill switch.

    Livrables : dépôt des politiques, registre des agents, matrice des permissions, piste active, compte rendu d'exercice, AIPD et FRIA signées là où elles s'appliquent. Sortie au niveau de maturité 2.

  3. 03

    Jours 61 à 90 · Opérer et rendre compte

    Former et nommer les vérificateurs, faire tourner la cadence hebdomadaire, répéter un export régulateur et émettre le premier rapport au conseil à partir de la piste.

    Livrables : registres de maîtrise de l'IA datés, liste des vérificateurs, premier rapport au conseil, compte rendu de répétition d'export, évaluation de maturité et plan de transfert. Sortie au niveau de maturité 3.

Les registres de maîtrise de l'IA suivent les parcours de formation datés et résolus par rôle qui rendent l'article 4 démontrable. Le niveau 4 dépend du plan de transfert, pas des quatre-vingt-dix jours.

9 · Anti-patterns

Cinq conceptions de gouvernance qui passent une revue et échouent face à un incident.

Chaque anti-pattern produit des documents qu'une revue accepte. Chacun cède le jour où un agent dérape ou où un régulateur demande un enregistrement.

  • Un comité sans chemin d'arrêt

    Un comité IA se réunit chaque mois, mais personne d'astreinte ne peut arrêter un agent ce soir. Un contrôle qui ne peut pas interrompre échoue à GOV-A-04 et à l'article 14.

  • Une politique sans point d'application

    Une politique IA signée qu'aucune exécution n'évalue. La politique décrit une intention pendant que le workflow fait autre chose, ce qui échoue à GOV-P-02.

  • Une preuve reconstituée après coup

    Des journaux assemblés avant un audit à partir de plusieurs systèmes. Le fichier ne peut pas prouver qu'il n'a pas été modifié : il échoue à GOV-E-01. Ce n'est pas l'enregistrement automatique que décrit l'article 12.

  • Une formation à la maîtrise de l'IA sans preuve datée

    Un cours que tout le monde a suivi et que personne ne peut prouver. Sans registres datés et résolus par rôle, rattachés aux identités, l'article 4 ne peut pas être démontré, ce qui échoue à GOV-E-02.

  • Des identités d'agent partagées

    Plusieurs agents qui agissent sous un même compte de service. Aucune action n'est attribuable et aucun agent ne peut être arrêté seul, ce qui échoue à GOV-A-01 et GOV-A-04.

10 · Versions et citation

Comment citer ce document.

Cette URL est permanente et sert toujours la version en vigueur. Chaque modification d'un contrôle ou d'un rôle incrémente la version et figure dans l'historique des versions, afin qu'une citation reste rattachable au texte qu'elle cite.

  • Citation recommandée

    Hikari Blue, « Enterprise AI Governance Framework v1.0 », 25 septembre 2026, https://hikariblue.com/governance-framework

    Les ancres de section sont stables : #principles, #roles, #controls, #evidence, #cadence, #maturity, #adoption, #anti-patterns, #cite. Les identifiants de contrôle GOV-P-01 à GOV-E-04 sont stables d'une version à l'autre.

  • Historique des versions

    v1.0 · 25 septembre 2026. Première version publique : huit principes, sept rôles et dix droits de décision, quinze contrôles en quatre domaines, modèle de preuve et de reporting, cinq cadences, quatre niveaux de maturité, trajectoire d'adoption en quatre-vingt-dix jours, cinq anti-patterns.

    Licence. Publié sous CC BY 4.0 : libre de citation, de reprise et de réutilisation, avec attribution à Hikari Blue et un lien vers cette URL.

Les corrections et contestations d'un contrôle sont bienvenues de la part des conseils d'administration, des auditeurs, des DPO et des régulateurs. Adressez-les par le canal conformité ; les modifications retenues sont créditées dans l'historique des versions.

Pour les conseils d'administration, DSI, RSSI, directions des risques et DPO

Testez votre gouvernance au regard du catalogue.

Trente minutes avec un partner désigné. Nous projetons les quinze contrôles sur un workflow que vous opérez déjà et montrons lesquels passent, lesquels échouent, et qui devrait porter chaque écart. Vous repartez avec la carte, que nous travaillions ensemble ou non.

Réserver le diagnostic Ou lire l'AI Operating Layer Reference Architecture