What the Digital Omnibus moved, and which notes to re-date

The amending instrument

The text to work from is Regulation (EU) 2024/1689, the EU AI Act, as amended by Regulation (EU) 2026/1744 — the Digital Omnibus on AI. It was published in the Official Journal on 24 July 2026 and has been in force since 27 July 2026.

That matters for a practical reason rather than a scholarly one. Most of the timeline material circulating in client-facing decks, onboarding packs and half-finished engagement letters was written against the unamended text. If you built a portfolio calendar before last summer and have not revisited it, some of the dates in it are wrong, and they are wrong in the direction that makes you look either alarmist or complacent depending on the row.

Everything below was checked against the post-omnibus text on 17 September 2026.

What moved, and what did not

Three things are worth separating, because clients conflate them and then act on the conflation.

The dates moved. The high-risk dates in particular sit later than the originally published schedule. This is the part that invalidates old notes.

The substance did not. What a provider of a high-risk system has to produce is unchanged: the technical documentation, the risk management work, the human oversight design, the logging. A later date is more time to do the same amount of work, not less work. Say this out loud to any client who reads "delayed" as "dropped", because the Annex III document set is measured in months of effort and the extra runway disappears quickly once you start.

One obligation was softened. Article 4, on AI literacy, now requires the organisation to support AI literacy among staff rather than to secure a particular level of it. Softened is not removed. A short literacy policy naming who is trained on what, and when, is still the cheapest document in the file and still the one a client's own enterprise customer asks for first.

There is also a date that is already behind us and gets treated as future in stale notes: the transparency obligations under Article 50 have been in application since 2 August 2026. For a client running a chatbot or a content generator, that is not something to schedule. It is a present gap, and the question to ask is where the disclosure actually appears — a line in the terms of service is not a notice at the point of interaction.

The dates as they now stand

Date	What applies	Attaches to
2 December 2026	New prohibited practices: intimate imagery without consent, child sexual abuse material	Confirmed prohibited practice, and limited-risk systems
2 December 2026	Machine-readable marking of generated content applies to systems already on the market	Confirmed limited risk
2 December 2027	High-risk obligations apply to Annex III systems	Confirmed high risk, Annex III
2 August 2028	High-risk obligations apply to Annex I systems, safety components of regulated products	Confirmed high risk, Annex I

Two rows deserve a note.

The December 2026 marking row is the one that catches ordinary businesses. It reaches systems already on the market, so the SME that shipped an image or a copy generator before the rule bit does not get to treat itself as grandfathered. Marking that a human can see is not marking that a machine can read, and retrofitting the second into an existing pipeline is engineering work with a lead time. That conversation has to happen months ahead of the date, not in the week after it.

The two high-risk rows sit on different branches and it is easy to put a client on the wrong one. Annex III is a list of uses — recruitment and screening at point 4(a), workforce decisions and monitoring at point 4(b), education at point 3, credit scoring at point 5(b), life and health insurance pricing at point 5(c), public benefits at point 5(a), emergency call triage at point 5(d), and the rest of the list. Annex I is the other branch: under Article 6(1), an AI safety component of a product covered by Annex I legislation — medical devices, machinery, toys, vehicles, aviation — is high risk. A twelve-person manufacturer with a vision system on the line is an Annex I client with an August 2028 date, not a December 2027 one.

Which client files to re-date

A concrete pass, in the order that costs least.

Any letter, proposal or engagement scope with a high-risk date in it. These are the ones with your name on them and a date that is now wrong. Fix the date, and add the instrument reference so the next reader can check it: Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744.

Portfolio reminder schedules. Six, three and one month before each date is a sensible cadence for high-risk work. If those reminders were seeded from the old calendar, they now fire against nothing, or worse, fire late.

Anything that describes Article 4 as a duty to ensure a level of literacy. Adjust the wording to supporting literacy. Do not delete the policy.

Chatbot and content-generation clients filed under "future obligation". Article 50 moved into the present in August 2026. Re-file those as current work and look at the December 2026 marking row for anything already shipped.

Prohibited-practice checklists. Add the two new practices effective 2 December 2026. Run the checklist across the whole register, including the clients you are confident about — the recurring surprises are sentiment and engagement scoring arriving as a feature update inside a tool bought for something else, and demographic inference in analytics features.

A date attaches to a confirmed category, not to a client

This is the part most portfolio calendars get structurally wrong, and it is worth being honest with clients about.

None of these dates apply to "a company that uses AI". Each one attaches to a risk category: the December 2027 row is for a confirmed Annex III system, the August 2028 row for a confirmed Annex I system, the marking row for confirmed limited risk. A client whose systems have not been classified and confirmed does not have a late deadline or an early one. They have no deadline yet, because nothing has been established that a deadline could attach to.

The practical consequence is an ordering. The system register comes first: name, intended purpose, vendor as a legal entity, role, use cases from a fixed list, whether the system was modified, and the risk category with who confirmed it and when. Only then does a calendar mean anything. Working the other way round — pushing a portfolio-wide deadline at clients whose systems nobody has looked at — produces alarm without work, and the client notices eventually.

Keep the confirmation honest, too. If the use cases, the role or the modification flag change later, the earlier confirmation is stale and has to be taken again. A register that silently keeps a category confirmed against facts that have moved is worse than no register, because it will happily generate a deadline that has nothing behind it.

Keep the dates as data

The last suggestion is structural. Dates belong in one list, with the instrument they come from and the date you last checked them written next to them — not scattered through templates and letter boilerplate where each copy ages on its own. The regulation has already moved once. Some of what follows is political until it is formally adopted, and it will move again.

That is how clausebench holds them: a single deadline file carrying its source and a checked-on date, so one edit moves every client's calendar at once. The mechanism matters more than the tool, though. Whatever you keep them in, the question to be able to answer in ten seconds is: which text, checked when, and by whom.

The cost of a stale date in a client letter is borne by your name, not the regulator's.