La gouvernance de l'IA a besoin d'architecture, pas d'une liste de contrôle de plus

La plupart des démarches de gouvernance de l'IA commencent près de la fin du système. Une politique est rédigée, un registre des risques est ouvert, un comité se réunit, et une liste de contrôle consigne ce que le système est censé faire. Chacun de ces artefacts a son utilité. Aucun ne répond à la question à laquelle l'architecture doit finir par répondre : quelle propriété du système rend l'énoncé de gouvernance vrai ?

Une politique peut dire que les résultats incertains font l'objet d'une revue humaine. Quelque part dans le code, quelque chose décide de ce qui compte comme incertain, et autre chose décide si un résultat incertain peut malgré tout poursuivre son chemin. Si ces décisions ne sont pas conçues, elles existent quand même ; elles sont simplement prises par accident. La gouvernance devient plus que de la documentation lorsque l'architecture peut l'imposer.

Trois énoncés figurent dans presque tous les documents de gouvernance de l'IA.

"Des personnes doivent revoir les résultats incertains." En tant que politique, c'est une intention. En tant qu'architecture, il faut un endroit où l'incertitude est représentée explicitement, une frontière que les résultats incertains ne peuvent pas franchir, une personne désignée qui décide, et un enregistrement de cette décision qui reste attaché au résultat. Sans la frontière, la revue est une politesse que la chaîne accorde quand elle n'est pas occupée.

"La traçabilité est assurée." En tant que politique, cela signifie en général que des journaux existent. En tant qu'architecture, cela signifie que le système préserve les relations nécessaires pour reconstituer comment une sortie précise est née : les preuves sur lesquelles elle repose, les étapes qui l'ont touchée, les décisions prises à son sujet et par qui. Des journaux qui n'ont jamais été conçus pour être rassemblés sont du stockage, pas de la traçabilité.

"Le modèle ne doit pas faire X." En tant que politique, c'est une demande adressée à un composant probabiliste. En tant qu'architecture, c'est une frontière déterministe qui ne dépend pas de la coopération du modèle : X est inaccessible depuis l'endroit où se trouve le modèle, ou bien un composant capable de refuser X le vérifie. Une règle adressée à un modèle est un espoir. Une frontière autour d'un modèle est une contrainte.

Un énoncé dans un document peut être vrai ou faux à propos d'un système, et la lecture du document ne dit pas lequel des deux. Une contrainte dans l'architecture peut être inspectée, testée et, quand elle casse, remarquée.

COADF, le Compliance-Oriented AI Development Framework, est un cadre de développement documenté publiquement pour les systèmes d'IA qui doivent tenir face à la réglementation. Il est issu du travail d'architecture du projet de recherche et développement AnyLAI et de sa démonstration de passeports de produit AnyDPP, mais sa portée dépasse un produit, une réglementation ou une mise en œuvre particuliers.

Il énonce huit principes d'architecture, chacun lié à l'obligation pour laquelle il a été écrit, avec des modèles de gouvernance, dont une échelle d'autonomie pour les agents d'IA qui écrivent du code de production, et un modèle lisible par machine pour rendre compte des contrôles qu'un projet exerce réellement. Son objet, ce sont les frontières entre le traitement déterministe, l'IA probabiliste, la preuve, la confiance, la revue humaine, les règles, la traçabilité, les normes externes et ce que le système publie.

Le nom décrit une orientation, pas un résultat. La méthode de développement est orientée vers les exigences réglementaires ; le nom n'affirme jamais qu'un système construit avec elle les respecte.

Chaque principe répond à une manière précise dont les systèmes d'IA cessent d'être gouvernables.

P-1 · D'abord déterministe, le probabiliste en quarantaine. Tout ce qui atteint une personne, un document ou un autre système est déterministe par défaut. Un composant probabiliste est cantonné à une tâche bornée et renvoie une valeur, une confiance et la méthode par laquelle la valeur a été extraite, jamais une valeur nue, parce qu'une valeur nue ne peut être ni filtrée, ni déclarée, ni revue.

P-2 · Sortie filtrée par la confiance. La confiance s'attache à un seul attribut, pas à un document entier, car un score unique pour un fichier cache quel fait, à l'intérieur, est faiblement étayé. Une confiance basse n'atteint jamais une sortie publiée. Sans preuve, il n'y a pas de valeur : ni valeur par défaut, ni estimation.

P-3 · Revue humaine par architecture. La revue est déclenchée par la confiance, pas par un calendrier. La personne qui revoit voit un fait à côté du passage de la source dont il provient et décide de ce fait ; une valeur rejetée laisse l'attribut vide au lieu d'appeler une seconde supposition.

P-4 · Une trace, de bout en bout. Un identifiant, créé à la réception d'un document, accompagne chaque étape de traitement, chaque évaluation de confiance et chaque décision humaine jusqu'à la sortie publiée, sur une piste à laquelle on ne fait qu'ajouter.

P-5 · Déclaration de l'extraction automatique. Une sortie contenant des données extraites par machine le dit de façon visible, sur la sortie elle-même, et nomme les attributs concernés.

P-6 · Le système de fences. Un garde-fou qui vit dans un document est un conseil. Un garde-fou qui s'exécute dans la chaîne et bloque une livraison est un fence.

P-7 · Isolation des dépendances aux normes. Les systèmes de classification, les bases terminologiques et les services de validation externes vivent dans des adaptateurs, hors du modèle de données central. Un service externe peut élever la confiance. Aucun ne peut bloquer une sortie.

P-8 · Les règles comme données, avec autonomie graduée. Les règles à l'aune desquelles une décision est mesurée sont des données versionnées, le moteur ne change pas quand une règle change, et chaque décision est liée à la version des règles qui l'a produite. Ce que le système peut faire sans une personne est fixé dans ces règles, jamais au-delà du plafond que fixe le droit.

Pris un par un, plusieurs de ces principes ressemblent à de l'hygiène d'ingénierie ordinaire. Ensemble, ils forment une discipline où chacun couvre une faiblesse que les autres laisseraient ouverte. Une confiance sans trace ne peut pas être auditée ; une trace sans filtre enregistre fidèlement des valeurs que personne n'a revues ; un filtre sans déclaration cache ce que la machine a apporté. Rien de tout cela ne survit au prochain refactoring si le build ne remarque pas quand cela casse.

Rien de tout cela ne s'oppose à l'apprentissage automatique. Les composants probabilistes sont précieux là où il faut interpréter : lire un document non structuré, reconnaître une entité dans un texte au format irrégulier, classer ce qu'aucune règle n'avait prévu. Les composants déterministes sont précieux là où comptent la répétabilité, l'application des frontières et la validation reproductible. L'erreur consiste à laisser implicite la répartition des responsabilités entre les deux.

Pour chaque chemin à travers le système, une architecture qui prend la frontière au sérieux peut dire quel composant a le droit d'inférer, lequel décide, lequel vérifie, lequel peut bloquer, et quel état ou quelle sortie devient visible à l'extérieur. Quand ces réponses vivent dans le code plutôt que dans un diagramme, une personne qui relit peut les vérifier, et une modification qui déplace une décision de l'autre côté de la frontière se voit à la relecture.

Une valeur de confiance décrit avec quelle force quelque chose est étayé. Elle ne rend rien vrai. Un modèle très confiant au sujet d'une valeur lue dans le mauvais document a formulé un énoncé précis sur la mauvaise chose.

La conséquence architecturale est que la confiance devrait changer ce que le système a le droit de faire, pas seulement ce qu'il affiche. Dans COADF, la confiance appartient à un attribut et à la preuve qui le soutient, et une confiance basse devient une question posée à une personne plutôt qu'une valeur publiée. Le cadre traite en outre un fait comme porteur de plusieurs lectures à la fois, par exemple si sa source est authentique et ce qu'elle couvre réellement, et ne les fond jamais en un seul chiffre. Un score sur un tableau de bord informe. Un score qui décide où une valeur peut aller gouverne.

"Il y a un humain dans la boucle" est la forme la plus faible d'une affirmation de contrôle humain, parce qu'elle laisse ouvertes toutes les questions qui comptent. Le règlement sur l'IA place l'exigence dans la conception elle-même : son article 14 demande que les systèmes d'IA à haut risque soient conçus et développés de manière à pouvoir être effectivement contrôlés par des personnes physiques pendant leur période d'utilisation.

Du point de vue de l'architecture, le contrôle humain doit répondre à quatre questions. Qu'est-ce qui déclenche le besoin d'une personne ? Sur quoi cette personne décide-t-elle : un dossier entier, ou un fait face à sa source ? Qu'est-ce qui ne peut pas avancer tant que la décision n'existe pas ? Et comment la décision, avec qui l'a prise et pourquoi, rejoint-elle la même trace que la valeur qu'elle concerne ? Une étape de revue que la chaîne peut contourner sous charge n'est pas un contrôle. C'est une file d'attente.

La traçabilité est généralement auditée comme l'existence de journaux. Un test plus utile consiste à savoir si une seule sortie publiée peut être remontée : du résultat visible de l'extérieur à la décision qui l'a libéré, au traitement qui l'a produit, aux preuves sur lesquelles il repose. Preuve, traitement, décision, résultat. Si un maillon de ce chemin doit être reconstitué par supposition, le système n'est pas traçable, quelle que soit la quantité de ce qu'il enregistre.

C'est pourquoi COADF traite la trace comme de l'architecture plutôt que comme de l'exploitation : un identifiant de la réception à la sortie, une piste à laquelle on ajoute et que l'on ne réécrit jamais, et une chaîne qui s'exporte sous une forme lisible par quelqu'un qui n'a pas construit le système. L'article 12 du règlement sur l'IA aborde l'enregistrement de la même façon, comme quelque chose qu'un système à haut risque doit permettre techniquement.

Une règle de gouvernance que rien ne vérifie se dégrade au rythme du code. Certaines règles ne peuvent être jugées que par des personnes. Beaucoup peuvent être vérifiées par le build : une dépendance qui ne doit pas exister entre deux couches, une formulation qu'une surface publique ne doit jamais employer, une livraison qui ne doit pas avancer tant qu'une vérification requise échoue. COADF traite ces règles comme des conditions sur lesquelles un build ou une livraison doit pouvoir échouer, et range ses fences en données, architecture, texte et processus.

Un fence doit aussi montrer qu'il fonctionne. COADF appelle cette pratique une preuve de dents : le vrai défaut est planté dans le vrai fichier, le fence se déclenche, et la plantation est retirée. Un fence que personne n'a jamais vu échouer est un commentaire avec un lanceur de tests à côté. Les rapports suivent la même règle : un contrôle ne compte comme appliqué que si sa preuve s'est exécutée dans une exécution identifiée et a réussi.

La réglementation façonne des exigences ; elle n'est pas une conception. Les textes juridiques sont modifiés, et les normes techniques sont révisées selon leurs propres cycles. Avec le règlement sur l'écoconception des produits durables, ce qu'un passeport numérique de produit doit contenir est fixé par des actes délégués, groupe de produits par groupe de produits. Un dictionnaire sémantique comme ECLASS, ou un modèle de jumeau numérique comme l'Asset Administration Shell, suit son propre calendrier de versions.

Un système qui inscrit ce vocabulaire en dur dans sa logique centrale devient fragile exactement là où la réglementation bouge. COADF garde les normes externes dans des adaptateurs qui peuvent apporter de la confiance mais pas décider, et les règles dans des données versionnées, de sorte qu'un changement de règle laisse le moteur intact et que les décisions antérieures nomment toujours la version des règles sous laquelle elles ont été prises. Relier un principe à l'article auquel il répond explique pourquoi le principe existe. Savoir si cet article s'applique à un système donné reste une question juridique.

COADF est un cadre de développement documenté publiquement. Ce n'est pas une certification, ce n'est pas une norme d'audit et ce n'est pas un schéma d'évaluation de la conformité. Ce n'est ni une approbation réglementaire, ni une promesse de conformité, ni un conseil juridique. Aucune autorité ne l'a évalué, audité ni avalisé. Rien ici n'est délivré, décerné ni retiré par quiconque, et l'appliquer ne produit ni label ni marque d'aucune sorte.

Le travail d'architecture devient plus utile quand ses hypothèses et ses frontières peuvent être inspectées. Un cadre privé ne peut qu'être décrit ; un cadre publié peut être lu, comparé et discuté.

La publication donne aux idées un vocabulaire stable, de sorte qu'une discussion sur les filtres de confiance ou les fences n'ait pas à commencer par redéfinir les termes. Elle rend les décisions de conception inspectables, y compris celles qui pourraient se révéler fausses. Elle donne à d'autres architectes quelque chose de concret à contester, et aux mises en œuvre une référence par rapport à laquelle expliquer où elles concordent et où elles divergent délibérément. Et elle laisse une trace technique publique et datée de ce qui a été énoncé, et quand.

Un cadre d'architecture public n'a pas besoin de publier chaque mécanisme de mise en œuvre. COADF documente les principes et les pratiques destinés à l'examen public, tandis que certains mécanismes propres à la mise en œuvre restent en dehors de l'édition publique. Ses pages disent, principe par principe, quelles parties sont énoncées en entier et lesquelles seulement comme principe, de sorte que la frontière elle-même est visible même là où le détail ne l'est pas.

COADF version 2.2 est documenté publiquement en anglais, allemand, espagnol, français et portugais du Brésil : les huit principes, les modèles de gouvernance, le rapport de contrôles et une carte réglementaire lue aux sources primaires, ainsi que le cadre complet en éditions téléchargeables. La réponse la plus utile à un cadre d'architecture n'est pas l'adhésion. C'est une lecture attentive et une objection précise.