AI Act européen : conformité concrète pour l'entreprise

Ce que l'AI Act change, concrètement

Le règlement européen sur l'intelligence artificielle (l'AI Act) n'est pas un label marketing. C'est un cadre d'obligations proportionnées au risque du système. Pour une DSI, un RSSI ou un responsable conformité, la question n'est plus « avons-nous de l'IA ? » mais « quel régime s'applique à ce cas d'usage, avec ces données, cette autonomie, ce impact sur les personnes ? ».

Les équipes qui déploient déjà des agents, du RAG ou de la vision industrielle découvrent souvent un décalage : le POC tourne, le fournisseur promet la conformité, et personne n'a classifié le système ni défini qui porte l'obligation (fournisseur vs déployeur). L'AI Act force précisément ce travail (classification, documentation, gouvernance, supervision humaine) avant que le volume ou l'incident ne le fasse à votre place.

Cet article traduit le texte en actions concrètes pour une plateforme IA d'entreprise : comment classer, quelles obligations retenir, comment produire la preuve (logs, audit, supervision), et où la souveraineté des données rejoint la conformité.

Classification : partir du cas d'usage, pas du modèle

L'AI Act raisonne en systèmes, pas en marques de modèles. Un même LLM peut alimenter un assistant RH à faible risque et un scoring qui influence l'accès à un service, deux régimes différents. La classification dépend de la finalité, du contexte, et parfois de l'annexe des domaines high-risk (emploi, éducation, services essentiels, infrastructures critiques, etc.).

Quatre niveaux utiles pour prioriser en interne :

1. Pratiques interdites: manipulation subliminale, scoring social de type citoyen, exploitation de vulnérabilités, certains usages de biométrie en temps réel dans l'espace public (avec exceptions strictes). Si votre use case y ressemble, arrêtez et requalifiez, ne « mitigez » pas un interdit.
2. Haut risque: systèmes listés ou utilisés dans des domaines sensibles où l'impact sur les droits et la sécurité est élevé. C'est là que vivent la plupart des obligations lourdes (gestion des risques, data governance, documentation technique, logging, transparence, human oversight, précision / robustesse).
3. Risque limité: obligations surtout de transparence (ex. indiquer qu'on interagit avec une IA, marquage de certains contenus synthétiques).
4. Risque minimal: pas d'obligations spécifiques AI Act lourdes ; les bonnes pratiques (sécurité, privacy, qualité) restent recommandées et souvent exigées par d'autres textes (RGPD, NIS2, sectoriel).

Haut risque : ce qui change

Gestion des risques, gouvernance des données, documentation, logs et supervision humaine : prouvables, pas déclaratifs.

Méthode pragmatique : pour chaque cas d'usage, rédigez une fiche d'une page : finalité, utilisateurs, décisions prises ou assistées, données personnelles / sensibles, niveau d'autonomie, impact en cas d'erreur. Faites classer par un binôme métier + conformité (pas par le seul vendor). Revoyez la fiche quand l'autonomie augmente (passage d'assisté à semi-autonome) ou quand de nouveaux outils d'écriture sont branchés.

Obligations concrètes pour les systèmes high-risk

Si votre système tombe en high-risk (ou si vous l'anticipez pour éviter une requalification tardive), traduisez les articles en contrôles opérationnels :

Gestion des risques

Pas un PDF figé : un cycle. Identifier les risques (biais, dérive, mauvaise citation RAG, action outil hors périmètre), évaluer la gravité / probabilité, traiter (garde-fous, seuils, fallback), retester après changement de modèle ou de prompt. Liez ce cycle aux releases, comme vous le feriez pour un changement ERP critique.

Gouvernance des données

Origine des jeux d'entraînement / fine-tuning / évaluation, critères de pertinence, traitement des biais connus, séparation train / eval, traçabilité des sources RAG. Pour un déployeur qui n'entraîne pas, documentez quand même le périmètre des données d'inférence : ce qui part vers le modèle, ce qui reste en retrieval, ce qui est loggé.

Documentation technique et instructions

Architecture, versions de modèles, limites d'usage, comportements attendus / hors scope. Les instructions destinées aux utilisateurs professionnels doivent être lisibles par le métier, pas seulement par le lab IA. Versionnez-les avec le système.

Enregistrement et traçabilité

Logs permettant de reconstituer événements pertinents : entrée (dans les limites privacy), modèle / version, outils appelés, politiques déclenchées, sortie, validations humaines. Sans timeline rejouable, vous n'avez pas de preuve, vous avez une anecdote.

Transparence et supervision humaine

L'humain doit pouvoir comprendre, contester, et reprendre la main sur les décisions sensibles. « Un bouton Approuver » ne suffit pas s'il n'y a ni contexte, ni alternative, ni responsable identifiable. Définissez les seuils où l'agent s'arrête.

Précision, robustesse, cybersécurité

Mesures sous charge, modes dégradés, résistance aux injections de prompt / données, contrôle d'accès aux outils. Ici l'AI Act croise votre posture sécu existante, ne créez pas un silo « conformité IA » déconnecté du SOC.

Audit et traçabilité

Une timeline : entrée, plan, outils, politiques, sortie, validation humaine. Sinon la conformité reste déclarative.

Fournisseur, déployeur, intégrateur : qui porte quoi ?

Le texte distingue des rôles. En pratique enterprise :

• Fournisseur: met le système sur le marché (souvent l'éditeur de la plateforme ou du modèle).
• Déployeur: utilise le système sous son autorité (votre organisation).
• Importateur / distributeur: chaînes d'approvisionnement.

Beaucoup de projets hybrides : vous déployez AI for leaders (ou équivalent) avec vos connecteurs, vos prompts, vos politiques. Vous devenez co-responsable de la conformité du système tel qu'exploité. Exigez contractuellement : documentation, capacités de logging exportable, support aux audits, engagement sur les mises à jour réglementaires. Refusez les boîtes noires « trust us, we're compliant » sans artefacts.

Les modèles à usage général (GPAI) ajoutent une couche : obligations de transparence et, pour les plus puissants, d'évaluation et de gestion des risques systémiques côté fournisseur. Cela ne dispense pas le déployeur de classer son cas d'usage.

Calendrier d'application : dates clés et anticipation

L'AI Act (règlement (UE) 2024/1689) s'applique par vagues. Le Digital Omnibus on AI a notamment reporté les obligations high-risk Annexe III / Annexe I, utile pour planifier, pas pour reporter le travail. Pour le calendrier et le cadre officiel, voir aussi la page Commission sur l'AI Act. Voici les jalons à ancrer dans un calendrier DSI / conformité, avec ce qu'il faut avoir prévu avant chaque échéance.

1er août 2024: Entrée en vigueur

Le règlement est publié et le compte à rebours démarre. Aucune obligation opérationnelle n'est encore exécutoire à cette date, mais le cadrage juridique est figé.

À avoir anticipé : désigner un sponsor (DSI / conformité), cadrer le périmètre « systèmes IA » dans l'entreprise, et lancer l'inventaire, sinon les vagues suivantes arrivent sans cartographie.

2 février 2025: Pratiques interdites et littératie IA

Chapitre I (définitions, littératie) et chapitre II (interdits) s'appliquent. Les pratiques à risque inacceptable sont bannies: ce n'est pas un régime de mitigation. L'article 4 exige des mesures de littératie IA pour les équipes qui conçoivent, déploient ou supervisent.

À avoir prévu avant : revue des use cases sensibles (biométrie, scoring social, émotion au travail / en formation, scraping facial…) ; arrêt ou redesign si un cas tombe dans l'interdit ; plan de formation / littératie proportionné (pas un certificat cosmétique) ; RACI clair sur qui décide du « go / no-go ».

2 août 2025: GPAI, gouvernance et sanctions

Obligations des fournisseurs de modèles à usage général (GPAI), structures de gouvernance (autorités nationales, AI Office), et régime de sanctions opérationnel. Côté déployeur : vous dépendez des artefacts que votre fournisseur GPAI / plateforme peut fournir.

À avoir prévu avant : revue contrats fournisseurs (documentation technique, résumé données d'entraînement / copyright, droits d'audit, mises à jour réglementaires) ; exigences d'export de logs et d'instructions d'usage ; clarification rôle fournisseur vs déployeur pour chaque plateforme ; bascule hors black box si le vendor ne produit pas les preuves.

2 août 2026: Application générale et transparence

Date d'application générale : la majorité des règles restantes s'appliquent, dont les obligations de transparence (article 50), chatbot / interaction IA, marquage de certains contenus synthétiques, information sur certains usages biométriques / émotion. L'enforcement sur les dispositions déjà applicables se densifie.

À avoir prévu avant : inventaire à jour et classification stabilisée ; disclosures UX (mention « vous interagissez avec une IA ») ; politique de marquage / watermarking si vous générez du contenu synthétique ; procédures de réponse aux autorités ; alignement RGPD / NIS2 sur la même cartographie de contrôles.

2 décembre 2026: Interdits complémentaires et transition marquage

Nouveaux interdits (notamment contenus à caractère sexuel non consensuel / CSAM générés ou manipulés) et échéance transitoire pour certains fournisseurs déjà sur le marché concernant le marquage de contenus synthétiques (article 50(2)).

À avoir prévu avant : revue des pipelines génératifs (image, vidéo, audio, texte) ; contrôles d'usage et de diffusion ; calendrier de mise en conformité marquage pour les systèmes placés avant août 2026.

2 décembre 2027: Systèmes high-risk Annexe III

Obligations principales pour les systèmes high-risk listés à l'Annexe III (emploi, éducation, services essentiels, infrastructures critiques, biométrie autorisée, etc.), reportées par le Digital Omnibus. C'est l'échéance structurante pour la plupart des déploiements enterprise « métier ».

À anticiper 12–18 mois avant (dès 2026) : classification définitive Annexe III vs filtre article 6(3) ; owner + registre des risques vivant ; gouvernance des données d'inférence / RAG ; documentation technique versionnée ; logging rejouable ; human oversight avec seuils ; QMS / critères de conformité ; préparation déclaration / enregistrement ; tabletop incident. Ne pas démarrer la doc technique au T4 2027.

2 août 2028: High-risk intégrés aux produits Annexe I

Systèmes IA composants de sécurité de produits déjà régulés (dispositifs médicaux, machines, etc.). La conformité AI Act se croise avec le régime sectoriel existant.

À anticiper : si vous êtes fabricant / intégrateur de produits réglementés, aligner les dossiers de conformité produit et IA (même cycle d'évaluation, même post-market monitoring) ; sinon, vérifier que vos fournisseurs de composants critiques ont un plan 2028 crédible.

Mise en conformité opérationnelle

Une feuille de route réaliste sur un trimestre, à caler sur le calendrier ci-dessus, pas à la place :

Semaine 1–2: Inventaire. Listez les systèmes IA en prod, pilote, et shadow IT (copilots métiers inclus). Une ligne = un cas d'usage, pas un vendor.

Semaine 3–4: Classification. Ateliers métier + legal/compliance. Marquez interdit / high-risk / limité / minimal. Escalez les zones grises (mieux une surclassification temporaire qu'un angle mort).

Mois 2: Contrôles manquants. Pour chaque high-risk (ou candidat) : owner, registre des risques, politique de logging, points d'human oversight, critères de sortie de pilote. Branchez les exports d'audit sur votre outil de conformité existant si possible.

Mois 3: Preuve et routines. Exercice tabletop : un incident biais / mauvaise action outil / fuite de contexte. Vérifiez que N2 + conformité peuvent reconstituer la timeline. Intégrez la revue AI Act aux CAB / comités risques.

Souveraineté, modèles et AI Act : le même périmètre

Conformité AI Act et IA souveraine ne sont pas des sujets séparés. La résidence des données, le contrôle des logs, le choix d'un catalogue de modèles (SLM local vs API externe), et le périmètre données déterminent ce que vous pouvez prouver :

• Si l'inférence part hors UE sans garanties, la traçabilité et la gouvernance des données deviennent fragiles.
• Si vous ne maîtrisez pas les versions de modèles ni les politiques d'outils, la documentation technique lie.
• Si l'humain ne voit pas le plan de l'agent, l'oversight est cosmétique.

Une plateforme enterprise utile fournit donc : classification assistée des use cases, politiques par rôle, audit exportable, déploiement dans votre périmètre, et routing multi-modèles sans perdre le fil de preuve.

« La conformité AI Act se joue dans les logs et les process, pas dans le slide de lancement. »

Checklist actionnable

Avant de passer un cas d'usage en production :

• Fiche de classification signée (métier + conformité)
• Owner nommé (produit / DSI) et RACI fournisseurs
• Registre des risques vivant, lié aux releases
• Périmètre données d'inférence et RAG documenté
• Logging : timeline rejouable, rétention définie, accès contrôlé
• Seuils d'human oversight et procédure de contestation
• Transparence utilisateur si régime « risque limité » ou obligation sectorielle
• Modes dégradés et plan d'incident (biais, outil, modèle down)
• Revue contractuelle vendor (docs, audit rights, updates réglementaires)
• Alignement RGPD / NIS2 / sectoriel, une seule cartographie des contrôles si possible

Conclusion

L'AI Act récompense les organisations qui traitent l'IA comme un système opérable : classifié, documenté, supervisable, auditable. Il pénalise les POC qui ont sauté l'étape gouvernance. La bonne nouvelle : les mêmes fondations (périmètre, logs, outils à périmètre limité, humain dans la boucle) sont celles d'une plateforme IA de production, pas un fardeau parallèle.

Pour ancrer le contrôle des données, lire données et IA : le périmètre souverain ; pour le choix des briques modèles, les 8 types de modèles spécialisés ; pour le « pourquoi » stratégique, pourquoi l'IA souveraine compte.