Most teams building on speech-to-text APIs obsess over word error rate while glossing over the compliance risks buried in their transcription vendor's terms of service. The legal and regulatory exposure from a misconfigured audio pipeline can dwarf the cost of a few missed words in a transcript, and most teams don't discover the gap until an enterprise security audit flags it.
This guide walks through every layer of the compliance stack for AI call transcription: consent law across the EU, UK, and US, GDPR and UK GDPR, CCPA, PCI DSS scope, and a vendor due diligence checklist you can use before signing any infrastructure contract.
Unpacking AI transcription compliance risks
"Secure call transcription" covers more than encrypted storage. It covers the entire lifecycle of audio data: consent at capture, PII handling during processing, data residency during storage, and deletion once the business purpose is met. When your audio leaves your infrastructure and travels to a third-party API, you inherit that vendor's data governance posture: their sub-processors, their training data policies, and their deletion schedules.
For low-stakes internal notes, you can manage the risk. For support calls that contain payment data, health information, or legally sensitive disclosures, the risk compounds at every seam in your pipeline.
Handling PII and PCI DSS compliance
PII in a support call context includes names, email addresses, phone numbers, dates of birth, and account identifiers. PCI-scoped data means cardholder data: primary account numbers (PAN), CVV codes, and expiration dates. The distinction matters, different frameworks govern each category with different penalty structures.
AI transcription models don't inherently know what to protect. Large-scale ASR models produce verbatim text output. If a customer reads their credit card number aloud, that number appears in the transcript as plaintext unless you explicitly configure redaction. The model has no default behavior that shields cardholder data from appearing in your logs, CRM, or downstream analytics pipeline.
Vendor evaluation must go beyond accuracy benchmarks. The questions that matter for a regulated environment: what certifications does the vendor hold, where is audio processed and stored, and does the vendor retrain its production models on your calls?
Recording consent laws across the EU, UK, and US
Consent is the first compliance layer, and it is jurisdictional. The rule that applies depends on where your caller is, not where your company is incorporated. For an EU-headquartered operation, or any platform serving European customers, that means starting with EU and UK law, not US state law.
EU: e-Privacy Directive and GDPR Article 6
In the EU, recording a call triggers two separate obligations. The e-Privacy Directive (2002/58/EC) protects the confidentiality of electronic communications and generally requires the consent of the parties before a call is recorded or intercepted, with each member state implementing the rule through national law.
Separately, the recording itself processes personal data, so it needs a valid legal basis under GDPR Article 6, consent, legitimate interest, or contractual necessity, before the audio stream even reaches your transcription API. This is the layer US-centric guides miss: in the EU the legal-basis question attaches to the act of recording, not just to transcript storage.
National implementations vary, and some are strict. In Germany, recording the confidential spoken word without consent is a criminal offense under section 201 of the Criminal Code (StGB). The safe default for any multi-country operation is all-party consent plus a documented GDPR legal basis. Confirm national requirements with local counsel before going live in a new market.
UK: UK GDPR and ICO guidance
Post-Brexit, the UK runs its own regime: UK GDPR alongside the Data Protection Act 2018, enforced by the ICO, with call handling also touching the Privacy and Electronic Communications Regulations (PECR). Businesses need a lawful basis and must inform callers that recording is happening and why. Personal recording for one's own use is treated more leniently, but business use requires notice. Transfers of UK data to the US require a UK-specific mechanism such as the International Data Transfer Agreement (IDTA) or the UK Addendum to the SCCs, separate from the EU mechanisms.
US: one-party vs. all-party consent states
US federal law under 18 U.S.C. § 2511 permits recording with the consent of at least one party to the conversation. That one-party standard applies in 36 states plus DC. Thirteen states impose a stricter all-party consent requirement, meaning every participant must be informed and consent before recording begins: California, Connecticut, Delaware, Florida, Illinois, Maryland, Massachusetts, Michigan, Montana, New Hampshire, Oregon, Pennsylvania, and Washington, according to Justia's 50-state survey.
California Penal Code § 632 and Florida Statute § 934.03 make recording without all-party consent a criminal offense, not just a civil one.
| Consent requirement |
States |
Key risk |
| One-party consent |
36 states + DC |
Disclosure recommended as best practice |
| All-party consent |
CA, CT, DE, FL, IL, MD, MA, MI, MT, NH, OR, PA, WA |
Criminal penalties apply in California and Florida |
A universal disclosure removes cross-border exposure
The practical implementation is a pre-call disclosure played before transcription begins: "This call may be recorded for quality assurance and training purposes." Build it into your IVR or contact center routing layer, before the audio stream reaches your transcription API, and it satisfies the strictest all-party standard as long as the caller continues after hearing it. When callers can be in different countries or states, default to the strictest applicable law. A single universal disclosure removes cross-border and cross-state exposure in one step, though for EU calls it does not replace the separate GDPR Article 6 legal-basis requirement.
Securing transcripts: GDPR and CCPA compliance
Recording consent governs capture. GDPR, UK GDPR, and CCPA govern what happens to the transcript after it's created. Under GDPR Article 6, processing personal data from call transcripts requires a valid legal basis: legitimate interest, contractual necessity, or explicit consent. Call transcripts from EU residents are generally treated as personal data under GDPR compliance frameworks.
GDPR's data minimization framework breaks down into three obligations that directly apply to transcript storage:
- Purpose limitation: Process transcript data only for the documented reason you collected it (agent coaching, QA review, CRM sync), not for secondary purposes like model training.
- Data minimization: Retain only the fields necessary for your stated purpose. Storing raw full-text transcripts indefinitely when you only need action items is inconsistent with this principle.
- Storage limitation: Set a deletion schedule tied to your business purpose. Transcripts you retain "just in case" don't satisfy this principle.
Cross-border data transfer requirements
Under GDPR, sending EU resident audio or transcripts to US-based servers without a valid transfer mechanism violates the regulation. Common transfer mechanisms include Standard Contractual Clauses (SCCs) and adequacy decisions. Verify that your infrastructure vendor has a signed Data Processing Agreement covering GDPR Article 28 obligations and specifies where they process and store data.
Data residency options eliminate the cross-border transfer question entirely. When a vendor processes EU data exclusively in EU-region infrastructure, you don't need to navigate transfer mechanisms for the transcription layer. For UK data, the equivalent mechanism is the IDTA or the UK Addendum to the SCCs.
CCPA consumer rights for California residents
Under CCPA, California residents can request to know what personal data you collected in their calls, request deletion, and opt out of data sales. For contact center platforms serving California users, you should build transcript deletion workflows that can respond to individual requests within the statutory timeframe, with confirmation to the requestor.
How to handle PCI and PII in support transcripts
When a customer reads a credit card number aloud during a support call, that number falls in scope for PCI DSS the moment it appears in a transcript. The PCI Data Security Standard defines cardholder data as primary account numbers, cardholder names, expiration dates, and service codes. Sensitive authentication data, including CVV codes, must never be stored after authorization, even if encrypted.
Unintended PII disclosure in AI transcripts
Beyond PCI, AI transcripts create a new category of discoverable evidence. Legal guidance on AI meeting tools suggests that transcripts, summaries, and keyword indexes are electronically stored information (ESI) that courts may subpoena in litigation. Ephemeral dialogue in a support call becomes permanent, indexed, and searchable once you transcribe it. If attorney-client privilege applies to any portion of a conversation, you can waive that protection when you share the transcript across non-privileged systems.
PCI DSS scope when transcribing calls
Under PCI DSS, any system that stores, processes, or transmits cardholder data falls within your cardholder data environment (CDE). If your transcription pipeline captures and stores raw call text that includes PANs or CVV codes, you bring every system that touches those transcripts into CDE scope: your transcription vendor, your CRM, your QA tooling, and any analytics layer that reads transcript data.
Expanding your CDE scope increases your PCI audit surface and your remediation costs. Redact payment data before you write the transcript to any persistent store to keep CDE scope contained.
Technical redaction for PII and PCI
Technical redaction of PII and PCI data relies on named entity recognition (NER) models that scan transcript text and classify tokens into categories like names, credit card numbers, phone numbers, email addresses, and account identifiers. Once classified, the system replaces sensitive tokens with placeholder labels (e.g., [NAME], [CREDIT_CARD_NUMBER], [PHONE_NUMBER]) before writing the transcript to storage. Most redaction systems support configurable entity categories, allowing you to redact only the data types that fall within your compliance scope. The architectural decision is where redaction fires: pre-storage redaction (at the API response layer) prevents sensitive data from ever reaching your CRM or analytics pipeline, while post-processing redaction requires you to secure the unredacted transcript until redaction completes, expanding your compliance surface.
You must explicitly enable our optional PII redaction feature in the API request. When you enable it, we identify and replace entity categories, including credit card numbers, names, phone numbers, and email addresses, before returning the transcript. Configure PII redaction via the redaction parameter set in the API request body, documented in full in our PII redaction documentation.
We offer this feature in the transcription API. Because you must explicitly configure it, treat its absence as a deliberate decision, not a safe default.
Evaluating real-time vs. post-call redaction
Async transcription can offer advantages for PII redaction. Batch processing lets the model analyze the complete conversation before making entity classification decisions, which can improve accuracy for multi-turn disclosures where the full conversational record is available. For CCaaS platforms where PCI or HIPAA compliance is a hard requirement, async post-call processing with configured redaction is the more reliable architecture.
Vendor due diligence checklist for AI transcription
Certifications tell you a vendor passed an audit. The DPA tells you what you're actually agreeing to. Both are required. The checklist below covers the minimum viable evaluation for a regulated contact center environment:
- SOC 2 Type II certification (continuous monitoring over 6-12 months, not a point-in-time Type I)
- ISO 27001 certification (information security management system)
- Explicit data training policy by pricing tier (not a blanket statement)
- Data residency options with region-specific infrastructure (not just "we have EU customers")
- PII redaction capability configurable by entity category
- Sub-processor list available on request or in the DPA
- Data Processing Agreement covering GDPR Article 28
- Automated deletion API or webhook support
- Encryption in transit (TLS) and at rest
- Public status page and documented incident history
SOC 2 Type II covers a vendor's security controls over a sustained period of six to twelve months and results in a formal attestation from an independent auditor. Type II verifies controls operated effectively over time, not just that they existed at a single point, which is what Type I confirms. ISO 27001 covers the full information security management system and is a certification rather than an attestation, meaning an accredited body verified the system meets the standard.
Data residency and regional hosting options
Data residency means processing and storing data within a defined geographic boundary, enforced at the infrastructure level through region-specific compute, storage, and network resources. It differs from contractual data-location commitments, which sub-processors can override if the vendor's infrastructure routes data through global endpoints or shared storage layers. GDPR provides two mechanisms for lawful cross-border transfers: Standard Contractual Clauses (SCCs), which impose contractual obligations on the data importer, and adequacy decisions, which recognize a jurisdiction as offering equivalent protection. When a vendor processes EU data exclusively within EU-region infrastructure, cross-border transfer mechanisms become unnecessary for the transcription layer because the data never leaves the regulated geography. Verify data residency at the infrastructure level, not just in contract language: ask where compute instances run, where object storage buckets reside, and whether region selection is enforced per API request.
If you operate under GDPR, you need infrastructure that keeps EU citizen data in EU-region servers as an architectural property of the platform, not as a contract addendum. We document Gladia's EU and US region separation in our compliance hub. We operate EU and US regional infrastructure with strict data separation. EU workloads are processed and stored in EU-region infrastructure, which removes the need for Standard Contractual Clauses to cover the transcription layer, while US workloads stay within US-region infrastructure for teams with domestic data residency requirements.
Accessing sub-processor details
A sub-processor is any third party that processes personal data on behalf of your transcription vendor. Under GDPR, a controller needs written permission before a sub-processor is engaged, and the controller remains liable for the sub-processor's compliance failures. Review your vendor's sub-processor list before signing to prevent shadow data sharing, where your audio routes through a third-party ML infrastructure provider you've never evaluated. If a vendor can't produce it, treat that as a disqualifying signal.
AI training data compliance policies
This is the single question most teams fail to ask. When a transcription vendor uses customer audio or transcript data to retrain its production models, it means your proprietary conversations (customer support calls, internal meetings, product demos) become training material that improves a shared model offered to all customers, including your competitors. This practice creates regulatory exposure under GDPR's purpose limitation principle (you collected the data for transcription, not for model improvement) and competitive exposure (your audio helps the vendor's model improve on your competitors' use cases). Responsible vendors publish an explicit per-tier data training policy on their pricing page or terms, not buried in a clause requiring opt-out. A defensible policy structure treats data training as opt-in on paid tiers, with clear disclosure on free or starter tiers where training may apply. Some transcription providers use customer audio to retrain their production models by default, with opt-out available only in enterprise contracts, buried in terms of service rather than prominently disclosed on the pricing page.
On Growth and Enterprise plans, Gladia doesn't use audio and transcript data to train its models by default, and you don't need to opt out or find a separate contract clause. On the Starter plan, data can be used for training by default. The distinction is material for any product handling regulated conversations. If you're on the Starter plan and processing sensitive audio, upgrade before you go to production.
Setting up transcript retention rules
Data you don't retain can't be breached. The minimum viable retention policy for a CCaaS platform covers three operational commitments.
GDPR/CCPA transcript retention: Set a default deletion schedule based on your primary business purpose and document it. Implement automated deletion at that threshold using Gladia's delete transcription endpoint, which removes the transcript and associated audio from storage. Review our data retention documentation for storage windows by plan and API parameters for triggering deletion.
Automating PII data removal: The cleanest architecture triggers transcript deletion via webhook once you've written structured data (action items, entity extractions, sentiment scores) to your system of record. Once your CRM is updated, the raw transcript has served its purpose and you should remove it from the transcription provider's storage. Keeping raw transcripts alive after structured extraction is over-retention under GDPR's data minimization principle.
Transcript auditability for SOC 2: SOC 2 Type II requires evidence that your access controls operated as designed over the audit period. For transcripts, this means logging who accessed which transcript and when, with that log retained separately from the transcript itself. Build access logging into your transcript retrieval layer so you have the audit trail available when your SOC 2 auditor asks for it.
Gladia's data governance and SOC 2 compliance
We hold SOC 2 Type II, ISO 27001, HIPAA, and GDPR certifications, with our full certification stack publicly documented and available for enterprise security reviews without requiring an NDA.
We're based in the EU with EU infrastructure. We built EU data sovereignty into the product, with EU data residency available to teams operating under GDPR. Teams can select the EU-west region to keep audio and transcript processing within EU borders.
On Growth and Enterprise plans, we never use customer data for model training. We document the commitment in our terms, not just the marketing page. You don't need an opt-out process because we never made opt-in the default on these plans. For Starter plan users, our standard terms allow training data use, a meaningful distinction for any team processing sensitive conversations.
Is your AI transcription truly compliant?
Compliance isn't a feature you toggle on. You build it from the aggregate of your consent disclosure system, your vendor's data governance posture, your redaction configuration, and your retention automation. Getting one layer right doesn't compensate for a gap in another.
Consent compliance: Default to all-party consent requirements in your IVR, regardless of where your support operation is based. Thirteen states require it, and the penalty for a missed disclosure in California or Florida is criminal, not just civil. Implement a universal pre-call disclosure to remove the cross-state exposure entirely.
GDPR and EU transcript storage: If you process EU resident calls, verify that your transcription vendor has EU-region infrastructure and a signed DPA. You violate GDPR by transferring data cross-border without a valid mechanism, regardless of where you incorporated your company. Verify data residency at the infrastructure level, not just in contract language.
PII exposure in transcripts: Configure PII redaction explicitly at the API level before transcripts touch any persistent store. For PCI-scoped audio, treat any call where a customer might read payment data as in scope and configure redaction accordingly. Async processing gives you the full conversation context for entity classification, which improves redaction accuracy. Review Gladia's PII redaction guide for implementation patterns, including how to handle redaction fan-out across downstream systems.
Auditing your current vendor: Audit against the checklist in this article before your next enterprise security review finds the gap. Verify the data training policy by tier, request the sub-processor list, confirm data residency at the infrastructure level, and check that you've configured and logged PII redaction in your API requests. For the CCaaS use case implementation, treat these as the baseline, not optional hardening steps.
Start with 10 free hours, review the compliance hub, and request the DPA before you commit to any production audio pipeline.
FAQs
Does Gladia retrain its models on customer support call audio?
On Growth and Enterprise plans, Gladia never uses customer audio or transcripts for model training, and no opt-out is required. On the Starter plan, data can be used for training by default, so teams processing sensitive conversations should upgrade before going to production.
Is PII redaction enabled by default in Gladia's API?
No. You must explicitly configure PII redaction as an optional feature in the API request. When you enable it, we identify and replace entity categories such as names, phone numbers, and credit card numbers with placeholder labels such as [NAME] and [CREDIT_CARD_NUMBER].
What certifications does Gladia hold for enterprise security reviews?
Gladia holds SOC 2 Type II, ISO 27001, HIPAA, and GDPR certifications, with clusters across Europe and the US.
Does Gladia offer EU data residency for GDPR-compliant deployments?
Yes. We operate EU-west and US-west regional infrastructure with data separation. When you select the EU region, we process and store EU workloads within EU-region infrastructure.
What is the difference between SOC 2 Type I and Type II for vendor evaluation?
SOC 2 Type I is a point-in-time snapshot confirming that controls exist on a given date. Type II covers six to twelve months and verifies that those controls operated effectively throughout the period, which is the standard enterprise security reviews require.
Key terms glossary
PII (personally identifiable information): Any data that can identify an individual, typically including names, email addresses, phone numbers, and account identifiers. In support call transcripts, PII falls under GDPR and CCPA requirements and can be redacted using configurable API features.
PCI DSS (Payment Card Industry Data Security Standard): A security standard governing storage, processing, and transmission of cardholder data, including PANs and CVV codes. Any system that stores unredacted payment card data in a transcript falls within PCI DSS scope and is subject to audit.
Data residency: The requirement to store and process data within a specified geographic region, typically to satisfy local data sovereignty laws such as GDPR. This differs from contractual data location commitments, which sub-processors can override if not enforced at the infrastructure level.
