When is an AI system high-risk?
2 The AI Act and the legal context of Article 6(3)
s. 7–13pp. 7–13 · PDF 11–17
2.1 The AI Act’s risk-based regulatory system#s. 7
The AI Act establishes a horizontal regulatory framework for AI systems in the EU, applicable across sectors and (almost) irrespective of the technology’s underlying architecture. The Act’s structural lineage is the EU’s New Legislative Framework for product safety (NLF). Its central regulatory mechanism is a purportedly risk-based approach under which the intensity of legal obligations imposed on providers and deployers of AI systems is proportional to the level of risk that those systems pose to fundamental rights, health, and safety. This approach reflects both the principle of proportionality enshrined in Article 5(4) of the Treaty on European Union (TEU) and the harmonisation objective of the Act’s legal basis in TFEU Article 114.
The Act organises AI systems into five semi-tiered (but not all mutually exclusive) categories of risk and regulatory obligations. Article 5 prohibits unacceptable-risk practices. Article 6 defines high-risk systems, the category carrying the most extensive provider and deployer obligations. Article 50 assigns transparency obligations to systems with deception risk. In a break with the otherwise activity centred risk-based approach, Articles 53 and 55 introduce technology-centred obligations to providers of general-purpose AI models. For systems that fall outside the scope of any of the above categories, the Act introduces no new obligations beyond general Article 4 AI literacy, though Article 95 encourages voluntary codes of conduct.
2.2 High-risk AI systems under the AI Act#s. 7
Article 6 establishes two distinct pathways through which an AI system may be classified as high-risk. The first pathway, set out in Article 6(1), concerns AI systems that are intended to be used as safety components of products, or that are themselves products, covered by the EU harmonisation legislation listed in Annex I. This pathway integrates the AI Act into the existing EU product safety legislation by ensuring that AI systems embedded in regulated products such as machinery, medical devices, and motor vehicles are subject to the high-risk requirements where the product itself undergoes third-party assessment.
The second pathway, set out in Article 6(2), is the one of primary relevance for this thesis. It provides that AI systems “referred to in Annex III shall be considered to be high-risk.” Annex III enumerates broad areas of use in which AI systems are presumed to present significant risks to fundamental rights, health, or safety. The Annex III classification follows an activity-based logic. Rather than prescribing requirements based on the technical characteristics or capabilities of the AI system itself, the Act identifies areas of use in which AI systems are presumed to pose significant risks by virtue of the context in which they operate. AI systems deployed in domains where fundamental rights are directly at stake – such as recruitment, credit scoring, criminal justice, or migration control – warrant heightened scrutiny regardless of their underlying technical design or surrounding processes. As Recital (52) notes, the Annex III enumeration is placed in an annex rather than in the operative text to enable future amendment via delegated acts as the risk landscape evolves.
Classification as high-risk triggers a comprehensive set of requirements and obligations set out in Articles 8–49. The aggregate compliance burden associated with these obligations makes the boundary between high-risk and not-highrisk classification a matter of considerable economic and strategic significance for providers and deployers.
This activity-based classification approach has significant strengths. It provides a degree of technology-neutrality that allows the framework to adapt to technological change; it aligns with the EU’s established tradition of sector-specific safety regulation; and it allows the same underlying technology to be subject to different regulatory treatment depending on the context of its deployment. An AI model used for entertainment recommendations may face no mandatory obligations, while the same model repurposed for credit scoring falls within Annex III’s high-risk category.
There is, however, a risk of over-inclusion. The Annex III categories are drawn broadly enough to capture AI systems that, while deployed within a high-risk use context, perform functions that do not, in and of themselves, pose a significant risk of harm – an AI system performing automated document sorting in a recruitment workflow falls within Annex III area 4 (employment), but presents a fundamentally different risk profile from one that autonomously screens and ranks candidates. The risk-tier architecture operates primarily as a tool of legislative proportionality rather than as a framework for individualised, empirical risk management.
Article 6(3) addresses this structural over-inclusion. Its legislative history shows an attempt to add a horizontal corrective to Annex III, so that systems unlikely to cause serious rights or safety risks are not captured merely because they operate in a sensitive domain. In a framework that classifies risk primarily by use-area rather than by individualised empirical assessment, Article 6(3) is the principal mechanism for restoring proportionality at the level of the specific AI system. It gives providers a limited route to rebut the Annex III high-risk presumption where the system’s actual task is too remote from the protected interests to justify high-risk treatment.
2.3 The function of Article 6(3) in the AI Act#s. 9
2.3.1 Article 6(3) as a proportionality “safety valve”#s. 9
Article 6(3) establishes that an AI system falling within one of the Annex III areas “shall not be considered to be high-risk where it does not pose a significant risk of harm to the health, safety or fundamental rights of natural persons, including by not materially influencing the outcome of decision making”.
The provision creates a mechanism through which AI systems that fall within the broad sweep of Annex III can, under certain conditions, be exempted from the full range of high-risk obligations. In this sense, Article 6(3) functions as a proportionality “safety valve” that relieves the regulatory pressure on systems that, despite operating in a high-risk domain, do not themselves present a significant risk of harm. Without a corrective mechanism, the framework would impose the full weight of high-risk compliance on AI systems performing genuinely low-risk functions, in tension with the proportionality principle articulated in Recital (26) and anchored in TEU Article 5(4). Recital (53) elaborates on this rationale, noting that “there may be specific cases in which AI systems referred to in [Annex III] do not lead to a significant risk of harm to the legal interests protected under those areas because they do not materially influence the decision-making or do not harm those interests substantially”.
2.3.2 The relationship between Article 6(2) and Article 6(3)#s. 10
The relationship between Article 6(2) and 6(3) is best understood as a two-step classification process. First Article 6(2) establishes a rebuttable presumption from the legislator: all AI systems falling within the Annex III categories are presumed to be high-risk. Next, Article 6(3) provides the mechanism through which this presumption may be rebutted by the provider who would bear the burden of compliance, subject to the satisfaction of specific conditions, through an individual case-by-case risk assessment. The starting point is one of classification as high-risk; the Article 6(3) carve-out operates as an exception to this default, with the burden of proof placed with the provider. Since the risk designation is tied to the provider-supplied intended purpose, a deployer cannot use Article 6(3) to escape Article 26 and 27 deployer high risk obligations, even if the deployer’s specific intended use of the system is low risk.
2.3.3 The Article 6(3) conditions are centred around “tasks”#s. 10
The four conditions of Article 6(3) do not refer to the AI system as such, but to the task it is intended to perform. Condition (a) speaks of a “narrow procedural task”, condition (d) of a “preparatory task to an assessment.” An AI system may have broad technical capabilities, for example a general large language model (LLM)-based AI assistant may be capable of performing tasks ranging from software development to document summarisation to risk assessment, but the classification under Article 6(3) depends not on its general capabilities but on the particular task for which it is “intended.”
As already mentioned, the intention referenced here is that of the provider, not the deployer. Article 3(12) of the AI Act defines “intended purpose” as “the use for which an AI system is intended by the provider, including the specific context and conditions of use, as specified in the information supplied by the provider in the instructions for use, promotional or sales materials and statements, as well as in the technical documentation.” The definition anchors the assessment to the provider’s declared purpose, not to the system’s inherent technical capacity. The intention must be documented and communicated, and deployers ignoring the documented “intended purpose” risk themselves being designated a provider of high-risk AI through the mechanism of Article 25(1)(c).
The task-based approach also has implications for AI systems that perform multiple functions. Where an AI system is configured to perform both a narrow procedural task (such as sorting incoming applications) and a substantive function (such as scoring applicants), the carve-out would apply only if the system, as deployed for its intended purpose, satisfies one of the Article 6(3) conditions. A system whose intended purpose encompasses both procedural and substantive functions cannot claim the benefit of the carve-out for the procedural component alone, as the classification assessment applies to the system as a whole.
2.3.4 The relationship between Article 6(3) and Article 14#s. 11
If a system is classified as high-risk, Article 14 requires the provider to design it in such a way that it can be effectively overseen by natural persons, including by enabling the user to correctly interpret the system’s output and to decide not to use it or to override it. Where an AI system is exempted under Article 6(3), these design requirements do not apply.
Recent literature has identified a consistent pattern in which formal human involvement in AI-assisted processes fails to translate into meaningful control, due to automation bias, limited competence or authority, and organisational pressure toward deference. The Article 14 safeguards, even if imperfect, represent a risk-mitigation minimum for Annex III systems; their removal through the carve-outs is important context for interpreting Article 6(3).
2.3.5 The task of assessing and documenting whether an AI system qualifies for the Article 6(3) carve-out rests with the provider of the system#s. 11
Article 6(4) requires the provider to document this assessment before placing the system on the market or putting it into service, and to make the documentation available to national competent authorities upon request. In addition, Article 49(2) requires providers who have determined their Annex III system not to be high-risk to register the system in the EU database established under the Act, thereby ensuring that authorities and the public have visibility of such self-assessed “low-risk-use-in-a-high-risk-sector” systems. The national-level post-market enforcement counterpart to this self-assessment is set out in Article 80. The evaluation under Article 80 may itself be escalated to the Commission through the Union Safeguard Procedure of Article 81 to ensure consistent application across the EU.
The self-assessment model with a registration safeguard reflects a regulatory design choice that seeks to balance administrative efficiency against the need for transparency and accountability. Risk self-assessments have been the subject of criticism in the literature, with the prediction that the AI Act will face the same challenges as the EU product-safety regime from which it draws inspiration, since self-assessment frameworks produce higher risk of harm to fundamental rights and safety than those involving third-party evaluation.
These concerns were sharpened by the Commission’s Digital Omnibus proposal of 19 November 2025, which proposed to eliminate the Article 49(2) registration obligation for self-assessed Annex III systems while retaining the documentation duty. The EDPB and EDPS criticised the proposal as one that “would significantly decrease the accountability” and create incentives for providers to claim Article 6(3) exceptions without critical analysis. The Council subsequently agreed on an amended omnibus proposal with the registration requirement reinstated in a simpler form. The European Parliament adopted its plenary position in March 2026 supporting a simplified registration obligation. Provisional agreement was reached on 7 May 2026, with formal endorsement and legal-linguistic revision pending at the time of writing.
For risk-seeking providers and deployers, the combination of vague Article 6(3) conditions, risk self-assessment, and (potentially) mostly ad-hoc transparency obligations create an incentive to characterise AI system functions and deployments in terms that bring them within the carve-outs, thereby avoiding the substantial compliance burden of high-risk classification. Risk-averse actors may avoid the carve-out altogether and accept unnecessary compliance costs. Both reactions weaken the proportionality function of Article 6(3). The asymmetry can only be reduced through operational criteria that are concrete enough to guide self-assessment and review.
2.3.6 The provider/deployer divergence under Article 6(3)#s. 13
A provider designs and declares an AI system’s intended purpose, and the question of whether that purpose qualifies as “narrow procedural” or “preparatory” is constrained to the deployment scenario(s) described by the provider. As indicated above, this can produce a mismatch between the provider’s declared classification and the deployer’s actual use. Where an AI system is declared by its provider to be intended for high-risk purposes, a particular deployer may use it only for a narrower procedural or preparatory function that would, in isolation, satisfy Article 6(3). The Act does not allow the deployer to reclassify the system on this basis to escape the deployer’s high-risk obligations of Articles 26 and 27.
The opposite mismatch, a system declared low-risk by the provider but deployed for a high-risk task, is captured by Article 25(1)(c), which loops the deployer into provider obligations. There is, however, a clear potential for responsibility pulverisation through the use of “constructive ambiguity” in the documented deployment requirements, where an ambiguously worded deployment requirement is initially interpreted strictly to support not-highrisk self-assessment by the provider, and later interpreted permissively by the deployer to justify minimising deployment costs. This has implications for the operative criteria developed in Chapter 4: criteria that turn on the conditions of deployment — transparency, verifiability, and resilience to automation bias — require the provider’s declared intended purpose to set clear demands on the deployment environment. The de lege ferenda implications of this constraint are taken up in Section 5.3.