Microsoft Azure AI Services Under the EU AI Act: Classify by Service, Classify by Use

Azure AI is not a single product — it is a family of roughly a dozen distinct services, each with its own inputs, outputs, and risk profile. Azure OpenAI generates text. Azure AI Vision analyses images. Azure Face detects and recognises faces. Azure Document Intelligence extracts structured data from documents. Each service can be used in ways that attract radically different obligations under Regulation (EU) 2024/1689. The only rule that matters: classify by what the service does in your specific context, not by the vendor name.

This guide walks through the main Azure AI services, maps each to the EU AI Act's risk tiers, and sets out what your organisation must do — depending on whether you are using a service to build something (making you a provider under Article 16) or deploying it in your own operations (making you a deployer under Article 26).

---

Two questions that determine everything

Before classifying any Azure AI service, answer two questions:

1. What does the service actually do in your use case? A service's general description is irrelevant. Azure OpenAI can draft marketing copy (minimal risk) or it can generate clinical advice that influences treatment decisions (potentially high risk). The use determines the tier.

2. What is your role? If you use an Azure service to build a product or feature that you then offer to customers under your own name, you are a provider (Article 16) with the full high-risk obligation stack where applicable. If you use an Azure service internally — for your own HR process, for customer-facing chat, for back-office automation — you are a deployer (Article 26). If you substantially modify an Azure AI component or repurpose it beyond its intended use, Article 25 converts you into a provider even if you started as a deployer.

Getting both answers right before you open any compliance checklist saves considerable wasted effort.

---

Service-by-service classification

Azure OpenAI Service

Azure OpenAI gives access to GPT-4 class models via API. Its EU AI Act classification depends entirely on what you build with it.

Generative feature facing users → Article 50 transparency. If you embed Azure OpenAI to produce text, images, or audio that users might mistake for human-created content, Article 50(1) requires disclosure that the output is AI-generated. This obligation applies from 2 August 2026. A customer-service chatbot powered by Azure OpenAI needs an Article 50(1) disclosure. A tool that generates synthetic media (video, audio deepfakes) triggers Article 50(4) watermarking requirements.

Build a recruitment screening tool on top of it → Annex III point 4(a), high risk. Use Azure OpenAI to rank or filter job applicants and that system falls under Annex III point 4(a) (employment, workers management, access to self-employment). You become the provider. Article 9 risk management, Article 11 technical documentation, Article 14 human oversight, and an Article 43 conformity assessment are all required before deployment. The deadline for stand-alone high-risk systems is 2 December 2027 (Digital Omnibus, political agreement May 2026).

Internal analytics with no individual-level decisions → minimal risk. Using Azure OpenAI to summarise internal meeting notes or draft procurement emails attracts no mandatory obligations beyond ensuring staff are appropriately informed under Article 4 (AI literacy, in force since 2 February 2025).

Azure OpenAI as GPAI. The underlying GPT-4 models are general-purpose AI (GPAI) models under Chapter V. Microsoft, as the model provider, bears the GPAI obligations (Articles 53–55). Your obligations as a downstream developer are those imposed by Article 25 and your contract with Microsoft — you do not inherit the GPAI duties, but you do inherit the risk classification that attaches to whatever you build on top.

Azure AI Vision and Custom Vision

Azure AI Vision analyses images and video for objects, scenes, text (OCR), and spatial relationships. Custom Vision lets you train classification models on your own image sets.

Product quality inspection on a factory line → minimal or limited risk. If the system flags defective components and a human reviews every flag before action, the Article 6(3) filter likely applies: the system improves a previously completed human activity and does not profile natural persons. Document the Article 6(3) assessment and keep it on file — providers claiming the exemption must record their reasoning.

Identity document verification in KYC → Annex III point 1, high risk. Using Azure AI Vision to compare a selfie against a passport photo is biometric identification. Annex III point 1 covers remote biometric identification systems. If the system contributes to a decision about who may access a service, it is high risk. The Annex VII notified-body route applies for conformity assessment under Article 43 for Annex III point 1 systems — not the simpler internal self-assessment route available for most other Annex III categories.

Azure AI Face

Face is the service that requires the most careful handling, because several of its capabilities sit at or near the Article 5 prohibitions.

Real-time facial recognition in publicly accessible spaces used by law enforcement → prohibited (Article 5(1)(h)). The Act bans real-time remote biometric identification of natural persons in publicly accessible spaces for the purposes of law enforcement, with narrow exceptions (serious crime pursuit, imminent threats, terrorism). This prohibition has applied since 2 February 2025. Microsoft has itself restricted access to certain Face API capabilities — but restrictions on the vendor side do not discharge your compliance obligations. If your use case resembles this pattern, stop before you start.

Biometric categorisation to infer sensitive attributes → prohibited (Article 5(1)(g)). Using Face to categorise individuals by race, political opinion, religious belief, sex life, or trade union membership is a prohibited practice regardless of consent. Again, in force since 2 February 2025.

Emotion recognition in the workplace or education → prohibited (Article 5(1)(f)). Deploying Face-based emotion recognition to monitor employee states or student engagement is banned. The ban is categorical: there is no compliance route, no conformity assessment, no exception.

Access control at a secure facility, non-law-enforcement, non-sensitive-categorisation context → Annex III point 1, high risk. The system must go through the Article 43 notified-body conformity route, carry full Article 11/Annex IV technical documentation, and operate under Article 14 human oversight. Post-market monitoring under Article 72 applies.

Important: Microsoft has restricted some Face API capabilities (e.g., "identification" of individuals in images, "verification" against a photo) to approved use cases. Check Microsoft's Responsible AI terms alongside your EU AI Act obligations — they are separate gates.

Azure AI Language and Azure Cognitive Services for Language

These services cover sentiment analysis, entity recognition, text classification, translation, and question-answering.

Internal text analytics for customer feedback → minimal risk. Aggregating sentiment across product reviews with no individual-level output does not fall in any Annex III category. Article 4 literacy obligations apply to staff operating the system.

Automated credit decision letter generation that assesses applicant sentiment → possible Annex III point 5(b). If the language model's output feeds into a creditworthiness decision, the system may fall under Annex III point 5(b) (access to essential services — creditworthiness/credit scoring). The Article 6(3) filter may still apply if the system performs purely preparatory work without influencing the assessment, but that claim requires documented justification.

Chatbot with transparent disclosure → Article 50(1) transparency only. A customer-service bot that identifies itself as AI when directly asked meets the Article 50(1) duty. That obligation applies from 2 August 2026.

Azure Document Intelligence (formerly Form Recognizer)

Document Intelligence extracts structured data from invoices, contracts, tax forms, and identity documents.

Automating invoice processing → minimal risk. No Annex III category applies. No mandatory obligations beyond Article 4 literacy for operators.

Extracting data from identity documents as part of a hiring or benefits eligibility decision → potential Annex III point 4 or point 5. If the extraction feeds directly into an automated decision on employment eligibility (point 4(a)) or social benefits (point 5(d)), classify the full system — not just the Document Intelligence component — against Article 6. The Art 6(3) exemption may apply if Document Intelligence is doing preparatory extraction that a human then reviews before any consequential decision.

Azure AI Content Safety

Content Safety detects harmful, offensive, or sensitive content in text and images. A moderation tool that assists human moderators without replacing their judgment is unlikely to fall in Annex III — the Article 6(3) filter applies because the system improves a previously completed human activity. Where Content Safety is the sole gate for removing content in a way that influences access to democratic processes, Annex III point 8 warrants review; in practice this is unusual for commercial deployments.

Azure AI Speech

Speech-to-text, text-to-speech, speaker recognition, and real-time translation. Call transcription for quality assurance with no individual-level decision output is minimal risk. Speaker recognition used to authenticate individuals for financial access can touch Annex III point 1 (biometrics) and point 5 (access to essential services) simultaneously — classify the end-to-end system, not the component alone. Synthetic voice output in a public-facing context requires Article 50(2)/(4) disclosure from 2 August 2026.

---

The role-shift trap under Article 25

The default assumption is that when you use an Azure AI service, Microsoft is the provider and you are the deployer. That breaks down in three situations:

1. You put your name on it. If you white-label an Azure AI capability and market it as your own product, you become the provider of that system under Article 25(1)(a).
2. You substantially modify it. Fine-tuning a model on your proprietary data, retraining a classifier, or materially extending capabilities counts as substantial modification under Article 3(23), converting you into a provider.
3. You change its intended purpose. Repurposing a general-purpose Azure AI component to make automated decisions in an Annex III domain — even without code changes — may trigger Article 25 if the new purpose falls outside the scope for which Microsoft placed the system on the market.

If any of these apply, you carry the full provider obligation stack: Article 9 risk management, Article 11/Annex IV technical documentation, Article 17 quality management, Article 43 conformity assessment, Article 47 Declaration of Conformity, Article 49 registration, and Article 72 post-market monitoring.

---

Deployer obligations that apply regardless of risk level

Even where a service is minimal risk and you remain a deployer, several obligations still bite.

Article 4 — AI literacy (in force since 2 February 2025). Staff who operate or oversee AI systems must have sufficient competence to understand what those systems do, their limitations, and when to escalate. Document this at the role level.

Article 26 — deployer obligations for high-risk systems. Use the system within the provider's instructions; implement human oversight; keep automatically generated logs for at least six months (Article 26); inform workers' representatives before deploying in the workplace (Article 26). The duty to report serious incidents to national market surveillance sits with the provider under Article 73; your duty is to flag to the provider and, where required, to the authority under Article 26.

Article 27 — FRIA. Not universal. It applies to public bodies deploying any high-risk system, and to private-sector deployers of creditworthiness/credit scoring (Annex III point 5(b)) or life/health insurance (point 5(c)) systems. A private employer using Azure ML for resume screening does not automatically owe a FRIA. A lender using it for credit scoring does.

Data residency. Microsoft's EU Data Boundary programme keeps data at rest and in processing within the EU/EEA. Verify your subscription actually enrols in EU Data Boundary — the default configuration does not guarantee this. EU residency simplifies GDPR compliance but does not substitute for the Article 10 data-governance documentation you must maintain as a provider.

---

Key deadlines for Azure AI deployments

Four dates govern Azure AI compliance. 2 February 2025 — Article 5 prohibitions and Article 4 AI literacy are already in force: stop any prohibited use case now and document staff literacy today. 2 August 2025 — GPAI obligations and penalties (Article 99) apply; this is Microsoft's compliance horizon for the Azure OpenAI models it offers. 2 August 2026 — Article 50 limited-risk transparency applies: chatbots and synthetic-voice outputs must carry disclosure. 2 December 2027 — the deadline for stand-alone Annex III high-risk systems, under the Digital Omnibus political agreement reached in May 2026 (deferred from August 2026). High-risk AI embedded in Annex I products (medical devices, machinery) has until 2 August 2028.

---

How Confir helps

Most organisations using Azure AI services need to inventory each service individually and classify it by use — not apply a single label to "our Azure deployment." Confir's register accepts one entry per system, with a guided intake that captures the service name, use case, output type, and downstream decision process. The rule-based classification engine derives the risk tier and your role from those answers; the same intake produces the same finding every time, with the rule that fired shown in plain language for audit purposes.

For high-risk systems, Confir generates the Article 11/Annex IV technical documentation pack and the Article 47 Declaration of Conformity, and it runs the Article 27 FRIA workflow for deployers in scope. The Compliance Health Score surfaces where documentation is incomplete so you can prioritise before the December 2027 window closes.

---

Frequently Asked Questions

Is Microsoft the provider of Azure AI services, and does that discharge my obligations?

Microsoft is the provider of the underlying Azure AI services and carries the corresponding provider obligations for those components. However, if you build a system on top of Azure AI services and offer it under your own name — or deploy it in an Annex III context — you become the provider of the resulting system under Article 16, or the deployer under Article 26. Microsoft's compliance with its provider duties does not substitute for yours. Check Microsoft's EU AI Act documentation and contractual commitments, but treat those as one input into your own compliance file, not a complete answer.

Which Azure AI services are most likely to be high risk?

Azure Face (biometric identification and categorisation), Azure OpenAI when used for employment screening or creditworthiness, and Azure ML models used in recruitment, insurance pricing, or credit scoring carry the highest likelihood of Annex III classification. Azure Document Intelligence, Language, Speech, and Content Safety are more commonly minimal or limited risk — but the use case, not the service name, is what determines the tier.

Does the Article 6(3) filter apply to Azure AI services used in internal workflows?

It can. The Article 6(3) filter removes high-risk classification for Annex III systems that perform narrow procedural tasks, improve the result of a previously completed human activity, detect patterns without replacing or influencing human assessment, or do preparatory work. The key condition: the system must not profile natural persons. If your Azure AI workflow assists a human decision-maker without substituting for their judgment, document the Article 6(3) assessment, record that no profiling of natural persons occurs, and register the finding under Article 49.

What are the penalties for non-compliance?

Penalties under Article 99 of Regulation (EU) 2024/1689 run to three tiers, each "whichever is higher" of a fixed sum or a percentage of worldwide annual turnover. Violations of Article 5 prohibitions: up to €35,000,000 or 7%. Violations of most other obligations — including high-risk provider and deployer duties: up to €15,000,000 or 3% (Article 99(4)). Supplying incorrect or misleading information to authorities or notified bodies: up to €7,500,000 or 1% (Article 99(5)). For smaller companies, fines are capped at the lower of the percentage or the fixed amount under Article 99(6) — a proportionality provision worth understanding before you assess your exposure.

When does the Article 50 chatbot disclosure obligation apply to Azure OpenAI deployments?

Article 50(1) requires that users interacting with an AI system — including chatbots — be informed they are interacting with AI, unless this is obvious from context. This applies from 2 August 2026, not from the high-risk deadline. If you deploy an Azure OpenAI assistant facing employees or customers, you need a disclosure mechanism in place by that date. The disclosure does not need to be intrusive — a clear label or opening message stating the system is AI-operated meets the requirement.

Does EU Data Boundary from Microsoft satisfy Article 10 data governance requirements?

Not automatically. Article 10 sets requirements for the data used to train, validate, and test high-risk AI systems — including representativeness, absence of errors, and appropriate data governance practices. EU Data Boundary is a data residency commitment (data stays in the EU/EEA) that addresses GDPR territorial concerns, but it does not substitute for the Article 10 data governance documentation you must maintain as a provider. Verify that your subscription configuration actually enrols in EU Data Boundary; then separately document your Article 10 compliance for the datasets your high-risk system relies on.

Do I need a Fundamental Rights Impact Assessment for every Azure AI deployment?

No. The Article 27 FRIA applies to a specific subset of deployers: public bodies and bodies providing public services deploying any high-risk system; and private-sector deployers of systems in the creditworthiness/credit scoring category (Annex III point 5(b)) or the life and health insurance risk and pricing category (point 5(c)). A private company using Azure ML for internal HR analytics does not automatically owe a FRIA. A lender using Azure ML to score credit applications does.

---

Related guides

• Article 6 risk classification methodology
• conformity assessment procedures
• enterprise compliance obligations guide
• Article 9 risk management system
• 2026 implementation roadmap
• provider obligations checklist
• Article 3 definitions
• Articles 6–29 compliance checklist
• Annex III high-risk assessment
• EU AI Act overview