A team that has just learned its hiring tool or credit model counts as high-risk usually reaches for a policy document. That is the wrong instinct. The heavy requirements of the high-risk tier are not things you write around a finished system - they are properties the system itself has to be built to have, and to demonstrate, before it goes to market.
If you have already worked out that a system is high-risk, the risk tiers decide that - this is what the Act then requires you to build in. The obligations sit across Articles 9 to 15; grouped for sense, they come to seven core requirements, and they are cumulative: a high-risk system must satisfy all of them, not pick among them.
The seven fall into three natural groups: how the system is built and trained, how it can be held to account, and how it performs. Take them in that order.
Building and training the system
A risk-management system that runs for the system's whole life
The first requirement is a continuous risk-management process, not a one-off assessment.
The Act expects known and foreseeable risks to be identified, evaluated and mitigated, and the process to run for as long as the system is in use, because a system's risks change as it meets real-world data it never saw in testing. This is the spine the other six requirements hang from.
Data governance the system can stand behind
High-risk systems are held to standards on the data they are trained, validated and tested on.
The training data has to be relevant and sufficiently representative, and examined for the biases it might carry into the system's outputs. The point is preventive: a high-risk system that discriminates usually does so because the data taught it to, and the Act puts the obligation upstream, at the data, rather than only at the output.
Making the system accountable
Technical documentation that proves the rest
Before a high-risk system goes to market, it must have technical documentation thorough enough to show it meets the Act's requirements.
This is not marketing material or a user guide. It is the evidence file; how the system was designed, what data it used, how it was tested, what its limitations are - that a market surveillance authority can read to check the system is what its provider claims. If the risk management and data governance are the work, the documentation is the proof the work was done.
Logging that makes the system auditable
A high-risk system has to keep records of its own operation.
Automatically generated logs let the system's behaviour be traced and audited after the fact, which is what makes it possible to investigate when something goes wrong, and to demonstrate the system was operating as intended when it did not. A system that cannot show what it did is a system no one can hold to account, and the Act treats traceability as a built-in property, not an optional add-on.
Transparency the deployer can actually act on
High-risk systems must come with instructions clear enough that the organisation deploying them can use them correctly and safely.
This is a different transparency from the "tell people they're talking to AI" duty on lighter systems. Here it points at the deployer: they have to be given enough about the system's capabilities, limitations and intended purpose to operate it without misusing it. A high-risk system shipped as a black box, with no honest account of what it can and cannot do, fails this requirement however well it performs.
Human oversight designed into the system
The Act requires that high-risk systems be built so that a person can meaningfully oversee them.
This is a design duty: the system has to be capable of being understood, monitored and, where necessary, overridden or stopped by a human. It is not satisfied by a person nominally in the loop who has neither the information nor the authority to intervene. Oversight has to be possible by design before it can be meaningful in practice, and building a system that resists human intervention fails the requirement at the root.
How the system performs
Accuracy, robustness and security as stated properties
Finally, a high-risk system has to perform to an appropriate level of accuracy, be robust against errors and inconsistencies, and be resilient against attempts to manipulate it.
The Act expects these levels to be declared and to hold up in real conditions, including against people actively trying to make the system fail. For a high-risk system, "it usually works" is not a specification; the Act asks for stated, defensible performance and security properties.
The step that ties them together: conformity assessment
Building the seven in is the work. Proving they are built in is a separate, mandatory step. Before a high-risk system is placed on the market, it has to go through a conformity assessment, the procedure by which the provider demonstrates the system meets all of the above.
For a large share of high-risk AI this is a self-assessment against the requirements, though some categories require an independent body. Either way, the system cannot lawfully go to market until the assessment is done and the system is registered.
This is why the high-risk requirements are best understood as engineering constraints, not paperwork. Each of the seven is something the system has to be, and conformity assessment is the gate that checks it is, before the system reaches a single user.
Where this leaves a provider
The honest summary is that high-risk classification turns a product decision into a build specification. The seven requirements are not a compliance layer applied on top of a finished system; they shape how it is designed, trained, documented and tested from the start.
A team that discovers late that its system is high-risk often finds the hardest part is not writing policies but retrofitting properties - representative data, traceable logs, designed-in oversight, that are far cheaper to build in than to bolt on.
There is an honest limit worth naming, and it changes who this really matters to. Most organisations are not providers building high-risk systems from scratch; they are deployers putting someone else's system to use.
For them the practical question is not "how do I build these seven in" but "has my vendor actually built them, and how would I know", and the answer is often that you are trusting a conformity assessment you cannot fully see behind.
That is the deeper lesson of the high-risk tier. The Act tells providers what a system has to be before it can exist in the market, and it leaves deployers needing to know those same requirements well enough to tell whether what they have bought actually meets them.
Frequently asked questions
What are the requirements for high-risk AI under the EU AI Act?
Montro's summary is seven core requirements a high-risk system must be built to meet: a lifecycle risk-management system, data governance, technical documentation, record-keeping and logging, transparency to the deployer, human oversight designed into the system, and appropriate accuracy, robustness and security.
On top of these, the system must pass a conformity assessment and be registered before it goes to market. The requirements are cumulative, a high-risk system has to satisfy all of them.
Does a high-risk AI system need a conformity assessment?
Yes. Before a high-risk AI system can be placed on the EU market, its provider must carry out a conformity assessment demonstrating the system meets the Act's requirements.
For many high-risk systems this is a self-assessment against the requirements, while certain categories require an independent notified body. The system also has to be registered, and it cannot lawfully go to market until these steps are complete.
What does human oversight require under the EU AI Act?
For providers, human oversight is a design requirement: the high-risk system has to be built so that a person can understand, monitor and, where needed, override or stop it.
It is not met by a person nominally approving outputs without the information or authority to challenge them. The provider builds the capacity for oversight into the system; the deployer is then responsible for exercising it in operation, two connected but distinct duties.
Is meeting the high-risk requirements a one-time task?
No. Several of the requirements are ongoing by design - the risk-management system runs across the whole lifecycle, logging is continuous, and accuracy and robustness have to hold up in real conditions, not just at launch. A high-risk system is not certified once and forgotten; it has to keep meeting the requirements as it operates and as the world it operates changes.
