The article that was not postponed: the part of the AI Act that lands in the interface

On 2 August 2026 most of the European Union’s AI Act became applicable. Six days earlier, on 27 July, a regulation postponing part of that timetable entered into force. Read apart from each other, those two sentences produce a headline like the EU delayed the AI Act, which is half true, and being half true is exactly what makes it the most misleading version.

What was postponed

The postponing text is Regulation (EU) 2026/1744, dated 8 July 2026, published in the Official Journal on 24 July and in force from 27 July. It does not build a new regime, it shifts the existing timetable: obligations for the standalone high-risk systems listed in Annex III move to 2 December 2027, and for systems embedded in products already covered by product safety law to 2 August 2028.

The Commission’s own page gives the same two dates and ties the reasoning to companies having the right support tools, such as standards. The regulation’s own recitals add a second item: the delayed establishment of national competent authorities. So what was postponed is not the obligation but the readiness of the instruments compliance would be measured against.

What was not postponed

The Commission’s transparency FAQ puts it in one sentence: Article 50 applies as from 2 August 2026. That article works independently of the high-risk classification. It does not ask whether a system is high risk, it looks at the moment the system touches a person.

The article itself carries four separate duties, two on the provider and two on the deployer. The first falls on the provider: a system that interacts directly with people must let the person using it know they are interacting with AI, unless that is obvious to a reasonably well-informed and observant person. The second also falls on the provider: audio, image, video and text produced by a generative system must be marked in a machine-readable format and be detectable as artificially generated or manipulated. The third falls on the deployer: anyone running an emotion recognition or a biometric categorisation system must inform the people exposed to it that the system is operating. The fourth falls on the deployer as well and has two parts: where a system generates or manipulates image, audio or video constituting a deep fake, the content must be disclosed as artificially generated or manipulated, and AI-generated text published in order to inform the public on matters of public interest must be labelled. Three of the four are a duty to tell somebody something, which ends up as a sentence on a screen; the second one is of a different kind.

in a clear and distinguishable manner at the latest at the time of the first interaction or exposure

That is the sentence describing when the information has to be given. There is also a narrow transition: for systems placed on the market before 2 August 2026 the marking obligation applies only from 2 December 2026, and content generated before 2 August 2026 does not have to be labelled retroactively. So the four month window does not exist for a new product; it exists so a system already in the field can retrofit its marking mechanism.

Most of this is interface work

The phrase in a clear and distinguishable manner at the time of the first interaction sits in a legal text, but what it describes is an interface decision. The disclosure does not belong in a settings page, a privacy policy or a footnote; it belongs at the moment the first message appears. In a chat interface that means one line above the first bubble. In a writing assistant it means the place where the assistance opens. Both are copy and layout work, and both get written into a component rather than into a compliance document. It also helps to know where the duty does not arise: the article leaves out the case where the interaction is obvious to a reasonably well-informed and observant person, and what draws the boundary of that exception is, again, the product’s own interface. A button with the word model in it may count as obvious; a suggestion box that appears at the edge of the page may not, and the line between them is drawn by a design decision rather than by a legal text.

The second duty is invisible in the interface, and that is precisely why it is easy to skip. Machine-readable marking is not a badge on screen, it is data carried inside the output that has to survive being exported. If an image loses its mark on re-encoding, or a text loses it on copy and paste, the obligation looks met on screen and is not met in fact. The article ties the standard to a durability claim rather than to a checkbox: effective, interoperable, robust and reliable as far as this is technically feasible.

What is genuinely unclear right now

The picture is not settled, and saying so is more honest than an invented certainty. The reason for the postponement is that standards are late, and the part that was not postponed sits in the same standards gap, because there is no single prescribed method for machine-readable marking and the text itself defers to technical feasibility. Read together, those two facts say that what took effect on 2 August is not a checklist but a duty to make a demonstrable effort. What will still be argued about a year from now is the measure of that effort.

One exception, and a record-keeping question

The deployer duty covering published text has an exception, and it is the one that will be used most in practice: where AI-generated text has undergone human review or editorial control and a real person or organisation holds editorial responsibility for the published content, the labelling duty does not arise. That is not an escape hatch, it is a sentence describing where responsibility sits: the fact that a model produced the text stops mattering, because somebody stands behind it.

The second practical consequence follows from the reason for the postponement. If the high-risk timetable moved because standards are not ready, then compliance with the part that did not move cannot rest on a ready-made standard either. In that case the only defensible move is to make what you did recordable: on which screen and at which moment the disclosure was shown, in what form and from which release the marking is written, which kind of output was left out of scope and why. Those are not sentences to be written into a compliance document afterwards, they are records that should already exist in release notes and in product code, and that is most likely exactly where a demonstrable effort will be measured.

What it means in this repository

There is no generative model on this site today, so Article 50 does not bind it. Writing that down is part of the job: presenting an obligation that does not apply as though it did causes as much damage as ignoring one that does. Where it will apply is the next piece of work, and the questions to ask there are already clear.

1. Does the user learn they are talking to AI at the first interaction, or on a settings page?
2. Does the generated output carry a machine-readable mark, and does that mark survive export?
3. In this setup, who is the provider and who is the deployer? Two of the four duties fall on the provider and two on the deployer, and a product calling a model over an API can be both at once.

One last note, and it is the most practical one: following a legal timetable and following compliance are not the same activity. In this round the postponed and the unpostponed parts were settled six days apart, and most headlines carried only the postponed half. The answer to what a product has to do by which date is read from the regulation itself and from the questions the regulator publishes, not from secondary coverage.