Your meeting notes are leaving your device. Here's what that means.

Most people who use an AI notetaker have not thought carefully about what happens in the first three seconds after they tap record. It's worth thinking about, because what happens in those three seconds determines everything: who has access to your words, under what jurisdiction, under what retention policy, and under what legal authority.

Here's what happens when you tap record on most AI notetakers.

The cloud transcription pipeline

When you record a meeting on Otter.ai, Fireflies.ai, Fathom, tl;dv, or Granola, the following sequence occurs:

1. Your device compresses and buffers the audio
2. The audio stream is transmitted over your internet connection to the provider's servers
3. A cloud speech-recognition model (often powered by Google, AWS, or a proprietary API) transcribes the audio
4. A large language model generates a summary and extracts action items
5. The transcript and summary are returned to your device
6. The audio may be retained by the provider under their data retention policy — or deleted after processing, depending on the tool

This pipeline is why cloud notetakers are fast and accurate: they can run very large models on powerful server hardware. It's also why your audio travels through infrastructure you don't control, operated by a company you're trusting with the content of your conversations.

According to a 2026 industry survey, 73% of businesses cite privacy and security as the primary barrier to AI notetaker adoption. Among people who haven't adopted an AI notetaker, 50% name security concerns as their primary reason. These concerns are not irrational. They reflect a real understanding of what cloud processing involves.

What "GDPR compliant" actually means for a cloud tool

When a cloud notetaker claims GDPR compliance, that claim operates at the policy level, not the architectural level. What it means is:

• They have a Data Processing Agreement (DPA) available
• Their servers are certified under relevant frameworks
• They have a retention and deletion policy
• They respond to data subject requests

What it does not mean is that your data is safe from a server breach, a compelled disclosure under the US CLOUD Act (if they're a US company), or a change in their data practices following a merger or acquisition.

A DPA is a contractual arrangement between two parties. It can be broken. It can be audited and found wanting. It operates after your audio has already left your device.

The Information Commissioner's Office is explicit that Article 9 special category data — health, biometric, racial/ethnic origin, religion, political opinion — requires the highest standard of protection. Patient consultation audio, therapy session recordings, and HR investigation recordings all fall in this category. Processing them through a cloud service, even one with a DPA, creates an exposure that many compliance teams will not accept.

The "Granola is private" question

Granola is worth examining specifically because it's the cloud notetaker most often described as privacy-conscious. Its pitch is compelling: no bot joins your meeting, it captures system audio directly from your Mac, and it doesn't store your audio recordings.

That last claim is accurate and meaningful. Granola deletes audio after processing. But the audio still travels to Granola's servers for transcription. The privacy story is "we process it in the cloud and then delete it" — not "it never leaves your device." These are different claims.

Granola's own documentation confirms that AI model training opt-out is gated to the Enterprise tier at $35/user/month. On the free and Business plans, your transcription data may be used to improve their models. This is a standard practice in the industry. It's worth knowing about before you record your next sensitive conversation.

GDPR by architecture, not policy

There is a formulation that matters for clinical, legal, and research contexts: GDPR by architecture.

A tool that processes audio on-device doesn't need a DPA because there is no data processor. It doesn't need a retention policy because nothing is retained externally. It cannot be compelled to provide your audio to a government authority because it doesn't have your audio. It cannot be breached remotely because there is no server holding your data.

This is not a stronger version of the same guarantee cloud tools offer. It is a categorically different guarantee. One is contractual. The other is architectural. Architecture cannot be violated by a policy change, a legal order, or a server breach.

For a clinical team, this distinction is the difference between a tool that is GDPR compliant and a tool whose GDPR compliance is inherent to how it works.

A clinical scenario worth taking seriously

A junior doctor records a ward round. Three patients are discussed in detail: names, diagnoses, treatment plans, medication doses, social circumstances. The recording lasts 22 minutes.

If that recording is made with a cloud notetaker, the following has occurred:

• Patient audio (Article 9 special category health data) has been transmitted to a US company's servers
• The audio has been processed by third-party AI infrastructure
• The transcript exists in a cloud database under the provider's retention policy
• The junior doctor has almost certainly not obtained consent for this data transfer
• The NHS trust's Caldicott Guardian would, if asked, prohibit this use

NHS Data Security and Protection Toolkit standards require that patient identifiable data is only transmitted and processed on approved, contracted systems. An individual clinician using a consumer cloud app does not meet this standard.

The same scenario with an on-device notetaker produces a completely different picture. The audio is processed on the doctor's phone. No data leaves the device. The GDPR position is clean: the doctor's phone is the processing environment, the data controller is the NHS, and there is no third-party processor to audit.

What happens to audio on different tools

Understanding the actual data flow on each major tool helps clarify the decision:

The difference between "policy-based" and "architectural" privacy is the difference between trusting a company and not needing to trust a company. For sensitive use cases, the latter is the only defensible position.

The consent conversation

One practical advantage of on-device processing is how it simplifies the consent conversation with the people you're recording.

With a cloud tool: "I'm using an AI notetaker. It sends audio to [company]'s servers in [country], where it's transcribed, summarized, and stored under their privacy policy. You can request deletion under GDPR."

With Kuulo: "I'm using an AI notetaker. It runs entirely on my phone. Nothing leaves my device."

The second explanation is easier to give, easier to understand, and easier for the other person to agree to. For therapists, GPs, researchers, and journalists — all of whom need to explain data handling to the people they're working with — this matters practically, not just ethically.

What Kuulo's architecture means in practice

Kuulo records, transcribes, and summarizes entirely on-device. The models run on Apple Silicon — the Neural Engine on iPhone's A-series chips and Mac's M-series chips. No audio is ever transmitted. No account is required, which means there is no cloud profile to associate with your recordings.

Sharing is opt-in and per-note. When you choose to share a note, you share a formatted summary — not the audio. You control whether the link expires and can revoke it at any time. The audio itself stays on your device indefinitely.

For the majority of users recording ordinary meetings in an office with stable internet, the privacy architecture of their notetaker may never matter. But for the significant minority who record something sensitive — a medical consultation, a therapy session, a legal intake, a research interview, a confidential negotiation — it matters enormously.

The question is not whether you will ever record something sensitive. It's whether you want a tool built from the ground up for that case, or a tool that handles it as an afterthought via a policy document.