Voice AI Privacy: Design Microphone Controls and Data Handling

Make capture a deliberate action

A voice interface should tell the user when the microphone is active and give them a visible way to stop it. Ask for browser permission when they start the feature, not as a surprise on page load. Explain what the audio is used for in language the user can understand.

Permission to access a microphone is a browser control. It doesn't by itself answer every question about recording, retention, or the user's consent under applicable rules. Work out those requirements for the actual product and jurisdiction.

Show separate states

A mute control, a paused interface, and an ended session can have different effects. The UI should explain which state applies. The provider's voice cost documentation notes that muting microphone input does not close a GPT-Live session.

If a user expects the microphone to stop, release the browser media tracks. Follow the API's graceful close sequence before closing the session when final events and usage are required.

Stop local media tracks

This browser-only example releases tracks obtained from an existing MediaStream. It doesn't stop server-side recording, close an API session, or delete previously stored material.

function stopMicrophone(stream: MediaStream): void {
  for (const track of stream.getTracks()) {
    track.stop();
  }
}

Decide what persists

List every copy: raw audio, transcripts, summaries, tool inputs, error logs, and analytics. For each, name an owner, access rule, retention period, and deletion process. Minimize the information recorded in logs; a debugging statement can outlive the call it describes.

Review provider data-control documentation for the exact endpoint, settings, and account policies you use. Don't assume one retention statement applies identically to every audio workflow.

Give the user an escape route

Provide a text alternative where your service can reasonably support one. Tell the user how to reach a person when the voice system can't help, and show a clear error if microphone permission is denied.

If generated speech is used, check the current provider requirements for disclosure and make sure the experience doesn't imply that a synthetic voice is a person.

Test the end of the session

• Deny microphone permission and confirm the interface remains usable.
• Stop a session and check the device's microphone indicator.
• Close the page during a call and verify cleanup and timeout behavior.
• Confirm that an authorized user can find and delete retained material according to policy.
• Inspect logs with synthetic data to check that sensitive speech isn't unnecessarily copied.

Map the data before choosing a retention period

Draw a path from the microphone to each destination. For example: browser audio, a voice session, an optional transcript, an application summary, and the logs used for support. Mark which components can read each item and whether a copy is stored. The map may reveal that a transcript is being retained even though the product only needs a temporary caption.

For every stored item, document why it exists and who can delete it. Configure retention according to the provider's current controls and your application's policy; verify deletion separately for your own database, storage, and any service that holds a copy. Avoid promising immediate deletion unless your entire path supports it.

Use a synthetic phrase when testing logs. Search the test environment for that phrase after a session ends. If it appears in places that don't need transcript content, adjust the logging and repeat the test.

Make the controls match their labels

A useful test is to put the interface in front of someone who hasn't seen the implementation. Ask them whether they believe audio is being captured after pressing Mute, Stop, or closing the page. Compare their expectations with the actual browser indicator, session state, and backend behavior.

The local stopMicrophone helper only stops tracks in that browser. If a recording process, API session, or another device is still active, stopping the local track doesn't stop those components. Implement and test each cleanup path explicitly, including unexpected network loss.

Keep explanations specific: tell users when the microphone is active, whether recording is occurring, and where they can find your data policy. Obtain advice appropriate to the jurisdiction and product before describing a particular consent mechanism as sufficient.

Include shared devices and browser permission changes in your test plan. A user can revoke microphone access or close a tab while your UI is still waiting for an event. Check that the interface and backend eventually leave their active states, and that a later session doesn't expose the earlier user's transcript. The test should describe the observable result and the cleanup behavior, without claiming that a browser control deletes data stored elsewhere.