EU AI Act Annex III: High-Risk Deadline Moved to 2027

Key Takeaways

• Annex III lists eight categories of AI use cases that can be classified as high-risk under the EU AI Act — it is not a list of AI systems that are automatically high-risk.
• The current application date for Annex III high-risk obligations is December 2, 2027, following the Digital Omnibus on AI that entered into force on July 27, 2026.
• August 2, 2026 remains an active EU AI Act milestone, but for different obligations: Article 50 transparency duties, AI literacy requirements, and enforcement of the Article 5 prohibitions and GPAI rules.
• High-risk AI embedded in regulated products under Annex I (medical devices, machinery, toys, and similar) now has until August 2, 2028.
• Classification runs through Article 6, which connects the Annex I and Annex III routes and includes an Article 6(3) filter that can exclude certain narrow, procedural, or preparatory AI systems from high-risk status.
• Profiling of natural persons removes the Article 6(3) exception, so systems that profile individuals inside an Annex III use case are treated as high-risk regardless of how limited their role appears.
• Compliance is broader than any single control: it spans risk management, data governance, technical documentation, human oversight, and post-market monitoring.
• The deferral buys planning time, not a reason to wait — the underlying obligations for data governance and documentation did not change, only the date they apply.

Annex III matters to almost anyone building, buying, or deploying AI inside a European market, even if their product doesn't look like a "regulated" system on the surface. A recruitment tool, a credit-scoring model, or an internal HR analytics dashboard can all touch an Annex III category without anyone on the team realizing the AI Act applies to them. Getting the classification question right early — before a system is built around assumptions that don't hold up — is usually far cheaper than retrofitting compliance after the fact.

What Is Annex III of the EU AI Act?

Annex III is the annex to Regulation (EU) 2024/1689 (the EU AI Act) that lists eight areas of AI use that can result in an AI system being classified as high-risk. It works together with Article 6, which is the operative provision that actually determines whether a given system is high-risk in law.

There are two separate routes to high-risk status under the AI Act:

The Annex I route (Article 6(1)): an AI system is high-risk if it is a safety component of a product, or is itself a product, already covered by EU product-safety legislation listed in Annex I — think medical devices, machinery, lifts, or toys — and that product is required to undergo third-party conformity assessment.

The Annex III route (Article 6(2)): an AI system is high-risk if it falls within one of the eight use-case categories listed in Annex III, subject to the Article 6(3) filter described below.

This distinction matters because the two routes carry different obligations, different transitional timelines, and different regulatory logic. Annex III is not a synonym for "high-risk AI system" — it is one gateway into that classification, defined by use case rather than by product type.

What Is the Current EU AI Act Annex III Deadline?

The Annex III deadline moved. The original text of the AI Act set August 2, 2026 as the application date for high-risk obligations tied to Annex III. In November 2025, the European Commission proposed delaying that date as part of a broader "Digital Omnibus" simplification package, citing the late arrival of the harmonized technical standards that providers need in order to demonstrate conformity. The European Parliament and Council reached political agreement on the delay in May 2026, the Council gave final approval on June 29, 2026, and the resulting Regulation (EU) 2026/1744 was published in the Official Journal on July 24, 2026, entering into force on July 27, 2026.

Two obligations sit on the August 2, 2026 date and are easy to confuse with Annex III compliance: the Article 50 transparency rules (disclosing that content is AI-generated, telling people they're interacting with an AI system) and the start of enforcement for rules that were already in force. Neither of those is the Annex III high-risk regime. If your organization's compliance calendar still treats August 2, 2026 as the date Annex III obligations become mandatory, that calendar needs correcting.

What enterprises should do now hasn't really changed, even though the date has moved. The extra runway exists because the technical standards underpinning conformity assessment weren't ready — not because the underlying obligations became less demanding. Risk management, data governance, documentation, and human oversight requirements are the same ones organizations were already expected to build toward.

What AI Systems Are Listed in Annex III?

Annex III groups high-risk use cases into eight areas. Each area covers specific, defined use cases within it — not every AI application that touches the general subject matter.

• Biometrics — remote biometric identification, biometric categorization based on sensitive attributes, and emotion recognition systems, where permitted.
• Critical infrastructure — AI used as a safety component in the management and operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating, or electricity.
• Education and vocational training — AI used to determine access or admission, to evaluate learning outcomes, to assess the appropriate level of education for an individual, or to monitor and detect prohibited behavior during tests.
• Employment, workers' management and access to self-employment — AI used for recruitment or selection, for decisions affecting terms of employment, promotion or termination, for task allocation, or for monitoring and evaluating performance and behavior.
• Access to essential private and public services and benefits — AI used to evaluate eligibility for public assistance benefits, for creditworthiness assessment and credit scoring, for AI risk assessment and pricing in life and health insurance, and for evaluating emergency call dispatch priority.
• Law enforcement — AI used to assess the risk of an individual becoming a victim or offender, as a polygraph, to evaluate evidence reliability, or to predict the occurrence of criminal offenses.
• Migration, asylum and border control management — AI used as a polygraph, to assess security or health risk, to examine asylum and visa applications, or for detection, recognition, or identification purposes at borders.
• Administration of justice and democratic processes — AI used to assist judicial authorities in researching and interpreting facts and law, and AI used to influence the outcome of elections or referenda or voting behavior.

Each of these categories includes carve-outs and conditions in the text of the Act itself, so falling within the general subject area of a category is a starting point for analysis, not a conclusion.

This table illustrates typical scenarios. It is not an exhaustive legal determination, and the actual classification of any specific system depends on its intended purpose and the conditions in Article 6.

How Article 6 Determines Whether an AI System Is High-Risk

Article 6 is the provision that actually does the classifying. Annex I and Annex III supply the subject-matter lists; Article 6 supplies the legal test.

• Article 6(1) covers the Annex I route: an AI system is high-risk if it's a product, or safety component of a product, covered by the EU harmonization legislation listed in Annex I, and that product must undergo third-party conformity assessment under that legislation.
• Article 6(2) covers the Annex III route: an AI system referred to in Annex III is high-risk, subject to the Article 6(3) exception below.
• Article 6(3) is a filter that narrows the Annex III route. An AI system that falls within an Annex III use case is not considered high-risk if it does not pose a significant risk of harm to the health, safety, or fundamental rights of natural persons — including if it does not materially influence the outcome of decision-making. The Act sets out specific conditions for when this applies, such as systems that perform a narrow procedural task, that improve the result of a previously completed human activity, that detect decision-making patterns without replacing human assessment, or that perform a preparatory task to an assessment.

Whether a specific AI system is high-risk therefore depends on a chain of questions: what does the system actually do, what is its stated intended purpose, does that purpose fall under Annex I or Annex III, and if Annex III, does the Article 6(3) filter apply. The presence of AI, machine learning, or automation alone does not answer any of these questions.

What Is the Article 6(3) Exception?

Article 6(3) exists because Annex III describes broad subject areas, and not every tool operating inside those areas meaningfully affects a person's rights or safety. In plain terms: an AI system can technically sit inside an Annex III category — employment, say — and still avoid high-risk classification if its actual function is narrow enough.

The Act gives four situations where this can apply:

• The AI system performs a narrow procedural task (for example, converting unstructured data into a structured format).
• The AI system improves the result of a previously completed human activity (for example, refining the formatting of a document a person already drafted).
• The AI system detects decision-making patterns or deviations from prior patterns and is not meant to replace or influence a human assessment without proper human review.
• The AI system performs a preparatory task to an assessment relevant to an Annex III use case.

Enterprises should treat this exception carefully, not liberally. Providers that place an AI system in an Annex III area and want to rely on Article 6(3) must document their assessment of why the exception applies, and that assessment can be reviewed by market surveillance authorities. Assuming an exception applies because a system feels "supportive" rather than "decisive" is not the same as demonstrating it meets the legal conditions. The intended purpose stated for the system — and how it functions in practice — is what actually controls the outcome, not the marketing description of the product.

When Does Profiling Make an AI System High-Risk?

Article 6(3) includes a hard boundary: the exception never applies if the AI system carries out profiling of natural persons. Profiling, in this context, means automated processing of personal data to evaluate aspects of a person — things like their performance at work, economic situation, health, preferences, reliability, behavior, location, or movements.

This matters because profiling is common in exactly the kinds of systems businesses are tempted to describe as "just supporting a human." An HR analytics tool that scores individual employees on performance indicators is profiling, even if a manager technically makes the final call. A credit tool that builds an individual risk profile from transaction history is profiling, even if it only produces a recommendation. Once profiling of individuals is present inside an Annex III use case, the Article 6(3) narrow-task exception is off the table and the system is treated as high-risk.

For compliance and legal teams, this is a useful triage question early in a system's design: does the AI build or use an individual-level profile of a specific person to inform a decision about them? For product leaders and engineers, it means the difference between an aggregate analytics dashboard (lower risk exposure) and an individual scoring or ranking tool (higher risk exposure) is not cosmetic — it can determine which compliance regime applies. For CISOs and DPOs, profiling activity inside an Annex III context is also a strong signal that the data governance and data protection impact assessment work needs to happen early, not as an afterthought before a conformity assessment deadline.

The 8 Annex III High-Risk AI Categories Explained

Biometrics. This category covers remote biometric identification systems (matching a person's biometric data against a reference database, typically without their active involvement), biometric categorization systems that infer sensitive attributes, and emotion recognition. Financial services firms using biometric authentication for account access are generally in a different position than a public venue deploying remote facial recognition across a crowd — the former is often closer to verification than identification, though the specific implementation still needs review.

Critical infrastructure. This covers AI functioning as a safety component in managing critical digital infrastructure, road traffic, or utility supply (water, gas, heating, electricity). A utility company using AI purely for demand forecasting sits differently than one using AI to directly control safety-relevant valve or grid operations.

Education and vocational training. Admissions decisions, assessment of learning outcomes, and proctoring for exam integrity fall here. Universities and education-technology vendors building adaptive learning tools need to separate tools that merely personalize content delivery from tools that determine access or pass/fail outcomes.

Employment, workers' management and access to self-employment. This is one of the most commonly triggered categories in practice. Recruitment screening, CV ranking, interview analysis tools, and performance-monitoring systems for existing employees all sit here. HR technology vendors and internal People Analytics functions are a natural focus for scrutiny, particularly where the tool influences hiring, promotion, or termination decisions for named individuals.

Access to essential private and public services and benefits. Creditworthiness assessment, insurance pricing and risk assessment for life and health insurance, and eligibility evaluation for public benefits fall here. Banks, insurers, and public-sector benefits agencies are the most exposed organizations in this category.

Law enforcement. Risk-assessment tools used by police, polygraph-type systems, and tools that assess the reliability of evidence are covered. This category carries some of the strictest conditions in the Act given the fundamental-rights stakes involved.

Migration, asylum and border control management. Risk and security assessment tools, polygraph-type systems, and tools assisting with the examination of asylum, visa, or residence permit applications fall here. Immigration technology vendors and government agencies deploying automated screening at borders are the primary audience.

Administration of justice and democratic processes. AI assisting judicial authorities in researching and interpreting facts and applying the law to a set of facts is covered, as is AI intended to influence election outcomes or voting behavior. Legal technology vendors building research-assistance tools for courts should pay close attention to how much interpretive weight their output carries.

Across all eight categories, the recurring theme is the same: the category defines the subject-matter area, but the actual classification still runs through Article 6, and different implementations within the same industry can land on different sides of the high-risk line.

Annex III Compliance Requirements

Once a system is confirmed high-risk under Annex III, a defined set of obligations applies, primarily to providers, with corresponding duties for deployers. In business terms:

• Risk management system — an ongoing, documented process to identify and mitigate risks throughout the system's lifecycle, not a one-time assessment.
• Data governance and data quality — training, validation, and testing data need to meet quality criteria and be examined for possible biases, particularly ones that could affect protected groups.
• Technical documentation — a detailed record of the system's design, capabilities, and limitations, maintained and updated, and available to authorities on request.
• Record-keeping and logging — automatic logging of events during operation, to support traceability and post-incident investigation.
• Transparency and instructions for use — deployers need enough information to use the system correctly, including its capabilities, limitations, and the level of human oversight it requires.
• Human oversight — the system must be designed so that a human can effectively understand, monitor, and where necessary override or stop it.
• Accuracy, robustness and cybersecurity — the system needs to perform reliably and resist attempts at manipulation, adversarial attack, or unauthorized access.
• Quality management system — providers need organizational processes to ensure ongoing compliance, not a single certification event.
• Conformity assessment and registration — before market placement, providers must complete the applicable conformity assessment procedure and register the system in the EU database.
• Post-market monitoring and incident reporting — providers must track how the system performs after deployment and report serious incidents to authorities.

None of these are single-step tasks that get "done" once. They're closer to ongoing operational disciplines — the kind that need real data infrastructure and governance behind them, not just a policy document.

An organization can be both, if it substantially modifies a third-party system or puts its own brand on it — a scenario that reclassifies a deployer into a provider for that system.

Annex III Compliance Checklist

A working checklist compliance teams can use as a starting inventory:

• Identify every AI system in use or under development across the organization.
• Determine the intended purpose of each system as it will actually be marketed or used.
• Check whether the system falls under the Annex I product-safety route.
• Check whether the system falls within one of the eight Annex III use-case categories.
• Assess the Article 6 conditions relevant to the applicable route.
• Evaluate whether the Article 6(3) narrow-task exception could apply, and document the reasoning.
• Assess whether the system profiles natural persons — if so, the Article 6(3) exception does not apply.
• Document the classification decision, including the reasoning and evidence relied on.
• Review data governance practices for training, validation, and input data.
• Assess the human oversight design and whether personnel are equipped to exercise it.
• Evaluate cybersecurity, robustness, and accuracy testing already in place.
• Review existing technical documentation against what Annex IV requires.
• Establish (or confirm) post-market monitoring and incident-reporting processes.
• Review the privacy and data protection implications, including any required data protection impact assessment.
• Identify sensitive or personal data flowing into the system and where it originates.
• Reassess third-party AI vendors used as part of the organization's own systems.

This list is a practical starting point for organizing internal work. It is not legal advice, and organizations with material exposure to Annex III categories should involve qualified legal counsel in the classification decision.

How to Determine Whether Your AI System Falls Under Annex III

A simplified way to work through the classification question:

1. Is the technology in question actually an "AI system" as defined under the Act?
2. What is its stated intended purpose, and how is it actually used in practice?
3. Does it fall under the Annex I product-safety route via Article 6(1)?
4. Does it fall within one of the eight Annex III categories via Article 6(2)?
5. If so, does the Article 6(3) narrow-task exception apply?
6. Does the system profile natural persons? If yes, the exception is unavailable.
7. What obligations follow from the resulting classification?
8. What documentation, governance, and oversight structures need to be built or strengthened as a result?

Annex III Classification Decision Tree

AI system

↓

Identify intended purpose

↓

Check Annex I (product-safety route)

↓ (if not covered)

Check Annex III (use-case categories)

↓

Assess Article 6 conditions

↓

Assess Article 6(3) narrow-task exception

↓

Check for profiling of natural persons

↓

Determine classification (high-risk / not high-risk)

↓

Map applicable compliance obligations

This decision tree is a simplified planning aid, not a substitute for a documented legal classification exercise.

Organizations should assess both routes, because some AI products can plausibly touch either depending on how they're embedded. A diagnostic AI tool built into a certified medical device, for example, is analyzed under the Annex I route, while a hospital's separate AI tool for triaging patient access to a service could be analyzed under Annex III.

Annex III vs Prohibited AI Under Article 5

Annex III and Article 5 are frequently confused, but they describe entirely different regulatory categories.

• Article 5 lists AI practices that are prohibited outright, regardless of use case — for example, social scoring by public authorities, certain forms of manipulative AI that exploit vulnerabilities, and (as of December 2, 2026) AI systems that generate non-consensual intimate imagery or child sexual abuse material. These have been enforceable since February 2, 2025, and cannot be brought into compliance through documentation or oversight; they are simply not permitted.
• Annex III lists use cases that may result in high-risk classification, which is a compliance regime, not a ban. High-risk systems can be lawfully placed on the market once they meet the applicable obligations.
• Other AI systems — like most general-purpose AI models, chatbots, and content-generation tools outside the prohibited categories — fall under separate transparency obligations (Article 50) or, in many cases, no specific AI Act risk tier at all beyond general provisions.

Getting this distinction right matters for internal risk conversations: a system that is prohibited cannot be "fixed" through compliance work, while a high-risk Annex III system can be lawfully deployed with the right controls in place.

Real-World Annex III Examples

AI recruitment screening that ranks or shortlists individual candidates is generally treated as high-risk within the employment category, since it directly affects access to a job.

• Employee performance evaluation tools that individually score or rank workers typically fall under the same category, particularly where they involve profiling.
• Creditworthiness assessment models used to approve or deny loans sit within the essential-services category — this applies broadly, though small-scale providers assessing creditworthiness for their own limited product offering have some narrower conditions under the Act.
• Biometric identification systems used for remote, non-consensual identification are generally high-risk; on-device biometric authentication for a single user's own device is treated differently.
• Educational admissions tools that materially influence acceptance decisions are typically high-risk; tools that only suggest supplementary reading materials generally are not.
• AI systems supporting access to essential public services, such as automated eligibility screening for benefits, generally fall within scope.
• Law enforcement risk-assessment tools used to predict offending or victimization are treated as high-risk given the fundamental-rights implications.
• Migration and asylum assessment tools used to evaluate applications or assess risk are similarly high-risk.
• Certain justice-related AI applications that assist judicial reasoning in ways that could influence outcomes are high-risk; purely reference-based legal search tools sit closer to the boundary and require individual assessment.

Each of these examples is "potentially high-risk," meaning the general pattern of use typically triggers Annex III scrutiny. None of them is "automatically high-risk" in every implementation — the specific intended purpose, the presence of profiling, and the Article 6(3) conditions still need to be assessed for each system individually.

What Enterprises Should Do Now

The December 2027 date is not a reason to slow down. It's additional time to do the classification and governance work properly rather than under deadline pressure. A practical sequence looks like this:

• Inventory every AI system in use, in procurement, or in development, including tools embedded in third-party software the organization didn't build itself.
• Classify each use case against the Annex I and Annex III routes, documenting the reasoning behind each determination.
• Map data flows feeding into and out of each AI system, particularly where personal or sensitive data is involved.
• Identify sensitive and personal data moving through AI workflows, including data that gets sent to third-party or general-purpose AI models as part of normal use.
• Document intended purpose clearly and consistently across product documentation, marketing materials, and technical specifications — inconsistent descriptions of the same system are a common source of classification disputes.
• Establish governance structures — a cross-functional group spanning legal, compliance, security, and product that owns AI classification and monitoring on an ongoing basis.
• Assess third-party AI vendors, since deploying someone else's high-risk system still carries deployer obligations.
• Evaluate privacy and security controls around how data reaches AI systems in the first place, not just how the AI system itself is documented.
• Establish human oversight mechanisms with named, trained personnel — not a theoretical policy that nobody actually exercises.
• Prepare technical documentation ahead of time so it isn't assembled retroactively under audit pressure.
• Monitor regulatory developments, since guidelines, delegated acts, and harmonized standards will continue to be published as the December 2027 date approaches.

That inventory step — mapping where sensitive data actually flows into AI systems — is where a lot of organizations discover their real exposure. It's rarely the flagship, purpose-built high-risk system that creates the biggest surprise. It's the everyday tools: a support team pasting customer records into a general-purpose chatbot, an HR team uploading resumes into a screening tool, a finance team feeding contract data into a document-analysis assistant. None of that shows up on a compliance spreadsheet until someone actually looks at the data flow.

What Does Annex III Mean for Enterprise AI Data?

Annex III compliance is fundamentally a use-case and governance question — but almost every use case on that list depends on sensitive data: employee records for HR and recruitment tools, financial history for credit scoring, health information for insurance risk assessment, biometric data for identification systems, case files for legal and law enforcement tools. Wherever an Annex III use case exists, sensitive personal or business data is usually sitting right behind it.

That creates a second, related problem alongside classification itself: reducing how much sensitive data actually reaches AI systems, and controlling what happens to it once it does. This is where data governance intersects with day-to-day AI usage across an organization — not just the purpose-built high-risk systems, but the broader pattern of employees pasting confidential documents, customer records, or proprietary information into AI tools as part of normal work.

This is the specific problem Questa AI is built around: reducing sensitive-data exposure in AI workflows before that data reaches a model. Questa AI's approach — including its Blackbox Anonymization — focuses on identifying and protecting sensitive business information, personal data, and confidential documents as they move into AI systems, rather than trying to retroactively audit what a model already processed.

It's worth being precise about what this does and doesn't solve. EU AI Act compliance for an Annex III high-risk system is broader than anonymization alone — it includes risk management, technical documentation, human oversight, and conformity assessment, none of which a data-protection layer replaces. Questa AI can help organizations reduce sensitive-data exposure within AI workflows as part of a broader AI governance and compliance strategy, not as a substitute for the full set of Annex III obligations. For organizations evaluating how to enterprise AI privacy and security, that distinction is worth keeping in view: classification and controls are a legal and operational exercise, and data protection technology is one component that supports it, alongside governance, documentation, and oversight.

Organizations that want to assess their AI data exposure as part of this broader preparation typically start by asking a narrower question than "are we AI Act compliant": where is sensitive data currently flowing into AI tools across the organization, and what controls exist around that flow today. That question tends to be answerable well before December 2027, and answering it early gives compliance, security, and product teams a much clearer picture of where the real Annex III exposure sits.

Frequently Asked Questions