There is no GDPR compliance badge that a dictation app can earn once and display forever. Start with the data path: what leaves the Mac, which entity receives it, and what that entity is allowed to do. Then classify each processing activity by who determines its purposes and essential means. A cloud recipient is a processor only when it acts on a controller's behalf and under that controller's instructions. It may instead be a separate or joint controller. [1] [4] That distinction decides whether Article 28's processor-contract rules apply. [2]
The two roles GDPR assigns
The GDPR allocates responsibility through two definitions. A controller is the natural or legal person that determines the purposes and means of the processing. [1] A processor is a separate entity that processes personal data on behalf of the controller. [1] Dictated audio will often contain personal data about the speaker, clients, patients, employees or other identifiable people. The classification still attaches to a specific processing activity, not to an app or company forever. [4] [5]
The Information Commissioner's Office puts the dividing line in one question: who determines the purposes for which the data are processed and the means of processing? [4] If you decide what to process and why, you are the controller. If you only act on a client's instructions and have no purpose of your own, you are likely to be a processor. [4]
The EDPB adds two cautions that matter here. First, not every service provider handling personal data is a processor; the role depends on its concrete activities and must be assessed case by case. [5] Second, a processor that goes beyond instructions and determines its own purposes and means becomes a controller for that processing. [2] [5] A provider using dictated content for its own model training therefore cannot be waved through as "just a processor" without examining the contract and the facts. The table below summarises the two roles. [4] [2] [3]
| Role | Who decides | Main obligations |
|---|---|---|
| Controller | Purposes and means: what data is processed and why | Comply with and demonstrate compliance with the data protection principles; responsible for the compliance of processors |
| Processor | Nothing beyond the controller's documented instructions | Contract under Article 28; confidentiality; security under Article 32; subprocessor authorisation; deletion or return on termination; audit |
Three processing models
Once the vocabulary is in place, the question becomes practical: which model does the app actually use? There are three, and the GDPR answer differs for each.
Entirely on-device. Audio is captured, transcribed and cleaned up on the Mac. If the vendor cannot access dictated content, there is no external processor for that stage and no Article 28 contract is needed for that stage. Your organisation may still be the controller of what staff dictate, and the vendor may have a separate role for licensing, support or website data.
Bring your own key (BYOK). You supply an API key and the app sends audio or text directly to the provider you chose. That makes the route visible, but it does not make the provider a processor by itself. Check whether the service agreement and DPA cover your account, whether the provider acts only on your instructions, and whether it uses any data for its own purposes. Also verify that the app vendor really is absent from the dictated-content path.
Vendor cloud. The app vendor routes audio through its own servers or other providers. The vendor may be your processor, a separate controller, or a controller for one purpose and a processor for another. The name in the privacy policy does not settle it. If the vendor is a processor, you need an Article 28 contract covering the chain. [2] [4] [5]
The EDPB's virtual voice assistant guidelines make the same point at the ecosystem level: multiple actors can be involved in a voice pipeline, and their roles are assessed case by case rather than assumed from a contract label. [6] The EDPB considers a DPIA very likely for virtual voice assistant services. That does not make every dictation tool a virtual voice assistant, but it is a warning against treating voice processing as low risk by default. [6]
Apple's own dictation is a useful illustration of how configurable this can be. Apple's privacy page says your device indicates in Keyboard Settings whether your audio and transcripts are processed on device or sent to Apple servers; server-processed dictation is not stored unless you opt in to Improve Siri and Dictation. [7] It also says that if you allow apps to use Speech Recognition for transcription, the audio to be transcribed may be sent to Apple. [7] In other words, the same operating system can be on-device or cloud depending on settings and on which app is doing the transcribing.
Apple's newer frameworks sit firmly on the device. SpeechAnalyzer manages a speech-to-text analysis session, and the SpeechTranscriber module that powers it ships as a model Apple describes as operating entirely on-device. [8] [9] In the WWDC25 session introducing it, Apple says the new model powers Notes, Voice Memos and Journal, and that it manages model assets on the user's device. [9] The older SFSpeechRecognizer API, by contrast, could use Apple servers on resource-constrained devices. [9] The lesson is that a single vendor can offer both paths, so the routing question has to be asked per app and per setting, never assumed from the platform name.
What Article 28 requires when a recipient is a processor
Once a recipient has been correctly classified as a processor, its relationship with the controller cannot rest on goodwill. Article 28(3) lists what the contract must cover:
- subject matter and duration of the processing, its nature and purpose, the type of personal data and the categories of data subjects; [2]
- documented instructions from the controller, including about transfers to third countries; [2]
- confidentiality obligations on everyone authorised to process; [2]
- all measures required by Article 32, which includes pseudonymisation and encryption as appropriate security measures; [2] [3]
- the conditions for engaging another processor; [2]
- assistance with data subject rights and with Articles 32 to 36 compliance; [2]
- deletion or return of all personal data at the controller's choice when the service ends; [2]
- making available the information needed to demonstrate compliance and allowing audits. [2]
The contract must be in writing, including electronic form. [2] Subprocessors sit in the same chain: a processor may only engage another processor with the controller's specific or general written authorisation, and the first processor remains fully liable for the subprocessor's failures. [2]
Two provider documents show why the document type and contractual scope matter.
OpenAI's Data Processing Addendum, effective 1 January 2026, is a useful example of an Article 28 instrument, but only within its stated scope. It supplements the OpenAI Services Agreement for the customer using those services. For customer data covered by that agreement, OpenAI says it acts as processor and follows the customer's documented instructions. [10] The DPA provides general authorisation for listed subprocessors with an objection route, return or deletion on termination, and transfer terms for EEA, Swiss and UK data. [10] A BYOK screen inside another app does not prove that this DPA covers your particular provider account. Check the agreement you actually accepted.
DeepSeek's public privacy policy shows why a privacy page cannot substitute for the contract. It describes DeepSeek as controller for the consumer services covered by that policy, then says processing in downstream applications built on its open platform is outside the policy and that the application developer is controller for that activity. [11] It does not, by itself, establish whether DeepSeek is that developer's processor or what terms govern an API request. A vendor relying on it must supply the missing contract and chain rather than asking you to infer them.
How to verify a vendor's claims
Marketing pages use "local", "private" and "GDPR compliant" loosely. Treat each claim as a hypothesis and verify it in six steps.
- Find the routing statement. Look for an explicit sentence about where audio and transcripts go. If the page only says "encrypted" or "secure", that describes transport, not destination. Apple's page is a model of clarity here: it names Keyboard Settings as the place where the routing decision is shown. [7]
- Separate "local", "zero retention" and "not used for training". These are three different properties and they do not imply each other. Wispr Flow is a worked example: its own documentation says transcription always occurs on the cloud, that zero data retention requires Privacy Mode enabled AND Private Cloud Sync disabled, and that without Privacy Mode your dictation data may be used to evaluate, train and improve models. [12] That is a precise, checkable statement of a config-dependent position, and it is exactly what to ask for from any vendor.
- Classify each recipient and ask for the governing terms. If audio leaves the device, identify every recipient and ask whether it acts as processor, separate controller or joint controller for that activity. If it is a processor, ask for the Article 28 contract. If the vendor cannot explain the role and point to the governing terms, do not fill the gap yourself.
- Check the subprocessor list and the objection mechanism. Article 28(2) requires authorisation for subprocessors, and a DPA should name them or give you a way to see them and object. [2] OpenAI publishes a list and an objection route. [10]
- Check retention, deletion and termination terms. Article 28(3)(g) requires deletion or return at the controller's choice when the service ends. [2] Confirm what happens to your transcripts and audio, not just during the subscription but after it.
- Check defaults, not just optional modes. A privacy mode you must find and switch on is not the same as a privacy default. Wispr's own page shows how much depends on two settings being in the right state. [12] Ask what the out-of-the-box configuration sends where, and what happens after an update changes it.
Questions to ask before choosing or continuing
Run this checklist against any dictation app, including one you already use:
- Where does my audio go in the default configuration?
- What is each recipient's role for that stage: processor, separate controller or joint controller?
- Where a recipient is a processor, is there a binding data processing agreement and does it cover subprocessors?
- What is retained, for how long, and what happens on termination?
- Is training on my audio possible, and is it controlled by a setting or by the contract?
- Does the vendor's privacy page answer these questions, or only promise to be "secure"?
If you want to remove an external provider from the dictated-content stage, on-device processing is the clearest route. ShoutFlow is one implementation of that approach. In local mode, its current public policy says WhisperKit transcription and MLX clean-up run on the Mac, while operational requests to ShoutFlow carry no audio, transcribed text or prompts. [13] That removes ShoutFlow's servers from the dictated-content path. It does not remove your organisation's duties as controller, or Recurse LTD's separate responsibilities for trial, licensing, purchase and support data. In BYOK mode, the Mac sends the selected stage directly to the chosen provider, whose role and terms still need checking. [13] The current public offer requires macOS 14 or later on Apple Silicon and is sold as a one-off purchase. [14]
What GDPR does not answer
Nothing in this article is legal advice, and several decisions sit outside the controller/processor question. You still need a lawful basis for processing the audio (consent, contract, legitimate interests or another basis under Article 6), a DPIA where processing is high risk, and records of processing if you are a controller. [6] Whether a voice recording is biometric data, and the special-category rules that would trigger, is a separate analysis that depends on the facts. [6] If you dictate client or patient material, take the routing question to your DPO or a solicitor before you choose a tool. The framework here tells you which questions to ask; it does not tell you the answers for your organisation.
Run the checklist. The answer is in the settings and the contract, not the marketing page.