Calendrier réel des obligations de l'EU AI Act (2025-2027), niveaux de risque, place d'un assistant RAG d'entreprise et checklist de conformité concrète — sans jargon, pour DPO et équipes produit.
L'EU AI Act est trop souvent rangé dans la case « problème de juristes » — une contrainte abstraite qu'on traitera « plus tard ». C'est une erreur de cadrage. Ce règlement structure dès aujourd'hui la façon dont vous concevez, documentez et exploitez un système d'IA, y compris un simple assistant RAG branché sur votre documentation interne. Les équipes qui l'intègrent en amont gagnent un avantage : elles évitent de refactoriser sous la contrainte, et elles transforment la conformité en argument commercial.
Voici, sans jargon inutile, ce que l'AI Act change concrètement, quand les obligations tombent, et une checklist opérationnelle pour un système d'IA d'entreprise.
L'AI Act ne régule pas « l'IA » en bloc. Il classe les usages selon le risque qu'ils font peser sur les droits des personnes, et calibre les obligations en conséquence. Quatre niveaux :
Le réflexe clé n'est pas « est-ce que je fais de l'IA ? » mais « dans quel niveau de risque tombe chacun de mes usages ? ». La réponse dicte tout le reste.
Concrétisons avec des exemples que vous rencontrerez en entreprise :
La frontière qui compte en pratique se situe entre risque limité et risque élevé. C'est là que se jouent la majorité des arbitrages d'une entreprise qui déploie de l'IA générative.
Le texte est entré en vigueur le 1er août 2024, mais ses obligations s'appliquent par vagues. Retenez ces jalons :
Concrètement : si vous déployez en 2026, les obligations de transparence et la classification de risque ne sont plus optionnelles. Et si l'un de vos usages est à haut risque, le compte à rebours pour la documentation technique est déjà lancé.
L'obligation de littératie en IA, applicable depuis février 2025, est la plus sous-estimée. Elle ne se règle pas avec une charte signée vite fait. Elle implique que les personnes qui conçoivent, déploient et utilisent vos systèmes d'IA comprennent leurs capacités, leurs limites et les risques associés. Pour un assistant RAG, cela veut dire que vos agents de support savent que l'IA peut « halluciner », qu'elle ne remplace pas leur jugement, et qu'ils doivent vérifier les réponses sensibles. Une session de formation tracée, adaptée aux rôles, suffit généralement — mais elle doit exister et être documentée.
C'est la question pratique qui intéresse la plupart des lecteurs. Un assistant interne qui répond aux questions des employés à partir de votre documentation, ou un copilote de support client, relève le plus souvent du risque limité. Vos obligations principales sont alors de l'ordre de la transparence :
Mais attention aux bascules en haut risque. Le même socle technique (un RAG) peut basculer selon l'usage :
La technologie ne décide pas du niveau de risque : l'usage le décide. Le même pipeline RAG est « risque limité » pour une FAQ interne et « haut risque » pour un tri de candidatures.
Une entreprise SaaS déploie un assistant qui répond aux clients à partir de sa documentation produit et de sa base de tickets résolus. Il ne prend aucune décision sur une personne : il informe, il oriente, il escalade vers un humain quand il ne sait pas. Risque limité. Ses obligations tiennent en quelques lignes : un bandeau « Vous échangez avec un assistant IA », un marquage des réponses générées, une page interne décrivant les sources mobilisées et un canal pour atteindre un conseiller humain. Rien d'écrasant pour une équipe d'ingénierie sérieuse.
La même entreprise étend l'assistant aux ressources humaines. Première version : il répond aux salariés sur leurs congés et leur mutuelle — toujours du risque limité. Puis l'équipe ajoute une fonction qui classe et note les candidatures reçues pour un poste, en s'appuyant sur le même pipeline RAG. À cet instant précis, l'usage bascule en haut risque : le recrutement figure explicitement dans les domaines sensibles de l'AI Act. Le périmètre d'obligations change du tout au tout : système de gestion des risques formalisé, documentation technique complète, exigences de qualité et de représentativité des données d'entraînement et de contexte, supervision humaine effective sur chaque décision, journalisation de longue durée, et information claire des candidats. Une simple fonctionnalité ajoutée à un produit existant peut donc déplacer tout le projet d'un régime à l'autre. D'où l'importance de reclasser le risque à chaque évolution fonctionnelle, pas seulement au lancement.
Pour un système à haut risque, la documentation technique n'est pas une formalité : c'est la preuve, opposable, que vous maîtrisez votre système. Elle doit notamment couvrir :
Bonne nouvelle pour les praticiens RAG : une grande partie de ce contenu existe déjà sous forme de décisions d'ingénierie. Vos paramètres de chunking, votre stratégie de récupération hybride, vos seuils de pertinence, votre golden set d'évaluation — tout cela est la documentation technique, à condition de l'écrire au fil de l'eau plutôt que de la reconstituer en panique. Versionnez ces décisions dans le dépôt, à côté du code, et la documentation se construit presque toute seule.
La transparence ne se résume pas à enfouir une phrase dans des CGU. Quelques formulations qui fonctionnent :
La meilleure mention de transparence est celle qui rend service à l'utilisateur en même temps qu'elle vous met en conformité. Citer ses sources coche la case réglementaire et réduit les hallucinations perçues.
Erreur fréquente : croire qu'être conforme au RGPD suffit. Les deux textes poursuivent des objectifs différents et se cumulent.
Un assistant RAG peut donc devoir, simultanément : disposer d'une base légale RGPD pour les données ingérées, faire l'objet d'une AIPD si nécessaire, et respecter les obligations de transparence de l'AI Act. Les deux documentations se nourrissent l'une l'autre, mais ne se substituent pas.
Concrètement, ces deux livrables se recoupent mais ne se confondent pas :
En pratique, sur un projet RAG à haut risque, on mène les deux en parallèle et on les fait pointer l'un vers l'autre. L'AIPD décrit le corpus ingéré contenant des données personnelles et leur base légale ; la documentation technique décrit comment le pipeline traite ce corpus, avec quels garde-fous. Mener une seule des deux démarches vous laisse exposé sur l'autre régime.
Voici une checklist concrète à dérouler pour un système d'IA d'entreprise. Elle ne remplace pas l'avis de votre juriste, mais elle vous fait poser les bonnes questions au bon moment.
Bonne nouvelle : pour un assistant RAG bien conçu (sources maîtrisées, réponses sourcées, hébergement souverain, journalisation), l'essentiel de cette checklist est déjà couvert par de bonnes pratiques d'ingénierie.
L'AI Act fait peur parce qu'on le lit comme une liste d'interdits. Vu autrement, il formalise ce qu'une entreprise sérieuse devrait déjà faire : savoir où vivent ses données, tracer ses traitements, garder un humain dans la boucle pour les décisions sensibles, et dire la vérité à ses utilisateurs. Ces exigences construisent la confiance — celle de vos clients comme celle de vos régulateurs.
Plutôt que d'attendre l'échéance d'août 2026, classez vos usages dès maintenant, documentez au fil de l'eau, et faites de la transparence un trait de votre produit. La conformité devient alors un actif commercial, pas une dette technique. Dans un appel d'offres, pouvoir présenter sur demande votre classification de risque, votre documentation technique et votre politique de supervision humaine vous distingue immédiatement d'un concurrent qui découvre le sujet. La conformité, traitée tôt, n'est pas un coût : c'est une barrière à l'entrée que vous érigez face à ceux qui l'ont négligée.
Les agents IA gérés par les grands hyperscalers américains posent un problème de conformité que beaucoup de DSI préfèrent ignorer. Faisons le point.
Anonymiser ou pseudonymiser avant de vectoriser ? La distinction RGPD, pourquoi l'anonymisation parfaite est rare sur du texte libre, les techniques (NER, pseudonymisation cohérente) et les réflexes à adopter.
Le guide de conformité RGPD pour vos projets RAG : base légale, minimisation, données personnelles dans les embeddings et les prompts, droit à l'effacement qui cascade jusqu'aux vecteurs, sous-traitants et articulation avec l'AI Act.
Démarrez gratuitement. Premier audit Knowledge Pulse en 60 secondes.
Démarrer gratuitement