Voice AI Compliance: What Should You Look For in a Vendor

Summary

Voice AI compliance is not one checklist. It follows the technical path a call takes through a system: where audio is processed, what is retained, whether voice is used to identify someone, which communications rules apply, and what has to be disclosed.
Different laws answer different parts of that path. The same deployment can fall under several frameworks at once, depending on the caller, the business, the vendors involved and what the system is actually doing.
A vendor saying it is “compliant” does not tell you enough. The useful questions are which obligations its architecture supports, in which jurisdictions, and what evidence it can provide.
This guide covers the cross-cutting issues that apply to many voice AI deployments. Outbound calling, healthcare, financial services and other regulated use cases can introduce additional requirements.
The seven questions below give legal, procurement and engineering teams a practical way to evaluate a voice AI vendor before deployment.

Voice AI compliance is not one checklist. It depends on where call audio is processed, what happens to it after the call, whether the voice is being used to identify someone, which recording or communications rules apply, and whether the interaction triggers AI-specific transparency requirements.

Those obligations can change with the caller’s location, the business’s location, the vendors and subprocessors involved, and what the system is actually doing with the audio.

So the useful question when evaluating a voice AI vendor is not simply: ”Are you compliant?” It is: Which compliance obligations does your architecture support, in which jurisdictions, and what can you show us to prove it?

There are seven questions worth working through.

QuestionWhat you are trying to establish1. Where is audio processed?Which entities and jurisdictions handle the call while it is live2. What is retained afterward?Whether audio, transcripts or both are stored, and for how long3. Is voice used to identify someone?Whether biometric rules are triggered4. What recording or interception rules apply?Whether the call needs notice, consent or another legal basis5. What AI disclosure or marking rules apply?Whether callers must be told they are interacting with AI and whether synthetic content needs technical marking6. Does the use case trigger additional rules?Whether outbound calling, marketing or a regulated industry adds another layer7. Who owns each obligation?What sits with the vendor, what sits with the business, and what evidence exists

1. Where is the audio actually processed?

Every voice AI system has to process audio somewhere before a response comes back. That might happen through a general-purpose cloud API, inside infrastructure operated by the carrier or enterprise, at the network edge, or through a combination of those depending on the call.

The important distinction is between where data is eventually stored and where it is processed while the call is happening. A system can store transcripts in one jurisdiction while routing live audio through infrastructure in another.

For GDPR purposes, the question is also more specific than simply asking where the server is. If personal data is transferred or made available to a separate controller or processor in a third country, Chapter V of the GDPR may apply.

An adequacy decision is one way to support a transfer, but it is not the only one. Appropriate safeguards can also include mechanisms such as Standard Contractual Clauses or Binding Corporate Rules where the relevant conditions are met.

That makes the vendor question: Who processes or can access the call audio, through which legal entity, from which jurisdiction, and under which transfer mechanism?

Egypt shows why the answer cannot simply be copied from a GDPR deployment. Under Egypt’s Personal Data Protection Law No. 151 of 2020, voice can fall within the definition of personal data. The law and its Executive Regulations No. 816 of 2025 also establish a licensing and permit framework around personal-data processing and cross-border transfers. The Egyptian Personal Data Protection Center now administers that framework.

The underlying issue is similar, controlling how personal data moves across borders, but the legal mechanism is different. When evaluating a vendor, ask:

Where is live audio physically processed?
Which company or legal entity processes it?
Which subprocessors can access it?
Where does failover traffic go if the primary region is unavailable?
Is the processing region configurable per deployment?
What transfer mechanism applies if data crosses borders?
Can the vendor provide the actual data-flow architecture, rather than only a privacy policy?

A statement such as “your data is stored in Europe” does not answer all of those questions.

2. What happens to the audio afterward?

Once a call ends, a voice AI system can retain one, both or neither of two things: the raw audio recording and a text transcript derived from it. Those are not operationally equivalent.

A transcript contains the words that were spoken. It can generally be searched, redacted and managed through text-based retention controls.

Raw audio contains more. It preserves the speaker’s voice, tone, timing, background sounds and other acoustic information that does not survive in a transcript. Depending on what later processing is applied, the audio may also contain the signal needed to derive biometric characteristics.

That does not mean every audio recording is automatically biometric data. It means the retention decision matters because the original signal can support uses that a transcript cannot.

The practical questions are straightforward:

Is raw audio retained by default?
Is the transcript retained?
How long is each retained?
Can the customer set different retention periods?
Can retention be disabled?
What happens to backups and replicated copies?
How quickly is deleted data actually removed?
Is customer data used to improve or train models?
Do the same retention rules apply to every subprocessor in the call path?

“Zero retention” is useful only if you know which data it applies to and at which layer of the system.

3. Is the voice being used to identify someone?

This is where voice data can become a biometric issue. A person’s voice is not automatically special-category biometric data simply because a system receives or transcribes it.

Under GDPR, biometric data involves specific technical processing of physical, physiological or behavioural characteristics that allows or confirms unique identification. Article 9 then applies additional protection where biometric data is processed for the purpose of uniquely identifying a person.

The distinction is important. A system that converts speech into text to understand what someone is saying is not doing the same thing as a system that creates a voice template and compares it with an enrolled profile to confirm who is speaking.

Voice authentication is the obvious example. If a bank asks a caller to speak and then compares characteristics of that voice with a stored profile before granting access to an account, it is using biometric recognition.

In that situation, GDPR generally requires both an Article 6 lawful basis for the processing and a valid Article 9 condition for the special-category biometric data. Explicit consent is one possible Article 9 condition, but it is not the only one provided by the Regulation.

Illinois takes a different approach through its Biometric Information Privacy Act, or BIPA. BIPA explicitly includes a voiceprint within its definition of a biometric identifier.

Before collecting biometric identifiers or biometric information, a private entity must provide specified written information and obtain a written release. The Act also requires a publicly available retention and destruction policy.

BIPA is unusual because it gives affected individuals a private right of action. The Act provides liquidated damages of $1,000 for negligent violations and $5,000 for intentional or reckless violations, or actual damages where greater.

A 2024 amendment also clarified that repeated collection of the same biometric information from the same person using the same method is treated as a single violation for recovery under the relevant provision.

So ask the vendor a very specific question: Does any part of your system create, extract or compare a voice representation for the purpose of identifying or verifying the caller? If the answer is yes, the compliance analysis changes.

4. What recording, interception or communications rules apply?

AI-specific disclosure is only one part of the call. Existing communications and recording laws still apply independently.

In the United States, federal law generally permits interception where one party to the communication has given prior consent, subject to the statute’s conditions and exceptions. State laws can impose stricter requirements.

A minority of states primarily require all parties to consent, while others have different rules depending on whether the communication is a telephone call, an in-person conversation, or another type of interaction. That creates a practical problem for national deployments.

A business may be operating from a one-party-consent state while speaking to a caller located in a state with stricter rules. The system does not become compliant simply because the business’s headquarters are in the easier jurisdiction.

It is also worth separating recording, interception and transcription. They can overlap technically, but they are not interchangeable legal concepts.

A system performing live transcription should not automatically be treated as if every recording statute applies in exactly the same way. The relevant analysis depends on what the system captures, how it captures it and which jurisdiction applies.

Europe has its own communications-privacy layer. The ePrivacy Directive requires Member States to protect the confidentiality of communications and restrict unauthorised listening, tapping, storage or other interception or surveillance. It also recognises legally authorised recording in the course of lawful business practice in specified circumstances.

So the deployment question is broader than: ”Do we have a recording disclaimer?” It is: What does the system technically do to the communication, where are the parties located, and which communications law applies to that specific call?

5. What has to be disclosed, and how?

This is where the EU AI Act adds another layer. Article 50 has several transparency obligations, and they should not be collapsed into one generic requirement to “label AI”.

Interaction Disclosure

For systems designed to interact directly with natural persons, Article 50(1) requires providers to design and develop the system so that the person is informed that they are interacting with AI, unless that fact is obvious in the circumstances. The Commission’s current guidance says the information should be provided from the start of the first interaction, clearly and distinguishably.

For a voice AI call, that means a clear spoken disclosure at the beginning of the interaction can address the human-facing interaction requirement where it applies.

Synthetic Content Marking

But Article 50(2) is a different obligation. Providers of AI systems generating synthetic audio, image, video or text must, where Article 50(2) applies, ensure that the output is marked in a machine-readable format and detectable as artificially generated or manipulated.

The law does not prescribe one specific metadata format. The technical solution is expected to be effective, interoperable, robust and reliable as far as technically feasible, taking account of the content type, implementation cost and state of the art.

So a spoken disclosure and a machine-readable mark solve different problems. A caller hearing: ”You’re speaking with an AI assistant” does not automatically satisfy a separate machine-readable marking obligation if that obligation applies to the generated audio.

Exceptions and Nuances

There is also an important exception. Article 50(2) does not apply where the AI system performs an assistive function for standard editing or does not substantially alter the input or its semantics.

The Commission’s final July 2026 guidance treats AI-generated translation and transcription among the examples that can fall within that standard-editing or non-substantial-alteration exception. But that does not mean every form of voice translation is automatically exempt.

The same guidance separately identifies synthesis of realistic speech in a specific person’s voice as an example on the marking side of the line. That distinction matters for real-time speech-to-speech systems.

A straightforward translation that preserves the underlying content may fall within the editing exception. A system that additionally recreates or synthesises the speech in a specific person’s voice can raise a different Article 50(2) question. The implementation has to be assessed based on what the system is actually generating, not simply because the product is described as “translation”.

Timing

There is one narrow timing exception as well. Article 50 applies from 2 August 2026. AI systems placed on the market before that date have until 2 December 2026 to comply with the Article 50(2) marking and detection obligation. That grace period does not generally postpone the other Article 50 transparency duties.

The vendor questions here should be:

When is the caller told that AI is involved?
Who is legally the provider and who is the deployer for this system?
Does Article 50(2) apply to the audio this implementation generates?
If marking applies, what technical method is used?
Is the mark still detectable after encoding, transcoding and carrier transport?
What detection method is available?
If the vendor relies on an Article 50 exception, what is the basis for that classification?
If the system predates 2 August 2026, what is the plan for the 2 December 2026 deadline?

6. Does the use case trigger another set of rules?

The layers above are cross-cutting. They can apply to many voice AI systems. They are not the whole regulatory picture. The purpose of the call can add another set of obligations.

Outbound calling in the United States is a good example. In 2024, the Federal Communications Commission confirmed that AI-generated voices fall within the Telephone Consumer Protection Act’s treatment of artificial or prerecorded voices.

That means an outbound call does not escape the TCPA simply because the voice was generated dynamically rather than played from a conventional recording. Consent requirements then depend on the type of call and destination.

For calls that include advertising or constitute telemarketing, FCC rules impose stricter consent requirements, and the FTC’s Telemarketing Sales Rule separately regulates prerecorded telemarketing messages, including written agreement and opt-out requirements in covered circumstances.

So an inbound customer-service deployment and an outbound AI sales campaign should not be treated as the same compliance problem. Healthcare, financial services, insurance, debt collection and other regulated sectors can add their own requirements as well.

This is why a useful compliance review starts with the architecture, but cannot end there. The final question has to be: What is this system actually being used to do?

7. Who owns each obligation, and what can the vendor prove?

This may be the most important question in the entire evaluation. Compliance responsibility does not always sit entirely with the vendor or entirely with the business using the system.

Under the EU AI Act, Article 50 places different obligations on providers and deployers depending on the activity. Under GDPR, obligations can change depending on whether an organisation is acting as a controller or processor.

Those roles are legal roles, not marketing labels. They depend on what each party is actually doing with the system and the data. That means a procurement conversation should not stop at a list of certifications.

Ask for evidence. For each relevant layer, request:

a current data-flow diagram;
the list of subprocessors involved in the call path;
processing and storage regions;
the applicable Data Processing Agreement;
the mechanism used for any international transfers;
retention and deletion controls;
the policy for using customer audio or transcripts for model training;
documentation of any biometric processing;
the implementation used for AI disclosure;
the technical implementation used for Article 50 marking, where applicable;
the vendor’s provider/deployer responsibility mapping;
incident-response and breach-notification procedures;
and the contractual allocation of each relevant obligation.

A compliance badge can be useful evidence of a particular control environment. It is not a substitute for understanding how the call actually moves through the system.

How the major frameworks compare

The same voice AI deployment can fall under several legal frameworks at once. Each one addresses a different part of the system or call.

EU AI Act, Article 50

Applies in: European Union
Covers: AI interaction disclosure and machine-readable marking of certain synthetic content.
What to check: Whether the system interacts directly with people, whether the generated audio falls within the marking requirement, whether an exception applies, and whether the relevant obligation sits with the provider or deployer.

Applies in: EU/EEA and certain processing outside the region where the GDPR’s territorial scope applies.
Covers: Personal data processing, international transfers and special-category biometric data.
What to check: The roles of each organisation involved, the lawful basis for processing, whether an Article 9 condition is required for biometric use, how long data is retained, and which mechanism covers any international transfer.

Illinois BIPA

Applies in: Illinois, United States
Covers: Biometric identifiers and biometric information, including voiceprints.
What to check: Whether the system creates or uses a voiceprint, whether the required written notice and release are in place, how biometric information is retained and destroyed, and whether it is disclosed to third parties.

US federal and state recording laws

Applies in: United States
Covers: Recording and interception of communications.
What to check: Where each party to the call is located, what the system is technically capturing, whether it is recording, intercepting or transcribing the communication, and which consent requirements apply.

TCPA and telemarketing rules

Applies in: United States
Covers: Certain outbound calls using artificial or prerecorded voices, including AI-generated voices.
What to check: The purpose of the call, who is being called, what form of consent is required, and whether identification, disclosure or opt-out requirements apply.

Egypt Personal Data Protection Law and Executive Regulations

Applies in: Egypt and other processing falling within the law’s scope.
Covers: Electronic personal data, including voice, sensitive data and cross-border transfers.
What to check: The role of each party processing the data, where the audio is processed or stored, whether licences or permits are required, and what conditions apply if personal data is transferred outside Egypt.

The important point is that these frameworks do not replace one another. A single call can be subject to several of them at the same time. That is why vendor evaluation needs to start with the technical path of the call, then map the relevant legal requirements onto each part of that path.

Where SentiVue fits

SentiVue addresses several of these questions at the infrastructure level. Audio processing and transcript handling can be kept inside a defined data zone, with retention controlled at the architecture layer rather than left only to a general privacy policy.

Disclosure and marking controls can also be handled at the network layer, rather than being tied to one isolated AI session. That matters when a call changes state.

Because translation is attached to the call rather than to a single AI persona or session, the same call-level handling can continue when a caller is transferred to another participant or handed off to a human agent.

The purpose of that architecture is not to claim that one platform makes every deployment compliant. The applicable requirements still depend on the jurisdiction, the use case, the customer’s role and what the system is configured to do.

The aim is to make the controls that a compliant deployment may require possible at the infrastructure layer. If you’re evaluating voice AI for a multi-jurisdiction or regulated deployment, send SentiVue a message or schedule a 30-minute call.

FAQ: Frequently Asked Questions

What are the main areas of voice AI compliance?

There is no single universal list, but seven questions cover the main cross-cutting issues for vendor evaluation:

Where is audio processed?
What is retained?
Is voice used for biometric identification?
What recording or communications rules apply?
What AI disclosure or marking rules apply?
Does the use case trigger additional regulation?
Who owns each obligation, and what evidence exists?

Additional sector-specific requirements can apply depending on the deployment.

Is voice data always considered biometric data?

No. A voice recording can be personal data without being special-category biometric data.

Under GDPR, biometric data involves specific technical processing of physical, physiological or behavioural characteristics that allows or confirms unique identification. Additional Article 9 protection applies where biometric data is processed for the purpose of uniquely identifying someone.

A system that transcribes speech content is therefore not automatically equivalent to a system that creates and compares voice templates for authentication.

Does the EU AI Act require voice AI systems to tell callers they are speaking with AI?

Article 50(1) requires providers of AI systems designed to interact directly with natural persons to ensure that those people are informed that they are interacting with AI, unless that fact is obvious in the circumstances. The Commission’s guidance says the information should be provided from the start of the first interaction in a clear and distinguishable way.

Does Article 50 always require machine-readable marking for AI voice translation?

No. Article 50(2) contains exceptions where the system performs standard editing or does not substantially alter the input or its semantics.

The Commission’s final guidance treats translation and transcription as examples that can fall within that exception. But it separately identifies realistic speech synthesis in a specific person’s voice as an example that requires marking. A real-time speech-to-speech implementation therefore needs to be assessed based on exactly what happens to the audio.

Is telling a caller that AI is being used enough to satisfy Article 50?

Not necessarily. The interaction disclosure under Article 50(1) and the machine-readable marking obligation under Article 50(2) are separate requirements. Where both apply, a spoken notice can address the human-facing disclosure, but it does not replace the technical marking requirement.

Do call recording laws still apply if the system discloses that it uses AI?

Yes. AI transparency and communications privacy are separate legal questions. A deployment can satisfy an AI disclosure obligation and still have additional requirements relating to recording, interception, storage or consent under the law governing the communication.

How does data residency work for voice AI outside the EU?

It depends on the jurisdiction. GDPR uses a framework that includes adequacy decisions and appropriate safeguards such as Standard Contractual Clauses. Egypt uses a different structure under Law No. 151 of 2020 and its 2025 Executive Regulations, including licensing and permit requirements administered by the Personal Data Protection Center.

The important vendor question is therefore not simply “Do you support data residency?” It is: Where is the audio processed, who can access it, and which legal mechanism covers that processing or transfer?

Can a voice AI vendor guarantee that a deployment is fully compliant?

Not in the abstract. Compliance depends on the jurisdiction, the purpose of the call, the system configuration, what data is processed, the roles of the organisations involved and the obligations that apply to that specific deployment.

A vendor can provide technical and organisational controls that support compliance. The deployment still has to be mapped against the laws that apply to the business and the call.

This article provides general information and is not legal advice. Voice AI requirements vary by jurisdiction, industry and deployment. Organisations should obtain legal advice for their specific use case.