The debate is over. On 27 July 2026, the EU's AI Omnibus entered into force. The final law gives companies more time for parts of the high-risk AI framework and simplifies several requirements.
It does not postpone the entire AI Act.
That distinction matters now. On 2 August 2026, enforcement powers and several transparency obligations become operational. A SaaS team that reads "high-risk rules delayed" as "nothing applies this weekend" can still launch with a disclosure, labelling, documentation, or procurement gap.
This guide replaces speculation with the final timeline: what moved, what stayed, and what an ordinary AI SaaS provider should do next.
The Final Timeline in One View
What the AI Omnibus Actually Delayed
Annex III high-risk use cases: 2 December 2027
High-risk systems in sensitive use cases—including employment, education, essential services, migration, biometrics, and critical infrastructure—now receive a longer implementation runway. Their main high-risk obligations apply from 2 December 2027.
This is meaningful relief. Providers get more time for risk management, data governance, technical documentation, logging, human oversight, accuracy, robustness, cybersecurity, conformity work, and post-market monitoring.
But an extension is not an exemption. Teams should use the additional time to build a traceable system, not to postpone classification until late 2027. Enterprise buyers can request the same evidence earlier through contracts and procurement questionnaires.
Annex I product-integrated systems: 2 August 2028
High-risk AI embedded in regulated products—such as certain machinery, medical devices, toys, lifts, or safety components—moves to 2 August 2028. These systems depend heavily on sectoral conformity-assessment structures and harmonised standards, so the extended date is operationally important.
Most ordinary web-based SaaS products do not become Annex I systems merely because they use an API model. The relevant question remains the intended purpose and the regulated product into which the AI is integrated.
What Still Applies on 2 August 2026
Article 50 transparency
The final Omnibus did not erase the Article 50 transparency layer. From 2 August 2026, the Act covers four distinct patterns:
- direct interaction between a natural person and an AI system;
- machine-readable marking of synthetic audio, image, video, and text;
- notice when people are exposed to emotion recognition or biometric categorisation;
- labelling of deepfakes and certain AI-generated public-interest text.
These obligations are not limited to "high-risk AI." A support chatbot, writing copilot, report generator, image tool, or voice application may be outside Annex III and still trigger Article 50.
Enforcement becomes operational
The AI Office and national market-surveillance authorities gain applicable enforcement powers from 2 August 2026 for the parts of the Act within their competence. For SaaS teams, this changes the posture from preparation to evidence: a policy statement alone is weaker than screenshots, release records, tests, ownership, and a dated legal assessment.
Earlier obligations remain earlier obligations
The prohibited-practices and AI-literacy duties have applied since February 2025. General-purpose AI model obligations began applying in August 2025. The Omnibus timeline does not reset those obligations.
The December 2 Grace Period Is Narrow
One transition deserves careful wording. For AI systems already placed on the market before 2 August 2026, the Article 50(2) machine-readable marking obligation moves to 2 December 2026.
That does not create a universal four-month Article 50 holiday.
- It concerns the provider-side marking and detection duty in Article 50(2).
- It does not generally postpone direct-interaction disclosure under Article 50(1).
- It does not remove deployer labels for deepfakes or relevant public-interest text.
- It should not be assumed to cover a materially new feature launched after August 2.
If your roadmap includes generative exports, record the exact system version and market date. "The company existed before August" is not a substitute for evidence that the relevant system was already placed on the market.
Provider, Deployer, or Both?
Buying access to a foundation model does not automatically make the model vendor responsible for your whole product. If you package a model into a branded SaaS workflow and place that AI system on the market under your own name, you may be the provider of that downstream system. When you also use another company's model internally, you may simultaneously act as a deployer in that part of the chain.
Map the roles per system and per use case:
- Who defines the intended purpose?
- Whose name appears on the product?
- Who controls the user interface and disclosure?
- Who generates and distributes the output?
- Who can change safeguards, prompts, thresholds, or model routing?
A vendor's DPA, model card, or compliance page is useful supplier evidence. It is not your own role analysis.
A 72-Hour SaaS Checklist Before August 2
1. Freeze the scope
List every production AI surface: chat, email, document generation, public reports, image/audio/video generation, ranking, classification, monitoring, and automated publication. Record the model provider and intended purpose.
2. Classify each surface
Decide whether the feature is prohibited, high-risk, transparency-triggering, or outside those categories. Do not classify the entire company with one label when features have different purposes.
3. Ship disclosures in the product layer
For direct AI interaction, inform the user before or no later than the first interaction unless the AI nature is objectively obvious. Keep a persistent AI identity cue. Do not rely on the model to disclose itself.
4. Test complete journeys
Test desktop, mobile, embedded widgets, logged-out flows, consent-denied states, localisation, keyboard navigation, and screen-reader output. A label that exists in source code but disappears behind a modal is not a reliable control.
5. Preserve evidence
Save dated screenshots, test results, release SHAs, responsible owners, exception reasoning, supplier documentation, and a short approval record. This is the difference between "we intended to comply" and "this control was active on this date."
6. Create the December workstream
If you rely on the existing-system transition for Article 50(2), document why it applies and plan machine-readable marking well before 2 December. Treat interoperability and provenance as engineering requirements, not a last-minute footer change.
What You Should Not Do
- Do not remove every AI Act ticket because high-risk dates moved.
- Do not call all model-powered SaaS "high-risk" by default.
- Do not assume a privacy-policy sentence satisfies an in-product disclosure duty.
- Do not treat your model vendor's compliance as your product compliance.
- Do not publish "fully EU AI Act compliant" without a scoped, dated assessment.
The Practical Conclusion
The final AI Omnibus is good news for teams building genuinely high-risk systems. It creates more time and a clearer implementation sequence.
For the wider SaaS market, however, 2 August 2026 still matters. Article 50 transparency, operational enforcement, earlier AI-literacy duties, and procurement expectations do not disappear because Annex III moved to 2027.
The correct message is not "the AI Act was delayed." It is: the timeline split.
Identify which branch your product is on, implement the controls that apply now, and preserve the evidence. That is a defensible compliance posture.
Check your public AI compliance signals
Scan your product page for EU AI Act, GDPR, and ePrivacy transparency gaps, then use the findings as a starting point for human review.
This article provides general technical and regulatory information, not legal advice. Applicability depends on the system, intended purpose, role, market date, and deployment context.