Skip to main content

​
AI disclosure pre-publish setup & evidence

The AI disclosure settings page describes what the surface stores. This guide walks the same surface end-to-end before a first agent goes live: decide which regimes apply, store the posture, verify the notice on a real chat and a real call, and collect the evidence an audit asks for. Run through it once per workspace, then re-run the verification steps whenever the posture changes.
AI disclosure is a tenant-owned control. You decide which regime applies to your traffic and what the notice says; the platform stores the posture, delivers the notice on every AI interaction while it is enabled, and records every change in the audit log. The platform does not mandate disclosure — confirm which regimes apply to you with qualified counsel. Section 6 covers exactly what “tenant-owned” means here.

​
1. Four regimes, one toggle each

Four disclosure regimes share the same requirement — the contact must be told they are interacting with an AI — so the workspace encodes all four with one toggle each, plus the master switch: Two facts decide how you set them:
  • default_enabled is the master switch. The regime toggles mark which rules apply; the master switch is what activates the notice and the AI-generated content marking. Most workspaces that need any regime turn the master switch on plus their regime toggle.
  • No geo-detection. A toggle applies workspace-wide. The platform never infers a contact’s jurisdiction from their number, address, or IP — if any of your traffic touches the EU, enable the EU rule for the whole workspace. The single exception is the SB 243 reminder, which fires only for contacts you have explicitly flagged as minors.

​
2. The console surface

Everything this guide does by API you can also do in the dashboard:
  1. Open Settings → Compliance → AI Disclosure.
  2. Set the master switch, the regime toggles, the chat notice text, the voice intro text (or a pre-recorded intro URL), and the SB 243 reminder interval.
  3. Save. The change takes effect on the next agent turn — no agent republish is needed.
The page requires the owner or admin role; a member sees it read-only.

​
3. Store and apply via the API

The posture is one singleton row per workspace. A GET returns the full state; a PUT is a partial update — only the keys you send change.
A fresh workspace returns { "settings": null } until the first write. The full field table — every parameter, its type, and its bounds — is on the settings reference page. Send "voice_intro_audio_url": null explicitly to clear a pre-recorded intro; invalid payloads get a 422 naming the field that failed.

​
4. Verify before you publish

Do this in the hour before the first agent goes active. A saved row is not evidence the contact actually hears anything.
  1. GET /api/v1/compliance/ai-disclosure — the row is not null, default_enabled is true, and the toggles for your regimes are true.
  2. Read the response’s chat_notice_text and voice_intro_text out loud, the way a contact will receive them. Check them against the wording legal approved, not against what you remember writing.
  3. Start a real chat session with the agent — the notice appears on the agent’s first reply, once per conversation.
  4. Place a real test call to the voice agent — the intro plays (or the pre-recorded URL speaks) before the agent says anything.
  5. If you enabled the SB 243 reminder, run a test session with a contact flagged as a minor and confirm the reminder fires at your configured interval.
If step 3 or 4 fails, the most common cause is an unflagged workspace: the row exists but default_enabled is still false. Re-check step 1.

​
5. Evidence a buyer wants at audit

Assemble the binder before anyone asks for it. Each item comes from a surface you already have:
  • The posture snapshot. The GET response above, saved with its timestamp — this is the exact wording and toggles in force. It lives in your evidence binder alongside your other audit artifacts.
  • The change history. Every write to the endpoint is recorded in the audit log under the action compliance.ai_disclosure_updated, with the acting user’s identity and the previous and new value of every changed field. Export the range your audit covers through audit export and include it — it shows what the mandatory notice said at any point in the period, not only today.
  • The live-render proof. From section 4: a transcript or screenshot of the chat notice on the first reply, and a call recording or log line of the voice intro playing. Captured the day you verified, this ties the stored posture to a rendered notice.
  • The agent inventory. The agent identity governance surface lists every agent in the workspace with its sponsor and channel reach — use it to show which agents carried the notice during the period.
Together the four answer the questions an auditor actually asks: what did the notice say, who set it and when, was it active, and which agents delivered it.

​
6. What “tenant-owned” means here

Split the responsibility precisely:
  • You own the decision. Which regimes apply to your traffic, what the notice says, and whether disclosure is on. The platform never decides a regime applies to you and never forces the master switch on — except for the single platform-wide federal calling-window guard, which is unrelated to AI disclosure.
  • The platform owns the machinery. Storing the singleton row, rendering the notice on every qualifying chat and call while it is enabled, stamping AI-generated content marking, and recording every change with previous and new values.
  • The platform does not interpret your traffic. There is no geo-detection and no inferred minor status — the workspace-wide toggles and the contacts you flag are the only inputs.
That split is why section 5 works: because the decision is yours, the evidence an auditor wants is evidence of your decision and its delivery — and both halves are on surfaces your workspace controls.