Normes et contrôle d'exécution de l'IA : une perspective infrastructurelle.

Niveaux différents, même problème.

L'AI Act, la NIS2 et les standards ISO et NIST opèrent sur des plans différents : juridique, organisationnel, de gestion du risque. Bien qu'hétérogènes, ils convergent vers un ensemble restreint d'exigences clés.

Lus par principes et non par articles, ces exigences se ramènent à quatre propriétés récurrentes : contrôle préventif de l'invocation de l'IA, traçabilité documentée et vérifiable des décisions, auditabilité technique et responsabilité attribuable à des sujets identifiables.

Le plan juridique définit des obligations ; le plan organisationnel définit des processus ; le plan de la gestion du risque définit des méthodes. Il manque, dans cette stratification, une définition explicite des mécanismes techniques par lesquels ces exigences peuvent être rendues observables dans les systèmes qui exécutent effectivement l'IA.

Le dénominateur commun manquant.

Les exigences énumérées dans les cadres de référence sont exprimées en termes de ce qui doit être garanti. Leur traduction opérationnelle est aujourd'hui confiée à des instruments hétérogènes — règles textuelles, documentation, contrôles applicatifs, enregistrements a posteriori — rarement ramenés au même plan architectural.

Il manque en particulier un point de contrôle technique présentant conjointement les quatre propriétés suivantes.

• Non contournable L'autorisation d'usage de l'IA ne peut être ignorée, réécrite ou omise par le code qui la demande.
• Indépendant Le point de contrôle est découplé des applications : il ne dépend ni de leur coopération ni de leur configuration correcte.
• Sous-applicatif Il réside en dessous du niveau applicatif, dans une position que les applications ne peuvent modifier.
• Preuves techniques Il produit, comme effet de son propre fonctionnement, des enregistrements vérifiables des décisions prises.

L'absence d'un tel point de contrôle n'est pas une lacune des normes : c'est une lacune de l'architecture des systèmes. C'est, en d'autres termes, un problème architectural.

Où se situe AIKNOCK.

AIKNOCK explore un possible point de contrôle technique ex-ante, au niveau du système, cohérent avec les exigences de contrôle d'exécution, d'auditabilité et de maîtrise du risque posées par les normes et les cadres, sans les remplacer ni les interpréter.

Les normes et les standards définissent des obligations. AIKNOCK opère sur le plan des mécanismes techniques. Le système opère de manière indépendante des cadres normatifs ou standardisés externes et maintient un comportement technique cohérent au niveau de l'exécution. Les deux plans sont complémentaires : ce que le droit et les standards prescrivent comme propriétés du système, un mécanisme tel que celui décrit peut contribuer à le rendre observable et vérifiable.

Ce qu'AIKNOCK ne fait pas à l'égard des normes.

Pour éviter la confusion entre des plans distincts, il convient d'énoncer explicitement le périmètre qu'AIKNOCK n'occupe pas.

• NE FAIT PAS il n'interprète pas la loi,
• NE FAIT PAS il ne garantit pas la conformité,
• NE FAIT PAS il ne remplace pas les processus organisationnels ou juridiques,
• NE FAIT PAS il n'élimine pas les responsabilités des deployers,
• NE FAIT PAS il ne gouverne ni les jeux de données ni les processus d'training.

L'observance des normes demeure une responsabilité des opérateurs, des implémenteurs et des autorités compétentes. AIKNOCK ne déplace pas cette responsabilité : il décrit un plan technique distinct.

Conclusion.