AI Act controls requirements : 8 garde-fous opérationnels pour un déploiement IA conforme

Les AI Act controls requirements — les exigences de contrôle imposées par le règlement européen — ne sont pas optionnelles pour les systèmes à risque limité ou élevé. Mettre en production sans ces garde-fous formalisés expose l’organisation à deux risques simultanés : une non-conformité réglementaire et une incapacité à produire des preuves d’audit en moins de 48 heures. Ce constat est partagé par la majorité des équipes accompagnées en 2024-2025 — les contrôles existent, mais ils sont fragmentés, non documentés, et jamais testés ensemble.

Ce que l’AI Act impose concrètement : les AI Act controls requirements en pratique

Le Règlement européen sur l’intelligence artificielle (AI Act, Règlement UE 2024/1689) ne se limite pas à des obligations de transparence ou de documentation. Il impose des contrôles techniques et organisationnels précis, vérifiables lors d’un audit réglementaire. Ces exigences s’appliquent différemment selon le rôle : fournisseur de modèle GPAI, fournisseur de système à haut risque, ou déployeur.

Pour les systèmes classifiés à haut risque — systèmes utilisés en RH, crédit, santé, infrastructure critique — huit domaines de contrôle sont explicitement requis. Ce n’est pas une liste de bonnes pratiques. C’est le socle minimum pour passer un contrôle réglementaire ou une due diligence.

Prenons le cas de Mathieu FOREST, RSSI chez IndusTech SA (industrie manufacturière, plusieurs milliers de salariés, implantation européenne). En octobre 2024, l’équipe a déployé un assistant IA interne pour la qualification des incidents de maintenance. Six mois plus tard, face à une demande d’audit préliminaire d’un grand client, l’équipe a constaté que trois des huit contrôles requis n’existaient pas : pas de traçabilité des décisions du système, pas de procédure de signalement d’incident, aucune formation formalisée pour les opérateurs qui validaient les suggestions du système. Le client a suspendu le contrat le temps de la mise en conformité. Ce cas illustre une réalité documentée : le problème n’est pas l’absence de volonté, c’est l’absence de méthode structurée.

Ce que font les équipes qui respectent les AI Act controls requirements sans bloquer l’innovation

Les organisations qui réussissent à déployer des systèmes IA conformes sans ralentir leur cadence de mise en production partagent une approche commune : elles traitent les huit contrôles comme une infrastructure, pas comme une contrainte ponctuelle. Ces garde-fous sont intégrés dès la conception, pas ajoutés après coup.

Voici les huit contrôles que l’AI Act rend obligatoires pour les systèmes à risque :

1. Supervision humaine effective. L’AI Act exige que la supervision soit prouvable, pas seulement déclarée. Cela signifie des logs d’intervention humaine, des procédures documentées définissant quand un opérateur peut outrepasser le système, et une traçabilité des décisions finales. Une validation par clic sans compréhension du contexte ne constitue pas une supervision effective au sens réglementaire.

2. Traçabilité OpenTelemetry GenAI. Le standard OpenTelemetry GenAI Semantic Conventions est devenu la référence technique pour la journalisation des systèmes LLM. Selon le NIST AI RMF, l’objectif recommandé est une couverture de 99,5 % des appels au modèle : chaque requête, chaque réponse, chaque décision doit être tracée et archivée avec horodatage immuable.

3. Guardrails entrées/sorties. Deux catégories de filtres sont requises : prévention des injections de prompt (manipulation du système via des entrées malformées) et détection des données personnelles en sortie (PII leak). Ces guardrails doivent être testés régulièrement et leurs logs conservés.

4. Surveillance post-marché. L’AI Act impose un mécanisme de détection et de signalement des incidents. La norme de fait dans les organisations conformes : tout incident critique doit être qualifié et signalé en moins de 72 heures. Le cadre NIST AI RMF propose une taxonomie d’incidents compatible avec les exigences européennes.

5. Formation des rôles critiques. Les opérateurs, superviseurs et administrateurs des systèmes IA à haut risque doivent recevoir une formation documentée sur le fonctionnement du système, ses limites, et les procédures d’intervention. Cette formation doit être tracée — attestations, dates, contenus — et revue lors des mises à jour majeures du modèle.

6. Provenance et traçabilité des médias. Pour les systèmes qui génèrent ou manipulent du contenu multimédia, le standard C2PA (Coalition for Content Provenance and Authenticity) ou équivalent permet de certifier l’origine des contenus. La Commission européenne s’appuie sur des mécanismes similaires pour les documents officiels dans le cadre réglementaire IA.

7. Cycle de changement avec tests pré-déploiement. Toute mise à jour du modèle, du prompt système, ou du pipeline de données doit passer par un cycle formalisé : test de régression, validation des guardrails, approbation documentée. Un changement non documenté est un changement non auditable.

8. Registre IA versionné. Le registre centralise la liste complète des systèmes IA actifs, leur classification de risque, leur propriétaire, et leur base légale de traitement. C’est le point d’entrée de tout audit réglementaire. Un système absent du registre est, du point de vue réglementaire, un système non autorisé.

Erreurs classiques dans la mise en place des contrôles AI Act

• Confondre supervision déclarée et supervision prouvable. Cocher une case « validation humaine » dans un workflow ne suffit pas. L’AI Act exige que la supervision soit démontrable : qui a validé, quand, avec quelle information disponible. Sans log d’intervention, la supervision n’existe pas aux yeux d’un auditeur.
• Déployer les guardrails sans les tester. Les équipes installent des filtres d’entrée/sortie mais ne les testent jamais sous charge réelle ou avec des entrées adversariales. Un guardrail non testé est un guardrail dont l’efficacité est inconnue — ce qui est précisément ce que l’AI Act veut prévenir.
• Traiter le registre IA comme un document statique. Le registre doit être mis à jour à chaque déploiement, chaque modification majeure, chaque décommissionnement. Un registre qui date de six mois est probablement inexact — et inexploitable lors d’un audit réglementaire.

Par où commencer : 3 actions prioritaires pour mettre en conformité votre déploiement IA

La mise en place des huit AI Act controls requirements ne se fait pas en une semaine. Voici les trois premières actions à fort levier pour les organisations qui débutent leur chantier de conformité réglementaire :

Action 1 — Auditer les contrôles existants contre les AI Act controls requirements. Avant de construire quoi que ce soit, cartographier l’état actuel : quels contrôles existent, sous quelle forme, avec quel niveau de documentation. Ce diagnostic prend entre deux jours et deux semaines selon la taille du portefeuille IA. C’est le prérequis à tout plan de mise en conformité structuré.

Action 2 — Implémenter OpenTelemetry GenAI sur les systèmes prioritaires. La traçabilité est le contrôle qui débloque tous les autres : sans logs structurés, il est impossible de démontrer la supervision humaine, de détecter les incidents, ou de valider les guardrails. Commencer par les systèmes classifiés à risque élevé ou limité déjà en production.

Action 3 — Formaliser le registre IA avec propriétaires et bases légales. Désigner un propriétaire pour chaque système IA actif, documenter la base légale de traitement, et établir une procédure de mise à jour trimestrielle. Ce registre est le document le plus demandé lors d’un contrôle réglementaire ou d’une due diligence client — et souvent le plus difficile à reconstituer en urgence.

Le Chapitre 14 du Tome 3 de Réussir l’IA en entreprise 2026 (Franck Lavoyer) traite chacun de ces huit contrôles avec son standard technique de référence, les SLO cibles mesurables et les runbooks d’implémentation testés sur des déploiements réels en entreprise. Ce tome accompagne les équipes techniques et conformité qui veulent transformer leurs opérations quotidiennes — logs, traces, décisions humaines — en preuves d’audit vérifiables, sans créer une bureaucratie parallèle qui ralentit les équipes produit.