EU AI Act High-Risk System Checklist for GenAI Deployments: 2026 Enforcement Window

If your organization plans to deploy GenAI systems that span the EU, the question is narrower. "Are we ready for the AI Act?" is the wrong framing. The framing should be: "What dates are impacted? What system category are we in? And where does our documentation intersect with the ISO and NIST processes?"

This guide explains how to use Articles 6 and Annex III to determine whether your system is high-risk, how to identify your role in the value chain, how to select between Articles 9 to 17 and map to ISO/IEC 42001:2023 Annex A and NIST AI RMF subcategories, and how to use a two part checklist for procurement. Every Article reference links to primary source.

The date that actually binds your system

The 2 August 2026 cliff date many competitor pages still lead with has been overtaken. The AI Omnibus, having been formally agreed at a political level on 7 May 2026 (see the amendments that were adopted on 19 November 2025), will instead have the following two dates: From 2 December 2027, Annex III (high-risk) products; and from 2 August 2028, Annex I (embedded) products. (Note: For most deployers in the Annex III category, the relevant date is December 2027.)

That is not a free runway. Three obligation streams are already live:

• Article 53 GPAI obligations are effective as of 2 August 2025. If you use a third-party foundation model, your counterparty has downstream Annex XII obligations. Request this documentation from your counterparty.
• Article 6(1) product-chain duties apply at 2 August 2028, but upstream sectoral regimes — medical device, machinery, in-vitro diagnostics, toys — continue to apply in parallel.
• Article 73 serious-incident reporting has 15-day, 10-day, and two-day windows that apply when a high-risk system reaches production.

The 2 August 2026 date also applies to the governance aspects, including the roles/authorities, the Article 6(5) guidance on derogation for high risk AI (published by the Commission 2 February 2026), and the conformity assessment procedures. The AI Act Service Desk and the European AI Office are the Commission's support organs. Make use of that time to develop the classification artifact, crosswalk and Annex IV evidence chain, properly, once, against a background moving target of the Commission guidance.

Article 6 and Annex III: is your GenAI system high-risk?

Article 6 gives two paths into high-risk classification.

Path one — Article 6(1) product safety. If the AI system is a safety component or constituent of, or the AI system itself is, a product covered by Union harmonisation legislation in Annex I and the latter requires third-party conformity assessment under sectoral law, then AI system shall be deemed high-risk. No derogation available under paragraph 1. A GenAI feature used in a medical device to make recommendations based on diagnostic advice; or an AI system used in a controller for the safety of a machine or a gas detector; or an AI system used in an IVD readout is high-risk by definition, with a transition period until 2 August 2028.

Path two — Article 6(2) and Annex III. The AI system is high-risk if it is intended for certain areas, such as biometrics; critical infrastructure; education and vocational training; employment and workers management; essential services (such as creditworthiness and insurance pricing); law enforcement; migration, asylum and border control; and administration of justice and democratic processes (Annex III). If your use case does not fall into any of these and you are not developing an AI system covered by Annex I, you will have to perform the transparency checks under Article 50 and the GPAI rules.

The Article 6(3) derogation. If you are in the Annex III, Article 6(3) lets you exit the high-risk obligation set where: The system concerned does not represent a substantial risk to health, safety or fundamental rights; Or the system is merely improving a completed human activity; Or the system merely detects decision-making patterns, but does not replace the human decision-maker; Or the system is preparatory to other systems. Document: Article 6(4); Register: Article 49(2). The derogation no longer applies if the system profiles natural persons.

The best-spent compliance dollar in a GenAI program is the Article 6 classification artifact, not a tool purchase — it sets the specification every downstream procurement is graded against.

Your role in the value chain

The pivot most GenAI teams underestimate is the Article 25 substantial-modification rule: a deployer becomes a provider (the "full provider set" includes Article 11 documentation and Article 43 conformity assessments) if the deployer puts their own name on the system, substantially modifies it, or changes its intended purpose to a high-risk one.

Start with three ordinary product moves. A prompt-and-RAG layer over a third-party API is usually deployer territory: Article 26 instructions for use, oversight, input-data control, monitoring, log retention, and FRIA where applicable. Fine-tuning that materially changes intended purpose is provider territory. Rebrand or white-label the system and the answer is even shorter: provider, regardless of who built the weights.

The deployer-to-provider transition is the most expensive line in a GenAI compliance roadmap. For each high-risk system, get a legal-signed Article 25 memo that names the role and explains if fine-tuning, prompt scaffolding, productisation, etc. does or does not constitute substantial modification.

The high-risk obligation set, mapped to operating reality

Articles 9 through 17 carry the operational load. Read them with a pencil in your hand. Some duties drop into controls you already have; others expose places where the AI system behaves unlike ordinary software.

Articles 9 and 10 are the risk and data layer. Article 9 asks for an iterative lifecycle that ties evaluation back into post-market monitoring. ISO 31000 gives you the bones, but hallucination, prompt injection, and training-data drift need their own risk language. Article 10 does the same for data: training, validation, testing quality, bias examination, documented collection. The bias-and-representativeness question runs past anything 27001 classifies.

Article 11 anchors the documentation pile to the Annex IV outline. Assemble that pack continuously from observability, evaluation, and risk-management artifacts rather than treating it as a one-shot deliverable. Article 12 then fixes what the logs feeding Articles 72 and 73 must contain: prompts, retrieval context, tool calls, model versions, policy decisions, and the user-attribution metadata that lets an investigator stitch an incident together months later.

Articles 13 and 14 sit at the deployer interface. Article 13 transparency is largely a procurement contract deliverable from the upstream provider. Article 14 is more uncomfortable. A reviewer needs real affordances: override, refuse-to-use, monitor, intervene. If the UI only lets them click approve faster, oversight is cosmetic. Runtime guardrail patterns (block, regenerate, flag, modify, escalate) are the operational surface for this; ABV's published catalog is one vendor reference among several.

Article 15 (accuracy, robustness, cybersecurity) is where the adversarial-ML vocabulary lives, against ENISA's Securing Machine Learning Algorithms and the OWASP Top 10 for LLM Applications. Articles 16 and 17 matter after Article 25 has flipped you to provider. ISO 9001 or 27001 can carry the QMS frame; evaluation discipline and model-change control are the missing pieces.

27001 and SOC 2 already cover perimeter cybersecurity, access control, supplier management, and information classification — that part of the lift is done. The work that is not done, and that this article keeps pointing at, is Articles 9 and 10 GenAI risk and data, Article 11/Annex IV documentation discipline, Article 12 logging granularity, and Article 14 oversight design.

The cross-walk: EU AI Act × ISO/IEC 42001:2023 Annex A × NIST AI RMF

Treat the mapping below as a working draft of your own crosswalk, not a finished deliverable. I would not hand this to counsel as the answer. I would hand it to the AI risk owner, the ISO owner, and the engineering lead and ask: which rows can we prove today?

Start with the build-time controls.

Then map the operator, market-entry, and post-market controls. This is where teams often discover that the "AI governance project" is partly procurement, partly incident response, and partly release engineering.

The three vocabularies have different jobs. ISO 42001 gives the management-system skeleton. NIST AI RMF gives the function vocabulary. The GenAI Profile names the failure-mode actions. Useful. But none of them substitutes for conformity-assessment evidence; they lower the cost of producing it by giving you reusable controls.

GPAI and adjacent-regime overlap

Paragraph from article 53(1): GPAI providers shall (i) maintain the annex XI technical documentation; (ii) provide access to the annex XII downstream-integrator documentation; (iii) apply a policy to ensure copyright compliance within the Union; and (iv) make available a summary of the training content that is detailed enough. If you use a model provided by OpenAI, Anthropic, Google, or another similar company, the Annex XII pack is the artifact to request — its absence is a contracting risk.

Article 53(2) provides a carve-out for free and open-source GPAI models with publicly available weights, architecture, and usage information, and with no systemic risk, in relation to the paragraph 1(a) and (b) duties. This is a carve-out only for the GPAI provider's paperwork (Paragraph 1(a)-(b) duties). It does not carve out the deployer's Article 25 or 9-17 duties. The presumption of systemic risk for GPAI models is 10^25 training FLOPs (Article 51). Systemic-risk GPAI providers have duties under Article 55 (adversarial evaluation; systemic-risk assessment, mitigation, and incident reporting; cybersecurity). These are due diligence considerations for you.

Adjacent regimes to deduplicate, not duplicate: Article 27 FRIA permits joint conduct with the GDPR Article 35 DPIA - build one, use one. GDPR Article 22 and AI Act Article 14 are not the same, but the same reviewer process applies to both. DORA and NIS2 incident pipelines are parallel, and apply to the same telemetry, Article 73. A GenAI feature in a medical device still needs to be MDR compliant (and Article 43 is not an alternative to it).

Conformity assessment, declaration, and CE marking

Article 43 gives two routes: Annex VI internal control for the Annex III system (by the provider) against the Annex IV documentation; or Annex VII notified-body assessment of Annex III(1)(a) biometric remote identification. In both cases, the provider must issue the Article 47 EU declaration of conformity (which must be kept for 10 years), and the Article 48 CE marking. The system is registered by means of Articles 49 and 71. Article 99(5) lays down that non-compliant documentation, including incorrect, incomplete, or misleading information, can expose the provider to fines of up to EUR 7.5 million or 1% of worldwide annual turnover. Harmonised standards have not yet been established. ISO/IEC 42001 is the management system standard for reference.

Post-market monitoring, logging, and the serious-incident pipeline

Articles 12, 19, 72, and 73 make up one loop: logs → post-market monitoring → reporting → competent authority

Logging. Minimum GenAI log set: prompt, response, retrieval context (for RAG), tool calls and results, policy/guardrail decisions, user attribution, model version. At least six months retention after deployment.

Article 73 reporting windows: 15 days for incidents not causing death; 10 days if the incident caused death; two days for serious irreversible disruption to critical infrastructure, or a widespread infringement of personal rights (the latter being a broad definition). Article 73(6) is the relevant one for the system itself: providers and deployers must not carry out investigations that change the system in any manner that might affect the evaluation of the incident, unless they first consult the relevant authority. In short, the SRE reflexes of rolling back, retraining, or hot-patching the system because a model emitted something bad can be an Article 73 violation. The runbook should have a hard gate between "we believe this is a serious incident" and making any changes to the model surface.

Tag each incident with the OWASP LLM taxonomy category (prompt injection is LLM01, insecure output handling is LLM02, training data poisoning is LLM03, supply chain is LLM05, sensitive information disclosure is LLM06) and the article this incident was mapped to.

The procurement checklist

Two parts. First, the vendor questions. Then the internal homework you should finish before procurement starts.

For the vendor: ask whether the platform produces and stores the Article 6 artifact itself, including 6(3) derogation reasoning and 49(2) registration record, or whether it assumes counsel already wrote the classification memo. That answer should land against A.6.1 and GOVERN 1.3. Then make them show the Article 9 lifecycle in the product: evaluation result, risk treatment, post-market monitoring, back again. Slideware does not count. The ISO/NIST anchors are A.6.1, A.6.2, and MAP 2.3.

Do the same for data and documentation. For Article 10, ask what data-quality examination looks like on a live dataset: bias-detection method, sampling rationale, retained documentation. That is A.7.2, A.7.3, and MEASURE 2.2. For Article 11 and Annex IV, ask whether design evidence, monitoring evidence, performance metrics, risk-management documentation, lifecycle changes, and the post-market plan can be assembled on demand. Quarterly export? Too slow. Map it to A.6.3, A.10.1, and MAP 4.2.

Now pressure-test operations. Article 12 requires prompts, responses, retrieval context, tool calls, policy decisions, user attribution, and model versions at Annex IV-compliant retention, queryable during an incident investigation. A.7.5 and MEASURE 3.1. Article 13 documentation should be usable by an Article 26 team without an internal translator. A.10.1 and GOVERN 4.1. Article 14 oversight should wire block, regenerate, flag, modify, and escalate actions into a reviewer queue with an audit trail. A.6.4 and MANAGE 2.3.

The last vendor questions are the ones people often leave for legal review and then regret. Which Article 15 adversarial failure modes does the evaluation suite cover: hallucination, prompt injection, jailbreak, data leakage? What cadence? A.6.5, A.8.4, and MEASURE 2.5. Does the Article 27 FRIA compose with the DPIA workflow on shared input data? A.6.2 and MAP 1.5. For any GPAI routed through the platform, is the Article 53 Annex XII downstream-deployer pack supplied or passed through? A.10.2 and GOVERN 6.1. Where does Article 72 monitoring live, what telemetry feeds it, and who sees continued-compliance regressions? A.7.5, A.9.3, and MEASURE 3.3. For Article 73, ask to see 15-day, 10-day, and two-day reporting workflows with the authority-notification gate before model mutation. A.9.4 and MANAGE 4.2. Then ask the dull deployment questions: EU data residency, GDPR Article 28 DPA, HIPAA BAA where applicable, and on-premises or single-tenant VPC for restricted-egress workloads.

Internal homework comes first. Have an Article 6 classification memo per in-scope system and an Article 25 role memo that names fine-tuning, prompt scaffolding, or rebrand as substantial modification or not. Keep a single inventory of GenAI systems, models, agents, and integrations, with shadow-AI discovery wired in. The classic failure is the marketing team's RAG bot that nobody catalogued. That is the kind of thing that trips Article 26 audits.

Your existing 27001 and SOC 2 control coverage should already be crossed against AI Act Articles, with gaps named and budgeted. ISO/IEC 42001 AIMS should be populated against the cross-walk above. NIST AI RMF and the GenAI Profile should trace into the same control catalog by subcategory ID. Build one combined FRIA-and-DPIA template for Article 27 and GDPR Article 35. Confirm Annex IV-retention logging end-to-end on a sample incident. Put the Article 73 15-day, 10-day, and two-day windows in the runbook, along with the 73(6) authority-notification gate.

Only then score vendors. Weight Articles 11, 12, 14, and the Article 53 GPAI pass-through heavily, and make sure the Article 43 process (classification, role, FRIA/DPIA) is signed off by counsel before vendor demos. Procurement goes faster when the internal artifact set is boring.

The next five weeks

A working sequence, written as the calendar would actually fill it. By the end, you want four artifacts a notified body or competent authority would ask for first.

Week one: classification and role. Inventory every in-scope GenAI system. For each one, draft the Article 6 classification memo, the Article 25 role memo, and a one-line note on where the Annex IV evidence already lives. "Scattered across observability dashboards" is an acceptable week-one answer. A blank is not.

Week two: the cross-walk. Populate the AIMS Annex A control catalog against the table above, with NIST AI RMF subcategories and GenAI Profile actions attached to rows you already operate. Name the gaps. Seriously, name them. An unnamed gap is the one auditors find.

Week three: logging and oversight. Audit the AI-specific log set against Article 12. Then look at the human-oversight workflow under Article 14 and check for the four real affordances: override, refuse-to-use, monitor, intervene. Missing telemetry should get wired now, not put in the "future platform work" column.

Week four: incident pipeline. Build the Article 73 workflow against 15-day, 10-day, and two-day calendar logic, add the 73(6) authority-notification gate before any model surface change, and run a tabletop on a prompt-injection-driven harmful output. The tabletop is where teams discover who actually has authority to pause the model.

Week five: procurement and sign-off. Score vendor candidates against Part A. Confirm the combined FRIA/DPIA template with legal. Lock the Article 43 route: Annex VI internal control for most Annex III systems, Annex VII notified-body assessment for biometrics.

After 2 August 2026: Article 43 conformity assessment, Article 47 declaration, Article 48 CE marking, and 49/71 registration – for any system where Annex III applies from 2 December 2027. Use the postponement period to gather the evidence, rather than carrying it over to the end.

Next step from the cross-walk

If this reader, for instance, has been troubled by a single "Act" cliff that will be on 2 August 2026, they will now have three documents they can look at: one categorising what the standard (per system) classification is, one standardising naming of the existing standard(s) (in this case 27001, or SOC 2, or 42001, or AI RMF) and one procurement checklist (what the platform operator needs to do, if anything, that is not already captured in the existing stack).

The ABV AI management system is aligned with the ISO/IEC 42001 AI management system standard (see docs.abv.dev/security/compliance), as well as the ISO/IEC 27001 information security management system standard. The GenAI control plane - observability, runtime guardrails, evaluation, LLM gateway, prompt management, and compliance automation - is implemented for the Build, Launch, Operate, and Comply phases. If you have the classification artifact and cross-walk and want help mapping the existing program to Articles 9 -17, we can conduct a readiness working session to produce the gap list and procurement scoring rubric.

FAQ

What are the fine bands for non-compliance with the EU AI Act?

Article 99 sets three bands. Prohibited Article 5 practices: up to EUR 35 million or 7% of worldwide annual turnover. Breach of operator and notified-body obligations: up to EUR 15 million or 3% of turnover. Supplying incorrect, incomplete, or misleading information to notified bodies or competent authorities: up to EUR 7.5 million or 1% of turnover. Article 99(6) caps SME and start-up fines at the lower of the two.

We're a US company that does not sell into the EU, but our model produces outputs that reach EU users — does the Act apply to us?

Yes, when the output is used in the Union. Article 2 covers providers placing systems on the EU market and deployers established outside the Union where the output is used in the Union. A US-based RAG service whose answers reach EU end users via a customer's product would be in scope. The consequence: an authorised representative under Article 22, plus the same Article 11, 12, and 14 evidence as any in-Union provider.

Does a prompt-injection-driven harmful output count as a serious incident under Article 73?

It can. A serious incident under Article 73 may result in death, serious harm to health, serious damage to property or environment, serious and irreversible disruption to critical infrastructure, or infringement to fundamental rights. An immediate injection that results in the system leaking personal data, producing unlawful decisions, or encouraging unsafe behavior from the operator qualifies. The injection is the cause, the Article 73 test is the effect.

If we consume a foundation model via OpenAI, Anthropic, Google, etc., are we the provider or the deployer?

Deployer of the foundation model. You are a provider of the high-risk AI system based on the foundation model — unless you put the foundation model on the market under your own brand, substantially modify it, or change its purpose in accordance with Article 25. In any case, the upstream provider of the foundation model owes you the Annex XII pack under Article 53(1)(b) in any event.

Can a single human reviewer satisfy Article 14 human oversight if they approve thousands of model outputs per day?

Almost never. Article 14 says that the person has to be able to understand the capabilities and limitations of the system, monitor its operation, interpret its output, and override or reject it. A reviewer rubber-stamping high-volume output cannot satisfy "correctly interpret" or "decide not to use" — design must reduce the rate, raise the threshold so only consequential cases hit the queue, or distribute review across a team with the time and expertise.