Gouvernance de l’IA : RGPD, AI Act et trust layer en production
La conformité IA ne se décrète pas dans un comité : elle se prouve en production, avec des logs, des évals et des pistes d’audit. Ce guide relie l’AI Act, le RGPD et le trust layer technique en une méthode opérationnelle, sans jargon ni promesses creuses.
En bref. Gouverner son IA, c’est articuler trois plans : l’AI Act (règlement UE 2024/1689) qui classe les systèmes par niveau de risque, le RGPD qui encadre les données personnelles, et le trust layer technique — ce que l’on appelle aussi observabilité de l’IA (AI observability), model governance et ML monitoring : logs, garde-fous, évals continues, contrôle des coûts et des accès, qui produisent la preuve en production. Selon le calendrier publié par la Commission, le règlement est entré en vigueur le 1er août 2024 et s’applique par paliers : interdictions depuis février 2025, obligations GPAI à compter du 2 août 2025, gros des obligations à haut risque à compter du 2 août 2026, certaines échéances en 2027. La fenêtre pour se préparer, c’est maintenant.
Le cadre
Qu’est-ce que la gouvernance de l’IA, concrètement ?
La gouvernance de l’IA est l’ensemble des règles, des rôles et des dispositifs techniques qui permettent de démontrer — à tout moment — qu’un système d’IA fait ce qu’il doit, reste fiable et respecte le droit. Ce n’est pas un document PowerPoint validé une fois pour toutes : c’est une couche vivante qui s’exécute en production. Trois plans se superposent et doivent être articulés ensemble.
Le plan réglementaire impose ce que vous devez prouver : l’AI Act (règlement UE 2024/1689) classe les systèmes par niveau de risque et fixe des obligations graduées, tandis que le RGPD encadre les données personnelles qui alimentent ou sortent de ces systèmes. Le plan organisationnel définit qui décide et qui répond : référent IA, DPO, métiers, sécurité. Le plan technique — le trust layer — produit la preuve : logs, traçabilité, garde-fous, évaluations continues, contrôle des coûts et des accès.
L’erreur classique est de traiter ces plans en silos : un juriste rédige une politique, une équipe data déploie un modèle, et personne ne vérifie que la politique est réellement appliquée par le système en ligne. La gouvernance utile est précisément le pont entre les trois. Le point de départ — souvent absent — est un simple inventaire : d’après nos missions d’audit, dans la majorité des cas l’organisation ne dispose pas, au démarrage, d’un inventaire complet et à jour de ses systèmes d’IA, alors que c’est la toute première pièce qu’un auditeur réclame. Le contexte sectoriel confirme cette immaturité : selon l’IAPP, AI Governance Profession Report, une majorité d’organisations n’ont structuré leur fonction de gouvernance IA que très récemment, ou prévoient de le faire à court terme.
AI Act : quelles obligations selon le niveau de risque ?
L’AI Act gradue vos obligations selon le niveau de risque du système d’IA, pas selon la technologie employée. La première question d’un audit n’est donc jamais « quel modèle utilisez-vous ? » mais « à quoi sert ce système, et qui peut-il affecter ? ». Quatre catégories structurent le règlement.
Comment classer un système d’IA selon l’AI Act ?
On classe un système en le rattachant à l’un des quatre niveaux de risque, du plus contraint au plus libre. La grille ci-dessous résume ce que recouvre chacun et ce qu’il implique concrètement.
Risque inacceptable
Pratiques interdites : notation sociale, manipulation comportementale, identification biométrique à distance en temps réel dans l’espace public (sauf exceptions strictes), catégorisation biométrique pour inférer des attributs sensibles, et moissonnage massif de visages. Aucune mise en conformité possible — le cas d’usage est proscrit.
Haut risque
Annexe III (RH, crédit, éducation, justice, infrastructures critiques…) et systèmes embarqués dans des produits réglementés (Annexe I). Exigences lourdes : gestion des risques, qualité des données, documentation technique, journalisation, supervision humaine, robustesse.
Risque limité
Chatbots, génération de contenu. Obligation principale de transparence : l’utilisateur doit savoir qu’il interagit avec une IA, et les contenus générés (textes, images, deepfakes) doivent être signalés.
Risque minimal
La grande majorité des usages internes (filtres, recommandations bénignes). Pas d’obligation spécifique, mais les bonnes pratiques de gouvernance restent recommandées.
Cas pratique — l’assistant de pré-tri de CV. Une ETI industrielle déploie un assistant LLM pour pré-trier les candidatures et proposer une liste courte aux recruteurs. L’équipe le voit comme « un simple chatbot » (risque limité). Erreur : un système qui participe à la sélection à l’embauche relève de l’Annexe III — haut risque. Il déclenche documentation technique, journalisation, supervision humaine effective, et une AIPD côté RGPD. D’après nos missions, ce type de requalification est fréquent : ce que le métier classe « limité » ressort souvent « haut risque ».
Modèles GPAI et responsabilités : fournisseur ou déployeur ?
Les modèles d’IA à usage général (GPAI) — les grands LLM comme Claude, Gemini ou Mistral — relèvent d’un régime propre de documentation et de transparence. Au-delà d’un certain volume de calcul d’entraînement, un modèle est présumé présenter un risque systémique et hérite d’obligations renforcées : évaluations, atténuation des risques, signalement des incidents graves, cybersécurité. Cette présomption s’appuie sur un seuil de calcul d’entraînement de l’ordre de 1025 FLOP.
Pour un dirigeant, le point décisif est la distinction fournisseur (provider) / déployeur (deployer). Le fournisseur conçoit ou met sur le marché le système ; le déployeur l’utilise sous sa propre autorité. Quand vous intégrez un LLM tiers dans votre produit ou vos processus, vous êtes le plus souvent déployeur — et porteur d’obligations propres (information des personnes, supervision humaine, usage conforme à la documentation). Si vous modifiez substantiellement un modèle GPAI, vous pouvez basculer fournisseur : la ligne de partage tient notamment au calcul mobilisé par la modification, apprécié par rapport au compute d’entraînement du modèle d’origine (de l’ordre d’un tiers selon les lignes directrices). Commercialiser le système sous votre propre marque produit le même effet.
Quel est le calendrier d’application de l’AI Act ?
Selon le calendrier publié par la Commission, le règlement est entré en vigueur le 1er août 2024 et s’applique par paliers. Les interdictions visant les pratiques à risque inacceptable sont applicables depuis février 2025. Les obligations relatives aux modèles GPAI s’appliquent à compter du 2 août 2025. Le gros des obligations applicables aux systèmes à haut risque s’applique à compter du 2 août 2026, et certaines échéances interviennent en 2027, notamment pour les systèmes embarqués dans des produits déjà réglementés. Des évolutions du cadre sont en discussion au niveau européen : à confirmer juridiquement au fil de leur adoption et de leur publication au JOUE.
Note de fraîcheur. Calendrier et seuils réglementaires de ce guide formulés au regard des textes publiés et du calendrier de la Commission. À jour au 18 juin 2026. Les jalons à venir restent à confirmer juridiquement en fonction des publications officielles.
Traduction opérationnelle : l’échéance arrive plus vite qu’on ne le croit. Constituer un inventaire des systèmes, leur classification et un trust layer auditable prend des mois, pas des semaines. Les entreprises qui attendent la dernière échéance découvriront qu’un système à haut risque ne se met pas en conformité a posteriori sans tout reconstruire.
Comment s’articulent RGPD et AI Act ?
RGPD et AI Act ne se substituent pas : ils se cumulent. L’AI Act régule le système ; le RGPD régule les données personnelles qui le traversent. Dès qu’un système d’IA traite des données personnelles — entraînement, prompts contenant des informations clients, sorties réidentifiables — les deux régimes s’appliquent simultanément.
Concrètement, un système RH à haut risque devra satisfaire l’AI Act (documentation, supervision humaine, journalisation) et le RGPD : base légale du traitement, minimisation des données, information des personnes, droits d’accès et d’opposition, encadrement de la décision automatisée (article 22, voir CNIL). Beaucoup d’obligations se recoupent utilement : une analyse d’impact relative à la protection des données (AIPD), exigée par l’article 35 du RGPD, nourrit directement la gestion des risques demandée par l’AI Act. Le piège inverse existe aussi : un transfert de données vers un LLM hébergé hors UE peut être conforme à l’AI Act mais violer le RGPD. La gouvernance consiste à fermer ces angles morts.
Règle pratique : avant tout déploiement, posez deux questions en parallèle. « Quel est le niveau de risque AI Act de ce système, et suis-je fournisseur ou déployeur ? » et « Quelles données personnelles transitent, où, et sous quelle base légale ? ». Si vous ne savez répondre clairement à l’une des deux, le système n’est pas prêt pour la production.
Qu’est-ce qu’un trust layer IA et que doit-il contenir au minimum ?
Le trust layer est la couche technique qui transforme une intention de conformité en preuve vérifiable. C’est notre terme maison pour ce que l’écosystème désigne par observabilité de l’IA (AI observability), model governance, ML monitoring et audit de l’IA. Sans lui, une politique de gouvernance reste une déclaration. Voici les quatre composants minimum d’une IA en production que vous pourrez défendre devant un auditeur, un client ou un régulateur.
Logs & pistes d’audit
Journalisation horodatée des entrées, sorties, versions de modèle et décisions, conservée de façon immuable. C’est la base de toute traçabilité exigée par l’AI Act.
Garde-fous
Guardrails sur les entrées et les sorties : filtrage des données sensibles, blocage des réponses hors périmètre, validation de format, supervision humaine sur les décisions critiques.
Évals continues
Jeux d’évaluation rejoués automatiquement à chaque évolution du modèle ou du prompt, avec seuils de qualité et tests de non-régression bloquant le déploiement en cas d’échec.
Coûts & accès
Suivi du coût d’inférence par cas d’usage, seuils d’alerte budgétaires, et contrôle granulaire des accès (qui peut interroger quel modèle avec quelles données).
Comment outiller la supervision humaine (human-in-the-loop) ?
Une supervision humaine se matérialise par des mécanismes mesurables, pas par une mention dans une politique. Concrètement : des seuils de confiance qui routent automatiquement vers un humain toute sortie en dessous d’un score donné ; des files de revue (review queues) où un opérateur valide, corrige ou rejette les cas critiques avant qu’ils ne produisent un effet ; un taux d’override (part des décisions IA modifiées par l’humain) suivi dans le temps comme indicateur de fiabilité ; et un kill switch permettant de suspendre le système. Si l’override est proche de 0 %, soit l’IA est excellente, soit la revue est fictive : c’est précisément la nuance qu’un auditeur cherche à vérifier. C’est aussi ce qui distingue un cabinet d’industrialisation d’un cabinet conseil : la supervision est instrumentée, pas seulement écrite.
Cette couche n’est pas un projet à part : elle s’intègre à votre architecture d’orchestration. Elle prolonge aussi le travail de cartographie des données pour l’IA, qui identifie ce qui transite et sous quelle base légale. Et c’est exactement le périmètre de notre offre Run, Ops & gouvernance IA, qui opère ce trust layer dans la durée.
Évaluation des LLM, drift et non-régression : comment garder le contrôle ?
On garde le contrôle en mesurant la qualité en continu, jamais en se fiant à un test unique au lancement. Une IA conforme au démarrage peut devenir non conforme en silence : les fournisseurs mettent à jour leurs modèles, vos données évoluent, les usages dérivent. Sans mesure continue, vous ne le saurez qu’au moment de l’incident — souvent signalé par un client mécontent ou un journaliste.
À quoi servent les évals d’un LLM ?
Une eval LLM est un jeu de tests reproductible qui mesure automatiquement la qualité des réponses d’un modèle face à des cas représentatifs, selon des critères objectifs (exactitude, format, absence d’hallucination, respect des garde-fous). On rejoue ces évals à chaque changement de modèle ou de prompt, et on bloque la mise en production si le score descend sous le seuil défini : c’est un test de non-régression appliqué à l’IA. Sans évals, « ça marche mieux » n’est qu’une opinion ; avec elles, c’est une métrique défendable devant un auditeur.
Comment détecter la dérive (drift) d’un modèle en production ?
On détecte le drift en instrumentant les distributions d’entrées (les questions changent-elles ?), de sorties (les réponses dérivent-elles ?) et de qualité (le taux d’échec aux évals augmente-t-il ?). Une variation significative déclenche une alerte et une investigation avant que les utilisateurs ne soient affectés. La détection de drift est ce qui distingue une IA supervisée d’une IA simplement déployée.
Qui fait quoi : référent IA, DPO et métiers ?
La gouvernance échoue presque toujours par défaut de responsabilité claire, pas par manque d’outils. Trois rôles doivent être nommément attribués, avec un mandat écrit.
Référent IA
Tient l’inventaire des systèmes, leur classification AI Act, le statut fournisseur/déployeur, la documentation et le suivi des évals. Point de contact unique pour toute question de conformité IA.
DPO
Garde la main sur les données personnelles : bases légales, AIPD, droits des personnes, transferts. Travaille en binôme avec le référent IA sur les systèmes à haut risque.
Métiers & sécurité
Le métier valide la pertinence et la supervision humaine ; la sécurité gère accès, secrets et exposition. La gouvernance est un sport d’équipe, pas une affaire de juriste isolé.
Ce que la non-conformité coûte vraiment
À noter : tous les manquements ne plafonnent pas à 35 M€ / 7 %. Ce niveau vise les usages interdits ; les manquements aux obligations haut risque et aux obligations des fournisseurs de modèles GPAI relèvent d’un palier distinct de 15 M€ ou 3 % du CA mondial. Croire que le plafond unique s’applique partout est une erreur fréquente.
Comment auditer une IA ? La checklist de conformité
Pour auditer une IA, on déroule une checklist actionnable, point par point, avant et pendant la mise en production. Si une case reste vide, vous tenez votre prochaine priorité — et exactement ce qu’un contrôle exhibera en premier.
- Inventaire des systèmes d’IA, classification du niveau de risque AI Act et statut fournisseur/déployeur pour chacun
- Cartographie des données personnelles traitées, base légale et AIPD (article 35 RGPD) si nécessaire
- Documentation technique et de transparence à jour (finalité, limites, données, supervision)
- Logs immuables et pistes d’audit couvrant entrées, sorties et versions de modèle
- Garde-fous entrées / sorties et supervision humaine outillée (seuils de confiance, files de revue, taux d’override) sur les décisions critiques
- Jeux d’évals avec seuils et tests de non-régression rejoués à chaque mise à jour
- Détection de drift instrumentée, avec alerting et procédure d’investigation
- Suivi des coûts d’inférence et contrôle granulaire des accès aux modèles
- Rôles nommés : référent IA, DPO, validation métier, sécurité
- Information des utilisateurs sur l’usage d’une IA et signalement des contenus générés
Cette checklist s’inscrit dans une démarche plus large d’industrialisation : voir Passer un POC d’IA en production : la checklist d’industrialisation. Pour faire le point sur votre situation, un diagnostic & cadrage court et à prix fixe pose un état des lieux objectif en quelques jours.
Les pièges à éviter en gouvernance IA
Voici les écueils que nous rencontrons le plus souvent sur le terrain — ceux qui transforment une conformité de façade en risque réel.
- La gouvernance-document. Une politique magnifique que rien, dans le système en ligne, ne vient appliquer ni mesurer. Si vous ne pouvez pas extraire un log, vous n’êtes pas conforme.
- Le « ce n’est qu’un chatbot ». Sous-estimer la classification : un assistant qui pré-trie des candidatures bascule en haut risque (Annexe III), pas en risque limité.
- Croire qu’on n’est « que » déployeur. Intégrer un LLM tiers ne vous exonère pas : le déployeur porte ses propres obligations, et une modification substantielle d’un modèle GPAI peut vous faire basculer fournisseur.
- Oublier les transferts hors UE. Envoyer des prompts contenant des données clients vers un LLM hébergé hors UE : conforme AI Act, mais violation RGPD si l’encadrement des transferts manque.
- Le « set and forget ». Déployer sans évals continues ni détection de drift, puis découvrir la dérive plusieurs mois plus tard via une plainte.
- La responsabilité diluée. Personne n’est nommément référent IA : en cas de contrôle, chacun se renvoie la balle et la documentation est introuvable.
La gouvernance doit aussi descendre jusqu’à la donnée qui alimente vos systèmes : notre guide sur la cartographie des données pour l’IA détaille comment tracer les flux avant même de parler de modèle.
Questions fréquentes
Mon entreprise est-elle concernée par l’AI Act ?
Dès lors que vous concevez, mettez sur le marché ou exploitez un système d’IA touchant l’UE — y compris en branchant un LLM tiers — vous entrez dans le champ du règlement. Ce qui varie, c’est l’intensité des obligations : elle dépend du niveau de risque du cas d’usage et de votre rôle (fournisseur ou déployeur). Première action concrète : classer chaque usage parmi les quatre niveaux (inacceptable, haut, limité, minimal).
Quel est le calendrier d’application de l’AI Act ?
Selon le calendrier publié par la Commission, le règlement est entré en vigueur le 1er août 2024 et s’applique par paliers : les interdictions visant les pratiques à risque inacceptable depuis février 2025, les obligations GPAI à compter du 2 août 2025, le gros des obligations à haut risque à compter du 2 août 2026, et certaines échéances en 2027. Des évolutions du cadre sont en discussion au niveau européen et restent à confirmer après adoption et publication au JOUE.
Comment articuler RGPD et AI Act sans tout dédoubler ?
Inutile de mener deux chantiers parallèles étanches : les régimes se cumulent mais leurs exigences se chevauchent largement. Une AIPD solide (article 35 RGPD) alimente directement la gestion des risques de l’AI Act. La bonne pratique : un binôme référent IA / DPO qui pilote les deux dès la phase de conception sur tout système à haut risque.
Qu’est-ce qu’un trust layer et est-il obligatoire ?
C’est l’outillage technique qui matérialise la preuve : journalisation immuable, pistes d’audit, garde-fous, évals continues, maîtrise des coûts et des accès. On parle aussi d’observabilité de l’IA (AI observability), de model governance ou de ML monitoring. Le terme « trust layer » ne figure pas dans la loi, mais chacun de ses composants répond point par point aux exigences de traçabilité, de robustesse et de supervision de l’AI Act. En pratique, sans cette couche, vous ne pouvez pas démontrer votre conformité.
Quelles sont les sanctions prévues par l’AI Act ?
Le règlement prévoit plusieurs niveaux : le plus élevé, jusqu’à 35 M€ ou 7 % du chiffre d’affaires mondial, frappe les usages interdits ; un palier intermédiaire de 15 M€ ou 3 % vise les manquements haut risque et les obligations des fournisseurs GPAI ; un niveau plus bas sanctionne les informations inexactes fournies aux autorités. À cela s’ajoute, de façon indépendante, le plafond RGPD de 20 M€ ou 4 %.
Comment auditer une IA déjà en production ?
Commencez par l’inventaire et la classification AI Act de chaque système, puis remontez la chaîne de preuve : les logs sont-ils immuables et exploitables ? Les garde-fous filtrent-ils réellement ? Existe-t-il des évals avec seuils, une détection de drift, une supervision humaine instrumentée (taux d’override suivi) et des rôles nommés ? La checklist de cet article fournit une trame d’audit prête à l’emploi.
Passez de l’expérimentation à l’IA en production
Commencez par un diagnostic court à prix fixe : maturité, cas d’usage à fort ROI, et une roadmap priorisée. Sans engagement.