What is a High-Risk AI System?
The EU AI Act does not regulate AI by how capable it is. It regulates AI by what it is used for, and it concentrates most of its weight on a single category: the high-risk AI system. Understanding that category is the closest thing there is to understanding the Act.
A law of tiers, not models
The Act sorts uses of AI into tiers. At the top sits a short list of practices judged unacceptable and prohibited outright, such as certain forms of social scoring and manipulation. At the bottom sits the vast majority of AI uses, which attract no new obligations at all. In between are two working tiers: systems with transparency duties (a chatbot must not pretend to be a person) and the tier that carries nearly all of the law’s substance, high risk. A high-risk system is not a banned system. It is a permitted system whose use touches something the law considers too important to leave ungoverned.
What lands in the high-risk tier
Two routes lead in. The first covers AI acting as a safety component of products already regulated in EU law, such as machinery or medical devices. The second, and the one that matters for services businesses, is a list of use cases in Annex III: areas such as education, access to essential services, and, pointedly, employment and the management of workers. That employment entry covers AI used to recruit and select people (placing targeted job advertising, screening and filtering applications, evaluating candidates) and AI used in decisions about promotion, termination, task allocation and the monitoring or evaluation of performance and behaviour. For a people business (recruitment, staffing, outsourcing), that is not a corner case; it is a description of the core workflow. High risk is not an accusation. It is the law’s way of saying that the decision this system touches (a livelihood, a loan, a place at a school) matters enough to be governed.
What the designation triggers
Classification as high risk pulls in a family of obligations that read less like paperwork and more like an engineering and operating standard. Conceptually: a risk management system, meaning risks are identified, mitigated and revisited across the system’s life rather than assessed once at purchase. Data governance, meaning the data the system was trained and tested on is relevant, representative and examined for bias. Logging and record-keeping, meaning the system’s operation leaves a trace from which outcomes can be reconstructed and audited. Transparency towards the organisation deploying it, so its people understand what the system can and cannot do. And human oversight: people with the competence and authority to intervene, override and stop it, plus accuracy, robustness and security appropriate to the stakes. The obligations divide between the provider who builds the system and the organisation that deploys it, and they phase in over several years. The detail is for lawyers, and this entry is educational context, not legal advice. The direction is not: if your AI touches a listed decision, you are expected to run it like something that matters.
One concrete example
Clearly illustrative, with no customer implied. An outsourcing firm uses a model to rank incoming applications for its client programmes, so recruiters read the most promising first. Treated casually, that is a productivity feature. Treated honestly, it is candidate evaluation, squarely within the employment entry of Annex III. The high-risk lens changes the questions the firm asks its vendor and itself. What data was the ranking model trained on, and would it score last year’s best hires highly? What does the log record when a candidate is ranked down? Who reviews the ranking before a rejection becomes final, and can that reviewer see why the model ranked as it did? None of those questions makes the tool illegal. All of them make it governable.
High-risk systems and decision intelligence
Read as a list, the high-risk obligations are familiar to anyone who has thought seriously about decision quality: know the quality of your evidence, keep a trace of how the conclusion was reached, put a competent human in a position to disagree, and check outcomes against expectations. That is the vocabulary of the evidence hierarchy, the decision audit trail and human-in-the-loop review. It is also the stance ONX takes with its own platform: candidate matching in Hiring is treated as high risk under the strict reading of Annex III, with human review gates, and AI conclusions are kept explainable and challengeable. A high-risk designation, met properly, does not slow decisions down. It forces them to become decisions you can defend, which is the whole project of decision intelligence.
Common questions
What is a high-risk AI system?
Under the EU AI Act, a high-risk AI system is one whose use falls into a category the law considers consequential enough to need strict governance: either AI acting as a safety component of an already regulated product, or AI used in the use cases listed in Annex III, which include employment and worker management, education, and access to essential services. High risk does not mean prohibited; it means the system is permitted but must meet obligations such as risk management, data governance, logging and human oversight.
Is AI used in hiring always high risk?
AI used to recruit and select people, such as screening or filtering applications and evaluating candidates, sits on the Annex III list, as does AI used in decisions on promotion, termination, task allocation and performance monitoring. The Act contains a narrow carve-out for systems in listed areas that do not materially influence the outcome, such as purely procedural tools, but profiling of people always remains high risk, and the assessment must be documented. This is educational context, not legal advice.
What obligations come with a high-risk classification?
Conceptually: a risk management process that runs across the system’s life, governance of training and testing data including examination for bias, logging so outcomes can be reconstructed, transparency to the deploying organisation about capabilities and limits, human oversight by people with the competence and authority to intervene and override, and accuracy, robustness and security appropriate to the stakes.
Who is responsible for a high-risk system, the vendor or the business using it?
Both, differently. The provider who builds the system and places it on the market carries the design-side obligations: risk management, data governance, documentation, logging capability, and building for effective oversight. The deployer, the organisation using it, must use the system as intended, assign competent human oversight, keep logs and monitor its operation. Buying a compliant tool does not discharge the deployer’s duties; using it well is part of the law’s design.