Le routing LLM et le RGPD : ce que les gateways américaines ne te disent pas
Résidence des données, sous-processeurs, Schrems II, et l'EU AI Act — un briefing précis

Ce post n'est pas une alarme. C'est un briefing. Si tu es une boîte européenne qui utilise une gateway LLM — ou qui shipe des features IA sur le marché européen — il y a des questions compliance précises auxquelles tu devrais pouvoir répondre, et plusieurs n'ont pas de réponse propre quand ta gateway est US-based.

Je ne suis pas avocat. Rien ici n'est un conseil juridique. Mais j'ai fait assez de cycles d'achat avec des enterprises européennes pour savoir quelles questions sont posées, quelles réponses passent, et quelles réponses tuent les deals. Laisse-moi les étaler.

Les quatre angles qui comptent

Quand une équipe compliance européenne review une intégration LLM, elle regarde typiquement quatre trucs :

1. Résidence des données — où les prompts et completions sont physiquement traités et stockés.
2. Sous-processeurs — la chaîne de tiers qui touche à la donnée, et sous quelle juridiction chacun opère.
3. Data Processing Agreement (DPA) — le doc contractuel qui gouverne comment les données perso sont traitées.
4. Implications EU AI Act — selon la classification du use case, des obligations supplémentaires sur la transparence, la gestion des risques, le contrôle humain.

Chacun est répondable. Chacun est aussi différent selon que ta gateway est US-based ou UE-based.

La résidence des données en pratique

La question de base : quand un utilisateur à Paris envoie un prompt contenant des données perso via ta feature IA, où ce prompt est-il traité ?

• Direct à Anthropic/OpenAI : traité dans la région du provider, typiquement US sauf si tu as configuré une région UE (Anthropic offre un traitement régional UE pour certains modèles ; OpenAI a des options zonales européennes dans Azure).
• Via une gateway US-hosted (OpenRouter, Vercel, Portkey, Helicone, Cloudflare AI Gateway en config par défaut) : traité au moins une fois sur de l'infra US avant de taper le provider de modèle.
• Via une gateway UE-hosted (HiWay sur OVH, ou un LiteLLM self-hosté en région UE) : traité sur infra UE, puis forwardé vers la région provider que tu as configurée.

L'étape gateway compte parce que c'est un événement de traitement distinct. Même si ton provider de modèle sous-jacent a une région UE, passer d'abord par une gateway US-hosted ajoute un lien de traitement US dans la chaîne.

Pour la plupart des produits B2C avec données non sensibles, c'est un non-problème. Pour les produits B2B qui vendent à des secteurs régulés (santé, finance, gouvernement, légal, éducation) ça l'est fréquemment.

Sous-processeurs : la chaîne pour laquelle tu signes vraiment

Quand tu signes avec une gateway, tu acceptes typiquement leur liste de sous-processeurs. C'est la chaîne de vendors additionnels qui peuvent toucher la donnée — CDN, infra de logs, monitoring, auth, cloud provider.

Pour une gateway US-hosted typique, la chaîne sous-processeurs peut inclure :

• AWS ou GCP (cloud US, avec régions UE dispos)
• Un vendor d'observability US (Datadog, New Relic, etc.)
• Un provider d'email US
• Un provider d'auth US
• Un CDN US (Cloudflare est un cas mixte)

Chacun est un flux de données séparé pour lequel tu signes. Tes propres clients ou équipe compliance s'attendent à ce que tu les listes, ou au moins que tu te portes garant de la liste de la gateway.

Pour une gateway UE-hosted sur OVH (notre cas), la chaîne sous-processeurs est plus courte et plus européenne :

• OVH (cloud français)
• Stripe (traitement de paiement — inévitable pour les paiements carte, mais minimisé au strict nécessaire)
• Un set limité de services supports UE

Les chaînes plus courtes sont plus faciles à documenter et plus faciles à passer en review compliance.

La question DPA

Le RGPD requiert un DPA entre toi (le contrôleur) et tout processeur qui traite des données perso. Quand tu signes avec une gateway, tu signes un DPA avec eux.

Trois trucs à vérifier sur tout DPA de gateway :

1. Est-ce qu'il s'engage sur une région de traitement précise ? Si le DPA est silencieux sur la région ou dit "on peut traiter globalement", ton équipe compliance va le flagger. Tu veux un engagement — "le traitement a lieu dans la région X" — ou au moins une option configurable qui produit un engagement signé.

2. Quelle est la timeline de notification de breach ? Le RGPD requiert notification aux autorités dans les 72h après qu'un breach est connu. L'engagement de ta gateway dans le DPA doit être assez rapide pour que tu puisses tenir ta propre fenêtre de 72h après qu'ils t'aient dit.

3. Quelle est la notification de changement de sous-processeur ? Le DPA doit s'engager à te notifier en avance quand ils ajoutent de nouveaux sous-processeurs, pour que ton équipe compliance puisse évaluer la chaîne. Un langage vague "on notifiera quand raisonnablement possible" est un problème.

La plupart des gateways US ont des DPA. La qualité varie. La précision sur la région de traitement est généralement le point le plus faible.

Schrems II, brièvement

Schrems II est une décision CJUE de 2020 qui a invalidé le précédent cadre de transfert de données UE-US. Le follow-up — EU-US Data Privacy Framework, adopté en 2023 — est actuellement en vigueur mais sous contestation juridique.

Ce que ça veut dire en pratique : les transferts de données perso de l'UE aux US reposent sur des mécanismes juridiques (le DPF, ou les Standard Contractual Clauses avec mesures supplémentaires) qui ont été contestés en justice avant et peuvent l'être encore. Utiliser une gateway US-based veut dire que tu reposes sur ces mécanismes, qui sont juridiquement valides aujourd'hui mais pas à toute épreuve.

Pour beaucoup de boîtes c'est un risque acceptable. Pour certaines — acheteurs publics, santé, finance régulée, services juridiques — c'est assez préoccupant pour préférer les alternatives UE-based quand c'est possible. L'EU AI Act a amplifié cette préférence.

La couche EU AI Act

L'EU AI Act est entré en vigueur en 2024, avec des obligations qui s'échelonnent sur 2026-2027. La partie pertinente pour les utilisateurs de gateway LLM :

• Pratiques prohibées (ex. certaines manipulations, catégorisation biométrique de masse) sont interdites purement et simplement.
• Systèmes à haut risque (scoring crédit, hiring, notation éducative, usage forces de l'ordre, et autres) ont des obligations obligatoires : gestion des risques, gouvernance des données, contrôle humain, transparence, logging.
• Modèles IA à usage général (les gros modèles de fondation) ont des obligations de transparence et documentation côté provider.
• Obligations de transparence s'appliquent largement : les utilisateurs doivent savoir quand ils interagissent avec un système IA.

La couche gateway n'est pas directement régulée, mais ton usage d'une gateway fait partie de ton tableau compliance. Si tu opères un système à haut risque, tu auras besoin de documentation montrant comment les données circulent, où elles sont traitées, et qui y a accès. Cette documentation est significativement plus facile à produire si ta chaîne de traitement est courte et UE-based.

Pour les use cases à haut risque, la combinaison infra UE-hosted + DPA explicite + chaîne sous-processeurs courte + pas de prompt logging par défaut est proche d'une réponse checklist pour la moitié du doc compliance.

La checklist compliance

Pour évaluer toute gateway LLM sur l'angle compliance, voici la checklist que j'utiliserais :

Résidence des données

• La région de traitement primaire de la gateway est-elle documentée par écrit ?
• Peux-tu t'engager sur une région de traitement UE-only si besoin ?
• Le DPA reflète-t-il l'engagement régional ?
• Les backups sont-ils traités dans la même région ?

Sous-processeurs

• La liste des sous-processeurs est-elle publique ?
• La juridiction de chaque sous-processeur est-elle documentée ?
• Y a-t-il un mécanisme de notification pour les changements ?
• Peux-tu mettre un veto sur des sous-processeurs précis s'ils sont inacceptables pour tes clients ?

Traitement des prompts

• Le prompt logging est-il activé ou désactivé par défaut ?
• Si le logging est activé, quelle est la rétention ?
• Le prompt logging peut-il être désactivé par clé API ?
• Les logs sont-ils accessibles seulement dans la région d'engagement ?

Qualité du DPA

• Le DPA spécifie-t-il une région de traitement ?
• La notification de breach est-elle ≤ 72h ?
• Requiert-il la notification de changement de sous-processeur ?
• Les timelines de traitement des demandes data subject sont-elles spécifiées ?

Alignement EU AI Act

• La gateway publie-t-elle une liste des modèles de fondation supportés avec leurs providers ?
• Y a-t-il de la documentation adaptée pour la compliance système à haut risque ?
• Y a-t-il une déclaration de transparence vers laquelle tu peux linker ?

Présence business

• La gateway est-elle opérée par une entité légale UE (ou US avec filiale UE propre) ?
• Où sont basées les personnes qui répondent aux demandes data subject ?
• Y a-t-il un représentant UE (Article 27 RGPD) si l'entité est non-UE ?

Si tu ne peux pas répondre à la plupart pour ta gateway actuelle, c'est de l'info utile.

À quoi ressemblent les réponses honnêtes

Pour la transparence, voici comment HiWay répond à chaque bucket :

Résidence des données. Tout le traitement sur infra française OVH. Configurable en UE-only quand requis contractuellement. Les backups restent en région.

Sous-processeurs. Liste courte, publiée. Principalement UE-based avec exceptions limitées (Stripe pour les paiements). Notification en avance pour les changements.

Traitement des prompts. Zéro prompt logging par défaut. Logging debug optionnel par clé API avec rétention bornée. Les logs restent en région.

DPA. Spécifie la région française OVH. Notification breach 72h. Engagement de notification de changement de sous-processeur. Inclus dans les tiers payants.

EU AI Act. Catalogue de modèles publié avec attribution provider. Template de documentation pour clients construisant des systèmes à haut risque. Page transparence.

Présence business. Opéré par Mytm-Group, SARL française. Les gens qui répondent aux demandes data subject sont basés en France.

Ce n'est pas pour dire que HiWay est la seule option qui fait bien ça. Un LiteLLM self-hosté en région UE sous ta propre entité peut produire des réponses équivalentes. Le point c'est que les gateways US-hosted ne peuvent structurellement pas, même quand les éléments individuels sont configurables.

Ce que les gateways US-hosted te disent parfois

Pour être juste : certaines gateways US ont fait de vrais investissements compliance. Portkey a des tiers enterprise avec options régionales. Helicone a une option OSS self-host qui te laisse deployer dans ta propre région UE. Cloudflare AI Gateway bénéficie de la sophistication régulatoire globale de Cloudflare.

Ce qu'elles ne peuvent typiquement pas offrir c'est "on est une entité UE sous loi UE avec du personnel UE-based en première ligne de réponse". C'est une différence structurelle entre gateways US et UE, et pour certaines conversations compliance, c'est le facteur décisif.

Quoi faire si tu es déjà sur une gateway US

Si tu lis ça et réalises que ta stack actuelle est US-hosted de bout en bout, pas de panique. Les étapes :

1. Documente ce que tu as. Écris ton flux de données actuel, les sous-processeurs, et les engagements DPA. Tu ne peux pas fixer ce que tu n'as pas mappé.
2. Parle à ton équipe compliance. Demande quelles sont leurs exigences dures versus préférences. La réponse surprend souvent dans les deux directions.
3. Évalue le risque pour ton use case précis. Une app B2C grand public servant des données non sensibles a un profil de risque différent d'un B2B santé.
4. Si la migration est justifiée, commence par les flux de données à plus haut risque. Tu n'as pas à tout bouger d'un coup. Bouge les workloads régulés d'abord.
5. Mets à jour ta doc publique. Si tu dis "RGPD-compliant" sur ton site marketing, ton archi réelle doit le soutenir.

La migration d'une gateway US vers une UE — en supposant que les deux sont compatibles OpenAI — est un changement de base_url. Voir notre post de migration.

Le takeaway honnête

Les gateways LLM US-hosted ne sont pas inutilisables par les boîtes européennes. Beaucoup bossent avec aujourd'hui. Mais elles ont des caractéristiques structurelles qui créent des frictions compliance précises, et cette friction empire à mesure que les obligations EU AI Act s'activent et que les équipes compliance mûrissent.

Si ton use case est sensible — secteurs régulés, classifications à haut risque AI Act, clients avec achat strict — une gateway UE-based réduit la surface compliance matériellement. Si ton use case est peu sensible, les options US-hosted vont bien et sont souvent plus feature-rich aujourd'hui.

La question n'est pas "est-ce que l'hosting US est légal ?" Il l'est majoritairement, pour l'instant. La question c'est "est-ce que ça rend mes conversations compliance plus dures ?" Pour beaucoup d'acheteurs européens, la réponse honnête est oui.

---

Prochain : le guide honnête pour choisir un router LLM en 2026 — un framework de décision.