Disclosure patterns: telling users when a machine is speaking

Every AI product eventually has the disclosure meeting. Legal wants the label bigger, marketing wants it smaller, design wants it elegant, and someone suggests a tooltip. Six weeks later the feature ships with "This content may be AI-generated" in 11px grey text that users have learned to ignore, which is to say it has learned them to ignore it. Disclosure done this way satisfies a policy while teaching users nothing — the worst of both outcomes, paid for with screen space.

We take a different position, and it's a design position, not a compliance position: disclosure is a trust instrument. Users who know when a machine is speaking calibrate correctly — they double-check the right things, forgive the right errors, and escalate the right edge cases. Users who don't know either over-trust (until the first visible failure, after which they trust nothing) or under-trust (and never adopt). Both failure modes trace back to disclosure that was filed, not designed. Here's the pattern language we use when we build it — the same thinking that underpins our public responsible-AI review.

The three questions good disclosure answers

Users don't need a legal notice; they need answers to three questions, and each has a level of the interface that owns it:

"Is this from a machine?" — answered at the point of content. Per-message or per-artifact, inline, unmissable by anyone actually reading. Not a banner on the page, not a modal at signup: adjacent to the thing itself.

"How much should I rely on it?" — answered at the point of decision. This is confidence, freshness and grounding, communicated where the user decides to act — the same problem as communicating probabilistic features honestly, and disclosure that stops at "AI-generated" without touching reliability is doing half the job.

"What happens if it's wrong?" — answered at the point of commitment. Recourse: who reviews this, can I undo it, does a human see it before it matters. This belongs next to destructive or consequential actions, not in the footer.

If your disclosure answers question one and ignores two and three, you've built a disclaimer, not trust.

Placement patterns, ranked by honesty

We've tried most of the field. In descending order of how much calibration they actually produce:

Inline labels with content. A small, consistent marker on each AI artifact — "AI draft" on the email preview, "Generated summary" above the abstract. High coverage, near-zero cost after the component ships, and it survives screenshotting: the label travels with the content when it's pasted into a slide deck. This is the baseline. Non-negotiable.

First-run disclosure with a real explanation. On first encounter, one focused moment: what this feature does, what it's good at, what it's bad at, where the human is. We cover the full arc in onboarding users to an AI assistant. The failure mode is the dismissible-forever banner, which users close in 400ms and you cite in the incident review. Make it skippable, never make it wallpaper.

Capability framing in empty states. "I can summarise this thread, but I can't send anything without you" is disclosure disguised as helpfulness — and the best-performing kind, because it arrives before the user has an opinion to defend.

Ambient indicators. An avatar tint, a labelled rail, a slight typographic register shift for machine content. Subtle, cheap, always-on — and weakest alone, because ambient signals outlive their novelty in about a week. They reinforce inline labels; they cannot replace them. Never let ambient be your only disclosure. It is the seatbelt reminder chime, not the seatbelt.

The legal footer. Necessary for contracts and regulation, useless for UX. Ship it, link it, and stop pretending it informs anyone.

Watermarking and export: the content outlives the app

The moment AI content can leave your product — copied, exported, forwarded — your inline label stops existing. So the label has to travel. In practice:

• Text artifacts carry a provenance line in exported documents ("Drafted with [product] AI — reviewed by [user] on 14 August"). Not a watermark on the pixels; a line in the artifact that survives copy-paste. B2B buyers actually want this — it's their compliance story too.
• Generated imagery gets verifiable provenance metadata where the pipeline allows, plus visible marking when the use case is public-facing. The point isn't policing; it's that a viewer two hops away can answer question one.
• Reports and summaries embed a grounding block: sources consulted, when, and who approved. This converts the export from a black box into an auditable document — the same philosophy as citation design, applied at the artifact boundary.

The test we apply: pick up one artifact from your product, strip the interface, and hand it to a stranger. Can they tell a machine helped make it? If not, export tore your disclosure off.

Model transparency: name the stack, not the spec sheet

Users occasionally deserve to know which system is speaking, and almost never benefit from knowing the version number. Our rule of thumb: disclose tier and trail, not build.

A settings row or "About this answer" affordance that says which model class handled the request ("Fast model · routed because this was a lookup") is useful where routing affects quality users can feel — structured tasks versus open-ended writing, say. It also pre-answers the "why was it dumber this morning?" support ticket when you migrate models mid-flight. What's not useful: changelog-grade version pinning in the UI, which invites benchmarking complaints and calibration theatre. Put that in your status page and release notes; keep the product surface in registers users can act on.

One exception: regulated or high-stakes contexts, where "which model answered" may matter after the fact. Keep the record server-side and exportable on request rather than tattooing it on every message.

Wording that informs without alarming

Disclosure copy lives or dies on tone, and the tone failure is binary: either it reads like a hostage note ("WARNING: AI-GENERATED CONTENT MAY CONTAIN ERRORS") or like a shrug ("✨ made with AI"). The wording that works is functional — it tells users what to do with the information:

• Weak: "This response was generated by AI."
• Strong: "Drafted by AI from your last three summaries — worth a quick fact-check before sending."

The strong version names the source, the input, and the appropriate verification behaviour. It treats the user as a capable adult reviewing a junior colleague's work, which is precisely the voice problem AI features have. We run every disclosure string through the same editorial bar as marketing copy, then through a red-team pass: would this wording still read as honest after the model has a very bad day? If a sentence would look embarrassing quoted in a "look what the AI did" screenshot, rewrite it now, preemptively.

And keep the register consistent across surfaces. If the empty state promises a careful assistant and the error toast yells about hallucination, users learn that the copy is scenery. One voice, established early, held under failure conditions — the same discipline we apply to brand voice everywhere else in a product.

The review: making disclosure survive legal and users

The meeting doesn't have to be a fight. We run disclosure through one review with two lenses in the room simultaneously. Legal's lens asks: is it accurate, is it comprehensive, could it imply a warranty? The design lens asks: did the user notice, do they know what to do, does it match reality? The artefacts that usually end the argument: a screenshot set of every disclosure surface in context (legal reviews depend on context; abstracted strings get misjudged), and a handful of 5-second comprehension tests — show the screen for five seconds, ask "what made this?" If fewer than four of five testers answer correctly, the label is filing, not disclosure.

Ship the honest version. Products we've built with loud, functional disclosure don't show slower adoption — they show calmer adoption: fewer trust-collapse churn events after visible model failures, because users were never oversold.

Key takeaways

• Disclosure is a trust instrument. It must answer three questions — machine-made? how reliable? what if wrong? — at the point of content, decision and commitment respectively.
• Inline per-artifact labels are the non-negotiable baseline; ambient indicators reinforce but never replace them.
• Watermark the exports. Content outlives your interface, and provenance lines survive copy-paste where pixel labels don't.
• Disclose model tier and routing where users can feel it; keep version numbers out of the product surface.
• Write functional disclosure copy: name the input, name the verification behaviour, hold one voice through failure states.
• Review disclosure with legal and testing in the same room, judged on screenshots-in-context and five-second comprehension, not abstracted strings.

FAQ

Won't a prominent AI label hurt adoption? We haven't seen it. What hurts adoption is the trust-collapse event: a user discovers the machine after being burned by it. Loud labels produce calmer growth curves — slower in the first session, sturdier by the second month. The users you "lose" to an honest label were leaving at the first hallucination anyway, louder.

Does this apply to small assists, like autocomplete? Scale disclosure to consequence. Autocomplete a user can see and edit inline needs nothing beyond the visible behaviour itself — the suggestion is the disclosure. As autonomy and stakes rise (whole drafts, sent messages, financial figures), the label grows toward inline and export-level. One rule binds it: the label's prominence tracks the cost of the content being wrong.

Do we need to disclose when AI was used but a human reviewed it? Yes, and the wording writes itself: "AI-drafted, human-reviewed by Priya Nair." The human sign-off is the most powerful trust signal available — use names and roles where the review is real, and never claim review that didn't happen. Fake human-in-the-loop labels are the one disclosure sin users don't forgive.

Should disclosure be a setting users can turn off? Never for point-of-content labels. You can let users collapse repeated explanations (they've read it, they know), but the question-one label isn't theirs to remove — the recipient of a forwarded artifact didn't consent to the setting. Disclosure rights belong to whoever reads the content, not whoever configured the sender's app.

How do we handle third-party platforms that strip metadata? Assume stripping and design for it: the visible line in the artifact body survives what the metadata doesn't. For images, visible marking in the corner of public-facing creative; for text, the provenance line in the footer of the document itself. Metadata is a bonus layer, not the plan.