Obligations for High-Risk AI Systems

Imagine you are preparing a deployment for a customer. The product works, the model is accurate on the test data, and the customer is eager to go live. Then a legal or procurement reviewer asks a question you cannot answer: does this system fall under the EU AI Act, and if so, what must be in place before it runs? For anyone deploying AI into real organizations, that question now has a concrete answer. The answer depends on the system's risk level and on where its outputs land.

This article follows that question step by step. You will first place the Act in time, then trace how a system is sorted by risk, then walk through the obligations that attach to the high-risk category, and finally trace a case where a US vendor and a US customer may still fall inside the Act's scope. Keep the reviewer's question in mind throughout: for any system, what must be true before it runs?

The EU AI Act is Regulation 2024/1689. It came into force on August 1, 2024, and its obligations arrive in stages running through 2026 and 2027. Treat this date range as a planning signal. Some duties are already relevant, and others are scheduled to apply later. Your job is to know which duties attach to which systems, and when.

Read the timeline as a sequence rather than a single deadline. The Act was in force from its entry-into-force date, and the duties it contains are scheduled across the later years. A compliance plan therefore has to ask two questions for each duty: is it already applying, and does it attach to this particular system?

The Act does not treat every AI system the same way. It classifies AI systems by risk level, and the classification determines which obligations apply. The practical question for any system is therefore not Is this AI? but How risky is this particular use, and what does that risk level require?

The four tiers shown above are the ones the Act uses for sorting. The obligations discussed in this article attach to the high-risk tier. The source material does not enumerate every category in detail, so for the exact tests that place a system in each tier, check the official summary and the legal text.

The sorting is tied to the use of the system. The same underlying model can sit in different risk positions depending on what it is used for and what its outputs affect. This is why a compliance review starts with the deployment context, not with the model architecture. Notice also what the sorting does not do: it does not hand every system a uniform checklist. The first analytical step for any system is determining where it sits.

Once a use is identified as high-risk, the Act imposes specific obligations. The source lists nine areas: risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy, robustness, and cybersecurity. Each one describes a property that the system and its surrounding processes must have. None of them is a single document to file.

The nine areas are not independent boxes. The sections below group them by what they protect, so you can see how they relate. The grouping is a teaching device drawn from how the source describes each area's purpose.

A common assumption is that a regulation only binds companies located in the regulating region. The EU AI Act has extraterritorial reach, meaning it can apply to parties outside the EU. The source gives a specific case: a US vendor deploying for a US customer can still be subject to the Act if the customer's outputs affect EU residents.

The key variable is where the effects land, not only where the companies are incorporated. A deployment that never leaves the United States in terms of parties can still touch EU residents through its outputs. For that reason, a customer conversation with a multinational organization should include a question about who the system's outputs reach.