IA conforme RGPD 2026 : l'architecture qui rassure le DPO

En mars 2026, le Conseil d’État a validé l’hébergement des données de santé du SNDS par Microsoft, tout en reconnaissant qu’une partie des données techniques d’administration pouvait, en cas de nécessité, être consultée depuis des administrateurs situés aux États-Unis. La plus haute juridiction administrative l’a jugé acceptable au vu des garanties contractuelles. Votre DPO, lui, n’a pas ce luxe d’arbitrage : un risque résiduel d’accès suffit à bloquer un projet.

C’est le vrai sujet quand un projet d’IA générative arrive sur le bureau du DPO ou de la DSI. La conformité d’un système qui lit vos documents internes ne se démontre pas par une clause de contrat, elle se démontre par une architecture. Une IA est conforme par conception quand la donnée ne peut techniquement pas quitter votre infrastructure, et quand chaque requête laisse une trace auditable. Le reste relève de la promesse.

Cet article explique pourquoi un DPO bloque, ce qui distingue une conformité contractuelle d’une conformité architecturale, quelle architecture rend une IA réellement souveraine, comment cette architecture devient auditable, et comment associer DSI et DPO sans enliser le projet.

Pourquoi un DPO bloque-t-il un projet d’IA générative ?

Un DPO bloque un projet d’IA générative parce qu’il engage sa responsabilité sur un traitement dont il ne maîtrise ni la localisation des données, ni les accès de tiers. Dès qu’un document interne part dans un service cloud grand public, il quitte généralement l’Union européenne sans contrat de sous-traitance ni encadrement du transfert. Si ce document contient des données personnelles, le traitement échappe à ce que le RGPD impose, et c’est le DPO qui devra le justifier en cas de contrôle.

Le point dur tient au droit applicable au prestataire, pas à l’adresse du serveur. La loi américaine CLOUD Act, adoptée en 2018, permet aux autorités des États-Unis d’exiger d’une entreprise de droit américain l’accès à des données qu’elle détient, quelle que soit leur localisation, y compris dans un centre de données situé en France. Héberger « en Europe » chez un fournisseur soumis au droit américain ne neutralise donc pas le risque : il le déplace, comme l’a précisément illustré la réserve formulée par le Conseil d’État.

Le DPO porte par ailleurs une obligation concrète. L’article 35 du RGPD impose une analyse d’impact relative à la protection des données (AIPD) pour tout traitement susceptible d’engendrer un risque élevé. La CNIL a listé quatorze types d’opérations pour lesquels cette analyse est obligatoire (délibérations n° 2018-326 et 2018-327 du 11 octobre 2018). Un agent IA branché sur la connaissance interne d’une entreprise tombe très vite dans ce périmètre. Le DPO ne bloque pas par excès de prudence : il bloque parce qu’on lui demande de garantir l’ingarantissable sur une architecture cloud externe.

Conformité par contrat ou par architecture : quelle différence ?

La différence est celle qui sépare une promesse d’une impossibilité. Une conformité contractuelle repose sur l’engagement d’un prestataire à ne pas faire quelque chose qu’il pourrait techniquement faire. Une conformité architecturale repose sur le fait que la chose interdite est techniquement impossible. Pour un DPO, la seconde se vérifie ; la première se croit.

Concrètement, un fournisseur cloud peut s’engager par contrat à cloisonner vos données, à ne pas les réutiliser, à restreindre les accès. Ces garanties ont une valeur juridique réelle, et c’est sur elles que le Conseil d’État s’est appuyé. Mais elles décrivent un comportement attendu d’un acteur qui a, matériellement, la capacité d’accéder aux données. La conformité dépend alors du respect d’un engagement, et de la résistance de cet engagement face à une injonction d’un droit étranger.

L’approche architecturale renverse la charge de la preuve. Si le modèle d’IA s’exécute localement, sur votre serveur, et qu’aucune donnée n’est jamais envoyée vers un service externe, la question « le prestataire respectera-t-il son engagement ? » ne se pose plus, car il n’y a pas de flux sortant à encadrer. C’est ce que résume la formule employée en interne chez Agify : la souveraineté est architecturalement impossible à violer, pas seulement contractuellement promise. C’est cette nuance qui débloque une discussion avec un DPO.

Quelle architecture rend une IA réellement souveraine ?

Une IA est réellement souveraine quand le modèle de langage tourne sur votre infrastructure et qu’aucune brique ne délègue le traitement à un service cloud tiers. C’est précisément le principe de ragify, l’agent RAG souverain d’Agify : un modèle exécuté localement via Ollama, une base vectorielle pgvector intégrée à PostgreSQL plutôt qu’un service d’embeddings externe, le tout orchestré dans un seul réseau Docker, hébergé sur un VPS GPU en France ou déployable directement sur l’infrastructure du client.

Le détail technique n’est pas cosmétique, il est le cœur de l’argument conformité. Le choix d’un modèle local signifie qu’aucun appel n’est émis vers OpenAI, Anthropic ou Google : les documents ingérés et les questions posées ne transitent à aucun moment par un LLM cloud. Le choix de pgvector, plutôt qu’une base vectorielle hébergée en SaaS, évite un second canal de sortie souvent oublié dans les audits. Chaque maillon est choisi pour qu’il n’existe pas de flux de données vers un tiers.

Cette architecture autorise aussi le déploiement en air-gap, c’est-à-dire sur une infrastructure totalement isolée d’Internet, pour les environnements les plus sensibles. Pour le DPO, la conséquence est directe : il n’y a pas de sous-traitant à qualifier hors de l’Union européenne, pas de transfert international à encadrer, pas de compte cloud externe à auditer. Le périmètre du traitement se referme sur le serveur. C’est l’architecture détaillée dans le guide de l’IA souveraine en entreprise, que cet article applique au cas précis de la validation par les instances de conformité.

Comment cette architecture rend-elle la conformité auditable ?

Une architecture souveraine devient auditable quand elle expose, en clair, ce qui s’est passé : quelles données sont entrées, quelles réponses sont sorties, qui a posé quelle question. Un système qui journalise l’intégralité de ses requêtes et dont le code source est ouvert à l’audit donne au DPO et à la DSI exactement les pièces qu’un contrôle réclame. La conformité cesse d’être une déclaration pour devenir une trace consultable.

Cette exigence de traçabilité n’est plus seulement une bonne pratique, elle devient une obligation réglementaire. L’article 12 du règlement européen sur l’intelligence artificielle (règlement 2024/1689) impose aux systèmes d’IA à haut risque une capacité de journalisation automatique des événements tout au long de leur cycle de vie, afin d’assurer un niveau de traçabilité adapté à leur finalité. Ses dispositions sur les systèmes à haut risque s’appliquent pleinement à compter du 2 août 2026. Une IA qui logue nativement chaque requête anticipe cette exigence ; une IA cloud opaque la subit.

Côté analyse d’impact, l’effet est tangible. Une AIPD doit décrire les flux de données, les destinataires, les transferts et les mesures de sécurité. Quand l’architecture ne produit aucun transfert hors UE et aucun sous-traitant externe, ces sections se rédigent en quelques lignes vérifiables, au lieu de mobiliser des engagements contractuels à apprécier au cas par cas. Le DPO ne signe plus sur la foi d’une politique de confidentialité de plusieurs dizaines de pages, il signe sur un schéma d’architecture qu’il peut lire.

C’est souvent à ce moment qu’un projet bloqué redémarre : quand le DPO réalise qu’il a enfin une architecture qu’il peut auditer plutôt qu’un risque à assumer. Si vous voulez confronter votre contexte de conformité à cette approche, voyons ensemble en 30 minutes ce qu’un déploiement souverain impliquerait chez vous.

Comment associer DSI et DPO sans enliser le projet ?

La meilleure façon d’éviter un blocage tardif est d’impliquer la DSI et le DPO dès le cadrage, pas à l’étape de validation finale. Un projet d’IA présenté en fin de parcours à un DPO qui le découvre se solde presque toujours par un report. Le même projet, co-instruit dès le départ avec une session technique dédiée, transforme l’instance de conformité en alliée plutôt qu’en frein.

Pour la DSI, les points d’appui sont concrets : un déploiement Docker standard sans dépendance applicative propriétaire, la possibilité d’installer sur l’infrastructure existante, l’absence de compte cloud à créer et d’API externe appelée, des journaux complets et un code source auditable sur demande. Aucun de ces éléments ne demande un acte de foi ; tous se vérifient.

Pour le DPO, l’argumentaire se résume à une cartographie de traitement qui se referme : aucune donnée personnelle envoyée à un tiers, données des utilisateurs stockées sur l’infrastructure choisie, conformité RGPD obtenue par l’architecture et non par une clause, AIPD simplifiée faute de sous-traitant hors de l’Union. Reste une condition humaine, valable pour tout projet d’IA : un système techniquement irréprochable mais déployé sans accompagnement métier rejoint vite les 80 % de projets IA qui échouent pour des raisons d’adoption, pas de technologie.

Questions fréquentes

Pourquoi le DPO est-il un point de passage obligé pour un projet d’IA ?

Parce que la plupart des projets d’IA générative en entreprise traitent des données personnelles ou confidentielles, et que le DPO est chargé de vérifier leur conformité au RGPD. L’article 35 impose une analyse d’impact pour les traitements à risque élevé, et la CNIL a listé quatorze types d’opérations où elle est obligatoire. Un agent branché sur la connaissance interne entre fréquemment dans ce périmètre.

Héberger en France suffit-il à être conforme au RGPD ?

Non. Ce qui compte est le droit auquel le prestataire est soumis, pas seulement l’adresse du serveur. La loi américaine CLOUD Act (2018) permet d’exiger d’une entreprise de droit américain l’accès à des données qu’elle détient, même hébergées en France. En mars 2026, le Conseil d’État a lui-même reconnu ce risque résiduel d’accès tout en le jugeant encadré. La localisation est nécessaire, pas suffisante.

Qu’est-ce qu’une conformité « par architecture » ?

C’est une conformité fondée sur l’impossibilité technique de violer une règle, et non sur l’engagement contractuel de ne pas la violer. Si le modèle d’IA s’exécute localement et qu’aucune donnée n’est envoyée à un service externe, il n’y a pas de flux sortant à encadrer. Le DPO vérifie un schéma d’architecture au lieu d’apprécier une promesse.

Une IA souveraine simplifie-t-elle l’analyse d’impact (AIPD) ?

Oui. Une AIPD doit décrire les transferts de données, les destinataires et les sous-traitants. Quand l’architecture ne produit aucun transfert hors Union européenne et aucun sous-traitant externe, ces sections deviennent courtes et vérifiables. L’analyse porte sur un périmètre fermé sur le serveur, ce qui réduit fortement la charge de justification.

L’AI Act impose-t-il de journaliser les requêtes d’une IA ?

L’article 12 du règlement européen sur l’IA (2024/1689) impose aux systèmes à haut risque une journalisation automatique des événements tout au long de leur cycle de vie, pour garantir leur traçabilité. Ces obligations s’appliquent pleinement à compter du 2 août 2026. Une IA qui logue nativement chaque requête répond déjà à cette logique de traçabilité.

Conclusion

Un DPO ne bloque pas un projet d’IA par principe, il le bloque parce qu’on lui demande de garantir une conformité qui repose sur des promesses contractuelles plutôt que sur des faits techniques. Trois points à retenir : héberger en France ne suffit pas tant que le prestataire est soumis à un droit étranger, comme le CLOUD Act ; une conformité par architecture se vérifie là où une conformité par contrat se croit ; et une IA souveraine, qui ne produit ni transfert ni sous-traitant externe et journalise ses requêtes, transforme une AIPD lourde en pièce courte et auditable.

La question n’est donc pas de convaincre votre DPO de fermer les yeux sur un risque, mais de lui donner une architecture qu’il peut auditer. Discutons de votre cas en 30 minutes : on examine vos contraintes de conformité, le périmètre de vos données et l’architecture qui permet de déployer une IA utile sans demander à votre DPO un acte de foi.

---

Agify déploie des agents IA souverains (RAG) hébergés en France pour les secteurs sensibles, où aucune donnée ne touche un cloud étranger.