L'AI Act européen : checklist d'ingénierie

Les obligations à haut risque de l'AI Act devaient s'appliquer le 2 août 2026, et une proposition de la Commission européenne pourrait repousser une partie de ce calendrier jusqu'à décembre 2027. Dans tous les cas, rien de tout cela ne dit à un ingénieur quoi changer dans le code, alors ce billet le fait.

Les cabinets d'avocats vous donnent l'obligation. Je n'en ai pas trouvé un seul qui vous donne le diff. Voici la traduction : voici l'Article, voici ce que vous construisez.

Je peux l'écrire parce que j'ai livré deux fois de la conformité imposée par le code. Une fois on-chain, où ERC-3643 vérifie l'éligibilité du transfert dans le token. Une fois dans un fonds régulé, où un agent de recherche cite ses sources, s'abstient quand la preuve est mince, et journalise chaque étape. Les Articles ci-dessous correspondent à ce travail presque un pour un.

Deux fois où j'ai imposé la conformité par le code

Avant tout Article, une idée fait l'essentiel du travail : la conformité que vous imposez dans le code bat la conformité que vous promettez dans un document. Je l'ai construite ainsi deux fois, et les deux sont le modèle mental de la checklist.

La première fois que j'ai rendu une règle impossible à contourner, c'était on-chain : ERC-3643 impose l'éligibilité du transfert dans le token, soit le même réflexe que cette checklist applique à un système d'IA.

La checklist : de l'Article au changement de code

Voici la carte. La colonne de gauche est l'obligation, tirée des exigences à haut risque de l'AI Act (Règlement (UE) 2024/1689, Chapitre III, Section 2, plus l'Article 72 sur la surveillance). La colonne de droite est ce que cela signifie dans un dépôt de code.

Je ne vous dis pas si votre système est à haut risque. Cette classification dépend de l'Annexe III et c'est une question juridique pour un avocat qualifié. Ce que je peux faire, c'est vous montrer la construction une fois que quelqu'un vous dit que vous êtes dans le périmètre.

Source : AI Act (Règlement (UE) 2024/1689), Articles 9 à 15 et 72. Ceci associe des obligations à du travail d'ingénierie ; ce n'est pas une interprétation juridique du périmètre d'un système donné.

Article 12 : quoi journaliser vraiment

L'Article 12 est celui que les ingénieurs sous-estiment, car il se lit comme de la paperasse et c'est en réalité un schéma. Il exige qu'un système à haut risque enregistre automatiquement les événements sur toute sa durée de vie, pour qu'un incident puisse être reconstitué plus tard.

Le piège, c'est de journaliser la sortie. La sortie est la chose la moins utile à garder. Journalisez la décision : quel était le modèle, quelle version de prompt a tourné, quelle preuve il a vue, ce qu'il a choisi de faire, et si un humain y a touché. Voici l'enregistrement que je garde par action.

// One immutable record per agent action. Article 12 wants events
// reconstructable over the system's lifetime, so log the decision,
// not just the output.
interface AgentAuditRecord {
  runId: string             // ties every step of one task together
  timestamp: string         // ISO-8601, UTC
  actor: 'agent' | 'human'  // Article 14: who made this call
  modelId: string           // exact model + version behind the output
  promptVersion: string     // Article 11: the prompt is config, and it is versioned
  inputHash: string         // what the agent saw, without storing raw PII
  retrievedDocIds: string[] // Article 15 evidence: which sources grounded the answer
  decision: 'answer' | 'abstain' | 'escalate'
  citations: Citation[]     // the evidence behind an 'answer'
  humanReviewer?: string    // set when a person confirmed or overrode
  outcome: 'accepted' | 'overridden' | 'pending'
}

Lisez cet enregistrement au regard des Articles et il cesse d'être une seule obligation. Les champs promptVersion et modelId sont votre documentation technique de l'Article 11, générée au lieu d'être rédigée. Le champ decision, avec abstain et escalate comme valeurs de premier plan, plus humanReviewer, est votre piste de surveillance humaine de l'Article 14.

Les champs retrievedDocIds et citations sont votre preuve de justesse de l'Article 15 : la preuve que la réponse était étayée, pas devinée. Et parce que l'enregistrement est en ajout seul, un par action, tout le journal satisfait l'exigence de l'Article 12 par construction. Une structure de données, quatre Articles.

Article 14 : la surveillance humaine dans un pipeline RAG

La surveillance humaine est l'Article que l'on cite et que l'on lit de travers. L'Article 14 ne veut pas dire qu'une personne regarde un tableau de bord. Il veut dire que le système est conçu pour qu'une personne puisse le comprendre, le corriger et l'arrêter, et pour qu'il n'agisse pas seul là où il ne doit pas.

Dans un pipeline de recherche, c'est un design concret, pas une politique. L'agent ne répond qu'à partir de la preuve récupérée. Quand la preuve est mince, il ne produit pas une supposition assurée, il s'abstient et achemine le cas vers une personne. Une action qui déplace de l'argent ne s'exécute jamais toute seule ; elle attend qu'un humain signe.

Une action qui déplace de l'argent est précisément là où la surveillance doit s'imposer. J'ai écrit sur le versant confinement dans le moindre privilège pour les agents qui paient ; le même contrôle sert aussi de preuve pour l'Article 14.

Article 15 : comment prouver la justesse

L'Article 15 demande justesse, robustesse et cybersécurité, et il vous demande de déclarer les métriques de justesse. Les ingénieurs entendent << justesse >> et attrapent un pourcentage unique. C'est la mauvaise forme pour un agent autorisé à dire << je ne sais pas >>.

Le jeu de métriques honnête a plus d'un axe. À quelle fréquence une réponse assurée est correcte. À quelle fréquence l'agent s'abstient quand il le devrait. Comment il tient face à un red-team qui cherche à le faire mentir. Vous les déclarez, vous les mesurez avant la mise en production, et vous continuez à les mesurer en production.

L'Article 15 vous demande de déclarer la justesse et de l'étayer. Deux textes que j'ai déjà écrits font ce travail : les citations vérifiées et l'abstention en RAG pour le mécanisme, et la suite d'évaluations qui bloque une release pour les chiffres qui conditionnent une mise en production.

Ce que cela débloque

Faites cela et l'échéance cesse d'être une menace pour devenir une checklist que vous savez déjà cocher. La journalisation est un schéma. La surveillance humaine, quelques chemins de code. La justesse, une suite d'évaluations. Rien de tout cela n'est nouveau pour une équipe qui livre avec soin ; l'AI Act ne fait que le nommer et le dater.

Les équipes qui peinent sont celles qui traitent l'AI Act comme un document juridique à résumer. Les équipes qui le passent le traitent comme une spécification. Je le lis comme une spécification parce que j'avais implémenté les mêmes idées avant que la loi me le demande.

Cette checklist n'est qu'une page d'une carte plus large : comment je construis l'IA pour la finance régulée.

FAQ