GovCompass

High-risk AI or not? classification guide for deployers

By GovCompass.ai· Last updated August 2026· Aligned with the consolidated EU AI Act, including the 2026 Omnibus amendments.

Whether an AI system is high-risk depends on Art. 6: it is high-risk if it is a safety component under Annex I or falls within an Annex III use case (such as employment, credit, or essential services). The Art. 6.3 exception can apply where the system performs only a narrow, non-decisive task.

Updated: June 2026

Introduction: why classification matters

The EU AI ActEU AI ActRegulation (EU) 2024/1689, the European Union's law on artificial intelligence. It takes a risk-based approach: prohibited practices, requirements for high-risk AI systems, transparency obligations for specific uses, and a separate regime for general-purpose AI models. Obligations are divided between providers and deployers. See general-purpose AI, conformity assessment.Open full entry → creates fundamentally different compliance obligations depending on riskriskIn the EU AI Act's terms, the combination of the likelihood that a harm occurs and the severity of it if it does. The link between a principle (via the harm that would breach it) and a control (the measure that reduces it). Naming the harm and assessing its risk is required by Art. 9 before any mitigation measure is chosen. See harm, control, residual risk.Open full entry → classification. High-risk AI triggers the full Art. 26 deployerdeployerAn organization using an AI system under its own authority in its activities. It carries the operator duties: use per instructions, oversight, input relevance, monitoring, notices.Open full entry → obligations: usage instructions compliance, human oversighthuman oversightDesigned-in human ability to monitor, intervene in, override or shut down an AI system. It is meaningful only when the human has authority, information and time to act. One of the seven pillars of responsible AI, and under the EU AI Act a requirement for high-risk AI systems: Article 14 requires that those systems are designed so natural persons can effectively oversee them. Oversight that exists on paper but amounts to confirming in practice does not meet that bar. See override rate, automation bias, high-risk AI system, fairness, safety and reliability, privacy, security and robustness, transparency and explainability, accountability, responsible AI. In the IAPP AIGP body of knowledge, this principle appears as human-centricity, with human oversight as one of its elements.Open full entry →, data quality controlscontrolThe concrete, testable measure that reduces a specific risk, and through that risk protects the principle behind it. Also called a risk management measure, risk response, or risk treatment. Always traceable to the risk it addresses: under EU AI Act Art. 9 every control must map back to a specific risk, and controls recorded separately from their risks is a recognized compliance failure. It works in one of three types: preventive, detective, or corrective. See risk, control types, evidence.Open full entry →, post-market monitoringpost-market monitoringProvider-side duty to systematically collect and act on experience from systems in use, the product-regulation half of continuous monitoring.Open full entry →, log retention, individual transparencytransparencyOpenness about the fact that AI is used and how it operates in general: disclosures, documentation, notices. Pairs with explainability, which addresses individual outcomes.Open full entry →, and in some cases DPIADPIAData Protection Impact Assessment: required before likely-high-risk processing (systematic profiling with significant effects, large-scale special categories, public monitoring); AI development triggers it constantly.Open full entry → and FRIAFRIAFundamental Rights Impact Assessment: required of public bodies and certain private deployers before using some high-risk AI systems under the EU AI Act.Open full entry →. Non-high-risk AI, depending on type, may require only transparency disclosures or nothing at all.

The classification decision is therefore one of the most consequential compliance choices an organization makes. This guide walks through the classification methodology step by step.

Step 1: is the system an "AI system" under the EU AI Act?

Art. 3.1 defines an AI systemAI systemA machine-based system that, for explicit or implicit objectives, infers from input how to generate outputs (predictions, content, recommendations or decisions) that can influence physical or virtual environments. The OECD-style definition followed by the EU AI Act.Open full entry → as "a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments."

Key exclusions from the AI definition:

  • Pure rule-based systems without any machine learningmachine learningThe dominant approach to AI: algorithms that improve at a task by learning patterns from data rather than following rules a human wrote.Open full entry → or inferenceinferenceThe stage where a trained model produces outputs on new inputs, as opposed to the training stage where it learns its parameters.Open full entry → component
  • Statistical tools that apply fixed mathematical formulas without inference
  • Traditional software automation that follows explicit programming

If your system is not an AI system under Art. 3.1, the EU AI Act does not apply.

Step 2: is the system prohibited under Art. 5?

Before assessing risk class, check against the eight prohibitions of Art. 5. If the system constitutes a prohibited AI practice, no risk classification exercise is needed, it must not be used.

Step 3: does the system fall under Annex i (safety-critical products)?

Check whether the AI system is a safety component of a product regulated by EU harmonization legislation listed in Annex I (machinery, medical devices, vehicles, etc.). If yes, the system is high-risk under Art. 6.1.

Step 4: does the system fall under Annex III?

Check the system against all eight categories of Annex IIIAnnex IIIThe EU AI Act's list of high-risk use-case areas: biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice.Open full entry →. The most commonly relevant for Dutch private-sector deployers:

Annex III categoryExamples
Point 1: Biometric IDRemote biometric identification (note: one-to-one verification for access control is outside Annex III 1(a), a standing exception, not an Omnibus change)
Point 2: Critical infrastructureAI managing power grid, water systems, banking systems
Point 3: EducationAI affecting admission decisions, exam proctoring with significant impact
Point 4: Employment/HRCV screening, performance evaluation, promotion decisions
Point 5: Essential servicesCredit scoring, insurance underwriting, benefit eligibility
Point 8: Democratic processesVoter registration, election integrity tools

Step 5: does the Art. 6.3 exception apply?

Even if the system falls within Annex III, Art. 6(3) sets four exhaustive grounds on which it is not high-risk: (a) it performs a narrow procedural task; (b) it improves the result of a previously completed human activity; (c) it detects decision patterns or deviations from prior patterns without replacing or influencing the human assessment without proper review; or (d) it performs a preparatory task. As an override, any system that performs profilingprofilingAutomated processing of personal data to evaluate or predict aspects of a person, such as performance, behavior or location, as defined in the GDPR.Open full entry → of natural personsnatural personA living human individual, as distinct from a legal person such as a company; the holder of data-protection and AI-Act rights.Open full entry → is always high-risk, profiling of any kind, not only "sensitive" profiling. The Art. 6(3) assessment is the providerproviderThe actor who develops an AI system (or has it developed) and places it on the market or into service under its own name. It carries manufacturer-style duties: design controls, documentation, conformity.Open full entry →'s, and must be documented and registered.

Request the provider's Art. 6.3 documentation if they claim this exception. Verify it against your actual use case.

Step 6: is your use case adding risk?

Classification depends on how you use the system, not just what the system is capable of. A general-purpose language model used as the sole basis for credit decisions is high-risk in that deployment, even if the model itself is not specifically classified as a credit scoring system. Assess your specific use case against the Annex III categories, not just the system in the abstract.

Borderline cases

  • HR scheduling software with AI: Scheduling AI that generates rosters a planner can freely modify, probably not high-risk. AI that determines working hours or contract terms, potentially high-risk under Annex III, point 4.
  • Customer service chatbots: Limited risk AI (Art. 50 transparency). If the chatbot makes decisions about credit limits or contract changes, high-risk.
  • Marketing recommendation engines: Not high-risk unless targeting vulnerable groups with exploitative techniques (Art. 5.1.b territory).

Compliance checklist

  1. Have you confirmed each AI system meets the Art. 3.1 definition?
  2. Have you assessed each system against Art. 5 before considering risk class?
  3. Have you checked against both Annex I and all eight Annex III categories?
  4. For potential Art. 6.3 systems: have you obtained the provider's written assessment?
  5. Have you assessed your specific use case (not just the abstract system) against the classification criteria?
  6. Is the classification rationale documented for each AI system?
  7. Is there a re-classification process for when use cases change?

Misclassification is also on the supervisor's radar. In its March 2026 Report AI & Algorithms Netherlands, the Dutch Data Protection Authority warns that organizations try to escape the AI Act by registering AI systems as ordinary algorithmsalgorithmThe learning procedure (e.g. gradient descent, tree induction); running it on training data produces a model. Controls attach to models and systems, not algorithms in the abstract.Open full entry →, and reports seeing new examples in the Dutch algorithm register every week. Classifying honestly is not a formality; supervisors are actively checking the boundary this article walks through.

Legal referencesArt. 6Art. 5
Share Share on LinkedIn

More on Accountability

Agentic AI and governance: why autonomy sharpens the control question

Analysis

Agentic AI does not need a new kind of governance. Autonomy widens the gap between what a system does and who is accountable for it, which makes the existing governance chain, control tracing to risk and forward to evidence, more important, not less. The actions are real and sometimes irreversible, so the stakes on each control rise.

Agentic AI risk assessment: from architecture decisions to control objectives

Analysis

Assessing the risk of an AI agent does not need a separate method. The steps stay the same: recognize the risk, assess how likely and how severe it is for your system, and control it. What changes is the input. An agent runs the process through recorded architecture decisions, about the model, the instruction, retrieved knowledge, tools, orchestration, memory, and autonomy, and each of those decisions, alone or in combination, creates the possibility of harm. The output of the assessment is a set of risk scenarios with a control objective for each.

AI certification: what exists and what it proves

Analysis

AI certification is not one category. Three different objects are assessed, each by a different kind of assessor: a person, an organization's AI management system, and an AI system placed on the EU market. The first two can be certified. The third is subject to a legal conformity assessment, which produces a certificate on one of its two routes and none on the other. Identifying which object a credential covers is the first step to judging what it is worth.

AI governance and enterprise risk management: where they meet

Analysis

AI governance is not a parallel structure that sits beside enterprise risk management. It belongs inside it. The seven pillars of responsible AI are the control structure the organization uses to govern each AI system; enterprise risk management is the machine that carries the residual risk those controls leave behind into the board's risk appetite, the risk register, and the assurance plan. The practical question is not whether to build AI governance or ERM, but how to slot the first into the second so that one accountable structure, not two competing ones, owns AI risk.

More on Safety & reliability

Regulatory sandboxes: innovation under EU AI Act supervision

Analysis

Regulatory sandboxes under Art. 57-61 are controlled environments, supervised by the national authority, in which organizations can develop and test innovative AI systems with guidance and temporary relief from certain administrative requirements, without suspending the material safeguards or incident-reporting duties.

Regulatory sandbox explained: innovation space under the EU AI Act

Guide

Joining a national AI regulatory sandbox under Art. 57-61 follows a structured path: prepare a project dossier, apply in one of the submission windows, sign a sandbox agreement with the supervisor, report progress and incidents during testing, and produce a final report that supports full compliance afterwards.

Art. 26.1 EU AI Act: following provider instructions as a deployer

Reference

Art. 26.1 requires deployers to use high-risk AI systems strictly in accordance with the provider's instructions for use. This means using the system only for its intended purpose, within its specified technical configuration, and by qualified users, and documenting that compliance. Deviating from the instructions can shift liability entirely to the deployer.

Art. 26.4 EU AI Act: input data quality for deployers

Reference

Art. 26.4 requires deployers of high-risk AI to ensure that input data is relevant and sufficiently representative for the system's intended purpose. The deployer is responsible for data quality in operation, even though the provider sets the specifications under Art. 10.