What is AI system classification?
AI regulation: concepts, institutions and standards
AI system classification is the process of sorting an AI system into meaningful categories so people can decide which rules, controls and review steps apply. Those categories can relate to whether a tool is an AI system at all, what task it performs, how much autonomy it has, where it is used, and whether that use creates elevated legal or governance risk. In practice, classification connects technical description to accountability, documentation and oversight.
What this means
People often talk about "classifying AI" as if there were one universal list. There is not. In practice, classification usually answers several different questions at once: is this software an AI system for the purpose of a given law or framework; what kind of task does it perform; how much freedom does it have to act; and how sensitive is the context in which it is used.
That is why the same underlying model can sit in different classes in different settings. A large language model used for internal drafting may mainly raise general governance or transparency questions. A system built on the same model to screen job applicants, support credit decisions or operate machinery may move into a stricter class because the use, not just the model, changes.
So AI system classification is best understood as a layered exercise. It combines function, context, autonomy and risk. It is not just a technical taxonomy, and it is not just a legal label.
Why it matters
Classification matters because most AI governance starts with scope and triage. If an organisation classifies a system too loosely, it can miss legal duties, overlook affected people, under-design human oversight and buy tools on the wrong contractual assumptions. If it classifies too broadly, it can over-control low-stakes uses, slow adoption and blur who is accountable for what.
In practical terms, classification shapes AI inventories, procurement questionnaires, deployment approvals, staff training, technical documentation, user notices, monitoring plans and board reporting. It also helps organisations separate model-level issues from system-level use, which is increasingly important where general-purpose models are reused across many products and sectors.
How it works
<strong>It starts with scope</strong>
Before anyone assigns a risk tier, they need to know whether the relevant law or framework even treats the software as an AI system. That first step sounds basic, but it is often the hardest. The OECD's updated definition centres on a machine-based system that infers from input to generate predictions, content, recommendations or decisions, while also recognising different levels of autonomy and adaptiveness after deployment. In the EU, the Commission has issued non-binding guidance to help providers and deployers decide whether a software system meets the AI Act definition. So the first classification question is not "how risky is it?" but "what exactly is in scope here?"
<strong>Then it describes what the system does</strong>
Once the system is in scope, good classification describes it in technical and operational terms before jumping to legal labels. The OECD Framework for the Classification of AI Systems is useful here because it does not collapse everything into one country's legal buckets. It looks across the system's people and planet effects, economic context, data and input, AI model, and task and output. That means teams can describe whether a system is doing recognition, personalisation, forecasting, optimisation, content generation or another task, and whether it relies on machine learning, knowledge-based methods or mixed approaches.
NIST uses a similar idea in a governance form. The AI RMF allows organisations to create use-case profiles and cross-sectoral profiles so they can classify systems in ways that support risk management. NIST gives examples such as hiring and fair housing profiles, and it separately provides a generative AI profile for technology that appears across sectors. The practical point is simple: classification should first tell people what the system is and how it works, not only whether it is allowed.
<strong>Context changes the class</strong>
A model in the abstract is rarely enough. Regulators and standards bodies repeatedly stress intended purpose, deployment setting, users, affected people and surrounding law. NIST's MAP function says organisations should document intended purposes, beneficial uses, context-specific laws, norms, expectations and the settings in which the system will be deployed. The OECD classification framework is also built for systems in a specific project and context, not only for lab-stage descriptions.
This matters because risk often comes from the setting rather than the model family. A recommendation engine inside a music app does not raise the same governance questions as a recommendation system used in lending, insurance or public services. A chatbot used for internal drafting is not the same thing as a chatbot used to communicate with customers about rights, safety or eligibility. Classification therefore has to be tied to the job the system is doing in the real world.
<strong>Autonomy and human control matter</strong>
Another core axis is autonomy. The OECD framework distinguishes between systems that cannot act on their own recommendations, systems that require human agreement, systems that act unless a human vetoes them, and systems that act without human involvement. That is a more useful question than the loose claim that a human is "in the loop". It asks what authority the system has, when the human intervenes, and whether intervention is meaningful.
This is where many governance mistakes happen. Teams often describe a system as low concern because someone can, in theory, override it. But if the person responsible lacks time, training or real power to change the result, the practical autonomy of the system may still be high. Classification should therefore capture the actual level of delegated action, not just a policy statement about oversight.
<strong>Risk tiers attach legal effects</strong>
In standards and governance frameworks, classification is often descriptive. It helps organisations gather the right evidence and choose the right review path. In binding law, classification can carry direct legal consequences. The EU AI Act is the clearest current example. It uses a risk-based structure that includes prohibited practices, high-risk AI systems, systems subject to transparency duties, and separate obligations for general-purpose AI models. High-risk status can arise through two main routes: the AI system is embedded in certain regulated products, or it is used in one of a set of sensitive contexts listed by the Act.
The important point is that legal risk classes are not universal labels for all governance work. They are jurisdiction-specific tools built for specific policy goals. A strong classification method should therefore be able to translate between descriptive categories, such as function or autonomy, and legal categories, such as high-risk or prohibited, without confusing the two.
<strong>Model-level and system-level classes can differ</strong>
Modern AI regulation increasingly separates the model layer from the system layer. This is especially important for general-purpose and generative technology. One organisation may provide a model that can be adapted across many downstream products. Another may integrate that model into a hiring system, a search tool, a drafting assistant or a medical product. Those are not the same compliance object.
For leaders, this means one inventory entry is often not enough. You may need to record at least three related things: the model, the downstream system, and the use case. Model-level duties may concern documentation, testing or training data transparency. System-level duties may concern intended purpose, instructions for use, human oversight, user notices or conformity checks. Classification fails when these layers are merged into one vague label.
<strong>Classification is maintained across the lifecycle</strong>
Classification is not a one-off workshop exercise. The OECD notes that a system's classification may change as it evolves, takes on new data, is deployed more widely, matures technically or gains new capabilities. NIST makes the same practical point by supporting current and target profiles that can be reviewed over time. In other words, a system can move across classes even if its original model family stays the same.
Operationally, that means organisations should treat classification as living governance evidence. A sound record usually includes the intended purpose, users, affected groups, sector, data sources, task type, degree of action autonomy, human review design, applicable jurisdictions and the reason the chosen class was selected. Review should be triggered by changes such as retraining, broader rollout, stronger tool access, new integrations, entry into a regulated sector or a move from advice to action.
Examples
Recruitment screening. An organisation buys software to rank, filter or prioritise job applicants. NIST treats hiring as a useful example of a use-case profile, which means the system should be classified in its employment setting rather than treated as a generic model. In the EU framework, employment is one of the sensitive areas associated with high-risk classification. In practice, that pushes the organisation to record intended purpose, staff competence, human oversight and deployment conditions before use.
Customer-facing chatbot. A company launches a large-language-model assistant on its website. From a standards perspective, this fits a generative or cross-sectoral technical profile because similar systems appear across many sectors. Under the EU AI Act's transparency logic, interactive systems and certain AI-generated or AI-manipulated content can trigger disclosure duties. The key classification question is therefore not only "does it use an LLM?" but also "how does it interact with people, what does it publish, and what is the user expected to understand from it?"
AI embedded in regulated machinery. A provider integrates AI into robotics or industrial equipment that already sits inside a product safety regime. In the EU, that can place the AI in a high-risk route tied to regulated products, even if the same broad technical methods would look lower concern in a different setting. Here the classification work has to connect software description, product safety documentation and instructions for use, rather than treating the AI as a standalone feature.
Common misunderstandings
Misunderstanding: AI system classification is just another name for "high-risk AI". Correction: High-risk is only one possible legal class in one regulatory approach. Classification is broader and starts much earlier, with scope, function, context and autonomy.
Misunderstanding: The model type tells you the final class. Correction: Model family is only one layer. The same model can sit inside very different systems with very different legal and governance consequences.
Misunderstanding: "Human in the loop" automatically makes a system low concern. Correction: Human involvement only changes classification if the person has real authority, proper information and enough time to intervene meaningfully.
Misunderstanding: Classification belongs only to engineers or only to lawyers. Correction: It usually needs both, plus product owners, procurement, compliance, risk and domain specialists who understand the real use case.
Misunderstanding: Once classified, always classified. Correction: A system can shift class when its capabilities, data, permissions, user base or deployment context changes.
Risks and boundaries
AI system classification is a front-end governance tool, not a complete compliance programme. It does not replace data protection review, safety engineering, sector-specific supervision, procurement diligence, impact assessment or a conformity assessment where one is legally required. It tells you which path to take next.
It is also easy to misuse. A common failure is to classify the model but ignore the deployment context. Another is to accept a vendor label such as "assistant", "copilot" or "agent" without checking the system's real permissions, affected people, data flows and degree of action autonomy. Those labels may help describe the product, but they do not settle the governance class.
Legal force also varies. OECD and NIST frameworks are influential and highly practical, but they are voluntary. The EU AI Act is binding law, yet some of the Commission material that helps apply it, including guidance on AI system definition and high-risk classification, is interpretive rather than binding. As of June 2026, detailed EU guidance on high-risk classification is still being refined through consultation. Classification also does not decide liability by itself. The OECD is explicit that responsibility and liability remain matters for humans and for each jurisdiction's legal regime.
What to do next
Build one living AI inventory that separates models, systems and use cases. For every entry, capture intended purpose, users, affected people, sector, data sources, task type, action autonomy, human review design, jurisdictions and vendor dependencies. If your records do not show those fields, classification will quickly become guesswork.
Then set a simple internal rulebook. Start with a scope test, then classify by function, context and autonomy, then map the system to any legal risk tiers that apply in the jurisdictions where you build, buy or deploy. Assign an accountable owner, require evidence from vendors rather than marketing labels, and create change triggers for reclassification before updates, integrations or wider rollout go live.
FAQs
Is AI system classification the same as a risk assessment?
No. Classification places a system in the right bucket and determines the right review path. A risk assessment then examines specific harms, likelihood, controls and residual risk inside that class.
What exactly is being classified, the model or the whole system?
Usually the whole system in its deployment context. Some regulatory approaches also attach duties at the model layer, especially for general-purpose models, so it is wise to keep separate records for model, system and use case.
Can the same model support both low-stakes and high-risk uses?
Yes. One model can support internal drafting, customer chat, recruitment screening and regulated products. The class changes with purpose, users, autonomy and sector.
Does using generative AI automatically make a system high-risk?
No. Generative AI is a technical family, not a universal legal tier. Many generative uses mainly raise transparency or general governance questions, while some become more heavily regulated because of their context.
If a human approves the final step, can we treat the system as low concern?
Not automatically. Human review only matters if it is meaningful, informed and able to change the system's effect in practice. Formal sign-off without real control is not enough.
Who should own classification inside an organisation?
One accountable owner should coordinate it, but the work usually needs product, legal, compliance, security, procurement and domain experts. No single team has the whole picture on its own.
When should we reclassify a system?
Revisit classification when the system enters a new sector, uses new data, gains new tool access, affects a different group of people, moves from advice to action, or is deployed in another jurisdiction.
Sources
Explanatory memorandum on the updated OECD definition of an AI system (OECD). The updated OECD definition of an AI system, the role of inference, autonomy and adaptiveness, and the point that the definition does not itself settle liability.
OECD Framework for the Classification of AI systems (OECD). The multi-dimensional logic of classification by people and planet, economic context, data and input, AI model, and task and output, plus lifecycle links and the fact that classification can change over time.
Artificial Intelligence Risk Management Framework (National Institute of Standards and Technology). Context mapping, intended purpose, user and affected-party analysis, and the use of profiles for specific sectors, technologies and end uses.
Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (National Institute of Standards and Technology). Technology-specific, cross-sectoral profiling for generative AI, showing how technical class and deployment context interact.
Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (European Union, EUR-Lex). The binding EU legal categories for AI, including prohibited practices, high-risk systems, transparency duties and general-purpose AI model obligations.
The Commission publishes guidelines on AI system definition to facilitate the first AI Act's rules application (European Commission). Practical, non-binding guidance on whether a software system qualifies as an AI system under the AI Act.
Guidelines for providers and deployers of AI high-risk systems (European Commission). The current Commission interpretation of how high-risk classification works, the two EU routes into high-risk status, practical examples, and the fact that guidance is non-binding and still evolving.
Guidelines and Code of Practice on transparent AI systems (European Commission). System-level transparency duties for interactive AI, AI-generated or AI-manipulated content, emotion recognition or biometric categorisation, and deep fake disclosures.