The moment captions appear on screen, personal data is being processed. Six questions to put to any vendor, and why the answer "nothing is stored" changes the whole analysis.
An EU organisation adding live captioning is doing something unambiguous under the GDPR: processing personal data. A voice belongs to an identifiable person. A transcript records what identifiable people said — names, opinions, sometimes health details that surface mid-meeting without warning. None of this makes captioning risky by nature; captioning is often deployed precisely to serve accessibility and inclusion. It means the vendor behind the captions is processing personal data on your behalf, and you are accountable for knowing exactly what they do with it. Six questions cover nearly all of it. This is practical orientation, not legal advice — bring your DPO in early.
Two data flows exist in every live captioning session. The audio — people's voices, captured and sent to a recognition engine. And the transcript — a written record of what identifiable individuals said, generated in real time. Both relate to identifiable people, so both are personal data; the GDPR applies regardless of whether anything is saved afterwards, because processing includes the transient handling itself.
The content compounds it. Meetings wander: a colleague mentions a medical appointment, a customer names another person, an HR discussion touches the exact categories the regulation treats as special. A captioning pipeline cannot know in advance that a sensitive sentence is coming — so the sensible posture is to choose a pipeline whose handling you would accept for the most sensitive sentence likely to cross it.
Your organisation chooses the basis (legitimate interests for internal meetings, consent in some contexts, and so on) — but the tool must not undermine it. A tool that quietly retains or reuses data can invalidate an analysis built on minimal processing. Ask the vendor what processing actually occurs, in writing.
The data-minimisation question, and the single most important one. Is audio stored at all — even transiently on disk? Do transcripts persist after the session? Are there backups, logs, or caches containing content? "We delete on request" and "we never keep it" are very different answers.
Which countries do audio and transcripts transit and rest in? If processing leaves the EU/EEA, what transfer mechanism covers it? Your DPO will need the storage and processing locations named, not gestured at.
For organisational use the vendor should act as your processor, under a data processing agreement covering instructions, sub-processors, security measures, and breach notification. A vendor that treats meeting content as its own data to use is a different — and worse — arrangement.
Training on customer content is further processing for the vendor's own purposes, and it stretches or breaks the processor relationship. The clean answer is a flat no, stated in the terms — not an opt-out buried in settings.
If content is retained at all, you need deletion mechanics that support data-subject rights: scope, timelines, backups included or not. An architecture that deletes everything at session end answers this question before it is asked.
Most GDPR effort around a new tool goes into governing data at rest: retention schedules, access controls, subject-access handling, deletion verification, breach exposure. An architecture that stores nothing removes the "at rest" category almost entirely — audio streams through recognition and is gone; the transcript exists for the session and is deleted when it ends.
The trade-off is real and worth stating: nothing stored means no meeting archive, no searchable history, no minutes generated from last month's calls. For live comprehension — accessibility, multilingual meetings, interpreted encounters — that trade is usually exactly right; if you separately need an archive, treat that as a second, deliberately-governed processing activity rather than a captioning default.
If this checklist feels familiar, it should. US healthcare organisations run the same analysis under HIPAA — who is the vendor to us legally, what do they retain, where does audio go, is content reused — with different statutes and the business-associate agreement in place of the DPA. We wrote the healthcare version in our HIPAA-compliant live captioning guide, and the two make a useful pair: a vendor with good answers to both has privacy in its architecture rather than its marketing.
The parallel holds down to the punchline: in both regimes, the architecture that stores nothing is dramatically easier to defend than the one that stores everything and promises to be careful. For EU health settings specifically — where both instincts apply — see telehealth live captioning and translation.
Unicaption was built on the nothing-stored side of this analysis, and answers the six questions directly:
For the meeting-platform mechanics, see live translated captions for Zoom, Teams, and Meet. And for anything contractual — DPA terms, processing locations for your assessment — ask us directly at hello@unicaption.com; written answers are what your DPO needs anyway.
None of the above replaces your organisation's own assessment. What it does is make the DPO conversation fast: arrive with the vendor's written answers to the six questions, the categories of meetings you intend to caption, and your proposed lawful basis, and the review becomes an afternoon instead of a quarter. If captioning will touch high-risk contexts — patient conversations, employee disciplinary meetings — expect your DPO to consider whether a data protection impact assessment is warranted, and let them make that call.
The encouraging conclusion: live captioning is one of the easier tools to bring through GDPR review well — the processing purpose is clear and sympathetic, the data flow is simple, and nothing-stored architectures exist. Choose one, document the answers, and captions stop being a compliance question at all.
It can be — GDPR compliance depends on the specific tool's architecture and the way you deploy it, not on the category. The checks that matter: what the vendor retains (audio and transcripts), where processing happens, whether the vendor acts as your processor under a DPA, whether content is used for model training, and how deletion works. Unicaption is GDPR compliant with a nothing-stored design: audio is never stored, transcripts are deleted at session end, and content is never used for training.
Yes. A voice belongs to an identifiable person, and a transcript records what identifiable people said — names, opinions, and sometimes special-category details that surface mid-conversation. The GDPR applies even when nothing is saved afterwards, because transient handling is still processing. That is why the vendor behind a captioning tool should be assessed as a data processor receiving live audio, not as a cosmetic meeting feature.
Six things, in writing: what processing occurs and on what lawful basis it can rest; what is retained and for how long; where audio and transcripts are processed and stored; whether the vendor signs a data processing agreement as your processor; whether session content trains models; and how deletion works. A vendor that stores nothing — Unicaption deletes transcripts at session end and never stores audio — gives the shortest defensible answers to all six.
Not necessarily — consent is one lawful basis among several, and many organisations rest internal captioning on legitimate interests, particularly for accessibility. Which basis fits depends on the context, the participants, and what the tool actually does with the data, which is why a nothing-stored tool makes the analysis easier. This is practical orientation, not legal advice: your DPO should choose the basis and the participant-notice approach.
GDPR compliant, end-to-end encrypted, audio never stored, transcripts deleted at session end. 30 free minutes every week — no credit card.
Start Free Trial →