High Risk AI System

What a High-Risk AI System is

A high-risk AI system is a system in the EU AI Act’s higher risk classification. The Act sorts AI by the risk a use carries, and this is the class that carries the heaviest obligations short of an outright ban. A system in it needs a risk management process and documentation, and those needs attach to the system and its risk, not to where it is hosted.

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. The wider regulation is on the EU AI Act page.

Where it sits on the Risk scale

The site’s article on what an AI audit checks describes the Act’s own tiers as running 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. High-risk is the upper middle of the scale: allowed, but with obligations attached.

The same logic sets the depth of a check. A process that only speeds up drafting, with a person reading the output before it goes anywhere, needs a light one. A process that feeds a decision about a person, such as a hiring shortlist, needs a fuller one.

It is a Classification of a use

The word system can mislead. A high-risk classification is not a label on a product that a vendor prints on the box. It follows what the system is used for. The same underlying tool can sit outside the category for one use and inside it for another.

That is why the site says the classification is something an audit establishes about your own processes and not about your suppliers. A supplier can tell you what its product is built to do. Only you can say what you use it for, and the use decides the class.

The Recruitment example

The clearest case on the site is HR. The HR article reports that the Act classifies systems used for recruitment and candidate evaluation as high-risk. That covers 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.

The classification puts a documentation and risk-management obligation on the system, whichever supplier or platform runs it. The same HR data is also personal data under GDPR, so the two apply side by side to one use case. The HR course takes recruitment AI as its hardest case, and its stated position is that human oversight is the part that can be held responsible.

Size does not exempt a Business

A common assumption is that the Act is written for large enterprises with compliance teams. The governance article says the Act does not draw its line there. It draws it at what the AI is used for. A small organisation using 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, whatever its headcount or turnover.

Most day-to-day use sits outside the 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, and not to treat small size as an exemption. That is why the agentic AI page says classifying each workflow comes before building it.

Who carries which duties

Two roles sit behind most AI use: the vendor that builds a system and the business that deploys it. The governance article says the heaviest obligations, a full risk management system run across a product’s lifecycle, training data that is representative and built-in logging, generally sit with the vendor developing a high-risk system. Most small businesses deploy an existing tool and do not build one.

A deployer still has duties of its own. The ownership article lists them. It must monitor the system for anomalies, dysfunctions and unexpected performance. It must keep the system’s logs for at least six months. It must assign competent people to oversee it. And it must inform the provider and the authorities if there is a serious incident. The vendor handling compliance is not a defensible answer, and a business that buys a tool has not bought its way out of responsibility for how it is used.

Someone has to own it

The oversight duty presumes a person. Monitoring needs someone monitoring, and oversight needs someone assigned. The ownership article makes the point that the owner has to exist before the duty applies, so a business that has not decided who that is will find the deadline arriving without an answer.

The article is careful about scope. Most everyday tools are not high-risk, and the Act does not ask every business to appoint someone for every chat assistant. The duty attaches to the systems that are in the category. The AI governance page covers the wider question of ownership.

The dates, as the site reports them

The governance article reports a change to the timeline. Under the Digital Omnibus agreement, 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.

The same agreement extended a simplified compliance route to qualifying small mid-cap companies, which the article defines 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.

Where it runs does not change it

The site’s reviews return to one point from several sides. Whether a business hosts a model itself, calls one through an API, runs a no-code platform, buys off the shelf or builds a custom workflow, a high-risk system carries the same documentation and oversight requirements. Moving it on-premise does not remove the requirement. It only changes who is directly answerable for the evidence.

The technique underneath does not change the question either. The review of retrieval against fine-tuning says the Act scales its obligations to the risk of the system and not to the technique, so both face the same question: what is the use, and does it fall into a high-risk category? The local model against Claude review and the cloud against on-premise review set out the hosting side.

A link to what should never be delegated

The site’s article on automating a task against automating a decision sets out a ladder of four levels: Assist, Recommend, Execute and Never delegate. It observes that the categories the Act names as high-risk, employment decisions among them, map closely onto the Never delegate rung.

The article treats that overlap as no coincidence. Both the law and the practical test answer the same question: which decisions carry enough consequence and need enough accountability that no amount of model accuracy changes the answer. A business that has sorted its workflows onto the ladder is most of the way to a defensible position on the regulatory question.

A worked example

This is an illustration, not a real client. A small company has two AI uses. One drafts internal meeting summaries, and a person reads each before it is filed. The other reads incoming CVs and produces a ranked shortlist for a hiring manager.

The first sits outside the category and needs a light check. The second is a recruitment use, so it falls in the high-risk class the HR article describes. The company decides who oversees it, keeps its logs and asks what the vendor’s documentation covers, knowing that it still has duties of its own. It also checks the same CV data under GDPR. Both uses might run in the same tool. The use, and not the tool, sets the class.

In an Audit

Every audit assesses the Act at the Identify step, inside the ranking of opportunities and not as a review added at the end. Each candidate is weighed on how often it repeats, what the manual version costs, whether the data exists in a usable state and what regulatory exposure attaches to it. Establishing whether a candidate is high-risk is part of that last question.

The result includes a compliance checklist covering the EU AI Act and GDPR obligations the recommended opportunities carry. The limits are stated on the audit page. An audit identifies and checks against those obligations. It does not certify them. The audit methodology explains the five steps, and the AI audit page states what it does not cover.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is assuming a small business is outside the class because of its size, when the Act draws the line at the use. The second is assuming a hosting choice settles it, in either direction, when the obligations follow the system.

The third is treating a vendor’s assurance as the end of the matter, when a deployer keeps oversight duties of its own. The fourth is treating a delay as a removal. The dates moved and the substance did not. A related slip is treating every AI tool as high-risk, which the site does not say. Most everyday tools are not in the category.

Where it goes wrong

One failure to avoid is classifying too late, when a tool has been built or bought first and someone asks afterwards what the Act says about it. The site’s answer is to classify each use case before building, and to check the Act and GDPR by what a use does and not by the size of the organisation running it.

Another is a step drifting up the ladder. The task-and-decision article warns that a Recommend step can quietly be treated as Execute once a demo looks good, for example a shortlisting step. Catching that at the scoping stage costs an afternoon, and catching it after launch costs a rebuild.

Where it is taught and where it appears in an Audit

The classification runs through the foundational programmes and through the HR course, which takes recruitment AI as its hardest case. The rest sit in the wider training catalogue.

In an audit it appears at the Identify step, beside GDPR, and its output is a line in the compliance checklist. The article on what an AI audit actually checks explains how deep the check goes for a small or mid-sized business.