Azure OpenAI and the EU AI Act: Who Owns the Compliance Obligation?

Azure OpenAI Service is a build-on service. You call OpenAI's models — GPT-4o, o3, or others — via Microsoft's Azure infrastructure to construct your own AI feature or system. The models themselves sit behind OpenAI and Microsoft; your application sits in front of users. That layering has a direct legal consequence under the EU AI Act (Regulation (EU) 2024/1689): when you place your application on the market or put it into service under your own name, you are almost certainly the provider of that system, with the full provider stack of obligations under Article 16.

The underlying GPAI model obligations — technical documentation, copyright policy, training-data summary — fall on OpenAI and Microsoft under Article 53. Your concern is the system you have built on top.

The central question: what does your system do?

The EU AI Act classifies AI systems by use, not by the model powering them. Azure OpenAI is not inherently high-risk, limited-risk, or minimal-risk. The system you build and deploy might be any of the four tiers.

A useful starting checklist before anything else:

• Does the system perform a function listed in Annex III (biometrics, credit scoring, recruitment, law enforcement, etc.)? If so, it is presumptively high-risk under Article 6.
• Does it interact directly with natural persons as a chatbot or generate synthetic content? If so, Article 50 transparency duties apply from 2 August 2026.
• Is it a safety component of a product covered by EU harmonised legislation (medical devices, machinery, civil aviation)? Article 6(1) and Annex I pull it into the high-risk tier via a different route.
• Is it an internal productivity tool — drafting emails, summarising documents, generating code — used by your own staff for non-consequential tasks? That is likely minimal risk with no mandatory obligations.

Most organisations building on Azure OpenAI will touch more than one category simultaneously: a customer-facing chatbot that also performs credit pre-screening sits in both Article 50 and Annex III point 5(b).

Role logic: provider, deployer, or both?

You are the provider (Article 16) if you develop the system and place it on the market or into service under your name or trademark — regardless of whether the underlying model is Azure's. The definition in Article 3 makes no allowance for "we just wrapped an API": if your name is on it and users receive it as your service, the provider obligations are yours.

You are the deployer (Article 26) if you integrate Azure OpenAI into a system built by another party and use it under your own authority in a professional context — for example, licensing a third-party legal-review tool built on an AI model and running it on your own contracts. Deployer obligations are lighter: follow the provider's instructions, ensure meaningful human oversight, keep logs for at least six months (Article 26), and run a Fundamental Rights Impact Assessment (Article 27) if you are a public body or deploying a creditworthiness or life/health-insurance system.

Role shifts matter. Under Article 25, a deployer or distributor becomes a provider — and inherits the full provider stack — if it puts its own name on a system, substantially modifies it, or changes its intended purpose. A company that takes a general-purpose Azure OpenAI integration and repurposes it to screen job applicants has likely triggered that shift.

The practical read for most companies building on Azure OpenAI: if you have built a feature that end-users or customers receive as your product, you are the provider for that feature's EU AI Act purposes.

When your application is high-risk

If the system you built on Azure OpenAI performs a function that falls within Annex III, you carry the full high-risk compliance stack. The eight Annex III areas include:

1. Biometrics — remote biometric identification, categorisation, emotion recognition (where permitted)
2. Critical infrastructure — safety components in digital infrastructure, road traffic, utilities
3. Education and vocational training — admission decisions, evaluation, exam-monitoring
4. Employment and worker management — recruitment, screening, promotion, termination, task allocation (Annex III point 4)
5. Access to essential private and public services — creditworthiness and credit scoring, excluding fraud detection (point 5(b)); health and life insurance risk and pricing (point 5(c)); emergency dispatch; public-benefits eligibility
6. Law enforcement — offending/re-offending risk, polygraphs, evidence reliability, profiling
7. Migration, asylum, border control
8. Administration of justice and democratic processes

The Article 6(3) filter applies: an Annex III system is not high-risk if it poses no significant risk of harm — for example, it performs a narrow procedural task, or it improves the result of a previously completed human activity without influencing the outcome, or it does preparatory work only. But any system that profiles natural persons is always high-risk regardless of this filter. Providers claiming the exemption must document that assessment and still register the system under Article 49.

The provider stack for a high-risk Azure OpenAI application

Once classified as high-risk, you must complete the following before placing the system on the market or putting it into service. The deadline for stand-alone Annex III systems is 2 December 2027 — deferred from the original August 2026 date under the Digital Omnibus agreed in May 2026. For AI systems embedded as safety components in Annex I products, the deadline is 2 August 2028.

Risk management system — Article 9. A documented, ongoing process: identify foreseeable risks, estimate likelihood and severity, implement technical and procedural mitigations, evaluate residual risk, and re-assess throughout the system's lifecycle. This is not a one-time audit. For an employment-screening feature built on Azure OpenAI, foreseeable risks include demographic bias in ranking, disparate impact on protected groups, and gaming of the system by candidates.

Data and data governance — Article 10. Training, validation, and testing data must be subject to documented governance: relevance, representativeness, freedom from errors where possible, and specific consideration of bias where data reflects historical discriminatory patterns. You cannot simply inherit this from OpenAI; you must document how your fine-tuning data or retrieval-augmented datasets meet the standard.

Technical documentation — Article 11 / Annex IV. The documentation pack covers system design, intended purpose, foreseeable misuse scenarios, training data composition, performance metrics across relevant subgroups, risk management records, and human oversight procedures. This is the legal artefact that regulators and notified bodies inspect. It must be kept current for ten years after the system leaves the market (Article 18).

Transparency and information to deployers — Article 13. If you supply your high-risk system to downstream deployers, it must come with a clear, machine-readable instruction set: what the system is for, its limitations, the human oversight measures required, and the data it expects. Deployers cannot fulfil their own obligations (Article 26) without this information.

Human oversight — Article 14. The system must be designed so that a natural person can effectively oversee its operation, understand the outputs, intervene, override, and refuse to act on outputs. For an Azure OpenAI-powered credit pre-screening tool, this means the underwriter must be able to see why a score was generated, override it, and document that override — not merely rubber-stamp a recommendation.

Accuracy, robustness, and cybersecurity — Article 15. Appropriate levels of accuracy for the intended purpose; resilience against adversarial inputs and errors; documented cybersecurity measures. Azure's infrastructure-level security does not satisfy this for your application layer.

Conformity assessment — Article 43. Before market placement, you must demonstrate compliance with Articles 9–15. Most Annex III categories (outside biometrics, where a notified body is generally required under Annex VII) can be assessed by internal self-assessment under Annex VI. Internal does not mean lightweight: the documentation must survive external scrutiny.

EU Declaration of Conformity — Article 47. A signed declaration that the system meets all applicable requirements. After high-risk classification is confirmed, this accompanies the system to market.

Registration — Article 49. Before placing a high-risk system on the market or into service, you must register it in the EU database for AI systems (the database itself is established under Article 71). The registration captures system description, intended purpose, risk tier, and your contact details.

Post-market monitoring — Article 72. You must actively monitor the system's real-world performance after deployment and feed findings back into the risk management system. For employment or credit applications, that means tracking output quality and adverse outcomes, not just uptime metrics.

Serious incident reporting — Article 73. If the system causes or contributes to a serious incident — death (report within ten days), widespread infringement or critical infrastructure disruption (two days), or other serious incidents (fifteen days) — you report to the market-surveillance authority in the member state where the incident occurred.

When your application is limited-risk: Article 50

If you build a chatbot on Azure OpenAI, or any system that interacts directly with natural persons and could plausibly be mistaken for a human, Article 50 transparency duties apply. Users must be informed they are interacting with an AI system in a clear, timely, and intelligible way. If the system generates synthetic audio, video, images, or text intended for public release, it must be labelled as AI-generated.

Article 50 applies from 2 August 2026 — not deferred by the Digital Omnibus. It is already close.

The disclosure obligation sits with whoever is placing the system in users' hands. If that is you, you need to build the notification mechanism into the interface, not rely on a generic Azure disclaimer buried in service terms.

Chatbots that also perform an Annex III function — a virtual assistant that, in the background, scores a user's creditworthiness — carry both Article 50 duties and the full high-risk stack.

Azure's own obligations and the GPAI layer

Microsoft and OpenAI, as providers of the underlying GPAI model under Article 53, must maintain technical documentation of the model, inform downstream providers about capabilities and limitations, publish a copyright policy, and provide a summary of training data. If GPT-4 is designated as a systemic-risk GPAI model under Article 51, OpenAI must also satisfy the more demanding obligations in Article 55 — model evaluations, adversarial testing, incident reporting to the AI Office, cybersecurity measures.

None of that transfers your compliance obligations to Microsoft. The GPAI layer and your application layer are regulated separately. Microsoft's Azure AI compliance attestations cover Microsoft's obligations as a cloud infrastructure and GPAI provider; they do not constitute a conformity assessment of the system you have built on top.

Data residency and the Azure EU Data Boundary matter for GDPR compliance and, derivatively, for the EU AI Act's data governance requirements under Article 10. Azure's EU Data Boundary commitment processes EU customer data within the EU — relevant when documenting where training or inference data flows. However, confirm the specific services in scope; not every Azure OpenAI region or capability is covered in every contractual configuration.

Internal productivity use: the minimal-risk case

Not everything built on Azure OpenAI is high-risk or even limited-risk. A system that helps your developers write code, summarises internal meeting transcripts, or drafts initial versions of internal reports — and operates only within your organisation without consequential outputs affecting third parties — is likely minimal risk. No mandatory obligations under the EU AI Act apply.

The watch-out: scope creep. If an internal drafting tool starts producing customer-facing decisions, or if outputs are fed into a credit or HR process without human intervention, the risk tier changes and your classification needs revisiting.

How Confir helps

The classification question — what tier is this system, and what role are we in — is where compliance work either starts correctly or goes wrong. Confir's rule-based classification engine walks you through the Annex III scenarios and the Article 6(3) filter, derives your role (provider or deployer), and maps out the exact obligation set that follows.

For each Azure OpenAI-based system you register, Confir generates the Article 11 / Annex IV technical documentation pack and the Article 47 Declaration of Conformity, runs the Article 27 Fundamental Rights Impact Assessment where required, and maintains a timestamped audit log. Classification, scoping, and findings are deterministic and reproducible — the same intake produces the same finding, and the rule that fired is human-readable. That matters for a compliance artefact that may need to survive regulatory inspection.

Register the system, classify it, and let the structured assessment identify the gaps. From €600 per year, no consultant required.

Frequently Asked Questions

Does Microsoft's Azure AI compliance certification cover my application?

No. Microsoft's compliance attestations — SOC 2, ISO 27001, and similar — cover Azure's infrastructure and the GPAI model layer. They do not constitute a conformity assessment of the system you have built on Azure OpenAI. Under the EU AI Act, you are the provider of your application; the provider carries the assessment obligation under Article 43. Microsoft's documentation is useful input to your technical documentation under Article 11, but it does not substitute for it.

Is an internal Azure OpenAI deployment high-risk?

It depends on function, not deployment mode. An internal tool that summarises documents or generates draft text for non-consequential tasks is likely minimal risk. If the internal system produces decisions or recommendations that affect employees — performance evaluation, task allocation, monitoring — it falls within Annex III point 4 (employment and worker management) and is high-risk. The internal/external distinction is not the classification axis; the function and affected persons are.

What is the deadline for high-risk Azure OpenAI applications?

For stand-alone Annex III systems: 2 December 2027, deferred from the original August 2026 date under the Digital Omnibus agreed in May 2026. For systems embedded as safety components in Annex I products (medical devices, machinery, civil aviation): 2 August 2028. Article 50 transparency obligations for chatbots and synthetic-content labelling apply from 2 August 2026 and were not deferred.

If we use Azure OpenAI to build a feature for our SaaS product, are we a provider?

Almost certainly yes. When you place a feature on the market under your own name or brand — even if the underlying model is Azure's — you are the provider of that feature for EU AI Act purposes (Article 3; Article 16). The obligations in Articles 9–15, 43, 47, 49, and 72–73 fall on you, not on Microsoft. Your downstream SaaS customers who use that feature are the deployers and carry deployer obligations under Article 26.

What happens if we substantially modify an Azure OpenAI integration we licensed from a third party?

Under Article 25, substantial modification of a high-risk AI system, or a change in intended purpose that takes it into a new Annex III category, converts the modifier into the provider of the modified system. You inherit the full provider stack from that point forward. What counts as "substantial modification" is defined in Article 3(23): a change affecting compliance with the applicable requirements, or a change of intended purpose. Repurposing a general-purpose Azure OpenAI integration to score credit applications would qualify.

What are the fines for non-compliance?

Under Article 99(4), non-compliance with provider obligations for high-risk systems (Articles 9–15, 16, etc.) can result in fines of up to €15 million or 3% of total worldwide annual turnover, whichever is higher. For SMEs and start-ups, the fine is capped at the lower of the percentage and the fixed amount — a statutory proportionality protection under Article 99(6). Violations of Article 5 prohibited practices carry the higher tier of up to €35 million or 7%.

Do we need to worry about the GPAI obligations ourselves?

The Article 53 obligations for GPAI providers — technical documentation, downstream information, copyright policy, training-data summary — sit with OpenAI and Microsoft, not with you. Your application is built on their model; you are not the model's provider. However, if you fine-tune a GPAI model significantly and place it on the market, you may become a GPAI provider in your own right for that derivative model. For most Azure OpenAI integrations using the API without fine-tuning, the GPAI obligations remain with OpenAI/Microsoft.

Related guides

• enterprise compliance guide
• Article 8 high-risk requirements
• Article 6 risk classification pathways
• step-by-step implementation framework
• Article 49 database registration
• provider obligations checklist
• Article 6 classification pathways
• Annex III social benefits assessment
• Article 9 risk management system
• Articles 6–29 compliance checklist