Comment utiliser OpenAI, Claude et Gemini en Europe sans risque RGPD

Utiliser une API d’intelligence artificielle en Europe ne consiste pas seulement à choisir le modèle le plus performant. Les développeurs doivent également savoir où les prompts sont traités, quelle entité juridique contrôle les données et quelles garanties contractuelles et techniques s’appliquent.

Ce guide compare OpenAI, Claude et Gemini, puis présente trois approches concrètes pour assurer la conformité au RGPD : utiliser les configurations européennes proposées nativement par les fournisseurs, passer par une passerelle IA basée dans l’Union européenne ou auto-héberger les modèles. Il aborde également les contrats, la gestion des logs et les obligations liées au règlement européen sur l’IA, que la seule résidence des données ne permet pas de couvrir.

Ce que chaque fournisseur fait réellement de vos données

OpenAI

L’API standard d’OpenAI ne garantit pas automatiquement que les traitements sont effectués en Europe. Les clients API éligibles doivent créer un nouveau projet configuré dans la région Europe et envoyer leurs requêtes vers l’endpoint européen. Un projet existant ne peut pas simplement être converti en projet européen.

Par défaut, OpenAI n’utilise pas les entrées ni les réponses de son API pour entraîner ses modèles et propose un accord de traitement des données, ou DPA. Cependant, la résidence européenne s’applique uniquement aux endpoints, fonctionnalités et configurations compatibles.

Pour réduire les risques liés à OpenAI et au RGPD en Europe, les équipes doivent activer un projet européen, vérifier que les endpoints utilisés sont éligibles et documenter les garanties applicables aux éventuels transferts de données.

L’erreur la plus fréquente consiste à penser qu’une entité de facturation européenne, un contrat Enterprise ou un abonnement ChatGPT Plus garantit automatiquement un traitement des données dans l’Union européenne.

Anthropic

L'API Claude directe ne propose actuellement pas de configuration permettant au client de garantir une résidence des données exclusivement européenne. Anthropic indique que les données commerciales peuvent être traitées sur des infrastructures situées dans plusieurs régions, notamment en Europe. Cela ne constitue toutefois pas une garantie que chaque requête reste au sein de l’Union européenne.

Par défaut, Anthropic n’utilise pas les données de son API pour entraîner ses modèles et met un DPA à la disposition de ses clients.

La solution la plus adaptée pour obtenir une résidence européenne des données avec l’API Claude consiste donc à déployer Claude via un endpoint AWS Bedrock ou Google Vertex AI configuré dans une région européenne.

La présence d’infrastructures Anthropic en Europe ne constitue pas, à elle seule, un engagement contractuel garantissant que toutes les requêtes sont traitées exclusivement dans l’Union européenne.

Google

La Gemini Developer API et Google AI Studio sont des services mondiaux. Leur infrastructure n’est donc pas automatiquement limitée à une région européenne.

L’utilisation payante de l’API Gemini est couverte par les conditions de Google applicables aux sous-traitants, et les prompts ne sont pas utilisés pour améliorer ses produits. Les conditions des services gratuits nécessitent cependant une vérification plus attentive avant tout traitement de données personnelles ou sensibles.

Pour renforcer la conformité de Gemini au RGPD, il est préférable d’utiliser Vertex AI avec un endpoint régional ou multirégional européen compatible. Les clients Google Workspace peuvent également appliquer des contrôles de résidence et de souveraineté des données aux catégories de données couvertes.

L’erreur la plus fréquente consiste à confondre l’interface grand public ou développeur de Gemini avec Vertex AI, puis à supposer que les garanties régionales de Google Cloud s’appliquent automatiquement à une clé API déjà utilisée en production.

L’hypothèse la plus risquée en matière de conformité des API IA en Europe est de croire que les garanties réservées aux offres Enterprise s’appliquent automatiquement à l’offre réellement utilisée.

Pourquoi l’utilisation d’API d’IA en Europe représente désormais un risque juridique

La plupart des intégrations d’IA commencent par l’utilisation d’un endpoint mondial. Tant que le traitement régional n’est pas explicitement activé, les API de fournisseurs comme OpenAI, Anthropic et Google peuvent traiter les prompts en dehors de l’Union européenne.

Lorsque les prompts contiennent des dossiers clients, des données sur les employés, des tickets de support ou d’autres informations personnelles, cela constitue un transfert transfrontalier de données. Une API d’IA conforme au RGPD doit s’appuyer sur une décision d’adéquation lorsqu’elle est applicable, ou sur des garanties telles que les clauses contractuelles types prévues par l’article 46 du RGPD.

L’hébergement dans l’Union européenne ne supprime pas à lui seul le risque lié à la juridiction. En vertu du CLOUD Act américain, un fournisseur dont le siège social se trouve aux États-Unis peut être contraint de communiquer des données placées sous sa possession, sa garde ou son contrôle, même lorsqu’elles sont stockées en Europe. Les exigences relatives à la résidence des données d’IA en Europe doivent donc couvrir à la fois le lieu de traitement et la juridiction applicable.

La résidence des données ne garantit pas la souveraineté des données.

Le règlement européen sur l’intelligence artificielle, ou EU AI Act, deviendra largement applicable le 2 août 2026. Les sanctions maximales peuvent atteindre 7 % du chiffre d’affaires annuel mondial, contre 4 % dans le cadre du RGPD. Les entreprises qui déploient des systèmes d’IA sont également soumises à des obligations directes, notamment pour les systèmes à haut risque et les cas d’usage réglementés en matière de transparence.

Une récente étude LARA a testé 12 modèles dans 3 000 scénarios professionnels simulés. Le modèle le moins performant a enfreint les exigences du RGPD ou de l’EU AI Act dans environ 90 % des cas. Même le meilleur modèle a échoué dans 46 % des scénarios.

Avant de pouvoir résoudre le problème, vous devez comprendre précisément ce que chaque fournisseur fait de vos données.

Option 1 : configurer les options européennes natives de chaque fournisseur

OpenAI

Pour activer la résidence des données OpenAI en Europe, vérifiez que votre organisation API est éligible à une résidence hors des États-Unis, ainsi qu’aux contrôles requis de surveillance des abus ou de Zero Data Retention.

Dans l’API Platform, créez un nouveau projet depuis les paramètres de votre organisation, sélectionnez l’Europe comme région, puis envoyez vos requêtes via : https://eu.api.openai.com

Consultez la matrice de compatibilité d’OpenAI, car tous les modèles, endpoints et outils ne sont pas éligibles au stockage et au traitement en Europe. Cette configuration couvre les contenus clients traités par le nouveau projet régional. Elle ne transfère pas les données historiques des projets existants.

Claude / Anthropic

L’API directe d’Anthropic ne propose pas de résidence exclusivement européenne. Le trafic est mondial par défaut et Anthropic indique que les données commerciales stockées restent aux États-Unis.

Pour bénéficier d’une résidence européenne des données avec l’API Claude, utilisez AWS Bedrock dans l’une des régions suivantes :

• eu-central-1 : Francfort ;
• eu-west-1 : Irlande ;
• eu-west-3 : Paris.

Vous pouvez également utiliser un endpoint européen compatible sur Google Vertex AI. La disponibilité et le routage varient selon les modèles. Cette configuration nécessite également de gérer les accès IAM du cloud, la facturation, les logs et les endpoints.

Gemini

La Gemini Developer API et Google AI Studio ne permettent pas de limiter le traitement à une région spécifique. Ils ne doivent donc pas être utilisés lorsqu’un traitement exclusivement européen des données personnelles est requis.

Pour mettre en place un déploiement contrôlé de l’API Gemini en Europe, activez Vertex AI et sélectionnez un modèle compatible avec la résidence des données dans l’une des régions suivantes :

• europe-west1 : Belgique ;
• europe-west4 : Pays-Bas.

Avec le SDK Google Gen AI, initialisez le client Vertex à l’aide de votre projet et de la configuration suivante : location="europe-west4"

Avec l’API REST, utilisez l’endpoint :

https://europe-west4-aiplatform.googleapis.com/v1/projects/PROJECT_ID/locations/europe-west4/publishers/google/models/MODEL_ID:generateContent

Évitez l’endpoint global et vérifiez la compatibilité du modèle dans la matrice de résidence des données actuellement publiée par Google.

Limites

Gérer chaque fournisseur séparément implique de maintenir trois DPA, trois pistes d’audit, trois systèmes de facturation et trois configurations d’endpoints.

Cette approche peut convenir aux équipes disposant de ressources dédiées au DevOps et à la conformité. Elle reste toutefois contraignante pour les équipes qui évoluent rapidement. Elle augmente également le risque d’erreur de configuration lorsqu’un développeur réutilise les paramètres mondiaux par défaut d’un SDK ou renseigne une mauvaise URL de base.

Option 2 : faire transiter les trois fournisseurs par une passerelle IA européenne

Une passerelle IA est une couche intermédiaire entre votre application et les fournisseurs de modèles. Elle centralise le routage, les logs et les contrôles de conformité au sein d’une seule intégration.

Pour choisir une passerelle IA européenne, ne vous contentez pas de la mention « hébergement européen ». Vérifiez que :

• l’entreprise a son siège social dans l’Union européenne et relève de la juridiction européenne ;
• les prompts, les fichiers, les réponses et les logs sont traités uniquement sur des infrastructures européennes ;
• la politique de Zero Data Retention est appliquée par défaut ;
• un accord de traitement des données, ou DPA, est inclus ;
• les mesures de sécurité sont validées par des certifications telles que SOC 2 et ISO 27001.

En pratique, votre application utilise une seule clé API et un seul endpoint européen. Vous sélectionnez le modèle dans chaque requête, tandis que la passerelle gère le routage, les logs et la conformité.

Passer de GPT-4o à Claude 3.5 Sonnet peut simplement nécessiter de modifier le paramètre du modèle. Vous n’avez pas besoin d’intégrer un nouveau SDK, de créer un autre système d’authentification ou de reconstruire la logique de traitement des réponses.

La même API peut également acheminer les requêtes vers Gemini et d’autres modèles compatibles.

Eden AI est un exemple de cette approche. L’entreprise a son siège social en France et propose un endpoint dédié à l’Union européenne. Les prompts, fichiers, requêtes et réponses envoyés par cet endpoint sont traités et acheminés au sein de l’Union européenne.

Son API unifiée donne accès à OpenAI, Anthropic, Google et à plus de 50 autres fournisseurs. L’endpoint européen expose uniquement les modèles qui répondent à ses exigences de résidence des données en Europe.

Eden AI applique également une politique de Zero Data Retention, inclut un DPA et dispose des certifications SOC 2 et ISO 27001.

Cette approche facilite l’exploitation d’une API d’IA conforme au RGPD auprès de plusieurs fournisseurs.

Au lieu de gérer trois DPA, trois pistes d’audit, trois systèmes de facturation et plusieurs configurations régionales, l’équipe administre une seule couche de conformité. Elle réduit également le risque qu’un développeur contourne accidentellement les exigences de résidence des données d’IA en Europe en utilisant l’endpoint mondial d’un fournisseur.

Cette configuration convient particulièrement aux produits qui utilisent plusieurs modèles, aux équipes qui évoluent rapidement et aux entreprises qui ne disposent pas d’une équipe dédiée à la conformité ou à l’ingénierie de plateforme.

Option 3 : auto-héberger des modèles open source sur une infrastructure européenne

L’auto-hébergement est l’option qui offre le plus de contrôle lorsque les prompts ne peuvent pas quitter l’infrastructure que vous gérez.

Cette approche convient notamment aux secteurs de la santé, du droit et de la fintech, ainsi qu’aux traitements classifiés, aux exigences strictes de souveraineté des données en Europe ou aux situations dans lesquelles le DPO interdit les appels à des API d’IA tierces.

Parmi les modèles adaptés figurent Mistral Large 3, un modèle à poids ouverts sous licence Apache 2.0 développé par l’entreprise française Mistral AI, ainsi que les modèles plus légers de la famille Mixtral.

Les modèles Llama 3.x de Meta peuvent également être déployés sur votre propre infrastructure, mais ils utilisent la licence communautaire de Meta plutôt que la licence Apache 2.0.

Tous ces modèles peuvent fonctionner sur votre propre matériel. Les modèles les plus volumineux nécessitent toutefois une capacité GPU importante et peuvent exiger une quantification ou un déploiement sur plusieurs nœuds.

Pour un hébergement en Europe, vous pouvez envisager OVHcloud ou Scaleway en France, ainsi que Hetzner ou IONOS en Allemagne.

Sélectionnez une région de centre de données située dans l’Union européenne et vérifiez :

• l’entité juridique qui signe le contrat ;
• les sous-traitants impliqués ;
• les accès accordés aux équipes de support ;
• l’emplacement des sauvegardes.

Un fournisseur dont le siège social se trouve dans l’Union européenne réduit l’exposition directe au CLOUD Act. La juridiction doit néanmoins être confirmée dans le contrat et non déduite uniquement de l’emplacement des serveurs.

Ollama convient aux déploiements simples reposant sur un seul modèle. Pour une utilisation en production, vLLM propose un serveur compatible avec l’API OpenAI, le traitement par lots, l’inférence distribuée et différentes options de mise à l’échelle. Open WebUI peut également fournir une interface auto-hébergée destinée aux utilisateurs internes.

Limites opérationnelles

L’auto-hébergement implique plusieurs contraintes :

• vous gérez les mises à jour des modèles, la capacité GPU, la montée en charge, la latence, la surveillance, les contrôles d’accès et les correctifs de sécurité ;
• pour certaines tâches, la qualité des modèles peut rester inférieure à celle des meilleurs systèmes hébergés ;
• aucun SLA ni support du fournisseur du modèle n’est inclus, sauf s’il est acheté séparément.

Une architecture hybride est souvent plus pratique.

Vous pouvez conserver les traitements sensibles sur des modèles auto-hébergés, puis utiliser une passerelle comme Eden AI pour les tâches moins risquées qui nécessitent un choix de modèles plus large.

Cette approche permet de répondre aux exigences de confidentialité des données liées aux modèles d’IA en Europe, sans imposer l’infrastructure la plus coûteuse à l’ensemble des traitements.

Ce que la résidence des données ne permet pas de résoudre

Vous avez toujours besoin d’une base légale

La résidence des données indique où celles-ci sont traitées. Elle ne détermine pas si le traitement est licite. Avant d’envoyer des données personnelles à un système d’IA, vous devez disposer d’une base légale valide au titre du RGPD, comme l’exécution d’un contrat, l’intérêt légitime ou le consentement. C’est le point de départ de la conformité de l’IA au RGPD.

Un serveur européen ne remplace pas un DPA

Un accord de traitement des données, ou DPA, est obligatoire au titre de l’article 28 du RGPD lorsqu’un fournisseur d’IA traite des données personnelles pour votre compte. Le DPA doit notamment couvrir :

• la sécurité et la confidentialité ;
• les sous-traitants ultérieurs ;
• la suppression des données ;
• les droits d’audit ;
• l’assistance pour répondre aux demandes des personnes concernées.

L’hébergement dans l’Union européenne ne supprime pas cette obligation.

Des transferts internationaux peuvent toujours avoir lieu

L’utilisation d’un serveur situé à Francfort ne garantit pas automatiquement que les données restent hors de la juridiction de pays non membres de l’Union européenne. Lorsqu’une entité américaine ou un sous-traitant situé en dehors de l’Espace économique européen peut accéder aux données, des clauses contractuelles types ou un autre mécanisme de transfert valide peuvent rester nécessaires.

Vous devez également évaluer les risques liés aux accès à distance et aux demandes de communication de données émanant des autorités publiques.

Les données personnelles ne se trouvent pas uniquement dans les prompts

Les données personnelles peuvent apparaître dans :

• les prompts ;
• les fichiers importés ;
• les réponses générées ;
• les historiques de conversation ;
• les embeddings ;
• les traces d’exécution ;
• les réponses mises en cache ;
• les logs de l’API.

Les données utilisées pour le débogage doivent donc respecter les mêmes règles de conservation, de contrôle des accès et de suppression que la requête d’origine.

L’EU AI Act ajoute des obligations distinctes

La résidence des données ne suffit pas à garantir la conformité à l’EU AI Act. Pour les cas d’usage à haut risque, comme le recrutement, l’évaluation du crédit, les systèmes médicaux et certaines applications biométriques, les déployeurs peuvent être tenus de mettre en place :

• une supervision humaine ;
• un suivi du système ;
• une conservation des logs ;
• une information des utilisateurs ;
• des analyses d’impact.

La conformité est un système, pas un simple paramètre.

Checklist de conformité avant la mise en production

• Confirmez que la résidence des données dans l’Union européenne est activée pour l’offre API, le projet, le modèle et l’endpoint exacts utilisés en production.
• Signez un accord de traitement des données conforme à l’article 28 du RGPD avec votre fournisseur d’IA, au lieu de vous appuyer uniquement sur ses conditions générales d’utilisation.
• Mettez en place des clauses contractuelles types, ou un autre mécanisme de transfert valide, lorsque les données sont transférées vers un pays situé en dehors de l’Espace économique européen ou peuvent y être consultées.
• Examinez chaque prompt et documentez une base légale avant d’envoyer des données personnelles, comme la nécessité contractuelle, l’intérêt légitime ou le consentement.
• Auditez les logs de l’API, les traces, les caches et les outils de débogage afin d’identifier les données personnelles. Appliquez ensuite des contrôles d’accès et des durées de conservation clairement définies.
• Informez les utilisateurs lorsqu’ils interagissent avec une IA ou lorsqu’une autre obligation de transparence prévue par l’article 50 de l’EU AI Act s’applique.
• Documentez un processus de contrôle humain pertinent avant que les réponses de l’IA ne contribuent à des décisions ayant un impact significatif sur une personne.
• Mettez à jour votre registre des activités de traitement prévu par l’article 30 du RGPD en précisant la finalité de l’IA, les catégories de données, les fournisseurs, les transferts, les durées de conservation et les garanties appliquées.

Cette checklist couvre les éléments essentiels. Les cas d’usage liés à la santé, au recrutement, au crédit, à la biométrie et à d’autres systèmes à haut risque nécessitent toutefois une analyse juridique et une évaluation complète des risques.

Une passerelle européenne comme Eden AI peut réduire le périmètre de conformité des trois premiers points en centralisant le routage régional, la relation avec le sous-traitant et la gouvernance des fournisseurs.

FAQ : comment utiliser OpenAI, Claude et Gemini en Europe