Compliance
Azure OpenAI EU compliance: residency before expansion
Azure OpenAI EU compliance is a region, logging and processor question, not a model question. Pexon documents where prompts are processed, which diagnostic settings your SOC already reads, and what the Microsoft agreements actually say — so legal can approve expansion for industrial companies under GDPR and the EU AI Act.
Two buyers, two objections
Security and legal do not ask the same question
Security / SOC
- Which region processes the prompt
- Where diagnostic logs land
- Who can read completions after the fact
- What happens on failover
Legal / DPO
- Processor and subprocessor list
- Retention and training position
- Record of processing activities update
- EU AI Act deployer obligations
An assertion without configuration is worth nothing
Vendor pages describe what is possible. Your ticket needs what is configured: the resource region, the diagnostic setting destination, content-filter mode, and whether any secondary path can leave the EU. We attach screenshots and portal exports to the answers, because that is what survives a works-council or customer questionnaire.
The EU AI Act adds deployer duties on top of GDPR. How you oversee the system and document residual risk sits with you even when Microsoft runs the model — which is why this page is architecture and evidence, not a marketing claim about 'EU AI'.
Evidence we collect before expansion
- Resource region and deployment list for every Azure OpenAI endpoint in scope.
- Diagnostic settings: destination, retention, and who in the SOC can query them.
- Content-filter and abuse-monitoring posture written in language legal can reuse.
- Gaps against the current record of processing activities, listed as tickets not prose.
- A one-page position on training, retention and subprocessors tied to Microsoft's current terms.
Trade-off
An EU-only path can cost model availability and sometimes latency. Pretending the global path is fine when contracts require EU processing costs the deal later. If your data classification allows non-EU processing, we will say so rather than sell you a narrower region you do not need.
Where this connects
- Governance and Entra — identity evidence that sits next to the residency evidence
- Claude EU hosting and GDPR — when Claude on Foundry or Bedrock shares the same legal review
- EU AI Act readiness — programme-level deployer obligations beyond one model endpoint
Questions buyers ask
Does using Azure OpenAI put us outside GDPR?
No, but it adds a processor relationship you must document. You need a defensible region story, a position on retention and training, and logging that matches what your record of processing activities already claims.
Is an EU region enough?
It is necessary and rarely sufficient. Legal will still ask about logging destinations, content-filter behaviour, subprocessors and whether any path can leave the EU under load or failover. Those answers come from configuration and contracts, not from the model card.
How does this relate to the EU AI Act?
Obligations attach to how you deploy the system and for what purpose, not only to which model you licensed. Classification, logging and human oversight sit with you as the deployer even when inference runs on Azure.
What do you deliver in two weeks?
A written residency and logging position tied to your actual resource configuration, gaps against what legal already promised, and a short list of changes required before the pilot may expand.
Next step
Start with what legal will ask next week
A two-week blueprint at €4,900. We tie your Azure OpenAI region, logging and processor story to what is actually configured, and leave a written position legal can attach to the expansion ticket.