The AI Act Omnibus deferred the classification, not the architecture
The Digital Omnibus on AI moved the high-risk obligations to December 2027 and August 2028 and left Article 50 running from 2 August 2026. It attaches to how a system is built and surfaced rather than to what it is used for, which is why an ordinary enterprise assistant sits inside the deadline that did not move.
The planning meeting goes like this. Somebody reports that Brussels has moved the AI Act deadline, the room relaxes, and the readiness work that was scheduled for the next two quarters moves quietly into next year.
The report is accurate. The Digital Omnibus on AI entered into force on 27 July 2026 and pushed the obligations for stand-alone high-risk systems to 2 December 2027, and for systems embedded as safety components in products already covered by EU product-safety law to 2 August 2028. The Commission’s own timeline now reads that way.
The relief is where the error is. The deferral applies to the high-risk chapter, which is triggered by what a system is used for. It does not reach Article 50, which is triggered by what a system is — whether it speaks to a person, and whether it produces synthetic content. Article 50 has applied since 2 August 2026. For an estate built mostly of assistants, drafting tools and summarisers, the obligation that is live today is the one nobody moved.
Two different questions, two different dates
The high-risk chapter asks a question about deployment. Is this system used for recruitment, for creditworthiness, for access to essential services, for biometric identification. Annex III is a list of situations, and an organisation answers it by cataloguing use cases. An internal drafting assistant, a document search tool or a meeting summariser will often not appear on that list at all, and the honest conclusion is that the system is not high-risk. That conclusion was correct before the Omnibus and it is still correct. It is also the conclusion whose consequences were deferred.
Article 50 asks a question about construction, and the Commission’s AI Act Service Desk carries the text. Two of its duties fall on providers. A system intended to interact directly with natural persons must be “designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system”. A system generating synthetic audio, image, video or text must have its outputs “marked in a machine-readable format and detectable as artificially generated or manipulated”. Two fall on deployers: telling people exposed to emotion recognition or biometric categorisation that it is running, and disclosing deepfakes and AI-generated text published to inform the public on matters of public interest.
None of those four duties asks what the system is for. An internal drafting assistant that no regulator would place in Annex III still interacts directly with a person, and still generates synthetic text.
- Layer 01 The model Provider duty — synthetic output marked in a machine-readable form.
- Layer 02 Orchestration No duty attaches here, and the mark survives only if the path is built to carry it.
- Layer 03 The interface Provider duty — the person is told at first interaction that they are talking to an AI system.
- Layer 04 The publication surface Deployer duty — deepfakes and public-interest text disclosed.
The word “provider” is doing more work than teams expect
Both build-time duties fall on the provider, and it is easy to read that word and picture the model vendor. The Act’s own definitions do not work that way. A provider is a body that develops an AI system, or has one developed, and “places it on the market or puts the AI system into service under its own name or trademark”. Putting into service is defined as supply for first use to a deployer “or for own use”. Both definitions sit in Article 3.
Read together, they mean that assembling an assistant around a bought model and running it internally under your own name does not move the provider duties to the vendor. It makes the assembling organisation the provider of the assembled system, and the two duties that attach at design time attach to it.
That matters most for marking, because marking is a property of the generation path rather than of the interface. If a mark is produced by the model and then lost to a rewriting step, a template renderer, a redaction pass or an export to a format that carries no metadata, it is not in the output the person receives, and nothing at the interface can put it back. It has to survive the stack. That is an architecture decision, taken by an architect, and it is why the deferral of a classification does not reach it.
The Commission has published what good looks like here, which removes the usual excuse that the requirement is too abstract to design against. Its guidelines on the Article 50 transparency obligations were adopted on 20 July 2026. The Code of Practice on Transparency of AI-generated Content was finalised on 10 June 2026, and the Commission and the AI Board have confirmed it as an adequate voluntary tool for demonstrating that the obligations are met. Signing it is optional. Reading it before you design the marking path is not a regulatory act — it is simply cheaper than the alternative.
What to survey, and in what order
There is one date in the near term worth establishing for yourself. Analysis of the amending regulation by White and Case reads the transitional arrangement as giving generative systems placed on the market before 2 August 2026 until 2 December 2026 to meet the machine-readable marking duty, with systems placed on the market on or after that date expected to meet it from the start. If that reading holds for your estate, the systems already carrying traffic are the ones with a date inside this calendar year, and they are also the ones hardest to change.
None of this is a large programme. It is a survey of what is already running and a decision about where in the path one property is applied. The ceiling for transparency breaches is set out in Article 99, which allows fines of up to EUR 15 000 000 or 3 % of total worldwide annual turnover, whichever is higher. The nearer risk is duller and more likely: the interface team, the platform team and the model vendor each assume one of the others owns marking, and none of them does.
What this does not tell you
This is not legal advice and it is not a classification of your estate. Whether a particular system falls inside Article 50, whether your organisation is its provider or its deployer, and what else in your position the Omnibus changed are questions for your counsel, decided against the text of the Act rather than against this article. The Omnibus text itself is Regulation (EU) 2026/1744, and it is the thing to read.
We do not certify anyone against the AI Act, and no review we run makes an organisation “compliant” — that is not a state any external party can confer here. What an architecture review can establish is narrower and more useful: where in a running system a required property is applied, where it is lost, and which team owns the layer it is lost at.
The person who decides differently is whoever owns the assistant layer and has just moved AI Act work out of this year’s plan on the strength of a headline. The deferral is real, and it applies to a classification most of their systems do not have. The duties that do apply attach to the generation path and the interface, they have been live since 2 August 2026, and they are the kind of property that costs almost nothing to design in at the point the path is drawn, and a great deal to retrofit into a system already answering people.