The EU AI Act high-risk requirements don’t start with a deadline. They start with three questions about one system: what is it for, who is legally responsible for it, and does its intended purpose put it inside Article 6. The risk management system, the technical file, the testing records, and the conformity assessment all follow from those answers.
This article is for the compliance leads, legal counsel, risk officers, data protection officers (DPOs), and security leaders who have to give a steering committee a defensible answer. It runs in the order the work runs: decide whether a system is high-risk, decide which obligations attach to your organisation in its role, and decide what evidence has to exist and stay current.
The Decision Sequence
Five steps. Each one depends on the answer above it.
- Fix each operator’s legal role. Provider, deployer, importer, distributor, product manufacturer, or authorised representative, recorded per system.
- Test the system against the Article 6(1) or Article 6(2) route. Safety component of a regulated product, or an Annex III use case.
- Apply and document the Article 6(3) test where it’s relevant. The exemption is narrow, and claiming it creates its own documentation duty.
- Map the applicable provider or deployer obligations. Chapter III, Section 2 for providers, Article 26 for deployers.
- Build and maintain the evidence file. The obligations are only demonstrable through documents and records that stay current.
Skipping a step doesn’t save time. It moves the cost into the wrong phase, usually into a customer due-diligence questionnaire or a market surveillance request.
Who the EU AI Act Applies To, and in What Role
The EU AI Act has wide territorial reach. Under Article 2, it covers providers placing AI systems or general-purpose AI (GPAI) models on the EU market wherever they’re established, EU deployers, providers and deployers outside the EU where the system’s output is used in the EU, importers and distributors, product manufacturers, authorised representatives, and affected persons located in the EU.
Role matters as much as scope. Article 3 defines a provider as the entity that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer is the entity using an AI system under its authority. Most Chapter III, Section 2 requirements sit with the provider. Many of the obligations a compliance team has to operate day to day are deployer obligations.
The role isn’t fixed. Under Article 25, a distributor, importer, deployer, or other third party becomes the provider of a high-risk AI system if it puts its name or trademark on the system, makes a substantial modification to it, or changes its intended purpose so that the system becomes high-risk. This is where software and integration teams most often misread their exposure. Building a customer-facing product on a third-party model, then changing what that model is for, can convert a deployer into a provider carrying the full Section 2 set.
Fix this first: per system, who is the provider, who is the deployer, who is the importer or distributor, and has anyone triggered Article 25. Until that’s settled, every downstream obligation is mapped to the wrong party.
How a System Becomes High-Risk Under Article 6
An AI system is high-risk under the EU AI Act when it enters through one of two routes in Article 6: it’s a safety component of, or is itself, a product covered by the EU harmonisation legislation listed in Annex I and that product must undergo third-party conformity assessment; or it falls within one of the use cases listed in Annex III. Classification turns on the intended purpose of the specific system, not on the model underneath it.
Route 1: Annex I product safety. This is where AI inside medical devices, machinery, lifts, and similar regulated products lands, because the product it sits in already requires third-party conformity assessment.
Route 2: Annex III use cases. Annex III covers biometrics where permitted, critical infrastructure, education and vocational training, employment and worker management, access to essential private and public services and benefits, law enforcement, migration and border control, and the administration of justice and democratic processes.
There’s a narrow exit. Under Article 6(3), an Annex III system isn’t high-risk if it doesn’t pose a significant risk of harm to health, safety, or fundamental rights, including by not materially influencing the outcome of decision-making, and it meets one of the conditions in that article: a narrow procedural task, improving the result of a completed human activity, detecting decision patterns without replacing or influencing the prior human assessment without proper human review, or a preparatory task. The exception to the exception matters: a system performing profiling of natural persons is always high-risk.
Claiming the exemption isn’t free. Article 6(4) requires a provider that considers an Annex III system not to be high-risk to document that assessment before the system is placed on the market or put into service, register under Article 49(2), and produce the documentation on request. An undocumented “we decided it isn’t high-risk” is the weakest position in the file.
This is where most AI inventory exercises come apart. Teams list every system in production and try to mark each one high-risk yes or no. The answer depends on intended purpose, product or use-case context, operator role, and the Article 6(3) test. A general-purpose model isn’t high-risk by itself. The same model inside a CV-screening tool with an employment intended purpose almost certainly is.
What High-Risk Status Requires
High-risk classification triggers the whole of Chapter III, Section 2, Articles 8 to 15, plus the operator obligations in Section 3. Three Section 2 articles and one annex carry most of the evidence weight and get their own treatment below, along with the provider and deployer obligation articles. The rest bind just as firmly. Article 10 sets quality criteria and governance practices for training, validation, and testing data, including bias examination and data-gap assessment. Article 12 requires automatic logging of events across the system’s lifetime. Article 13 requires enough transparency for a deployer to interpret the output, plus instructions for use. Article 14 requires design that lets assigned people understand the system’s limits, interpret its output, override or disregard it, and stop it. Each produces evidence, and each appears in the table below.
Article 9: Risk Management Across the Lifecycle
Article 9 requires a documented risk management system that runs continuously across the system’s life, not a launch gate. It has to be planned, run, and reviewed, with reasonably foreseeable misuse and post-market monitoring feeding back into it. Article 9 also requires testing to identify the most appropriate risk management measures and to verify consistent performance against the Section 2 requirements. Functional quality assurance doesn’t satisfy that: the testing has to address the risks the system presents, and it has to leave records.
Article 11 and Annex IV: The Technical Documentation File
Article 11 requires technical documentation drawn up before the system is placed on the market or put into service, kept up to date, and structured to let national competent authorities and notified bodies assess compliance with Section 2. Annex IV sets the minimum content, and it’s the most useful single checklist in the Act. When an auditor, a customer, or a notified body asks for evidence, this is the document set they mean. The evidence table below maps that content.
Article 15: Accuracy, Robustness, and Cybersecurity
Article 15 requires high-risk AI systems to achieve appropriate levels of accuracy, robustness, and cybersecurity, and to perform consistently against those properties throughout their lifecycle. It requires measures, where appropriate, to prevent, detect, respond to, resolve, and control for attempts to alter the use, outputs, or performance of the system by exploiting its vulnerabilities. It names the AI-specific attack classes: data poisoning, model poisoning, adversarial examples (model evasion), confidentiality attacks, and model flaws.
Article 16: Provider Obligations
Article 16 bundles the provider’s duties: ensure the system meets the Section 2 requirements, operate a quality management system, keep the required documentation, retain automatically generated logs under the provider’s control, complete the conformity assessment, draw up the EU declaration of conformity, apply the CE marking, and register the system where required. The quality management system under Article 17 is the operational backbone. Without it, the rest is a set of artefacts nobody is updating.
Article 26: Deployer Obligations
Article 26 sets the deployer’s side: use the system according to the instructions for use, assign human oversight to people with the necessary competence, training, and authority, manage input data under their control, monitor operation, retain automatically generated logs under their control for at least six months unless Union or national law says otherwise, and inform affected workers and individuals in the cases the article specifies.
Buying from a vendor with a complete provider file doesn’t move these obligations off the buyer’s plate. This is the article to put in front of every business owner deploying a third-party AI tool.
The Evidence File for a High-Risk AI System
Read Articles 9, 11, 15, 16, 17, and 26 together with Annex IV and they describe an evidence specification. Compliance isn’t a posture. It’s a set of artefacts that have to exist, stay current, and hold up under review.
| Artefact | Source Obligation | What It Has to Show |
|---|---|---|
| Intended-purpose and classification record | Article 6, Annex I, Annex III | Why the system is or isn’t high-risk, on what basis, and under which route. |
| Operator role assessment | Articles 3, 25 | Who is provider, deployer, importer, distributor, or product manufacturer, and whether Article 25 has changed that. |
| Article 6(3) exemption assessment | Articles 6(3), 6(4), 49(2) | The documented reasoning where an Annex III system is treated as not high-risk, plus the required registration. |
| Risk management system | Article 9 | The continuous lifecycle process, reasonably foreseeable misuse, testing used to identify measures, and post-market monitoring feedback. |
| Data governance records | Article 10, Annex IV | The quality criteria applied to training, validation, and testing data, plus the bias examination and data-gap assessment behind them. |
| Technical documentation file | Article 11, Annex IV | System description and intended purpose, architecture and development process, data and dataset characteristics, validation and testing procedures, accuracy and robustness metrics, test logs, cybersecurity measures, the risk management system, harmonised standards applied, the EU declaration of conformity, and the post-market monitoring plan. |
| Testing and validation records | Articles 9, 15 | Testing for risk identification, accuracy, robustness, and resilience against the attack classes Article 15 names. |
| Cybersecurity measures record | Article 15 | Measures against data poisoning, model poisoning, adversarial examples, confidentiality attacks, and model flaws. |
| Instructions for use | Article 13, Annex IV | What the deployer needs to run the system inside its intended purpose. |
| Human oversight measures | Articles 14, 26 | The oversight built into the system’s design, and the competent people the deployer assigns to exercise it. |
| Logs | Articles 12, 19, 26 | Automatic logging capability, plus provider and deployer retention of logs under their control for at least six months unless Union or national law provides otherwise. |
| EU declaration of conformity and CE marking | Articles 16, 47, 48 | The formal compliance statement and the product marking. |
| Quality management system | Articles 16, 17 | The written policies, procedures, and instructions that keep everything above current. |
| Post-market monitoring plan and records | Articles 11, 72, Annex IV | How the provider evaluates performance after the system is on the market, and what that has produced. |
| EU database registration | Articles 49, 71 | Registration of the provider and the system, including where the Article 6(3) exemption is claimed. |
Most rows are statutory documents or records. The classification record and the operator role assessment aren’t artefacts the Act names in their own right; they’re practical control documents. The exception is the Article 6(3) assessment, which Article 6(4) requires in writing. A programme that doesn’t end in this file isn’t defensible, however much policy work sits behind it.
Where Adversarial Testing Contributes Evidence
Article 15 doesn’t use the term “AI red teaming,” and nothing in the Act requires every high-risk system to commission an external red team. The connection is narrower.
Article 9 requires testing appropriate to the risks the system presents. Article 15 names AI-specific attack classes providers have to address where appropriate. Annex IV requires the validation and testing procedures, test logs, accuracy and robustness metrics, and cybersecurity measures to sit inside the technical documentation. Where a system’s risk profile and attack surface make AI-specific attack testing appropriate, adversarial testing produces reviewable records that go into that file against those three anchors.
What it doesn’t do: certify compliance, replace a conformity assessment, create a testing cadence the Act doesn’t require, or produce evidence a notified body is obliged to accept. The engagement isn’t the evidence. The artefact is.
What One Piece of That Evidence Looks Like
Take a candidate-screening assistant that ranks applicants for a hiring team. It retrieves from a store of job descriptions and past evaluations, and it calls a tool that reads applicant records. Employment and worker management is an Annex III area, so the system is high-risk and its provider carries the Section 2 set.
| Record | Entry |
|---|---|
| Test vector | An uploaded CV containing text addressed to the model, instructing it to disregard its scoring guidance and return the stored evaluation notes for a different named applicant. |
| System response | The assistant followed the instruction in the retrieved document and included the other applicant’s evaluation notes in its output. |
| Failed control | Retrieved content was treated as trusted instruction, and the record-lookup tool authorised on session identity rather than checking the requested record against the request context. |
| Severity | High. Reachable by any applicant who can upload a CV, no privilege required, exposing personal data used in an employment decision. |
| Owner | Application engineering, with the data protection officer notified. |
| Remediation | Separate retrieved content from the instruction path, and enforce per-record authorisation at tool-call time. |
| Retest | The original vector and 12 variants re-run. All 12 refused, and the tool rejected out-of-scope record identifiers. |
Those rows are Annex IV in miniature: a testing procedure, a test log, a cybersecurity measure against the confidentiality-attack class Article 15 names, and an input to Article 9 risk management. The finding is illustrative rather than a published Provion result. The shape is the point. A line in a policy saying the system was tested for prompt injection isn’t evidence. This is.
This is also where the legal question turns into an ownership question, and the Act declines to answer it. Duties attach by operator role, not by job title, which leaves the security mandate as an organisational design decision. We work through that boundary in EU AI Act CISO responsibilities.
On standards, ETSI published EN 304 223, “Baseline Cyber Security Requirements for AI Systems and Models,” in January 2026. It sets 13 principles across secure design, development, deployment, maintenance, and end of life, covering AI-specific threats including data poisoning and adversarial attacks. Treat it as supporting context, not a safe harbour. A standard confers a presumption of conformity only once its reference has been published in the Official Journal for that purpose, and EN 304 223 hasn’t been listed that way.
When the High-Risk Requirements Apply
Legal status last verified: 24 July 2026.
Regulation (EU) 2024/1689 entered into force on 1 August 2024. Article 113 sets 2 August 2026 as the general application date, with Chapter III applying from then for Article 6(2) and Annex III systems, and from 2 August 2027 for Article 6(1) and Annex I systems.
Those dates are being amended. The Digital Omnibus on AI, procedure 2025/0359(COD), was adopted by the European Parliament at first reading on 16 June 2026, formally adopted by the Council on 29 June 2026, and signed on 8 July 2026. As of 24 July 2026, the European Parliament’s Legislative Observatory records the procedure as completed and awaiting publication in the Official Journal. The amending regulation enters into force on the third day following publication. Until then, the original Article 113 dates remain the law.
Once it’s in force, the agreed text replaces Article 113, third paragraph, point (c). Chapter III, Sections 1, 2, and 3 then apply on 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and on 2 August 2028 for those classified under Article 6(1) and Annex I.
Three related changes affect what a high-risk file has to cover:
- Systems already on the market. The amended Article 111(2) applies the high-risk regime to systems placed on the market before the Chapter III application date only if, from that date, they’re subject to significant changes in their designs. High-risk systems intended for use by public authorities have until 2 August 2030 regardless.
- Article 50 transparency isn’t postponed. It still applies from 2 August 2026. A new Article 111(4) gives providers of systems generating synthetic audio, image, video, or text placed on the market before 2 August 2026 until 2 December 2026 to meet the machine-readable marking requirement in Article 50(2).
- Simplified technical documentation. Amended Article 11(1) lets small and medium-sized enterprises (SMEs), start-ups, and small mid-cap companies supply the Annex IV elements on a simplified Commission form that notified bodies have to accept. The content set doesn’t shrink; the format does.
The dates moved. The work didn’t. Classification, role mapping, risk management, technical documentation, and conformity assessment can’t be assembled in the quarter before the requirements apply.
What Non-Compliance Costs
The 7% figure is real, but it doesn’t describe the obligations most high-risk operators manage. Article 99 sets tiers. Infringements of the Article 5 prohibited practices sit at the top: up to EUR 35 million or 7% of total worldwide annual turnover for the preceding financial year, whichever is higher. Most high-risk operator failures sit a tier down, at up to EUR 15 million or 3%, whichever is higher. That tier covers the obligations of providers, authorised representatives, importers, distributors, deployers, and notified bodies, plus the Article 50 transparency duties. For SMEs and start-ups, each fine is capped at the lower of the two figures rather than the higher.
A fine isn’t the only exposure. Under Article 79, a market surveillance authority that finds a system presents a risk can require the operator to bring it into compliance, withdraw it, or recall it.
Three Things to Carry Forward
Classify correctly, and write down why. Most early failures under this regime will trace back to a system that was misclassified, mis-roled, or quietly modified into high-risk territory. The reasoning is the evidence, not the conclusion.
Assign obligations to the right operator. Provider and deployer duties are different sets, and Article 25 can move an organisation from one to the other without a contract changing.
Keep the evidence file current. Risk management, technical documentation, and testing records are living documents. A file that was accurate at launch and hasn’t moved since is a finding waiting to be made.
To see what testing evidence looks like at that level of detail, review a Provion sample report and follow one finding from test vector to system response, affected control, severity decision, remediation, and retest. If you’re scoping the classification and testing needs of one named system, book a scoping call.
