AI Act : ce qu'il dit vraiment (et ce que vos équipes conformité sur-interprètent)

Le 2 août 2026 marque l'entrée en vigueur des obligations pour les systèmes à haut risque.Ou plutôt, c'était la date prévue. Le Digital Omnibus européen, dont le Conseil a adopté sa position le 13 mars 2026, propose un report à décembre 2027 pour les systèmes autonomes et août 2028 pour les systèmes embarqués.

Mise à jour du 18 mars 2026 : les commissions IMCO/LIBE du Parlement européen ont voté le report — Annexe III (systèmes autonomes) repoussé à décembre 2027, Annexe I (systèmes embarqués) à août 2028. Les trilogues sont prévus mars-avril 2026, adoption finale probablement en juin. Mais que le report soit adopté ou non, la plupart des entreprises ne sont pas prêtes — et pour les mauvaises raisons.Le problème n'est pas le manque de temps. C'est la sur-interprétation du texte qui paralyse les équipes.

Ce qui est déjà en vigueur

Depuis le 2 février 2025 :

• Les pratiques interdites sont sanctionnables — manipulation subliminale, exploitation de personnes vulnérables, scoring social, identification biométrique en temps réel dans les espaces publics
• L'obligation de littératie IA (Art. 4) — tous les opérateurs doivent s'assurer que leur personnel a une compréhension suffisante de l'IA

Depuis le 2 août 2025 :

• Les obligations pour les modèles à usage général (GPAI) — transparence, respect du droit d'auteur, et pour les modèles à risque systémique, évaluations de sécurité
• Le régime de sanctions est actif — les autorités nationales peuvent infliger des amendes
• Le Bureau de l'IA est opérationnel au niveau européen

À noter : en mars 2026, aucune amende n'a encore été prononcée sous l'AI Act. Mais ne vous y trompez pas — la CNIL a accumulé 486 millions d'euros d'amendes en un an au titre du RGPD. Comme l'a déclaré l'autorité : “la phase pédagogique est terminée.” La France a désigné la CNIL comme autorité nationale de l'AI Act le 12 février 2026. Le modèle français est décentralisé : CNIL (15 cas d'usage IA), DGCCRF (14), ARCOM (7), plus l'ANSM pour les dispositifs médicaux.

Les 3 sur-interprétations les plus courantes

1. “Chaque agent IA doit être inscrit au registre européen”

Ce que dit le texte (Art. 49) : Seuls doivent s'enregistrer :

• Les fournisseurs de systèmes à haut risque (avant mise sur le marché)
• Les fournisseurs qui déterminent que leur système Annexe III n'est pas à haut risque (Art. 6(3))
• Les déployeurs publics de systèmes à haut risque

Les déployeurs privés n'ont PAS d'obligation d'enregistrement.C'est une confusion fréquente. Et la grande majorité de vos agents — résumés, rédaction, recherche, automatisation bureautique — ne sont même pas à haut risque.

2. “Un humain doit valider chaque action de chaque agent”

Ce que dit l'article 14 : Les systèmes à haut risque doivent permettre une supervision humaine “effective” — la capacité d'intervenir et de comprendre le système.

L'article 14 ne demande PAS :

• Un humain qui approuve chaque output
• Un “human-in-the-loop” littéral pour chaque décision
• Que la supervision humaine seule élimine tous les risques

Le human-on-the-loop est parfaitement compatible avec le règlement.Superviser le système dans son ensemble, intervenir quand les seuils de risque sont franchis, et auditer périodiquement — c'est exactement ce que l'article 14 demande.

D'ailleurs, comme le souligne le Harvard Journal of Law and Technology, les lois qui imposent une supervision humaine “présument une capacité cognitive que les humains ne possèdent tout simplement pas” face à des systèmes opérant à vitesse machine. Meta a déjà remplacé la revue humaine par défaut par de l'IA pour ses changements d'algorithme.

3. “Nous sommes fournisseur (provider) pour chaque agent que nous créons”

Ce que dit l'article 3 :

• Fournisseur (provider) = développe un système IA et le met sur le marché sous son propre nom
• Déployeur (deployer) = utilise un système IA sous sa propre autorité

Si vous construisez des agents sur des APIs commerciales (Azure OpenAI, Claude, Gemini) sans modifier substantiellement le modèle sous-jacent, vous êtes déployeur. Les obligations lourdes (documentation technique, évaluation de conformité, marquage CE) restent chez le fournisseur du modèle.

Quand devenez-vous fournisseur ? Quand vous :

• Mettez votre marque sur un système à haut risque déjà sur le marché
• Modifiez substantiellement un système existant (fine-tuning profond + déploiement commercial)
• Changez la finalité d'un système pour le rendre à haut risque

Les estimations industrielles (lettre ERT, mars 2026) situent le coût de conformité fournisseur à environ 319 000€ initial + 150 000€/an pour une PME. La distinction provider/deployer n'est pas un détail — c'est un enjeu stratégique majeur.

Ce qui est réellement à haut risque (Annexe III)

Les 8 catégories sont plus étroites que ce que la plupart des équipes conformité imaginent :

1. Identification et catégorisation biométrique
2. Gestion d'infrastructures critiques (transport, eau, énergie)
3. Éducation et formation professionnelle (notation, admissions)
4. Emploi (recrutement, promotion, licenciement, allocation de tâches, évaluation de performance)
5. Accès aux services essentiels (scoring crédit, dispatch d'urgence, assurance vie/santé)
6. Forces de l'ordre (évaluation de preuves, profilage criminel)
7. Migration et contrôle aux frontières
8. Administration de la justice et processus démocratiques

Vos dashboards analytiques, vos générateurs de contenu marketing, vos assistants de code et vos chatbots internes ne sont PAS à haut risque— sauf s'ils sont déployés dans l'un de ces 8 domaines avec un impact décisionnel conséquent.

L'article 6(3) ajoute une nuance : même un système Annexe III n'est pas à haut risque s'il ne présente pas de risque significatif de préjudice et n'influence pas matériellement la prise de décision. Mais cette exemption est étroite — si l'output de votre système influence une décision conséquente, elle ne s'applique probablement pas.

Le cas spécifique de l'IA agentique

L'AI Act n'a pas été conçu avec les agents autonomes en tête. Plusieurs zones grises subsistent :

• Aucune disposition pour la délégation runtime. Un agent orchestrateur qui distribue des tâches à des sous-agents crée une chaîne de responsabilité opaque. Les rôles du règlement (provider, deployer) supposent des configurations fixes, pas des sélections d'outils dynamiques.
• “Modification substantielle” floue pour les agents. Si un agent réécrit son plan en cours d'exécution ou crée des sous-agents, chaque adaptation constitue-t-elle une modification substantielle nécessitant une nouvelle évaluation de conformité ?
• Le modèle de conformité est statique. L'approche de conformité pré-market suppose un système figé. Les systèmes agentiques évoluent en production.

L'autorité espagnole de protection des données (AEPD) a clarifié en février 2026 que les agents IA sont des moyens techniques à travers lesquels le traitement est effectué, pas des acteurs juridiques autonomes. L'autonomie technique ne modifie pas l'allocation de responsabilité RGPD.

Ce qu'il faut faire concrètement

Si vous n'avez pas encore commencé, ne paniquez pas — mais commencez maintenant :

1. Clarifiez votre rôle — Provider ou deployer ? Pour chaque système, la réponse change vos obligations du tout au tout.
2. Inventoriez vos systèmes IA — Plus de la moitié des entreprises n'ont pas d'inventaire systématique de leurs systèmes IA en production.
3. Classifiez par risque — Passez chaque système au crible de l'Annexe III. Vous serez probablement surpris de constater que 90%+ sont en risque minimal.
4. Concentrez vos efforts sur les 5-10% à haut risque — C'est là que les obligations sont réelles et les sanctions sévères.
5. Mettez en place une traçabilité — L'article 12 exige des journaux automatiques. Un seul système de logging peut servir à la fois l'AI Act et le RGPD.

Le vrai risque n'est pas l'AI Act — c'est la paralysie qu'il engendre quand il est sur-interprété. Pendant que vos équipes conformité débattent, vos collaborateurs utilisent l'IA sur leurs comptes personnels, hors de tout contrôle.