Server-side meeting transcription creates a breach surface, a subprocessor chain, and a compliance checklist. On-device transcription eliminates the data set.
Most meeting-notes tools are built like ordinary SaaS products. An app on the user's device uploads audio or a transcript to a vendor's backend, a hosted transcription pipeline processes it, and the output is returned to the user. The finished transcript, the summary, and often the original audio file live on the vendor's servers for the duration of a retention policy the vendor sets — which is where compliance teams start having a problem.
That architecture is normal. It is also what makes a meeting-notes tool relevant to a compliance team. The moment your meetings are stored on a vendor's infrastructure, the vendor is processing personal data on your behalf — sometimes special-category personal data — and the compliance questions accumulate. This post walks through the breach-surface problem that compliance teams actually care about, the regulatory frameworks most likely to touch meeting recordings, and what an on-device transcription architecture actually changes.
This is not legal advice. Your compliance obligations depend on your jurisdiction, industry, contracts, and data types. The goal is to describe the shape of the problem; a qualified professional needs your specific facts before answering whether any of this applies to you.
Every meeting stored on a vendor's server is one meeting that can be breached. Server-side transcription creates three exposure surfaces a compliance team has to account for. First, the transport path: the audio file crossing the public internet between the user's phone and the vendor's ingestion endpoint. Second, the storage layer: the object storage and database where the audio, the transcript, and the summary sit for the retention period. Third, the operational surface: the vendor's employees and subprocessors with administrative access to that storage for support, debugging, or model evaluation. Each surface is governed by technical controls, legal agreements, and vendor processes. All three are places where a breach, a misconfiguration, an insider, or legal process can produce an exposure event. On-device transcription removes the upload, the storage, and the operational surface in one architectural decision — the audio never leaves the user's device.
Meetings are a data type compliance frameworks do not always name directly, but most treat under a broader category. Here are the regulations most likely to apply.
GDPR (EU + UK). Under the EU General Data Protection Regulation and its UK successor, a voice recording or transcript that identifies a natural person is personal data. If the meeting covers sensitive categories — health, religion, sexual orientation, biometric identification of a participant — it may also be special-category data under Article 9 of the GDPR, which imposes additional lawful-basis requirements. Article 32 of the GDPR requires controllers and processors to implement "appropriate technical and organisational measures" to protect personal data. The exact measures are left to the controller, but encryption, access controls, and breach notification are common expectations. Meeting-notes vendors that store personal data on your behalf are typically Article 28 processors and require a Data Processing Agreement.
HIPAA (US healthcare). If any of your meetings discuss identified patient information, the HIPAA Security Rule (45 CFR Part 164, Subpart C) governs the technical, administrative, and physical safeguards around that data. A cloud meeting-notes vendor that stores transcripts of such meetings is almost certainly a business associate under HIPAA, which requires a Business Associate Agreement. Not all vendors will sign one; those that do charge a premium tier for it.
SOC 2. Not a law, but a vendor-assurance framework. A buyer's own SOC 2 controls usually cascade to the vendors they use — meaning if your transcription vendor is in scope for your SOC 2 report, their controls matter to your audit. SOC 2 Type II evaluates the operating effectiveness of controls over an observation period, often 6 or 12 months.
PCI DSS. Rarely relevant to meeting recordings directly, but if a meeting includes payment-card data dictated aloud, the transcript can fall into PCI DSS scope.
State and national privacy laws. California's CCPA/CPRA, Virginia's CDPA, Colorado's CPA, and a growing list of US state statutes create additional obligations. Any US state law that gives consumers a right to deletion applies, at least in theory, to meeting-transcript vendors that fall under its definition of a business.
When a meeting-notes vendor processes personal data for you, the typical contractual framework is a Data Processing Agreement (DPA) or the equivalent. A DPA commonly specifies the categories of data processed, the processing purpose, retention periods, security measures, subprocessor disclosure, breach notification windows, audit rights, and the transfer mechanism for any data leaving the EEA or UK. It exists because Article 28 of the GDPR (and similar provisions elsewhere) require it whenever you use a processor to handle personal data.
A DPA is a real compliance artifact. It is also, structurally, a negotiated contract saying: "I, the controller, acknowledge that my data lives on your, the processor's, servers; we agree on the terms of that fact." The DPA does not reduce the underlying data-surface; it governs it. If the data never leaves the device, the DPA's role narrows substantially, because there is no processor receiving a personal-data flow for most of the processing path.
Most enterprise cloud meeting-notes vendors publish a DPA template on their trust page. It is worth reading. The subprocessor list — the third parties the vendor itself uses to deliver the service — is especially informative. A typical subprocessor list will include a cloud hosting provider, a logging service, a customer-support platform, an analytics vendor, and increasingly an upstream language-model provider. Each subprocessor processes some portion of your meeting data.
On-device transcription does not make compliance obligations disappear. It changes what the obligations apply to.
If meeting audio, transcripts, and summaries never leave the user's phone, most vendors do not become processors of your meeting data. The app's developer runs no server that holds the data; there is no object storage containing transcripts, no database containing summaries, and no subprocessor pipeline to disclose. The user's device is where the data lives; the organisation's existing mobile-device controls — passcode policies, MDM, encryption-at-rest requirements, remote-wipe — are the governing controls.
For most regulated teams, the shift means:
The simplest framing for a regulated organisation: on-device transcription converts a vendor-side data-protection problem into a device-side data-protection problem. The device-side controls are usually already in place for other reasons, and they cover the new data surface without a new vendor review.
One additional dimension worth calling out: data residency and cross-border transfer rules. Chapter V of the GDPR restricts transfers of EU personal data to countries without an adequacy decision, which has made cross-border data flows a recurring audit concern for European organisations using US-hosted SaaS. A typical cloud meeting-notes vendor routes meeting data through infrastructure in the United States, and the resulting transfer mechanism — standard contractual clauses, supplementary measures, transfer-impact assessments — is a non-trivial piece of compliance work. If the meeting never leaves the user's device, the cross-border transfer does not happen in the first place, which removes an entire class of audit findings. The same logic applies to data-localization rules in other jurisdictions — Russia, China, India, and several Middle Eastern and Latin American countries have some flavour of data-localization requirement for certain data types. On-device processing is compatible with all of them by default, because nothing is transferred.
A few categories where on-device processing tends to be the default ask from a compliance or risk team:
In each of these, the question from a compliance reviewer is rarely "is the vendor secure?" and usually "why is this data leaving our device at all?" On-device architectures pre-empt the question by giving it an answer the reviewer already accepts: it isn't.
That question is what shaped Meeting Summarizer's architecture. Every design decision — no backend, no account, no upload path — traces back to it.
On-device processing removes the vendor-storage problem. It does not remove the recording-consent problem, which is separate and arguably more important. Recording laws vary significantly by jurisdiction — some US states require all-party consent, others one-party; the EU's consent model operates under GDPR lawful-basis rules; many non-EU countries have their own regimes. None of that changes because your transcription runs locally. A user still has to obtain whatever consent their law requires before recording a conversation.
It also does not replace good device hygiene. A lost unlocked phone containing a quarter's worth of confidential meetings is still a problem, and the on-device architecture raises the stakes of ordinary mobile-device security rather than lowering them. Face ID or passcode lock, FileVault-equivalent encryption, and an organisation-wide remote-wipe policy are still the right baseline.
And it does not replace a conversation with your own counsel. Anything in this post is a description of a pattern, not a legal conclusion about your specific matter. A compliance decision about whether a given meeting can be recorded, where the resulting data can live, and for how long, is a legal question that needs a qualified professional with access to your specific facts.
For a practical walk-through of what on-device recording actually looks like in a meeting workflow, see Record iPhone meetings privately. For the architectural comparison between on-device and cloud transcription, Apple Intelligence vs cloud AI for meeting notes covers the pipeline side of the same question.