Quick answerIt is also a different question from when the agent should demand more proof before acting. That step-up authentication decision covers when to escalate the identity bar for a risky action; this post covers what happens once biometrics specifically are the mechanism chosen to clear that bar, since the storage and consent obligations kick in the moment you capture the biometric sample, regardless of how often you actually use it to step someone up. It is narrower still than the general safety-review question of what changes once an agent starts accepting voice or image input at all, which covers moderation and prompt-injection risk in uploaded media, not the specific storage regime for a biometric identifier extracted from that media.
Quick answer
Biometric identifiers, a voiceprint, a facial scan, a fingerprint, are treated as a heightened category of personal data under most privacy regimes, so storage, consent, and retention rules are stricter and enforced more aggressively than general PII handling. Get explicit, separate, written consent before capturing any biometric identifier, since a bundled general terms-of-service checkbox is not sufficient under BIPA or GDPR, store only a derived mathematical template rather than the raw voice or image sample, set a defined retention and deletion schedule tied to the authentication relationship rather than indefinite storage, and never reuse a biometric template captured for authentication for any secondary purpose like personalization without separate consent for that specific use.
What separate consent actually requires
A biometric consent notice bundled into a general terms-of-service acceptance does not meet the bar in BIPA-style statutes or under GDPR's special-category rules. The consent needs to specifically name the biometric identifier being collected, state the purpose as authentication and nothing broader unless separately consented, state the retention period, and be captured as an affirmative, separate action, not a pre-checked box or an implied opt-in from continuing to use the product. Build the consent capture as its own discrete step in the enrollment flow, logged with a timestamp and the exact notice text shown, since the burden of proving valid consent falls on the company if it's ever challenged.
Store a template, not the raw sample
Never store the raw voice recording or facial image as the biometric credential; convert it into a mathematical template, a vector representation, at capture time and store only that, ideally with the raw sample discarded immediately after template generation unless you have an independent, separately consented reason to retain it. A support-quality recording program, for example, needs its own consent and retention rule and should not piggyback on the authentication capture. A template is generally harder to reverse-engineer into the original biometric and is treated more favorably in several jurisdictions' breach-notification thresholds, though it is still biometric data and still covered by the same consent and retention rules.
Set a real deletion trigger, not an indefinite hold
Tie the biometric template's retention explicitly to the relationship that justified collecting it: delete it when the customer closes the account, when the authentication method is no longer offered, or on a fixed schedule if the account goes dormant, whichever comes first, and make deletion an automated, auditable process rather than a manual cleanup task someone has to remember to run. Several state statutes set an explicit maximum retention window, three years of inactivity under BIPA, for example; know your applicable jurisdiction's number rather than picking an arbitrary internal default.
FAQ
Does voice used only for a phone call, not authentication, count as biometric data? It depends on whether you extract and store a voiceprint, a biometric identifier, versus simply processing the audio for transcription and discarding it. Processing audio without deriving and retaining an identifying voiceprint template generally falls outside biometric-specific statutes, but confirm this against your specific jurisdiction's definition rather than assuming.
Can we use the same biometric template to both authenticate a customer and personalize their experience? Not without separate consent for the personalization use. Bundling a second purpose into a credential captured for authentication is exactly the kind of scope creep BIPA-style statutes and GDPR's purpose-limitation principle are designed to catch.
What happens to biometric templates if we switch vendors for the authentication feature? Treat it as a data migration requiring the same consent scrutiny as the original capture: confirm the new vendor's storage and retention practices meet the same bar, and don't assume the original consent covers processing by a different third party unless your notice specifically anticipated that.