What a High-Risk System Must Actually Do

Articles 8 to 15 set out the requirements a high-risk AI system must meet. Read separately they look like seven compliance workstreams. Read properly they describe one system built to a standard, and the interlocks between them are what make the set coherent.

A risk management system running continuously across the lifecycle. Data and data governance. Technical documentation. Record-keeping through logging. Transparency and provision of information to deployers. Human oversight. And accuracy, robustness and cybersecurity.

Two framing points before the detail.

These are outcome requirements, not prescribed methods. The Act says a high-risk system must achieve an appropriate level of accuracy; it does not say which metric or what threshold. That is deliberate, and it means the burden of justifying your choices sits with you.

And they apply to the provider. A deployer of a purchased high-risk system does not build these; it relies on the provider having done so, which is why the transparency requirement in Article 13 is the hinge between the two roles.

Article 9 requires a risk management system established, implemented, documented and maintained as a continuous iterative process planned and run throughout the entire lifecycle, requiring regular systematic review and updating.

Continuous and throughout the entire lifecycle is the operative phrase, and it rules out the common pattern of a risk assessment performed once before launch and filed.

The process has a defined shape: identify and analyse the known and reasonably foreseeable risks the system can pose to health, safety or fundamental rights when used in accordance with its intended purpose; estimate and evaluate the risks that may emerge under reasonably foreseeable misuse; evaluate other risks arising from post-market monitoring data; and adopt appropriate targeted risk management measures.

Two elements are routinely underweighted. Reasonably foreseeable misuse means you must consider how the system will be used incorrectly, not only as intended, and predictable off-label use is your problem. And the requirement to consider fundamental rights, not merely health and safety, pulls in discrimination, privacy, and access to services, which sit outside a traditional product safety analysis.

Residual risk that remains after mitigation must be judged acceptable, and where testing is used it must be against prior defined metrics and probabilistic thresholds appropriate to the intended purpose.

Article 10 applies to high-risk systems that use techniques involving the training of models with data, and it is the requirement with the most direct engineering consequences.

Training, validation and testing data sets must be subject to data governance and management practices appropriate to the intended purpose. Those practices cover the design choices behind the data; data collection processes and the origin of the data; relevant data preparation such as annotation, labelling, cleaning, updating, enrichment and aggregation; the formulation of assumptions about what the data is supposed to measure and represent; an assessment of the availability, quantity and suitability of the data sets needed; examination for possible biases likely to affect health and safety, have a negative impact on fundamental rights, or lead to discrimination prohibited under Union law; appropriate measures to detect, prevent and mitigate those biases; and identification of relevant data gaps or shortcomings.

The standard set for the data sets themselves is that they be relevant, sufficiently representative, and to the best extent possible free of errors and complete in view of the intended purpose, with the appropriate statistical properties, including as regards the persons on whom the system is intended to be used.

Data sets must also take account, to the extent required by the intended purpose, of the characteristics or elements particular to the specific geographical, contextual, behavioural or functional setting in which the system will be used.

Article 10 creates a genuine tension with data protection law, and it is worth understanding because it blocked real work.

To demonstrate a system does not discriminate on the basis of ethnicity, you need to measure performance by ethnicity. But ethnicity is special category data under the GDPR, whose processing is prohibited absent a specific condition. So the obligation to detect bias appeared to require processing that data protection law restricted, and cautious organisations resolved it by not measuring, which meant not knowing.

The Act already contained a narrow provision permitting processing of special categories of personal data where strictly necessary for bias detection and correction in high-risk systems, subject to safeguards including technical limits on re-use, pseudonymisation, and restrictions on access.

The 2026 Digital Omnibus went further, clarifying and widening the flexibility to process special category data for bias detection and mitigation.

The practical consequence is that not measuring is no longer defensible on data protection grounds. If your organisation declined to test for performance disparities because the necessary attributes were off limits, that reasoning has been overtaken, and the safeguards, minimisation, access control, and deletion when no longer needed, are the conditions rather than the obstacle.

Article 14 is the requirement most often misread as a process obligation. It is a design obligation on the provider.

High-risk systems must be designed and developed, including with appropriate human-machine interface tools, such that they can be effectively overseen by natural persons during the period in which they are in use.

The oversight measures must enable the person to properly understand the relevant capacities and limitations of the system and to duly monitor its operation, including to detect and address anomalies, dysfunctions and unexpected performance; to remain aware of the possible tendency of automatically relying or over-relying on the output, known as automation bias, in particular where the system produces information or recommendations for a human to decide upon; to correctly interpret the output, taking into account the interpretation tools available; to decide in any particular situation not to use the system or otherwise disregard, override or reverse the output; and to intervene or interrupt the system through a stop button or similar procedure that brings it to a halt in a safe state.

Read as an engineering brief, this is a list of product features: surfacing confidence and limitations in the interface, exposing what drove an output, making disregard a first-class action rather than an exception, and a working stop control.

A system delivered as an opaque score with no interface affordances for any of that has not met Article 14, whatever the deployer's process document says.

Article 15 requires that high-risk systems be designed and developed to achieve an appropriate level of accuracy, robustness and cybersecurity, and to perform consistently in those respects throughout their lifecycle.

Accuracy is not given a threshold, deliberately. What the Act requires instead is that the levels of accuracy and the relevant accuracy metrics be declared in the accompanying instructions for use. So the obligation is to choose a metric appropriate to the purpose, measure against it honestly, and publish the result to the deployer. Selecting a flattering metric and stating it is a weaker position than it looks, because the metric's appropriateness is itself assessable.

Robustness concerns resilience to errors, faults and inconsistencies that may occur within the system or its environment, including interaction with natural persons or other systems. Technical redundancy solutions such as backup or fail-safe plans are named as one route.

For systems that continue to learn after being placed on the market, there is a specific requirement: they must be developed to eliminate or reduce as far as possible the risk of possibly biased outputs influencing input for future operations, the feedback loop problem, with appropriate mitigation measures.

Cybersecurity covers resilience against attempts to alter use, outputs or performance by exploiting vulnerabilities, and the Act names AI-specific attacks: data poisoning, model poisoning, adversarial examples designed to cause a model to make a mistake, model evasion, and confidentiality attacks.

The seven are not parallel workstreams. They form a loop, and treating them as independent is why compliance programmes produce documents that contradict each other.

Risk management identifies what could go wrong, which determines what the data governance work has to examine and what accuracy and robustness targets are appropriate.

Data governance and the accuracy work produce measured results, including performance across subgroups.

Those results are what the technical documentation records and what the instructions for use declare to the deployer.

Human oversight is designed against the specific limitations those measurements revealed, which is why oversight designed before measurement is guesswork.

Logging captures operation in the field, feeding post-market monitoring, which feeds back into risk management as new evidence.

The loop is the requirement. Article 9's continuous, iterative and lifecycle language is describing exactly this circulation.

The requirements are outcome-stated, so the evidence that you met them is testing, and the Act says something specific about how testing is done.

Testing must be performed against prior defined metrics and probabilistic thresholds appropriate to the intended purpose. Prior defined is the load-bearing phrase: choosing the threshold after seeing the results is not testing, it is reporting.

Testing occurs throughout development and, in any event, before placing on the market or putting into service.

Three practices distinguish evidence that holds from evidence that does not.

Disaggregate. Aggregate accuracy conceals exactly the failure the fundamental rights analysis is concerned with. Report performance by the subgroups the system will be used on, which is what Article 10's reference to persons on whom the system is intended to be used points at.

Test the foreseeable misuse, not only the intended use, because Article 9 requires the misuse analysis and an untested analysis is an assertion.

And record the negative results. A test suite showing only passes reads as a test suite designed after the fact. Documented failures with the mitigations that followed are considerably stronger evidence of a functioning risk management process than a clean sheet.

None of Articles 9 to 15 falls on a deployer of a purchased system. The deployer's position is derivative, and understanding the seam prevents both over-building and dangerous assumptions.

What the deployer relies on: the provider met the requirements, and declared the relevant limitations and accuracy metrics in the instructions for use.

What the deployer must do with that: use the system in accordance with those instructions, assign human oversight to people with the necessary competence, training and authority, ensure input data is relevant and sufficiently representative in view of the intended purpose where the deployer exercises control over it, monitor operation and report serious incidents and risks, and keep the logs.

The input data duty is the one most often missed. A provider's accuracy claims were established on a particular data distribution. A deployer feeding the system materially different inputs, a different population, a different geography, a different time period, has moved outside the conditions under which those claims hold, and the Act places that responsibility on the deployer where it controls the input.

The practical instruction: read the declared intended purpose and the stated performance characteristics, then ask honestly whether your use matches them. Where it does not, you are either misusing the system or you have become its provider.

The requirements are stated as outcomes, which leaves an obvious question: how do you know your answer is good enough?

The Act's mechanism is harmonised standards. Where a high-risk system conforms to harmonised standards published in the Official Journal, it is presumed to conform to the requirements those standards cover. That presumption is legally valuable: it moves the question from whether your engineering judgement was adequate to whether you followed a published standard.

The European standardisation organisations were tasked with producing these, and the work has been substantial and slower than the original timetable assumed. That gap is part of the reason the high-risk deadlines moved to December 2027 and August 2028.

In the meantime, providers may demonstrate conformity by other means, documenting the technical solutions adopted where harmonised standards were not applied, which Annex IV expressly contemplates.

The practical advice is to track the standards work for your system type, because adopting a published harmonised standard is materially cheaper than defending a bespoke justification. And where you must proceed without one, document the reasoning against the requirement text itself, article by article, since that is the comparison a notified body or authority will make.