+190 XP

Le risque IA et l'AI Act européen

En 2023, un scandale de l'administration fiscale néerlandaise, la *toeslagenaffaire*, a provoqué la démission d'un gouvernement entier. Le déclencheur : un algorithme qui signalait des familles pour fraude aux allocations de garde d'enfants, ciblant de façon disproportionnée les ménages binationaux, et réclamait le remboursement de sommes à des dizaines de milliers de personnes innocentes. Aucun CDO n'a validé un « système d'IA à haut risque ». Ils ont validé un modèle de détection de fraude. C'est précisément cet écart, entre la façon dont le métier étiquette un système et la façon dont un régulateur le fera, que l'AI Act européen cartographie aujourd'hui. Votre travail n'est pas d'apprendre le texte par cœur. C'est de construire une fonction de triage qui vous dit, un lundi quelconque, lesquels de vos 200 modèles pourraient devenir la *toeslagenaffaire* de demain et lesquels sont suffisamment ennuyeux pour être laissés tranquilles.

Le recadrage central : le risque réside dans le cas d'usage, pas dans le modèle

L'erreur la plus coûteuse qu'un CDO commet avec l'AI Act est de gouverner à la mauvaise altitude. Les équipes demandent instinctivement « ce modèle est-il risqué ? ». Le texte pose une autre question : « **à quoi ce système *sert-il*, et sur qui ? »**

Le même classifieur à gradient boosting n'est pas régulé lorsqu'il classe des leads marketing et devient à haut risque lorsqu'il filtre des candidatures. La technologie est identique. Le niveau de risque est entièrement déterminé par le contexte de déploiement. C'est pour cela que la gouvernance centrée sur le modèle échoue : vous ne pouvez pas inspecter un fichier .pkl et en déduire son exposition réglementaire. Vous devez le relier à une décision qui affecte l'accès d'un humain à l'emploi, au crédit, à l'éducation, aux services essentiels ou à la liberté.

Le texte classe les systèmes en quatre niveaux, et votre modèle opérationnel doit les refléter précisément :

  • Risque inacceptable (interdit) : notation sociale par les autorités publiques, identification biométrique à distance en temps réel dans les espaces publics (avec des exceptions restreintes), reconnaissance des émotions sur le lieu de travail et à l'école, techniques subliminales manipulatoires. Il ne s'agit pas de « gouverner avec soin », mais de « ne pas construire ». Depuis février 2025, ces interdictions sont déjà en vigueur.
  • Haut risque : systèmes utilisés dans l'emploi, la solvabilité, les services publics et privés essentiels, l'éducation, les infrastructures critiques, les forces de l'ordre, la migration et l'administration de la justice. Également les produits ou composants de sécurité déjà couverts par le droit européen de la sécurité des produits. Ce niveau porte tout le poids des obligations du texte.
  • Risque limité : systèmes qui interagissent avec des humains (chatbots) ou génèrent du contenu synthétique. L'obligation est essentiellement de transparence : dire aux gens qu'ils ont affaire à une IA, étiqueter les deepfakes.
  • Risque minimal : tout le reste, filtres antispam, optimisation des stocks, moteurs de recommandation pour le retail. Aucune obligation contraignante. C'est là que vit la grande majorité de votre portefeuille, et là où la sur-gouvernance détruit silencieusement de la valeur.

L'enseignement stratégique : le texte est conçu pour concentrer l'attention. Si votre programme de gouvernance traite les 200 modèles avec la même rigueur, vous avez mal lu toute l'intention réglementaire. La proportionnalité n'est pas un bonus ; c'est le principe opérationnel que les législateurs ont inscrit dans le texte.

Surveillez la couche des modèles de fondation séparément

Il existe une cinquième piste qui traverse les niveaux : les modèles d'IA à usage général (GPAI), y compris les grands modèles de langage. Si vous construisez au-dessus d'un modèle de fondation, certaines obligations incombent au fournisseur (OpenAI, Anthropic, Mistral). Mais si vous procédez à un fine-tuning substantiel, ou si le modèle dépasse le seuil de calcul du risque systémique (10²⁵ FLOPs), des obligations peuvent vous revenir. Le geste pratique du CDO : tenir un registre des modèles de fondation que vous consommez, du fait que vous les fine-tunez ou non, et de la documentation fournie par le fournisseur. Quand votre équipe juridique demande « sommes-nous fournisseur ou déployeur de ce système GPAI ? », il vous faut la réponse dans un tableur, pas au terme de fouilles archéologiques dans Slack.

Construire la fonction de triage : de 200 systèmes à une file priorisée

Voici le problème du lundi matin. Vous avez un inventaire IA (si ce n'est pas le cas, c'est la leçon prérequise). Vous devez maintenant classer chaque entrée dans un niveau sans recruter une équipe juridique pour passer en revue chaque modèle. La réponse est un funnel en deux étapes : un filtre automatisé peu coûteux, puis une adjudication humaine pour tout ce qui déclenche une alerte.

Étape un, le questionnaire de filtrage. Rattachez cinq questions à chaque système de votre registre, auxquelles répond le product owner, pas le data scientist :

  1. Le système prend-il, ou informe-t-il matériellement, une décision concernant une personne précise ?
  2. Cette décision affecte-t-elle son accès à l'emploi, au crédit, à l'éducation, à la santé, aux prestations sociales ou à son statut juridique ?
  3. Le système est-il utilisé par les forces de l'ordre, les services de migration ou le système judiciaire ?
  4. Utilise-t-il des données biométriques ou infère-t-il des caractéristiques émotionnelles / protégées ?
  5. Interagit-il directement avec une personne ou génère-t-il des médias synthétiques ?

Tout « oui » aux questions 3 ou 4 déclenche une escalade immédiate. Un « oui » à la question 1 *et* à la 2 signale un haut risque. Un « oui » uniquement à la question 5 signale des obligations de transparence pour risque limité. Tout en « non » atterrit en risque minimal. Vous pouvez encoder cela sous forme de table de décision pour que la classification soit reproductible et auditable, et non une affaire d'opinion :

yaml
# ai_risk_triage_rules.yaml — classifieur déterministe de premier passage
rules:
  - id: prohibited_check
    if: uses_social_scoring OR realtime_biometric_public OR workplace_emotion_recognition
    then: PROHIBITED           # arrêt : revue juridique avant tout travail supplémentaire
  - id: high_risk_domain
    if: affects_individual AND domain in [employment, credit, education,
         essential_services, critical_infra, law_enforcement, migration, justice]
    then: HIGH_RISK
  - id: transparency_only
    if: interacts_with_human OR generates_synthetic_content
    then: LIMITED_RISK
  - id: default
    then: MINIMAL_RISK
review:
  HIGH_RISK: mandatory_human_adjudication   # jamais de décision automatique finale sur le haut risque
  PROHIBITED: mandatory_human_adjudication

L'intérêt de cette configuration n'est pas la syntaxe, c'est la discipline. La classification devient un artefact de politique que vous pouvez versionner, auditer et défendre devant un régulateur, au lieu d'un jugement qui s'évapore quand l'analyste qui l'a porté quitte l'entreprise.

Étape deux, l'adjudication humaine. Ne laissez jamais le filtre automatisé finaliser un label « haut risque » ou « interdit ». Les cas limites sont là où se joue l'argent. Un modèle de crédit qui ne produit qu'un score de risque interne qu'un chargé de prêt humain peut outrepasser peut être ou non à haut risque selon le degré réel de déférence de l'humain envers lui. C'est la question du « contrôle humain effectif », et elle se tranche sur la réalité opérationnelle, pas sur le théâtre de l'organigramme. Si vos chargés de prêt approuvent 99,3 % des recommandations du modèle, vous n'avez pas de contrôle humain, vous avez un tampon avec un pouls, et un régulateur traitera le système comme étant à haut risque.

The EU AI Act Explained for Practitioners

Watch on YouTube

Ce que le « haut risque » vous coûte réellement sur le plan opérationnel

Quand un système atterrit dans le niveau haut risque, le texte impose une pile de conformité spécifique. En tant que CDO, vous devez savoir ce que chaque obligation exige de vos équipes :

  • Système de gestion des risques : un processus continu et documenté, pas une validation ponctuelle. Prévoyez des effectifs en continu.
  • Gouvernance des données : les jeux de données d'entraînement, de validation et de test doivent être pertinents, représentatifs et examinés pour détecter les biais. C'est là que votre fonction de gouvernance existante porte ses fruits, mais il vous faut désormais une preuve documentée de l'examen, pas seulement la pratique.
  • Documentation technique et journalisation : le système doit journaliser automatiquement son fonctionnement pour permettre la traçabilité. Concevez-le dès le départ ; ajouter la journalisation à un modèle en production est brutal.
  • Transparence envers les déployeurs : des instructions d'utilisation claires.
  • Contrôle humain : intégré, pas rajouté.
  • Exactitude, robustesse, cybersécurité : seuils de performance documentés et résilience aux attaques adverses.
  • Évaluation de la conformité avant la mise sur le marché, et enregistrement dans la base de données européenne.

La distinction critique que la plupart des CDO manquent : êtes-vous fournisseur ou déployeur ? Si vous développez le système à haut risque (ou en modifiez un substantiellement), vous portez l'intégralité des obligations du fournisseur. Si vous utilisez simplement le système à haut risque d'un tiers, vous êtes déployeur avec un jeu d'obligations plus léger mais bien réel : assurer le contrôle humain, surveiller le fonctionnement, conserver les logs et l'utiliser conformément aux instructions. La plupart des entreprises sont simultanément déployeurs d'outils fournisseurs et fournisseurs de leurs développements internes. Votre registre doit indiquer quelle casquette vous portez pour chaque système, car les obligations et la responsabilité diffèrent fortement.

Vérification des acquis

1. Selon la leçon, qu'est-ce qui détermine fondamentalement le niveau de risque d'un système d'IA au titre de l'AI Act européen ?

2. Pourquoi la leçon soutient-elle que la gouvernance centrée sur le modèle échoue ?

3. Une équipe déploie un classifieur à gradient boosting pour filtrer des candidatures. Selon le cadrage de l'AI Act européen présenté dans la leçon, comment ce système doit-il être traité ?

CHOIX MULTIPLES

4. Sélectionnez TOUS les éléments suivants qui relèvent du niveau « risque inacceptable » (interdit) au titre de l'AI Act européen tel que décrit dans la leçon.

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les affirmations qui reflètent correctement les points clés de la leçon sur l'application de l'AI Act européen.

Sélectionnez toutes les réponses correctes.

La proportionnalité comme principe de conception, pas comme réflexion tardive

Cette leçon existe parce que la peur produit une mauvaise gouvernance. Quand on cite les amendes, jusqu'à 35 M€ ou 7 % du chiffre d'affaires mondial pour les violations liées aux systèmes interdits, l'instinct des dirigeants est de tout verrouiller. Cet instinct vous rendra plus lent que vos concurrents sur les 90 % de votre portefeuille qui sont à risque minimal, tout en vous donnant le faux confort d'avoir « fait de la gouvernance IA ».

La posture mature consiste en des contrôles gradués qui correspondent aux niveaux de risque. Concrètement :

  • Systèmes à risque minimal : enregistrez-les, appliquez vos pratiques standards de qualité des données et de monitoring des modèles, et passez à autre chose. Pas d'évaluation de conformité, pas de documentation spéciale. Ne laissez pas un comité des risques bien intentionné inventer des obligations que le texte n'exige pas.
  • Systèmes à risque limité : mettez en œuvre la divulgation de transparence et vérifiez qu'elle se déclenche effectivement. Le mode d'échec ici, c'est un chatbot qui ne dit jamais aux utilisateurs qu'il est un bot, ou des images générées sans étiquette de provenance. Peu coûteux à corriger, gênant à rater.
  • Systèmes à haut risque : toute la pile ci-dessus, plus, et c'est là la véritable valeur ajoutée du CDO, un *gate avant déploiement*. Aucun système à haut risque ne part en production sans validation de l'évaluation de conformité. Câblez cela dans votre pipeline de release comme un blocage dur, exactement comme vous bloqueriez un déploiement qui échoue au scan de sécurité.

Regardez comment Klarna a abordé son IA de service client. Quand ils ont déployé un assistant à grande échelle, le système interagit directement avec les clients, un déclencheur de transparence pour risque limité, pas de haut risque, car il traite des demandes de service et non des décisions de crédit. Leurs modèles d'octroi de crédit, en revanche, se situent clairement en haut risque. Même entreprise, même investissement IA, deux régimes de gouvernance entièrement différents. Un CDO qui gouverne les deux à l'identique a soit étranglé le chatbot, soit sous-protégé le moteur d'octroi. La proportionnalité, c'est réussir cette séparation.

Le calendrier est votre contrainte de planification

Le texte entre en application par étapes, et votre roadmap doit s'y séquencer :

  • Février 2025 : interdictions des pratiques prohibées et obligations de littératie IA déjà en vigueur.
  • Août 2025 : les obligations relatives aux modèles GPAI s'appliquent.
  • Août 2026 : l'essentiel des obligations haut risque s'applique.
  • Août 2027 : obligations haut risque pour l'IA intégrée dans des produits réglementés.

Cet échelonnement est un cadeau. Il vous dit exactement où dépenser d'abord : confirmer que vous n'avez aucun système interdit (existentiel), puis inventorier vos dépendances GPAI, puis construire la pile de conformité haut risque avant l'échéance de 2026. Un CDO qui place en premier l'audit des systèmes interdits et repousse la construction de la documentation haut risque séquence intelligemment. Celui qui essaie de tout traiter au premier trimestre brûle sa crédibilité.

Là où se situe vraiment le jugement

Le texte vous donne des niveaux ; il ne vous donne pas de certitude aux frontières. Les véritables arbitrages du CDO sont :

  • Haut risque limite : un outil RH qui « suggère » des questions d'entretien, « informe-t-il matériellement » une décision d'emploi ? En cas de doute, traitez-le provisoirement comme à haut risque et laissez le juridique argumenter pour le déclasser. Il est bien moins coûteux de sur-documenter et de reclasser que de sous-documenter et de reconstruire l'historique sous pression réglementaire.
  • Modification substantielle : si vous fine-tunez fortement un modèle fournisseur, vous pouvez devenir le fournisseur. Fixez avec le juridique un seuil pour ce que « substantiel » signifie dans votre contexte, et journalisez chaque modification par rapport à ce seuil.
  • Portée extraterritoriale : le texte s'applique si le résultat de votre système est utilisé dans l'UE, même si votre siège est ailleurs. Un CDO basé aux États-Unis ne peut pas considérer que c'est le problème de quelqu'un d'autre.

Points clés

  1. Classez par cas d'usage, pas par modèle. Construisez un filtre de triage déterministe relié à votre registre IA, qui oriente chaque système vers un niveau selon les personnes qu'il affecte et la décision qu'il pilote, pas selon sa sophistication technique.
  2. Auditez d'abord les systèmes interdits, dès ce trimestre. Les interdictions sont déjà en vigueur et portent les amendes les plus élevées. Tout le reste est un problème de planification ; celui-ci est existentiel.
  3. Étiquetez fournisseur ou déployeur pour chaque système. Vos obligations et votre responsabilité divergent fortement, et la plupart des entreprises sont les deux à la fois. Intégrez-le au registre dès maintenant.
  4. Alignez l'intensité des contrôles sur le niveau de risque, et protégez les 90 % à risque minimal de la sur-gouvernance. La proportionnalité est le principe opérationnel du texte ; l'enfreindre vers le bas est illégal, l'enfreindre vers le haut vous rend simplement lent.
  5. Câblez un gate dur avant déploiement pour les systèmes à haut risque dans votre pipeline de release avant l'échéance d'août 2026, et concevez la journalisation et la documentation dès le départ : les ajouter à des modèles en production est le chemin le plus coûteux.

Articles liés

Les articles récents du blog qui s'appuient sur cette leçon.