Recruitment AI became the poster child for the EU AI Act because the stakes are so easy to grasp: an opaque model deciding who gets a job. But recruitment is one item on a much longer list. The Act designates AI as high-risk across a broad sweep of activities — creditworthiness assessment, life and health insurance pricing, medical devices, access to education and exam scoring, dispatch of emergency services, eligibility for public benefits, and more. If your organisation uses AI to make or materially influence decisions about people in any of these areas, the obligations are the same demanding set regardless of sector.
The common misconception is that these rules are a problem for the companies that build AI models. They are not — or rather, not only. The Act places substantial, independent obligations on the organisation that deploys a high-risk system in a real decision, not just the one that developed it. You cannot outsource accountability by buying a model from a vendor. Understanding what a high-risk system must prove, and who has to prove it, is now a core governance question for organisations far beyond the technology sector.
What makes a system high-risk
The Act uses two routes to the high-risk category. The first covers AI that is a safety component of a product already regulated under EU law — medical devices, machinery, vehicles, and similar. The second, and the one that catches most organisations by surprise, is a list of specific use cases in Annex III: biometric identification, critical infrastructure management, education and vocational training, employment and worker management, access to essential private and public services (including creditworthiness and insurance), law enforcement, migration and border control, and administration of justice.
The classification turns on what the system is used for, not how sophisticated it is. A simple statistical model that scores loan applications is high-risk; an enormously complex model used to recommend films is not. This is the point organisations most often miss: high-risk status is about consequences for people, not technical complexity. A modest scoring rule can carry the full weight of the regime while a far more advanced system escapes it entirely, because one touches access to credit and the other touches entertainment.
The obligations every high-risk system must satisfy
Whatever the sector, a high-risk system has to demonstrate a consistent set of properties. These are not aspirational principles; they are documented requirements that must be evidenced before the system goes to market and maintained throughout its life.
A risk management system. The provider must establish a continuous, iterative process to identify and evaluate the risks the system poses to health, safety and fundamental rights, and to adopt measures that address them. This is not a one-time assessment. It runs across the entire lifecycle and must be updated as the system and its context change.
Data governance. Training, validation and testing data must be relevant, sufficiently representative, and — to the best extent possible — free of errors and complete. The Act explicitly requires examination for possible biases that could lead to discrimination. In practice this means an organisation must be able to describe where its data came from, what it represents, who it under-represents, and what was done about it.
Technical documentation. Before a high-risk system is placed on the market, documentation must exist that demonstrates compliance — detailed enough for authorities to assess whether the system meets the requirements. This documentation is not a formality filed and forgotten; it is the evidentiary backbone of the whole regime.
Record-keeping and logging. High-risk systems must technically allow for the automatic recording of events over their lifetime, to a degree appropriate to the intended purpose. Logs support traceability — the ability to reconstruct, after the fact, what the system did and why.
Transparency and instructions for use. The system must be accompanied by clear information enabling deployers to interpret its output and use it appropriately, including its capabilities, its limitations, and the conditions under which it may produce unreliable results.
Human oversight. The system must be designed so that people can effectively oversee it — understanding its output, remaining aware of the tendency to over-rely on it, being able to interpret results correctly, and being able to intervene or halt the system. Oversight designed as a rubber stamp does not satisfy the requirement.
Accuracy, robustness and cybersecurity. The system must perform consistently across its lifecycle and be resilient to errors, faults, and attempts at manipulation. Declared accuracy levels and the metrics used must be stated in the accompanying documentation.
Provider versus deployer: who has to prove what
The single most consequential thing for most organisations to understand is the split between the provider — broadly, the entity that develops the system or has it developed and places it on the market under its own name — and the deployer, the entity that uses it under its own authority in the course of its activities.
Providers carry the heaviest burden: building the risk management system, ensuring data governance, drawing up technical documentation, running the conformity assessment, and affixing the CE marking that declares the system compliant. But deployers are not passive purchasers. They must use the system in accordance with the instructions, ensure that input data is relevant for the intended purpose, monitor operation and inform the provider or authorities of serious incidents and risks, keep the logs the system generates, and — where they make decisions about people — carry out the transparency and, in many cases, fundamental-rights obligations toward those affected.
There is a further trap. A deployer can inadvertently become a provider. If an organisation puts its name or trademark on a high-risk system, makes a substantial modification to one, or changes the intended purpose of a system in a way that brings it into the high-risk category, it takes on the full provider obligations. Buying a general-purpose model and adapting it to score loan applications is precisely the kind of act that can transfer the heavy end of the burden onto the buyer.
What this means in practice
For an organisation deploying AI in any high-risk area, three consequences follow directly.
First, due diligence on vendors becomes non-negotiable. You cannot meet your deployer obligations if the provider cannot furnish the documentation, the declared accuracy metrics, the instructions for use, and the evidence of conformity you are entitled to. A vendor who cannot produce these is not offering a compliant high-risk system, and deploying it exposes you.
Second, internal evidence becomes as important as vendor evidence. Monitoring, logging, human oversight arrangements, and the relevance of your input data are your responsibility, not the provider's. These have to be designed, staffed and documented within your own organisation.
Third, independent assurance stops being optional in spirit even where it is not literally mandated. The obligations describe a system that has been tested for bias, validated for accuracy, documented for traceability, and designed for meaningful oversight. An organisation that cannot show it has actually verified these properties — rather than merely asserting them — is carrying a risk it cannot see.
The bottom line
The EU AI Act is often discussed as a recruitment story because that example is vivid. But the architecture of the law is sectoral only in its list of triggering use cases; the obligations themselves are universal. Credit scoring, insurance pricing, clinical decision support, exam grading, benefits eligibility and emergency dispatch all sit under the same demanding regime, and in every one of them the organisation deploying the system carries real, independent duties it cannot delegate to a vendor.
The organisations that will navigate this well are not the ones with the most advanced models. They are the ones that treat the Act's requirements as an evidence problem — who can show, with documentation and independent testing, that their high-risk systems actually do what the law requires — rather than a paperwork problem to be solved at the last minute.