Skip to main content

​
FCC 24-17 — written consent for AI voices

If you run outbound voice with an AI agent, text-to-speech playback, or a cloned voice, US federal law demands prior express written consent from the recipient. Orbit enforces that bar on every outbound leg before the call is placed, and blocks with 422 FCC_AI_VOICE_WRITTEN_CONSENT_REQUIRED when you haven’t recorded it. This page explains what the rule changed, which call-metadata signals trigger the gate, how it orders with the other build-time guards, and how a legitimate synthetic-voice campaign complies.

​
What FCC 24-17 changed

The FCC’s February 2024 declaratory ruling (DA 24-17) put AI-generated voices under the TCPA’s “artificial or prerecorded voice” rule — 47 CFR § 64.1200(a)(1)(iii). Two consequences follow for outbound callers:
  • Synthetic means artificial. Text-to-speech of any kind — including a Devotel TTS voice, and including voices from third-party providers — is an “artificial voice” under the rule.
  • Cloned means artificial too. A voice model trained to mimic a specific person still qualifies; the ruling attaches the same bar to both kinds.
The exposure is statutory: 500–500–1,500 per non-compliant call (47 U.S.C. § 227(b)(3)). For marketing calls under the TCPA, the prior express written consent bar applies — not merely verbal or implied. Orbit’s role, consistent with the wider compliance model (compliance posture): the platform classifies the voice on each outbound leg and enforces a consent check against your consent records. The obligation to obtain valid written consent is the tenant’s.

​
Classification: how Orbit decides which voice a call uses

At send time the gate reads the call’s request metadata and resolves one of three content types — human, synthetic, or cloned — using this precedence, first match wins: Voice campaigns stamp these keys for you — the outbound campaign path writes voice_agent_id on AI-voice legs, and text-to-speech sends stamp tts_text / tts_body. The agent_id fallback keeps direct-API callers inside the gate. Only when none of those signals is present does the call count as human (click-to-call, bridged agent, conference). Worked examples (input metadata → verdict): A human verdict short-circuits the consent check entirely — no database read, no block.

​
Where the gate runs

The gate sits before any paid or media work:
  1. It runs after the federal dialing-window guard — the one platform-global control that stops calls outside 8 AM–9 PM recipient- local time (the federal voice guard). That guard always runs first; this one layers on top of it and never relaxes its outputs.
  2. It runs before the send claim takes a billing hold, before any media room is created, and before the leg is dispatched to the voice fabric.
That ordering is the point: a blocked consent call never burns a billing hold, never opens a media path, and never interacts with the disposition lock that would otherwise record a half-routed call. Human-voice calls are unaffected because the classifier returns human without a consent check.

​
Failure posture: fail closed

The consent lookup blocks on two failure shapes, not just on “no consent”:
  • Consent schema missing. A workspace whose consent records table was never provisioned (older tenants) blocks — migration instructions included in the returned error.
  • Lookup error. Any non-does not exist database error on the existence probe is captured and blocks, same shape.
Fail-open would silently treat an AI voice as compliant whenever the database hiccups. At 500–500–1,500 per call of statutory exposure, that risk is the platform’s to take on the block side, not yours to wave on the allow side. The tradeoff is a blocked call (fixable) versus a class-action discovery request you have to answer. When a block fires, the event lands in your audit log as a voice.fcc_ai_consent_blocked entry — see below. From there the entry shows up as a consent-evidence gap you can chase and close in your own audit exports: the recipient, the voice type the classifier saw, and the reason (no_written_consent_on_record, tenant_consent_schema_missing, or consent_lookup_error). Process those entries the way you process any other consent-evidence gap, through the consent register.

​
Audit trail

Every block writes a voice.fcc_ai_consent_blocked audit row to the append-only, tamper-evident chain before the error is thrown, so the regulatory evidence survives whatever happens to the request upstream. The row carries the classification verdict, a redacted recipient number, the reason, and the campaign/agent id when those were stamped. Allow-path calls do not write — the usual voice-call audit downstream covers granted- consent calls. Filter on voice.fcc_ai_consent_blocked in your audit log to work the queue.

​
Complying with a legitimate synthetic-voice campaign

  1. Obtain prior express written consent for every recipient under the consent register — either under consent type fcc_24_17_written_consent, or with a free-text type plus a lawful_basis entry of fcc_24_17_written_consent in the record’s metadata.
  2. Stamp it in the right shape. The gate accepts either marker on a granted, non-revoked record; both unblock a synthetic or cloned call for that recipient.
  3. If you’re blocked, the error tells you which. 422 FCC_AI_VOICE_WRITTEN_CONSENT_REQUIRED carries the reason and a hint describing the exact consent row shape to add. Human-voice paths are outside the gate entirely.

​
Tenant ownership

Recording and holding valid written consent is your obligation — Orbit classifies, enforces, and audits; it does not obtain consent for you. This page is not legal advice; run the posture by qualified counsel, same as any US voice-consent question.

​
See also