EU AI Act au 2 août 2026 : la stack MLOps de conformité

Le 2 août 2026, les obligations principales de l'EU AI Act deviennent applicables aux systèmes d'IA en production sur le marché européen. Et ça se traduit en chiffres très concrets : jusqu'à 15 M€ d'amende ou 3 % du chiffre d'affaires mondial annuel par infraction. Pour la plupart des équipes qui ont déployé des agents IA en 2024-2025, l'échéance se rapproche plus vite que la stack outillage ne se met en place.

LangChain a publié le 27 avril dernier un mapping détaillé entre sept articles du règlement et les capacités MLOps qui les couvrent. C'est un cadre utile, indépendamment du choix d'outil — parce qu'il révèle ce qui doit être en place, pas qui le fournit. On vous donne la lecture pratique pour une équipe qui doit livrer une preuve de conformité avant l'été.

Le contexte et les sept articles qui obligent un changement d'outillage

L'AI Act est entré en vigueur en août 2024 mais ses obligations s'activent par paliers. Le 2 août 2026 marque l'application des articles 9 à 15 et 72, qui couvrent les systèmes d'IA classés "à haut risque". Cette catégorie inclut beaucoup de cas d'usage agent IA aujourd'hui en production : scoring de crédit, dispositifs médicaux, recrutement, identification biométrique, infrastructures critiques, application de la loi, finance et santé, RH, manufacturing.

Si votre agent fait partie d'un de ces flux — même indirectement — vous tombez sous le régime à haut risque. Et le calendrier ne souffre pas de tolérance : passé le 2 août, c'est un risque réel, pas un risque théorique. Les amendes pour non-conformité grave plafonnent à 15 M€ ou 3 % du CA mondial, montant le plus élevé. Pour comparaison, le maximum RGPD est 20 M€ ou 4 % — ordre de grandeur similaire, philosophie différente.

Voilà la cartographie courte, dans l'ordre du règlement :

• Article 9 — Système de gestion des risques : risque géré tout au long du cycle de vie, pas un audit annuel ponctuel
• Article 10 — Gouvernance des données : examen du biais sur des dimensions protégées (race, genre, âge, religion, nationalité, handicap, orientation sexuelle)
• Article 12 — Logging automatique : traces d'événements horodatées, conservées sur la durée de vie du système
• Article 13 — Transparence et interprétabilité : sortie compréhensible pour l'utilisateur, niveau de précision déclaré
• Article 14 — Supervision humaine : capacité d'intervention, override, interruption à tout moment
• Article 15 — Robustesse et précision : métriques d'exactitude, résilience adversariale, cohérence
• Article 72 — Surveillance post-déploiement : monitoring actif après mise en production

Sept articles, sept exigences distinctes. Aucune ne se règle "au déploiement" — elles décrivent toutes des capacités opérationnelles continues.

Observabilité : la fondation des articles 12 et 72

L'article 12 demande explicitement un journal d'événements automatique sur la durée de vie du système. En pratique, ça veut dire tracer chaque appel LLM avec :

• Inputs et outputs textuels
• Horodatage à la milliseconde
• Métadonnées structurées : utilisateur, modèle, version, contexte de session
• Chaîne d'appels d'outils (tool calls) avec résultats
• Étapes de raisonnement intermédiaires

C'est exactement ce que produit un outil de tracing comme LangSmith, mais aussi un setup OpenTelemetry custom. La question pratique côté MLOps : combien de temps conserver ces traces ? La réponse n'est pas dans le règlement directement, mais le considérant 73 invite à une rétention "raisonnable" alignée sur la durée de vie du système. LangSmith propose 14 jours en base et 400 jours en extended ; pour un système à haut risque, viser au moins 12 mois de rétention auditable est une lecture prudente.

L'article 72 (surveillance post-déploiement) ajoute une couche : ne pas se contenter de logger, réagir aux dérives. Évaluateurs en ligne sur un échantillon de production, alerting sur un PagerDuty, dashboard de drift. C'est la même logique qu'un SRE sur un service web, transposée à des métriques modèle (perplexité, taux de hallucination, taux d'usage de PII).

Évaluation continue : biais, robustesse, hallucinations

Les articles 10 et 15 demandent de mesurer activement la qualité du système, pas juste de logger. Trois familles d'évaluateurs deviennent obligatoires en pratique :

Biais et équité (Article 10)

Évaluation du comportement sur les axes protégés cités par le règlement. Concrètement : un dataset de tests stratifié par race, genre, âge, religion, nationalité, handicap, orientation sexuelle, et un score de parité à publier. Si votre agent prend des décisions de scoring de crédit ou de recrutement, c'est non-négociable.

Robustesse adversariale (Article 15)

Détection de prompt injection et de jailbreak. Tests de bout en bout sur des payloads malicieux. Le règlement ne donne pas de seuil chiffré, mais l'absence totale de défense documentée est indéfendable en audit.

Sécurité du contenu (Articles 13 et 15)

Hallucination, fuite de PII, contenus toxiques, contenus explicites, code injection. Les évaluateurs out-of-the-box des plateformes MLOps couvrent ces axes ; les écrire à la main reste possible mais rallonge le calendrier de plusieurs semaines.

La supervision humaine : nouvelle norme opérationnelle (Article 14)

L'article 14 est probablement celui qui change le plus les architectures déjà déployées. Il exige une capacité d'intervention, d'override et d'interruption par un humain, avec compréhension claire de ce qui se passe. Pour un agent qui tourne en boucle fermée, ça implique :

• Un point d'arrêt programmable à n'importe quel nœud du graphe d'exécution
• Une file de revue humaine où des sessions sont routées pour annotation
• Un webhook d'escalade quand un score d'évaluation dépasse un seuil

Le primitive interrupt de LangGraph couvre ce besoin, comme le mécanisme HumanLayer ou le pattern checkpoint des frameworks équivalents. Côté implémentation, l'angle subtil est l'exactly-once execution : il faut pouvoir reprendre exactement où l'agent s'était arrêté, sans rejouer les side-effects (création de tickets, envoi d'emails, écritures DB). C'est la couche qui distingue un prototype d'un système conforme.

Ce que ça change pour les équipes IA

Trois actions concrètes à mener avant fin juin pour être prêt au 2 août :

1. Auditer l'existant. Listez vos systèmes en production et classifiez-les contre la grille à haut risque de l'AI Act. La plupart des équipes découvrent qu'au moins un de leurs agents tombe dans le scope sans qu'elles s'en soient rendu compte. Une fois la liste posée, mappez chaque système contre les 7 articles ci-dessus et identifiez les trous. C'est un exercice de 2-3 jours bien fait.

2. Choisir entre stack intégrée et stack assemblée. Une plateforme comme LangSmith couvre les 7 articles d'un coup ; une stack maison (OpenTelemetry + Pydantic evals + Argilla pour annotation + PagerDuty) demande 3-6 mois pour atteindre le même niveau de couverture. Pour qui n'a pas commencé, l'arbitrage en mai 2026 penche fortement vers l'intégré ; pour qui a déjà investi, l'enjeu est de combler les manques sans tout réécrire.

3. Préparer la documentation d'audit dès maintenant. Le règlement demande une trace écrite des choix techniques : pourquoi tel évaluateur, pourquoi tel seuil, pourquoi telle politique de rétention. Cette doc est l'évidence en cas de contrôle. Tenir un journal de décisions techniques sur Notion ou un ADR git versionné couvre le besoin sans complexité supplémentaire — à condition de commencer maintenant et pas en juillet.

L'AI Act n'est pas une tempête qui va passer. C'est le standard de fonctionnement pour les cinq prochaines années en Europe, et probablement la base sur laquelle d'autres juridictions vont caler leur propre cadre. La fenêtre pour mettre la stack en ordre est de trois mois. Au-delà, le risque devient financier et reputationnel, plus seulement opérationnel.

En bref

• 2 août 2026 : application des articles 9-15 et 72 de l'AI Act ; amende max 15 M€ ou 3 % du CA mondial
• Sept capacités MLOps à couvrir : risk mgmt continu, gouvernance données, logging auto, transparence, supervision humaine, robustesse, monitoring post-prod
• Observabilité = fondation : tracing complet (inputs/outputs/timestamps/metadata) + rétention min 12 mois pour les systèmes à haut risque
• Évaluateurs obligatoires : biais sur axes protégés, prompt injection, hallucination, PII leakage, contenus toxiques
• Supervision humaine = primitive d'interrupt + queue d'annotation + webhook d'escalade, avec exactly-once execution sur reprise
• Calendrier réaliste : audit (J), arbitrage stack (J+15), implémentation (J+60), doc d'audit en parallèle. Tout ça d'ici fin juin.

Vous industrialisez vos agents IA ? SeedVision propose des audits IA en 3-5 jours et des forfaits de mise en production de 15 à 30 jours. Voir les packages ou réserver un appel de 30 min.

Photo de couverture : Photo by 1981 Digital on Unsplash.