Disclosure: Telling Users They’re Talking to AI
5 min read · updated August 3, 2026
Disclosure is usually implemented as a line in an onboarding modal, which satisfies neither of the two reasons it exists. One of them is a legal obligation with specific placement requirements; the other is a design goal that a modal cannot achieve at all.
Two reasons that want different things
The compliance reason is that in a growing number of jurisdictions, a person interacting with an AI system has to be told, and synthetic content has to be identifiable. This is satisfied by disclosure at the point of interaction, once, clearly.
The calibration reason is that a user who does not know the output is generated cannot apply the right amount of scepticism to it. This is not satisfied by a one-time notice at all, because the scepticism has to be applied at the moment of reading, by whoever is reading — including people who were never in your product.
The second requirement is strictly stronger and it is the one that drives the design. Meet it and compliance follows; meet only the first and you have a legally defensible product in which nobody knows which text was written by a machine.
What the regulation asks for
The EU AI Act sets transparency obligations in this area: providers and deployers of systems that interact directly with people must ensure those people are informed that they are interacting with an AI system, unless it is obvious to a reasonably observant person; providers of systems generating synthetic audio, image, video or text must mark the output in a machine-readable format as artificially generated; and deep fakes and certain AI-generated text published to inform the public on matters of public interest carry their own disclosure duties.
Two things that follow, and both are engineering work rather than copy work. Machine-readable means metadata or a provenance signal, not a visible label — a visible label is for the human and does not discharge the machine-readable requirement. And obligations attach differently to whoever builds the model and whoever deploys it, so “our vendor handles it” is not automatically true of a product that deploys someone else’s model.
Dates, thresholds and exact scope move, and anything specific stated here would go stale — the current position is worth reading in the AI Act overview and the disclosure requirements page rather than trusting a summary in a design article.
Label the output, not the session
The design principle is short: the label belongs to the artefact, because the artefact is what travels.
Generated text gets screenshotted, forwarded, pasted into documents and quoted in meetings. A banner at the top of your interface is not attached to any of that. A quiet marker rendered with the output is, for the screenshot at least, and metadata carried with an exported file is for the rest.
This also resolves an argument that comes up in every review, about whether persistent labelling is condescending to users who obviously know. It is not for them. It is for the third person who sees the output with none of the context, and that person is the one the calibration argument is about.
The handoff problem
The case that catches most products is support: a bot handles the conversation, then a human takes over, or the reverse. Users routinely cannot tell which they are talking to, and the failure is expensive in both directions — treating a person like a bot, or disclosing something private to a bot believing it was a person.
- Announce every transition explicitly, as a system event in the transcript, not as a change of avatar. Avatars are missed.
- Keep the current responder visible in the composer area, where the user is looking when deciding what to type — not only in the header.
- Never give a bot a human first name with no marker. This is the single most common deliberate ambiguity in shipped products and it is the one closest to the line discussed in dark patterns.
- Where a human is reviewing and sending AI-drafted replies, the honest label is neither “AI” nor silence. Something closer to “drafted with AI, sent by Sam” describes what actually happened.
A placement matrix
Keyed on the two questions that determine what is required: who sees the output, and does the medium carry the label with it.
| Case | Description |
|---|---|
| In-product, user is the reader | A quiet persistent marker on generated blocks. Once per block, not once per sentence — this is where the hedging tax applies. |
| In-product, exported or copied | Decide deliberately whether the marker survives the copy. Text copied out of your product loses everything you did not put in the string, and users will paste it somewhere that matters. |
| Sent to a third party under the user's name | The user is the author and takes responsibility; the disclosure that matters here is to the user, before sending, that this text was generated and is unreviewed. The approval step is the disclosure. |
| Conversational, real time | Identity of the responder must be continuously available, and every handoff announced. Voice is the hardest case: there is no persistent visual surface, so the disclosure has to be spoken and re-stated after any transfer. |
| Published publicly | Machine-readable provenance on the asset, plus a visible label. This is where the regulatory requirements bite hardest and where a visible label alone is not sufficient. |
The third row is the one teams get wrong most often, because it looks like the case with the strongest disclosure requirement and it is actually the case with a different one. When a user reviews and sends AI-drafted text under their own name, they are the author. Labelling the message to its recipient as machine-generated misdescribes what happened and is not generally what is being asked for. What is owed is disclosure to the sender, before sending, that this text was generated and has not been checked — which is an approval step, not a badge, and which is why it belongs to approval design.
Disclosure without theatre
A last point about register, since it is where good intentions produce bad interfaces. Disclosure done anxiously — a warning icon, a coloured band, a modal asking the user to acknowledge that they understand this is an AI — communicates risk rather than provenance, and it habituates exactly as fast as any other repeated warning. The information you are conveying is a fact about how the text was produced, not a hazard, and it should read like a byline rather than a disclaimer.
The corresponding failure in the other direction is disclosure that is technically present and practically invisible: grey-on-grey, six pixels, below the fold, or worded so obliquely that it does not register. Both extremes fail the calibration test in the same way, which gives a usable check — could a person who is not looking for it still tell, and would a person who is looking for it not feel warned off? Landing between those is the whole design problem, and it is a smaller one than the amount of argument it usually generates.