Integration / Model provider
OpenAI, routed by jurisdiction.
Route GPT traffic through YTT Secunet to OpenAI's regional API hosts, so a European tenant only ever reaches an OpenAI project configured for European data residency.
OpenAI
Model provider
- Regions documented
- 4
- Setup steps
- 6
OpenAI offers data residency as a project setting on its API platform. A project created with the Europe region (covering the EEA and Switzerland) is served from the regional host eu.api.openai.com, and OpenAI documents in-region processing for its main inference endpoints there, including Chat Completions, Responses, Embeddings and Batch. The region is chosen when the project is created and cannot be changed afterwards, eligibility goes through OpenAI's sales team, and non-US regions require approved retention controls such as Zero Data Retention or Modified Abuse Monitoring. OpenAI also lists regions where only storage at rest is localised (the UK, Japan, Canada, India, Singapore, South Korea and Australia, among others), which is a narrower guarantee than in-region inference.
YTT Secunet does not replace any of that. It sits in front of your OpenAI projects and decides, per request, which project and which regional host a call is allowed to reach. Your application keeps the OpenAI SDK and points it at https://eu.yttsecunet.com/v1. The policy pack named in X-YTT-Policy resolves the tenant's domicile, checks that the target project carries a matching residency setting and an approved retention control, and only then forwards the request to eu.api.openai.com with the project's own key. A request that would land on a global project, or on a storage-only region, is refused before any bytes leave the data plane.
Two boundaries are worth stating plainly for your DPIA. OpenAI's residency covers customer content, not system data such as account metadata, usage and billing records. And OpenAI, L.L.C. is a US company, so a European project reduces transfer exposure but does not remove the provider from US legal process. YTT Secunet adds the evidence layer: every response carries a signed receipt naming the resolved host, the project's residency region and the ZDR flag, which is what your Article 30 record and transfer impact assessment can point to.
| Region or deployment | Location | Jurisdiction |
|---|---|---|
| Europe data residency (eu.api.openai.com) | EEA and Switzerland | EU / European Union |
| United States (us.api.openai.com) | United States | US / United States |
| United Arab Emirates (ae.api.openai.com), approval required | United Arab Emirates | GCC / Middle East (GCC) |
| United Kingdom (gb.api.openai.com), storage at rest only | United Kingdom | UK / United Kingdom |
- 01
Ask your OpenAI account team to enable data residency, then create a new API project with Europe selected as its region. Existing projects cannot be converted, so plan a key rotation.
- 02
Confirm with OpenAI which retention control applies to the project (Zero Data Retention or Modified Abuse Monitoring) and record the approval reference.
- 03
In the YTT Secunet console, add the project under Sovereign Endpoints with upstream host eu.api.openai.com and store its API key in the YTT Secunet secret vault or your own KMS.
- 04
Attach the endpoint to the eu-gdpr-strict policy pack and mark the route as requiring a ZDR attestation, so a misconfigured project fails closed.
- 05
Change your SDK base_url to https://eu.yttsecunet.com/v1 and add the X-YTT-Policy and X-YTT-Tenant headers.
- 06
Send a test request and verify the X-YTT-Proof-Signature receipt offline with ytt-verify before moving production traffic.
import os
from openai import OpenAI
client = OpenAI(
base_url="https://eu.yttsecunet.com/v1",
api_key=os.environ["YTT_SECUNET_API_KEY"],
default_headers={
"X-YTT-Policy": "eu-gdpr-strict",
"X-YTT-Tenant": "tenant-de-0142",
},
)
resp = client.chat.completions.with_raw_response.create(
model="gpt-4.1",
messages=[{"role": "user", "content": "Summarise clause 14 of this supply contract."}],
)
print(resp.headers["X-YTT-Proof-Signature"][:48])
print(resp.parse().choices[0].message.content)- Storage-only regions are not treated as in-region inference. A UK GDPR policy that requires UK processing will not route to gb.api.openai.com on the strength of its storage commitment alone.
- Chat Completions with store=true is unavailable in OpenAI's non-US regions; YTT Secunet strips or rejects the flag on EU routes so the call does not fail upstream.
- Features OpenAI lists as storage-only (Files, Vector Stores) are flagged in the receipt so your RoPA does not overstate where retrieval data is processed.
- The receipt records the OpenAI project's residency region and retention control alongside the model id, so a change on OpenAI's side shows up as a policy violation rather than silently.
Does OpenAI's European data residency mean no transfer to the US at all?
It means customer content for supported endpoints is stored and processed in the region. OpenAI's documentation excludes system data such as account and billing metadata, and OpenAI is a US-parented company. Treat it as a strong supplementary measure in your transfer impact assessment, not as the end of the analysis.
Can I use one OpenAI key for every jurisdiction?
You can, but you should not. YTT Secunet maps each jurisdiction to its own OpenAI project so a policy decision always lands on a project whose residency setting matches, and so revoking one region does not affect the others.
What happens if the European project is rate limited?
YTT Secunet fails over only to endpoints inside the same jurisdiction, for example a second EU-region OpenAI project or an EU deployment on Azure OpenAI. It never falls back to a global or US project for an EU tenant; it returns a 429 with a policy explanation instead.
Sovereign route ready
Stop risking 4% global turnover GDPR fines on AI inference.
Deploy sovereign, cryptographically proven AI routing in 15 minutes.