Can you use Microsoft Azure OpenAI Service on regulated or classified data?

For general enterprise data the answer is a qualified yes: Microsoft Azure OpenAI Service can be configured to satisfy many GDPR, ISO and sector obligations, and Microsoft publishes strong contractual commitments on how it handles customer prompts. For privileged, classified or material non-public information the honest answer is no. Azure OpenAI processes your prompts and completions inside Microsoft-operated regions, under Microsoft's control plane, within reach of the US CLOUD Act, and its data protections are contractual promises rather than architectural facts. The question that decides your own case is simple: is a promise not to look at your data enough, or do you need a design in which no external party can look at all?

This matters more now than two years ago. Buyers in finance, defence, law and critical infrastructure now face overlapping duties on operational resilience, third-party concentration and provenance, and their auditors have stopped accepting a vendor logo as evidence. The shortlist question has shifted from can it perform to can it be proven, and that shift is where a hosted cloud service and a sovereign substrate part company.

What does Azure OpenAI Service actually do with your data?

When you send a prompt, the text leaves your perimeter and is processed on Microsoft-managed hardware in an Azure region you select. Microsoft states that customer prompts and outputs are not used to train the foundation models, that data stays in the chosen geography, and that abuse monitoring and human review can be switched off for eligible customers. These commitments are real, and for a large class of workloads they are sufficient. What they cannot change is the underlying shape of the arrangement: the compute, the keys, the identity system and the region are all governed by the vendor, and your data is processed outside a boundary you control.

Where does Azure OpenAI fit, and where does it not?

It fits general business content, non-sensitive analytics, customer-service drafting under a data processing agreement, marketing copy and code assistance on repositories that hold no secrets. Wherever a contractual boundary plus regional residency satisfies the risk owner, it is a reasonable choice. It does not fit privileged legal material, classified or protectively marked government data, market-moving non-public information, source intelligence or anything where cross-border legal compulsion and vendor insider access are unacceptable residual risks. The dividing line is not model quality. It is the consequence of the data being seen by someone you did not authorise.

Which rules make an offline substrate necessary?

Several regimes push the highest tiers off shared cloud inference. DORA, in force since January 2025, requires financial entities to manage third-party concentration risk and prove they can exit a provider. NIS2 extends security and accountability duties across essential and important entities. GDPR still governs international transfers and the degree of control you retain over a processor. ISO/IEC 42001 asks you to evidence AI governance, not assert it. On the EU AI Act, the high-risk Annex III obligations once due on 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moving to 2 August 2028 and the Article 50 transparency duties largely unchanged. We read that as a build window, not a reprieve.

What can an auditor actually check?

With a hosted service, an auditor can inspect contracts, certifications, region settings and whatever logs the vendor exposes. What the auditor cannot do is independently verify that the vendor, or a party compelling the vendor, never accessed the data. The assurance terminates at the vendor's word. An architecture-first answer inverts this. If every action is written to a tamper-evident, cryptographically sealed ledger that the operator holds, the auditor checks the ledger itself rather than a promise about it. The named test is straightforward: can you prove what happened to a specific record without asking the vendor?

“A contractual promise not to look at your data is not the same as an architecture in which no external party can, and for classified or privileged information only the second is defensible.”

Why does the US CLOUD Act decide the classified case?

The CLOUD Act allows US authorities to compel US-headquartered providers to produce data under their control regardless of where that data physically sits. Regional residency does not remove this reach, and no data-handling clause can override a lawful order served on the provider. For most commercial data this is a manageable risk. For classified, sovereign or privileged material it is dispositive, because the whole point of the classification is that disclosure to a foreign jurisdiction is the harm you are guarding against.

What does an architecture-first answer look like?

Mickai is a Sovereign Intelligence Operating System, a SIOS that runs offline on operator-owned hardware so data never leaves the perimeter. The design rests on a small number of concrete mechanisms: a zero-egress inbound perimeter, so prompts and documents cannot be exfiltrated by construction; hardware-attested identity bound to the audit chain, so every action is tied to a verified operator; a post-quantum signed audit ledger, sealed and verified under FIPS 204 (ML-DSA) with FIPS 205 (SLH-DSA) as the belt-and-braces companion, giving offline verifiability that survives quantum computing; and cross-model consensus, so no single sovereign model is trusted blindly. Our sovereign models run inside that boundary rather than calling out to any public service. The approach is reflected in 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD; never granted or patented. The point is not that Azure OpenAI is unsafe. It is that for the data an auditor will not let you send anywhere, verifiability has to be built in, not promised.

Frequently asked questions

Is Azure OpenAI GDPR compliant?

It can be, when configured with a data processing agreement, an EU region and appropriate controls, and it satisfies many GDPR obligations for ordinary business data. Compliance still depends on your use case, your transfer analysis and your risk owner's assessment. For special category data or anything where processor control is critical, the residual questions around vendor access and cross-border compulsion remain.

Can Azure OpenAI be used for classified government data?

For genuinely classified or protectively marked material the general commercial service is not appropriate, because processing happens under the vendor's control plane and within US CLOUD Act reach. Classified handling generally requires an accredited, air-gapped or sovereign environment where the operator, not a third party, holds the keys and the audit trail. That is an architectural requirement, not a configuration setting.

Does the US CLOUD Act apply to data stored in European Azure regions?

Yes. The CLOUD Act can reach data controlled by a US-headquartered provider regardless of the storage region, so European residency alone does not place data beyond its reach. This is why residency and legal jurisdiction are separate questions. For the most sensitive tiers, only processing on hardware you own and control removes the exposure.

What is the difference between contractual and architectural data protection?

Contractual protection is a promise, backed by policy and audited after the fact, that a provider will handle your data a certain way. Architectural protection makes the unwanted outcome impossible by design, for example a zero-egress perimeter and a cryptographically sealed ledger the operator holds. For regulated or classified data, auditors increasingly want the second, because a promise cannot be independently verified and cannot override a lawful order.

When should a regulated buyer choose an offline substrate over a cloud AI service?

Choose an offline substrate when the data is privileged, classified or market-sensitive, when third-party concentration or exit is a supervisory concern under DORA or NIS2, or when an auditor needs to verify what happened without asking the vendor. For everything below that line, a well-configured cloud service is often the pragmatic choice. The decision is about the consequence of unauthorised access, not about model performance.