AI Act High-Risk Classification: Why Deployers Face Urgent Compliance Gaps Before 2026

The EU AI Act’s high-risk classification framework arrives in August 2026, but deployers—entities using AI systems in critical sectors—are already exposed to enforcement risk. A €200 million fine against Temu in July 2024 for non-compliance with DSA transparency rules signals a broader regulatory shift: deployers, not just providers, are now accountable for third-party AI systems. With draft guidelines on high-risk classification published in May 2026, the ambiguity around deployer obligations is creating urgent operational gaps. This article examines the classification blind spots, audit challenges, and pre-deployment verification steps CTOs and compliance teams must take before the final guidelines lock in enforcement expectations.

---

The Temu Fine and the Deployer Accountability Shift

The €200 million fine imposed on Temu by the French data protection authority (CNIL) in July 2024 was framed as a DSA violation, but its implications for AI deployers are far-reaching. The case centered on Temu’s failure to provide transparent information about its recommendation algorithms, which regulators argued could manipulate user behavior. While the DSA targets digital platforms, the underlying principle—deployer accountability for third-party systems—mirrors the AI Act’s approach to high-risk AI.

Under the AI Act, deployers are not passive users. AI Act Article 26(1) explicitly requires deployers to "take appropriate technical and organisational measures" to ensure compliance when using high-risk AI systems. This includes verifying that the system meets the requirements of Title III, Chapter 2, such as risk management, data governance, and transparency. The Temu case demonstrates that regulators will not wait for the AI Act’s full applicability to enforce accountability. Deployers must proactively audit AI systems, even if they did not develop them, or risk facing similar penalties—up to €15 million or 3% of global turnover for high-risk violations.

---

What the Draft Guidelines Actually Say (and Don’t Say) About Deployer Obligations

The May 2026 draft guidelines on high-risk AI classification, published by the European Commission, provide a framework for determining whether an AI system falls under Annex III of the AI Act. However, the guidelines leave critical gaps for deployers:

What the Guidelines Clarify

1. 1Annex III Scope: The guidelines confirm that AI systems listed in Annex III (e.g., biometric identification, critical infrastructure management, employment, education, law enforcement) are *presumed* high-risk unless they perform "narrow procedural tasks" or improve prior human decisions without materially altering outcomes. Deployers must document this assessment.
2. 2Intended Purpose: The guidelines emphasize that the *intended purpose* of the AI system, as defined by the provider, determines its classification. Deployers cannot rely solely on the provider’s marketing claims; they must verify the system’s actual functionality against Annex III criteria.
3. 3Significant Risk Exemption: AI systems that pose a "significant risk of harm to health, safety, or fundamental rights" may still be classified as high-risk even if they are not listed in Annex III. Deployers must conduct their own risk assessments to identify such cases.

What the Guidelines *Don’t* Clarify

1. 1Third-Party Verification: The guidelines do not specify how deployers should verify the compliance of AI systems they did not build. Should they rely on provider documentation, third-party audits, or in-house testing? The lack of guidance creates operational uncertainty.
2. 2Documentation Burden: While deployers must document their classification decisions, the guidelines do not define the required level of detail. Is a high-level summary sufficient, or must deployers retain technical evidence (e.g., model cards, data sheets)?
3. 3Liability for Misclassification: The guidelines do not address whether deployers can be held liable if they misclassify a system as low-risk based on incomplete or inaccurate provider information. This ambiguity leaves deployers exposed to enforcement actions.

The draft guidelines are a starting point, but they do not resolve the core challenge: deployers lack clear, actionable criteria for auditing third-party AI systems before deployment.

---

The Classification Ambiguity Problem: Where Deployers Get Stuck

The AI Act’s high-risk classification framework is intentionally broad to capture evolving AI applications, but this flexibility creates ambiguity for deployers. Three key areas of uncertainty stand out:

1. The "Material Influence" Test

AI Act Article 6(3) states that an AI system is high-risk if it is "intended to be used for the *material influence* of decisions" in areas like employment, credit scoring, or law enforcement. However, the term "material influence" is not defined. For example:

• Does an AI-powered resume screening tool that ranks candidates but does not make final hiring decisions meet this threshold?
• Does a chatbot that provides financial advice but defers to human agents for final decisions qualify?

Deployers must interpret "material influence" in the context of their specific use case, but without regulatory examples, this is a high-risk judgment call.

2. The "Narrow Procedural Task" Exemption

Annex III exempts AI systems that perform "narrow procedural tasks" from high-risk classification. However, the guidelines do not define what constitutes a "narrow" task. For instance:

• Is an AI system that automates invoice processing for a financial institution a narrow procedural task, or does it fall under Annex III’s financial services category?
• Is a customer service chatbot that routes inquiries to human agents exempt, or does it qualify as a high-risk system if it handles sensitive data?

Deployers must document their reasoning for applying this exemption, but the lack of clarity increases the risk of misclassification.

3. The "Significant Risk" Catch-All

Even if an AI system is not listed in Annex III, deployers must assess whether it poses a "significant risk of harm" under AI Act Article 6(1). This catch-all provision requires deployers to evaluate:

• The severity of potential harm (e.g., physical injury, discrimination, financial loss).
• The likelihood of harm occurring.
• The context of use (e.g., healthcare vs. marketing).

Without standardized risk assessment methodologies, deployers are left to develop their own frameworks, which may not align with regulatory expectations.

---

Practical Audit Gaps: How to Classify AI Systems You Don’t Build

Deployers face a fundamental challenge: how to classify and verify AI systems they did not develop. The draft guidelines provide no step-by-step process, leaving deployers to navigate four key audit gaps:

1. Lack of Transparency from Providers

Many AI providers treat their models as proprietary, limiting access to technical documentation. Deployers often receive only high-level marketing materials, which are insufficient for compliance. For example:

• A provider may claim their AI system is "low-risk" for resume screening, but without access to training data, bias mitigation measures, or model architecture, deployers cannot verify this claim.
• Some providers offer "compliance certifications" from third-party auditors, but these may not cover the specific use case or regulatory requirements of the deployer.

Solution: Deployers must demand granular documentation from providers, including:

• Model cards (e.g., performance metrics, limitations, bias assessments).
• Data sheets (e.g., training data sources, preprocessing steps).
• Risk management reports (e.g., failure modes, mitigation strategies).
• Compliance attestations aligned with AI Act Article 10-15 (e.g., data governance, transparency, human oversight).

2. Inconsistent Risk Assessment Frameworks

Deployers lack standardized tools to assess whether an AI system poses a "significant risk of harm." Common pitfalls include:

• Over-reliance on provider risk assessments, which may not account for the deployer’s specific use case.
• Underestimating indirect risks, such as reputational harm or regulatory backlash.
• Failing to consider the cumulative impact of multiple AI systems (e.g., a hiring tool combined with a performance monitoring system).

Solution: Deployers should adopt a structured risk assessment framework, such as:

• ENISA’s AI Risk Management Guidelines: Provides a methodology for identifying and mitigating AI risks.
• NIST AI Risk Management Framework: Offers a voluntary framework for mapping, measuring, and managing AI risks.
• ISO/IEC 23894: A standard for AI risk management that aligns with the AI Act’s requirements.

3. Dynamic AI Systems and Concept Drift

AI systems are not static; they evolve over time due to retraining, updates, or changes in input data. This "concept drift" can alter the system’s risk profile. For example:

• A credit scoring model trained on pre-pandemic data may become biased as economic conditions change.
• A chatbot fine-tuned on new customer interactions may start generating harmful or misleading outputs.

Solution: Deployers must implement continuous monitoring to detect concept drift and reassess risk classification. This includes:

• Regular performance audits (e.g., bias testing, accuracy metrics).
• Automated alerts for deviations in model behavior.
• Periodic reviews of training data and retraining processes.

4. Cross-Border and Cross-Sector Variability

The AI Act’s high-risk classification may vary depending on the deployer’s sector or jurisdiction. For example:

• An AI system used for employee monitoring may be high-risk in the EU but not in other regions.
• A healthcare AI system may be subject to additional sectoral regulations (e.g., GDPR, MDR).

Solution: Deployers must align their classification process with:

• Sector-specific guidelines (e.g., EBA guidelines for financial services, EDPB guidelines for biometric data).
• National interpretations of the AI Act (e.g., Germany’s AI Act implementation law, France’s CNIL guidance).
• International standards (e.g., ISO/IEC 42001 for AI management systems).

---

Building a Pre-Deployment Verification Checklist for CTOs

To close the compliance gap, CTOs and compliance teams should develop a pre-deployment verification checklist tailored to the AI Act’s high-risk classification requirements. Below is a practical framework:

1. Intended Purpose Verification

-