Comment répondre à l'AI Act sans arrêter ses projets IA ?

Ce que l’AI Act exige concrètement

Le règlement européen sur l’intelligence artificielle est souvent lu comme un texte d’interdiction. Ce n’est pas sa mécanique principale. Pour la grande majorité des systèmes, il organise une mise en documentation et une supervision, proportionnées au risque. L’interdiction concerne des pratiques limitativement énumérées. Le reste du champ est un régime d’obligations.

Pour les systèmes classés à haut risque, le texte demande notamment : une gestion des risques, des données d’entraînement et d’entrée documentées, des logs, une transparence vis-à-vis des utilisateurs concernés, une surveillance humaine, une précision et une robustesse déclarables. Traduit en langage d’exploitation, cela signifie que l’organisation doit pouvoir dire ce que le système a fait, sur quelles données, sous quel contrôle humain, et conserver de quoi le démontrer.

Ces exigences ne sont pas étrangères à ce qu’un commissaire aux comptes, un régulateur sectoriel ou un comité des risques demande déjà. L’AI Act les rend opposables dans un calendrier, avec un vocabulaire commun. Il ne crée pas, pour autant, l’obligation de geler les projets le temps de rédiger une doctrine. Il crée l’obligation que les projets qui restent en production soient documentables.

La lecture utile pour une direction est donc celle-ci : le règlement ne tranche pas entre « innover » et « se conformer ». Il distingue les systèmes dont on peut montrer le fonctionnement, et ceux dont on ne le peut pas. Les seconds deviennent chers, puis intenable. Les premiers continuent.

Il faut aussi éviter un malentendu fréquent. Produire un rapport annuel de conformité, un registre des systèmes d’IA, une politique IA signée du COMEX, ce n’est pas satisfaire l’exigence de logs et de surveillance humaine. Ces documents sont des enveloppes. L’auditeur, lorsqu’il viendra, ouvrira un cas. Il voudra le run. Si le run n’a pas de dossier, l’enveloppe ne le remplace pas.

Les systèmes concernés

Tous les agents internes ne tombent pas dans la catégorie haut risque. Un assistant de synthèse pour un usage de confort, sans effet sur des personnes ou sur des obligations réglementées, n’appelle pas le même régime. Un système qui oriente un crédit, un recrutement, un scoring d’assurance, un contrôle d’accès, ou qui alimente une information financière contrôlée, s’en rapproche ou y entre, selon les annexes et les lectures sectorielles.

L’erreur de cadrage consiste à attendre une qualification juridique définitive avant de documenter quoi que ce soit. La qualification peut être discutée. La documentation d’un run, elle, est utile indépendamment de la case cochée dans l’annexe. Si le système n’est pas haut risque, le dossier reste un actif d’audit interne, de qualité, de réemploi. S’il l’est, le dossier est déjà là. Attendre la qualification pour commencer à tracer, c’est accepter de tracer sous contrainte de calendrier.

Une cartographie des usages reste nécessaire. Elle n’est pas un livrable de fin de projet. Elle est un inventaire vivant : quel rituel, quel effet, quelles données, quel signataire. Le diagnostic de fragmentation des usages IA : dix questions, un indice, des priorités : n’est pas un substitut à l’analyse juridique. Il donne un ordre de travail. On documente d’abord ce qui entre dans un comité, ce qui produit un chiffre publié, ce qui touche un tiers. On ne commence pas par l’usage le plus spectaculaire en démonstration.

Les fournisseurs de modèles ne portent pas cette cartographie à la place du déployeur. Le règlement distingue des rôles (fournisseur, déployeur, etc.). L’organisation qui met le système dans son rituel de décision est déployeur. C’est elle qui doit pouvoir montrer la surveillance humaine et les logs d’utilisation. S’en remettre au contrat du modèle pour « la conformité AI Act » est une confusion de rôles. Le contrat peut aider. Il ne signe pas à la place du comité.

Le coût de la mise en conformité rétroactive

Revenir sur un an de production pour reconstituer des logs, des versions, des validations, c’est le scénario le plus coûteux. Les données d’entrée ont bougé. Les prompts aussi. Les personnes ont changé d’affectation. On produit alors des dossiers approximatifs, des attestations, des revues par échantillon. L’autorité, ou l’auditeur interne, y verra ce qu’elles sont : des approximations.

Le coût n’est pas seulement financier. C’est un coût de stop-and-go. Les projets sont gelés le temps d’une task force. Les métiers perdent confiance dans l’outil, parce que l’outil devient synonyme de chantier juridique. Les équipes data sont extraites de la production pour écrire des mémoires. On paie deux fois : une fois le déploiement sans preuve, une fois la preuve sans déploiement.

Les organisations qui choisissent ce chemin le font rarement par insouciance. Elles le font parce que le critère de go-live n’incluait pas le dossier. Le go-live mesurait la qualité de la sortie, pas l’opposabilité de la sortie. L’AI Act, comme l’audit financier, inverse le critère. Une sortie non documentable n’est plus un succès. C’est un passif.

Il n’est pas raisonnable de promettre qu’une mise en conformité rétroactive est impossible. Elle est possible, mal, et cher. Le point de décision pour un COMEX n’est pas « peut-on s’en sortir ». C’est « veut-on payer le prix fort pour des runs déjà exécutés, ou produire le dossier sur les runs suivants, tout de suite ». Les runs suivants arrivent chaque jour. Chaque jour sans preuve native allonge la zone rétroactive.

La documentation par construction

La documentation par construction, c’est l’inverse du mémoire. Chaque exécution émet ses artefacts : sources, traitement versionné, statut de supervision humaine, identifiant de rejeu. L’Audit Pack n’est pas rédigé. Il est exporté. Le registre des usages s’alimente des runs, pas d’un tableur tenu à jour par un stagiaire conformité.

Cette approche n’arrête pas les projets. Elle change le critère d’achèvement. Un rituel n’est pas en production lorsqu’il produit un texte acceptable. Il l’est lorsqu’il produit un texte acceptable et un dossier. Les deux naissent ensemble. Le délai supplémentaire, si le système est conçu pour, se mesure en secondes d’écriture d’artefacts, pas en mois de programme de conformité.

Les équipes qui objectent que « la documentation va tuer l’agilité » décrivent en réalité une documentation séparée du run : un Word à remplir, un workflow parallèle, un comité ad hoc. Cette documentation-là, effectivement, ralentit. La documentation attachée au run ne ralentit que si l’on force l’humain à saisir ce que le système peut émettre tout seul. Le travail humain utile, dans ce régime, n’est pas de remplir des champs. C’est de valider, ou de refuser, en voyant la preuve.

Répondre à l’AI Act sans arrêter ses projets, c’est donc un choix d’architecture d’exécution, pas un choix de calendrier politique. On peut publier une doctrine, nommer un référent, commander un gap analysis. Tant que le run ne produit pas le dossier, le gap analysis se reproduira. Tant que le run le produit, le gap analysis a déjà sa pièce maîtresse. Le reste : qualification, annexes, dialogues avec les autorités : s’appuie sur des faits. Les faits, ici, sont des exécutions tracées. Pas des intentions.

La discipline consiste à ne pas geler les rituels déjà documentables pour attendre une doctrine parfaite, et à ne pas lancer de nouveaux rituels à enjeu sans cette maille. Les deux erreurs se valent : l’une arrête ce qui pourrait déjà produire un dossier, l’autre allonge la zone rétroactive. Un diagnostic de fragmentation aide à ordonner. Il ne remplace pas le premier run qui émet ses artefacts. C’est ce run-là, répété, qui constitue la réponse opérationnelle au règlement.