Audit EU AI Act : votre runtime d'IA peut-il produire les preuves ?

En bref : Un audit ne porte pas sur votre modèle ; il vérifie si votre runtime peut montrer qui a autorisé chaque action d’IA, ce qu’elle a modifié et où se trouvent les preuves — et l’auditabilité ne se rajoute pas après coup, elle ne s’enregistre qu’au fil de l’eau.

Imaginez une salle de réunion.

Une compagnie d’assurance opérant en Europe a fait appel à un auditeur externe pour une répétition de conformité à l’AI Act. L’auditeur s’assoit, ouvre son ordinateur, sans civilités, et pose sa première question :

« Sortez-moi le déroulé complet de ce sinistre que l’IA a automatiquement signalé le mois dernier comme « à risque de fraude élevé » et qui a donc été refusé — qui l’a déclenché, sur quelles données l’IA s’est-elle appuyée, quelle règle a été appliquée, qui a contrôlé, et par quelle procédure la réclamation du client est-elle passée. »

Puis la salle se tait.

Non pas parce que ce refus était forcément une erreur, mais parce que la part de cette décision où l’IA est intervenue n’a, dans le système, aucun endroit complet, continu et non répudiable d’où l’extraire. Les données du sinistre sont dans un système, le service de scoring de l’IA dans un autre, l’enregistrement du contrôle dans un troisième — et tout cela ne figure pas dans le même registre que les opérations humaines. Pour reconstituer la trace demandée par l’auditeur, il faudrait que trois équipes épluchent trois jours de logs, sans garantie d’aboutir.

Cette entreprise n’a pas été sanctionnée à ce moment-là — ce n’était qu’une répétition. Mais les sanctions de l’AI Act pour les systèmes d’IA à haut risque se calculent en pourcentage du chiffre d’affaires mondial, un ordre de grandeur suffisant pour que n’importe quelle entreprise prenne la chose au sérieux. Et le problème exposé par la répétition est celui que le vrai audit reposera, à l’identique, quelques semaines plus tard.

Cette salle de réunion silencieuse, c’est la scène à laquelle de nombreuses entreprises vont être confrontées en 2026.

Le compte à rebours est réel

L’EU AI Act transforme progressivement l’auditabilité, la supervision humaine et la gouvernance des données en exigences opérationnelles. Les discussions européennes sur la souveraineté cloud et IA vont dans la même direction : pour les entreprises présentes en Europe ou servant des clients européens, il ne suffit plus de choisir un bon modèle ; il faut pouvoir prouver comment chaque action a été autorisée et enregistrée.

Le point le plus cinglant n’est pas une amende théorique. C’est cette question très simple : si un audit indépendant arrivait maintenant, sauriez-vous sortir le déroulé complet d’une action IA précise, sans le reconstruire à la main ?

L’audit ne porte pas sur le modèle, mais sur le runtime

La première chose que beaucoup d’équipes font pour la conformité est d’évaluer le modèle — a-t-il des certifications, peut-il produire des contenus nuisibles. C’est important, mais ce n’est pas le terrain principal de l’audit. Ce que le régulateur veut vraiment, c’est que vous puissiez établir trois choses pour chaque action où l’IA touche au métier :

Ce que l’auditeur demande	Ce qu’il vérifie	Conséquence si vous ne savez pas répondre
Ces données sont-elles traitées légalement ?	Où sont les données, qui peut les lire, sont-elles sorties de l’UE	Violation de résidence des données, exposition au CLOUD Act
Qui a autorisé l’IA à faire cette action ?	Sous quelle permission comptent les actions comme refuser un sinistre, débloquer un prêt	Responsabilité non attribuable, action incontrôlable
L’étape impliquant l’IA a-t-elle laissé une trace ?	Pouvez-vous produire une chaîne de preuves complète et non répudiable	Échec direct de l’audit

Aucune de ces questions ne porte sur le modèle. Toutes portent sur la couche au-delà du modèle — le runtime qui porte les données, applique les permissions, enregistre les preuves.

Ce que l’AI Act exige vraiment des « systèmes à haut risque »

Ce n’est pas un abstrait « il faut se conformer ». L’AI Act énumère nommément, pour les systèmes d’IA à haut risque (sinistres, crédit, recrutement, infrastructures critiques, ce genre), plusieurs obligations dures qui méritent d’être confrontées point par point — car elles tombent presque toutes sur le runtime, pas sur le modèle :

Exigence de l’AI Act	Sur quelle couche elle tombe	Le modèle peut-il la fournir
Journalisation automatique des événements (traçable)	Le journal d’audit du runtime	Non, le modèle ne laisse pas de trace
Supervision humaine (décisions clés interceptables, révocables)	Validation et processus du runtime	Non, cela doit être imposé par le processus
Décision explicable (sur quoi elle s’appuie)	Entrées et règles enregistrées par le runtime	Partiellement, mais l’enregistrement non répudiable est dans le runtime
Gouvernance des données (origine, permissions, résidence)	Permissions et déploiement du runtime	Non

Vous constaterez que, si puissant soit-il, le modèle ne peut cocher aucune case de ce tableau. C’est précisément la cause profonde de ces nombreuses équipes qui « ont choisi le modèle avec grand soin, mais échouent à la conformité » — elles s’échinent sur la mauvaise couche. Ce que le régulateur exige pousse, structurellement, sur le runtime.

Il suffit d’acheter un outil de conformité, non ?

La réaction la plus naturelle est : il y a tout un marché de « plateformes de conformité à l’AI Act », les fournisseurs vantent tous leur conformité, on signe un DPA, on obtient une certification, et le tout est externalisé, non ?

Cette voie résout une partie du problème, mais pas celui de cette salle de réunion.

Les outils et certifications de conformité font de l’enregistrement et de l’attestation : ils disent au régulateur « nous avons des processus, de la documentation, des accords de traitement des données ». Mais ce que l’auditeur veut, ce n’est pas « avez-vous des processus », c’est « sortez-moi le déroulé complet de cette opération précise ». La documentation ne prouve pas la légalité d’une action précise, et un DPA ne répond pas non plus à « sur quelle permission l’IA s’est-elle appuyée pour ce refus, et qui l’a contrôlé ». Ce type de preuve ne peut être enregistré qu’au moment même où l’action se produit, par le runtime qui exécute réellement cette action. Acheter un outil aide à maîtriser la « couche des règles institutionnelles », pas la « couche des actions » — or l’audit, en remontant jusqu’au bout, finit toujours par interroger une action précise.

L’auditabilité ne se rattrape pas

D’où une vérité dure que beaucoup n’ont pas réalisée : la conformité n’est pas un document que vous bouclez au troisième trimestre, mais une propriété qu’un système possède ou ne possède pas.

Cette chaîne de preuves que l’auditeur réclame doit être enregistrée à l’instant même où l’action se produit. Si le runtime ne l’a pas enregistrée alors, aucun coup de force avant août ne fera surgir le déroulé réel de cette remise du mois dernier — vous ne pourrez que « reconstruire », et un enregistrement reconstruit, l’auditeur sait d’un coup d’œil qu’il n’est pas recevable.

C’est pourquoi « déployons l’IA d’abord, on verra la conformité plus tard » est un pari dangereux : vous pariez que l’audit ne posera pas de questions sur les actions qui n’ont pas été enregistrées sur le moment. Une fois la question posée, les décisions de l’IA sur cette période deviennent difficiles à étayer autrement que par reconstruction.

Avant d’entrer dans la salle d’audit, auto-diagnostiquez-vous avec ces cinq questions — pour toute réponse autre que « oui », ce point est votre zone de risque :

Prenez au hasard une action métier impliquant l’IA : pouvez-vous en sortir le déroulé complet sur-le-champ ?
Les permissions sont-elles imposées par le runtime, ou écrites dans le prompt ?
Les actions humaines et celles des agents sont-elles consignées dans le même journal d’audit ?
Ces données et ces traitements relèvent-ils de quelle juridiction ?
En cas de problème, pouvez-vous arrêter d’un clic un agent ou une catégorie d’actions ?

Pourquoi « écrire les règles dans le prompt » ne passe pas cette épreuve

Bien des équipes ont en fait mis en place une gouvernance, mais au mauvais endroit — dans le prompt. « Tu ne peux interroger que les données auxquelles l’utilisateur courant a accès », « les sinistres à haut risque exigent un contrôle humain » : au quotidien, ça paraît même fonctionner. Mais ça ne passe pas l’audit, pour deux raisons toutes deux fatales :

Premièrement, le prompt est une suggestion, pas un contrôle. Il n’opère que si le modèle « veut bien obéir » ; un jailbreak, un cas limite non couvert, et il est contourné. Quand l’auditeur demande « comment garantissez-vous qu’une certaine catégorie de sinistres passe forcément par un contrôle humain », « on l’a écrit dans le prompt » n’est pas une réponse que l’on peut signer.

Deuxièmement, le prompt ne produit pas d’enregistrement. L’audit veut une preuve structurée et non répudiable ; le prompt ne peut la fournir.

Ce que la conformité exige vraiment, c’est de déplacer la gouvernance d’une « suggestion dans le prompt » à une « contrainte dans le moteur d’exécution » — les permissions vérifiées par le runtime à chaque lecture/écriture, l’audit étant un sous-produit naturel de l’action.

Après le CADA, « où sont les données » devient un critère dur — mais l’auto-hébergement n’est pas une absolution

Le CADA met une autre chose sur le devant de la scène : la souveraineté des données. Au fond, il demande sous quelle juridiction se trouvent vos données et les traitements de l’IA. Cette question pointe directement vers la forme de déploiement. Confier le runtime d’IA qui lit de vraies données métier à un SaaS externe dont vous ne pouvez inspecter l’intérieur et qui relève du CLOUD Act devient, sous le nouveau cadre, de plus en plus difficile à signer. L’auto-hébergement améliore d’un coup la résidence des données, l’exposition aux tiers et la visibilité — et ce qu’il faut auto-héberger n’est pas forcément le modèle, mais le runtime qui porte les objets, les permissions, les outils, les validations et les preuves d’audit.

Mais soyons honnêtes : l’auto-hébergement n’est pas une absolution, c’est une transaction. Quand le runtime tourne sur votre propre infrastructure, appliquer les correctifs, faire tourner les clés, garantir que les logs ne se perdent pas, couper le circuit d’un clic en cas d’incident — ces opérations et cette charge de la preuve vous reviennent aussi. Ce que vous gagnez, c’est le contrôle ; le prix, c’est la responsabilité. À l’inverse, si vous souhaitez que quelqu’un d’autre porte cette responsabilité à votre place, cela implique généralement de lui confier aussi les données. Aucun des deux plateaux n’est gratuit ; tout est de savoir quel prix vous pouvez assumer et signer.

À quoi ressemble un runtime qu’on peut signer

Renversez les exigences ci-dessus, et vous obtenez la liste de recette. Le test le plus direct n’est pas de regarder la fiche produit, mais de voir s’il peut recracher, sur-le-champ, l’enregistrement que l’auditeur réclame. Sur ObjectOS, le refus de sinistre du début se sort sous cette forme :

{
  "event": "claim.decision.update",
  "actor": { "type": "agent", "on_behalf_of": "user:risk.bot.supervised" },
  "object": "ins_claim/CLM-88231",
  "decision": { "from": "pending", "to": "rejected", "reason_code": "fraud_high" },
  "model_evidence": ["device_mismatch", "velocity_anomaly"],
  "permission_checked": "claims_adjuster → allowDecide: true",
  "human_review": { "rule": "fraud_high → contrôle humain obligatoire", "by": "user:wang.adjuster", "at": "2026-05-12T09:40:55Z" },
  "timestamp": "2026-05-12T09:31:02Z"
}

Dans cet enregistrement : qui, a fait quoi, sur quoi l’IA s’est appuyée, quelle permission a été touchée, qui a contrôlé, et quand — tout y est. Ce n’est pas de l’ingénierie ajoutée après coup, c’est une trace que le runtime pose au passage lorsque l’agent, sous une identité supervisée, appelle un outil gouverné. Humains et agents passent par le même moteur de permissions et consignent dans le même journal. La définition métier (objets, permissions, processus de contrôle) est, quant à elle, une métadonnée diffable et traçable dans votre dépôt — quand l’auditeur demande « quelle catégorie de sinistres exige un contrôle humain obligatoire », la réponse n’est pas dans la tête de quelqu’un, elle est écrite dans la définition du processus.

Conclusion

Il ne reste que quelques semaines avant août. Revenons à cette salle de réunion : si l’auditeur s’asseyait maintenant et vous réclamait le déroulé complet d’une décision d’IA du mois dernier, votre système pourrait-il le recracher à cet instant, sans que trois équipes épluchent trois jours de logs ?

Ne pas savoir répondre n’est presque jamais dû à un modèle défaillant, mais à une gouvernance placée sur la mauvaise couche — mise dans le prompt, externalisée dans des documents institutionnels, plutôt que tombée dans le runtime. Remettez-la dans le runtime, et cette chaîne de preuves sera déjà là avant que vous en ayez besoin. Cette chose ne se rattrape pas ; il faut la rendre effective dès maintenant.

npm i -g @objectstack/cli && os start

Faites qu’un agent, sous l’identité d’un utilisateur, modifie une donnée, puis ouvrez le journal d’audit — vous verrez que la trace que l’auditeur réclame y était déjà.