An agentic SDLC sends far more of your organisation to a model than a chat window ever did: source code, tickets, incident threads, production telemetry, test fixtures and the customer records that leak into all of them. If you run an Azure-primary tenant, some of that is probably being processed outside the EU today. Every new OpenAI model launches as a Global deployment first, Claude on Microsoft Foundry still has no EU data zone, and Microsoft Copilot’s “flexible inferencing” has defaulted to on for EU tenants since April. None of that is a breach. All of it is a transfer your DPIA and your DORA register most likely do not describe.
Cleverbit helps engineering leaders design governed agentic SDLC practices for regulated environments, including the data-handling policy and model routing that keep an agent harness inside the lines. This article covers what changed in the rules since July, where each cloud can and cannot keep inference in the EU as of 13 October 2026, and the controls that make the answer hold.
Which terms do you need before the rest makes sense?
Personal data, not PII. GDPR protects personal data: anything relating to an identifiable person, pseudonymised data included. It is wider than the US notion of PII. In an engineering context it means customer identifiers in logs, email addresses in tickets, names in commit messages and production data copied into test fixtures.
EDPB. The European Data Protection Board: the national data-protection regulators (Ireland’s DPC, France’s CNIL, Italy’s Garante, Malta’s IDPC and the rest) plus the European Data Protection Supervisor, sitting as one body. Its opinions are not law, but regulators and courts follow them, so they are the closest thing to an official EU reading of how GDPR applies to LLMs.
Controller, processor, and who is which on each route. You are the controller for every prompt your engineers send. Your processor is whoever runs the model on your instructions, and it changes by route: Microsoft for Azure OpenAI, AWS for Bedrock, Google for Vertex AI, and Anthropic itself for Claude on Microsoft Foundry. Most vendors also reserve some processing for their own purposes, typically abuse and safety monitoring, for which they act as a controller in their own right. Your Article 28 agreement covers the processor leg only.
Data at rest versus inference location. “Stored in the EU” says nothing about where the prompt is processed. All three hyperscalers offer global deployment types that run inference anywhere in the world while data at rest stays in Europe. Residency is the configuration that fixes both. Sovereignty is which jurisdiction’s law can reach the data regardless of where it sits, and a region setting does not change it.
Zero data retention and abuse monitoring. Most API vendors keep prompts and outputs for a limited period for abuse detection, sometimes with human review. Zero data retention (ZDR) or “modified abuse monitoring” switches that off, usually on request and after approval. A few frontier models carry retention that only the vendor can waive.
Model provider, system provider and deployer. The AI Act’s roles. The lab that trains the LLM is the provider of a general-purpose AI model. If you build an agent system and run it under your own name, you are the provider of that AI system, with transparency duties today. If you only use someone else’s system, you are a deployer. Using a model, or fine-tuning it with ordinary enterprise data, does not make you a model provider.
Open-weight, open-source and self-hosted. Open-weight means the parameters are downloadable. It does not mean open-source: several 2026 releases carry revenue caps or regional exclusions. Self-hosted means you run the model on infrastructure you control, which makes you the operator and moves every security and retention question to your side of the line.
What leaves the building when an agent runs?
A code-completion plugin sends fragments of the open file. An agentic SDLC harness sends context. The whole point of grounding agents in real systems, which is what makes their output verifiable, is that they read the issue tracker, the repository, the CI logs, the observability platform and the service desk. That context is the payload, and it differs by stage:
- Requirements and design. Stakeholder names, customer feature requests, a commercially sensitive roadmap. Light on personal data, heavy on confidentiality.
- Code and configuration. Secrets, infrastructure detail and regulated business logic: credit decisioning, AML rules, game-fairness logic. Confidential rather than personal. GDPR ignores it; DORA, NIS2 and your customer contracts do not.
- Tests and fixtures. Where production data gets copied. Often the highest concentration of personal data in the whole SDLC, and the least noticed.
- Telemetry and incidents. Customer identifiers, IP addresses and transaction data, live and current.
- Support history. The richest personal data of all, and the hardest to pseudonymise, because the answer the agent needs is usually in the thread.
- Release artefacts and customer-facing output. Little personal data, but this is where the AI Act’s transparency and labelling duties bite.
So the data question cannot be answered per tool. It has to be answered per data class and per SDLC stage, then enforced at the harness boundary, where context is assembled before anything is sent to a model.
What is probably wrong in your tenant today?
The defaults are the trap. On Azure, every new OpenAI model launches as Global Standard, reaches the EU Data Zone weeks or months later, and may never get a regional deployment. On Bedrock, the global inference profile is ten per cent cheaper than the EU profile. Microsoft Copilot switched on “Flexible inferencing during peak load periods” by default for EU tenants in April 2026, which lets inference leave the EU Data Boundary until an administrator turns it off, and its Anthropic models sit outside the boundary entirely unless an administrator opts in. GitHub Copilot’s EU data residency, which covers agent mode, the coding agent and the CLI, is an enterprise policy that defaults to off and costs ten per cent more. Underneath all of that, the IDE model picker and personal accounts on consumer tiers are where training exclusions stop applying.
If a Global deployment has been serving your agents, data at rest stayed in the EU, nothing was used for training, and the transfer is probably covered by the Data Privacy Framework or standard contractual clauses. It is not a breach. It is a transfer your transfer impact assessment did not cover, a processing location your DORA contract said you would be told about, and, on Azure, the only way to reach the Codex models or Claude at all. That last point is the trade-off this whole article turns on.
What does GDPR require when you send data to a model?
Nothing in GDPR prohibits sending personal data to an LLM. It applies the usual obligations to a new processor.
Purpose first, then lawful basis. Start from whether the agent’s use is compatible with the purpose you collected the customer data for. A documented three-step legitimate-interest test, which the EDPB’s December 2024 opinion on AI models requires in full, covers most engineering uses. Health data in claims or support threads needs an Article 9 ground, and employee data in commits and incident threads attracts national rules on top.
A processor contract on each route. Your Article 28 counterparty is whoever processes the prompts: the hyperscaler on Azure OpenAI, Bedrock and Vertex AI, Anthropic itself for Claude on Foundry. Read the DPA for the vendor’s own-purpose processing, where it is a controller rather than your processor.
One DPIA for the pattern. An EDPB-commissioned expert report of April 2025 treats prompts, context windows and outputs as risk vectors. A harness that pulls telemetry and tickets into context is high-risk processing. Assess the pattern once and revise it per route change, not per tool.
Minimisation before the model. Pseudonymise or strip personal data at the context-assembly step, before the prompt exists. This works well for code, fixtures and telemetry, where identifiers can be tokenised without losing the task. It works badly for support history, where the answer is in the thread. Those classes go to an EU-pinned or self-hosted route with a human gate, which is what the routing policy below is for.
Retention and training in writing. The major enterprise APIs exclude customer data from training by default; several free tiers and China-hosted APIs do not. Confirm per contract, and check retention per model rather than per vendor (see the notes under the availability table).
Transfers, honestly. EU inference narrows the transfer footprint. It does not remove it. Remote access by non-EEA support or abuse-review staff is a transfer under EDPB guidance, and the vendors’ own documentation shows metadata and safety-flagged content leaving the region on some routes. Map those flows. The EU-US Data Privacy Framework survived the General Court in September 2025, but the Court of Justice appeal is pending and the US institutions it rests on weakened during 2026. Where the importer is not DPF-certified, standard contractual clauses with a transfer impact assessment are the primary mechanism, not a fallback.
One more point from the EDPB’s 2024 opinion: where a model was built by unlawful processing of personal data, supervisory authorities may ask whether the deployer made a proportionate assessment of that risk. Keep the provider’s model documentation and training-data summary on file. The AI Act now obliges providers to produce both.
Residency, localisation, sovereignty: what are you buying?
“EU residency” is sold at three layers.
Location. Azure’s EU Data Zone, Bedrock’s EU inference profiles and Vertex AI’s EU multi-region keep inference inside EU member states. Azure’s zone may include Norway and Switzerland, Google’s excludes the UK and Switzerland, and which countries your “EU” means belongs in your DORA contract’s location clause, not in a vendor’s definition that can change without notice. This layer is a configuration you can pin with policy.
Legal reach. A US-controlled provider is subject to the CLOUD Act wherever the data sits. In June 2025 Microsoft France told a Senate inquiry under oath that it could not guarantee French data would never reach US authorities. The same applies to AWS and Google. The EU’s answer is in progress. The Data Act, applicable since September 2025, obliges cloud providers to prevent third-country access to non-personal data where it would conflict with EU law; personal data stays under GDPR Article 48. The proposed Cloud and AI Development Act (June 2026) would grade cloud services on four “Union assurance levels”, from EU-located infrastructure to EU ownership with no derogations.
Operational control. The sovereign-cloud products: the AWS European Sovereign Cloud, live in Brandenburg since January 2026 under German entities with EU-resident staff; Microsoft’s EU-personnel-only access control, external key management and European board; and Google’s French partner S3NS, whose core offering is SecNumCloud-qualified, with Vertex AI in scope not yet confirmed. All three lag on model choice. The only model live on Bedrock inside the AWS sovereign region is Google’s open-weight Gemma 4.
Residency is a setting, sovereignty is a structure. Unless a contract, a national scheme such as SecNumCloud or C5, or your regulator demands EU ownership, pin the setting, document the posture, and spend the model choice you save on the engineering problem.
Where does the EU AI Act bite an engineering organisation?
The Digital Omnibus on AI, Regulation (EU) 2026/1744, took effect on 27 July 2026 and reset the timeline:
- High-risk obligations moved to 2 December 2027 for stand-alone systems (Annex III) and August 2028 for product-embedded ones.
- Transparency did not move. Article 50 applied on 2 August 2026 in three limbs: providers must design AI systems so that people know they are interacting with AI; synthetic output must carry machine-readable marking, with a grace period to 2 December 2026 for systems already on the market; and deployers must disclose deepfakes and AI-generated public-interest text.
- AI literacy was softened to a duty to take measures supporting staff literacy, with no guaranteed level.
- Model-provider obligations have applied since August 2025, with Commission fines possible since August 2026.
Where you sit depends on what you built. An agent harness you run under your own name makes you the provider of an AI system: the design limb of Article 50 and the literacy duty apply to you now. Using or fine-tuning the underlying model does not make you a model provider; the Commission’s threshold for that is a modification using more than a third of the original training compute, which no fine-tuning programme approaches. A coding, review or test-strategy agent is not high-risk; Annex III does not list software engineering. One caution: a review agent whose output feeds engineer performance evaluation can fall under the employment entry. Your products are a separate question. Credit scoring, life and health insurance pricing, recruitment decisions and biometric identification are all listed, so if agents build those systems the SDLC’s traceability becomes conformity evidence, and if you deploy them you carry deployer duties and, for banks and insurers, a fundamental-rights impact assessment from December 2027.
The GPAI Code of Practice, signed by Amazon, Anthropic, Google, IBM, Microsoft, Mistral and OpenAI among others, and by no Chinese lab, commits providers to a model documentation form for downstream providers and the AI Office. Ask your vendor or hyperscaler for the downstream pack; it is the right input for your DPIA and DORA files. Harmonised standards are still unpublished, and ISO/IEC 42001 carries no presumption of conformity, but it is the AI management-system certification buyers and auditors currently ask for.
What does DORA add if you are a financial entity?
For banks, insurers, payment and e-money institutions, investment firms, crypto-asset service providers and the other entities in its scope, DORA has applied since January 2025, and it is the regime that governs your LLM choices today.
Every model route is an ICT service with a contract behind it. The register of information is keyed on contractual arrangements: your Microsoft agreement, your AWS agreement, your direct contract with a lab. Article 30(2) terms, including the locations of data processing and storage with notice of changes, apply to every ICT contract. If the service supports a critical or important function, Article 30(3) adds quantified service levels, audit and access rights and participation in resilience testing, and your own exit strategy under Article 28(8) has to be one you could execute. An agent harness in the path to production for a core platform supports such a function. One that drafts internal documentation probably does not. Decide per use case and record it.
Decide what the lab is. Where you reach a model through a hyperscaler, the hyperscaler is your provider. Whether the lab whose weights it runs is a subcontractor under the 2025 subcontracting standards or a licensor is a judgement to document. On Microsoft Foundry the chain is inverted: Anthropic is the contracting provider.
Concentration risk is now an AI question. In July 2026 the three European Supervisory Authorities confirmed that hosted frontier models are ICT third-party dependencies under DORA, alongside the AI Act, to be inventoried, assessed, contracted for and included in concentration analysis. The same month the ECB asked the significant institutions it supervises directly for action plans on AI-enabled cyber threats by 31 October 2026. If your whole SDLC runs on one provider’s model, that is a concentration you need to be able to explain and exit.
Designation does not change your duties. The first list of critical ICT third-party providers, published in November 2025, named nineteen firms including AWS, Microsoft, Google Cloud, Oracle and IBM, and no model lab. Designation gives the supervisors oversight of the cloud; it gives you nothing, and reliance on a designated provider is a concentration data point. The reasons to prefer a hyperscaler route are that the hyperscaler is your processor, the lab does not receive your prompts under AWS’s and Google’s terms, and that is where EU inference exists today.
Outside finance, NIS2 brings similar supply-chain and incident expectations to essential and important entities, with four member states still untransposed, and the Cyber Resilience Act’s vulnerability-reporting duties bound manufacturers of products with digital elements from September 2026.
Which models can you run with EU inference on Azure, AWS and Google?
For an Azure-primary organisation the finding is simple: as of October 2026, neither Claude nor OpenAI’s Codex line can be pinned to EU inference on Microsoft Foundry. The mainline GPT models can. Claude’s EU routes are Bedrock and Vertex AI.
| Model family | Microsoft Foundry (Azure) | Amazon Bedrock | Google Vertex AI |
|---|---|---|---|
| OpenAI GPT-5.x and 6.x | Yes for the mainline models (GPT-5.5, 5.6, 6 Sol and Luna, 6.1 Sol) in the EU Data Zone. Codex, Pro and Astra variants Global only. | No. GPT-5.5 is US only. | No. |
| Anthropic Claude | No EU Data Zone "coming soon". Global Standard from Sweden Central; Anthropic is your processor. | Yes. EU inference profiles across six EU-27 regions. | Yes. EU multi-region, Belgium and Netherlands. |
| Google Gemini | No | No. | Yes. All EU regions; air-gapped on Google Distributed Cloud. |
| Mistral | Partial Large 3 and Medium 3.5 in the EU Data Zone as "sold by Azure" (preview). Marketplace SKUs Global only. | Partial. Large 3 in Stockholm; Ministral in five EU regions. | Yes. EU multi-region. |
| DeepSeek | Partial V4-Flash in the EU Data Zone under Microsoft's terms. V4-Pro Global only. | Partial. V3.2 in Stockholm only; R1 US only and end-of-life. | Yes. EU multi-region. |
| Meta Llama | Partial Provisioned EU Data Zone only (Llama 3.3 70B). | No. US only, end-of-life 2027. | Yes. EU multi-region. |
| Alibaba Qwen | Not listed. | Yes. Frankfurt, Stockholm, Milan. | Yes. EU multi-region. |
| OpenAI gpt-oss (open weights) | Not listed. | Yes. Frankfurt, Stockholm, Milan, Ireland. | Yes. EU multi-region. |
| xAI Grok | No. US Data Zone only. | No | No |
Verified against the vendors’ region and residency documentation on 13 October 2026. Availability changes monthly; check the linked pages in the sources before you commit to a route.
Only OpenAI and Mistral sell EU inference directly. OpenAI’s EU-region API projects require zero data retention or modified abuse monitoring to be approved before use, and ChatGPT Enterprise offers EU inference residency. Mistral’s EU endpoint runs in EU and EFTA data centres at a ten per cent premium; its default endpoint carries no location commitment. Anthropic’s direct API offers US or global inference only. DeepSeek’s direct API is China-hosted, with no adequacy decision, a provider subject to China’s National Intelligence Law, and no transfer impact assessment that works.
Retention follows the model, not the platform. Anthropic’s Fable and Mythos models carry 30-day retention on the direct API, Bedrock and Vertex alike, waivable only with Anthropic’s express authorisation; the Opus, Sonnet and Haiku lines are not retained by default. On Bedrock, inputs and outputs are not stored by default and a service control policy can force that organisation-wide. On Azure, abuse-monitoring review for EEA deployments is done by EEA-located staff, and the data store stays in your geography even on Global deployments.
When does self-hosting make sense?
Self-host when a data class contractually or legally cannot leave infrastructure you control, when the environment is air-gapped, or when a sustained workload keeps a dedicated node busy enough to beat per-token pricing. Everything else goes through an EU-pinned hyperscaler route. Most regulated organisations end up with both and a harness that decides which is which.
The 2026 open-weight field can carry serious engineering work. Mistral Large 3 and Small 4 (Apache 2.0, French), Google’s Gemma 4 (now Apache 2.0), OpenAI’s gpt-oss-120b (Apache 2.0, a single 80 GB GPU), Alibaba’s Qwen 3.5 and 3.8 (Apache 2.0), DeepSeek V4 (MIT) and Aleph Alpha’s Kolibri-1 (Apache 2.0, trained in Germany, released this month) are all credible for coding and assistant workloads. The gap to the closed frontier is about twelve points on the Artificial Analysis index, and on SWE-bench Pro the best open-weight result sits in the low sixties against roughly ninety for the top closed model. Inside a harness with scoped tasks and verification gates that matters less than it looks. For open-ended autonomous work it matters a great deal.
Read the licence file, not the press release: Mistral’s Devstral 2 and Medium 3.5 exclude companies above a revenue threshold, Moonshot’s Kimi K3 and Z.ai’s GLM-5.3 moved from MIT to revenue-gated terms this year, and Llama 4 withholds multimodal rights from EU-domiciled companies. Document provenance whatever the origin. Chinese-origin models are not banned in the EU; the restrictions in Italy, the Netherlands, Czechia and Belgium target the DeepSeek consumer app and the China-hosted API, and Czechia’s cyber agency explicitly carves out locally run open models. But the US CAISI evaluation found DeepSeek R1 complied with 94 per cent of malicious requests under jailbreak, CrowdStrike documented it producing weaker code when prompts touched politically sensitive topics, and the Commission’s JRC and ENISA began testing Chinese open weights on their own hardware this month. Pull weights in safetensors format, pin the commit hash, verify checksums and mirror internally; the 2025 PickleScan bypass vulnerabilities on Hugging Face were rated critical.
Then count the cost honestly. On EU GPU providers in October 2026 a single H100 runs roughly $2,200 to $3,300 a month on demand, enough for gpt-oss-120b or Gemma 4. An eight-GPU H100 or H200 node for a 400B-class model runs $17,000 to $31,000 a month, and the inference engine (vLLM or SGLang), patching, prompt-injection defence and throughput tuning add one to two platform engineers on top. EU providers with managed open-weight endpoints or bare GPU include OVHcloud, Scaleway, IONOS, STACKIT, T-Systems, Nebius and Mistral Compute. Under the AI Act, running unmodified open weights does not make you a model provider; you remain the provider of the system you built around them.
Which controls make the policy hold?
- Classify data by SDLC stage. The six classes above, written down once. Every control that follows keys off this list.
- Route by class, not by tool. The harness holds the routing policy: which model, on which platform, in which region, for which class. State the trade-off in the policy: on Azure, pinning to the EU Data Zone removes the Codex models and Claude, so those workloads go to Bedrock or Vertex or wait, and the exception path has a named approver.
- Pseudonymise at the boundary. Tokenise identifiers when context is assembled, before any prompt exists, for the classes where it works. Send the rest to the EU-pinned or self-hosted route with a human gate.
- Redact secrets and scope the agent. Secrets scanning on every context assembly, least-privilege credentials per agent, an allowlist of MCP servers and tools, and no write access to production without a human in the loop.
- Treat pulled context as untrusted. Tickets, support threads and web pages are the prompt-injection surface of a harness. Strip instructions from retrieved content, allowlist tool calls, and gate any side effect.
- Pin residency and identity with policy. Deny the Global Standard SKU with Azure Policy, force the retention mode with an AWS service control policy, disable caching per Vertex project, and alert on inference-profile changes. Put every seat behind SSO and close the personal-account route.
- Log the evidence. For every agent action, record the model version, the platform, the inference region and the retention mode alongside the prompt and output. That is the audit evidence behind your DPIA and your DORA register, which itself is keyed on the contract.
- Keep the harness portable, measured and capped. Skills, sub-agents and evaluation suites that are not bound to one provider make an exit strategy credible and a concentration conversation short. Run the evaluation suite on every model change, and cap spend per team.
- Name the human. Every artefact an agent produces has a gate and a person who signs it. Whatever built a change never checks it. That remains the answer to “who is answerable for what the AI produced?”, and nothing in the regulation above changes it.
How Cleverbit builds this into the Agentic SDLC
Cleverbit’s Agentic SDLC is tailored to each organisation, and the tailoring starts with the questions above. An opening workshop works through risk appetite, regulatory obligations, approved-vendor constraints and existing enterprise agreements alongside the current SDLC and AI maturity. What typically comes out of it is a first view of which data classes can go to which models, where inference would run, what would need pseudonymising before it leaves the harness and what evidence would be worth logging per agent action.
A pilot then takes that view into one team and one real workflow, in the client’s own repository: version-controlled skills and sub-agents grounded in the client’s systems through the Model Context Protocol, with residency and retention settings enforced by platform policy where the platform supports it. The model behind the harness is treated as configuration, so routing can move between OpenAI on Azure, Claude on Bedrock or Vertex, Mistral in France or an open-weight model on the client’s own GPUs as the availability table changes, as it will. The approach draws on a multi-year engagement inside a large enterprise SaaS engineering organisation and on building Cleverbit’s own software the same way.
Everything stays in the client’s repository, owned by the client’s engineers, and the aim is for the evidence a DPIA and a DORA register need to be captured as a by-product of the harness rather than assembled afterwards.
Ready to put a residency policy under your agents?
Start with a workshop. It works through your data classes, the routes open to you in your tenant and the evidence your DPIA and DORA register will need, and it sets out what a pilot in one of your teams could look like.
This article is general information for engineering leaders, not legal advice. Legal, your DPO and compliance should review any policy built from it; accountability stays with management.
Sources
Regulation and supervisory material:
- Regulation (EU) 2024/1689 (AI Act), consolidated text: https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Digital Omnibus on AI, Regulation (EU) 2026/1744, summary and new dates: https://artificialintelligenceact.eu/ai-act-explorer/digital-omnibus/
- European Commission, Guidelines on transparency obligations (Article 50), July 2026: https://digital-strategy.ec.europa.eu/en/library/guidelines-transparency-obligations-providers-and-deployers-ai-systems
- European Commission, GPAI Code of Practice and signatories: https://digital-strategy.ec.europa.eu/en/policies/gpai-code-practice
- European Commission, Guidelines on the scope of GPAI provider obligations: https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers
- Regulation (EU) 2022/2554 (DORA): https://eur-lex.europa.eu/eli/reg/2022/2554/oj
- ESAs, designation of critical ICT third-party providers, November 2025: https://www.eba.europa.eu/publications-and-media/press-releases/european-supervisory-authorities-designate-critical-ict-third-party-providers-under-digital
- ESAs joint statement on ICT risks from frontier AI models, July 2026: https://www.esma.europa.eu/press-news/esma-news/eba-eiopa-and-esma-call-enhanced-governance-and-consistent-supervision
- EDPB Opinion 28/2024 on personal data in AI models: https://www.edpb.europa.eu/system/files/2024-12/edpb_opinion_202428_ai-models_en.pdf
- EDPB Support Pool of Experts, AI privacy risks and mitigations in LLMs, April 2025: https://www.edpb.europa.eu/system/files/2025-04/ai-privacy-risks-and-mitigations-in-llms.pdf
- Regulation (EU) 2023/2854 (Data Act): https://eur-lex.europa.eu/eli/reg/2023/2854/oj
- European Commission, proposal for a Cloud and AI Development Act, June 2026: https://digital-strategy.ec.europa.eu/en/library/proposal-cloud-and-ai-development-act-cada
- French Senate, hearing of Microsoft France, 10 June 2025: https://senat.fr/compte-rendu-commissions/20250609/ce_commande_publique.html
- NIST CAISI, evaluation of DeepSeek models, September 2025: https://www.nist.gov/document/caisi-evaluation-deepseek-ai-models-report
Vendor documentation:
- Microsoft Foundry, deployment types: https://learn.microsoft.com/azure/foundry/foundry-models/concepts/deployment-types
- Microsoft Foundry, region availability for models sold by Azure: https://learn.microsoft.com/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure-region-availability
- Microsoft Foundry, data, privacy and security for Azure OpenAI: https://learn.microsoft.com/azure/foundry/responsible-ai/openai/data-privacy
- Microsoft Foundry, Claude model hosting comparison: https://learn.microsoft.com/azure/foundry/foundry-models/concepts/claude-models-hosting-comparison
- Microsoft Copilot, AI subprocessor (Anthropic) and EU Data Boundary: https://learn.microsoft.com/microsoft-365/copilot/connect-to-ai-subprocessor
- Microsoft, European Digital Commitments one year on, April 2026: https://blogs.microsoft.com/on-the-issues/2026/04/29/one-year-on-progress-on-our-european-digital-commitments/
- GitHub, Copilot with data residency: https://docs.github.com/en/enterprise-cloud@latest/admin/data-residency/github-copilot-with-data-residency
- GitHub changelog, Copilot data residency in US and EU, 13 April 2026: https://github.blog/changelog/2026-04-13-copilot-data-residency-in-us-eu-and-fedramp-compliance-now-available
- Amazon Bedrock, cross-region inference: https://docs.aws.amazon.com/bedrock/latest/userguide/cross-region-inference.html
- Amazon Bedrock, data retention modes: https://docs.aws.amazon.com/bedrock/latest/userguide/data-retention.html
- Amazon Bedrock, security and compliance: https://aws.amazon.com/bedrock/security-compliance/
- AWS, launch of the European Sovereign Cloud, January 2026: https://press.aboutamazon.com/2026/1/aws-launches-aws-european-sovereign-cloud-and-announces-expansion-across-europe
- AWS, open-weight models on Bedrock in the European Sovereign Cloud, September 2026: https://aws.amazon.com/blogs/security/run-open-weight-models-on-aws-bedrock-in-aws-european-sovereign-cloud/
- Google Cloud, Vertex AI data residency: https://docs.cloud.google.com/vertex-ai/generative-ai/docs/learn/data-residency
- Google Cloud, Vertex AI generative AI data governance: https://docs.cloud.google.com/vertex-ai/generative-ai/docs/data-governance
- Anthropic, data residency: https://platform.claude.com/docs/en/manage-claude/data-residency
- Anthropic, API data retention: https://platform.claude.com/docs/en/manage-claude/api-and-data-retention
- OpenAI, your data and EU data residency for the API: https://developers.openai.com/api/docs/guides/your-data
- OpenAI, data residency for ChatGPT Enterprise: https://help.openai.com/en/articles/9903489
- Mistral AI, regional inference: https://docs.mistral.ai/inference/regional-inference
- Artificial Analysis, model leaderboards: https://artificialanalysis.ai/leaderboards/models
- Nebius, GPU pricing: https://nebius.com/prices
FAQ
Is “data stored in the EU” the same as “processed in the EU”?
No. Data at rest stays in your chosen region on every deployment type, but the global deployment types on all three hyperscalers can run inference anywhere in the world, and on Bedrock’s cross-region profiles any abuse-detection data is stored in the region that served the request. Only the EU Data Zone (Azure), the EU inference profiles (Bedrock) and the EU multi-region or EU regional endpoints (Vertex AI) keep processing inside the EU.
Do we need a DPIA for a coding assistant?
If personal data can reach the model, and in most codebases it can through logs, fixtures and tickets, the EDPB-commissioned guidance points to yes. Run one DPIA for the agent-harness pattern and revise it per route change, rather than one per tool.
Does using an LLM make us a provider under the AI Act?
Using a model, or fine-tuning it with ordinary enterprise data, does not make you a model provider. Building and operating an agent system under your own name does make you the provider of that AI system, which carries the Article 50 design duty and the AI literacy duty today, and the full high-risk obligations from December 2027 if the system is one of the listed uses.
Can a bank use Claude or GPT under DORA?
Yes, on the same conditions as any ICT service: a register entry keyed on the contract, a critical-or-important-function assessment, Article 30 terms including data location, and an exit strategy you could execute. Choose the route on those terms and on where EU inference exists: Claude through Bedrock or Vertex AI, the mainline GPT models through the Azure EU Data Zone. The hyperscaler’s designation as a critical provider changes the supervisors’ relationship with it, not yours.
Is DeepSeek banned in the EU?
No. The DeepSeek consumer app is blocked in Italy and barred from government devices in several member states, and the China-hosted API is unsuitable for regulated data. The open weights, run on EU infrastructure or through Azure, Bedrock or Vertex in the EU, are not banned. Document the provenance and behavioural testing in your model selection record.
Which standards will procurement ask about?
ISO/IEC 27001 and the 2025 standalone edition of ISO/IEC 27701 for privacy, SOC 2 Type II for UK and US-influenced finance, ISO/IEC 42001 for AI governance, and the national cloud schemes where you operate, principally Germany’s BSI C5 and France’s SecNumCloud. The EU’s own cloud certification scheme, EUCS, remains unadopted. For model vendors, ask for the Code of Practice documentation form and the ISO 42001 certificate.