Voice Consent and Deepfake Policy

Reference documentation: not a medical device

This documentation describes a public reference implementation evaluated on 100% synthetic data. It is a capability and readiness reference, not a compliance certification or legal advice, and it is not a medical device. It is not clinically validated and handles no production PHI.

Documents the voice integration consent framework for the ai-agent-eval-harness-healthtech reference implementation, including consent mechanisms, deepfake risk awareness, and the voice data handling policy.

Read alongside the regulatory posture and the voice extension design decision.

Voice Integration Overview

The reference implementation includes optional voice capabilities via ElevenLabs TTS/STT integration: text-to-speech for agent responses and speech-to-text for user input. Voice is an opt-in feature, OFF by default, with a persisted toggle in the browser. Voice metadata is carried on streaming sidecar events rather than in the chat response schema, preserving the stable response contract and schema immutability.

Consent Framework

Current Consent Mechanisms

Mechanism	Implementation	Location
Voice toggle	Opt-in via UI toggle; default OFF; persisted in the browser	Frontend SPA
Feature detection	Browser capability check (navigator.mediaDevices, MediaRecorder); graceful disable if unsupported	Frontend feature-detection module
Disclosure modal	Pre-permission disclosure modal explaining: what data is captured, how it is processed, that audio is NOT retained	Frontend modal component
”Audio NOT retained” notice	Displayed in multiple locations: disclosure modal, voice settings panel, microphone activation indicator, and help/FAQ section	Frontend UI
Recording duration limit	30-second maximum recording duration per turn	Frontend enforcement
Microphone visibility	Visual indicator when microphone is active; follows browser permission indicators	Frontend UI overlay

Consent Flow

1. User opens voice settings or clicks the microphone for the first time
2. Disclosure modal appears explaining: voice input is converted to text via STT, processed by the agent, and the audio is NOT stored or transmitted beyond the STT service
3. User acknowledges the disclosure
4. Browser permission prompt for microphone access (native browser UI)
5. If granted: voice toggle activated, microphone indicator shown when recording
6. If denied: graceful fallback to text-only input

What Voice Data Is NOT

• Voice data is NOT stored persistently
• Voice data is NOT used for model training
• Voice data is NOT shared with third parties beyond the STT service
• Voice biometrics are NOT collected or analysed
• Voice recordings are NOT retained after STT processing

Deepfake Risk Awareness

Threat Assessment

Voice-enabled AI systems carry inherent deepfake risks that must be acknowledged and mitigated:

Risk	Assessment	Mitigation
Voice cloning from user input	User audio is processed by STT (speech-to-text) and not used for voice synthesis; no voice model is trained on user audio	STT-only processing; no voice model training pipeline; audio not retained after STT
Synthetic voice impersonation	TTS generates agent responses using ElevenLabs voices (Sarah/EN, Matilda/ES, Bella/PT-BR); these are licensed voice models, not clones of real individuals	Licensed TTS voices only; no custom voice training; no user voice cloning capability
Misuse of agent voice output	Agent TTS output could be recorded by users and misrepresented as a real person’s voice	Demo disclaimer on every response (“This is a demonstration. Not medical advice.”); TTS voice is clearly synthetic
Deepfake generation from healthcare content	A voice-enabled health agent’s outputs could be used to generate convincing fake medical advice	Guardrails prevent clinical advice (dosing, diagnosis, prescription change); citation enforcement; refusal on out-of-scope

Anti-Deepfake Measures

1. No voice cloning capability: The system provides TTS output using licensed ElevenLabs voices. It does not train, fine-tune, or clone any voice. No user audio is stored or used for synthesis.

2. Transparent synthetic voice: TTS output is clearly synthetic. The disclosure modal informs users that agent responses are generated by AI and spoken by a synthetic voice.

3. Guardrails apply equally to voice: The same scope classifier, refusal templates, and escalation router that govern text interactions apply to voice. A voice request for dosing advice is refused just as a text request would be.

4. No audio persistence: Audio input is processed by STT and discarded. Audio output is generated per-response and not stored. No audio files are written to disk or persisted in any storage system.

Current State

The voice integration is opt-in and OFF by default. The consent framework described above is implemented; the design decisions governing voice are captured in the voice extension decision record.

Key design constraints that protect users:

• Voice is opt-in: The toggle defaults to OFF; users must explicitly enable voice
• Feature detection with graceful disable: If the browser does not support navigator.mediaDevices or MediaRecorder, voice controls are hidden; the text interface works without degradation
• Disclosure before permission: The disclosure modal appears before the browser microphone permission prompt, giving users information before they make a decision
• Audio NOT retained: This commitment is stated in multiple locations and is enforced by architecture: no audio file is written to any storage at any point in the pipeline
• 30-second recording limit: Prevents indefinite recording; enforced client-side
• Same guardrails as text: Voice input is transcribed to text and processed through the same six-node LangGraph pipeline with identical guardrails

The consent framework follows the principle that consent should be informed, specific, and freely given. The pre-permission disclosure modal ensures users understand what happens with their voice data before they grant microphone access.

Production Path

A production deployment with voice would need to strengthen the consent and deepfake framework:

1. Explicit voice consent flow: Formal consent capture with timestamp and versioned consent text; consent withdrawal mechanism; consent audit trail for regulatory compliance
2. Deepfake detection capability: If the system processes voice input in a context where impersonation is a risk, integrate voice authentication or deepfake detection to verify the speaker is not using synthesised audio
3. Voice biometric policy: If voice biometrics are ever collected (not planned), explicit consent under applicable biometric privacy laws (e.g., Illinois BIPA, GDPR Art. 9); biometric data retention and destruction policies
4. Audio retention and deletion procedures: If any audio is retained for quality assurance or debugging, define retention periods, deletion procedures, and access controls; provide users with the ability to request deletion
5. Cross-jurisdictional consent: Voice consent requirements vary by jurisdiction; production deployment would need jurisdiction-aware consent flows (e.g., GDPR requires explicit consent; some jurisdictions require recording notifications)
6. Accessibility: Ensure voice interaction is accessible to users with speech disabilities; provide text fallback at all times; do not make voice the only input method for any critical function
7. Children’s voice data: If the system could be used by minors, additional protections under COPPA (US), GDPR Art. 8 (EU), and Ley 19.628 (Chile) for children’s data

See Also

• Regulatory posture — regulatory boundary
• Model card — CHAI Applied Model Card
• Multilingual safety parity — multilingual safety
• HIPAA readiness assessment — HIPAA readiness
• Voice extension design — voice extension design