TL;DR
- EU AI Act risk categories place every AI system into one of four tiers: prohibited, high-risk, limited risk, or minimal risk. Which tier your system lands in determines your pre-deployment obligations, documentation requirements, and exposure to regulatory penalties.
- High-risk classification triggers eight specific obligations under Articles 9–15. They include complete technical documentation before deployment, inference logging at the model-serving layer, functioning human oversight, and EU database registration.
- Classification follows the use case, not the model type or company size. A hiring tool built on a general-purpose model is high-risk. A demand forecasting algorithm built on a custom model is not.
Under the EU AI Act (Regulation 2024/1689), “high-risk” is not a vague regulatory warning. It is a specific technical classification that places eight concrete obligations on your system before it can legally operate in the EU market. Whether your AI qualifies depends on what it does, not how sophisticated it is.
This article is for founders and executives who are building and running AI-powered systems. All of them need to answer one practical question: does what we’ve built trigger a high-risk classification, and, if so, what does that mean for our product roadmap right now?
We’ll cover the two classification paths, walk through specific B2B (business-to-business) use cases and where they land, explain what high-risk obligations actually require at the architecture level, and give you a starting workflow for assessing your own systems. For a broader overview of the regulation and its compliance timeline, see our companion piece EU AI Act Explained: What Your System Must Actually Do. All regulation references in this article draw from the official EU AI Act text.
What triggers a high-risk classification under the EU AI Act
High-risk classification follows two distinct paths under the Act. A system qualifies if it fits either one — the paths are not cumulative.
Path A — Annex III use cases
Annex III names eight specific domain categories where AI that makes or meaningfully influences consequential decisions about individuals is classified as high-risk. The phrase “meaningfully influences” is the operative one. A system that generates a recommendation a human acts on without genuine review meets the same standard as one that decides directly.
The eight Annex III categories:
| Category |
What qualifies as high-risk |
| Biometric identification | Remote biometric ID systems, emotion recognition for categorization |
| Critical infrastructure | Safety components in energy, water, traffic management |
| Education and vocational training | Systems that determine access, grades, or evaluation of students |
| Employment and HR | Recruitment screening, CV filtering, performance monitoring, task allocation |
| Access to essential services | Credit scoring, insurance risk assessment, benefit eligibility |
| Law enforcement | Crime risk profiling, polygraph tools, evidence reliability assessment |
| Migration and border control | Risk assessment of applicants, document verification |
| Justice and democratic processes | Systems assisting courts; tools that influence elections |
Source: Annex III, EU AI Act.
If your AI inputs into decisions about who gets hired, who gets credit, who accesses education, or who faces law enforcement action, treat it as Annex III high-risk until a documented assessment confirms otherwise.
Path B — AI integrated into regulated products
Annex I covers AI embedded as safety components into products already regulated under EU law: medical devices, in vitro diagnostic (IVD) devices, machinery, aviation components, motor vehicles, agricultural machinery, toys, lifts, and personal protective equipment.
For healthcare AI companies specifically: if your AI is part of a diagnostic tool, clinical decision support system, or any component of a medical device, Annex I applies alongside EU Medical Device Regulation (MDR) requirements. Both frameworks operate in parallel, and compliance with one does not satisfy the other.
EU AI Act risk categories explained: the full four-tier picture
EU AI Act risk categories divide all AI systems into four tiers. This article focuses on high-risk, but a brief orientation to the others is useful since many companies build across multiple product lines, and different systems in the same portfolio can land in different tiers.
- Prohibited (unacceptable risk): AI practices banned outright under Article 5 since February 2, 2025. Social scoring by public authorities, subliminal manipulation that bypasses conscious awareness, real-time remote biometric surveillance in public spaces for law enforcement, and individual predictive policing based purely on profiling. No transition period applied.
- High-risk: Full compliance obligations under Articles 9–15. Two classification paths: Annex I (AI in regulated products) and Annex III (named use case categories). Compliance must be in place before the system is deployed.
- Limited risk: Transparency obligations only. Chatbots must identify as AI at the start of each interaction. Synthetic media must be labeled as AI-generated. Emotion recognition must notify subjects. These are design requirements with direct interface implications.
- Minimal risk: No mandatory obligations. Most deployed AI falls here — spam filters, recommendation engines, content personalization. Approximately 85% of AI systems fall into this tier. The European AI Office is developing voluntary codes of conduct.
Classification is done system by system. A company with five AI products may have two in different risk tiers.
Where does your SaaS or AI product actually land?
The matrix above applies a consistent principle: AI that influences consequential decisions about specific, identifiable individuals is high-risk. AI that optimizes internal business processes without producing outputs about specific people is not.
Two examples clarify where the line sits:
- A hiring tool that recommends candidates to a recruiter based on CV content is high-risk. A tool that drafts job descriptions or schedules interviews is not — it does not influence individual outcomes under Annex III.
- An AI symptom checker that influences a clinician’s decision for a specific patient is high-risk. An AI tool that analyzes population-level health data for resource planning is not automatically considered high risk under Annex III.
The operative question is: does this system produce outputs about specific individuals that a human acts on in ways that affect their legal, economic, or social position?
Use the flowchart above as a starting point for each AI system in your portfolio. Document your reasoning at each decision point. If a regulator later asks why you classified a system as minimal-risk, a written rationale produced before deployment is what you will need.
One classification scenario most B2B AI companies miss: if your company fine-tunes a foundation model and deploys it for a specific regulated use case, you may be classified as a Provider under the Act, not just a Deployer. Provider obligations are substantially more extensive and include technical documentation, conformity assessment, and EU database registration. This applies even if you did not train the underlying model. Classification follows the use case, not the model’s origin.
The AI Compliance Stack: three layers every high-risk system must address
High-risk compliance under the EU AI Act requires simultaneous work across three distinct engineering layers. Teams most often start with whichever layer surfaced first — typically a specific audit finding or a regulatory question that arrived unexpectedly. Working on one layer at a time is not a compliance strategy. Missing any layer creates regulatory exposure even when the other two are solid.
We call this structure the AI Compliance Stack. It’s the framework Corpsoft Solutions developed from work across a range of AI compliance engagements, and it’s the methodological foundation we use to scope and deliver EU AI Act high-risk compliance work today.
The AI Compliance Stack maps these three layers directly onto the obligations in Articles 9–15:
|
Layer |
What it covers |
EU AI Act obligations |
| Layer 1: Data governance | Input data sourcing, consent capture, storage and retention, cross-border transfer, anonymization, training data provenance, bias screening and remediation | Article 10 (data and data governance); GDPR lawful basis for training data |
| Layer 2: Model governance | Decision logging, audit trails, model version control, explainability interfaces, human-in-the-loop design, performance and robustness monitoring | Article 12 (record-keeping), Article 13 (transparency to users), Article 14 (human oversight), Article 15 (Accuracy, robustness and cybersecurity) |
| Layer 3: Regulatory compliance | Classification, risk management system, technical documentation, conformity assessment, EU database registration, ongoing audit evidence | Article 9 (risk management system), Article 11 (technical documentation), Article 43 (conformity assessment), Article 49 (EU database registration), Annex III |
The layers are also sequential in one specific direction: Layer 3 documentation depends on Layer 2 logging being in place, which in turn depends on Layer 1 data governance being designed into the system. You cannot document training data provenance you never recorded. Decision logs cannot be produced from an inference pipeline that was never built to generate them. Documentation that describes a system’s intended behavior, rather than its actual behavior in production, does not satisfy Article 11.
The eight specific obligations in Articles 9–15 that apply to high-risk systems are distributed across all three layers. That is why compliance cannot be handled as a single engineering sprint or a documentation project alone.
What a high-risk AI system must actually do
The eight obligations defined in Articles 9–15 of the EU AI Act apply to every high-risk AI system before it can legally go to market. Below is what each requires in engineering and operational terms.
Data governance and training data
Training and testing data must be relevant and representative of the operational environment, screened for biases that could produce discriminatory outputs — with documentation of what was found and how it was addressed — and subject to AI data governance practices covering collection, labeling, cleaning, and storage.
Documented provenance for training datasets is required, not just versioned model files. Where data was collected under GDPR, its use for AI training must align with the original lawful basis — or a new one must be established. Our AI data governance guide covers the data-layer requirements in detail.
Technical documentation — before you ship
Technical documentation is EU AI Act compliance documentation as a condition of market entry. It must exist before the system is deployed and must cover:
- The general purpose and design of the system
- System architecture and components
- Capabilities, limitations, and known risks
- Data used for training, testing, and validation
- Performance metrics and accuracy benchmarks
- Changes made during the system’s lifecycle
Placing a high-risk system on the EU market without complete technical documentation is a compliance violation on day one of deployment. The documentation must be updated whenever the system changes significantly.
Automatic logging — what your system must record
High-risk AI systems must automatically log events to the extent needed to identify risks during operation, enable post-hoc investigation of incidents, and support national authority audits.
At minimum, the log must capture: when the system starts and stops operating, input data where technically feasible, output decisions, and any overrides by human operators. This is an architecture requirement. Logging assembled from application logs after the fact does not satisfy Article 12. The log must be generated at the model serving layer.
Transparency to users and deployers
Deployers must receive documentation about the system’s intended purpose, accuracy levels, and known risks. Users affected by high-risk AI decisions have the right to a meaningful, case-specific explanation — particularly when those decisions concern employment, credit, or essential services.
This is where explainable AI becomes a regulatory requirement, not an engineering aspiration. A generic description of how the model works does not satisfy GDPR Article 22 or EU AI Act Article 13. The explanation must be specific to the individual decision.
Human oversight that actually works
Article 14 requires high-risk systems to be designed so that humans can understand what the system is doing and why, monitor its performance in operation, intervene to pause, stop, or override it, and make and bear accountability for consequential decisions.
The compliance gap here is specific. A human approving AI decisions without reviewing the underlying reasoning does not satisfy Article 14. Using the AI output as the sole basis for a consequential decision does not count. Delegating oversight to a second AI system does not count.
What does count: access to the model’s reasoning, confidence scores, and relevant input data; a documented process for when to override; logged records of interventions and overrides. Human oversight is an interface design requirement as much as it is a workflow policy.
Accuracy and robustness
Article 15 requires high-risk systems to achieve and maintain levels of accuracy appropriate to their intended purpose throughout the system’s lifecycle, not only during initial validation. A system that performed well in testing six months ago is not automatically compliant today if the data it now encounters in production has drifted from what it was trained on.
Robustness has a specific meaning here. The system must continue to perform adequately under edge cases, adversarial inputs, and conditions that differ from the training environment. In practice, this requires continuous performance monitoring in production, documented accuracy benchmarks tied to the system’s stated purpose, and a defined process for retraining or recalibrating when performance drops below an acceptable threshold. Accuracy claims made in the technical documentation must be testable, not aspirational.
Cybersecurity
Article 15 also requires high-risk systems to resist attempts to alter their behavior, exploit vulnerabilities, or manipulate outputs without detection. This obligation extends past conventional application security into attack surfaces specific to AI systems.
Three types of attacks are most relevant here. Prompt injection manipulates the inputs a system receives to override its intended behavior. Model poisoning corrupts training data to bias future outputs in an attacker’s favor. Inference attacks extract sensitive training data or internal model details through carefully constructed queries sent to a deployed system. Traditional cybersecurity frameworks, built around network and application-layer threats, were not designed to catch any of these. Meeting Article 15 in practice means testing for AI-specific vulnerabilities as part of the same security review that covers standard infrastructure, not treating model security as a separate problem.
EU database registration
Before a high-risk AI system is deployed, it must be registered in the EU’s publicly accessible AI database, with exceptions for national security applications. Registration appears administrative, but in practice it requires most of the documentation above to be complete before the filing can proceed. It is a pre-deployment requirement, not a post-launch step.
Providers vs. deployers — who owns which obligation
For B2B AI companies, the obligation split between providers and deployers is frequently misunderstood — and the consequences of misunderstanding it are significant.
| Role | Definition | Key obligations |
| Provider | Develops or places an AI system on the market | Technical documentation, conformity assessment, EU database registration, post-market monitoring |
| Deployer | Uses an AI system in a professional context | Correct use per instructions, DPIA where required, human oversight implementation, operational monitoring |
| Importer | Brings a non-EU provider’s AI into the EU market | Verify provider compliance before placing on market |
| Distributor | Makes an AI system available without modifying it | Verify compliance markings, cooperate with authorities |
Source: EU AI Act, Chapter 3.
If you fine-tune a foundation model for a client, or build a product on top of a third-party model for a specific regulated use case, you may be reclassified as a Provider — even if you did not train the underlying model. This distinction needs to be established in contracts and compliance planning before an audit raises it.
A practical starting point: classify your AI systems now
The classification exercise is the first step every company building AI for EU markets needs to complete. Document the output at each step. Classification reasoning produced before deployment is defensible in a regulatory review. Reasoning assembled in retrospect is not.
Step 1 — Build a complete AI system inventory
List every AI-powered system your company develops, deploys, or incorporates into a product or internal process. For each system, document:
- What decision or recommendation the system produces
- Who the output affects, and in what context
- Whether affected individuals are specifically identifiable
- Whether the use case matches any Annex I or Annex III category
If the answer to the last question is “possibly yes,” treat the system as high-risk until a documented assessment confirms otherwise.
Step 2 — Run a gap analysis against Articles 9–15
For each system classified as high-risk, compare your current state against the eight obligations:
- Data governance documentation for training datasets
- Complete technical documentation — pre-deployment
- Automatic event logging at the model serving layer
- User and deployer transparency with case-specific explanations
- Human oversight mechanism designed as a required gate
- Accuracy and robustness standards — tested and documented
- Cybersecurity controls evaluated against AI-specific attack vectors
- EU database registration readiness before deployment
A gap written down with an engineering effort estimate is a manageable remediation item. A gap assumed to be minor is a compliance liability.
The architecture behind high-risk compliance
The eight obligations above are engineering requirements. The most common obstacle is not that teams don’t understand what’s required — it’s that the systems they’ve built weren’t designed with these requirements in mind.
Most AI systems in production today have no version control on trained models (only on source code), no logging infrastructure separate from application logs, no ability to trace a specific prediction back to the training data that influenced it, and human review interfaces that are optional workflow elements rather than required gates.
These are expensive to retrofit. The cost — in engineering time, data re-labeling, and test coverage — is the real AI compliance risk for teams that discover their classification late. For a detailed breakdown of how to approach AI governance architecture, see our article on AI governance and compliance.
How Corpsoft Solutions works with teams preparing for high-risk compliance
Corpsoft Solutions designs and builds AI systems for regulated environments. For teams facing high-risk classification, our work covers all three layers the Act requires: data governance at the pipeline level, model governance at the serving layer, and regulatory compliance documentation for conformity assessment.
Our AI governance services are designed for teams at exactly this stage — classifying AI portfolios, identifying architecture gaps, and producing remediation roadmaps. For industry-specific guidance, see our AI governance across industries resource. For the full EU AI Act compliance engineering service, see our EU AI Act compliance services page.
Where to go from here
The question “is your AI system high-risk?” has a specific, documentable answer under the EU AI Act. EU AI Act risk categories follow the use case — and for most B2B AI products that influence employment, credit, education, or healthcare decisions, the answer is yes. Knowing that now, with the August 2027 compliance deadline still allowing deliberate architecture decisions, is a different position than discovering it under deadline pressure.
Share this post:
