The compliance calendar moved. On June 29, 2026, the Council of the EU gave final approval to the AI Act “digital omnibus” simplification package, following the European Parliament’s formal endorsement on June 16 — confirming a deferral first agreed in provisional form on May 6–13, 2026. Stand-alone high-risk AI systems under Annex III now have until December 2, 2027 to comply, and high-risk systems embedded in regulated products (medical devices, machinery, vehicles) have until August 2, 2028 — both pushed back from the original August 2, 2026 date (Council of the EU, June 29, 2026). Article 50’s transparency obligations were largely left alone: August 2, 2026 remains an active compliance date for those, with only a four-month grace period on watermarking requirements, to December 2, 2026.
Sixteen months of additional runway on the headline high-risk deadline is real relief, and engineering teams that had been treating August 2026 as an immovable wall should recalibrate. But the deferral changes the calendar, not the underlying requirements, and it does not touch Article 50 at all. What the new timeline means in practice for engineering teams is still not what most compliance briefings emphasize: this was never primarily a legal problem. It is an instrumentation problem, and the instrumentation most production AI stacks lack does not get built in a sprint regardless of which year the deadline lands in.
The high-risk articles — Articles 9 through 15 — are not abstract policy statements. They specify what an AI system must be able to demonstrate, document, and log to be conformant. The gap between those requirements and the observability posture of most production AI systems is substantial. Systems deployed for high-risk purposes that were instrumented for performance and reliability, but not for regulatory evidence production, are likely non-compliant in ways that require architectural changes, not document drafting.
What Articles 9–15 Actually Require
The compliance-relevant content of the high-risk section is specific enough to map directly to engineering tasks. Working through each article as a requirements document is more useful than treating them as policy abstractions.
Article 9 (Risk Management System) requires a continuous and systematic risk management process across the AI system’s lifecycle. This is not a one-time pre-deployment assessment. The system must support ongoing identification of known and reasonably foreseeable risks — including risks arising from foreseeable misuse, not just intended use. Post-market monitoring data must feed back into the risk management process. Operationally, this means a live system needs a mechanism for surfacing anomalous behavior and routing it to a risk assessment workflow.
Article 10 (Data Governance) establishes that training, validation, and testing datasets must be relevant, representative, free of errors, and complete to the extent possible. For high-risk applications, data lineage documentation — where the training data came from, how it was processed, what known biases or gaps it carries — needs to exist and be recoverable. This is a data engineering artifact, not a legal one, and it needs to have been maintained during model development.
Article 11 (Technical Documentation) requires documentation sufficient to allow competent authorities to assess compliance without reverse-engineering the system. The mandatory content per Annex IV includes system description, intended purpose, performance metrics across relevant conditions, training methodology, and the risk management measures applied. This documentation must exist before deployment and be updated as the system changes. A 10-year retention period applies under Article 18.
Article 12 (Automatic Logging) is where the gap is sharpest. High-risk systems must be capable of automatically recording events throughout their operational lifespan. Logs must be retained for a minimum of six months and must capture enough information to reconstruct the system’s behavior in situations where risk is identified. Regulators expect logs that capture inputs, outputs, and decision points with sufficient detail to support full traceability.
Most production AI systems log at a level appropriate for debugging and performance monitoring — request counts, latency percentiles, error rates. Capturing inputs and outputs per inference event for compliance retention is a different instrumentation posture. It carries storage implications, privacy implications (if inputs contain personal data), and data pipeline requirements that most stacks were not designed for.
Article 13 (Transparency) requires that high-risk systems be designed and documented so that deployers can understand their capabilities, limitations, and the conditions under which performance may degrade. System cards — documentation artifacts that describe the full deployed system’s behavior, not just individual models — align closely with this requirement.
Article 14 (Human Oversight) is a design requirement, not a policy statement. Systems must enable human overseers to understand what the system is doing, to detect anomalies and unexpected performance, and to intervene. The oversight mechanism must be built into the system architecture. A human with access to a dashboard who could, in principle, intervene is not the same as a system designed to surface decision-relevant information at the point where human intervention is meaningful.
Article 15 (Accuracy, Robustness, Cybersecurity) requires that systems perform reliably under normal and adverse conditions, resist manipulation and adversarial degradation, and maintain consistent performance throughout the lifecycle. Fallback mechanisms and uncertainty quantification are within scope. Systems that degrade silently on distribution shift — without surfacing uncertainty signals — are architecturally non-conformant.
The Instrumentation Gap Is Not Uniform
Not every AI system that touches a high-risk category is automatically a high-risk system under the Act. The classification depends on the use case, the sector, and whether the system is used as a safety component or makes autonomous decisions. Annex III lists the high-risk categories: biometric identification, critical infrastructure management, education, employment and worker management, access to essential services, law enforcement, migration and asylum, and administration of justice. Systems within these categories used in the EU are the immediate compliance target.
For systems that are clearly in scope, the instrumentation gap falls into three tiers:
Already-instrumented systems — those built with strong observability for quality assurance, with input-output logging for model monitoring, and with documented model cards and evaluation records — face primarily a documentation assembly and retention-period compliance problem. They are closest to conformant.
Systems with performance-oriented observability — logging aggregate metrics, latency distributions, and error rates, but not per-inference event data — face a genuine instrumentation change. Adding event-level logging, ensuring human oversight tooling actually exposes decision-relevant data, and building the retention pipeline are architectural tasks that require engineering time.
Systems that were shipped without structured evaluation documentation — no model cards, no systematic risk assessment, no training data governance records — face the largest gap. The documentation required by Articles 11 and 10 cannot be reconstructed after the fact from a production system; it describes the model development process that was or was not followed.
Conformity Assessment and What It Looks Like in Practice
For most high-risk AI systems, the conformity assessment path is self-assessment by the provider, resulting in CE marking and registration in the EU AI Act database. Third-party notified body assessment is mandatory only for a subset of high-risk systems (primarily biometric systems and certain critical infrastructure applications).
Self-assessment still requires producing the complete set of evidence specified in Annex IV: technical documentation, risk management records, data governance documentation, evaluation results, and post-market monitoring plans. Organizations that have treated compliance as a documentation exercise are discovering that the documents depend on records that need to have been maintained during system development and deployment — and that absent records cannot be constructed from current system state.
The penalty structure provides context for the stakes: non-compliance with Article 16 obligations (provider obligations for high-risk systems) is subject to fines up to €15 million or 3% of global annual turnover. That ceiling applies to failures to meet the technical requirements, not just to prohibited AI uses.
What Engineering Teams Need to Build
The concrete engineering tasks that close the compliance gap fall into three areas:
Event-level inference logging with retention. A log pipeline that captures inputs, outputs, and decision points per inference event, with configurable retention (six months minimum under Article 12, with longer retention for post-market monitoring). If inputs contain personal data, the logging architecture needs to support pseudonymization or differential access controls consistent with GDPR — the two regulatory regimes interact.
Human oversight interfaces that surface decision-relevant data. Article 14 compliance is not satisfied by a generic dashboard. Oversight tooling needs to present the information a human would need to identify anomalous behavior and to intervene. For high-risk domains — employment screening, credit scoring, medical triage support — this typically means exposing the features or inputs that drove a decision, not just the output.
Post-market monitoring infrastructure. The risk management obligation under Article 9 is continuous, which means the deployed system needs a mechanism for detecting performance degradation, distribution shift, and anomalous behavior after deployment — not just at pre-deployment evaluation. This is MLOps-adjacent work: data drift detection, performance monitoring against held-out evaluation sets, and a workflow for routing anomalies to risk assessment. The held-out sets themselves are only as trustworthy as the evaluation methodology behind them — see what a credible evaluation pipeline requires once benchmark contamination is accounted for for the design considerations that carry over directly into post-market monitoring evidence.
Documentation pipelines for Article 11. Technical documentation needs to be structured to match Annex IV requirements and kept current as the system changes. Treating model cards and system cards as living documents — updated at each significant model version and retained for the required period — is the most practical path to maintaining this, and it overlaps substantially with the documentation practices already recommended by voluntary frameworks like NIST AI RMF and ISO/IEC 42001, which many teams will already have partially implemented.
The Revised Calendar, and Why It Still Isn’t Slack Time
December 2, 2027 is now the operative deadline for stand-alone high-risk systems, and August 2, 2028 for product-embedded ones. Organizations that were racing to complete conformity assessment, CE marking, and database registration against an August 2026 wall have a genuine, legislatively confirmed extension. That extension does not apply to Article 50: systems with transparency obligations — chatbots, synthetic content, emotion-recognition and biometric-categorization systems, deepfake generation — still need to meet those requirements on the original schedule, with only the watermarking-specific grace period running to December 2, 2026.
The instrumentation gap this piece is about — logging, documentation, oversight tooling, post-market monitoring — takes engineering quarters to close for systems that were never built with regulatory evidence production in mind, not weeks. Sixteen months is meaningfully more runway than four months, but the conformity assessment process — assembling Annex IV documentation, conducting the risk management review, and completing database registration — is still not a rapid exercise for systems with real documentation gaps. Organizations that have not begun this process should treat the engineering work as a parallel track to ongoing development, not a pre-launch checklist item to start once the new deadline gets close. The Act’s lifecycle requirements — continuous risk management, ongoing logging, post-market monitoring — mean compliance is not a state achieved once at deployment; it is an operational posture maintained across the system’s life, and that structural reality is unchanged by which calendar year the first conformity deadline falls in.
Frequently Asked Questions
Which AI systems are high-risk under the EU AI Act?
High-risk AI systems are defined by Annex III of the Act. The categories include biometric identification and categorization; safety components of critical infrastructure; educational or vocational training systems that determine access or outcomes; employment and worker management systems; access to essential private or public services; law enforcement systems; migration and asylum management; and administration of justice. Systems used in these categories within the EU, where they make or significantly influence decisions affecting individuals, are the primary scope.
What does Article 12 require for logging?
High-risk systems must automatically record events throughout their operational lifespan to enable traceability, especially in situations where risk is identified. Logs must support reconstruction of the system’s behavior and must be retained for a minimum of six months. Regulators expect logs that capture inputs, outputs, and decision points — not just aggregate performance metrics. A 10-year retention requirement applies to the technical documentation specified in Article 11 under Article 18.
Is self-assessment sufficient for most high-risk systems?
For most high-risk systems, yes. Third-party notified body assessment is mandatory primarily for biometric systems and certain critical infrastructure applications. For the broader Annex III categories, providers conduct self-assessment, produce the Annex IV documentation package, and register in the EU AI Act database. Self-assessment still requires complete evidence production; it does not reduce the substance of the requirements.
Did the EU AI Act’s high-risk deadline actually change?
Yes. The Council of the EU gave final approval on June 29, 2026 to an AI Act “digital omnibus” simplification package, following the European Parliament’s endorsement on June 16, 2026. It deferred the application date for stand-alone Annex III high-risk AI system obligations from August 2, 2026 to December 2, 2027, and for high-risk systems embedded in regulated products from August 2, 2027 to August 2, 2028. The deferral is legislatively confirmed, not a proposal — organizations should plan against the new dates.
Does the deferral affect Article 50 transparency obligations too?
No. Article 50’s transparency obligations — covering chatbots and other systems that must disclose they are AI, synthetic and manipulated content, and emotion-recognition or biometric-categorization systems — remain on the original schedule, with a compliance date of August 2, 2026. The only adjustment is a four-month grace period specifically for watermarking requirements, extending to December 2, 2026. Teams building systems in scope for Article 50 should not assume the broader Annex III deferral applies to them.
How does the EU AI Act interact with GDPR when logging inference inputs?
If inference inputs contain personal data — which is common in employment, healthcare, and financial applications — logging them for Article 12 compliance creates GDPR processing obligations. A lawful basis for processing is required; data minimization principles apply; and data subjects’ rights must be accommodated. The GDPR and EU AI Act interact here, and organizations need both a technical architecture (pseudonymization, access control) and a legal basis documented in their data protection records. The two regimes do not conflict in principle but require coordinated legal and engineering design.