Every AI meeting assistant has to turn audio into text before it can do anything useful. That single step, transcription, is where most of the data-sovereignty risk lives, and it is the step almost no product page talks about. The question that decides whether your recordings stay in Europe is simple: when the audio gets converted to text, where does that happen, and on whose infrastructure?
There are two answers. Either the model runs on a server the provider controls, or the audio is shipped to a third-party cloud transcription API. The first can be sovereign. The second usually is not. Here is the difference, why it matters for an EU team, and what to look for.
Self-hosted meeting transcription runs the speech-to-text model on infrastructure the provider controls, rather than sending your audio to an external cloud transcription API. The recording is converted to text inside that environment and the audio never leaves it. When the infrastructure sits in the EU, the audio stays in EU jurisdiction from capture to transcript.
How most notetakers actually transcribe your meetings
The typical AI notetaker does not run its own speech recognition. It calls a cloud transcription API, sends the meeting audio to that provider, and gets text back. The big names in that market are almost all US companies, and their processing runs on US infrastructure or on US-owned cloud regions.
That is a real transfer. Your meeting audio, which frequently contains client names, contract terms, salaries, health details, and other special-category or commercially sensitive content, leaves the EU to be processed and comes back as text. For a European customer, the legal cover for that trip is a transfer mechanism such as the EU-US Data Privacy Framework plus Standard Contractual Clauses, not residency. The data went out; a contract governs what happens to it while it is out.
This is exactly the pattern we traced through individual tools when we looked at where Otter.ai sends your meeting data and whether Fireflies is GDPR-compliant. The mechanics differ by vendor, but the audio path leaving the EU for transcription is the common thread.
What self-hosting changes
Self-hosting the transcription model removes that trip. The model runs on a server the provider operates. Audio arrives, gets converted to text on that machine, and the transcript stays in the same environment. There is no third-party transcription API in the loop, so there is no transfer to legitimise. If the server is in Frankfurt, the audio is processed in Frankfurt.
The models that make this possible are open-weight. Speech recognition models such as Whisper and speaker-diarization models such as pyannote are published under permissive licences, which means you can download the weights and run them on your own hardware. That is the whole trick: you are not renting access to someone's hosted model, you are running the model itself, in a place you choose.
Origin versus control: the point people get wrong
A common objection is that Whisper was released by a US company, so how can running it be sovereign? The answer is that sovereignty is about where your data is processed, not where the model was born.
When you download open weights and run them on an EU server, no audio is ever sent back to the organisation that trained the model. The model is just a file of numbers doing maths on your machine. Compare that with a hosted US transcription API, where the audio genuinely travels to the vendor. The origin of the model is irrelevant to your data path; the location of the compute is everything.
Sovereignty means control, not origin. A US-authored open-weight model running on an EU server keeps your audio in the EU. A hosted transcription API from a European-sounding brand can still ship your audio to the US. What decides residency is where the compute happens, not the flag on the model's birth certificate.
This is the same reasoning we apply across our data path, and it is why we are careful about the word sovereign. We wrote about the honest version of these claims, including where the harder questions sit, in our work on the GDPR-compliant AI meeting assistant comparison.
Why the transcription layer is the one to get right
Audio is the rawest form of the data. A transcript can be redacted after the fact; the recording cannot be un-sent. If the audio leaves the EU to be transcribed, every downstream promise about where the text lives is answering a smaller question than the one that already got answered at the microphone.
It is also the highest-volume flow. A notetaker sitting in every meeting transcribes hours of conversation a day. If each of those hours is streamed to a US API, the exposure is continuous, not occasional. Getting transcription right is not a nice-to-have detail; it is the load-bearing wall of a sovereign meeting stack.
Self-host it yourself, or use a provider that self-hosts for you
Once you accept that transcription should run on EU infrastructure, there are two ways to get there.
Running your own stack
You can do it yourself. It means provisioning GPUs, deploying and maintaining the speech-recognition and diarization models, tuning for the languages your team actually speaks, handling load and availability, and keeping the whole thing patched. It is entirely doable, and for organisations with strict on-premise mandates it is sometimes the only acceptable answer. It is also real infrastructure work that most sales and revenue teams do not want to own.
Using a managed EU provider
The middle path is a provider that self-hosts the transcription for you, inside the EU, and gives you the residency guarantee without the operational burden. You get the sovereignty property, they run the servers. The thing to verify is that the provider genuinely self-hosts the model rather than quietly reselling a US transcription API behind a European-looking front end. Ask them directly: where is the audio transcribed, and does any third party receive it?
How Numi handles transcription
Numi runs self-hosted transcription on EU servers in Frankfurt. Meeting audio is converted to text by open-weight speech-recognition and speaker-diarization models that run on our own infrastructure, not by an external transcription API. The audio stays in the EU for the part of the pipeline where it matters most: no US processor sits in the transcription path, and nothing about your meetings is used to train a model.
From there the transcript feeds the parts of the product our customers actually came for, the coaching, the scorecards, the talk-to-listen and objection-handling analysis, all built on top of a transcript that was produced in Europe. You can see how the pieces connect on the meeting assistant page and how the bot joins your calls through our integrations.
If you are earlier in the question and still mapping where different tools send data, the hidden cost of free AI notetakers is a good next read, and the case for AI meeting assistants sets out why the category is worth getting right in the first place.