A practical AI Act classification framework covering inventory, intended purpose, risk tiers, approvals and the evidence teams need to defend decisions.
Topics: AI Act, EU AI Act, AI Governance, Risk Classification, Compliance
An AI system can move from a contained pilot to a business-critical service before anyone has recorded what it does, who is accountable for it, or whether it falls within a regulated use case. AI Act classification turns that uncertainty into a controlled decision. For privacy, legal, risk and technology leaders, the objective is not simply to attach a category to each tool. It is to establish an evidence-based process that stands up to internal challenge, supplier scrutiny and regulatory review.
The EU AI Act applies according to the system’s intended purpose, the organisation’s role in the AI value chain and the context in which the system is placed on the market, put into service or used. A useful classification process therefore begins with facts, not assumptions. Product names, broad statements such as “AI-assisted”, and supplier marketing material are not enough.
Why AI Act classification needs an operating process
Classification is often treated as a one-off legal exercise. That creates a predictable control gap: the business changes the system’s use, adds new data sources, expands deployment to another country or relies on a supplier update, while the original assessment remains untouched.
An effective process treats classification as a lifecycle control. It connects intake, assessment, approval, implementation, monitoring and change management. This matters because the classification outcome determines the controls an organisation must apply, the people who need to be involved and the evidence that must be retained.
For example, a system that ranks job applicants, supports access to education, assesses creditworthiness or influences access to essential services may require close analysis against the Act’s high-risk categories. A generative AI tool used solely to help a communications team draft internal copy presents a materially different governance profile from a tool that influences employment, insurance, healthcare or public-sector decisions.
The difference is not the technology alone. It is the intended purpose, the affected individuals, the decision context, the degree of human oversight and the consequences of error.
Start with a complete AI system inventory
No classification programme works if the organisation cannot identify the systems it uses. The AI system registry should be the operational source of truth, rather than a spreadsheet held by one team or an informal list maintained by IT.
Each record should establish the system’s business owner, technical owner, supplier or developer, deployment status, jurisdictions, user groups and intended purpose. It should also capture whether the organisation is acting as a provider, deployer, importer, distributor or authorised representative. More than one role can be relevant across a complex group structure or supply chain, so this must be assessed carefully.
The intended purpose should be written in plain operational language. “Uses machine learning for efficiency” does not support a classification decision. “Prioritises customer service cases based on predicted vulnerability and recommends escalation actions to agents” gives legal, risk and operational stakeholders something concrete to assess.
The inventory should also record the data categories involved, whether special category or criminal offence data is processed, whether outputs affect people directly, and whether the system interfaces with other automated workflows. These details support both AI governance and existing privacy controls, including ROPA and Data Protection Impact Assessment workflows.
Apply AI Act classification in the right sequence
A repeatable decision sequence reduces inconsistent judgements across business units. The first question is whether the product or use case falls within the Act’s definition of an AI system and within its territorial scope. Organisations should document the reasoning, particularly where the answer is uncertain or where an existing software product gains AI functionality through an update.
Next, assess whether the intended practice is prohibited. The Act restricts certain uses because of their potential impact on people’s rights and safety. This review should never be reduced to a checkbox. Teams need sufficient information about how the system operates, the environment in which it is used and the population affected.
If the use is not prohibited, determine whether it is high-risk. High-risk classification can arise because the system is a safety component of a regulated product, or because its intended purpose fits a listed area such as employment, education, access to essential services, law enforcement, migration, justice or democratic processes. The precise analysis depends on the use case and applicable conditions, so borderline cases should be escalated for legal review rather than forced into a low-risk category for convenience.
Where a system is not high-risk, it may still carry transparency obligations. This can be relevant where people interact with AI, encounter certain AI-generated content or are subject to particular forms of emotion recognition or biometric categorisation. General-purpose AI models can also create obligations for providers and responsibilities that deployers need to understand through their supplier governance process.
The output should be more than a label. A defensible record states the classification, the rationale, the source material reviewed, the accountable decision-maker, the date of decision and the review trigger. It should also identify unresolved questions and required actions before deployment.
Classification must reflect the actual use case
The same underlying model can support very different classifications. A language model used to summarise non-sensitive meeting notes is not assessed in the same way as that model embedded in a recruitment workflow to score candidates. Similarly, a supplier’s statement that its product is “EU AI Act ready” does not decide the organisation’s classification. The customer’s intended use and configuration remain central.
This is why a central registry needs structured use-case records, not only a catalogue of approved suppliers. One supplier product may have multiple deployments, owners, data sources and risk profiles. Treating it as one entry can hide the highest-risk use.
Translate the classification into accountable controls
A classification decision only creates value when it changes how the organisation governs the system. For high-risk use cases, the control plan will typically need clear ownership across legal, compliance, privacy, security, procurement, technical teams and the business sponsor. The plan should map applicable requirements to evidence, deadlines and accountable owners.
Data governance is a practical example. Teams need to understand what data supports training, testing and operation; whether it is relevant and sufficiently representative for the purpose; how data quality issues are identified; and whether privacy risks have been assessed. A DPIA may be necessary under data protection law, but it does not replace AI Act analysis. The two assessments should inform each other while retaining their distinct legal and operational purposes.
Human oversight also requires specificity. “A human is in the loop” is not a meaningful control if the reviewer lacks authority, time, training or access to the information needed to challenge an output. Record who can intervene, when intervention is required, what escalation route exists and how overrides are monitored.
For supplier-provided systems, contract review and vendor risk assessment should collect the documentation required to support the organisation’s role. This may include intended-use statements, technical documentation, instructions for use, test and performance information, security commitments, change notifications, incident cooperation and clear allocation of responsibilities. Procurement should not approve a material AI service without confirming which evidence will be available throughout the relationship.
Build change management into the decision
Classification can change. A model retrained on new data, a new automated action, a different user group, a move into another jurisdiction or a supplier functionality release may alter the original assessment. Governance teams need defined triggers that return the system to review.
Useful triggers include a change to intended purpose, a significant model or supplier update, a new integration, use of sensitive data, a material performance issue, an incident, or a decision to rely on outputs in a higher-impact process. These triggers should feed existing incident management, change approval and supplier review workflows rather than depend on employees remembering to notify legal teams informally.
Periodic review still matters, particularly for systems that remain active but do not undergo obvious change. The appropriate review frequency depends on the classification, scale of deployment, impact on individuals and supplier release cycle. A high-impact decision system should not receive the same review cadence as a low-impact internal productivity tool.
Make evidence available when it is needed
Audit readiness is not achieved by storing documents in multiple team folders. It requires a clear evidence trail connecting the inventory record, classification rationale, risk assessments, approvals, supplier materials, implementation controls, monitoring results and review history.
A unified governance platform makes this operationally manageable. Privacy360 connects the AI system registry and EU AI Act risk classification with DPIAs, ROPA, vendor assessments, contract review, incident management and evidence collection. That structure gives control owners a shared view of obligations while allowing legal, privacy, security and business teams to work within defined responsibilities.
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 strongest classification programmes do not aim to classify every AI tool perfectly on the first attempt. They establish a disciplined way to make proportionate decisions, record uncertainty and revisit conclusions as use changes. That is how AI governance becomes a managed enterprise capability rather than a static register of good intentions.