> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Voice biometrics privacy posture: consent, retention, and deletion under BIPA, CUBI, MHMDA, and GDPR

> The biometric-privacy regimes a tenant meets when enrolling voiceprints, and the tenant-owned controls Orbit exposes for consent capture, retention scheduling, erasure, residency, and audit.

# Voice biometrics privacy posture

Enrolling voiceprints puts you inside biometric-privacy law: Illinois BIPA, Texas CUBI, Washington MHMDA, and GDPR Article 9 each attach obligations to the party that collects and stores the biometric. Orbit supplies the controls — consent capture at enrollment, an operable ledger, hard delete, and DSAR erasure — and the posture decisions are yours: which disclosure to read, how long to keep a voiceprint, when to destroy it. This page maps each regime to the control that satisfies it. The mechanics of the lifecycle itself live in the [voice biometrics walkthrough](/guides/voice-biometrics-enrollment-walkthrough).

## 1. What counts as a voiceprint on Orbit

A voiceprint on Orbit is the 192-dimension speaker embedding minted from a short enrollment clip, plus the consent metadata you attach at capture. The analysis that mints it runs in an internal sidecar that accepts only HMAC-signed requests and caps clips at 30 seconds; the clip is analyzed before anything is stored, and a clip that fails the anti-spoof gate is refused with nothing written.

What the ledger stores per voiceprint: the encrypted embedding, the contact it binds, your verbatim consent text and its version tag, the anti-spoof score the enrollment clip earned, and timestamps. What it never exposes: embedding bytes or raw audio. `GET /api/v1/verify/voice-biometrics/` lists ids, contacts, consent versions, confidence, and timestamps.

The surfaces that consume a voiceprint:

* **Caller verification on a live call.** An enrolled voiceprint is stronger evidence than knowledge factors; [KBA caller verification](/guides/kba-caller-verification) defers to biometrics when the contact has a voiceprint on file.
* **Verify profile fallback chains.** Biometrics sits beside the profile's OTP chain as the step-up pairing; it is not a delivery channel on the profile.
* **The Voice Biometrics API.** The same enroll, challenge, verify, and delete lifecycle from your own application.

A contact with no enrollment resolves to `no_enrollment` on verify — an enrollment gap, not a match failure. Nothing biometric is ever computed against a caller who never enrolled.

## 2. Regulatory map

| Regime | What attaches at enrollment | The tenant-owned control on Orbit |
| - | - | - |
| Illinois BIPA (740 ILCS 14) | Written informed consent before capture (§15(b)); a published retention schedule with destruction when the purpose is satisfied or three years after the last interaction, whichever occurs first (§15(a)); no selling or leasing the identifier (§15(c)) | Your disclosure text in `consentText`; your schedule, run over the ledger with hard delete; no sale of biometrics by the platform |
| Texas CUBI (Bus. & Com. Code ch. 544) | Notice and consent before capture; prohibition on sale; destruction once the purpose for collection is satisfied | The same consent capture; your destruction schedule |
| Washington MHMDA | Biometric data processed to identify a consumer is in scope, and becomes consumer health data where voice analysis touches health inferences; consent must be freely given, specific, and free of dark patterns; deletion rights attach | Per-audience consent versioning; DSAR erasure covering the biometric category |
| EU AI Act, Article 5 | Prohibits named biometric practices: untargeted scraping to build identification databases, real-time remote biometric identification in publicly accessible spaces, and certain biometric categorisation | One-to-one, consented speaker authentication — matching a live caller against their own enrolled voiceprint — is none of those; keep the purpose narrow and documented |
| GDPR Article 9 | A voiceprint used to uniquely identify a person is special-category data; you need an Article 9(2) exception, in practice explicit consent | `consentText` plus `consentVersion` is your provable explicit-consent record; Article 17 erasure via hard delete and DSAR |

Every control in the right-hand column is tenant-owned. Orbit stores the enrollment you choose to capture and erases on your instruction; enablement, disclosure wording, and the retention schedule are your posture decisions, and the platform does not make them for you.

## 3. Tenant-owned configuration

### Require your disclosure before enrollment

`POST /api/v1/verify/voice-biometrics/enroll` stores nothing without `consentText` (10 to 5,000 characters: the verbatim disclosure the speaker agreed to) and a `consentVersion` tag you choose. That pair is your hook into every regime above: BIPA's written informed consent is the disclosure you write; the GDPR Article 9 explicit-consent record is the same row.

```bash theme={null}
curl -X POST "https://api.orbit.devotel.io/api/v1/verify/voice-biometrics/enroll" \
  -H "X-API-Key: $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contactId": "contact_8f2a1c9d",
    "audioBase64": "UklGRiQAAABXQVZFZm10IBAAAAABAAEA…",
    "consentText": "I consent to Devotel Orbit processing my voice for speaker verification (GDPR Art. 9).",
    "consentVersion": "gdpr-art9-v1"
  }'
```

When a consent version is retired or disputed, the version tag is the targeting metadata: list the ledger for the enrollments carrying it and erase them as a set.

### Set and run your retention and destruction schedule

BIPA §15(a) places the retention schedule on the collector — you. Orbit deliberately does not choose a period on your behalf, and it does not silently extend retention past the moment you erase: `DELETE /api/v1/verify/voice-biometrics/{voiceprintId}` is a hard delete of the row and its encrypted embedding, with no soft-delete window and no undo. After it, `GET /api/v1/verify/voice-biometrics/enroll/{id}` returns 404 and verify for that contact resolves `no_enrollment` until a fresh consent re-enrolls a new voiceprint.

Running the schedule is therefore yours to wire: when the purpose you enrolled for is satisfied — account closure, consent withdrawal, the interval you published — issue the delete for the affected ids you read from the ledger listing. Org-wide defaults for other pillars live on [data retention policy](/compliance/data-retention-policy); for voiceprints, the erasure primitive above is what your schedule executes.

### Bind the enrollment consent to your consent ledger

To keep voiceprint consent auditable beside your SMS, WhatsApp, and email consents, also record a consent receipt for the same contact through the consent surfaces ([consent management](/compliance/consent-management), [consent receipt integrity](/compliance/consent-receipt-integrity)) — the receipt write is what creates the consent ledger row your preference and suppression logic reads. Carry the same `consentVersion` tag on both writes: the enrollment row and the consent row then corroborate each other, and together they answer "what disclosure was the speaker shown, and when did they agree."

## 4. Deletion rights

Two paths reach the voiceprint store:

* **Direct erasure.** `DELETE /api/v1/verify/voice-biometrics/{voiceprintId}`, per row, from the API or the row action menu on the Verify page.
* **DSAR erasure.** A subject request through the [DSAR surface](/compliance/dsar) names biometric among its data categories; when the erasure runs, the subject's voiceprints are cleared with the rest of their data, and the erasure certificate closes the request.

For BIPA §15(a) destruction evidence, retain the erasure certificate: it records the categories erased and the completion timestamp, which is the destruction record your published schedule promised. A direct delete plus the ledger gap (the id now 404s) is the equivalent evidence when you run your schedule outside a subject request.

## 5. Data residency

Voice biometrics inherits your organization's residency posture on two axes:

* **The voiceprint row** lives in your tenant schema, alongside the rest of your contact and consent records — the same schema your [data residency overview](/compliance/data-residency-overview) posture applies to.
* **The clips** that produce and probe it are voice media, so they follow your voice region pin ([voice data residency](/compliance/voice-data-residency)); a caller's enrollment and verification audio never leaves the pinned region mid-call.

A region pin covers the voice media the residency guide enumerates. If a contract puts a residency requirement on biometric storage that goes beyond your current pin, raise it with support before you go live, exactly as the guide instructs for cross-channel requirements.

## 6. Audit and access

Every enrollment, challenge, verify verdict, and delete lands in the tenant audit stream with the operator or integration identity and the outcome, never the audio or the embedding bytes. Export the trail for a reviewer via [audit export](/compliance/audit-export).

The HIPAA boundary: a voiceprint used for speaker verification is not PHI by default — it is an identity factor, not a health record. If you pair voice analysis with care flows, so that a voiceprint gates or labels a care interaction, it can come into scope as PHI; operate it under your BAA and the [HIPAA posture guide](/compliance/hipaa-posture-guide) from that point on.

## 7. FAQ

**Does Orbit support BIPA-compliant opt-in?**
On the capture side, yes: enrollment stores nothing without your verbatim written disclosure and a version tag, and no biometric identifier is ever sold or leased by the platform. The schedule side is yours — BIPA places the retention schedule on the collector, and the ledger plus hard delete are the tools you run it with.

**Does an enroll call retain the spoof score?**
The enrollment clip's anti-spoof score is stored on the row as enrollment confidence, so a poor enrollment is visible and re-enrollable. Verify-time probe scores appear in the recent-events ledger per event. Neither path stores raw audio.

**Can Orbit destroy voiceprints on a schedule for me?**
No platform-side timer chooses a period; the schedule is the collector's under BIPA, and Orbit keeps the erasure primitive under your control. Wire the delete into whatever event satisfies your purpose — account closure, consent withdrawal, or a published interval.

**Is a voiceprint PHI?**
Not by default; see §6 for the care-flow case where it can come into scope.

## Where to go next

* [AI disclosure settings](/compliance/ai-disclosure-settings) — disclosure copy for AI-handled calls, the sibling consent surface.
* [KBA caller verification](/guides/kba-caller-verification) — the knowledge-factor path biometrics complements.
* [GDPR posture guide](/compliance/gdpr-posture-guide) — the Article 9 and Article 17 context in full.
* [DSAR erasure](/compliance/dsar) — subject-request erasure and the certificate.
* [HIPAA posture guide](/compliance/hipaa-posture-guide) — the PHI boundary when care flows are involved.
* [EU AI Act](/compliance/eu-ai-act) — the Article 5 prohibitions and deployer duties.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.