Risk Classification

What Risk Classification is

Risk classification is sorting each AI use case by what happens if it goes wrong. The site’s definition adds the questions that do the sorting: who is affected, and whether the use touches personal data, a regulated decision or client-facing output that nobody checks.

The aim is a policy that is proportionate. A business that has classified its AI use can give a drafting assistant a light review and give a system that screens job applications a named checkpoint that is actually staffed. Without classification, both get the same rule, and the same rule is wrong for at least one of them.

This page explains the term as this business meets it, in audits and in training. It is not legal advice. The site says of its own audits that they are a diagnostic and not a legal opinion, and no page here replaces a qualified lawyer.

Why a blanket rule fails

Once a business knows what AI is in use, the temptation is to write one rule that covers all of it, either approving everything or blocking everything. The governance article says both produce a policy nobody follows. A rule that approves everything is too permissive to mean anything. A rule that blocks everything is too restrictive for the work that genuinely needs the tool, and people route around it.

The article’s alternative is a narrower question put to each use case: what happens if this goes wrong, who is affected, and does it touch personal data, a regulated decision, or a client-facing output nobody checks before it goes out.

A tool used to draft an internal summary carries a different exposure from one used to screen a job application or generate content a client will see unreviewed. Treating a drafting assistant and a decision-making system as the same problem is the mistake classification exists to prevent.

The three levels

The governance article sets out three levels, and the site’s governance page repeats them.

Low. An internal draft or summary. It moves fast with a light review, and no named checkpoint is required.

Medium. Content a client sees, or output shared outside the team, unreviewed. It needs a checked step before it goes out.

High. A hiring decision, a regulated communication or a client deliverable. It needs a named human checkpoint, and the checkpoint has to be actually staffed.

The levels are not a scoring system with a pass mark. They are a way of deciding how much attention a use case deserves. The same tool can sit at different levels for different uses, because the level follows what the tool is being used for.

Classification needs a person and a checkpoint

The article is clear that a classification on its own does nothing. It only works when it is attached to a specific person and a specific checkpoint. A rule that says a person should check the output is not a control, it is a hope. Oversight has to name who checks, at what stage and against what standard, before the result reaches a client, a decision or a public output.

Part of what makes a checkpoint effective is basic literacy. The article says that knowing a large language model can produce a confident hallucination in exactly the same tone as a correct answer is what lets a reviewer catch a wrong result and not approve it on confidence alone.

This matters most for the highest-exposure uses. A low-risk internal draft can reasonably move fast. A use case that touches a hiring decision or a client deliverable needs a defined human checkpoint that is actually used under deadline pressure, not one that exists only on paper. The article adds that the same oversight question gets harder once an AI agent runs unattended, so a checkpoint has to reach past chatbots to anything acting on an organisation’s systems without a person in the loop. The human in the loop page covers what the checkpoint has to be.

The checkpoint is only as real as the person accountable for it. That is the ownership gap, and the AI ownership page covers the named person for each tool.

Start from an Inventory

Classification is the second step, not the first. The governance article puts an inventory before it, because a policy built on a guess gets rewritten within a month. The AI tool inventory page covers the list: every AI tool in use, who uses it, what for and on what kind of data, including the tools nobody approved.

The article explains why the list matters with its own figures. It reports an estimate that 77% of small businesses using AI have no written AI policy at all. It reports surveys in which 81% of employees and 88% of security leaders say they use unapproved AI tools at work, and in which 60% of security leaders lacked confidence they could identify the unapproved tools already running in their own environment. A classification built only on the approved tools would classify a shrinking share of real use.

This is the shadow AI problem. The article calls the inventory what turns an open-ended worry into a specific, closeable list. Classification then sorts that list.

The EU AI Act applies by use

The Act is the second reason to classify. The governance article says it draws its line at what the AI is used for, not at the size of the organisation. A small organisation deploying AI for a use case the Act classifies as high-risk carries the same core obligations as a large one running the same use case.

The audit article says the Act’s own risk tiers run on the same logic as the three levels above, from minimal risk through to the uses it treats as high-risk or bans outright. An audit maps each process in scope against that same scale and does not invent its own.

Most day-to-day use sits outside the high-risk category. The article’s examples are drafting, summarising and internal search. But the only way to know which use case is which is to classify each one against the Act, and not to treat small size as an exemption. Any use that touches personal data also carries GDPR obligations, and the article says both are checked at the same point in the process and not as a separate review added afterwards.

What the Act treats as High-Risk

The clearest example on the site is recruitment. The HR training article reports that the Act classifies systems used for recruitment and candidate evaluation as high-risk, covering job-advert targeting, CV filtering and candidate scoring. It also covers systems that decide promotion, termination or task allocation, and performance monitoring once someone is employed.

That classification puts a documentation and risk-management obligation on the system, whichever supplier or platform runs it. The high-risk AI system page covers the category, and the deployer page covers the role a business takes on when it uses one.

The governance article adds that the heaviest obligations generally sit with the vendor that develops a high-risk system and not with the small business deploying an existing one. It also says the vendor handling compliance is not itself a defensible answer, because a deployer still carries oversight duties of its own. Classifying a use is how a business finds out whether it is in that position at all.

Dates and the Small mid-cap route

The governance article reports that the compliance deadline for stand-alone high-risk systems under Annex III moved from 2 August 2026 to 2 December 2027. Product-embedded high-risk systems under Annex I were given a separate extension to August 2028.

It also reports that a simplified compliance framework was extended to qualifying small mid-cap companies, defined as organisations with fewer than 750 employees and either 150 million euro or less in annual turnover or 129 million euro or less in total assets.

The article’s reading is that the extension buys time and eases paperwork, and that it does not remove the requirement to classify a use case correctly and manage the risk it carries. Dates move, so a business should confirm the current position with its own adviser.

Depth of check follows the class

The audit page puts the practical result plainly. The depth of the risk check is set by what each process actually touches, not by a template built for a much larger business. A process that only speeds up drafting, with a person checking the output before it goes anywhere, needs a light check. A process that talks to a customer directly, or feeds a decision about a person such as a hiring shortlist or a pricing offer, needs a fuller one.

The article says a business running two or three customer-facing processes gets a risk section built around those two or three, not a policy copied from elsewhere. That is classification at work: the effort goes where the exposure is.

The same sorting appears at the level of a single workflow step in the delegation ladder. The ladder decides how much authority AI is given over a step. Classification decides how much attention a whole use case needs.

A worked example

This is an illustration, not a real client. A small business runs through its inventory and finds four uses. A team uses an assistant to draft internal meeting notes. Another drafts replies to customer enquiries, and a person reads each one before it goes. A third tool summarises client contracts for a manager. The fourth ranks incoming CVs for a hiring manager.

The meeting notes are low. The customer replies are medium: a client sees them, so they need a checked step, and the person reading each one is that step. The contract summaries are medium to high depending on how they are used, so the business decides they are spot-checked against the original. The CV ranking is high. It is a recruitment use, so it falls in the class the HR article describes, it gets a named owner with authority to pause it, a staffed checkpoint and a check under GDPR. Four uses, four different treatments, and one policy that says which is which.

Keeping it Current

The governance article says the organisations that keep their governance current do not treat it as a one-off. They run it as a process that gets rerun as usage changes, the same way an operational audit gets rerun and not filed and forgotten. The sequence is map what is happening, document it, identify and classify the risk in each use case, test a proposed rule against the highest-risk use, then build the oversight and ownership that keeps it working.

The article describes this as the same five-step audit method, Map, Document, Identify, Test or Prototype, and Build and Scale, applied to governance. A classification made once goes stale as new tools and new features arrive, so it needs a review date and an owner.

The ban article makes a related point from the staff side. It says a rule drawn by kind of data, together with an approved tool, does more than a blanket prohibition. That is classification in its simplest form: the rule follows the data and the use, not the tool name.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is writing one rule for everything. The second is classifying by the tool and not by the use, when the same tool can sit at different levels. The third is assuming a small business is outside the Act because of its size. The fourth is treating a classification as finished once it is written, when a use that was low last quarter may now touch a client or a person.

How we use it

The audit maps what is actually in use across the teams in scope and classifies each use against the rules that apply. That is the inventory and the sort described above, done across every function and not just one. See the AI governance article for the three levels and the Act timeline, and what an AI audit actually checks for how deep each check goes.

If you want every use in your business mapped and classified, a discovery call is where it starts. No audit substitutes for advice from a qualified lawyer on what applies to your organisation.

Sources

• AI governance for small and mid-sized businesses: the three levels, the question put to each use, the checkpoint, the Act by use, the dates and the shadow AI figures.
• What an AI audit actually checks and AI audit: depth of check set by what a process touches, and the Act’s risk tiers.
• AI training for HR teams: what should it cover?: recruitment and candidate-evaluation systems as high-risk.
• Why banning AI tools at work does not work: a rule drawn by kind of data with an approved tool.
• High-risk AI system, EU AI Act and deployer: the category, the regulation and the role.