AI Act 2026 : Implications pour les Systèmes Agentiques et Multimodaux

Table des Matières

1 Introduction : l'AI Act entre en vigueur, impacts sur l'IA agentique

Le Règlement (UE) 2024/1689 sur l'intelligence artificielle, couramment désigné EU AI Act, est officiellement entré en vigueur le 1er août 2024, après sa publication au Journal officiel de l'Union européenne. Son déploiement suit un calendrier échelonné jusqu'en août 2027, mais l'essentiel de ses obligations s'est progressivement matérialisé depuis 2025. En 2026, les entreprises opérant dans l'espace économique européen font face à un double défi : comprendre précisément quelles dispositions s'appliquent à leurs systèmes d'IA, et adapter leurs processus de développement, de déploiement et de surveillance en conséquence. Ce défi est particulièrement aigu pour deux catégories émergentes de systèmes : les systèmes d'IA agentiques, capables d'agir de manière autonome et de prendre des décisions sans validation humaine à chaque étape, et les modèles multimodaux, capables de générer du texte, des images, du son et de la vidéo à partir de prompts en langage naturel.

L'AI Act a été conçu à une époque où les systèmes d'IA agentiques étaient encore essentiellement expérimentaux et où les modèles multimodaux avancés n'existaient pas dans leur forme actuelle. Le règlement a donc été rédigé avec des catégories pensées pour des systèmes plus conventionnels, créant des zones d'interprétation délicates pour les technologies les plus récentes. L'AI Office européen et les autorités nationales compétentes ont commencé à publier des orientations interprétatives en 2025 pour clarifier l'application du règlement aux cas difficiles, mais des incertitudes subsistent. Les systèmes agentiques, par exemple, posent des questions inédites sur la chaîne de responsabilité : qui est responsable quand un agent IA prend une mauvaise décision après une séquence d'actions autonomes impliquant plusieurs outils et sources de données ? La notion de supervision humaine significative — exigée pour les systèmes à haut risque — est-elle compatible avec l'autonomie multi-étapes par définition des agents IA ?

Pour les entreprises, l'enjeu de 2026 est de cartographier précisément leurs systèmes d'IA dans la taxonomie de l'AI Act afin de déterminer leurs obligations exactes. Une erreur de classification — sous-estimer le niveau de risque d'un système agentique utilisé dans les ressources humaines, par exemple — expose à des sanctions sévères et à des dommages réputationnels significatifs. À l'inverse, une sur-conformité coûteuse pour des systèmes à risque minimal représente un gaspillage de ressources qui handicape la compétitivité. La maîtrise de la logique de classification de l'AI Act est donc devenue une compétence stratégique pour tout responsable IA, CTO, DPO ou juriste d'entreprise en 2026.

2 Classification des risques : modèles GPAI, systèmes haut risque, usages interdits

L'AI Act organise sa réglementation autour d'une pyramide de risques à quatre niveaux, chacun entraînant des obligations proportionnelles. Au sommet, les pratiques d'IA interdites (Article 5) constituent une liste exhaustive d'usages bannis dès le 2 février 2025 : systèmes de manipulation comportementale subliminale ou trompeuse ciblant les vulnérabilités humaines, notation sociale généralisée par des acteurs publics ou privés, identification biométrique à distance en temps réel dans les espaces publics à des fins policières (sauf exceptions judiciaires strictes), profilage prédictif pour la commission d'infractions pénales, reconnaissance des émotions sur le lieu de travail ou dans les établissements scolaires, et catégorisation biométrique révélant des caractéristiques sensibles. Pour les systèmes agentiques, l'interdiction la plus pertinente est celle de la manipulation comportementale : un agent IA de vente qui utiliserait des techniques de persuasion s'appuyant sur des biais cognitifs identifiés chez l'utilisateur pour le pousser à l'achat serait en violation directe de l'Article 5.

Les systèmes à haut risque (Article 6 et Annexe III) constituent la catégorie la plus complexe et la plus impactante pour les entreprises. Ils se définissent par leur appartenance à un secteur critique et leur potentiel d'impact significatif sur les personnes. Les huit domaines listés à l'Annexe III couvrent l'infrastructure critique (énergie, eau, transport), l'éducation et la formation professionnelle, l'emploi et la gestion des ressources humaines, l'accès aux services essentiels (crédit, assurance, prestations sociales), la justice pénale et la sécurité publique, la migration et l'asile, l'administration de la justice et les processus démocratiques. Un point capital pour les concepteurs de systèmes agentiques : un agent IA qui automatise les décisions de recrutement, d'attribution de crédit ou d'accès à des services sociaux est classé haut risque, indépendamment de la sophistication de son architecture ou du degré d'autonomie de ses décisions. C'est l'usage final qui détermine la classification, pas la technologie sous-jacente.

La catégorie des modèles GPAI (General Purpose AI), introduite spécifiquement dans l'AI Act pour répondre à l'émergence des fondation models, est particulièrement pertinente en 2026. Tout modèle IA entraîné avec une grande quantité de données, capable de réaliser une large gamme de tâches distinctes et mis à disposition via des APIs ou intégré dans des produits tiers, est qualifié de GPAI model. Les exemples typiques sont GPT-4o, Claude Opus 4.6, Gemini 2.0 Ultra, Llama 3.1, Mistral Large. Ces modèles sont soumis à des obligations de transparence envers les déployeurs (documentation technique, politique d'usage acceptable, instructions de déploiement sécurisé) et envers le public (résumé des données d'entraînement, capacités et limites). Les modèles GPAI dépassant le seuil de 10^25 FLOPS de puissance de calcul d'entraînement sont qualifiés de modèles à risque systémique et soumis à des obligations renforcées décrites dans la Section 3 ci-dessous.

3 Obligations des modèles fondation : transparence, tests, rapports

Les fournisseurs de modèles GPAI — c'est-à-dire les entreprises qui entraînent et commercialisent des modèles fondation — sont soumis à un ensemble d'obligations spécifiques depuis août 2025. La première obligation, et sans doute la plus structurante, est la documentation technique exhaustive : le fournisseur doit maintenir un dossier technique détaillant l'architecture du modèle, les jeux de données d'entraînement (sources, taille, méthodes de filtrage, respect du droit d'auteur), les méthodes d'évaluation utilisées, les performances sur des benchmarks standardisés, les capacités connues et les limitations identifiées, ainsi que les mesures d'atténuation des risques implémentées. Cette documentation doit être mise à disposition de l'AI Office sur demande et, pour certains éléments, publiée publiquement. La politique d'utilisation acceptable du modèle — définissant les usages autorisés, restreints et prohibés — doit également être documentée et communiquée aux déployeurs qui intègrent le modèle dans leurs produits.

Pour les modèles à risque systémique (seuil 10^25 FLOPS), les obligations sont substantiellement plus lourdes. L'article 55 de l'AI Act impose quatre exigences supplémentaires : (1) réaliser des évaluations de modèle contradictoires (red-teaming, adversarial testing) avant la mise sur le marché et après chaque mise à jour majeure, potentiellement en coordination avec l'AI Office, (2) évaluer et atténuer les risques systémiques identifiés, incluant les risques pour la sécurité publique, la démocratie et la diffusion d'informations incorrectes, (3) signaler à l'AI Office tout incident grave ou dysfonctionnement susceptible de constituer un risque pour la santé, la sécurité ou les droits fondamentaux dans les 24 heures, (4) assurer la cybersécurité du modèle et des infrastructures physiques et numériques associées. Ces obligations concernent directement OpenAI, Google DeepMind, Anthropic et Meta qui commercialisent leurs modèles en Europe, mais aussi les acteurs européens développant des modèles frontière.

Un aspect souvent négligé est la responsabilité des déployeurs de modèles GPAI — c'est-à-dire les entreprises qui utilisent un modèle fondation pour construire un produit ou service. Le déployeur n'est pas exempt d'obligations sous prétexte qu'il n'a pas entraîné le modèle. Si le système final tombe dans la catégorie haut risque, le déployeur est responsable de la conformité de l'application — y compris de la documentation de l'usage spécifique, de l'évaluation de conformité, et de la mise en place de la supervision humaine requise. De plus, si le déployeur modifie substantiellement le modèle via du fine-tuning ou qu'il l'utilise d'une manière non prévue ou non autorisée par le fournisseur, il peut acquérir le statut de fournisseur au sens de l'AI Act et être soumis à l'ensemble des obligations correspondantes. La frontière entre déployeur et fournisseur est donc un enjeu juridique critique pour les entreprises qui fine-tunent des modèles fondation sur leurs propres données.

4 IA agentique : prise de décision autonome et supervision humaine

Les systèmes d'IA agentiques — agents autonomes capables de planifier et d'exécuter des séquences d'actions multi-étapes sans validation humaine intermédiaire — posent des défis interprétatifs fondamentaux à l'AI Act. Le règlement, conçu pour des systèmes plus statiques, repose sur une logique de supervision humaine qui suppose qu'un être humain peut examiner et valider les décisions de l'IA avant qu'elles aient des effets irréversibles. Or, un agent IA opérant dans un pipeline automatisé peut enchaîner des dizaines d'actions — appels API, modifications de bases de données, envois d'emails, exécutions de code — avant que quiconque n'ait eu l'occasion d'intervenir. L'AI Office a publié en octobre 2025 des orientations sur l'IA agentique qui clarifient plusieurs points essentiels.

Pour les systèmes agentiques classés haut risque, la supervision humaine requise par l'Article 14 doit être réelle et efficace, pas symbolique. Cela signifie concrètement que les agents opérant dans des domaines haut risque doivent intégrer des points d'arrêt obligatoires (human-in-the-loop checkpoints) aux étapes critiques — par exemple, avant d'exécuter une décision d'embauche, de refus de crédit ou de signalement policier. La simple existence d'un tableau de bord de monitoring post-hoc ne satisfait pas l'exigence de supervision humaine si un humain n'a pas eu l'opportunité réelle de valider ou d'arrêter l'action avant son exécution. Le concept de human-on-the-loop — supervision globale sans validation action par action — peut être acceptable pour des agents à risque limité ou minimal, mais pas pour les systèmes haut risque. Les concepteurs d'agents IA doivent donc architecturer leurs systèmes en distinguant soigneusement les actions réversibles (pour lesquelles l'autonomie complète peut être acceptable) des actions irréversibles à fort impact (qui nécessitent une validation humaine préalable).

La question de la traçabilité des décisions agentiques est également critique sous l'AI Act. Les articles 12 et 13 imposent aux systèmes haut risque de générer des logs automatiques permettant de retracer les décisions et les actions post-incident. Pour un agent IA, cela implique de journaliser l'ensemble du raisonnement — les thoughts du modèle, les outils invoqués, les arguments utilisés, les résultats obtenus — avec suffisamment de granularité pour permettre une enquête ultérieure. Cette exigence de traçabilité pousse vers des architectures agentiques avec des mécanismes de chain-of-thought logging structurés, des identifiants de session uniques, et des systèmes de retention des logs conformes au RGPD. La combinaison AI Act + RGPD crée une tension délicate : l'AI Act exige de conserver les logs de décision pour la responsabilité, tandis que le RGPD impose des limites à la rétention de données personnelles et des droits d'accès et d'effacement pour les personnes concernées.

5 Contraintes multimodales : génération de contenu, deepfakes, watermarking

Les modèles d'IA multimodaux — capables de générer du texte, des images, de l'audio et de la vidéo à partir de descriptions en langage naturel — sont au coeur de deux ensembles d'obligations de l'AI Act particulièrement impactants en 2026. Le premier concerne la transparence envers les utilisateurs pour tout contenu généré par l'IA. L'Article 50 impose que les systèmes d'IA interagissant avec des humains (chatbots, assistants vocaux) informent les utilisateurs de la nature artificielle de l'interaction de manière claire et sans ambiguïté. De même, les contenus audio, image, vidéo et texte générés par des systèmes GPAI et susceptibles d'être perçus comme authentiques doivent être marqués comme générés par IA via un mécanisme technique fiable. Cette obligation de marquage s'applique aux fournisseurs de systèmes GPAI qui mettent ces capacités à disposition ; les déployeurs doivent à leur tour s'assurer que les interfaces utilisateur communiquent cette information de manière compréhensible.

Le second ensemble d'obligations concerne spécifiquement les deepfakes — contenus hyperréalistes représentant des personnes réelles dans des situations fabriquées. L'Article 50(4) impose que toute personne déployant un système d'IA pour générer des contenus deepfake divulgue clairement que ces contenus ont été générés ou manipulés artificiellement, sauf dans des contextes strictement délimités (oeuvres artistiques, satire explicite, sécurité nationale). Cette obligation de divulgation des deepfakes crée des exigences concrètes pour les plateformes de création de contenu, les studios de divertissement, les applications de médias sociaux et toute entreprise utilisant de l'IA générative pour produire du contenu audiovisuel. La non-divulgation d'un deepfake — même partielle, comme modifier subtilement la voix ou l'apparence d'une personne sans indiquer l'intervention de l'IA — constitue une violation directe du règlement.

La question du watermarking (tatouage numérique) est particulièrement complexe techniquement. L'AI Act impose un marquage fiable du contenu généré par IA, mais ne prescrit pas de technologie spécifique, laissant l'industrie développer des standards. En 2026, plusieurs approches coexistent : le watermarking invisible embarqué dans les pixels ou les fréquences audio du contenu (C2PA, SynthID de Google), les métadonnées standardisées associées aux fichiers (Coalition for Content Provenance and Authenticity C2PA, adopté par Adobe, Microsoft, Sony), et les marquages visibles textuels ou iconographiques. Chaque approche présente des compromis entre robustesse (résistance aux modifications du contenu), discrétion (impact sur la qualité perçue) et déployabilité. L'AI Office développe activement un cadre technique de référence pour le watermarking en coordination avec les organismes de normalisation, mais sa finalisation est attendue pour fin 2026. En attendant, les entreprises doivent implémenter les solutions disponibles en documentant leur choix technique et son niveau de fiabilité.

6 Calendrier de conformité : obligations 2024-2027

Le calendrier de mise en conformité à l'AI Act s'étale sur trois ans, permettant théoriquement aux organisations de planifier leur adaptation progressive. En pratique, le rythme d'application reste intense, notamment pour les entreprises qui n'avaient pas anticipé l'ampleur des changements requis. Le tableau ci-dessous synthétise les principales obligations par date d'application et type d'acteur.

En août 2026, la majorité des entreprises déployant de l'IA dans des domaines à haut risque doivent être en conformité complète avec les obligations des systèmes haut risque. Pour celles qui ne l'étaient pas encore, l'urgence est maximale. Les principaux chantiers de conformité pour un système haut risque incluent : (1) la rédaction et la maintenance d'une documentation technique complète (architecture, données d'entraînement, métriques de performance, analyses de risques), (2) la mise en place d'un système de gestion de la qualité (QMS) couvrant le cycle de vie du système IA, (3) l'enregistrement du système dans la base de données européenne EU database gérée par l'AI Office, (4) l'implémentation d'une supervision humaine effective avec procédures documentées pour les opérateurs humains, (5) le déploiement de mécanismes de surveillance post-marché incluant la collecte de métriques de performance, la détection de dérives et les procédures de rapport d'incidents. Pour les organisations qui déploient des systèmes agentiques dans des domaines haut risque, l'architecte IA doit documenter explicitement les points d'intervention humaine et démontrer que la supervision est effective, pas seulement formelle.

7 Sanctions et enforcement : surveillance de marché et amendes 35M euros

Le régime de sanctions de l'AI Act est l'un des plus stricts jamais mis en place pour une réglementation technologique, surpassant même certaines dispositions du RGPD. L'Article 99 définit trois niveaux d'amendes administratives. Pour les violations des pratiques interdites (Article 5) — systèmes de manipulation, notation sociale, biométrie non autorisée — l'amende maximale est de 35 millions d'euros ou 7 % du chiffre d'affaires mondial annuel de l'exercice précédent, le montant le plus élevé étant retenu. Pour les violations des obligations applicables aux systèmes haut risque et aux fournisseurs GPAI (Articles 9-49), l'amende maximale est de 15 millions d'euros ou 3 % du CA mondial. Pour la fourniture d'informations incorrectes, incomplètes ou trompeuses aux autorités dans le cadre d'un contrôle ou d'une certification, l'amende peut atteindre 7,5 millions d'euros ou 1 % du CA mondial. Pour les PME et start-ups, des plafonds spécifiques s'appliquent pour éviter des sanctions disproportionnées.

La surveillance de marché est organisée à deux niveaux. Au niveau national, chaque État membre désigne une ou plusieurs autorités nationales compétentes (ANC) chargées de surveiller le marché, d'enquêter sur les violations et d'imposer des mesures correctives. Ces autorités disposent de pouvoirs étendus : accès aux documentations techniques, inspections sur site, demandes d'information aux fournisseurs et déployeurs, tests des systèmes d'IA, injonctions de retrait ou de restriction. Au niveau européen, l'AI Office est compétent pour les modèles GPAI à risque systémique, avec des pouvoirs d'investigation propres et la capacité d'imposer des sanctions directement aux fournisseurs de ces modèles. Un mécanisme de coordination européenne permet l'échange d'informations entre ANC et avec l'AI Office via l'European AI Board, favorisant une application harmonisée entre États membres. En 2026, les premières procédures d'enforcement formelles ont été ouvertes par plusieurs ANC, notamment en relation avec des systèmes de recrutement algorithmique et des applications de modération de contenu utilisant l'IA.

Au-delà des sanctions financières, l'AI Act prévoit des mesures d'enforcement non monétaires potentiellement encore plus impactantes pour les entreprises. Une autorité nationale peut ordonner le retrait du marché d'un système IA non conforme, interdire temporairement ou définitivement son déploiement dans l'UE, ou imposer des obligations de rappel pour les systèmes déjà déployés. Pour les modèles GPAI à risque systémique dont un fournisseur refuserait de coopérer avec l'AI Office, l'accès au marché européen peut être suspendu. Ces perspectives rendent la conformité non négociable pour tout acteur qui souhaite opérer durablement dans l'espace économique européen. La réputation de conformité IA devient par ailleurs un critère de sélection des fournisseurs pour les entreprises soucieuses de leur propre conformité : un déployeur ne peut pas confier des fonctions haut risque à un fournisseur dont les systèmes présentent des risques de non-conformité, car la responsabilité en cascade de l'AI Act peut l'exposer à des sanctions.

8 Guide pratique de mise en conformité pour les entreprises

Mettre en conformité une organisation avec l'AI Act en 2026 s'articule autour de six chantiers structurants. La première étape est l'inventaire et la classification de tous les systèmes d'IA utilisés ou déployés — qu'ils aient été développés en interne, achetés à des éditeurs ou construits sur des APIs de modèles fondation. Chaque système doit être évalué selon la grille de classification de l'AI Act pour déterminer son niveau de risque. Pour les systèmes agentiques et multimodaux, l'analyse doit prendre en compte l'usage final concret et non la technologie abstraite : un agent de génération de code (risque minimal) est très différent d'un agent de décision de crédit (haut risque), même s'ils utilisent le même modèle fondation. Cette classification initiale doit être documentée et révisée périodiquement, notamment à chaque mise à jour significative du système ou changement d'usage.

Pour les systèmes classés haut risque, le deuxième chantier est la mise en place d'un système de gestion de la qualité (QMS) conforme à l'Article 17. Le QMS doit couvrir : les politiques et procédures de conformité, les rôles et responsabilités, la gestion de la documentation, la gestion des incidents et des non-conformités, les processus d'évaluation de la conformité, et la surveillance post-marché. Ce QMS n'est pas sans rappeler les exigences ISO 9001 et peut être intégré dans un système de management existant. Le troisième chantier est la gouvernance des données : les systèmes haut risque nécessitent que les jeux de données utilisés pour l'entraînement, la validation et les tests soient documentés, représentatifs, exempts d'erreurs et de biais autant que possible, et traités conformément au RGPD. Les pratiques de data governance déjà mises en place pour le RGPD constituent une base utile mais insuffisante — l'AI Act ajoute des exigences spécifiques sur la représentativité statistique et la traçabilité des données d'entraînement.

Pour les systèmes agentiques en particulier, le quatrième chantier est l'architecture de supervision humaine. Il s'agit de concevoir ou de retrofitter les agents pour intégrer des points d'arrêt obligatoires aux actions irréversibles, des mécanismes d'escalade vers des opérateurs humains en cas de doute ou d'anomalie, des interfaces de supervision intuitives pour les opérateurs, et des procédures de formation documentées pour ces opérateurs. Le cinquième chantier est la gestion des fournisseurs IA : auditer les fournisseurs de modèles fondation sur leur conformité AI Act, négocier des clauses contractuelles appropriées, et maintenir un registre des APIs et services IA tiers utilisés avec leur niveau de conformité évalué. Voici un exemple de checklist de conformité pouvant être implémentée dans un pipeline MLOps.

# Checklist de conformité AI Act automatisée
# Intégrable dans un pipeline MLOps pour les systèmes haut risque

from dataclasses import dataclass
from typing import List, Tuple
from enum import Enum

class ComplianceStatus(Enum):
    COMPLIANT     = "conforme"
    NON_COMPLIANT = "non_conforme"
    PARTIAL       = "partiel"
    NA            = "non_applicable"

@dataclass
class ComplianceCheck:
    article: str          # Référence article AI Act
    requirement: str      # Description de l'exigence
    status: ComplianceStatus
    evidence: str         # Preuve ou action requise
    priority: str         # "critique", "majeur", "mineur"

class AIActComplianceChecker:
    """Vérificateur de conformité AI Act pour systèmes haut risque.
    Couvre les articles clés du Chapitre III, Section 2."""

    def run_checks(self, system_config: dict) -> List[ComplianceCheck]:
        checks = []

        # Art. 9 : Système de gestion des risques
        has_rmf = system_config.get("risk_management_framework", False)
        checks.append(ComplianceCheck(
            article="Art. 9",
            requirement="Système de gestion des risques établi et documenté",
            status=ComplianceStatus.COMPLIANT if has_rmf else ComplianceStatus.NON_COMPLIANT,
            evidence="RMF documenté" if has_rmf else "MANQUANT : créer et documenter un RMF",
            priority="critique"
        ))

        # Art. 10 : Gouvernance des données
        data_documented = system_config.get("training_data_documented", False)
        bias_tested     = system_config.get("bias_evaluated", False)
        data_status = (ComplianceStatus.COMPLIANT if data_documented and bias_tested
                       else ComplianceStatus.PARTIAL if data_documented or bias_tested
                       else ComplianceStatus.NON_COMPLIANT)
        checks.append(ComplianceCheck(
            article="Art. 10",
            requirement="Données d'entraînement documentées et évaluées pour biais",
            status=data_status,
            evidence=(f"Docs: {'OK' if data_documented else 'NON'} | "
                      f"Biais: {'OK' if bias_tested else 'NON'}"),
            priority="critique"
        ))

        # Art. 14 : Supervision humaine
        human_oversight = system_config.get("human_oversight_implemented", False)
        override_possible = system_config.get("human_override_possible", False)
        oversight_ok = human_oversight and override_possible
        checks.append(ComplianceCheck(
            article="Art. 14",
            requirement="Supervision humaine effective avec possibilité d'intervention",
            status=ComplianceStatus.COMPLIANT if oversight_ok else ComplianceStatus.NON_COMPLIANT,
            evidence="Supervision et override OK" if oversight_ok else
                     "CRITIQUE : implémenter supervision humaine et mécanisme d'arrêt",
            priority="critique"
        ))

        # Art. 12 : Logging des décisions
        logging_enabled = system_config.get("decision_logging", False)
        checks.append(ComplianceCheck(
            article="Art. 12",
            requirement="Logs automatiques des décisions (traçabilité)",
            status=ComplianceStatus.COMPLIANT if logging_enabled else ComplianceStatus.NON_COMPLIANT,
            evidence="Logging actif" if logging_enabled else "MANQUANT : activer decision logging",
            priority="majeur"
        ))

        # Art. 13 : Transparence envers les déployeurs
        instructions_provided = system_config.get("instructions_for_use", False)
        checks.append(ComplianceCheck(
            article="Art. 13",
            requirement="Instructions d'utilisation claires fournies aux déployeurs",
            status=ComplianceStatus.COMPLIANT if instructions_provided else ComplianceStatus.NON_COMPLIANT,
            evidence="Instructions OK" if instructions_provided else "Rédiger instructions d'usage",
            priority="majeur"
        ))

        return checks

    def compliance_score(self, checks: List[ComplianceCheck]) -> Tuple[float, str]:
        points = {ComplianceStatus.COMPLIANT: 1, ComplianceStatus.PARTIAL: 0.5,
                  ComplianceStatus.NON_COMPLIANT: 0, ComplianceStatus.NA: None}
        scored = [(c, points[c.status]) for c in checks if points[c.status] is not None]
        score = sum(s for _, s in scored) / len(scored) * 100 if scored else 0
        level = "Critique" if score < 50 else "Insuffisant" if score < 75 else "Partiel" if score < 90 else "Conforme"
        return round(score, 1), level

# --- Utilisation dans un pipeline MLOps ---
checker = AIActComplianceChecker()

# Configuration d'un agent IA de recrutement
agent_rh_config = {
    "risk_management_framework": True,
    "training_data_documented": True,
    "bias_evaluated": False,    # NON CONFORME
    "human_oversight_implemented": True,
    "human_override_possible": True,
    "decision_logging": False,    # NON CONFORME
    "instructions_for_use": True,
}

checks = checker.run_checks(agent_rh_config)
score, level = checker.compliance_score(checks)

print(f"Score de conformite AI Act : {score}% ({level})")
for c in checks:
    icon = "OK" if c.status == ComplianceStatus.COMPLIANT else "!!"
    print(f"  [{icon}] {c.article} — {c.requirement[:45]}... | {c.evidence}")
# Score: 60.0% (Insuffisant)
# [OK] Art. 9 — Système de gestion des risques ... | RMF documenté
# [!!] Art. 10 — Données d'entrainement documentées ... | Docs: OK | Biais: NON
# [OK] Art. 14 — Supervision humaine effective ... | Supervision et override OK
# [!!] Art. 12 — Logs automatiques des décisions ... | MANQUANT : activer logging
# [OK] Art. 13 — Instructions d'utilisation claires ... | Instructions OK

Ce type de checker automatisé, intégré dans les pipelines CI/CD et MLOps, permet de détecter les écarts de conformité avant le déploiement et de maintenir un tableau de bord de conformité en continu. Les plateformes de gouvernance IA du marché (IBM OpenPages, ServiceNow AI Governance, Credo AI, Holistic AI) proposent des fonctionnalités similaires avec des interfaces graphiques et des workflows d'approbation intégrés, ce qui facilite l'adoption par des équipes non techniques.

A Propos de l'Auteur

Ayi NEDJIMI • Expert Cybersécurité & IA

Avec plus de 20 ans d'expérience en cybersécurité et intelligence artificielle, Ayi NEDJIMI accompagne les entreprises dans leur transformation numérique sécurisée. Expert reconnu en conformité EU AI Act, gouvernance IA et sécurité des systèmes ML, il a mené plus de 100 missions pour des organisations du CAC 40, des scale-ups tech et des institutions gouvernementales.

Diplômé en cybersécurité et certifié en Cloud Security (AWS, Azure, GCP), Ayi combine une expertise technique pointue avec une vision stratégique business. Il intervient sur des projets de mise en conformité AI Act, de gouvernance IA, de déploiement de LLM en production et d'architecture de systèmes agentiques sécurisés.

20+Ans d'expérience

100+Missions réalisées

50+Entreprises accompagnées

Nous contacter Nos prestations Tous les articles IA Expertise Cyber