An EU AI Act classification guide for enterprise teams: inventory, risk categories, provider and deployer roles, approvals and ongoing review triggers.
Topics: EU AI Act, AI Governance, Risk Classification, Compliance, Enterprise
An EU AI Act classification guide should not begin with a legal label. It should begin with an inventory: which AI systems are in use, who owns them, where they operate, what decisions they influence, and which data and people are affected. Without that operational baseline, classification becomes a one-off exercise that cannot be evidenced, reviewed, or maintained as systems change.
For enterprise teams, the central task is to turn the Act's risk-based framework into a repeatable governance workflow. That means classifying each system consistently, recording the rationale, assigning accountable owners, and linking the result to privacy, security, supplier, and incident-management controls.
EU AI Act classification guide: start with the system, not the tool
The EU AI Act applies to AI systems and, separately, to certain general-purpose AI models. A product name or supplier category is not enough to determine the applicable obligations. The same underlying model may support a low-impact internal drafting assistant, a customer-facing chatbot, or a system that influences recruitment decisions. Those uses require different assessments.
Create an AI system registry that captures the system's intended purpose, users, affected individuals, geography, deployment status, provider or deployer role, input and output data, degree of human oversight, and connection to consequential decisions. This record should be owned by the business function using the system, with review by privacy, legal, risk, and security stakeholders where appropriate.
Classification should be triggered before procurement, development, major configuration changes, deployment in a new business unit, or a material change in intended purpose. It should also be reviewed periodically. An initially limited pilot can become a controlled production system quickly once it receives live personal data, is integrated into core workflows, or is made available to a wider group of users.
The four practical classification outcomes
The Act is often described through four risk categories: prohibited, high-risk, transparency obligations, and minimal or no specific AI Act obligations. This is useful for operational triage, provided teams also assess general-purpose AI model requirements and other laws that may apply.
1. Prohibited AI practices
The first question is whether the intended use falls within a prohibited practice. These are uses the Act does not permit, subject to tightly defined exceptions in particular areas. Examples include certain manipulative or exploitative techniques, social scoring, prohibited forms of biometric categorisation, and certain uses of real-time remote biometric identification in publicly accessible spaces.
A prohibited-practice check should be a hard stop in the intake workflow. Do not treat it as a later legal review after a pilot has been approved or supplier contracts have been signed. Record the use case, the assessment date, the reviewer, the decision, and any restrictions imposed. This creates a clear evidence trail if the system is challenged internally or externally.
2. High-risk AI systems
High-risk status is the most significant operational classification for many organisations. Under Article 6, systems may be high-risk because they are safety components of products covered by specified EU product safety legislation, or because they are used in one of the areas listed in Annex III.
Annex III covers defined use cases, including parts of biometric identification and categorisation, education and vocational training, employment and worker management, access to essential private and public services, law enforcement, migration and border management, and the administration of justice and democratic processes. Recruitment screening, candidate ranking, employee performance evaluation, creditworthiness assessment, and eligibility decisions are common enterprise scenarios that require careful analysis.
The classification cannot be reduced to an industry label. A system used in HR is not automatically high-risk solely because it appears in an HR workflow. The intended purpose and actual function matter. There is a limited exemption where an Annex III system does not pose a significant risk of harm to health, safety, or fundamental rights, such as where it performs a narrow procedural task or supports a human activity without materially influencing the outcome. That exemption requires documented reasoning, not an informal judgement.
Where a system is high-risk, the organisation must identify its role. Providers have a more extensive set of requirements, including risk management, data governance, technical documentation, logging, human oversight, accuracy, cybersecurity, and conformity assessment obligations. Deployers also have defined responsibilities, including using the system according to instructions, maintaining human oversight, monitoring operation, and, in relevant circumstances, carrying out a fundamental rights impact assessment.
For governance teams, the practical point is simple: high-risk classification needs a control plan, not just a tag in a register. Connect the AI record to the relevant impact assessments, approval workflow, testing evidence, supplier documentation, monitoring plan, training records, and incident process.
3. Transparency obligations
Some AI systems are not high-risk but still require transparency measures. Article 50 addresses situations such as AI systems intended to interact directly with people, emotion recognition or biometric categorisation systems, and AI-generated or manipulated content.
The correct control depends on the use. A customer service assistant may need to make clear that a person is interacting with AI. Synthetic content processes may require machine-readable marking or disclosure measures, subject to the Act's detailed conditions and exceptions. Teams should avoid treating transparency as a generic disclaimer exercise. The disclosure must be appropriate to the audience, the channel, and the system's actual behaviour.
Document the required measure in the system record and assign a business owner who can demonstrate that it is live. If the system is supplied by a third party, ensure the contract and implementation process make responsibilities explicit rather than assuming the supplier has addressed every deployer obligation.
4. Minimal-risk or unregulated use cases
Many AI applications will not fall into a prohibited or high-risk category and may not trigger a specific transparency duty. Internal productivity tools, forecasting support, document summarisation, and quality assurance workflows may sit here, depending on their purpose and deployment.
This does not mean no governance is required. GDPR, confidentiality, intellectual property, sector rules, employment obligations, contractual restrictions, and internal risk policies may still apply. A system processing personal data should be assessed through the organisation's DPIA process where likely high risk to individuals exists. Where the legal basis relies on legitimate interests, a Legitimate Interest Assessment may also be needed.
A proportionate control set is usually more effective than applying high-risk controls indiscriminately. Record the classification, restrict sensitive data where necessary, define acceptable use, establish human review for consequential outputs, and retain supplier due diligence. This preserves speed for lower-risk use while maintaining organisational control.
Do not confuse AI system classification with model classification
General-purpose AI models create a separate assessment path. A model provider may have obligations because of the model's capabilities and distribution, including additional requirements for models with systemic risk. An enterprise deploying a model inside an application still needs to classify the resulting AI system according to its intended purpose.
This distinction matters in supplier governance. A vendor's statement that its model is compliant does not classify your customer-facing or employee-facing deployment. Conversely, a system can be subject to high-risk requirements even where the underlying model is widely available and used in many lower-risk contexts.
Your vendor and third-party risk assessment should therefore collect evidence on the model, the supplier's documentation, data handling, security controls, change management, usage restrictions, and the organisation's own configured use case. Contract review and DPA redlining should reflect the allocation of privacy and AI governance responsibilities.
Build a defensible classification workflow
A defensible process has defined inputs, accountable decisions, and retained evidence. It should not depend on one subject-matter expert remembering why an earlier decision was made.
Start with a structured intake questionnaire. Ask what the system does, whether it makes or materially supports decisions about individuals, the categories of people affected, whether biometric or sensitive data is involved, the intended users, and whether a supplier or internal team is providing the system. Include questions aligned to prohibited practices, Annex III, Article 50, and general-purpose AI.
Next, route the assessment based on the answer set. A possible prohibited practice should go to legal review before use. A potential high-risk system should require a deeper assessment, documented owner approval, and linked control activities. A transparency case should produce an implementation task and validation record. Lower-risk systems should receive proportionate governance requirements rather than disappearing from view.
The decision record should capture more than the final category. Retain the rationale, legal interpretation used, applicable provisions, named approvers, evidence reviewed, residual risks, conditions of use, and next review date. Where the classification relies on an exception, state exactly why the exception applies and what facts would require reassessment.
Finally, link classification to the operational systems that keep it current. An AI system register should connect with ROPA entries where personal data is processed, DPIAs and LIAs, vendor assessments, contract records, breach and incident management, and audit evidence. Privacy360 supports this model by bringing AI system oversight and EU AI Act risk classification into the same operational environment as core privacy governance workflows.
Review classifications when the facts change
Classification is not permanent. A system may change risk profile when it moves from internal support to customer interaction, starts processing new data types, becomes integrated with a decision engine, expands into another jurisdiction, or receives a material model update from a supplier.
Set event-based reassessment triggers and do not rely only on an annual review. Procurement renewals, significant incidents, audit findings, supplier change notices, new integrations, and changes in intended purpose should all prompt a check. The incident workflow is particularly valuable: recurring errors, bias concerns, unauthorised use, or inaccurate outputs may show that the original assumptions no longer hold.
Where internal capacity is limited, Formiti's data protection and AI governance consulting services provide experienced practitioner support to design, run and assure this operating model across jurisdictions.
The useful outcome is not a perfect label in isolation. It is a living record that allows the organisation to show what the system does, why it received its classification, who accepted the risk, and what controls operate around it. That is the foundation for AI governance that can withstand growth, scrutiny, and change.