Disclosure, Trust and the Product Surface

Disclosure is a design decision before it is a legal one

Regulatory transparency obligations exist and vary by jurisdiction — Practical AI for Future Managers covers the EU position, and the general shape is that obligations bite hardest where users could mistake a system for a human or content for genuine.

But most disclosure decisions are not driven by regulation. They are driven by whether the user needs to know in order to use the product well.

Disclose where it changes what the user should do. If knowing the output is generated should prompt them to verify it, tell them, at the point of use.

Do not disclose where it does not. A search ranking has always been algorithmic. Labelling every ordered list "AI-powered" is noise, and it trains users to ignore the label — which means the label is unavailable when you genuinely need it.

That last point is the strongest argument against over-disclosure. Warnings work by being rare. A banner on every surface becomes furniture within a week, and then the one surface that genuinely needed a caution has a caution nobody reads.

Set expectations in the product

Users form their model of what a product can do from the product, not from documentation. Three places carry almost all the weight:

The empty state. What the product says before the user has done anything is the most-read text in any product. Say what it does well and what it is not for. A drafting tool whose empty state says "I write first drafts of customer replies — check names, dates and figures before sending" has set expectations more effectively than any onboarding flow.

The first failure. Covered below.

The language of the output itself. A system that writes "the contract appears to require 90 days' notice — see clause 14.2" is making a calibrated claim. One that writes "the contract requires 90 days' notice" is making an assertion. The second is more satisfying and less honest, and it is a product decision, controlled in how you instruct the model.

The moment of discovery

The most important moment in an AI product's relationship with a user is the first time they catch it being wrong. What happens then determines whether they calibrate or abandon.

Two paths from the same event:

The product overclaimed. The user believed it was reliable, discovers it is not, and revises their trust downward sharply — often below what the system deserves. They now doubt everything, including the parts that were fine. This is why overclaiming is expensive: you spend trust you will need later.

The product was honest. The user was told it produces drafts to check, catches an error, and concludes: yes, this is what it said it was. Trust is unchanged or increased, because the product's self-description proved accurate.

The asymmetry is worth stating plainly. Underpromising costs you a little enthusiasm at the start. Overpromising costs you the relationship at the first error, which will come. Since errors are certain, the arithmetic is not close.

Design for that moment concretely: make it easy to report a wrong output, respond to reports, and where you fix something, tell the person who reported it. A user who reports an error and sees it fixed becomes more committed than one who never found an error at all.

The empty state is the highest-traffic text in a product and is usually written last, by whoever is available.

Version one: "Ask me anything about your documents."

Confident, inviting and actively harmful. It promises everything, so every limitation is experienced as a failure. Users ask about documents that were never indexed, ask for judgements the system cannot make, and ask questions whose answers are not in any document — and every one produces either a confident wrong answer or a refusal that now reads as a defect, because the product said anything.

Version two: "I search your uploaded contracts and quote what they say. I can find clauses, dates and obligations, and I'll link to the exact paragraph. I can't tell you what a clause means legally, and I only know about documents in this workspace."

Longer, less exciting, dramatically better. It states the capability, the evidence behaviour (quoting and linking), and two explicit limits. A user who reads it forms an accurate model in ten seconds.

What this changes downstream:

Fewer out-of-scope questions, so the refusal path is exercised less and the system looks more capable.
The first error is survivable, because "I quote what your contracts say" never promised interpretation.
Support load falls, because most support questions in AI products are really expectation mismatches.
The evaluation set gets easier to define, because the empty state is a de facto specification — anything it promises should be in the set.

That last point is the one to carry: the empty state and the evaluation set should say the same thing. If your product promises something the evaluation set does not measure, you are promising something you are not testing.

❓ Knowledge Check

Why does over-disclosure — labelling every AI-touched surface — damage a product?

📚 Flashcards1 / 6

Term

Disclose where it changes behaviour

Click to flip

Definition

Tell users where knowing the output is generated should prompt them to verify it. Labelling surfaces where it changes nothing trains users to ignore the label.

Click to flip back

💡Key Takeaway

Disclose where it changes what the user should do and nowhere else, because universal labelling destroys the mechanism you need for genuine cautions. Set expectations inside the product — the empty state is the most-read text you have and should say the same thing your evaluation set measures. Prefer calibrated language over confident assertion, and design deliberately for the moment a user first catches an error, because that moment decides whether they calibrate or leave.