EU AI Act High-Risk Obligations: What They Require

High-risk classification under the EU AI Act brings a defined set of obligations, and almost all of them are engineering requirements rather than paperwork. Built in, they document decisions a careful team makes anyway; retrofitted, they become a project. This guide covers what each requires, drawing on FISTA Solutions' AI enablement work. This article is general guidance, not legal advice.

What makes a system high-risk?

Broadly, two routes: use in listed areas — including employment, education, access to essential services, law enforcement, migration, and critical infrastructure — and AI acting as a safety component of products already covered by EU product legislation.

Classification depends on use rather than on technology. The same model can be high-risk in one deployment and outside scope in another, which is why classification is a per-system exercise.

What are the core obligations?

Obligation	What it means in practice
Risk management system	Continuous, across the lifecycle
Data governance	Training and testing data quality, bias examination
Technical documentation	Sufficient to assess conformity
Record-keeping	Automatic logging, traceable events
Transparency	Instructions enabling correct use by deployers
Human oversight	Designed so people can intervene meaningfully
Accuracy, robustness, security	Appropriate to purpose, and demonstrated
Quality management system	Organisational, not per-system

How do provider and deployer duties differ?

Providers develop or place systems on the market and carry the bulk of the obligations, including conformity assessment and post-market monitoring.

Deployers use them and carry duties around operating in line with instructions, assigning competent human oversight, monitoring operation, keeping logs, and in defined cases informing affected people. Organisations that modify a system substantially, or put their own name on it, can become providers.

What does human oversight actually require?

That people can understand the system's capabilities and limits, interpret its output, decide not to use it, and intervene or stop it.

That is a design requirement, not a policy statement. A system whose output arrives with no basis, no confidence signal, and no practical way to override it does not support meaningful oversight regardless of what the policy says. See what is human in the loop AI.

What does data governance involve?

Examining training, validation, and testing data for relevance, representativeness, and errors, and looking for biases likely to affect health, safety, or fundamental rights.

The practical work is knowing where your data came from, what it represents, who is under-represented in it, and what you did about that. Organisations that cannot describe their training data cannot meet this.

What has to be logged?

Enough to make operation traceable across the system's lifetime: inputs, outputs, and events sufficient to identify situations where the system might present a risk or undergo substantial modification.

Design logging before launch. Retrofitting traceability onto a live system is expensive and frequently incomplete, because the events you now need were not recorded.

What is conformity assessment?

The process of demonstrating the system meets the requirements before it is placed on the market, with the route depending on the category — internal control for most Annex III systems, third-party involvement for others.

It results in a declaration of conformity and, where applicable, CE marking and registration in the EU database. Plan the timeline around it; it is not a final formality.

Does the obligation end at launch?

No. Post-market monitoring, record-keeping, and serious incident reporting continue throughout the system's life, and substantial modification can trigger reassessment.

Treat the system as an operated capability with a compliance tail rather than as a delivered project.

When do these obligations apply?

The Act applies in phases, with prohibitions taking effect first, general-purpose model obligations next, and high-risk obligations later, with some product-embedded categories later still.

Confirm the current dates for your category rather than relying on a summary, including any transitional provisions for systems already on the market.

What does compliance cost?

Mostly the cost of good engineering practice: evaluation, documentation, logging, and oversight design. Built into the project, the incremental cost is modest.

Retrofitted onto a live system it is a project, performed under deadline, on something people already depend on. See AI governance cost.

What are the common mistakes?

Assuming classification is about technology rather than use. Treating human oversight as a policy. Deferring logging design. Assuming deployer status removes all duties. And leaving conformity assessment until the launch date is fixed.

Who owns this internally?

The function that owns the system, supported by legal and compliance. Ownership by legal alone produces documents describing systems nobody changed.

What should you do first?

Classify your systems by use, honestly. Most organisations find the list of genuinely high-risk systems is shorter than feared and includes one they had not considered — frequently something in recruitment or in access to a service.

How FISTA Solutions helps

FISTA Solutions builds systems against these obligations from the start: classification by use before design, data provenance documented, logging and traceability designed before launch, human oversight made structural rather than procedural, evaluation evidence produced continuously, and post-market monitoring in place at launch. Delivery runs through AI enablement, AI agents, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries.

To scope a high-risk system properly, message FISTA on WhatsApp, or read EU AI Act conformity assessment.