Twenty-three days remain before 2 August 2026. The 100-day checklist and the 90-day FRIA countdown already published on this site cover the planning phase. This piece covers what is left when planning time has run out: what to lock in regardless of the Omnibus outcome, what to do if confirmation does not arrive in time, and how to avoid burning the final stretch on two contingency plans at once.
Key takeaways
- The Digital Omnibus delay has not been confirmed as of 10 July 2026. Treat 2 August 2026 as the operative deadline until the Official Journal says otherwise.
- A small set of actions does not depend on the trilogue outcome at all and should be locked in during these final three weeks regardless of how the negotiation resolves.
- If final confirmation does not arrive before 2 August, deployers should proceed as though the original deadline holds, since a later adoption does not retroactively excuse a gap that existed on that date.
- The Product Liability Directive deadline of 9 December 2026 is unaffected by the AI Act delay discussion and needs its own parallel preparation track.
- Building two full contingency plans, one for the delay passing and one for it failing, wastes the final window. The correct model is one compliant file with a single external trigger to monitor: Official Journal publication.
Section 1. Where the Digital Omnibus actually stands on 10 July 2026
The European Parliament adopted its negotiating position on the Digital Omnibus on AI in March 2026, supporting a deferral of certain high-risk obligations of up to sixteen to twenty-four months, conditional on the European Commission first delivering the harmonised standards that providers and deployers need to demonstrate conformity. That is a negotiating position, not a settled outcome. As of this article's publication, the Council and the Commission have not concluded trilogue, and no agreed text has been published in the Official Journal of the European Union.
This matters more now than it did in April, when the 100-day checklist on this site first walked through the operator file in detail. At that stage, a deployer could reasonably wait a few weeks to see how the political process developed before committing resources. That reasoning no longer holds. Twenty-three days is not enough time for a negotiation outcome to change what a deployer with an incomplete file needs to do. The honest position for a compliance team on 10 July 2026 is this: the delay may or may not arrive in time, the timing of its arrival is outside your control, and the file you need to hold either way is largely the same file.
We deliberately avoid predicting whether trilogue concludes before 2 August. Readers should not take silence on that question as evasion. It reflects the actual state of a live legislative process: Parliament, Council, and Commission have not reached the point where a European Union outcome can be stated as fact, and a publication that treats a pending negotiating position as a settled result would be doing readers a disservice.
Section 2. Five actions to lock in this week, regardless of the Omnibus outcome
The single most useful thing a compliance team can do with twenty-three days is separate the actions that depend on the trilogue outcome from the actions that do not. Almost everything genuinely useful falls into the second category. The table below sets out the five highest-value actions for this window and why each one holds its value whether the delay is adopted before 2 August, adopted afterward, or does not pass at all.
| Action | Why it holds value in every scenario | Effort required in the final three weeks |
|---|---|---|
| Freeze the five-document operator file | Article 26 requires the same risk record, oversight register, instructions-for-use map, logging schedule, and incident protocol under any adoption date the Omnibus eventually sets. Nothing about the substance changes. | Final legal review and sign-off only, assuming drafting is already underway from the earlier planning phase. |
| Confirm named oversight persons can articulate their role | A named, trained, authorised oversight person under Article 26(2) is required whenever the obligation activates. Competence gaps do not close themselves on a later date; they need to be closed now. | One structured conversation per system, not a training programme. |
| Run the incident protocol once, live | A protocol that has never been exercised is a document, not a procedure. This is true in August 2026 and would remain true in December 2027 under the proposed delay. | A single tabletop exercise, roughly half a day including the retrospective. |
| Confirm the named contact at the relevant national supervisor | BaFin in the financial sector, AFM in the Netherlands, and ACPR in France have each published sector guidance. Knowing the correct contact point removes a delay from any future incident report, regardless of when the obligation formally activates. | A short verification call or a check of the supervisor's published guidance page. |
| Confirm the insurance policy schedule for AI exclusion endorsements | Whether or not the deadline moves, a policy that excludes AI-originated claims through an endorsement leaves the deployer exposed to the Product Liability Directive from 9 December 2026 regardless of the AI Act's timeline. | A single review meeting with the broker or carrier, ideally before the end of July. |
Section 3. One file, one trigger: avoiding the two-contingency trap
A natural but costly instinct under legislative uncertainty is to prepare two parallel plans, one that assumes the delay lands in time and one that assumes it does not, and to run both simultaneously so that whichever outcome arrives, the organisation is ready. In a three-week window, this instinct is close to the worst available use of remaining capacity. Two contingency plans do not double coverage. They halve the depth of attention each plan receives, at the exact moment when depth, not breadth, is what closes a file.
The more effective model treats the compliance programme as a single file built to the original 2 August 2026 standard, with exactly one external fact to monitor: whether the Digital Omnibus on AI has been formally adopted by both co-legislators and published in the Official Journal of the European Union before that date. This is a binary, publicly observable fact, not a judgement call the compliance team has to make. It does not require tracking committee vote counts, statements from individual members of the European Parliament, or informal signals from Brussels. It requires checking one register.
If publication occurs before 2 August, the operator file's activation date moves out with it, for whichever obligations the final text actually defers, and the compliance team gains calendar time it can use productively. If publication has not occurred by 2 August, the file that was built to the original standard is already the file that needs to exist on that date. In neither branch does the underlying work change. Only the activation date does. This is the practical reason the five actions in Section 2 are worth completing in full: they are correct under both branches, which means they are not really contingent planning at all. They are simply the work.
Readers who want the fuller institutional picture, including the Parliament, Council, and Commission positions and the provisions that are not affected by the Omnibus under any scenario, such as the Article 5 prohibitions and the GPAI obligations, should read the Digital Omnibus Master Brief published on this site. That piece maps the legislative mechanics in depth. This piece assumes that background and focuses only on what changes in the final three weeks.
Section 4. If confirmation does not arrive before August 2
A compliance team should plan explicitly for the branch in which trilogue has not concluded, or has concluded without Official Journal publication, by 2 August 2026. This is not a pessimistic assumption. It is the legally conservative one, and it is the only assumption a deployer can safely rely on without a confirmed text in hand.
In that branch, the original application date governs. A deployer operating a high-risk AI system under Annex III without the operator file, oversight structure, logging schedule, and incident protocol required by Article 26 is in breach from that date, regardless of how close the Omnibus came to adoption. National market surveillance authorities are not obliged to treat a pending negotiation as grounds to defer their own supervisory activity, and nothing in Regulation (EU) 2024/1689 grants an informal grace period tied to the status of a separate legislative proposal.
The practical response is documentation of good faith and readiness, not documentation of the political process. If a supervisor opens an inquiry in the weeks after 2 August, the file that matters is the operator file itself: whether it exists, whether it was signed off before the deadline, and whether the oversight and incident procedures it describes have actually been exercised. A record showing that the organisation was closely tracking the Digital Omnibus negotiation is context. It is not a substitute for the file. Deployers should resist the temptation to treat proximity to a possible delay as a compliance argument in its own right.
A subsequent adoption of the Omnibus after 2 August would change the forward obligation from that point, but it does not retroactively cure a gap that existed between 2 August and the eventual publication date. Any deployer weighing whether to complete its file this month against the chance that adoption lands a few weeks later should treat that gap window, however short it turns out to be, as full legal exposure, not a rounding error.
Section 5. The deadline the Omnibus cannot touch
Directive (EU) 2024/2853, the revised Product Liability Directive, must be transposed into national law across all twenty-seven Member States by 9 December 2026. This deadline sits entirely outside the AI Act and outside the Digital Omnibus negotiation. It is not a candidate for deferral in the current trilogue, and no proposal before Parliament, Council, or Commission touches it.
Once transposed, AI software is treated as a product for the purposes of strict liability, and claimants gain expanded rights to obtain evidence from defendants, including deployers, where a defect is alleged. A deployer's compliance posture under the AI Act, including whether the operator file existed and whether the incident protocol was followed, becomes directly relevant evidence in a product liability claim, independent of whether the AI Act's own high-risk obligations have been formally delayed. A deployer that treats the Digital Omnibus as a reason to slow down its AI Act preparation is, in effect, also slowing down its preparation for a deadline the Omnibus cannot move. The two tracks should run in parallel, and the final three weeks are the wrong moment to let one absorb attention that the other needs.
For a fuller treatment of how the two regimes interact, including the rebuttable presumption of defect and its relationship to the Article 26 documentation set, see the Product Liability Directive double-exposure guide on this site.
Section 6. The final three weeks, day by day
What follows assumes the operator file described in the Article 26 complete guide is substantially drafted already, following the earlier 100-day and 90-day planning cycles. This is a closing sequence, not a build sequence. Deployers who have not yet started drafting the five-document file should treat this section as a compressed, best-effort version of the fuller programme, prioritised strictly in the order below.
Days 1 to 5 (10 to 14 July): Close the file, not open new work
Phase: Final drafting freeze
- Stop adding new scope to the risk record, oversight register, instructions-for-use map, logging schedule, and incident protocol. Any system not yet assessed should be triaged for whether it can realistically be brought into scope in the remaining window, and deprioritised if not.
- Resolve every open divergence flagged in the instructions-for-use map. An unresolved divergence at this stage should be escalated directly to a senior decision maker for a same-week decision, not left pending.
- Confirm the logging schedule meets the six-month retention floor under Article 26(6) and any longer sectoral retention rule that applies.
Days 6 to 12 (15 to 21 July): Rehearse once, correct what fails
Phase: Live test, not another tabletop
- Run the incident protocol once as a live drill, not a discussion. Present a realistic Article 3(49) serious incident scenario and time the response from identification to the point of external notification.
- Test log retrieval under realistic conditions: request a specific date-range extract and confirm it can be produced in a format a supervisor could review.
- Interview each named oversight person directly. If any cannot describe their authority to intervene or halt the system without prompting, this is the last week available to close that gap through targeted, not general, training.
Days 13 to 18 (22 to 27 July): Sign-off and insurance confirmation
Phase: Governance close-out
- Obtain board or senior management sign-off on the finalised operator file. This is the organisational record a supervisor will look for if an inquiry opens shortly after 2 August.
- Confirm with the insurance broker or carrier that the current policy schedule has been reviewed for AI exclusion endorsements, and that the insurer has been informed of the organisation's high-risk AI systems where required.
- Confirm registration under Article 71 if the deployer is a public authority, and confirm worker information notices have been issued where Article 26(7) applies.
Days 19 to 23 (28 July to 1 August): Final check, no new changes
Phase: Readiness confirmation
- Conduct a final readiness confirmation against the five-document file. No further substantive changes should be made in these last days; a file still being revised on 1 August raises the same question it would raise on any other deadline, namely whether it was genuinely ready before the obligation activated.
- Check the Official Journal of the European Union for Digital Omnibus publication status once, as a matter of record, and note the outcome. This does not change what the file needs to contain; it only determines the activation date the file is being held ready against.
- On 2 August, the file should be identical whether or not the Omnibus was published in the interim. That is the point of building to a single standard instead of two.
Section 7. Frequently asked questions
What should a deployer do in the final three weeks before August 2, 2026?
In the final three weeks, a deployer should stop planning and start closing files. Freeze the risk record, oversight register, instructions-for-use map, logging schedule, and incident protocol required under Article 26 of Regulation (EU) 2024/1689. Confirm named oversight persons can explain their authority without notes. Test log retrieval once. Confirm the incident escalation contact at the relevant national supervisor by name. None of these actions depends on whether the Digital Omnibus is adopted, so none of them should wait for that outcome.
Has the EU AI Act delay been confirmed as of July 2026?
No. As of this article's publication on 10 July 2026, the Digital Omnibus on AI remains in trilogue negotiation between the European Parliament, the Council, and the European Commission. The Parliament adopted a negotiating position in March 2026 supporting a delay of certain high-risk obligations by sixteen to twenty-four months, conditional on the Commission first delivering harmonised standards. That position is not law. Until a final text is agreed, adopted by both co-legislators, and published in the Official Journal of the European Union, the original 2 August 2026 application date remains legally binding.
What if the delay is not confirmed before August 2, 2026?
If trilogue negotiations have not concluded and no text has been published in the Official Journal before 2 August 2026, deployers must operate as though the original deadline applies, because it does. A subsequent adoption of a delay after that date would govern conduct going forward but would not retroactively excuse a gap that existed on 2 August. A deployer with no operator file on that date, waiting on the Omnibus, has no legal basis for that wait if a supervisor opens an inquiry.
Should a compliance team build separate plans for the delay passing and the delay failing?
No. Building two parallel contingency plans in the final three weeks divides scarce attention across two outcomes a compliance team cannot control. The more effective approach is a single file, built to the original 2 August 2026 standard, with one objective trigger monitored externally: publication in the Official Journal. If publication occurs before 2 August, the file's operational start date moves out with it. If it does not, the file is already ready. The work does not change; only the activation date does.
Is the Product Liability Directive deadline affected by the AI Act delay discussion?
No. Directive (EU) 2024/2853 on liability for defective products must be transposed into national law by every Member State by 9 December 2026. This deadline sits entirely outside the AI Act and the Digital Omnibus negotiation. It applies regardless of whether the Article 26 high-risk obligations are delayed, and it makes AI software subject to a rebuttable presumption of defect in specific circumstances. Deployers should treat the two deadlines as independent tracks and prepare for both without waiting on the outcome of either.
What documentation should a deployer be able to produce on August 2, 2026 regardless of the Omnibus outcome?
Five documents form the minimum operator file under Article 26 of Regulation (EU) 2024/1689: a risk record, an oversight register naming trained and authorised persons, an instructions-for-use map, a logging schedule meeting the six-month retention floor, and a tested incident protocol. Producing this file is a no-regret action. It satisfies the obligation if the original deadline holds, it satisfies the same obligation on whatever later date the Digital Omnibus eventually sets, and it strengthens the deployer's position with insurers and national supervisors in either case.
Related reading
References
- Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act), OJ L, 12.7.2024.
- Article 3(49), Regulation (EU) 2024/1689. Definition of serious incident.
- Article 6 and Annex III, Regulation (EU) 2024/1689. Classification criteria for high-risk AI systems.
- Articles 9 to 17, Regulation (EU) 2024/1689. Risk management system, data governance, technical documentation, logging, transparency, human oversight, accuracy, robustness, cybersecurity, provider obligations, and quality management system.
- Article 26, Regulation (EU) 2024/1689. Obligations of deployers of high-risk AI systems, sub-paragraphs (1) through (8).
- Article 71, Regulation (EU) 2024/1689. EU database for high-risk AI systems: registration obligation for public authorities.
- Article 99, Regulation (EU) 2024/1689. Penalties, including the second-tier ceiling of EUR 35 million or 7 per cent of worldwide annual turnover applicable since August 2025.
- Digital Omnibus on AI, COM(2025) 836. European Commission proposal amending Regulation (EU) 2024/1689. European Parliament negotiating position adopted March 2026 supporting deferral of certain high-risk obligations by sixteen to twenty-four months, conditional on delivery of harmonised standards by the Commission. Status as of 10 July 2026: in trilogue, not adopted.
- Directive (EU) 2024/2853 of the European Parliament and of the Council on liability for defective products, OJ L, 18.11.2024. National transposition deadline 9 December 2026.
- BaFin (Bundesanstalt für Finanzdienstleistungsaufsicht). Published guidance on AI governance in the financial sector. Available at bafin.de.
- Autoriteit Financiële Markten (AFM), the Netherlands. Supervisory guidance relevant to AI-supported financial services. Available at afm.nl.
- Autorité de Contrôle Prudentiel et de Résolution (ACPR), France. Sector guidance on AI use in banking and insurance supervision. Available at acpr.banque-france.fr.
- AI Safety Institute (AISI), United Kingdom. Referenced as a comparator supervisory model outside the European Union.