The EU AI Act’s high-risk classification system is designed to protect fundamental rights, but the May 2026 draft guidelines reveal a critical enforcement blind spot: deployers lack clear, actionable criteria to assess third-party AI systems before deployment. While providers bear primary responsibility for conformity assessments, deployers—whether financial institutions, healthcare providers, or industrial operators—remain liable for systems they integrate into critical operations. With enforce
The EU AI Act’s high-risk classification system is designed to protect fundamental rights, but the May 2026 draft guidelines reveal a critical enforcement blind spot: deployers lack clear, actionable criteria to assess third-party AI systems before deployment. While providers bear primary responsibility for conformity assessments, deployers—whether financial institutions, healthcare providers, or industrial operators—remain liable for systems they integrate into critical operations. With enforcement of high-risk obligations beginning in August 2026, CTOs and compliance teams must address these gaps now or risk regulatory exposure, operational disruptions, and reputational damage.
---
The Deployer’s Dilemma: Why Draft Guidelines Don’t Solve the Real Problem
The AI Act’s risk-based framework places significant obligations on deployers of high-risk AI systems, including human oversight, accuracy monitoring, and transparency requirements (AI Act, Article 26). However, the May 2026 draft guidelines from the European Commission and the AI Office fail to provide deployers with concrete tools to evaluate whether a third-party AI system meets the high-risk criteria before procurement.
This gap creates a paradox: deployers are expected to ensure compliance but lack the authority to audit providers’ internal development processes. The guidelines clarify that deployers must verify a system’s intended use aligns with the provider’s conformity declaration (AI Act, Article 47(1)), but they do not specify how deployers should assess whether the system *should* have been classified as high-risk in the first place. For example, an AI system used for credit scoring may fall under Annex III’s high-risk categories, but if the provider misclassified it as limited-risk, the deployer inherits the liability without a clear mechanism to challenge or verify the classification.
The result? Deployers are forced to rely on providers’ self-certifications, which may not reflect the system’s actual risk profile in their specific operational context. This leaves organizations exposed to enforcement actions, particularly if regulators determine that a system’s use case—even if not originally classified as high-risk—should have triggered stricter obligations.
---
What the May 2026 Guidelines Actually Say (and Don’t Say) About Deployer Responsibility
The draft guidelines expand on the AI Act’s provisions but stop short of addressing deployers’ most pressing operational challenges. Key takeaways include:
**1. Deployers Must Verify—but Not Validate—Providers’ Classifications**
The guidelines reiterate that deployers must ensure a system’s intended use matches the provider’s conformity declaration (AI Act, Article 26(1)). However, they do not require deployers to independently validate whether the system meets the high-risk criteria under Annex III. This creates a compliance gray zone: if a provider incorrectly classifies a system as non-high-risk, the deployer is still responsible for its use in a high-risk context.
For instance, an AI system used for employee performance evaluation may not be classified as high-risk by the provider, but if the deployer uses it to make promotion decisions, it could fall under Annex III’s employment-related high-risk category. The guidelines do not provide a framework for deployers to assess such edge cases.
**2. No Standardized Methodology for Pre-Deployment Assessments**
The guidelines suggest deployers conduct "due diligence" on providers but do not define what this entails. Should deployers request access to the provider’s technical documentation (AI Act, Article 11)? Demand evidence of conformity assessments (AI Act, Article 43)? The lack of specificity leaves deployers to interpret these requirements independently, increasing the risk of inconsistent or inadequate assessments.
**3. Context Matters—but How?**
The AI Act acknowledges that a system’s risk level depends on its "context and purpose of use" (AI Act, Recital 27). The guidelines expand on this by stating that deployers must consider whether their use case alters the system’s risk profile. However, they do not provide a methodology for conducting this contextual analysis. For example, an AI system used for predictive maintenance in a manufacturing plant may not be high-risk in isolation, but if it controls safety-critical machinery, its risk level could escalate. Deployers lack clear criteria to make these determinations.
**4. The Burden of Monitoring Post-Deployment**
Deployers are required to monitor AI systems for risks throughout their lifecycle (AI Act, Article 26(4)). The guidelines emphasize that this includes tracking performance drift, bias, and accuracy degradation. However, they do not address how deployers should implement these monitoring obligations when they lack access to the system’s underlying training data or model architecture. This is particularly problematic for black-box AI systems, where deployers cannot independently verify performance metrics.
---
The Liability Chain: How Deployers Get Caught Between Providers and Regulators
The AI Act’s liability framework creates a complex chain of responsibility that leaves deployers vulnerable to enforcement actions, even when they are not the primary developers of the AI system. Understanding this chain is critical for CTOs and compliance teams to mitigate risks.
**1. Providers: The First Line of Defense (and the First Point of Failure)**
Providers are responsible for classifying their AI systems, conducting conformity assessments, and affixing the CE marking (AI Act, Article 43). However, the AI Act does not mandate third-party audits for all high-risk systems, meaning providers can self-certify compliance. If a provider misclassifies a system or fails to meet technical requirements, the deployer inherits the liability for any resulting harms or regulatory violations.
**2. Deployers: The Last Line of Accountability**
Deployers are liable for:
- Using a high-risk AI system in a manner inconsistent with its intended purpose (AI Act, Article 26(1)).
- Failing to implement human oversight or accuracy monitoring (AI Act, Article 26(4)).
- Not reporting serious incidents to the provider and relevant authorities (AI Act, Article 73).
Critically, deployers cannot shift blame to providers if they fail to conduct adequate due diligence before deployment. For example, if a deployer integrates an AI system into a safety-critical process without verifying its conformity declaration, they may face fines of up to €15 million or 3% of global turnover (AI Act, Article 99), even if the provider’s documentation was misleading.
**3. Regulators: Enforcement with Limited Guidance**
National supervisory authorities will enforce the AI Act, but the May 2026 guidelines do not provide them with additional tools to assess deployers’ compliance. This means regulators may interpret the rules differently across member states, creating inconsistency in enforcement. Deployers operating in multiple EU countries could face conflicting expectations, further complicating compliance efforts.
**4. The "Chain of Custody" Problem**
The AI Act introduces a "chain of custody" requirement for high-risk systems, where deployers must ensure the system’s integrity from procurement to decommissioning (AI Act, Article 16). However, the guidelines do not specify how deployers should document this chain, particularly when integrating AI systems from multiple providers. Without standardized processes, deployers risk gaps in their compliance documentation, which could be exploited during regulatory audits.
---
Practical Gaps: Classification Criteria That Don’t Translate to Procurement
The AI Act’s high-risk classification criteria are theoretically clear but practically difficult to apply during procurement. The May 2026 guidelines do not bridge this gap, leaving deployers to navigate ambiguous requirements without operational support.
**1. Annex III’s Broad and Overlapping Categories**
Annex III lists eight high-risk categories, including:
- Biometric identification and categorization of natural persons.
- Management and operation of critical infrastructure.
- Education and vocational training.
- Employment, workers management, and access to self-employment.
- Access to and enjoyment of essential private services and public services and benefits.
- Law enforcement.
- Migration, asylum, and border control management.
- Administration of justice and democratic processes.
While these categories are broad, the guidelines do not provide examples of how to apply them in specific industries. For instance:
- A financial institution using AI for fraud detection may assume the system falls under "access to essential private services," but the guidelines do not confirm this.
- A healthcare provider using AI for diagnostic support may question whether it qualifies as "critical infrastructure," but the guidelines offer no clarity.
**2. The "Significant Risk" Threshold**
The AI Act states that a system is high-risk if it poses a "significant risk of harm to the health, safety, or fundamental rights of natural persons" (AI Act, Article 6(1)). The guidelines expand on this by introducing a non-exhaustive list of factors to consider, such as:
- The severity of potential harm.
- The likelihood of harm occurring.
- The number of affected individuals.
- The irreversibility of harm.
However, these factors are subjective and difficult to quantify during procurement. Deployers lack standardized risk assessment methodologies to evaluate these criteria, leading to inconsistent interpretations. For example, an AI system used for resume screening may pose a low risk of harm to an individual but a high risk of systemic bias if deployed at scale. The guidelines do not provide a framework for assessing such trade-offs.
**3. The "Intended Purpose" vs. "Actual Use" Dilemma**
The AI Act defines high-risk systems based on their "intended purpose" (AI Act, Article 6(1)), but deployers must also consider how the system will be used in practice. The guidelines acknowledge this distinction but do not provide a process for reconciling potential mismatches. For example:
- A provider may classify an AI system as non-high-risk for general customer service use, but the deployer may use it to make credit decisions, which could trigger high-risk obligations.
- A deployer may modify an AI system’s inputs or outputs, altering its risk profile without the provider’s knowledge.
Without clear guidance, deployers risk non-compliance if their actual use of the system diverges from the provider’s intended purpose.
**4. The Lack of Standardized Documentation Requirements**
The AI Act requires providers to supply technical documentation to deployers (AI Act, Article 11), but the guidelines do not specify what this documentation should include. Deployers are left to determine whether the provided materials are sufficient to assess the system’s risk level. Common gaps include:
- Incomplete descriptions of the system’s training data.
- Lack of transparency about the model