On 19 May 2026, the European Commission published draft guidelines on the classification of high-risk AI systems under the AI Act. The publication comes at a time when many businesses are seeking a quick answer: does our tool fall within its scope or not? The document offers examples and a method. It does not replace the classification process.
That is probably its most useful contribution. The tool alone is not enough to determine the level of risk. The same language model can help rephrase an internal note, assist a recruiter or contribute to access to an essential service. In these three cases, the data, the people affected and the scope of the decision are not the same. Expecting a provider to supply a general label amounts to asking it to classify a use that it cannot always see.
The Commission guidelines, published today, are intended for providers, deployers and market surveillance authorities. They reiterate the two routes set out in Article 6: a system may be classified as high-risk because it is a product, or a safety component of a product, covered by the Union harmonisation legislation listed in Annex I and subject to third-party conformity assessment; it may also fall into one of the cases in Annex III. The Commission specifies that its examples are not exhaustive and may evolve.
Classification starts with the intended purpose, not the product name
A useful map therefore cannot be limited to a list of licences and vendor names. For each system, it must describe what the organization actually does with it: which decision or work step it influences, who receives the result, which people may be affected, what data goes in, and what action follows the output produced.
This description may seem elementary. Yet it becomes decisive when a tool is integrated into a process. An assistant that summarizes applications to help a recruiter does not occupy the same position as a system that ranks, filters or evaluates candidates. A summarization feature can become a decision-making component if its output is used without oversight to reject applications. The apparent quality of the text reveals nothing about this shift.
Regulation (EU) 2024/1689 defines the legal framework and lists, in Annex III, areas such as biometrics, critical infrastructure, education and vocational training, employment and worker management, and access to certain essential services. The fact that a system is used in a sensitive area does not remove the need to examine the precise conditions of Article 6. Above all, it rules out the shortcut of declaring that a productivity tool is inherently irrelevant.
For a business, the first concrete decision is to appoint the person responsible for keeping this map up to date. Uses do not remain fixed. An assistant installed for drafting may later be given access to an HR database; a workflow designed to pre-screen requests may begin rejecting them automatically; a team may add a local rule that changes the intended purpose of the product it purchased. Risk shifts with integration, often faster than the contractual documentation.
The deployer's role cannot be delegated to the provider
The guidelines explicitly address deployers, a point that should be read without alarmism. Purchasing a system does not make every business its manufacturer. However, the organization using it must understand its role within the framework and verify that its practices comply with the intended conditions of use. The provider can supply instructions and technical information; it cannot decide on behalf of the business function how the tool will be used or organize oversight within the business.
This distinction changes the discussion with a vendor. Rather than asking “are you compliant with the AI Act?”, it is more useful to ask: what intended purpose have you declared for this feature? What restrictions do you place on its use? What information, logs and oversight instructions do you provide? What happens when we configure the tool for another purpose or connect it to an automated decision? The answers must be suitable for inclusion in the classification file, not merely in a sales presentation.
The Commission's page on the European regulatory framework notes that the AI Act applies according to a phased timeline. This phased approach does not make mapping optional. It provides time to do what businesses are often inclined to postpone: identify uses already in production, reconcile contracts with actual practices, and establish controls before a tool influences a right, access to a service or a sensitive decision.
The right deliverable is verifiable reasoning
The draft guidelines replace neither the Regulation nor, ultimately, its interpretation by authorities and courts. They do, however, provide a valuable test: can we explain why a system does or does not fall into a category based on its intended purpose and how it functions? A simple “high-risk: no” field in a spreadsheet is not enough. The supporting evidence must be retained and reviewed whenever the use changes.
For a system that assists a decision, the data used, the person who retains control, the expected errors, the escalation cases and the available audit trails must be specified. Agents connected to business tools require particular attention: a textual response becomes an operation when it can create, modify or transmit information. Classification and governance must not wait until this capability is already active.
The skills of the teams are also part of the classification file. Understanding that a tool includes an AI feature is not enough; the people using it must know its authorized purpose, when oversight is required and whom to alert if the scope changes. AI training tied to use cases is more valuable than isolated awareness training because it enables drift to be detected as it occurs.
The news of 19 May therefore does not provide an automatic answer to the high-risk question. It usefully reframes the question: what use have we actually built, and can we demonstrate its limits? It is a methodological obligation before it is a matter of labelling.