EU AI Act Compliance Requirements for High-Risk AI Systems

The EU AI Act sorts systems into tiers, and that sorting decides what happens to each one. Judge a system unacceptable risk, and Article 5 bans it outright, enforceable since February 2025. A system judged high-risk inherits dozens of substantive legal obligations. If a system is limited-risk, it owes users a transparency disclosure and little else. Judge a system minimal-risk, and it answers only to voluntary codes of conduct. The distance between the second tier and the third is the distance between a multi-year compliance program and a short notice to users, so getting the classification right determines which category of enterprise an organization is about to become.

Article 6 offers two separate roads into the high-risk category, and they lead to different deadlines and different obligations. The first road runs through Annex I: systems used as safety components in products already regulated across the EU, things like medical devices, autonomous vehicles, aviation equipment, machinery, toys, lifts, rail systems, and marine equipment. Annex I systems now have an August 2028 deadline under the Digital Omnibus. The second road runs through Annex III, which names eight sensitive application categories directly: biometric identification, critical infrastructure, education, employment, workers' management and access to self-employment, access to essential services such as credit scoring and insurance, law enforcement, migration, and administration of justice. Annex III systems carry a December 2027 deadline.

Those two roads sound clean on paper. They get messier in practice. A substantial share of enterprise AI systems cannot be clearly classified on first examination, particularly where a system touches more than one Annex III category at once. An HR platform that screens résumés is an employment tool by function, but if it also processes facial images or voice data for identity verification, it now sits in biometric identification territory too. That overlap is a structural feature of how modern AI products get built, because most enterprise tools stack capabilities rather than staying confined to one use case.

The breadth of Annex III means plenty of systems already running in production may qualify as high-risk without anyone inside the organization having clocked it. AI-assisted hiring pipelines, credit risk models, systems that help determine health benefit eligibility: these are ordinary enterprise tools that predate anyone's AI Act compliance review, and each one maps onto a named Annex III category whether or not the deploying organization built it with that category in mind.

An unresolved classification question is not a neutral holding pattern. The Act requires providers to document whether or not a system falls in scope, so failing to answer the question is itself a failure to comply, not a delay of the real compliance work.

How the Digital Omnibus Reshaped the Enforcement Calendar

Earlier guidance said full high-risk obligations would bite in August 2026, but that date is no longer accurate. The Digital Omnibus moved the Annex III standalone system deadline to 2 December 2027 and the Annex I product-embedded system deadline to 2 August 2028, and both now sit well past the dates many enterprises had been planning around. If you are still building a compliance timeline off the original August 2026 marker, that schedule is one the EU itself replaced.

Several obligations were not touched by that deferral and are already live. Prohibited AI practices under Article 5 have been enforceable since 2 February 2025. AI literacy obligations have applied since that same date. General-purpose AI model transparency requirements became enforceable on 2 August 2025. The Act's broader application also takes effect on 2 August 2026, and so do the enforcement powers of the AI Office and national market surveillance authorities, along with the Article 50 transparency obligations. The deadlines that moved are just the full high-risk compliance obligations under Annex I and Annex III. Everything else on the calendar stayed put.

The deferral exists because the technical infrastructure the Act leans on was not ready. Enterprises need CEN/CENELEC harmonised standards as the technical benchmarks to prove compliance, and more than 300 European experts across five working groups are writing them, but that work fell well behind its original April 2025 target. First publications are now arriving from mid-2026, with the bulk of prioritized standards expected in Q4 2026 or H1 2027, and some stretching as far as H1 2027 for the more complex categories. You could not ask enterprises to meet the original August 2026 deadline against standards that did not yet exist, so the Digital Omnibus deferral addresses that gap directly.

None of this resets the compliance clock to zero. The Act is not retroactive, so if a system reaches the market before its high-risk deadline applies, it may qualify for transitional treatment, and that grandfathering means deployment timing matters now, not later. An organization deciding when to launch a borderline system is, in effect, choosing which regulatory regime applies to it.

Enforcement itself will not look uniform across the bloc in the near term. A significant number of EU member states had not appointed competent authorities or designated single points of contact as the Omnibus was being finalized, so enforcement intensity will vary by jurisdiction for a while yet. That unevenness is a reason to build toward the substantive obligations now, not a reason to wait and see which country moves first.

What Articles 8–15 Require in Practice, Obligation by Obligation

Articles 8 through 15 do not read like a checklist, and treating them as one is the most common early mistake. They describe systems: technical and governance infrastructure that has to run continuously across the full life of an AI system, from the first line of development through the day it gets decommissioned. Each article below names a distinct piece of that infrastructure.

Article 9 covers risk management. The obligation is a live inventory of AI assets paired with ongoing identification of emerging risks, not a document produced once and filed away. If you run vendor-supplied AI rather than models built in-house, this obligation does not shrink. Risk management has to extend to third-party models and agents too, because licensing a system from someone else does not transfer the provider's legal responsibility away from the organization deploying it.

Article 10 covers data governance, and the Act is explicit that datasets must be examined for biases that could harm fundamental rights, not just for statistical accuracy. The obligation does not end once a model finishes training. Data governance also covers inference time, so you need to watch for things like unauthorized access or data integrity issues that surface through API calls or agent actions once the model is live. An organization that audited its training data carefully but never looked at what happens at inference has only done half the job.

Article 11 covers technical documentation: a record of system purpose, functionality, design specifications, performance metrics, and operational information that stays current as the system changes, available on request to regulators. For agentic systems or any system wired into external APIs, documentation has to capture every component and interface involved, not just the core model sitting at the center of it.

Article 12 covers automatic logging, and logs must be tamper-evident and retained for at least six months for most high-risk systems, including biometric and law enforcement systems, under the same floor set by Articles 19 and 26(6). Deployers carry a parallel obligation under Article 26, so they must keep those automatically generated logs for the same six-month minimum.

Article 14 covers human oversight. Systems have to let a human overseer understand what the system can and cannot do, catch anomalies, and intervene to stop it. That oversight only works if the people assigned to it are trained and competent, and deployers carry the responsibility for making that assignment. This requirement needs the AI literacy obligations that have been in force since February 2025 as its foundation.

Article 15 covers cybersecurity and adversarial robustness; security teams treat it as central even though governance teams most often underweight it. Article 15(3) makes technical robustness against adversarial attacks from unauthorized third parties mandatory. Article 15(5) names the specific threats in scope: data poisoning, adversarial examples, confidentiality attacks, model evasion. For AI agents, this obligation runs through the entire action layer: the APIs an agent calls, the MCP server connections it opens, and the tools it invokes all fall inside the article's scope. Meeting Article 15 takes both a governance read of the requirement and a security team's grasp of what the threats actually look like in practice.

Post-market monitoring and incident reporting as ongoing operational burdens, not post-launch formalities

Articles 72 and 73 cover what happens after a system goes live, and the obligations there start on day one of deployment and do not stop. Nothing in either article treats launch as a finish line.

Article 72 requires a monitoring system that is established and documented from the first day a high-risk system is deployed. That monitoring system connects directly back to the Article 9 risk management system: whatever it finds has to update the risk register, and the two obligations function as one loop. For enterprises running a large AI footprint, multiple vendor-supplied models, embedded AI inside products, agents operating across different workflows, monitoring has to cover all of it at once, not one system at a time as convenience allows.

Article 73 sets tiered deadlines for reporting serious incidents, and they are tight, so you need the infrastructure built in advance. An urgent, short window applies where an incident involves widespread infringement or serious and irreversible disruption to critical infrastructure. A 10-day window applies where an incident involves the death of a person. A 15-day window applies to other serious incidents. None of those windows leaves room for an organization to first learn about a problem from a user complaint and then start figuring out what happened. The detection infrastructure has to already exist before the incident occurs, because a reporting clock measured in days, sometimes in hours for the most severe cases, cannot be met by an organization starting its investigation from scratch.

Deployers carry their own share of these obligations too. Under Article 26, deployers must notify every individual affected by the AI system, a duty separate from the incident reporting requirements in Article 73 itself.

Taken together, these two articles are the clearest argument against treating AI Act compliance as a project with an end date. An organization that reaches conformity at launch but builds no ongoing monitoring behind it will drift out of compliance as the system's datasets shift, as the threat landscape around it changes, and as the system itself gets updated in ways the original conformity assessment never anticipated.

The conformity assessment and EU database registration process providers must complete before market placement

Before a high-risk AI system reaches the EU market, a provider has to clear a defined sequence of formal steps: conformity assessment, an EU declaration of conformity, CE marking, and registration in the EU database. Which assessment route applies depends on which category the system falls into.

For most Annex III high-risk systems, specifically points 2 through 8, the provider must self-assess by default, and that holds whether or not harmonised standards have been finalized yet. This is where the delayed CEN/CENELEC standards become directly relevant: enterprises cannot lean on a standards-based self-assessment route if the standards in question do not exist yet, and that gap is part of why the Digital Omnibus deferral was justified in the first place. Higher-sensitivity categories face a different route. Biometric identification, Annex III point 1, may require third-party conformity assessment by a notified body where harmonised standards are not applied. Critical infrastructure and law enforcement systems, by contrast, can self-assess internally.

Once a system clears its assessment route, it must carry the CE marking before it can be placed on the EU market. The marking is the visible signal that the conformity assessment behind it has actually been completed.

Registration in the EU database comes next, and it has to happen before market placement, not after. That registration creates a public record that national market surveillance authorities can draw on for oversight, and one that civil society groups can query directly. The record is a working oversight tool, not a formality tucked away in a filing cabinet somewhere.

Article 17, the quality management system every provider has to implement, ties every other obligation together. It has to cover a provider's regulatory compliance strategy, its system design techniques and procedures, its development procedures, its test and validation processes, its data management, its risk management, its post-market monitoring, and its serious incident reporting. Article 17 is less a separate obligation than the connective tissue holding every other article in this piece together: a provider that builds the risk management system, the data governance practices, the documentation, the logging, the oversight structure, and the monitoring infrastructure described above, and ties them into one coherent quality management system, has effectively built the compliance program the Act was written to require.