Les systèmes d'IA consignent des sorties. Les tribunaux réclameront des décisions.

Toute organisation qui déploie l'IA dans un domaine aux conséquences lourdes — crédit, droit, assurance, recrutement — constitue un journal d'audit. La plupart de ces journaux seront inutiles le jour où une décision sera contestée. Non pas parce qu'ils sont incomplets, mais parce qu'ils consignent la mauvaise chose.

L'infrastructure d'audit traditionnelle est conçue autour d'événements : une action a été menée, par un acteur déterminé, à un instant déterminé, produisant un changement déterminé dans l'état du système. L'invariant, c'est la possibilité de reconstitution. Si vous rejouez le journal des événements, vous pouvez reconstituer ce qui s'est passé. C'est ce qui confère à une piste d'audit sa portée juridique. Non pas le fait qu'elle existe, mais le fait qu'elle peut prouver quelque chose.

L'inférence d'une IA n'est pas un événement en ce sens. Une décision prise par une IA est une fonction. Elle prend des entrées et produit une sortie. La sortie n'est pas la décision — elle est le résultat de la fonction de décision appliquée à un ensemble déterminé d'entrées, dans des conditions déterminées. Si vous ne consignez que la sortie, vous avez enregistré la réponse sans enregistrer la question, le modèle qui y a répondu, le contexte qui lui a été fourni, ni les paramètres dans lesquels il a opéré. Vous disposez d'un reçu, pas d'une piste.

Les quatre entrées qui déterminent la décision

Une décision produite par un modèle de langage est déterminée par au moins quatre variables indépendantes.

L'entrée de l'utilisateur : le document, la requête ou l'invite soumis au moment de l'inférence. La plupart des organisations consignent cette donnée. C'est la plus facile.

L'invite système (system prompt) : les instructions qui encadrent le comportement du modèle, contraignent ses sorties et définissent son rôle dans la chaîne de traitement. Les invites système évoluent. Elles sont mises à jour silencieusement, sans gestion de versions, à mesure que les équipes affinent le comportement du modèle. Si vous ne pouvez pas restituer l'invite système exacte en vigueur au moment d'une inférence donnée, vous ne pouvez pas reconstituer ce qui avait été demandé au modèle.

La version du modèle : pas le nom du modèle. La version. « GPT-4 » n'est pas une version de modèle. Si un fournisseur met à jour un modèle derrière un point d'accès d'API stable — ce qui arrive — votre entrée de journal « GPT-4 » est compatible avec deux modèles distincts produisant deux sorties distinctes pour la même entrée. La décision n'est pas reconstituable.

Le contexte de récupération : si le système recourt à la génération augmentée par récupération (RAG), les documents récupérés font partie de la fonction de décision. Un index de récupération évolue dans le temps. Des documents sont ajoutés, dépréciés, redécoupés, ré-embarqués (re-embedded). Le résultat de récupération pour la même requête aujourd'hui n'est pas le même que le résultat de récupération d'il y a six mois. À moins que le contexte récupéré ne soit consigné au moment de l'inférence, la décision ne peut pas être reproduite.

L'absence de consignation ou de versionnement de l'une quelconque de ces variables rend la décision irrécupérable.

Pourquoi les journaux de sorties échouent au moment même où ils sont mis à l'épreuve

Le mode de défaillance est invisible en exploitation normale. Un journal de sorties fonctionne très bien pour la supervision, l'analytique et le débogage. Il échoue précisément quand vous en avez le plus besoin : lorsqu'une décision est contestée.

Imaginez le scénario. Une décision automatisée aux conséquences lourdes est contestée douze mois après avoir été prise. Le modèle a depuis été mis à jour. L'index de récupération a été rafraîchi. L'invite système a été révisée à deux reprises. Le contestataire demande, légitimement : que savait votre système lorsqu'il a pris cette décision, et pourquoi a-t-il tranché ainsi ?

Le journal de sorties répond : il a décidé ceci. Il ne répond pas : sur quelle base.

C'est là toute la différence entre la consignation et la responsabilité. Un journal vous dit ce qui s'est passé. Un registre de responsabilité (accountability record) vous dit pourquoi, sous une forme qui peut être vérifiée, reproduite et défendue. Les cadres réglementaires qui comptent commencent à faire respecter cette distinction, que les organisations y soient prêtes ou non.

Ce que les cadres réglementaires exigent réellement

L'article 12 du règlement européen sur l'IA (EU AI Act) impose que les systèmes d'IA à haut risque « permettent techniquement l'enregistrement automatique des événements (journaux) tout au long de la durée de vie du système », les capacités de journalisation étant calibrées pour garantir un niveau de traçabilité « adapté à la destination du système » (règlement (UE) 2024/1689, article 12, paragraphes 1 et 2). En vertu de l'article 22 du RGPD, toute personne a le droit de ne pas faire l'objet d'une décision fondée exclusivement sur un traitement automatisé — y compris le profilage — produisant des effets juridiques ou des effets significatifs similaires ; et lorsqu'un tel traitement est autorisé, l'article 22, paragraphe 3, lui ouvre droit à des garanties incluant l'intervention humaine, le droit d'exprimer son point de vue et le droit de contester la décision. Un « droit à l'explication » en tant que tel ne figure pas dans le texte de l'article 22, mais découle du considérant 71 (non contraignant) et des obligations de transparence des articles 13 à 15, qui exigent des « informations utiles concernant la logique sous-jacente ». Le cadre de gestion du risque de modèle de la PRA — la déclaration de surveillance SS1/23, « Model risk management principles for banks » — attend des établissements qu'ils tiennent une documentation suffisamment détaillée pour qu'un tiers indépendant puisse comprendre et reproduire les résultats d'un modèle, à l'appui de l'auditabilité et d'une gouvernance efficace des modèles.Sources : Règlement européen sur l'IA (EU AI Act), article 12 (Tenue de registres) — règlement (UE) 2024/1689 · RGPD, article 22 (texte intégral), gdpr-info.eu · Bank of England (PRA) — SS1/23, « Model risk management principles for banks »

Aucune de ces réglementations ne précise ce que la journalisation signifie sur le plan technique. Un tribunal ou un régulateur qui les interprète appliquera un critère téléologique : le journal permet-il de reconstituer et d'expliquer la décision ? Un journal de sorties ne satisfait pas à ce critère. Un journal « sortie + contexte + version du modèle » y satisfait.

La conséquence pratique est que les organisations qui bâtissent leur IA sur des API généralistes, sans engagement de versionnement ni journalisation de la récupération, accumulent une responsabilité invisible jusqu'à ce qu'une décision soit contestée — moment où les entrées nécessaires à la reconstitution n'existent plus.

À quoi ressemble réellement un journal permettant de reconstituer la décision

Le registre de responsabilité minimal viable pour une décision d'IA contient : une empreinte (hash) de l'entrée de l'utilisateur au moment de l'inférence ; l'invite système exacte en vigueur, versionnée et hachée ; un identifiant de modèle engageant des poids spécifiques — un identifiant de déploiement figé ou une référence d'instantané au niveau du fournisseur, et non un nom ; le contexte récupéré le cas échéant : identifiants des documents, empreintes du contenu et horodatage de la récupération ; les paramètres d'inférence : température, configuration d'échantillonnage, tout ce qui influe sur le caractère stochastique de la sortie ; la sortie, hachée et horodatée ; et la décision en aval, si la sortie alimente une étape fondée sur des règles ou revue par un humain.

Ce n'est pas un grand volume de données. Le contexte de récupération est la composante la plus volumineuse pour les systèmes RAG, mais il est borné par la fenêtre de contexte. Le reste relève des métadonnées. Le coût de leur conservation est négligeable au regard du coût de ne pas pouvoir les produire.

Le test

Si, à partir d'une entrée de journal, vous ne pouvez pas reproduire une décision d'IA — réinjecter les mêmes entrées dans la même version du modèle, avec la même invite système et le même contexte de récupération, et aboutir à la même sortie — alors votre journal n'est pas une piste d'audit. C'est un historique de sorties.

Les historiques de sorties sont utiles. Ils ne sont pas défendables.

Les organisations qui seront en position de force lorsque des décisions automatisées seront contestées ne sont pas nécessairement celles qui disposent des meilleurs modèles. Ce sont celles qui ont traité la journalisation comme un problème d'architecture décisionnelle dès le départ, avant que la moindre décision ne soit contestée.

Le moment de bâtir cette architecture, c'est avant le litige, pas après.