ComplianceEU AI Act in September 2026: What Applies Now After the Digital Omnibus
The EU AI Act is broadly applicable, but the 2026 Digital Omnibus created a split operating calendar. This updated briefing maps active duties, the December 2026 synthetic-content transition, and the revised 2027-2028 high-risk deadlines.
Accuracy-reviewed by the editorial team
Updated September 2, 2026: The EU AI Act became broadly applicable on 2 August 2026, but the implementation picture is not the one many 2024 compliance plans assumed. Regulation (EU) 2026/1744, the Digital Omnibus on AI, changed the timetable for high-risk systems shortly before the main application date. The result is a split calendar: many governance and transparency duties are active now, some amended prohibited-practice and synthetic-content provisions take effect in December 2026, general-purpose AI obligations have applied since August 2025, and the principal high-risk-system requirements move into 2027 and 2028. Organizations should update control maps to the amended law instead of treating every obligation as either fully live or uniformly delayed.
What is already live in September 2026
The AI Act’s general application date remains 2 August 2026. The consolidated legal text shows Chapters I and II applying from February 2025 subject to newly amended exceptions, Chapter III Section 4 and several other governance and enforcement provisions applying from August 2025, and Articles 102 through 110 applying from 27 July 2026. The practical point is that the Digital Omnibus changed selected dates; it did not suspend the entire AI Act.
Organizations should therefore maintain an inventory that distinguishes legal role, intended purpose, system category, geography, and obligation family. A provider, deployer, importer, distributor, and authorized representative do not inherit the same responsibilities. Those roles depend on facts such as who places the system on the market, whose name or trademark is used, who substantially modifies the system, and how the system is actually deployed.
Transparency work should be treated as an operating control. Teams need to know where people encounter AI, where synthetic or manipulated content is produced or published, who owns disclosures, and how the disclosure is tested across interfaces and channels. A policy document is weak evidence on its own. Stronger evidence connects the inventory record to the product surface, disclosure text, owner, test result, exception rationale, and change trigger.
December 2, 2026 is the next near-term transition date
The Digital Omnibus added a specific transition for providers of AI systems, including general-purpose AI systems, that generate synthetic audio, image, video, or text content and were placed on the market before 2 August 2026. Those providers must take the necessary steps to comply with Article 50(2) by 2 December 2026. That makes synthetic-content provenance and marking a near-term engineering issue rather than something organizations can postpone until the later high-risk dates.
The amendment also moved selected prohibited-practice provisions added by the Digital Omnibus to 2 December 2026. Teams maintaining policy maps should therefore avoid a single status field that says ‘Article 5 active’ without identifying the paragraph and amendment involved. The safest operating record captures the specific article, applicability date, system facts, control owner, and evidence location.
For product teams, the useful question is whether a December deadline requires an actual technical or release change. If a system generates synthetic content, document the current output-marking mechanism, downstream transformations that could remove or alter it, API behavior, supported formats, customer responsibilities, and testing evidence. Where the organization is a deployer rather than the provider, preserve the provider’s documentation and identify which additional disclosure duties belong to the deployment context.
The Digital Omnibus moved the principal high-risk deadlines
Regulation (EU) 2026/1744 amended Article 113 so that Chapter III Sections 1, 2, and 3—other than the specified Article 6(5) exception—apply from 2 December 2027 for systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 for systems classified as high-risk under Article 6(1) and Annex I. The law explains that delayed standards, specifications, guidance, and national-authority readiness contributed to the revised timetable.
This is a legal delay, not evidence that preparatory work has no value. A provider waiting until the final quarter before the deadline will still need to confirm classification, establish data-governance controls, produce technical documentation, design logging, define human oversight, validate accuracy and robustness, connect cybersecurity testing to release governance, and establish post-market monitoring. Those activities can depend on procurement, architecture, engineering, and assurance cycles that are much longer than a few months.
The amended timetable makes classification discipline more important. Annex III use cases and Annex I product-related systems now have different principal dates. A single spreadsheet field called ‘high risk’ is therefore inadequate. Record the classification basis, article and annex reference, system role, geography, evidence owner, review date, and the event that would force reclassification.
Public-authority high-risk deployments have an additional transition point
The amended text also states that providers and deployers of high-risk AI systems intended to be used by public authorities must take the necessary steps to comply by 2 August 2030 in the relevant transition provision. Public-sector teams should not read that outer date as permission to ignore current procurement and architecture decisions. Systems procured now can remain in service for years, and contract terms established in 2026 may determine whether the authority can later obtain documentation, logs, testing evidence, version information, and remediation support.
For public-sector procurement, use the longer horizon to improve contract quality. Request role analysis, intended-purpose documentation, model and version information, data-flow information, human-oversight capabilities, logs, evaluation evidence, incident notification, material-change notice, and exit data. Make the evidence refreshable so the authority is not trying to reconstruct a 2026 procurement record in 2029.
Zeph Tech’s Public-Sector Technology Procurement Toolkit and Vendor Security Questionnaire can be used to preserve those evidence requests alongside the broader acquisition record rather than treating AI compliance as a separate legal attachment.
Earlier obligations still matter
AI-literacy duties and many prohibited-practice rules began applying in February 2025. Governance rules and obligations for providers of general-purpose AI models began applying in August 2025. The Digital Omnibus did not erase those earlier dates. Organizations should preserve evidence of training, prohibited-use controls, model-provider due diligence, escalation procedures, and role-specific governance rather than rebuilding the program only around the revised high-risk timetable.
AI literacy should reflect actual responsibilities. Procurement staff need to recognize product claims and contract gaps. Developers need to understand evaluation, logging, data handling, and misuse boundaries. Frontline deployers need to recognize where AI output cannot simply become a decision. Risk and legal reviewers need enough technical context to challenge intended-purpose and classification statements. Attendance records are useful, but role-specific objectives and practical checks are stronger evidence.
General-purpose AI governance also requires a supply-chain view. Record the model and version, provider terms, data-use settings, hosting route, retrieval sources, tools or actions the model may invoke, output destinations, and the trigger for re-evaluation. A deployer may depend on model-level documentation from a provider while remaining responsible for its own interface, instructions, monitoring, and downstream use.
A practical 30-day control reset
First, reconcile the AI inventory with the amended dates. Replace blanket ‘August 2026’ status labels with the specific obligation family that applies. Confirm whether each system implicates prohibited practices, transparency, general-purpose AI, potential Annex III high-risk use, Annex I product-related use, or none of those categories. Preserve uncertainty where classification is not yet resolved.
Second, inspect public and employee-facing experiences for transparency and synthetic-content handling. Capture test evidence showing disclosures or marking in context. Review generated-content workflows in marketing, support, public information, knowledge bases, document generation, and API-based publication. Assign an owner for changes in model behavior or delivery channel that could invalidate the current control.
Third, review contracts and vendor evidence. Ask for model cards or equivalent documentation, intended and excluded uses, data handling, retention, subprocessors, security controls, incident notification, version-change practices, evaluation evidence, logging support, and technical documentation. A vendor statement that a product is ‘AI Act compliant’ is not a substitute for evidence relevant to the buyer’s role and use case.
Finally, create a dated decision record that identifies the business owner, technical owner, risk owner, legal interpretation source, classification rationale, current controls, open gaps, next review event, and accountable approver. Link the record to evidence rather than duplicating unsupported conclusions across systems.
The evidence pack leadership should ask to see
For a material AI use case, leadership should be able to inspect an inventory record, role analysis, intended-purpose statement, data-flow or architecture view, model and vendor documentation, evaluation plan, test results, transparency evidence, human-oversight design, incident path, monitoring indicators, and a record of accepted residual risk. The pack should distinguish vendor-supplied facts from findings produced by the organization.
Useful metrics include the percentage of systems with a current owner, percentage with a dated classification rationale, evaluation coverage after material changes, unresolved high-severity findings, disclosure test coverage, time to disable or contain a problematic deployment, and incomplete vendor evidence requests. A count of ‘AI projects reviewed’ has little meaning if the review standard is undefined.
The Software Evaluation Scorecard can be used to make these evidence differences visible during a technology decision, while the Evaluation Brief Builder helps turn an AI use case into concrete questions before a vendor conversation.
Decision questions for the next steering meeting
- Which obligations are active for this system today, and what article-level basis supports that conclusion?
- Do any synthetic-content systems need a technical or operational change before 2 December 2026?
- Which systems depend on the 2027 Annex III or 2028 Annex I timetable, and what engineering lead time remains?
- Which public-authority deployments may rely on the later transition provision, and are current contracts preserving the evidence needed before 2030?
- Where are we relying on vendor assurances without documentation relevant to our own legal role?
- Can we trace every material system to an owner, intended purpose, model or version, data boundary, evaluation, and incident path?
- What change—new model, new data, new user group, new action, new geography, or substantial modification—forces reclassification or re-evaluation?
The practical advantage of the revised timetable is the opportunity to replace hurried checkbox work with an evidence-producing operating model. The organizations that use the extension well will arrive at the later high-risk deadlines with tested controls, current supplier evidence, and repeatable review habits. Organizations that read ‘delay’ as ‘do nothing’ will face the same engineering and governance work later with less time and weaker institutional memory.
this analysis is an implementation aid, not legal advice. Validate material decisions against the consolidated EU legal text, current Commission guidance, and qualified counsel for the relevant role and jurisdiction.
Continue in the Compliance pillar
Return to the hub for curated research and deep-dive guides.
Latest guides
-
Third-Party Compliance Oversight Guide
Operate evidence-based third-party compliance oversight after vendor selection: obligations, monitoring, control evidence, findings, incidents, reassessment, concentration signals…
-
Privacy Enforcement Readiness Guide
Build an evidence-based privacy enforcement readiness program around current EU GDPR priorities, California CCPA regulations, U.S. sensitive-data restrictions, rights operations…
-
SOX and ICFR Modernization Guide
Modernize Sarbanes-Oxley internal-control operations with current SEC management guidance, PCAOB AS 2201, COSO 2013, technology controls, evidence design, and the December 2026…
Coverage intelligence
- Published
- Coverage pillar
- Compliance
- Source credibility
- 40/100 — low confidence
- Topics
- EU AI Act · Digital Omnibus · AI Governance · High-Risk AI · Transparency · Compliance
- Sources cited
- 3 sources (eur-lex.europa.eu, digital-strategy.ec.europa.eu)
- Reading time
- 8 min
Further reading
- Regulation (EU) 2026/1744 — Digital Omnibus on AI — Official Journal of the European Union
- Regulation (EU) 2024/1689 — consolidated text as amended in 2026 — EUR-Lex
- AI Act — implementation timeline and risk-based obligations — European Commission
Source feedback
Editorial
Found a factual issue, superseded source, broken citation, or important context we should review? Send the specific claim and supporting source through the correction path so it can be evaluated against the article record.