You are the deployer. EESI gives you the models, the phone leg and the speech stack; the person on the other end of the call is yours, and so are the duties that attach to calling them. This page tells you which duties bite, what the platform already does about each one, and — just as important — 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’re talking to an AI

Disclosure is the one duty that applies to essentially everything you can build here, and it applies at the start of the interaction — not when someone thinks to ask. What the platform does. Every /v1/realtime session inherits the platform persona, which answers the question honestly: asked what it is, or whether it’s a person, the model says it’s an AI. It won’t volunteer that every other sentence, and it won’t deny it. Every synthesized response also carries the X-Synthetic-Audio header, and realtime clients get a session-start declaration that the audio is machine-generated — the EU 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 call by naming itself as an AI unless your own instructions or greeting say so, and there is no pre-flight check that they do.
This bites hardest on a phone call. A phone leg is served by the relay, not by the gateway’s session rewriter, so it carries only the instructions in its session brief — the platform persona is not applied, and the model has nothing telling it to disclose. Put the disclosure in the greeting itself, where it is spoken verbatim, rather than in the instructions, which the model can paraphrase away.
Put it in the first sentence, before anything substantive. “Hi, you’re speaking with an AI assistant from Acme — how can I help?” satisfies all three regimes at once and costs you a second and a half of call time.

​
Outbound calls to US numbers

The TCPA governs prerecorded and artificial-voice calls to US numbers, and a synthesized voice on a call is an artificial voice. The short version: you need prior express consent before you dial, written consent if the call is marketing, and the consent has to be traceable to the specific number you called. Statutory damages run per call, which is what makes a badly sourced contact list expensive rather than embarrassing. The platform does none of this for you. Concretely, EESI has:
  • no consent store — nothing on a contact record says who agreed to what, or when
  • no scrubbing against the National DNC Registry or your internal suppression list
  • no recipient-local calling hours — nothing evaluates the timezone of the number being dialed, so “nothing before 8am where they are” is a constraint your dialing system has to enforce before it calls the API
Do the list hygiene upstream, in the system that captured the consent, and dial only numbers you are allowed to call. Keep your own record of the consent; a run’s transcript proves what was said on the call, not what someone agreed to a year earlier. Identifying the caller at the top of the call is also a TCPA requirement, and it composes with disclosure: name your organization and the fact that the caller is an AI in the same opening line — which, on a phone call, means the greeting in the session brief.

​
Recording and transcripts

Two-party-consent states (California, Florida, Illinois, Pennsylvania, Washington and others) require every participant to consent before a call 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’re recording, say it before the substance of the call, and be able to delete it afterwards. What the platform records, by default: Where audio is kept, the two directions are stored separately rather than mixed, so a caller’s own words can be produced or destroyed on their own. A realtime client is told at session start when the session is recorded, through a structured eesi.recording_disclosure event. That is a channel for a client to render, not a notice in the audio — and a phone caller never receives it, because the relay carries audio and nothing else. On a phone call nothing announces the recording unless your greeting does. In a two-party-consent jurisdiction that sentence belongs in the greeting, which is spoken verbatim. Deletion on request is real, and it means the bytes rather than a flag: Any session — a phone call included — is erased through the same endpoint. The audio objects go first, then the transcript and the row: a real delete, not a flag.
A track that fails to erase leaves the row in place, so the request can be retried rather than half-succeeding in silence. See Sessions. Deleting on request is not a retention policy, though. For that, see the next section.

​
Cloned voices

Every voice on this platform resolves to a stored reference clip — that is what keeps a voice from drifting between sentences, and it means a cloned voice is a recording of a real person sitting in your storage bucket. You need that person’s permission to clone them, and in several jurisdictions that 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 that imitates 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: create_voice rejects an upload unless you send consent_attested=true, and the timestamp of the attestation is stored on the voice as consent_attested_at. 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. Two things that help:
  • Built-in voices are designed from a text vocabulary, not cloned from a person, so they carry no likeness rights. Prefer them unless you specifically need a named voice.
  • delete_voice 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.

​
How long we keep it

This is the platform’s written retention and destruction schedule. Illinois BIPA requires one in writing for biometric data, and a policy that says “we delete when appropriate” is not one — so the periods below are specific, and a daily job enforces them rather than an intention to. Voice clones 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 voice row goes with them. Using a voice resets the clock; a voice you keep in production never expires out from under you. There is no recovery — export anything you need to keep before then, and hold your own copy of the speaker’s consent, which outlives the clip. Recordings and transcripts default to being kept. That default is honest rather than convenient: every recording made before this feature existed was captured under “keep forever”, and picking a period on your behalf would have destroyed call history the day it shipped. It also means an untouched organization has no retention limit on recorded data, so if your privacy policy states one, configure it. Once set, one period governs all three kinds of recorded artifact — realtime sessions, saved transcriptions and generation history — and anything older is erased by the daily sweep through exactly the same path as a deletion request: audio and transcript objects come off before the row, and a partial failure leaves the item intact and retryable. One setting rather than three, because a second column would only let one category quietly opt out of a period the operator believed they had set. Ask support to set the period for your organization. Closing an organization erases its data rather than orphaning it. Deleting the organization upstream queues the same erasure across every category — realtime sessions, saved transcriptions, generation history and every cloned voice it owns — so a voiceprint does not wait out its three years after the account is gone.

​
Summary: what you own