The EU AI Act as a Design Problem

The EU has pushed almost every AI Act deadline out to 2027 and 2028, but not the transparency obligations: those apply from August 2, 2026. The Commission issued its interpretive guidelines 13 days before the deadline: the AI disclaimer, content labeling, and human handover all have to sit in the components by default.

Anyone following regulatory news over the past months had good reason to think the entire EU AI Act was slipping. The Digital Omnibus on AI was published on July 24, 2026, pushing the obligations for standalone high-risk systems to December 2027, and those for AI embedded in regulated products to August 2028. Creditworthiness assessment, insurance risk pricing, and the entire conformity assessment apparatus all get at least another 16 months.

The legislator deliberately left one thing out of the deferral, though: the transparency obligations. These apply from August 2, 2026, and according to the regulation's own reasoning, the Digital Omnibus on AI had to enter into force as a matter of urgency precisely so that this date would not be put at risk. The interface itself is therefore untouched by the delay.

What It Requires, and Who It Binds

Article 50 of the AI Act covers four situations, each of which can be put as a simple question. Are you talking to it? A system that interacts directly with people has to disclose that it is AI. Does it generate? Synthetic audio, image, video, and text have to be marked in a machine-readable format. Does it measure? Emotion recognition and biometric categorisation have to be disclosed to the person concerned. Does it fake? Deep fakes and AI-generated text published on matters of public interest have to be visibly labelled.

How responsibility is divided decides whose job the solution is. The first two cases fall on the provider, the second two on the deployer, meaning the organisation that uses the system under its own name. A bank, for example, that puts a third party's chatbot on its customer portal is liable as a deployer for the labeling, and cannot pass on that responsibility to its vendor.

A reverse case shows that not everything can be settled by contract. Suppose a bank uses a generative tool to produce customer-facing text, say a macroeconomic outlook or a sustainability report. Machine-readable marking of the output is the provider's job; the bank cannot carry it out technically, only require it. One document, two obligations, two owners, and only one of the two comes with a way out: visible labeling can be omitted if the text has undergone substantive human review and someone takes editorial responsibility for it. The guidelines read this narrowly; a formal sign-off or a spellcheck is not enough for it.

The obligations apply immediately, regardless of when the system reached the market. There is a single transition: generative systems placed on the market before August 2, 2026 have until December 2, 2026 for machine-readable marking. There is no retroactive labeling obligation, but text generated earlier and published on or after August 2 falls under the rule.

The EU set of optional labeling icons

The interpretation has arrived as well. On July 20, 2026, the Commission adopted the final, 51-page guidelines. They are not binding, and only the Court can give an authoritative interpretation, but the market surveillance authorities will be following them. Alongside them sit a voluntary code of practice on content labeling and an optional EU set of icons. Using these is a choice, but there is no departing from the obligation itself; the fine for failing to comply is capped at €15m or 3% of global annual turnover, whichever is higher.

What the “Clear and Distinguishable” Principle Forces

The legislation states how the information has to be presented, and sets three things at once. It has to happen at the latest at the moment of first interaction, it has to be immediately distinguishable from its surroundings, and it has to meet the accessibility requirements.

The guidelines are at their most concrete about what they rule out. Disclosure buried in the terms and conditions, hidden deep in menus, or exiled to a manual does not qualify. This looks trivial, but its consequences are not. With disclosure, you also have to design where it appears and how long it stays visible.

It follows that the label cannot be a one-off flash. If a banner appears at the start of a long conversation and 60 messages later the user is at a credit limit increase question, while the first-interaction condition is formally met, distinguishability is not. The standard therefore calls for a label that stays visible throughout the conversation.

Whether the disclosure is legal depends in practice partly on meeting the WCAG (Web Content Accessibility Guidelines) requirements. An AI disclaimer that a screen reader never reads out does not exist for blind and partially sighted users. With visible labeling, contrast plays the same role: if it fails, the marker remains on the screen and does not separate from its surroundings. What used to be a question of good practice is now a compliance question as well.

In practical terms, all of this means a few new concrete decisions are needed on a chat interface. The disclosure has to appear before the user's first message, since the interaction is already happening as they type. A marker that stays in the header performs better than a bubble sliding in above the conversation, because the latter scrolls out of view. The label needs to appear in the accessible name of the conversation region, otherwise the user on a screen reader gets the unlabeled version.

Distinguishability is where most solutions can come undone. If the AI marker looks just like every other small label on the interface, the same pale, rounded badge in the same secondary colour, then the user glides straight past it. The guidelines don’t prescribe a typography; the question is whether the user notices, which is why the label has to stand out from its own brand environment too.

Transparency Has a Price, Concealment a Higher One

In UX discourse, the assumption runs strong that transparency builds trust on its own. The research – on this territory at least – shows the opposite. Across 13 experiments on US online panels, Schilke and Reimann had the same piece of work evaluated in two versions: one carried a note made with AI, the other did not. Subjects trusted the author of the AI-disclosing version less. In the researchers' explanation, disclosure violates the tacit expectation that human expertise stands behind the work. They tried several wordings, from the “a human reviewed it” reassurance to a version invoking radical transparency, but none restored the trust.

It is worth planning for this in advance, because the labeling will show up in the conversion numbers too. It serves the project better if this is priced into expectations from the start, rather than the first report being what breaks the news.

The same study, though, has a half-sentence that can put all of this in a different light: the trust-eroding effect of disclosure is weaker than when a third party happens to expose the AI use. The question is therefore one of timing: we pay the cost now, or pay a higher price later. Add to that the loss of trust being less frequent among those who feel positively about technology, so the effect varies by segment.

Why It Belongs in the Design System

The rule is easy to understand and hard to scale. If every screen touching AI has to go through an individual legal review, the pace of development will certainly suffer for it. If it is left to a developer's memory whether a one-off chat interface gets a label, then labeling will vary screen by screen, and the missing ones may well be found by the regulator.

There is a direct analogy for this where the same problem has already played out. An analysis of GitHub's accessibility audit data found that 48% of the issues could have been prevented in the design phase. Its conclusion was that a good component is not enough either: a missing ARIA label (Accessible Rich Internet Applications, the screen-reader-facing name that is not visible to the eye), a dropped error message, and poor focus management are not broken in the component, but where it gets built in. Its answer was the preset annotation, a per-component, pre-defined checklist on the canvas that has to be filled in, plus Code Connect, which carries those details into the code developers export.

GitHub’s examples for preset annotations

AI labeling behaves the same way, which is why it is worth applying the same mechanics to it. Conversational and generative components should get an explicit property for whether they are AI, where the content comes from, and whether they contain an exit to a human agent, all three switched on by default. And the code-side component should not allow a build without a label. That way font size, contrast, and position are decided once, globally.

In Time and Recognisably

On how an automated decision has to be explained to the customer, there is judicial guidance already. In the Dun & Bradstreet case, the CJEU (Court of Justice of the European Union) says an automated decision has to be intelligible enough for the person to contest it. Handing over the algorithm or the full scoring logic would not meet that test, and the person cannot demand it either.

Human handover, in turn, is under pressure from the supervisory side. Some national supervisors expect human oversight beyond the high-risk perimeter as well. The Hungarian central bank's recommendation, for instance, extends it to lower risk categories as good practice. A route to a human agent is therefore available from the first screen, not only once the bot gets stuck.

The obligation covering the interface applies from August 2, 2026, the one covering credit assessment systems from December 2, 2027. Anyone putting a banner above the chat now does formally comply, but will have to start the same work over again on a system that may well be bigger and riskier; anyone putting a banner in the component will only have to do it once.

The AI Act's transparency rules describe what a well-designed interface would do anyway: it speaks in time, it speaks recognisably, and it leaves a way out. The only new element is that solving it well on one screen is not enough. As long as labeling is not the default in the component, every new interface reopens the question.