GDPR Compliance Checklist for AI Meeting Assistants: What Fireflies, Otter.ai, and Gong Get Wrong

Most EU companies evaluating AI meeting assistants ask the wrong question. They ask whether the vendor is "GDPR compliant" and accept a checkbox answer. The right question is whether the tool satisfies the five specific legal requirements that GDPR imposes on tools that record, transcribe, and analyze conversations involving EU data subjects. Fireflies.ai, Otter.ai, and Gong — the three most widely adopted tools in this category — each fail at least one of these requirements in ways that create real legal exposure. A 2024 study found that 73% of AI agent implementations in European companies had GDPR vulnerabilities, with 47% lacking explicit informed consent and 39% operating without a defined retention policy. This is not a paperwork problem. It is an enforcement problem, and regulators are catching up.

The 5-point GDPR compliance framework for AI meeting tools

GDPR does not contain a single article that governs AI meeting tools specifically, but five distinct requirements converge on any tool that records and processes conversations between natural persons in the EU. Meeting all five is the baseline for genuine compliance — not a marketing claim.

1. EU data residency for both storage and processing. Under Article 44 and the Schrems II ruling, transferring personal data to a third country without adequate safeguards is unlawful. Storage in the EU is necessary but not sufficient: if audio is sent to a US-based AI model for transcription or analysis, that processing step constitutes a data transfer. The transfer safeguard — Standard Contractual Clauses plus a Transfer Impact Assessment — must cover the processing, not just the storage location.

2. On-device transcription (audio never leaves the device). The cleanest way to eliminate the transfer problem entirely is to perform speech-to-text conversion locally on the user's device, so that raw audio never traverses a network at all. Only the resulting text — which carries significantly less biometric risk than audio — is then transmitted for further processing. This architectural choice is not required by GDPR, but it is the only approach that eliminates the audio transfer risk without relying on SCCs and TIAs that can be legally challenged.

3. Article 28 Data Processing Agreement with EU Standard Contractual Clauses. Any external vendor that processes personal data on your behalf is a data processor under Article 28. A DPA is legally mandatory — not optional, not something to negotiate after the pilot. The DPA must specify the subject matter and duration of processing, the nature and purpose of the processing, the type of personal data, and the categories of data subjects. Crucially, it must also explicitly prohibit the vendor from using your data to train AI models. If that prohibition is absent from the DPA, the vendor's training activities are legally your responsibility.

4. Transfer Impact Assessment documentation. Even with SCCs in place, Article 46 requires that you assess whether the destination country's legal framework undermines the protections the SCCs are supposed to provide. For US processors, this means a documented TIA that evaluates US surveillance law (FISA 702, EO 12333) against the specific data being transferred. Most companies using US-based AI tools have signed SCCs but never completed a TIA — which means their transfer safeguard is legally incomplete.

5. Binding no-training agreements with all AI sub-processors. Your DPA with the primary vendor is not enough if that vendor routes your data through sub-processors — transcription APIs, AI inference engines, cloud storage layers — that have their own model training policies. Article 28(4) requires that sub-processors provide at least the same data protection guarantees as the primary processor. This means your no-training prohibition must flow down the entire chain, and you must be notified of any sub-processor change before it occurs.

Fireflies.ai: stored in the EU, processed in the US — the compliance gap most buyers miss

Fireflies.ai is the most commonly cited "GDPR-friendly" option among EU sales teams, largely because it offers an EU Private Storage plan. The framing is almost always: "We keep your data in Europe." What that means in practice is more limited than the marketing implies, and the gap matters for compliance purposes.

Under the EU Private Storage configuration, meeting recordings and transcripts are stored on servers located within the EU. This satisfies the data residency requirement for storage. However, when a meeting is recorded, the audio must be transcribed and analyzed before it can be stored as a searchable transcript with AI summaries. That transcription and AI analysis step — the processing — occurs on Fireflies' US-based infrastructure. The raw audio, or at minimum the audio stream processed for transcription, traverses the Atlantic.

This creates the compliance gap that most buyers miss. EU data residency for storage is visible and easy to communicate. EU data residency for processing is an architectural constraint that requires either a separate EU-based transcription stack or on-device processing. Fireflies has not publicly documented EU-based AI inference for its transcription pipeline as of mid-2026. The company's DPA covers the storage location but is silent on where the transcription model runs.

For a DPO conducting a vendor assessment, this means Fireflies' EU Private Storage plan satisfies Article 44 for stored data but does not satisfy it for processed data. You would still need SCCs and a completed TIA covering the processing step. Whether Fireflies provides a usable TIA is a question worth asking directly before signing. Most EU enterprise buyers have not asked it.

The practical consequence: Fireflies is a workable option for EU companies prepared to execute SCCs and a TIA for the processing transfer, and whose legal basis for recording is documented. It is not a tool you can deploy and declare compliant without that additional paperwork. The EU Private Storage label addresses one of the five compliance requirements, not all five.

Otter.ai: US-hosted, trains on your meetings by default

Otter.ai presents the clearest compliance picture of the three — it is clearly non-compliant for EU companies under the current legal framework, with no architectural option to remediate this. Otter.ai is a US-hosted service. All audio, transcripts, and derived analytics are processed and stored on US infrastructure. There is no EU data residency option, no EU-region deployment, and no on-device transcription mode.

The training issue compounds the transfer problem. Otter.ai's terms of service permit the company to use de-identified audio recordings to train and improve its proprietary AI models. De-identification is not anonymization under GDPR: if a natural person can still be identified from the de-identified data through combination with other information, the data remains personal. In meeting recordings, voice is a biometric identifier. Speaker patterns, vocabulary, and conversation context make re-identification plausible even from "de-identified" audio. The Article 29 Working Party guidance and its successor, the EDPB, have consistently held that de-identification does not equal anonymization for biometric data.

This means that an EU company using Otter.ai is not only transferring personal data to the US without an adequate safeguard — it is also potentially allowing that personal data to be used to train AI models without a legal basis for that processing activity. The DPA it would need to sign with Otter.ai would need to prohibit model training on meeting data. Otter.ai's standard terms do not provide this prohibition.

For EU companies, Otter.ai is not a compliant option under current GDPR requirements regardless of what SCCs or DPAs are in place. The absence of EU infrastructure means that even a perfect legal transfer framework cannot address the fundamental processing architecture problem. EU buyers who have deployed Otter.ai based on a vendor-provided DPA should flag this for their DPO immediately.

Gong: all data in the United States, ISO 27001 status uncertain

Gong occupies a different position in the market. It is not primarily a meeting notetaker — it is a revenue intelligence platform that uses meeting recordings as input to pipeline analytics, deal forecasting, and rep coaching. This makes its compliance profile more complex, but the core data transfer facts are unambiguous: Gong stores all customer data in the United States, regardless of the customer's location.

Gong's GDPR compliance posture relies on two mechanisms. First, it holds Data Privacy Framework certification, which provides a legal basis for EU-US data transfers under Article 45 (adequacy decision). The DPF is the successor mechanism to Privacy Shield, which was invalidated in Schrems II. The DPF itself faces ongoing legal challenges; its long-term durability as a transfer mechanism is not guaranteed. Second, Gong supplements DPF with Standard Contractual Clauses in its enterprise DPA. SCCs as a backup to DPF is sound practice, but SCCs require a Transfer Impact Assessment to be legally effective, and Gong does not publicly provide a completed TIA template for its customers.

The ISO 27001 question adds a procurement risk layer on top of the compliance question. Gong's ISO 27001 certification — a common requirement in enterprise security questionnaires — was reported to be expiring in October 2025. ISO 27001 certifications require annual surveillance audits and full recertification every three years. If recertification lapsed, Gong's certification claim during a 2026 procurement process should be verified against current Gong documentation, not assumed.

For EU enterprises, Gong is a defensible option only with a fully executed DPA, a completed TIA conducted by your own legal team (not relying solely on Gong's documentation), and a confirmed current ISO 27001 certificate. The data never leaves the US — that is the architectural constraint your DPO needs to sign off on explicitly, not implicitly through a vendor checkbox.

What a genuinely compliant EU meeting tool looks like

The five-point framework is a useful filter precisely because it is achievable — but achieving it requires architectural choices that most US-headquartered tools have not made, because their primary market does not require them. A genuinely compliant EU meeting tool looks different from the inside out, not just on the compliance documentation page.

At the infrastructure level, both storage and AI processing must occur within European infrastructure. This is not simply a matter of choosing an AWS eu-west region for a database; it means the transcription model, the AI analysis pipeline, and the derived analytics must all run on EU-hosted compute. For tools that use large language models for summarization and insight extraction, this requires either a European model deployment or a model that can run entirely on-device.

On-device transcription — converting speech to text locally on the user's device before any data leaves — is the most privacy-preserving architecture for the initial recording step. It means raw audio, which carries the highest biometric sensitivity, never traverses a network. Only the text transcript, which is still personal data but lacks the voice biometric, is transmitted for further processing. Tools built on this architecture can provide strong documented evidence that they satisfy Article 5(1)(c) data minimization: they are collecting the minimum data necessary for the purpose.

Hedy AI version 2.15 introduced EU/US storage choice at onboarding, and for EU-region users, both storage and AI processing occur through European infrastructure. This is a meaningful architectural improvement over the partial EU storage models. However, it is worth noting that Hedy still retains US-based infrastructure for account authentication, subscription billing, and error monitoring. These functions process metadata — account credentials, payment information, event logs — that may include personal data. A complete compliance review should evaluate these auxiliary US-hosted functions alongside the core recording and transcription pipeline.

The DPA is not just a document to sign — it is a set of operational commitments. A DPA for an AI meeting tool should explicitly specify the permitted processing purposes (transcription, analysis, coaching — not model training), enumerate all sub-processors with their locations and processing roles, provide at least 30 days notice of sub-processor changes with a right to object, and include deletion timelines that match your retention policy. See how Numi's approach to EU-native call intelligence addresses these requirements by design rather than by documentation.

The sub-processor chain is where most vendor DPAs fall apart in practice. The primary vendor may have robust EU infrastructure, but if it routes transcription through a US-based speech-to-text API, the chain is broken. Require a complete sub-processor list with processing locations, and verify that each sub-processor has its own DPA with the primary vendor that includes the no-training prohibition.

The consent problem most sales teams are ignoring

The infrastructure and documentation requirements are the ones most commonly discussed in GDPR compliance guides for AI meeting tools. The consent requirement is the one most commonly violated in practice, and the one most likely to create enforcement exposure.

GDPR Article 5(1)(c) requires data minimization: personal data must be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed." Recording all meetings by default violates this principle directly. The default setting on an AI meeting tool must be recording-OFF. Recording should require an affirmative choice by someone with authority to make that choice, not an opt-out that most participants will never find.

Consent under Article 7 requires that it be freely given, specific, informed, and unambiguous. In the context of a recorded meeting, this means every participant must give prior explicit consent before the recording begins — not a "this meeting is being recorded" banner that appears after they have already joined, and not a policy clause buried in a vendor contract that the participant never saw. The banner that most AI meeting tools add to calendar invites or display at meeting start does not satisfy GDPR consent requirements. It is a notification, not consent.

The distinction matters practically. If a sales rep starts a recorded call with a prospect who is an EU data subject, and the prospect's only notice was a "Recording in progress" message in the video interface, that recording has no valid legal basis. Legitimate interest — the most common alternative to consent for B2B recordings — requires a documented Legitimate Interest Assessment showing that the recording is necessary for the stated purpose and that the data subject's interests do not override the legitimate interest. If that LIA has not been completed, legitimate interest does not apply either.

The EU AI Act adds another layer that applies specifically to AI meeting tools. Article 26(11) requires that deployers of high-risk AI systems inform natural persons that they are subject to automated processing. AI meeting tools that generate behavioral scores, coaching analytics, or performance metrics from meeting recordings meet the threshold for high-risk AI under the AI Act's Annex III classification of biometric categorization systems. Informing participants that their data is being processed by a high-risk AI system is not the same as a recording disclosure — it requires explaining that AI is being used to analyze their behavior.

A Data Protection Impact Assessment under Article 35 is mandatory before deploying any AI meeting tool at scale. The German Data Protection Conference (DSK) has explicitly endorsed this position. A DPIA must identify the processing risks, assess their severity, and document the measures taken to mitigate them. It is not a one-time exercise: it must be reviewed whenever the processing changes in a material way — for example, when the tool adds a new AI analysis feature or changes its sub-processor stack. Companies that deployed AI meeting tools before the EU AI Act came into force and have not conducted a DPIA are operating in violation of Article 35, independent of whether their tool is otherwise compliant.

The practical checklist for sales operations teams deploying an AI meeting tool in the EU:

1. Complete a DPIA under Article 35 before go-live. Involve your DPO.
2. Set the default recording state to OFF. Require affirmative activation per meeting.
3. Document your legal basis. Legitimate interest requires a written LIA; consent requires an explicit opt-in mechanism that meets Article 7 standards.
4. Sign an Article 28 DPA that explicitly prohibits AI training on your meeting data.
5. Confirm where processing occurs — not just where data is stored. Obtain a completed TIA for any US-based processing.
6. Require prior explicit consent from all participants before recording begins. A banner is not consent.
7. Set a defined retention schedule and test automated deletion.
8. Review the sub-processor list. Confirm no-training guarantees flow to all sub-processors.
9. Disclose AI processing to participants per EU AI Act Article 26(11) if the tool generates individual-level behavioral analytics.

The gap between "we have a DPA signed" and "we are GDPR compliant" is where most EU companies currently sit. For RevOps and Sales Ops teams, the compliance work is not optional overhead — it is the condition under which the tool is legally deployable. The enforcement risk from regulators and from DPAs exercising data subject rights has been accelerating since 2023. Getting this right before an audit is significantly cheaper than getting it right after one.