Write Trust and Disclosure Requirements (EU AI Act-Aware)

Workflow area: Agents & Responsible AI · Tier: Advanced · Hands-on time: ~40 minutes

Disclosure requirements are usually written twice: once as an afterthought before launch, and once properly after the first incident. The EU AI Act's transparency obligations (Article 50) made the afterthought version a compliance risk — chatbots must disclose they're AI unless it's obvious, and AI-generated content faces marking obligations, with the transparency provisions applying from August 2026 and penalties that get board attention. But treating this as pure compliance wastes it: disclosure, uncertainty display, and escalation paths are trust features that measurably affect adoption. The annex makes them requirements with acceptance criteria instead of legal review comments.

When to use — and when not to

• Use it for any feature where users converse with or receive content from AIchatbots, copilots, generated summaries, synthetic voice or imagery; if a user could mistake machine output for human output, this annex applies.
• Use it early enough to shape UIcitation panels, confidence treatments, and escalation buttons are design work, not disclaimer text; they need to enter the design cycle with the feature.
• Use it when you serve EU users, even from elsewherethe Act's reach follows the user, and your annex is the artifact legal review needs to assess exposure.
• Skip duplicating it per featurewrite it once as a product-wide standard, then annex per-feature deviations; ten inconsistent disclosure patterns are worse than one imperfect standard.
• Skip using this as legal advicethis playbook structures the requirements and the questions; classification of your system under the Act and final wording belong to counsel.

The recipe

1. 1.

   Classify what you're shipping in the Act's terms. Three questions with your legal team: does the feature interact with people (chatbot-style — Article 50 disclosure duty)? Does it generate or manipulate content that could pass as authentic (marking obligations, and deepfake-specific rules)? Could it plausibly fall into a high-risk category (employment, credit, education decisions — a different, heavier regime beyond this playbook)? Write down the answers and who confirmed them; the annex cites this classification.

2. 2.

   Draft the five-part annex with AI, against your actual screens.

   Copy

   Draft a trust & disclosure requirements annex for an AI feature
   spec. Write requirements with acceptance criteria, not policy
   prose. I will review with legal counsel — flag every point where
   counsel must confirm.
   Feature: [WHAT IT IS, WHO USES IT, EU EXPOSURE YES/NO]
   Surfaces: [WHERE OUTPUT APPEARS — chat, inline text, email, voice]
   Classification (from legal triage): [interacting / generating /
   both; high-risk: no]
   
   Cover, as numbered requirements:
   1. AI LABELING — where and how the user is told they're
      interacting with AI (EU AI Act Art. 50-aligned): placement,
      persistence (visible at conversation start AND discoverable
      later), wording tone; machine-readable marking for generated
      content where applicable.
   2. UNCERTAINTY DISPLAY — when and how the UI signals low
      confidence or missing grounding; what NEVER gets a confident
      treatment.
   3. CITATION UI — which claims require sources, how citations
      render, what happens when no source exists (say so, don't
      fabricate authority).
   4. FEEDBACK AFFORDANCES — per-output flag/rate controls, where
      reports go, response SLA.
   5. HUMAN ESCALATION — how a user reaches a human, in how many
      steps, and the no-dead-end rule when AI can't help.
   Each requirement: rationale in one line, acceptance criterion
   testable by QA, and [LEGAL-CONFIRM] tags where wording or
   applicability needs counsel.
   

   Sample output fragment:

   Copy

   R1.2 — Persistent discoverability. The "AI assistant" label
   appears in the conversation header at all times, not only in the
   first message. Acceptance: label visible in a screenshot of ANY
   point in a 20-turn conversation. [LEGAL-CONFIRM: wording
   "AI assistant" vs "virtual assistant" against Art. 50 phrasing.]
   R5.1 — Two-click human. From any AI response, a user reaches
   the human-escalation entry point in ≤ 2 interactions; the
   escalation carries conversation context with user consent.
   Acceptance: QA path test on all surfaces.
   

3. 3.

   Make uncertainty honest instead of decorative. The failure mode is a UI that renders every answer with identical confidence chrome. Decide the two or three states your system can actually distinguish (grounded-with-source, generated-without-grounding, low-confidence/declined) and give them visibly different treatments. If your system cannot distinguish them, that's a product gap to log — do not fake a confidence signal you don't have.

4. 4.

   Route the feedback somewhere real. A thumbs-down that lands in a dashboard nobody owns is a disclosure liability, not an affordance. Spec the pipeline: flagged outputs go to a reviewed queue, confirmed failures become eval cases (pb-40) and failure-catalog entries, and user-facing acknowledgment closes the loop. Name the owner and the review cadence in the annex.

5. 5.

   Run the legal review as a working session. Send the annex with its [LEGAL-CONFIRM] tags 48 hours ahead, then walk the actual screens together — counsel reviewing live UI catches what document review misses. Record outcomes per tag (confirmed / changed / open), the date, and the reviewer. Store the annex in Notion beside the feature spec with a review-trigger list: new surface, new jurisdiction, Act guidance updates, or a model change that alters content types.

Make it yours

• Voice and avatar variant: spoken disclosure at session start plus a periodic reminder for long sessions; synthetic-voice marking has deepfake-adjacent obligations — escalate that classification question to counsel explicitly.
• API/platform variant: when customers build on your AI, disclosure duty partially transfers — annex the contractual requirement (customers must disclose AI to end users) and what marking metadata your API emits so downstream disclosure is even possible.
• Trust-metrics addition: instrument the annex — label visibility (do users know it's AI? survey it), escalation usage rate, feedback volume. pb-41's ladder gains a trust rung, and you learn whether disclosure hurts adoption (evidence says less than teams fear).

Quality check

• Every requirement has a QA-testable acceptance criterion"clearly labeled" fails; "label visible at any scroll position in any turn" passes.
• Escalation has a step count and no dead endscount the clicks from worst-case entry; "contact support" links that loop back to the bot fail the annex.
• Uncertainty states map to real system signalsno confidence theater; the UI distinguishes only what the system genuinely distinguishes.
• Feedback has a named owner and an SLAthe affordance is a pipeline with a queue, not an icon.
• Legal review is recorded per tagconfirmed-by-whom-and-when exists for every [LEGAL-CONFIRM]; an annex without the review log is a draft.