EU AI Act compliance for high-risk systems has become a production audit problem: as of 21 June 2026, Annex III obligations still apply from 2 August 2026, and Article 99 fines can reach EUR 15 million or 3% of global turnover for provider, deployer, and transparency failures.
EU AI Act compliance means proving, with evidence, that each high-risk AI system has lifecycle risk management, governed data, current technical documentation, replayable logs, human oversight, validated performance, and a quality system. The useful unit is an artefact: a register, card, runbook, test report, or retained log.
TL;DR: The proposed Digital Omnibus would move Annex III high-risk obligations to 2 December 2027 and product-embedded high-risk obligations to 2 August 2028, according to the European Parliament file. As of the publish date, that delay still awaits final procedural completion and publication. Engineering teams should keep building against the enforceable 2 August 2026 date until the law changes.
Key Takeaways
- The first audit gap is usually evidence, not policy. A policy that says "we manage AI risk" has little value unless it points to current risk decisions, dataset lineage, logs, and signed-off controls.
- Article 9 is the operating system. Risk management has to be a continuous lifecycle process tied to model changes, post-market monitoring, and release gates.
- Vendors reduce work, they do not erase deployer duties. Article 26 still requires deployers to assign oversight, monitor operation, and retain logs for at least six months.
- Open-source and SME status are limited answers. They may change some obligations or penalty exposure, but they do not remove high-risk duties when the system is in scope.
- ISO/IEC 42001 helps with QMS structure. It is not, by itself, proof of AI Act conformity as of 21 June 2026.
What Does EU AI Act Compliance Require by August 2026?
The operative calendar is the uncomfortable part. The AI Act’s implementation timeline lists 2 August 2026 as the date when the remainder of the Act starts applying, except Article 6(1), and separately notes high-risk operator obligations for systems already placed on the market when significant design changes occur after that date (implementation timeline).
The Digital Omnibus creates uncertainty because it may move the deadline. The Parliament’s June 2026 process supports postponement of some AI Act rules (Parliament press release), but compliance teams should separate legislative probability from current enforceability.
Article 99 is the financial forcing function. Non-compliance with prohibited practices can reach EUR 35 million or 7% of global turnover, while operator and transparency failures can reach EUR 15 million or 3% (Article 99).
For SMEs and startups, Article 99 uses the lower of the percentage or monetary cap for the relevant tier. That reduces penalty exposure, but it does not create a size-based exemption from high-risk obligations.
Which Systems Are High Risk AI Systems?
Article 6 creates the classification problem engineering teams need to solve first. A system may be high-risk through the product-safety route, the Annex III standalone route, or a self-classification analysis under Article 6(3).
Article 2 also gives the Act extraterritorial reach. It covers providers placing systems on the EU market and providers or deployers in third countries where the AI system’s output is used in the Union (Article 2 summary in the Service Desk).
| Route | Typical systems | Engineering action |
|---|---|---|
| Annex I product route | AI embedded in products covered by EU harmonisation law, such as medical devices or machinery | Map product legislation, conformity assessment path, and model-change controls |
| Annex III standalone route | Biometrics, employment, education, essential services, law enforcement, migration, justice | Build high-risk evidence pack unless a documented Article 6(3) exception applies |
| Article 6(3) self-classification | Annex III system claimed to pose no significant risk | Preserve the assessment before market placement and prepare for authority review |
The most dangerous shortcut is treating "we use a foundation model" as the classification answer. The Act classifies systems by intended purpose and deployment context, so the same model can sit inside a low-risk drafting tool or a high-risk employment screening workflow.
The AI Act Engineering Audit: 10 Gaps to Fix First
An AI Act engineering audit should ask one question repeatedly: can this control be replayed by someone outside the team? If the answer depends on a staff engineer remembering what happened six months ago, the control is too weak.
| Priority | Audit gap | Article basis | Evidence an auditor will expect |
|---|---|---|---|
| 1 | Missing or stale risk register | Article 9 | Lifecycle risk register with owners, mitigations, residual risk, and review dates |
| 2 | Dataset lineage gaps | Article 10 | Dataset cards, provenance, representativeness evidence, bias assessment |
| 3 | Logging gaps | Articles 12 and 26 | Automatic event logs tied to system and model versions, retained at least six months where under deployer control |
| 4 | Human oversight gaps | Article 14 | Oversight playbook, escalation path, override mechanism, automation-bias training |
| 5 | Post-market monitoring gaps | Article 72 | PMM plan, live telemetry, feedback intake, drift and incident review |
| 6 | Incident reporting gaps | Article 73 | Serious-incident runbook, causal-link process, 15-day reporting chain |
| 7 | Transparency gaps | Article 13 | Instructions for use, capabilities, limits, foreseeable misuse, accuracy metrics |
The theme is boring and consequential. Auditors will look for artefacts that connect legal obligations to system behaviour: what was released, what data trained or validated it, who accepted residual risk, which logs prove how it behaved, and which human could stop it.
Article 9 AI Act: Risk Management Is the Backbone
Article 9 requires a risk management system to be established, implemented, documented, and maintained for high-risk AI systems. The AI Act text describes it as a "continuous iterative process" across the lifecycle (Act texts).
That means a one-time launch review is structurally wrong. Risk review should be triggered by model changes, data changes, intended-purpose changes, monitoring signals, serious incidents, and new foreseeable misuse patterns.
A useful Article 9 risk register looks closer to release engineering metadata than a legal spreadsheet:
system_id: hr-screening-ranker-eu
article6_route: annex_iii_employment
intended_purpose: rank job applications for recruiter review
model_version: 2026-06-12
data_version: applicants_eval_eu_2026_q2
risk_owner: ai-governance
hazard: protected-group ranking disparity
foreseeable_misuse: automated rejection without recruiter review
affected_groups: applicants in EU hiring processes
mitigation: threshold audit, recruiter override, adverse-impact review
residual_risk: medium
acceptance_criteria: disparity ratio within approved band, reviewed monthly
evidence_links:
- dataset_card
- bias_eval_report
- oversight_playbook
review_trigger: model_update, data_update, drift_alert, incident
The important fields are the ones that make accountability durable. A risk entry needs an owner, a current model version, a mitigation, residual-risk acceptance, and links to the evidence that supports the decision.
Data, Logs, and Oversight Are the Controls Auditors Can Replay
Article 10 requires training, validation, and testing datasets to be governed for the intended purpose, including origin, preparation, assumptions, suitability, possible bias, and gaps (Act texts). In engineering terms, a dataset card should become a required dependency for every high-risk model release.
Dataset cards should answer five questions without a meeting: where the data came from, what it represents, which groups may be underrepresented, which transformations changed it, and which bias tests were run. If a model was fine-tuned, re-ranked, or evaluated on internal data, the card needs to cover that layer too.
Article 12 requires high-risk AI systems to technically allow automatic event logging over their lifetime. Article 26 adds the deployer-side retention rule: deployers must keep logs under their control for a period appropriate to the intended purpose and at least six months, unless other law says otherwise.
Logging should capture enough context to reconstruct operation: system ID, model or prompt version, input class, output class, human review status, override action, timestamp, and downstream decision reference. Avoid storing raw sensitive data where hashed references, redaction, or controlled access can preserve traceability.
Article 14 is where many AI governance controls fail in practice. Human oversight requires people with competence, training, authority, and support, plus the ability to disregard, override, reverse, or interrupt a system through a safe stop procedure.
That last part matters. A dashboard that shows a score does not prove oversight if the operator cannot understand the limitation, challenge the output, or route the case to a fallback process.
Can Your Vendor Cover Your EU AI Act Compliance?
Vendor evidence is useful, especially when it maps controls to specific Articles. Microsoft’s EU AI Act Compliance page is notable because it cites Article-level obligations and describes provider-side control support.
But deployers still need their own evidence. Article 26 makes deployers responsible for use according to instructions, competent human oversight, input-data relevance where they control inputs, monitoring, incident escalation, and log retention (Article 26).
The vendor-deployer split should become a procurement checklist:
| Vendor artefact | What it helps with | What remains yours |
|---|---|---|
| Model card or system card | Capabilities, limitations, test results, known risks | Intended-purpose fit, local misuse analysis, user instructions |
| Logging API | Technical traceability | Six-month retention, access controls, incident reconstruction |
| Security and benchmark reports | Article 15 evidence input | Your deployment threat model and acceptance criteria |
| Contractual Article 25 allocation | Role clarity across the value chain | Deployer duties under Articles 26 and 27 |
Open-source status also needs careful handling. The research snapshot found that the open-source carveout is narrow and anchored mainly to GPAI obligations; Recital 102 does not remove Articles 9-17 duties for a high-risk system placed on the EU market.
A 30/60/90-Day AI Compliance Checklist for Engineering
If you are starting on 21 June 2026, the first two tracks need to run in parallel because the current Annex III enforcement date is 2 August 2026. Treat this as a release-readiness sprint with legal review embedded, rather than a documentation project parked outside engineering.
By 21 July 2026: classify and inventory. Map every AI system to Article 6: Annex I product route, Annex III standalone route, or documented Article 6(3) self-classification. Record provider, deployer, importer, distributor, and authorised representative roles, especially for non-EU providers.
Before 2 August 2026: build the minimum audit pack. Stand up the Article 9 risk register, Article 10 dataset cards, Annex IV technical documentation, Article 12 logging, Article 13 instructions for use, Article 14 oversight playbook, Article 15 benchmark and cybersecurity reports, and Article 17 quality-management procedures.
By 20 August 2026: harden operations. Connect logs to incident review, wire risk decisions into release gates, make human override measurable, and verify six-month log retention under deployer control.
By 19 September 2026: close post-market loops. Build the post-market monitoring plan, serious-incident reporting runbook, and Article 27 fundamental rights impact assessment where required.
Article 73 sets the serious-incident clock: reports are due no later than 15 days after the provider, or where applicable the deployer, becomes aware of the serious incident, with shorter windows for widespread infringements or deaths. The Commission also issued draft guidance and a reporting template for serious AI incidents in 2026 (Commission consultation).
What This Means for You
The practical move is to turn AI governance controls into engineering gates. A high-risk release should fail if it lacks a current risk entry, dataset card, logging configuration, oversight assignment, benchmark report, security review, and post-market monitoring hook.
Do not wait for harmonised standards to rescue the programme. ISO/IEC 42001 can help structure the quality management system (ISO 42001 overview), but as of 21 June 2026 the research found no Official Journal-cited harmonised standard conferring presumption of conformity for high-risk AI Act obligations.
The best AI compliance checklist is simple to state and hard to fake: every legal claim should point to a living artefact, every artefact should point to a system version, and every system version should be replayable from logs, data, approvals, and monitoring records.
Sources
- Implementation Timeline, EU Artificial Intelligence Act
- European Parliament Digital Omnibus on AI report, A10-0073/2026
- MEPs support postponement of certain rules on artificial intelligence
- AI Act Service Desk, Article 99: Penalties
- AI Act Service Desk, Article 6: Classification rules for high-risk AI systems
- The Act Texts, EU Artificial Intelligence Act
- AI Act Service Desk, Article 12: Record-keeping
- AI Act Service Desk, Article 13: Transparency and information to deployers
- AI Act Service Desk, Article 26: Obligations of deployers
- AI Act Service Desk, Article 27: Fundamental rights impact assessment
- AI Act Service Desk, Article 73: Reporting of serious incidents
- Microsoft Trust Center: EU AI Act Compliance