Compliance

You are the deployer. EESI supplies the models and the speech stack; the person on the other end of the conversation is yours, and so are the duties that attach to talking to them. This page says which duties bite, what the platform already does about each one, and — the half that matters more — where it does nothing and you have to.

This is engineering guidance, not legal advice. Thresholds, exemptions and enforcement differ by jurisdiction and by what you actually build. Read it as a map of where the platform’s defaults end.

Tell people they are talking to an AI

Disclosure applies to essentially everything you can build here, and it applies at the start of the interaction — not when someone thinks to ask.

Where	Rule	What it means
EU	AI Act Article 50, applicable since 2 August 2026	A person interacting with an AI system must be told, unless it is obvious to a reasonably well-informed person
California	B&P Code 17941	You may not use a bot to mislead someone about its artificial identity in a commercial or election-influencing interaction. A clear, conspicuous disclosure is the safe harbour
Utah	AI Policy Act	Disclose when asked, and disclose up front in a regulated occupation

What the platform does. A conversational /v1/realtime session inherits the platform persona, and that persona answers the question honestly: asked what it is, or whether it is a person, the model says plainly that it is an AI. It will not volunteer that every other sentence, and it will not deny it. Separately, every audio response carries a machine-readable synthetic-audio marker — the AI Act’s marking obligation, which is a different duty from telling the person. What the platform does not do. It does not speak a disclosure. Nothing opens a session by naming itself as an AI unless your own instructions or greeting say so, and there is no pre-flight check that they do.

Two ways that honest answer stops being there.Your instructions are appended after the persona, and trailing text carries the most weight. That is what lets your brief override the defaults — and it means an instruction of yours can also weaken the answer above.An interpreting session does not carry the persona at all. It gets the interpreter prompt instead, because a persona that introduces itself and declines to translate unasked is exactly the behaviour an interpreter must not have. Nothing in that session answers “are you an AI”.In both cases the disclosure is yours to put back.

Put it in the first sentence, before anything substantive: “You are speaking with an AI assistant from Acme — how can I help?” satisfies all three regimes at once and costs a second and a half.

Recording and transcripts

Two-party-consent jurisdictions — California, Florida, Illinois, Pennsylvania, Washington and others — require every participant to consent before a conversation is recorded. Under GDPR a recording is personal data and needs a lawful basis and an honest retention period. Both mean the same thing operationally: say you are recording, say it before the substance of the conversation, and be able to delete it afterwards. What the platform keeps:

Surface	Transcript	Audio
`/v1/realtime` sessions (Live, Duet, interpretation, native and SDK clients)	Kept unless the deployment or the workspace turned recording off	Same two switches, stored as one track per direction
`POST /v1/audio/speech`	The text you sent, in generation history	The generated audio, kept with it
`POST /v1/speech/transcriptions`	The transcript you saved	The uploaded source audio, where it was kept with the run

Session recording is on in the shipped configuration, and turning it off is a per-workspace decision made in the console under Settings. Two switches gate it — SPEECH_SESSION_RECORDING, which is the deployment’s capability, and record_sessions, which is the workspace’s choice — and both default to on. A session row is written either way, so a conversation can always be found; with recording off there is no transcript and no audio. See Sessions. Recording voice carries obligations that differ by jurisdiction. That is why every live session is handed a disclosure before any audio moves, below. Where audio is kept, the two directions are stored separately rather than mixed, so one person’s own words can be produced or destroyed on their own.

The disclosure event

Every live session receives a structured disclosure with the session-start declarations, before any audio frame is relayed:

{
  "type": "eesi.recording_disclosure",
  "event_id": "event_3b7d…",
  "disclosure": {
    "schema": "eesi-recording-disclosure/1",
    "recorded": true,
    "text": "This session is being recorded.",
    "disclosed_at": "2026-09-07T03:14:42.154209+00:00"
  }
}

recorded is derived from the same recorder that decides whether audio is actually kept, so the two cannot drift: if a session is recorded, the client was told, and there is no ordering in which it was not. When recorded is false because recording was requested but could not run, the disclosure carries status: "unavailable", a reason, and text saying the conversation can continue without a recording. disclosed_at is when the client was told, and it is a full ISO-8601 timestamp with microseconds and a +00:00 offset — not the …Z to the second that the synthetic-audio marker uses. Parse both with an ISO-8601 parser rather than a fixed format string. text is fixed on the server rather than left to each client, so every client discloses identically — a disclosure that differs per client is one nobody can attest to.

This is a channel for your client to render, not a notice in the audio. It does not satisfy a two-party-consent recording requirement on its own, and it is not consent evidence — nothing here records that anyone agreed. Show it before the person speaks, and keep your own record of the consent.

Cloned voices

Every voice on this platform resolves to a stored reference clip — that is what keeps a voice from drifting between sentences — which means a cloned voice is a recording of a real person sitting in storage. You need that person’s permission, and in several jurisdictions the permission has to be specific: Tennessee’s ELVIS Act and the New York and California right-of-publicity statutes treat a voice as a protected likeness, and the EU AI Act’s Article 50 deepfake rules attach to synthetic audio imitating a real person. Cloning a public figure, a celebrity, or a customer whose support call you happen to have on tape is the case these laws were written for. Cloning requires you to attest to that permission. POST /v1/voices rejects an upload unless you send consent_attested=true, and the moment of the attestation is stored on the voice as consent_attested_at:

{
  "error": {
    "message": "Cloning a voice requires `consent_attested=true`: you must confirm that this is your own voice, or that you hold the speaker's written consent to clone it.",
    "type": "invalid_request_error",
    "param": "consent_attested",
    "code": null
  }
}

An attestation is a record of your claim, not a verification of it. Nothing checks who is actually speaking on the clip you uploaded. The diligence is yours to run before the upload, and the evidence of the speaker’s permission is yours to keep — it has to outlive the clip.

Two things that help:

Built-in voices carry no likeness rights. They are designed from a text vocabulary rather than recorded from a person, so they are not biometric data and are not on a destruction schedule. Prefer them unless you specifically need a named voice.
DELETE /v1/voices/{voice_id} erases the reference clip from storage before the row, so a withdrawal of consent can be honoured completely rather than by hiding a row that still points at a voiceprint.

See Voice cloning for what makes a clip work.

How long data is kept

This is the platform’s written retention and destruction schedule. Illinois BIPA requires one in writing for biometric data, and “we delete when appropriate” is not one — so the periods below are specific, and a daily job enforces them rather than an intention to.

Data	Period	Measured from	Configurable
Cloned voices (reference clip, prompt cache, preview)	3 years	The individual’s last interaction — the last time the voice was used for synthesis, or its upload if never used	No. This is BIPA’s outer bound and applies to every deployment
Built-in voices	Kept	—	No. Designed from a text vocabulary, not recorded from a person
Recordings and transcripts — realtime sessions, saved transcription runs, and synthesis history	Kept until you set a period	The end of the session, or the upload	Yes, per organization, in days. One period covers all three
Unprocessed memory capture	1 day	When it was captured	No
Billing and usage rows	Kept	—	No. They record that a session happened and what it cost, not what was said
Operational telemetry (request rollups, backend health, per-turn latency)	14 to 90 days	When the row was written	No. Not a recording of anyone

Cloned voices expire whether or not you delete them. Three years after the last time a voice was used, the reference clip, the prompt cache and the preview are removed from storage and the row goes with them. Using a voice resets the clock, so a voice in production never expires out from under you. There is no recovery — export anything you need before then. Recordings default to being kept. That default is honest rather than convenient: every recording made before the schedule existed was captured under “keep forever”, and picking a period on your behalf would have destroyed history the day it shipped. It also means an organization that has configured nothing has no retention limit on recorded data. If your own privacy policy states one, configure it — the period is not self-serve today, so ask support to set it. Once set, one period governs realtime sessions, saved transcription runs and synthesis history alike, and the daily sweep erases anything older through exactly the same path as a deletion request: objects come off before the row, and a partial failure leaves the item intact and retryable. One setting rather than three, because a second control would only let one category quietly opt out of a period you believed you had set. The sweep is bounded per run and continues on the next one, carries on past an item that fails, is safe to run twice, and logs what it destroyed and what it skipped. A retention schedule nobody can prove ran is not a retention schedule.

Data subject requests

Every category has a real deletion path, and “deleted” means the bytes rather than a flag:

What someone asks you to erase	Call
A conversation, its transcript and both audio tracks	`DELETE /v1/speech/sessions/{session_id}`
A saved transcription run and its uploaded audio	`DELETE /v1/speech/transcriptions/{session_id}`
A synthesis take and the text that was spoken	`DELETE /v1/generations/{generation_id}`
A cloned voice, its reference clip, prompt cache and preview	`DELETE /v1/voices/{voice_id}`
One remembered fact	`DELETE /v1/user/memory/{memory_id}`
Every remembered fact, and memory switched off	`DELETE /v1/user/memory`

In each case the stored objects are erased before the row, because the row holds the only pointers to them: dropping it first and then failing on storage strands bytes nothing can ever find again. A failure therefore leaves the item visible and the request retryable rather than half-served. Closing an organization erases its data rather than orphaning it. Deleting the organization queues the same erasure across every category — realtime sessions, saved transcriptions, synthesis history and every cloned voice it owns — so a voiceprint does not wait out its three years after the account is gone. Personal memory is a special case worth knowing: it is scoped to one signed-in person and one workspace, API keys cannot read it, and deleting the conversation a fact came from erases the fact with it.

What you own

Duty	Platform default	Still yours
AI disclosure	The persona answers honestly when asked; nothing discloses unprompted, your instructions outrank the persona, and an interpreting session has no persona	Saying it, at the top of every conversation
Recording consent	A structured disclosure reaches every live client before any audio; audio is kept only where the deployment enables it	Rendering that disclosure, and keeping evidence of consent
Synthetic-audio marking	Every generated response is marked, in the header and in the container	Not stripping it, and not claiming it detects audio from elsewhere
Voice-likeness rights	Attestation required at upload, never verified	Permission from the speaker, and the evidence of it
Recording retention	Kept until you configure a period; erased on request through the API	Choosing the period, and stating it in your own policy
Voice-clone retention	3 years from last use, enforced, not optional	Exporting anything you need before it expires

Going further

Synthetic audio marking

The marker, where it rides, and the claim it cannot support.

Sessions

Finding, replaying and erasing one conversation.

Voices

The consent attestation, in the request that carries it.

Memory

What is stored per person, and how to remove it.

Start here

Realtime interaction

Speech

Platform

Tell people they are talking to an AI

Recording and transcripts

The disclosure event

Cloned voices

How long data is kept

Data subject requests

What you own

Going further

Synthetic audio marking

Sessions

Voices

Memory

​Tell people they are talking to an AI

​Recording and transcripts

​The disclosure event

​Cloned voices

​How long data is kept

​Data subject requests

​What you own

​Going further

Synthetic audio marking

Sessions

Voices

Memory

Tell people they are talking to an AI

Recording and transcripts

The disclosure event

Cloned voices

How long data is kept

Data subject requests

What you own

Going further