AI Act : préparer le registre des agents IA

Le Règlement (UE) 2024/1689dit AI Act est le premier texte transversal au monde qui régule l'intelligence artificielle. Il est entré en vigueur le 1er août 2024, avec une application progressive jusqu'en 2027.

Le texte distingue trois rôles :

• Le fournisseur(provider) — l'éditeur qui développe l'agent IA et le met sur le marché (OpenAI, Mistral, Hugging Face, un éditeur SaaS qui intègre un LLM, etc.).
• Le déployeur(deployer) — l'organisation qui utilise l'agent sous son autorité, dans son périmètre métier. C'est la plupart des entreprises qui consomment des API IA tierces.
• L'importateur / distributeur — pertinent pour les intégrateurs européens revendant des systèmes hors UE.

Sanctions : jusqu'à 35 M€ ou 7 % du chiffre d'affaires mondial pour la violation des interdictions (Article 5), 15 M€ ou 3 % pour les manquements aux obligations high-risk. Une non- conformité documentaire (registre absent ou mal tenu) = 7,5 M€ ou 1 %. C'est strictement plus dur que le RGPD.

Le texte adopte une approche par risque — l'intensité des obligations dépend du contexte d'usage, pas de la techno sous-jacente.

Risque inacceptable (Article 5) — interdits

• Manipulation comportementale qui cause un préjudice significatif (deepfakes politiques ciblés, micro-targeting psychologique abusif).
• Exploitation des vulnérabilités d'un groupe (mineurs, personnes en situation de handicap, etc.).
• Social scoring par les pouvoirs publics ou les acteurs privés à des fins de notation générale des individus.
• Reconnaissance des émotions dans l'éducation et le monde du travail (sauf raison médicale).
• Identification biométrique en temps réel dans l'espace public à des fins répressives (sauf exceptions très encadrées).

Risque élevé (high-risk, Article 6 + Annexe III)

C'est la catégorie centrale, celle qui demande la paperasse maximale. Sont concernés les usages dans :

• Sécurité de produits(jouets, machines, dispositifs médicaux — passent par la liste de l'Annexe I).
• Infrastructures critiques (trafic, eau, gaz, électricité).
• Éducation (admissions, évaluation, fraude examens).
• Recrutement et gestion RH (CV-screening, promotion, licenciement, évaluation de performance).
• Accès aux services essentiels (crédit bancaire, urgences, prestations sociales, assurance santé/vie).
• Police, justice, immigration (profilage, prédiction criminalité, lecture de polygraphe, etc.).
• Démocratie (systèmes influençant le comportement électoral).

Risque limité (Article 50) — obligations de transparence

• Chatbotsconversationnels (B2C surtout) → l'utilisateur doit savoir qu'il interagit avec une IA.
• Contenu généré par IA → marquage obligatoire (deepfakes, images synthétiques, etc.).
• Reconnaissance émotionnelle hors contextes interdits → information préalable.

Risque minimal — aucune obligation spécifique

Filtres anti-spam, recommandations contenu basiques, tâches automatisées de back-office sans impact sur les personnes. Le texte encourage des codes de conduite volontaires mais ne contraint rien.

L'Article 11 (fournisseurs) et l'Article 26 (déployeurs) imposent une documentation technique tenue à jour. Pour un agent classé high-risk, le contenu minimum est listé en Annexe IV :

1. Identification— nom de l'agent, version, fournisseur, date de mise en service, propriétaire interne (Tech Lead + Product Owner).
2. Description fonctionnelle— finalité prévue, périmètre métier, types d'utilisateurs et d'impactés, contexte d'usage attendu.
3. Architecture technique — modèle(s) sous-jacent(s), fournisseur du modèle, intégration (RAG, fine-tuning, prompt-only), dépendances externes, contrats avec les fournisseurs de modèles.
4. Données— sources d'entraînement (pour les modèles internes), données d'inférence collectées, mesures contre les biais, plan de qualité, métadonnées de provenance.
5. Gestion des risques— analyse des risques (préjudice utilisateurs, hallucinations, injection de prompt, fuite de données), mesures d'atténuation, monitoring continu.
6. Tests et validation — protocoles de test, métriques de performance, seuils acceptables, red-teaming, résultats datés.
7. Supervision humaine — qui valide quoi, à quelles étapes du processus, comment override une décision, formation des opérateurs (Articles 14 et 26).
8. Cybersécurité — mesures contre les attaques adversariales (prompt injection, data poisoning), conservation des logs (6 mois minimum Article 19).
9. Information utilisateurs— quelles notices, modalités de consentement, mention de l'IA dans les communications.
10. Procédure de mise à jour— comment notifier en cas d'incident grave (Article 73), de changement substantiel (re-évaluation déclenchée), point de contact unique.

Pour les risques limités ou minimaux, le contenu peut être réduit aux points 1-2-3-5-9. Mais le bon réflexe opérationnel reste de tenir le même squelette pour tous les agents — vous évitez d'avoir à re-catégoriser le jour où une fonction évolue et fait basculer l'agent en high-risk.

Si vous êtes déployeur (vous consommez un agent fourni par un éditeur tiers), votre charge est plus légère mais pas nulle :

• Respecter la notice fournisseur— pas d'usage hors mode d'emploi. Si le fournisseur interdit explicitement un cas d'usage, vous ne pouvez pas le déployer dessus.
• Désigner des personnes physiques formées pour la supervision humaine (point critique pour les agents high-risk impactant les personnes : ces personnes doivent pouvoir override effectivement la décision IA).
• Pertinence des données d'entrée — surveillance que les inputs métier collent à la finalité prévue et représentent le contexte.
• Monitoring continu— surveiller le fonctionnement, déclencher une re-évaluation en cas d'écart, alerter en cas d'incident grave sous 15 jours (Article 73).
• Conservation des logs — 6 mois minimum, pour permettre les enquêtes a posteriori.
• Information des personnes affectées — quand un agent IA prend ou contribue significativement à une décision les concernant (Article 26.11).
• FRIA (cf. §5) pour les agents high-risk déployés par des organismes de droit public, les banques pour le scoring de crédit, ou les assurances pour les tarifications santé/vie.

Trois évaluations d'impact se chevauchent. Bien les aligner = éviter de tripler le travail.

DPIA (Article 35 RGPD)

Obligatoire pour tout traitement à haut risque pour les droits et libertés. Un agent IA qui traite des données personnelles à grande échelle, qui profile, ou qui prend des décisions automatisées la déclenche presque toujours. Output : un document analysant la nécessité, la proportionnalité, les risques, les mesures d'atténuation. Le DPO est référent.

FRIA (Article 27 AI Act)

Fundamental Rights Impact Assessment. Spécifique AI Act, obligatoire avant la mise en service de certains agents high-risk par des déployeurs spécifiques :

• Organismes de droit public, quelle que soit la finalité high-risk
• Acteurs privés fournissant des services publics (santé, éducation, formation, etc.)
• Banques pour le scoring de solvabilité
• Assurances pour la tarification santé / vie

Le FRIA documente : finalité, périmètre, fréquence d'usage, catégories de personnes impactées, risques spécifiques sur les droits fondamentaux (non-discrimination, vie privée, accès au service, recours effectif), mesures de gouvernance, plan d'information des personnes.

Registre des traitements (Article 30 RGPD)

Le grand classique RGPD. Doit lister tous les traitements de données personnelles. Bonne nouvelle : un agent IA qui manipule des données perso est déjàdans ce registre. La cohérence à viser : un agent = une fiche registre RGPD + une fiche registre IA + une DPIA + un FRIA si applicable, tous chaînés par un identifiant unique d'agent.

• Sous-estimer le périmètre.Tout workflow qui fait passer une décision par un modèle de langage compte, même un « assistant interne ». Trier les emails entrants, suggérer une réponse client, qualifier un lead commercial — tout ça est dans le périmètre.
• Confondre fournisseur et déployeur.Si vous fine-tunez un modèle open-source pour votre usage interne avec un système maison, vous passez fournisseur. Si vous wrappez une API OpenAI avec votre propre prompt système et la commercialisez sous votre marque, idem. Re-lire l'Article 25 (changements substantiels).
• Vendor lock-in invisible. Les modèles GPAI évoluent en continu côté fournisseur (versions, prix, modération). Pas de documentation = pas de reproductibilité = pas de FRIA crédible. Pinner les versions et logger les changements de fournisseur est une obligation implicite de la gestion des risques.
• Mauvaise supervision humaine.« Un humain valide » en bout de chaîne ne suffit pas. La personne doit être en mesured'override (autorité, formation, temps, données d'explicabilité). Sinon c'est de la signature cosmétique — sanctionnable.
• Oublier l'information des personnes. L'Article 26.11 oblige à informer les personnes affectées par une décision IA. En B2B, on oublie souvent les salariés (recrutement, paie, évaluation) — c'est pourtant exactement les cas typiques high-risk.
• Registre « one-shot ».Faire la fiche le jour du déploiement et passer à autre chose = échec garanti à l'audit. Le registre est vivant : MAJ à chaque release modèle, à chaque changement de finalité, à chaque incident.

Pratiquement, trois familles d'outils se croisent :

• Catalogue d'agents IA— la fiche par agent (registre Article 11 + 26). Maintenu par l'architecture, contribué par les équipes produit. Versionné, datable, exportable PDF pour les auditeurs.
• Workflow d'ARB / comité IA— l'instance de validation préalable à la mise en service. Évalue le risque, demande les éventuels FRIA / DPIA, prononce un GO / GO-cond / NO-GO opposable. Idéalement réutilise votre instance ARB existante (cf. notre article ARB).
• Audit trail post-déploiement— logs d'usage 6 mois minimum, notifications d'incident Article 73, monitoring de drift.

C'est exactement ce que Architecture Platform fournit nativement — registre IA, DPIA / FRIA templatés par agent, rapport de conformité PDF, audit trail signé. Plutôt que d'assembler 4 tableurs et un Confluence, vous avez un workflow auditeur-ready depuis le jour 0.

• 2 février 2025 — interdictions Article 5 + IA literacy (Article 4 : tout employé en contact avec un agent IA doit avoir une formation de base au fonctionnement et aux risques).
• 2 août 2025 — gouvernance européenne active, sanctions financières applicables, obligations GPAI pour les fournisseurs de modèles à usage général (OpenAI, Anthropic, Mistral, Google…).
• 2 août 2026 — application générale, notamment des obligations high-risk Article 6.2 (Annexe III : RH, éducation, services essentiels, justice, démocratie…) ← date critique pour la majorité des entreprises.
• 2 août 2027 — obligations high-risk Article 6.1 (Annexe I : produits réglementés, dispositifs médicaux, jouets, machines…).

À 14 mois de l'échéance phare (août 2026), le bon rythme est : inventorier les agents existants ce trimestre, cadrer le registre et identifier les high-risk d'ici 6 mois, puis itérer sur les FRIA / DPIA des cas critiques avant fin 2025. Toute organisation qui découvre l'AI Act à 3 mois de l'échéance sera en mode panique — éviter ce piège.