The EU AI Act and High-Risk AI Systems: What You Actually Have to Do
The first time I read the EU AI Act properly, the thing that struck me was how Belgian it is in spirit. No drama, no ban on the technology, just a sober question repeated for every system: how much harm can this thing do, and have you done the work to match. The whole law is built on that one idea, risk tiers, and almost everything practical hangs off where your system lands.
The four tiers, in plain language
| Tier | What it covers | What you must do |
|---|---|---|
| Unacceptable | Social scoring, manipulative systems | Not allowed. Do not build it. |
| High-risk | AI in hiring, credit, healthcare, critical infrastructure, and similar | The heavy obligations live here |
| Limited risk | Chatbots, systems people interact with | Mainly transparency: tell people it is AI |
| Minimal risk | Spam filters, game AI, the vast majority | Essentially free to use |
Most of your systems are minimal or limited risk and need very little. The Act is not trying to drown you. It is trying to make sure that the small number of systems that decide who gets a job, a loan, or a diagnosis are built with care. That is a reasonable ask, and frankly it is what a good engineer would do anyway.
The misclassification trap is the one to watch. Teams mark a system minimal-risk because nobody on the call wanted the high-risk workload. A hiring screener is high-risk whether you label it that or not. The tier sorts itself on what the system does, not on what you wish it did. Be honest at this step, because every downstream control hangs off it.
What “high-risk” actually requires
If a system lands in the high-risk tier, the Act asks for a recognisable set of things. Stripped of the legal language, they are the habits of a serious engineering team:
- A risk management system. You have to actually do risk management, not just claim it. The risk register is a live document, reviewed on a cadence, not a one-off artifact.
- Data governance. Training and input data has to be relevant, representative, and documented. Garbage in is now a legal problem, not just a quality one. The lineage matters: where did the training data come from, who consented, what was excluded.
- Technical documentation. You can explain how the system works and why. Architecture, design decisions, training process, evaluation results, known limitations. The bar is “another engineer could understand it cold.”
- Record-keeping (logging). The system keeps an audit trail by design. Inputs, outputs, decisions, overrides, retained for the period the law requires. Logging-on-request is not the same as logging-by-default; the law assumes the latter.
- Transparency to users. The people relying on the output know what it is and what its limits are. The recruiter using a screening tool knows it screens, knows what it weighs, and knows it can be wrong.
- Human oversight. A person can understand, override, and stop it. Not a committee, a person. With authority and a working override that does not require an engineer to ship a code change.
- Accuracy, robustness, and security. It works, it holds up under stress, and it resists tampering. This is where AI security (prompt injection, adversarial inputs, model supply chain) lives.
Read that list again. There is nothing exotic in it. It is the difference between a demo and a product. The Act is essentially legislating the move from “it works on my laptop” to “it works in the world, and I can prove it.”
Who is actually on the hook: provider vs deployer
The single most common scoping mistake I see is teams thinking the Act is only the problem of the company that built the AI. It is not. The Act splits obligations between the provider (whoever puts the system on the market) and the deployer (whoever actually uses it in their workflow). Both carry duties; they are different duties.
If you bought a hiring screener from a vendor and use it to filter candidates, you are the deployer. You owe the human oversight, the transparency to the people being screened, the operational record-keeping, and the responsibility for the way you configured and used it. The provider owes the model documentation, the conformity assessment, and the post-market monitoring. Neither of you can point at the other. The regulator can have a conversation with both.
That distinction reshapes vendor contracts. The deployer needs to extract enough information from the provider to discharge the deployer’s own duties: model cards, training-data summaries, known limitations, monitoring commitments. If the contract does not give you that, the contract is the gap.
How to start without panicking
You do not need a consultancy and a year. You need three honest steps:
- Inventory and classify. List your AI systems, including the Shadow AI nobody logged, and sort them into the four tiers. This alone tells you where the work is. Most teams discover their high-risk list is shorter than they feared.
- Gap-check the high-risk few. For each high-risk system, walk the seven requirements above and mark what you already do versus what is missing. The honest gaps are usually logging and human oversight. Mark also the provider/deployer split for each, so you know which obligations are yours.
- Build the controls, then document. Put the checkpoint and the audit log into the system, then write the technical documentation to describe what is actually there. The order matters; documentation that precedes the controls is fiction.
That is the whole game for most organisations. The companies that get hurt are the ones treating a high-risk system like a minimal-risk one, not the ones who are a few documents short.
