Teams building voice products for hospitals, public administrations, courts, or banks kick off with the same question before any discussion on accuracy or price: where does the audio go, who can access it, and what remains once processing is done?

For most Voice AI APIs, the answer is shared infrastructure operated by a provider in another jurisdiction, under that provider's data retention and training terms. For a growing share of use cases, that answer fails the security review.

This article explains why sovereignty in Voice AI has to cover both how models are built and how they are deployed. It then compares the deployment options available to regulated teams, defines what data residency and ownership mean for each option, and reviews the regulatory frameworks that rule out generic cloud APIs for sensitive audio. It also explains why a provider's training policy is a security question, not a commercial detail. For sector-specific analyses, see our articles on healthcare and the public sector.

Why voice data needs more protection than most data

A recording carries two kinds of personal data at once.

The first is the content: what was said. Depending on the context, that can include health information, financial details, statements made during a police interview, or information about third parties. Under the GDPR, several of these categories are special categories of personal data (Article 9) or data relating to criminal offences (Article 10). Processing them is prohibited by default and only allowed under narrow conditions.

The second is the signal: the voice itself. When voice characteristics are processed to identify a person, they become biometric data under Article 4(14) of the GDPR and fall under Article 9 as well. This is exactly what speaker identification does. A voiceprint is an embedding computed from speech, and its purpose is to recognise a speaker. In the United States, HIPAA lists voice prints among the biometric identifiers that make health information identifiable.

Three properties make audio harder to govern than most other data:

• It involves people who never signed anything. A recording of a call, a consultation, or a hearing captures every participant, not just the customer of the service.

• Derived data inherits the sensitivity of the source. Transcripts, speaker-attributed segments and voiceprints are often as sensitive as the recording itself, and they tend to be kept longer.

• It is produced continuously. A meeting assistant, a contact centre or an emergency call platform generates thousands of hours of audio, so any weakness in the pipeline applies at scale.

Sovereignty applies to development and to deployment

Sovereignty is often reduced to hosting location, but a Voice AI stack raises questions at two separate stages.

Development concerns the model itself. Who built it, and under which jurisdiction does that company operate? Can the model be inspected and benchmarked independently? Will customer data flow back into the training of future versions? A closed model from a provider whose terms allow training on customer data remains a dependency, even if it runs on your servers. You cannot verify what it does, and your data may already be part of the next release.

Deployment concerns inference. Where does processing run, who operates the infrastructure, which laws can compel access to it, and what persists after a job completes? A model developed in Europe but served from infrastructure controlled by a non-European provider inherits that provider's legal exposure at deployment.

A sovereign Voice AI stack needs satisfactory answers at both stages. Inspectable models trained without customer data address the first. The choice of deployment option addresses the second.

Where sovereignty becomes a requirement

Several sectors reach the same architectural conclusion for different regulatory reasons.

• Public administration: Council sessions, social services interviews, sessions with psychologists and administrative hearings produce records that are often legally binding and sometimes highly sensitive. In France, administrations increasingly require hosting on SecNumCloud-qualified infrastructure, a qualification issued by ANSSI that includes protection against non-European laws.

• Healthcare: Consultation recordings, ambient clinical documentation, and telehealth sessions combine health data and biometric data in a single file. National rules add requirements on top of the GDPR, such as HDS certification for health data hosting in France. In the United States, a provider processing protected health information must sign a Business Associate Agreement.

• Software vendors serving these sectors: A company building a meeting minutes tool for municipalities, or a transcription product for hospitals, inherits the constraints of its customers. Its Voice AI provider becomes a subprocessor that must pass the same review.

• Justice and law enforcement: Police interviews, court hearings, and emergency calls contain data relating to criminal proceedings. In the United States, criminal justice information is subject to the FBI's CJIS Security Policy, which constrains where and how that data can be processed.

• Financial services: MiFID II requires investment firms to record telephone conversations related to transactions. Since January 2025, DORA has required financial entities to manage the risk of their ICT third-party providers, including concentration risk and exit strategies.

Three deployment options for a Voice AI stack

Regulated teams generally choose between three architectures. They differ in where audio travels and in who operates the infrastructure.

Cloud API with European processing is the fastest route to production, and it suits products where external processing is acceptable under the right contractual terms. The points to verify are specific: where processing actually runs, which subprocessors are involved, how long each type of data is kept, and whether the provider trains on customer data. With the pyannoteAI API, for example, core services are hosted in the European Economic Area. Job processing can be restricted to the EEA in your processing region settings. By default, jobs can be processed in any region.

Self-hosting runs the models in a cloud environment you control, whether a private tenancy with a hyperscaler or a qualified sovereign cloud. Audio never reaches the model provider. The residency and jurisdiction of the data follow those of your hosting provider, which lets you choose a qualified environment when your rules require it.

On-premise deployment runs the models on your own hardware, inside your own security perimeter. It is the standard option for organisations whose audio must never leave their network. With pyannoteAI's on-premise package, the only data sent to pyannoteAI is technical metadata used to authenticate the deployment and bill usage: API key, package version, OS and architecture, job type, job identifier, and audio duration. Audio, transcripts, and speaker embeddings are never included.

What data residency and ownership mean at each level

Three notions are often used interchangeably, but a security review treats them separately.

Data residency is the physical location where data is stored and processed. Jurisdiction is the set of laws under which an authority can compel access to that data. Control is the technical and contractual ability to decide who can access the data, how long it is kept, and what it is used for.

The distinction between residency and jurisdiction matters most. Data processed in a European region of a provider headquartered outside the EU is resident in Europe, but it can remain within reach of foreign legal process. The US CLOUD Act, for instance, allows US authorities to require US providers to produce data they control, wherever it is stored. This is why SecNumCloud requires protection against non-European laws in addition to European hosting.

Applied to the three options:

• Cloud API: Residency depends on the regions the provider offers. Jurisdiction covers both the provider and its hosting subprocessors. Control is shared and defined by the Data Processing Agreement and the published retention policy. For the pyannoteAI API, the audio copy on the processing server is deleted immediately after a job completes. By default, uploaded files are deleted within 48 hours and job outputs within 24 hours, while streamed audio is never stored. The request payload and job metadata are kept for the duration of the agreement and 18 months after it ends, for billing, support, and fraud prevention. They never contain audio or job outputs, and voiceprints submitted in requests are redacted within 96 hours. The list of hosting subprocessors is published on the Trust Center.

• Self-hosting: Residency and jurisdiction follow the cloud provider you choose. Control over audio and outputs is entirely yours.

• On-premise: Residency, jurisdiction, and control are yours, within the limits of your own network.

Ownership of outputs is a separate question from infrastructure. With pyannoteAI, the intellectual property of transcripts, speech segments, and diarization results belongs to the customer under the terms of use, once the corresponding usage is paid for, whatever the deployment option.

Regulatory constraints that rule out generic cloud APIs

No single regulation forbids cloud APIs for voice data. Generic APIs become unworkable when several requirements apply to the same recordings at once.

• GDPR: Processing special categories or biometric data requires a specific legal basis under Article 9. Using a provider requires a processor agreement under Article 28, and any transfer outside the EEA must rely on the safeguards defined in Chapter V. Since the Schrems II judgment of 2020, transfers to the United States have depended on adequacy arrangements, currently the EU-US Data Privacy Framework, whose durability many data protection officers are reluctant to assume. A provider that processes audio outside the EEA by default, keeps it without a defined limit, or reuses it for training creates obligations that the data controller cannot easily meet.

• HIPAA: There is no official HIPAA certification. A provider handling protected health information must sign a Business Associate Agreement and apply the safeguards of the Security Rule. Many generic APIs do not offer a BAA, or reserve it for specific contracts, which rules them out for clinical audio in the United States.

• SOC 2 Type II: SOC 2 is not a regulation but an attestation standard defined by the AICPA. A Type II report certifies that an organisation's security controls operated effectively over a period, usually six to twelve months, whereas a Type I report only covers their design at a given date. In practice, it serves as a procurement requirement, and enterprise buyers ask for it before any contract.

• National and sectoral rules: HDS certification for health data in France, SecNumCloud for sensitive public data, CJIS for criminal justice information in the United States, and DORA for financial entities each add requirements on location, operator qualification, or supplier management.

For many organisations, the combined effect leads to a single practical conclusion: sensitive audio is processed inside a perimeter they control, and the provider supplies models, not infrastructure.

Why the provider's training policy is a security question

Some Voice AI providers use customer audio to train or improve their models by default. Others offer an opt-out, or exclude training only on higher pricing tiers. For a team building a product that processes other people's voices, this is a structural risk for four reasons.

• Training turns temporary processing into permanent retention: Once audio has contributed to a model's weights, it cannot be withdrawn in any practical sense. A data subject's right to erasure under Article 17 of the GDPR becomes very difficult to honour for data that has shaped a released model.

• Training is a new purpose: Under the purpose limitation principle (Article 5(1)(b)), data collected to transcribe a consultation or document a hearing cannot simply be reused to develop a vendor's product. Your end users consented, or were informed, for the first purpose only.

• Models can memorise training data: Research on neural networks has shown that models can retain and reveal elements of their training data. For voice, this concerns both what was said and the characteristics of the speakers.

• Opt-out defaults shift the burden to you: A protection that depends on a setting, a contract tier, or a request to support can be forgotten, misconfigured, or changed at renewal.

pyannoteAI's position is written into its terms of use: audio files and outputs generated by customers are not used to train, improve, or develop pyannoteAI models, unless the customer gives explicit consent. This applies to every plan, with no opt-out required. When a customer reports a quality issue, they can choose to share example audio for investigation, which pyannoteAI uses for validation and testing only with their consent. With self-hosting and on-premises deployments, the question does not arise, because pyannoteAI never receives the audio.

European origin as a matter of jurisdiction

pyannoteAI is a French company. Its models originate from pyannote.audio, the open-source speaker diarization toolkit developed through more than a decade of public research in France, and their development continues in Europe. For European organisations, this means the provider operates under the same legal order they do, with the GDPR as its home law and European courts and supervisory authorities as its authorities.

Jurisdiction also depends on who operates the infrastructure. For the cloud API, core services run on hyperscaler infrastructure in France. Teams that need to exclude any non-European operator can self-host the models in a qualified environment or deploy them on-premises.

The open-source foundation matters as much as the jurisdiction. The code is on GitHub, and the open models are on Hugging Face, so teams can inspect them, benchmark them on their own data, and run them without depending on the provider's infrastructure. Verification replaces trust in vendor assertions.

Questions to ask when evaluating a Voice AI stack

Before selecting a provider, teams responsible for sensitive audio can put these questions to every candidate and ask for written answers:

• In which regions is audio processed, at the level of named subprocessors, and can processing be restricted to the EEA?

• Can the models run entirely inside our infrastructure, and what exactly does the provider receive in that configuration?

• What is stored after processing, for how long, and what does the provider keep beyond that period?

• Is customer data excluded from training by default and by contract, without an opt-out?

• Does the provider treat voice as biometric data in its own data protection analysis?

• Which jurisdiction governs the provider and its hosting subprocessors?

• Which compliance documents are published, such as the DPA, the subprocessor list, audit reports and the status of certifications in progress, and can a security team access them without a sales call?

pyannoteAI publishes its answers in its data retention documentation, its terms of use, and its Trust Center, which lists current compliance status, subprocessors, and monitored security controls.

Frequently asked questions

What are the GDPR-compliant options for Voice AI?

There are three: a cloud API that processes audio in the EEA under a Data Processing Agreement with bounded retention, self-hosting in a cloud environment you choose, and on-premises deployment on your own servers. The right option depends on the sensitivity of the audio. For special categories or biometric data, many organisations choose self-hosting or on-premise deployment so that no transfer to a third-party processor is needed.

How can I run speaker intelligence on-premise?

You deploy the models in your own environment and call them from your application, as you would call an API. pyannoteAI offers self-hosted and on-premises deployment of its commercial models, including diarization, voiceprints, and speaker identification, on Enterprise plans. The open-source pyannote.audio toolkit can also run locally for research and prototyping.

How do I ensure the sovereignty of a Voice AI stack?

Check both stages. For development, choose inspectable models from a provider that does not train on customer data. For deployment, choose where inference runs and under which jurisdiction, and document what each component stores. Residency alone is not enough if the operator of the infrastructure is subject to non-European laws.

What are the European alternatives for Voice AI infrastructure?

Evaluate providers on the jurisdiction of the company, the location of processing, the availability of self-hosted deployment, and the openness of the models. pyannoteAI is a French company whose speaker intelligence models can be used through an API whose core services are hosted in the EEA, with job processing that can be restricted to the EEA, or deployed in your own infrastructure.

How do I process sensitive audio without sending it to the cloud?

Deploy the models on your own servers or in a private environment, and keep the audio source, the processing, and the storage of results inside that perimeter. With on-premises deployment, pyannoteAI receives only technical metadata to authenticate the deployment and bill usage, never audio or outputs.

Why does a sovereign Voice AI stack matter for enterprises, governments and regulated industries?

Because voice recordings combine sensitive content and biometric identifiers, often about people who are not your customers. Processing them through infrastructure you do not control creates legal exposure, transfer obligations, and dependencies that are difficult to reverse once a product is in production.