AI Act risk classification — a step-by-step method

AI Act risk classification must be performed for a specific system, use case and organisational role — not for a model or vendor in isolation. First establish whether the solution is an AI system and whether it carries out a prohibited practice. Then test both high-risk routes, the transparency provisions, the remaining uses and the separate GPAI layer. The output should be a decision record with an owner, legal source, rationale and review trigger, not merely a label such as “high-risk” or “minimal”.

The primary reference is the EU AI Act, Regulation (EU) 2024/1689. Its general application date is 2 August 2026, but some provisions started earlier. Chapters I and II, including Article 4 and the Article 5 prohibitions, have applied since 2 February 2025. GPAI obligations started to apply on 2 August 2025. The updated high-risk timetable is explained in our Digital Omnibus and AI Act deadlines guide: 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. Record every date together with the scope and role to which it applies.

Table of contents

• Step 1. Define the AI system boundary
• Step 2. Exclude prohibited practices
• Step 3. Test the high-risk routes
• Step 4. Assess transparency duties
• Step 5. Document the remaining uses
• Step 6. Add the GPAI layer and roles
• FAQ: AI Act risk classification
• Sources and next steps

Step 1. Define the AI system boundary

The first decision is to classify the operating arrangement that produces and uses an output, not the product name printed on a purchase order. Describe the inputs, model or logic, outputs, degree of autonomy, users, people affected and the decision that the output informs. Article 3 provides the definition of an AI system; a vendor’s use of “AI” in marketing does not settle whether a particular implementation is within scope.

The boundary should include all components needed to understand the behaviour. For a recruitment assistant, that may include CV sources, prompts, ranking rules, the ATS integration and the way recommendations are shown to a reviewer. The same language model used to edit neutral internal notes may support a different use case from a module that ranks applicants. One vendor can therefore appear in the system inventory several times, with a different classification record for each use.

Capture at least:

1. intended purpose and actual use;
2. business and technical owners;
3. categories of users and affected people;
4. input data, outputs and integrations;
5. model, configuration and policy versions;
6. markets and jurisdictions in which it operates.

If the solution is not an AI system within the Regulation’s definition, retain the basis for that conclusion and a review trigger. A feature, model or purpose change may alter the result. Being outside the AI Act does not remove obligations under data protection, employment, consumer or sector-specific law.

Step 2. Exclude prohibited practices

If the use case carries out a prohibited practice under Article 5, do not place it in a lighter bucket — stop the deployment and escalate it for legal analysis. This check comes before high-risk classification. A prohibited practice cannot be made permissible merely by adding documentation, monitoring or an owner approval.

Article 5 defines specific practices, conditions and exceptions, so keyword screening is not enough. Review the mechanism, context and people affected. Areas requiring particular attention include manipulation or exploitation of vulnerabilities, social scoring, certain forms of crime-risk prediction, untargeted scraping of facial images, emotion recognition in workplaces and educational settings, and particular biometric uses. This summary is not a substitute for reading the complete provision and its conditions.

A useful decision record names the practice tested, relevant facts, legal text, exceptions considered, reviewer and outcome: “stop”, “redesign” or “continue”. Repeat the test when procurement changes the supplier or the team introduces a new data source. Articles 4 and 5 have applied since 2 February 2025. Keep that earlier timetable separate from the later Annex I and Annex III dates.

Step 3. Test the high-risk routes

A system is a high-risk candidate if either Annex I or Annex III leads to that result, and the two routes must be tested separately. The Article 6(1) route requires both conditions: the AI system is a safety component of, or is itself, a product covered by the Union harmonisation legislation listed in Annex I, and that product is required to undergo a third-party conformity assessment under that legislation. Annex III identifies use cases in fields including biometrics, critical infrastructure, education, employment, access to essential services, law enforcement, migration and the administration of justice, subject to the wording and conditions in the Regulation.

Do not classify an entire HR department or banking platform in one stroke. A tool that improves the wording of a vacancy and a module that ranks applicants can have different legal treatment. For Annex III uses, also test the conditions in Article 6(3) and document the assessment before relying on an exception available there. Record the intended purpose, the significance of the output to the decision, each criterion met and every exception applied. Where qualification is uncertain, mark the case for legal review rather than defaulting to a lower category.

For high-risk systems, the Regulation establishes an extensive regime that also depends on the actor’s role: risk management, data requirements, technical documentation, logging, information for deployers, human oversight, accuracy, robustness and cybersecurity, alongside conformity and post-market activities assigned to the relevant actors. This does not mean every organisation performs every task. Providers, deployers, importers and distributors have distinct duties.

Our Digital Omnibus and AI Act deadlines guide explains the amended timing in context. The full rules apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I systems. A deferral does not remove the need for inventory, rules already in application or duties arising under other law.

Step 4. Assess transparency duties

A finding that a system is not high-risk does not finish the analysis: test Article 50 for transparency duties linked to the interaction or content. Depending on the facts, a person may need to be informed that they are interacting with AI, certain synthetic outputs may require machine-readable marking, or manipulated image, audio or video content may need disclosure. The exact duty, exception and responsible actor come from the relevant paragraph, not from the broad shorthand “limited risk”.

Map a duty to the actual audience touchpoint. For a chatbot, review the first exchange and whether the context makes the AI interaction obvious. For content, establish who generates it, who publishes it, for what purpose, and whether an exception applies. Keep the approved notice text, screenshot or interface version, accessibility test and owner responsible for revisiting the disclosure when the channel changes.

“Limited risk” and “minimal risk” are helpful operational shorthand, but they are not substitutes for testing the applicable provisions. A system can be outside the high-risk categories yet still be subject to Article 50, Article 4, a GPAI requirement or non-AI-Act law. The general application date remains 2 August 2026.

Step 5. Document the remaining uses

If the system is not prohibited, does not qualify as high-risk and does not trigger the transparency duty being tested, record a lower regulatory profile — not “no risk”. These uses are often described as minimal risk. That means the analysis did not identify the specified system-level duties under the AI Act; it is not a finding that the system is safe, accurate or compliant with every other law.

For an internal document summariser, proportionate practice may include quality testing, access controls and an error-reporting route. A customer-facing system may justify more extensive controls. Those are governance and risk-management choices; they are not automatically legal requirements created by the “minimal risk” label.

The table below deliberately separates legal duties from implementation practice. “Obligations” summarises duties that may apply and must be confirmed against the actor’s role and facts. “Semitora evidence artifact” describes an implementation practice used to organise evidence; the AI Act does not mandate that exact artifact or format.

This material does not replace legal advice or a formal conformity assessment. Semitora supports technical analysis, governance and evidence engineering, while legal qualification and any required formal conformity assessment remain with the appropriate qualified actors and bodies.

Risk level	Obligations	Semitora evidence artifact	Owner
Unacceptable / prohibited practice	Prohibition of the defined practice; confirm Article 5 scope and exceptions	Versioned “stop or redesign” decision note	Legal / compliance and sponsor
High-risk — provider	Provider duties include risk management, data requirements, technical documentation, logging and the design of human oversight	Requirements-to-evidence matrix, gap backlog and go/no-go record	AI-system provider and risk owner
High-risk — deployer	Deployer duties include use according to instructions, input-data controls, human oversight in operation, monitoring and log retention where required	Register of instructions, operating controls, incidents and escalations	Deployer and business-process owner
High-risk — Annex I route	The AI Act regime must be aligned with the regulated-product procedure after both Article 6(1) conditions are met	Mapping from AI requirements to product file and assessment plan	AI provider and product manufacturer or product compliance; the roles may sit with different entities
Transparency	Information or labelling duty where Article 50 conditions are met	Notice register, channel test and approved version	Product owner / content owner
Remaining uses	No automatic high-risk package; Article 4 and other law still require review	Proportionate control card, tests and review date	Business owner
GPAI — separate layer	Duties depend on the model-provider role and model characteristics	Supplier due diligence, model documentation and dependency list	Model provider / vendor owner

Version the artifact with the system. A minimum record includes the system identifier, use case, organisational role, result of the six steps, sources, assumptions, open questions, owner and next review point. This prevents a model or purpose change from silently overwriting the history of a decision.

Step 6. Add the GPAI layer and roles

Finish by adding two axes: dependence on a general-purpose AI model and each actor’s role in the value chain. GPAI is not a fifth system risk level. It is a separate regime for general-purpose models that can coexist with the classification of the downstream system. GPAI obligations have applied since 2 August 2025; their scope depends, among other matters, on who is the model provider and the characteristics of the model. Models placed on the market before that date are covered by separate transitional rules, so check the provider’s deadline under Articles 111 and 113 before treating documentation as overdue.

A company consuming an API does not become a GPAI model provider merely by purchasing access, but it should still understand dependencies, use terms and available documentation. In parallel, establish its role for the downstream system. It may be the deployer of an off-the-shelf tool, the provider of a system placed under its own name, an importer or a distributor. A substantial modification or changed intended purpose may affect roles and duties, so the conclusion must rest on the specific facts.

A strong handover is a concise decision record:

• result: prohibited / high-risk I / high-risk III / Article 50 / remaining use;
• roles: separately for the model, system and distribution channel;
• rationale: legal source, fact, criterion and any exception;
• evidence: links to documentation, tests, logs and approvals;
• decision: stop, redesign, conditional deployment or go-live;
• review trigger: a change in purpose, data, model, market or process.

Our seven-part AI Act Evidence Pack guide shows how to organise the supporting record. Not every part of the pack is a document expressly named by the law. Together, however, the parts provide a navigable trail from scope and testing through decision and operation.

FAQ: AI Act risk classification

Does a language model have one risk level everywhere it is used?

No. The downstream system classification depends on intended purpose, use case, role and context. The same model may support low-impact text editing and a separate recruitment process that requires an Annex III analysis. The GPAI model is assessed as an additional, distinct layer.

Does keeping a human in the loop automatically remove high-risk status?

No. Human oversight can be an important control, but placing a person after the model does not automatically change the Annex criteria. Reviewers need a genuine ability to understand, challenge and disregard outputs, and the use case still needs its own legal classification.

Can we postpone classification because high-risk dates were deferred?

That is not a sound approach. The Digital Omnibus moved the full dates for the specified high-risk systems, but it did not switch off provisions that already apply or other legal regimes. Classification is what tells an organisation which date and set of duties are relevant.

Who should approve the classification record?

The business owner should confirm the facts and intended purpose, the technical owner should confirm architecture and behaviour, and risk, compliance and legal should address their respective qualification questions. Regulated products also require product-compliance roles and whoever owns the formal assessment path.

How often should the classification be reviewed?

There is no single interval appropriate for every system. Set a periodic review and event triggers: a new purpose, model, supplier, data source, user group, country, integration or material performance change. Linking the review to factual change matters more than choosing a calendar cadence alone.

Sources and next steps

The controlling primary source for the classification method is Regulation (EU) 2024/1689. Read the operative provisions with their annexes, definitions, actor roles and exceptions; the updated high-risk dates are summarised in our Digital Omnibus deadlines guide. This material is informational; it does not replace legal advice or a formal conformity assessment for a specific deployment.

Our AI Act practice page explains Semitora’s technical and governance scope. For self-service preparation, use the readiness checklist and Evidence Pack template. If you need to move from an AI-system inventory through classification to an evidence plan, see Semitora services. A useful first workshop outcome is not a colour in a spreadsheet but an agreed decision record, named owner and explicit list of questions requiring formal legal interpretation.