What the EU AI Act Requires From High-Risk AI Systems?

The EU AI Act’s high-risk regime is about classification, evidence, and ongoing risk work, not a single enforcement date. After the 7 May 2026 political agreement between the European Parliament and the Council on the Commission’s Digital Omnibus proposal, the deadline picture has shifted, but the underlying obligations haven’t. Here’s what providers, deployers, and other operators need to determine before any compliance programme is worth running.

The first useful question about EU AI Act compliance isn’t when the rules apply. It’s whether they apply to a specific system, in a specific role, against an intended purpose that puts it inside the high-risk category. That’s the question this article answers, in the order a legal or compliance team typically has to answer it.

Most of the early industry conversation has been built around the 2 August 2026 calendar entry. After the 7 May 2026 political agreement on the Digital Omnibus proposal, the deadline picture has changed and the calendar is no longer the most pressing variable. What stays constant is the underlying classification and evidence work: identifying the systems in scope, fixing each operator’s legal role, mapping obligations onto auditable documentation, and embedding testing and monitoring into the lifecycle rather than the launch.

This article is written for compliance leads, legal counsel, risk officers, and data protection officers (DPOs) who need to bring a clear picture to a steering committee or board. It covers scope, the high-risk classification test, the core operator obligations, the evidence the Act expects in writing, how adversarial testing fits the risk and cybersecurity logic, the actual penalty tiers, and where the timeline now sits.

Who the EU AI Act Applies To, and in What Role

The Act has wide territorial reach. Under Article 2, it applies to:

• Providers placing AI systems or general-purpose AI (GPAI) models on the EU market or putting them into service in the EU, wherever they’re established.
• Deployers based in the EU.
• Providers and deployers established outside the EU where the output of the AI system is used in the EU.
• Importers and distributors of AI systems.
• Product manufacturers placing an AI system on the market or putting it into service together with their product under their own name or trademark.
• Authorised representatives of providers not established in the EU.
• Affected persons located in the EU.

Role matters as much as scope. Article 3 defines a provider as the entity that develops, has developed, places on the market, or puts into service an AI system under its own name or trademark. A deployer is the entity using an AI system under its authority. The legal weight of an obligation sits with the provider for most Section 2 high-risk requirements. Many of the obligations a compliance team actually has to operate are deployer obligations.

The role isn’t always stable. Under Article 25, a distributor, importer, deployer, or third party can become the provider of a high-risk AI system if it rebrands the system under its own name or trademark, substantially modifies it, or changes its intended purpose so that the system becomes high-risk. This is where a lot of SaaS and integration teams misread their exposure. Building a customer-facing product on top of a third-party model, then changing what the model is “for,” can convert a deployer into a provider, with the full Section 2 obligations attached.

Before answering any other compliance question, fix this: for each AI system in the inventory, who is the provider, who is the deployer, who is the importer or distributor, and has the intended purpose been changed in a way that triggers Article 25? Until that’s nailed down, every downstream obligation is being mapped to the wrong party.

When the EU AI Act High-Risk Rules Actually Apply

The deadline story requires precision because the timetable in the law currently differs from the timetable in the provisionally agreed amendment.

Under the AI Act currently in force, Article 113 sets 2 August 2026 as the general application date. As a result, the Chapter III requirements for high-risk systems classified under Article 6(2) and Annex III are due to apply from that date. Article 6(1) and the corresponding obligations for product-related high-risk systems are scheduled to apply from 2 August 2027.

These dates are subject to the transitional provisions in Article 111. In particular, the Act doesn’t impose all high-risk requirements retrospectively on every system already placed on the market or put into service. The applicable treatment depends on factors including when the system entered the market, whether its design changes significantly after the relevant application date, and whether it is intended for use by a public authority.

On 7 May 2026, the European Parliament and Council reached a provisional political agreement on the Digital Omnibus on AI. The agreed text would postpone the application of Chapter III, Sections 1, 2, and 3 until 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and until 2 August 2028 for systems classified as high-risk under Article 6(1) and Annex I.

As of 11 June 2026, those dates are politically agreed but not yet legally binding. Formal adoption by Parliament and Council, publication in the Official Journal, and entry into force remain outstanding.

The postponement is also limited. Article 50 transparency obligations generally remain due to apply from 2 August 2026. Under the agreed text, providers of systems that generate synthetic audio, image, video, or text and were placed on the market before that date would have until 2 December 2026 to comply with the machine-readable marking requirement in Article 50(2). This grace period does not postpone Article 50 as a whole.

Two practical consequences follow:

1. Organisations shouldn’t treat the proposed postponement as a reason to pause. System classification, role mapping, risk management, technical documentation, and, where applicable, conformity assessment require sustained work. They can’t credibly be assembled in the final quarter before the relevant requirements apply.
2. Customer and board communications should distinguish between obligations that remain due to apply from 2 August 2026 and the specific Chapter III provisions covered by the proposed postponement. Presenting 2 August 2026 without explaining the pending amendment gives an incomplete picture. Presenting 2 December 2027 as settled law, or as a comfortable horizon, is equally misleading. The compliance work hasn’t disappeared. The political timetable has shifted, but the law hasn’t yet changed.

How a System Becomes High-Risk

There are two routes into the high-risk category. Article 6 defines both.

Route 1: Annex I product safety. An AI system is high-risk if it’s intended to be used as a safety component of, or is itself, a product covered by EU harmonisation legislation listed in Annex I, and the product is required to undergo a third-party conformity assessment before being placed on the market or put into service. This route is where AI inside medical devices, machinery, lifts, toys, and similar regulated products lands.

Route 2: Annex III use cases. An AI system is high-risk if it falls within one of the use cases listed in Annex III. The Annex III areas are:

• Biometrics, where permitted.
• Critical infrastructure.
• Education and vocational training.
• Employment, worker management, and access to self-employment.
• Access to and enjoyment of essential private services and essential public services and benefits.
• Law enforcement.
• Migration, asylum, and border control management.
• Administration of justice and democratic processes.

There is a narrow exit. Under Article 6(3), an Annex III system may avoid high-risk classification if it doesn’t pose a significant risk of harm to the health, safety, or fundamental rights of natural persons, and it meets the conditions set out in the article. The carve-out has an important exception: systems performing profiling of natural persons are always high-risk. Compliance teams that lean on the Article 6(3) exit need to document the reasoning and keep the assessment current.

This is the part of the analysis that derails most early AI inventory exercises. Teams pull together a list of every AI system in production and try to mark each one “high-risk: yes/no.” Classification turns on intended purpose, Annex III use case, product context, operator role, and the Article 6(3) exemption test. A general-purpose model isn’t high-risk by itself. The same model, embedded in a CV-screening tool with an explicit employment intended purpose, almost certainly is.

A useful classification template covers, per system: the intended purpose in writing, the Annex III area or Annex I product route that applies, the operator’s role (provider, deployer, importer, distributor, product manufacturer, authorised representative), the user population, the deployment context, and the Article 6(3) assessment. That template is what a compliance team should be able to put in front of an auditor, not a list with checkmarks.

What High-Risk Status Actually Requires

High-risk classification triggers the obligations in Chapter III, Section 2 of the Act. The centre of gravity for compliance work sits in five articles and one annex.

Article 9: Risk Management as a Lifecycle Process

Article 9 requires a documented risk management system for high-risk AI systems. Two features of the requirement matter most for compliance design.

First, it’s a continuous lifecycle process, not a launch gate. The risk management system has to be planned, run, and reviewed across the system’s life, with reasonably foreseeable misuse and post-market monitoring inputs feeding back in.

Second, Article 9 requires testing of high-risk AI systems to identify the most appropriate risk management measures and to verify consistent performance against Chapter III, Section 2 requirements. The testing isn’t optional, and it isn’t satisfied by functional QA. It has to address the risks the system actually presents.

A risk management system that is run once before launch and never revisited is a documentation failure, not a process. So is one that doesn’t produce reviewable testing results.

Article 11 and Annex IV: Technical Documentation

Article 11 requires technical documentation to be drawn up before the system is placed on the market or put into service, kept up to date afterward, and structured to demonstrate compliance with Section 2. Annex IV sets the minimum content. For a compliance team, Annex IV is the most useful single checklist in the Act.

Annex IV technical documentation includes, at minimum:

• A general description of the AI system and its intended purpose.
• The system’s architecture, design choices, and development process.
• Data requirements and characteristics of the datasets used.
• Validation and testing procedures.
• Metrics for accuracy and robustness.
• Test logs.
• Cybersecurity measures.
• The risk management system.
• Harmonised standards applied (and any non-harmonised solutions chosen instead).
• The EU declaration of conformity.
• The post-market monitoring plan.

If an internal audit or notified body asks for evidence that a high-risk system is compliant, this is the document set they’re asking for. A “governance framework” that doesn’t end in this material isn’t, by itself, evidence of compliance.

Article 15: Accuracy, Robustness, and Cybersecurity

Article 15 requires high-risk AI systems to achieve appropriate accuracy, robustness, and cybersecurity, and to perform consistently against those properties throughout their lifecycle. The cybersecurity language is the part most relevant for adversarial testing programmes.

Article 15 sets out, where appropriate, measures to prevent, detect, respond to, resolve, and control for attempts to alter the use, outputs, or performance of high-risk AI systems by exploiting their vulnerabilities. It names the AI-specific attack classes directly:

• Data poisoning.
• Model poisoning.
• Adversarial examples, or model evasion.
• Confidentiality attacks.
• Model flaws.

This is the bridge between the regulation and what a security team actually has to do. The Act’s language is risk management, testing, robustness, and cybersecurity. The attacks it lists are the attacks an adversarial testing programme is designed to find.

Article 16: Provider Obligations

Article 16 bundles the provider’s responsibilities. A provider of a high-risk system has to ensure the system meets the Section 2 requirements, maintain a quality management system, keep the required documentation and, where the logs are under its control, retain automatically generated logs for the applicable retention period, complete the conformity assessment procedure, draw up the EU declaration of conformity, apply the CE marking, and register the system where required.

The quality management system is the operational backbone behind everything else. Without it, the rest of the article is a list of artifacts no one is updating.

Article 26: Deployer Obligations

Article 26 sets the deployer’s side of the contract. Deployers of high-risk systems have to use systems in accordance with the instructions for use, assign competent human oversight, manage relevant input data where it’s under their control, monitor the operation of the system, retain logs for at least six months where the logs are under their control, and inform affected workers or individuals in certain cases.

This is the article DPOs and risk officers should be holding in front of every business owner deploying a third-party AI tool. Buying a high-risk system from a vendor with full provider documentation doesn’t move the deployer obligations off the buyer’s plate.

What the Evidence Looks Like

The most useful way to read Articles 9, 11, 15, 16, 17, 26, and Annex IV together is as an evidence specification. Compliance for a high-risk AI system isn’t a posture or a policy. It’s a set of artifacts that have to exist, be current, and be defensible under review.

A minimum evidence pack for a high-risk system, mapped to the source obligations, looks like this:

Artifact	Source Obligation	Purpose
Intended-purpose and classification memo	Article 6, Article 6(3), Annex III	Records why the system is or isn’t high-risk, and on what basis.
Role assessment per operator	Article 3, Article 25	Fixes who is provider, deployer, importer, distributor, or product manufacturer for each system.
Risk management system documentation	Article 9	Shows the continuous lifecycle process, foreseeable misuse analysis, and feedback from post-market monitoring.
Technical documentation file	Article 11, Annex IV	The Annex IV content set, kept current.
Testing and validation records	Article 9, Article 15	Evidence of testing for risk identification, robustness, and resilience against the attack classes Article 15 names.
Cybersecurity measures record	Article 15	The measures in place against data poisoning, model poisoning, adversarial examples, confidentiality attacks, and model flaws.
Instructions for use	Article 13, Annex IV	What the deployer needs in order to operate the system within scope.
Logs	Articles 12, 19, 26	Automatic logging capabilities, plus provider/deployer retention of automatically generated logs where those logs are under their control, for at least six months unless Union or national law provides otherwise.
EU declaration of conformity and CE marking	Article 16	The formal compliance statement and product marking.
Quality management system documentation	Article 16, Article 17	The operational backbone that ties the rest of the artifacts together.
Post-market monitoring plan and records	Articles 11, 72, Annex IV	The provider’s system for evaluating performance in the post-market phase, including the Article 72 post-market monitoring plan and related records.

Most items in that table are statutory documents or records. The classification memo and role assessment are practical control documents rather than separately named AI Act artifacts, but they’re the cleanest way to make the statutory documentation defensible. A compliance programme that doesn’t produce reviewable evidence isn’t in a credible position, regardless of how much policy work has been done.

Where Adversarial Testing Fits

Article 15 doesn’t use the phrase “AI red teaming.” It uses risk, robustness, cybersecurity, and resilience against attempts to alter use, outputs, or performance. The Act’s vocabulary is regulatory, not commercial. The work it implies is the work an adversarial testing programme does.

Three connections matter.

First, Article 9 requires testing to identify risk management measures and verify performance against Section 2 requirements. A risk management system that hasn’t been tested against adversarial conditions can’t credibly claim to have identified the appropriate measures.

Second, Article 15 lists the specific attack classes high-risk systems have to address: data poisoning, model poisoning, adversarial examples and evasion, confidentiality attacks, and model flaws. These aren’t generic IT security categories. They’re AI-specific attack classes that the Act expects providers to address where appropriate.

Third, Annex IV requires the testing logs, the cybersecurity measures, the validation procedures, and the accuracy and robustness metrics to live inside the technical documentation. Adversarial testing without documentation that maps to these Annex IV sections produces interesting findings and weak compliance evidence. The artifact, not the engagement, is what stays on the file.

For broader context on the standards side, ETSI published ETSI EN 304 223, “Baseline Cyber Security Requirements for AI Systems and Models,” which addresses AI-specific threats including data poisoning, model manipulation, and adversarial attacks across 13 principles spanning design, development, deployment, maintenance, and end of life. EN 304 223 is the correct reference for the ETSI AI cybersecurity standard. It’s a European AI cybersecurity standard aligned with the Act’s implementation. It isn’t, on current evidence, an Official Journal-listed harmonised standard conferring presumption of conformity under the AI Act. Treat it as supporting context, not a guaranteed safe harbour.

What Non-Compliance Actually Costs

The “7% of turnover” line is a real fine, but it doesn’t apply to the obligations most high-risk operators have to manage. Article 99 sets a tiered structure.

• Top tier: up to EUR 35 million or 7% of worldwide annual turnover, whichever is higher. This applies to non-compliance with the prohibited AI practices in Article 5, not to ordinary high-risk obligations.
• Operator tier: up to EUR 15 million or 3% of worldwide annual turnover, whichever is higher. This is the tier that covers many provider, importer, distributor, deployer, notified body, and Article 50 transparency infringements. Most failures on the Section 2 high-risk requirements sit here.

A compliance brief that uses the 7% number to describe documentation failures, deployer oversight gaps, or technical file shortfalls is inflating the risk. A brief that ignores the EUR 15 million / 3% tier is understating it. Both errors weaken trust in the underlying analysis.

The penalty isn’t the only cost. A finding of non-compliance can trigger corrective action, restriction or prohibition of market availability, withdrawal, or recall. Formal CE-marking failures can also trigger market-surveillance action. The financial fine is one line of a longer exposure.

A Practical Sequence for Compliance Teams

For a compliance lead, legal counsel, risk officer, or DPO trying to make this actionable, the work runs in a specific order. Skipping a step doesn’t save time. It moves cost into the wrong phase.

1. Inventory the AI systems in scope, including AI built into third-party tools. The inventory has to be current and concrete, not aspirational. SaaS contracts, embedded vendor models, and shadow-deployed tools all count.
2. Classify each system against Article 6 and Annex III, including the Article 6(3) test. Document the reasoning, not just the outcome. Profiling triggers the high-risk classification even where the carve-out would otherwise apply.
3. Fix the role for each operator per system, including the Article 25 trigger. Rebrand, modify, or change intended purpose can convert a deployer into a provider with the full Section 2 obligations attached.
4. Build the technical documentation file against Annex IV. Use Annex IV as the table of contents. Identify the gaps. Plan the work to close them before the system is placed on the market or put into service.
5. Stand up the risk management system as a lifecycle process, with testing. Article 9 expects continuous risk work feeding back from post-market monitoring, not a one-shot launch review.
6. Specify the cybersecurity measures, including adversarial testing, against the Article 15 attack classes. The output of that testing is evidence for Annex IV. Build the engagement so the artifacts are usable.
7. Operationalise deployer obligations under Article 26. Instructions for use, human oversight, input-data management, logging, and notification to affected workers or individuals. These are running obligations, not launch tasks.
8. Set the calendar against the revised application dates and the original ones. Plan for the earlier date and keep the slack the Digital Omnibus may add as a buffer, not a delay.

That sequence won’t fit on a slide. It does fit on a steering-committee agenda, and it tells a board what the next two budget cycles need to deliver.

What to Bring Into the Next Meeting

Three things matter more than the rest.

Classification is the work. Almost every compliance failure in the early years of the AI Act will trace back to a system that was misclassified, mis-roled, or quietly modified into high-risk territory. Spending time here isn’t a delay. It’s where the rest of the programme is anchored.

Evidence beats posture. A high-risk AI compliance programme produces a file an auditor can read. If the work isn’t ending in Annex IV documentation, risk management records, testing logs, cybersecurity measures, instructions for use, and a post-market monitoring plan, it isn’t ending in compliance.

Adversarial testing can produce strong evidence for Articles 9, 15, and Annex IV where the system’s risk profile makes AI-specific attack testing relevant. Independent adversarial testing, scoped against the AI-specific attack classes Article 15 names and documented against the Annex IV structure, is one of the most directly usable inputs into a high-risk compliance file. It also surfaces the failure modes that internal QA was never designed to find.

Provion works with organisations preparing for the EU AI Act’s high-risk requirements, focused on adversarial testing engagements that produce evidence mapped to Articles 9, 15, and Annex IV. For compliance leads, legal counsel, risk officers, and DPOs who want to walk into the next meeting with a defensible plan, the practical next step is a scoping conversation against the systems already in scope.