TL;DR: Meeting audio is personal data under GDPR, and every STT vendor you route it through becomes a data processor under Article 28, with a signed data processing agreement as a core requirement. The compliance surface covers data residency, no-training commitments, PII redaction, deletion APIs, and sector-specific requirements such as HIPAA BAAs for healthcare and regulated retention workflows for finance. Gladia highlights GDPR Compliant, HIPAA Compliant, AICPA SOC Type 2, and ISO 27001 Compliant status, along with retention controls, deletion tooling, and enterprise deployment options for stricter security and residency requirements.
Building an automated note-taking system for a regulated environment is a different engineering problem than building one for a general-purpose SaaS product. The accuracy and latency questions are the same, but sitting underneath them is a compliance layer that can block a production launch entirely: unsigned DPAs, data flowing through the wrong region, a no-retraining clause buried in fine print, or a missing HIPAA BAA. Legal reviews of STT vendors routinely take longer than the integration itself, and they surface blockers that weren't visible in the API documentation.
This guide works through each layer of that compliance surface in sequence: from the GDPR principles that apply to meeting audio, through the specific API features and deployment options that let you satisfy them, to the pre-production checklist your legal and security teams will expect you to have completed before sign-off.
What GDPR actually requires for meeting audio and transcripts
Personal data in meeting transcriptions
Meeting audio constitutes personal data under GDPR because recorded voices can identify individuals, and transcripts typically capture identifying information such as names, roles, and conversation content that participants share. GDPR Article 5 applies the moment you collect audio from EU residents, regardless of where your servers sit or where your company is incorporated.
The Irish Data Protection Commission's principles guidance outlines data protection principles that apply to processing personal data: lawfulness and transparency, purpose limitation, data minimisation, accuracy, storage limitation, and integrity with confidentiality. Each has implications for a meeting transcription pipeline.
Purpose limitation means you can't collect audio for meeting notes and then route it to an analytics pipeline without a separate lawful basis. Data minimization means you should configure the shortest possible retention period for raw audio and transcripts. Storage limitation means you need a documented retention and deletion policy that ensures data is not kept longer than necessary for the stated purpose. Integrity and confidentiality means encryption in transit and at rest, access controls, and documented incident response.
For a broader orientation to these requirements in the STT context, Gladia's compliance regulations guide covers GDPR, HIPAA, and PCI-DSS in one place.
The six principles and what they mean in practice
The six GDPR principles translate into concrete engineering decisions for a meeting notes system:
- Lawful basis selection: Processing audio typically requires a documented reason. Legitimate interests or contractual necessity are common bases for internal meeting tools, but for customer-facing tools you may need explicit consent with an opt-out mechanism.
- Retention configuration: Raw audio and transcripts should have explicit, documented deletion timelines. The principle of storage limitation suggests that data is kept "no longer than necessary" for the stated purpose.
- Deletion workflow: A tested, reliable mechanism to delete specific transcripts on request is important for meeting data protection obligations. This requires an API endpoint that performs permanent deletion, not soft deletion.
- Sub-processor transparency: Every vendor your pipeline touches is a sub-processor. You need a complete, current list of them, and your DPA needs to flow those obligations downstream.
Lawful basis for transcribing meetings
Consent is one of the clearest lawful bases for transcribing meetings, though it presents operational challenges since it requires a genuine opt-out mechanism. For internal enterprise tools, legitimate interests (Article 6(1)(f)) is more commonly used, though this approach typically involves demonstrating that the interests of the organization outweigh the privacy interests of participants. If your meeting notes system serves external clients or includes call recordings with customers, the lawful basis analysis becomes substantially more complex and typically requires legal review before deployment.
Regardless of which lawful basis you use, participants must be informed that their audio will be transcribed, who processes it, how long it's retained, and how to exercise their rights. Updating your privacy notice and meeting invitation templates before you begin processing ensures you meet transparency obligations from day one.
Data processing agreements: what Article 28 requires
The eight mandatory DPA clauses
GDPR Article 28 requires a written contract between you (the data controller) and any vendor that processes personal data on your behalf (the data processor). This isn't guidance or best practice; it's a legal requirement that must be in place before processing begins. The penalty for operating without one falls on the controller, not the processor.
The GDPR.eu DPA overview identifies eight mandatory clauses that every Article 28 contract must include:
- Typically, the processor processes data only on documented instructions from the controller.
- Generally, personnel accessing the data are bound by confidentiality obligations.
- Appropriate technical and organisational security measures are typically specified.
- Often, sub-processors require the controller's authorisation, with sub-processors subject to equivalent obligations.
- The processor commonly assists the controller in responding to data subject rights requests (access, deletion, portability).
- The processor often assists with security obligations and data protection impact assessment requirements.
- Arrangements for data deletion or return on termination are typically included.
- Provisions for processor cooperation with audits and compliance verification are commonly specified.
The ICO's controller-processor contracts guidance adds that controllers retain primary accountability under UK GDPR, meaning a processor's breach of the DPA creates both regulatory and civil liability exposure for the controller. Sign the DPA before you make a single API call.
Gladia’s DPA is publicly available and includes provisions on sub-processors, deletion, and audit cooperation that should be reviewed by legal counsel against your Article 28 requirements before launch.
Sub-processor obligations
Your DPA with Gladia covers Gladia’s own processing, but the service runs on cloud infrastructure, which means your audio passes through sub-processors. Hyperstart's DPA analysis notes that controllers must approve sub-processors explicitly, and the DPA must bind sub-processors to the same data protection obligations as the primary processor.
Before production, request Gladia’s current sub-processor list. Per GDPR Article 28, any changes to that list should trigger a notification to you, giving you the right to object before the change takes effect.
How to verify your DPA covers meeting transcription
A generic DPA template may not explicitly address audio data, speaker identification, or transcript storage. Before sign-off, verify that the DPA specifies:
- The category of personal data (audio recordings, transcripts, speaker labels) by name.
- The specific processing operations (transcription, diarization, summarisation, deletion) that are authorised.
- The data residency commitment, including whether processing uses European infrastructure by default and what other geographies are available based on customer requirements, along with the infrastructure provider.
- The timeline for sub-processor notification when the list changes.
- The breach notification obligation, including the contractually defined notification window to you (verify this is specified in hours, not business days, as it triggers your own 72-hour notification obligation to supervisory authorities under Article 33).
For a detailed walkthrough of Gladia’s compliance posture and how it maps to these requirements, the compliance hub is the starting point, with SOC 2 and HIPAA reports available on request.
Data residency and cross-border transfers
EU data residency for GDPR compliance
GDPR doesn't require that all EU resident data stays physically within EU borders, but it places significant restrictions on transfers outside the EU and EEA. The EDPB's international transfers guide outlines two primary mechanisms: adequacy decisions (where the European Commission has determined that a third country provides adequate protection) and appropriate safeguards such as Standard Contractual Clauses (SCCs).
In practice, the cleanest compliance posture for EU personal data is to keep it within the EU. Gladia’s public security materials state that it uses a European provider based in France by default, which can support keeping EU resident meeting audio in European infrastructure depending on your deployment configuration. Regional data hosting options are available to support geographic separation of workloads based on customer requirements.
For applications serving both EU and US customer bases, verify which regional endpoint your integration uses and document your data routing architecture in your DPIA.
As Flosum's GDPR residency guide notes, organisations serving EU residents from US-based infrastructure must rely on either adequacy decisions, SCCs, or Binding Corporate Rules (BCRs). Cross-border data transfer mechanisms can be subject to legal and regulatory changes that create uncertainty. Keeping EU data in EU infrastructure avoids reliance on these transfer mechanisms entirely.
Standard contractual clauses and transfer impact assessments
If you need to process EU audio through a US-based system or vendor, SCCs are the most common safeguard. The European Commission's SCC guidance confirms that you must conduct a transfer impact assessment for every transfer using SCCs, assessing whether the destination country's laws undermine the protections the SCCs provide.
For teams building meeting note systems that route audio outside the EU, consider documenting the following in your DPIA: the transfer mechanism (SCCs or adequacy decision), the destination country's legal framework, the supplementary measures in place (encryption, access controls, data minimisation), and the assessment outcome.
No-retraining clauses: why they matter and what to check
The default data use terms across STT vendors vary significantly, and the distinction is not always visible in the headline pricing or marketing copy. Data use policies may differ across pricing tiers, and for regulated industries processing sensitive conversations, it's critical to verify these terms before deployment to avoid compliance gaps that require remediation.
Gladia’s paid plans include data-control options around model training and retention. Confirm the exact plan-level terms in the pricing page and contract before deployment.
When reviewing any STT vendor's no-retraining terms, check four things:
- Tier applicability: Does the no-retraining commitment apply at every paid tier, or only at enterprise?
- Scope of the restriction: Does it cover audio files only, or also transcripts, metadata, and derived outputs?
- Third-party scope: Does the restriction extend to sub-processors and model improvement partners?
- Consent mechanism: If you later want to allow model training (for example, in exchange for custom model fine-tuning), what does the opt-in process look like and what data does it cover?
For the strongest legal protection, look for a no-retraining clause in the DPA rather than relying solely on blog posts or marketing FAQs, since the DPA is the legally binding instrument that governs data use.
Sector-specific requirements
Healthcare and HIPAA BAA requirements
Any STT vendor that creates, receives, maintains, or transmits Protected Health Information (PHI) on behalf of a covered entity is a business associate under HIPAA, and HIPAA requires a signed Business Associate Agreement before any PHI is disclosed to that vendor. This is a hard legal requirement with no grace period or fix-it-later option.
The HIPAA Journal's BAA guide provides helpful context on business associate agreements. Because BAA requirements are complex and legally binding, your legal team should verify that any proposed BAA meets all applicable HIPAA requirements before signing - marketing materials alone are not sufficient to confirm compliance.
Gladia’s public materials state HIPAA compliance and offer healthcare documentation through the compliance hub. For deployments that process PHI, request a BAA before sending patient data through the API.
Gladia’s healthcare case study shows a production deployment where an AI-powered healthcare assistant improved medical transcription speed by 120%, confirming the API's viability in clinical environments. Technical performance and compliance readiness are separate questions, though, so verify the BAA independently of the accuracy benchmarks.
For practical implementation guidance on BAA requirements in communications contexts, SignalWire's BAA explainer covers the scope of business associate relationships in detail.
Financial services compliance
Financial services meeting transcription touches multiple regulatory frameworks simultaneously. SEC Rule 17a-4 requires broker-dealers to retain originals of all communications received and copies of all communications sent relating to their business for at least three years, with the first two years in an easily accessible format. FINRA Rule 3110 requires firms to establish and maintain a supervisory system for employee communications. Sarbanes-Oxley Sections 302 and 404 (certification of financial statements and internal control assessment) may apply if meetings involve financial planning, material non-public information, or internal control discussions.
The architecture implication is that standard data retention configurations may need to be supplemented to meet SEC recordkeeping requirements. A common pattern teams use: audio routes to Gladia for transcription, the resulting transcript is archived in a separate records management system with immutable storage and indexed retrieval, and then the transcript can be deleted from Gladia’s infrastructure per your retention policy. This separates operational transcription from regulatory recordkeeping, though you should verify any workflow against your specific compliance requirements with legal counsel.
If your transcription pipeline captures audio where participants may discuss payment card numbers, PII redaction via the API can be configured to mask card numbers in the resulting transcript. PII redaction is an optional feature that requires explicit configuration per API call, so you need to include it in your request parameters for every audio file where sensitive financial data may appear.
Legal sector and attorney-client privilege
The legal sector risk with automated transcription is not primarily a GDPR question; it's a professional responsibility question. ABA Model Rule 1.6 requires lawyers to maintain the confidentiality of client information. When using third-party transcription services, lawyers should consult their jurisdiction's ethics guidance regarding appropriate safeguards and client disclosure requirements.
To preserve privilege on meeting transcripts:
- Include disclosure of third-party transcription in client engagement letters, naming the vendor.
- Restrict transcript access to attorney and paralegal staff only, using API key isolation and application-level RBAC.
- Store transcripts with privilege markings and separate from non-privileged documents.
- Document the privilege assertion and the safeguards in your matter management system.
The safest technical approach is treating every meeting transcript as potential work product and implementing maximum access restrictions by default, rather than opening access incrementally.
How Gladia addresses compliance requirements
Compliance certifications
Security teams typically look for documentation covering AICPA SOC Type 2, HIPAA, GDPR, and ISO 27001 when evaluating vendors. As the IAPP notes, SOC 2 Type II is designed to demonstrate that security and privacy controls were tested over a sustained period. This is often the first standard your security team will request.
Sprinto's SOC 2 vs GDPR analysis makes an important distinction: SOC 2 Type II certification is not equivalent to GDPR compliance, and GDPR has no official certification path. The SOC 2 report provides strong evidence that Gladia’s technical controls function as described, but your DPIA still needs to address the controller obligations that fall outside Gladia's scope, including lawful basis, consent management, and DSAR response timelines.
All compliance reports, including SOC 2 and HIPAA attestations, are available through the compliance hub on request. Request them before your security review, not during it.
Data deletion and right to erasure via API
Gladia’s documentation provides a transcription deletion endpoint for removing a transcription and its associated data, while noting that older delete routes are deprecated in favor of more specific pre-recorded endpoints. This provides a programmatic way to respond to DSAR deletion requests as part of your GDPR compliance workflow.
The deletion workflow for a DSAR looks like this:
- Receive the deletion request from the data subject with identifying information.
- Query your application's transcript metadata to identify the corresponding transcription IDs.
- Call the current Gladia transcription deletion endpoint for each transcript associated with that data subject, using the route appropriate to your workflow as documented in the latest API reference.
- Log the deletion request, the transcription IDs deleted, the timestamp, and the API response in your DSAR audit log.
- Respond to the data subject within the GDPR's 30-day window with confirmation of erasure.
- Verify that deletion propagated to backups, and document that confirmation.
Consider configuring your application to capture and store transcription IDs against user and session identifiers at creation time to streamline DSAR response workflows.
Our DPA addresses data deletion obligations upon termination of the processing agreement.
PII redaction capabilities
Gladia’s PII redaction feature is designed to detect and redact personally identifiable information in pre-recorded transcripts. The redaction operates on the transcript output. The redacted output is what's returned and stored, meaning the PII is not persisted alongside the transcript in any retrievable form.
PII redaction configuration is controlled at the request level. Refer to Gladia’s pre-recorded features documentation for the available redaction parameters and implementation details.
Two implementation considerations apply in regulated environments. First, evaluate whether PII redaction aligns with your data minimization obligations. Second, test the redaction feature with representative samples of your audio data before production deployment to understand how it performs in your specific use case.
For details on Gladia’s audio intelligence suite and its capabilities, see the documentation.
Data residency and deployment options
Deployment models for regulated environments may include:
| Deployment model |
Data residency control |
GDPR posture |
Setup complexity |
| European cloud deployment (default) |
European infrastructure, including France-based processing components |
EU infrastructure with legal safeguards |
Minimal |
| Other regional deployment options |
Available depending on customer requirements |
Confirm transfer and residency posture with Gladia for your deployment |
Minimal |
| On-premises |
Contact Gladia for deployment details |
Deployment options available for regulated environments |
Contact Gladia for requirements |
| Air-gapped |
Contact Gladia for deployment details |
Enhanced isolation options available |
Contact Gladia for requirements |
Our public materials describe regionally separated infrastructure, with European infrastructure based in France by default and other geographies available depending on customer requirements.
For organizations that can't route sensitive audio through any cloud vendor, Gladia supports on-premises and air-gapped hosting. On-premises deployment eliminates the cross-border transfer question entirely, and air-gapped deployment addresses environments where any external network connectivity is prohibited by security policy or regulation.
The trade-off is worth considering: on-premises deployment typically involves managing model updates, infrastructure scaling, and uptime internally. Cloud deployment with European infrastructure by default and a signed DPA may meet compliance requirements in many regulated environments. On-premises deployment may be considered when organizational policies require data to remain entirely within controlled infrastructure.
Configuring retention and access controls
Gladia’s security page provides information about retention options, which may include periods such as 1-month, 1-week, 1-day, and zero data retention. Contact support or your account manager to discuss available retention periods that correspond to your documented DPIA rationale. Configure your retention policy before routing real personal data through the API.
Access control configuration works at the API key level. The steps to lock down a production environment are:
- Issue separate API keys per environment. Development, staging, and production should each have isolated keys so that credential exposure in one environment doesn't affect others.
- Consider scoping API key permissions to match your integration's operations. For example, a read-only analytics pipeline that only queries completed transcripts might benefit from a key that cannot initiate new transcriptions or delete data, if your security model requires this separation.
- Implement application-level RBAC on transcript storage in your own system. Transcripts should be accessible only to users with a documented need, not to all authenticated users by default.
- Consider rotating keys periodically based on your organization's security practices. For production rotation, deploy the new key to all systems, allow both keys to work during a monitored overlap period, then deactivate the old key after traffic shifts to ensure zero downtime. If a key is suspected of being exposed, rotating it promptly can help mitigate risk.
- Consider enabling API call logging on your side. Gladia maintains internal access controls and audit procedures, but your DPIA's accountability requirements may benefit from application-side logs that track transcript data access patterns.
For a visual walkthrough of the API in action, including parameter configuration for compliance-sensitive workloads, the real-time webinar replay covers API configuration in detail.
The no-retraining default
Gladia’s plan terms differ by tier. Growth includes automatic model-training opt-out, and Enterprise includes default model-training opt-out, with stronger protections such as zero data retention and stricter residency options. Confirm the exact plan-level terms in the pricing page and your contract before deployment.
When you're ready to move to production in a regulated environment, Gladia’s pricing page shows the current tier structure. Paid plans include audio intelligence features, while higher tiers add stronger controls around model training, retention, and deployment flexibility.
Implementing the shared responsibility model
What we own vs. what you own
GDPR creates a clear division between controller obligations (your company) and processor obligations (Gladia). Neither party’s compliance substitutes for the other’s.
Gladia owns:
- Infrastructure security, encryption in transit and at rest, and physical data centre controls.
- Employee confidentiality (all employees sign NDAs on joining).
- Sub-processor management and DPA flow-down to sub-processors.
- Breach notification to you within the contractual window.
- Deletion execution when you send the API request.
- Providing evidence of compliance when audited (SOC 2, HIPAA reports, DPA).
You own:
- Establishing and documenting the lawful basis for transcription.
- Obtaining and managing participant consent or legitimate interests balancing tests.
- Notifying supervisory authorities of breaches as required by applicable law.
- Notifying affected data subjects of breaches where required.
- Responding to DSARs within applicable timeframes.
- Defining and configuring retention periods.
- Conducting data protection impact assessments where required for high-risk processing.
- Implementing application-level access controls on who can view transcripts.
- Maintaining records of processing activities where required by applicable law.
- Auditing downstream integrations (CRM, LLMs, analytics) that receive transcript data.
As your processor, Gladia follows your documented instructions when handling personal data. See Gladia’s DPA for details on the respective obligations. Your controller responsibilities remain with you regardless of Gladia’s processing role.
Pre-production compliance checklist
Complete all of the following before routing personal data through the API in a production environment. This maps to what a legal or compliance team will typically request before sign-off.
Legal and contractual (must be complete before first API call):
- Signed DPA obtained and reviewed by legal team for Article 28 completeness.
- Healthcare: HIPAA BAA requested via privacy@gladia.io and reviewed.
- Finance: DPA addendum addressing SEC/FINRA record-keeping requirements.
- Legal sector: Client engagement letters updated to disclose third-party transcription.
- Sub-processor list obtained and reviewed.
Technical (must be tested before production launch):
- Data residency configured to match legal requirements, with European infrastructure used by default for EU-sensitive workloads and other geographies confirmed based on customer requirements.
- Data retention policy set explicitly; default not relied upon if a shorter period is required.
- Deletion workflow tested end-to-end with a sample transcription.
- PII redaction enabled and accuracy tested on representative audio samples.
- Transcription IDs captured and stored against user and session identifiers for DSAR mapping.
- Application-level access controls implemented on transcript storage.
- API call logging enabled on your side for audit trail purposes.
Organizational (must be documented before production launch):
- DPIA completed and signed off by data protection officer (if required).
- Lawful basis documented for each processing activity in internal records.
- Participant notification updated (privacy notice, meeting invite templates).
- Breach notification procedure in place and communicated to relevant staff.
- DSAR response process established and aligned with deletion workflow.
- Retention policies documented based on your organization's requirements.
For teams going through an enterprise security review, Gladia’s guide on evaluating STT APIs for compliance provides a structured framework you can share with your security team as part of vendor risk assessment documentation.
GDPR compliance testing before go-live
Documented controls are not the same as working controls. Before production launch, test your implementation and retain the results as evidence for future audits.
1. Deletion verification test:
Create a test transcription using sample audio that contains no real personal data. Call the deletion endpoint and verify whether the transcript remains accessible via the API or dashboard. Consider requesting confirmation from the vendor regarding their data retention and backup policies, and document their response.
2. Data residency audit:
Request infrastructure location documentation confirming that your EU API calls route to EU infrastructure. If feasible, consider requesting information about DNS routing and load-balancing configurations to better understand traffic flow. For on-premises deployments, consider inquiring whether model updates and telemetry calls, if any, include customer audio.
3. PII redaction accuracy test:
Create test audio that contains a controlled set of PII: names, email addresses, phone numbers, and any sector-specific identifiers relevant to your use case (medical record numbers, account numbers). Run the audio through the API with redaction enabled. Verify that all target PII entities are redacted in the output. Consider documenting any observed false negatives for your risk assessment records.
4. Encryption verification:
Consider verifying that TLS 1.2 or higher is used on API calls where possible. As a security best practice, avoid logging raw audio URLs or transcript content in plain text in application logs or monitoring tools.
5. Access control test:
Confirm that API keys are isolated per environment (development, staging, production). Verify that your application enforces role-based access to transcript storage, so that not all authenticated users can retrieve all transcripts. Test that API key rotation supports a grace period where both the old and new keys remain valid, allowing you to deploy and verify the new key before revoking the old one.
6. DPA completeness audit:
Review the signed DPA to ensure it addresses the Article 28 requirements mentioned earlier in this article. Consult with your legal team to confirm adequate coverage before launch.
Common implementation pitfalls
The following errors appear consistently in compliance post-mortems for meeting transcription systems. Most are preventable with a review before production launch.
Missing or unsigned DPA: Starting to process personal data via the API before the DPA is signed is a GDPR violation, even if it's just a proof-of-concept. It is advisable to have the DPA in place before the first call that contains real personal data. Consult with your legal team regarding the DPA requirements for development and staging environments, especially when transitioning from synthetic to real participant audio.
Incorrect region selection: Sending EU resident audio to the US region without SCCs or an adequacy decision in place is an unlawful transfer. Confirm your region parameter explicitly rather than relying on the default. Document the region selection in your DPIA.
PII redaction left disabled: Verify whether redaction is enabled for your configuration. If you're processing audio that may contain PII in a regulated context, explicitly include the redaction parameter in every API call. Configure it consistently across your implementation rather than attempting to segment calls by sensitivity level.
Retention left at default: The default retention period may not align with your legal basis. Configure retention based on what your data protection assessment actually supports rather than accepting whatever default the provider sets.
Deletion not tested: Implementing the deletion API call in your codebase is not the same as verifying it works as expected in production. Test the full deletion cycle, including verification that the transcript is no longer accessible, before you have to execute it for a real DSAR.
Sub-processor changes unmonitored: The sub-processor list will change over time as infrastructure providers are added or changed. Your DPA should include a notification clause that gives you advance warning of changes and the right to object before they take effect. Update your ROPA whenever those changes are notified. GDPR Article 28 requires processors to inform controllers of intended changes to sub-processors.
Downstream integrations unaudited: If your pipeline sends transcripts to a CRM, an LLM, or an analytics tool, consider whether those integrations may be processing personal data. Depending on the nature of the data and processing, you may need to review contractual safeguards and assess these systems as part of your compliance review.
Start your compliance evaluation with 10 free hours of transcription, test the deletion workflow against your DSAR process, and verify residency and contractual terms before scheduling legal review. Gladia’s public documentation and compliance materials are available for review before a formal legal or security review.
FAQs
Is meeting audio considered personal data under GDPR?
Yes. A recorded voice directly identifies a natural person, which meets the GDPR definition of personal data under Article 4. Transcripts that include names, job titles, opinions, or any content tied to an identifiable speaker are also personal data and subject to the full scope of GDPR obligations.
What must a DPA with an STT vendor include to satisfy GDPR Article 28?
Article 28 requires eight mandatory clauses: processing only on controller instructions, staff confidentiality, appropriate security measures, sub-processor restrictions, assistance with data subject rights, assistance with security and DPIA obligations, deletion or return of data on termination, and audit cooperation. A DPA that omits any of these is non-compliant.
Do you use my meeting audio to train your models?
Plan terms differ by tier. Growth includes automatic model-training opt-out, and Enterprise includes default model-training opt-out, with stronger protections such as zero data retention and stricter residency options.
What data residency options do you provide?
Gladia offers regional deployment options across EU and US infrastructure. For teams with stricter data residency or security requirements, on-premises and air-gapped deployment options are available on Enterprise plans.
Do you offer on-premises deployment?
Yes. Gladia supports on-premises and air-gapped hosting for organizations with strict data residency or security requirements. Contact our team to discuss availability and pricing for your specific needs.
How do I implement a GDPR right-to-erasure request for a meeting transcript?
Use Gladia’s transcription deletion endpoint with the relevant transcription ID, noting that the older DELETE /v2/transcription/{id} route is marked deprecated in the docs in favor of more specific pre-recorded deletion endpoints. Log the request, the IDs deleted, the timestamp, and the API response. Confirm deletion, then respond to the data subject within GDPR's 30-day window. This requires that your application captures and stores transcription IDs against user identifiers at creation time.
Are you HIPAA compliant, and do you provide a BAA?
HIPAA Compliant healthcare documentation is available for teams evaluating PHI-related deployments. For healthcare deployments that process PHI, contact privacy@gladia.io to obtain a Business Associate Agreement before routing any patient data through the API. A BAA must be signed before PHI is disclosed to any business associate.
What is the difference between PII redaction and acoustic emotion detection in transcription?
PII redaction operates on the transcript text using Named Entity Recognition and pattern matching to identify and mask sensitive entities like names, emails, and phone numbers. It requires only the transcript to function. Acoustic emotion detection, if available, would analyze audio characteristics to infer emotional state, representing a technically distinct capability. Consult current feature documentation for specific implementation details, and ensure these capabilities are not conflated when designing a compliance-sensitive pipeline.
What does the shared responsibility model mean in practice for GDPR?
Gladia (the processor) owns infrastructure security, encryption, sub-processor management, and deletion execution. You (the controller) own establishing the lawful basis, obtaining participant consent, responding to DSARs, notifying supervisory authorities of breaches within 72 hours, conducting the DPIA, and maintaining the ROPA. A signed DPA covers the processor layer, but your controller obligations require separate compliance work.
At what point in the integration process must the DPA be signed?
The DPA must be signed before any personal data is processed via the API. The DPA must be in place before real participant audio routes through the production environment. Treating the DPA as a post-launch administrative step creates significant compliance risk.
Key terms glossary
Word error rate (WER): The percentage of words in a transcript that differ from the ground truth, calculated as substitutions plus deletions plus insertions divided by total words. Lower WER indicates higher accuracy.
Diarization: A speech processing technique that assigns speaker labels to segments of audio. Gladia’s diarization uses pyannoteAI's Precision-2 model, a third-party provider that processes audio as a sub-processor under the DPA.
Data processing agreement (DPA): A legally binding contract required by GDPR Article 28 between a data controller and a data processor, specifying the terms under which personal data may be processed.
Data Protection Impact Assessment (DPIA): A structured risk assessment required by GDPR Article 35 before high-risk processing begins, documenting the processing purpose, necessity, risks, and mitigating controls.
Records of Processing Activities (ROPA): Documentation required by GDPR Article 30 that records all processing activities carried out by a controller, including the purpose, categories of data, recipients, and retention periods.
Standard Contractual Clauses (SCCs): Pre-approved contractual terms issued by the European Commission that provide appropriate safeguards for personal data transfers from the EU to third countries.
Air-gapped deployment: A deployment architecture where the system has no external network connectivity, providing maximum isolation for sensitive data processing.
PII redaction: The process of detecting and replacing personally identifiable information in a transcript with entity labels or masks, preventing sensitive data from being stored in retrievable form. Requires explicit configuration per API call and does not enable by default.
Business Associate Agreement (BAA): A contract required by HIPAA between a covered entity and any vendor that handles Protected Health Information on its behalf.
Transfer impact assessment: A structured evaluation required when using SCCs for cross-border data transfers, assessing whether the destination country's legal framework undermines the protections the SCCs provide.
.png)
.png)
.png)
.png)
