Why EU Teams Need a European Loom Alternative

The compliance gap in async video

Async video has quietly become infrastructure for remote teams. Product managers record walkthroughs instead of writing specs. Engineers attach screen recordings to bug reports. New hires get onboarded through video libraries instead of shadowing sessions. If your team works across time zones, you probably send more video messages in a week than you realize.

The tooling for this has converged on a handful of platforms: Loom, Vidyard, Screencastify, and a few others. They work well. The recording experience is polished, sharing is frictionless, and the integrations cover the usual suspects — Slack, Notion, Linear, Jira.

There is one problem. Nearly all of them are US-based companies, storing recordings on US-controlled infrastructure. For teams operating entirely within the EU, or handling EU customer data, this creates a compliance gap that most people do not think about until their Data Protection Officer flags it.

It usually surfaces during a vendor review or an internal audit. Someone asks where the video data actually lives, who can access it, and under what legal framework. The answers are rarely satisfying. And the deeper you look, the worse it gets — because video is not just “data.” Under EU law, it is a very specific and sensitive category of data.

Video is biometric data under GDPR

Most people think of GDPR compliance in terms of cookies, email consent, and data deletion requests. But the regulation covers something far more consequential for video tools: biometric data.

Article 4(14) of the GDPR defines biometric data as “personal data resulting from specific technical processing relating to the physical, physiological or behavioural characteristics of a natural person, which allow or confirm the unique identification of that natural person, such as facial images or dactyloscopic data.”

A video recording of someone’s face is biometric data. A recording of their voice can be too, depending on how it is processed. This is not an edge case or a creative legal interpretation — it is the plain text of the regulation.

Article 9 classifies biometric data (when used for uniquely identifying a natural person) as a special category of personal data. Processing special category data is prohibited by default unless one of a limited set of exceptions applies. The most common exception is explicit consent — and “explicit” means more than a buried checkbox in a terms-of-service page.

This matters because most async video tools process face and voice data as a core function. Some use it for speaker identification, thumbnail generation, or AI-powered transcription. Their privacy policies typically describe this processing in generic terms, without acknowledging the biometric data classification or establishing the explicit legal basis that Article 9 requires.

If you are an EU company recording internal communications — standups, design reviews, engineering walkthroughs — every video with a person’s face in it is special category data under GDPR. Your legal basis for processing it, and your choice of processor, needs to hold up to scrutiny.

The Schrems II problem

Even if a video tool claims to store data “in the EU,” the jurisdictional question is more complicated than picking a data center region.

In July 2020, the Court of Justice of the European Union issued its ruling in Schrems II (Case C-311/18), invalidating the EU-US Privacy Shield framework. The court found that US surveillance law — specifically Section 702 of FISA and Executive Order 12333 — provided insufficient protection for EU personal data transferred to the United States.

The practical consequence is that transferring personal data to a US company requires additional safeguards beyond what Privacy Shield offered. But the Schrems II ruling also affects data that never physically leaves the EU, because of a separate piece of US legislation.

The US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) compels US-headquartered companies to produce data in response to US government requests, regardless of where that data is physically stored. If your video recordings sit on AWS eu-west-1 but the service provider is a US corporation, the data is still subject to US government access under the CLOUD Act.

Selecting “EU region” in a US cloud provider’s dashboard does not solve the jurisdictional problem. The legal exposure follows the corporate entity, not the server rack.

The EU-US Data Privacy Framework, adopted in 2023, attempts to bridge this gap again. But it faces the same structural challenge as its predecessors: US surveillance law has not fundamentally changed. Privacy advocates, including Max Schrems’ organization noyb, have signaled that legal challenges are likely. Several EU data protection authorities — including those in Austria, France, and Italy — have already ruled against specific US-based tools for insufficient transfer protections.

For a company processing biometric data of EU employees and customers, relying on a legal framework with a track record of being invalidated is a meaningful risk.

What a real EU solution requires

If you are evaluating video tools for an EU team and want to genuinely address these compliance issues, there is a concrete set of requirements to check against. This is not about ideology — it is about reducing legal exposure.

EU-owned infrastructure. The entity operating the servers must be incorporated in the EU, subject to EU law, and outside the jurisdictional reach of the US CLOUD Act. This rules out AWS, GCP, and Azure as primary infrastructure — even their EU regions — unless the service provider itself is an EU company that has built its own abstraction layer with appropriate contractual protections.

Open-source code. When a tool processes biometric data, “trust us” is not an adequate security posture. Open-source allows your security team to audit what actually happens to recordings: how they are stored, who can access them, whether they are used for AI training, and how deletion works. Transparency is not a feature — it is a prerequisite for informed consent.

Self-hostable deployment. For organizations with strict data residency requirements — government contractors, healthcare, financial services, or companies operating in regulated industries — the only way to guarantee data sovereignty is to run the infrastructure yourself. A self-hostable option should not be an afterthought requiring enterprise sales calls. It should be a documented, maintained deployment path.

GDPR-compliant by architecture. Compliance should be a property of the system design, not a policy document bolted on after the fact. This means:

• Data minimization: do not collect or retain data beyond what is necessary for the stated purpose
• Hard-delete pipelines: when a user requests deletion, the data is actually removed from all storage layers — not soft-deleted and retained for 90 days
• Consent management built into the recording and sharing flow
• No third-party tracking scripts, no external CDN dependencies that leak referrer headers, no analytics services that create their own compliance obligations

No vendor lock-in on your data. You should be able to export every recording, every piece of metadata, in standard formats, at any time. Your compliance posture should not depend on a vendor’s continued cooperation.

This is a checklist, not a wishlist. Every item on it is technically achievable today. The reason most video tools do not meet these requirements is that compliance was not a design constraint — it was a sales objection to be handled.

What we are building

We started SendRec because we needed this tool ourselves and it did not exist.

SendRec is an open-source async video messaging platform, built from the ground up for EU data sovereignty. The core technical decisions reflect the requirements above:

• Infrastructure: Hetzner (German-owned and operated) for compute and storage, BunnyCDN (Slovenian) for delivery. No US-owned cloud providers in the data path.
• Stack: Go backend, React frontend, S3-compatible object storage. Standard, well-understood components — no proprietary lock-in.
• Self-hostable: Helm charts and Docker Compose for teams that need full control over their deployment. This is a first-class deployment path, not an afterthought.
• License: Open-source core under AGPLv3. Read the code, audit the code, contribute to the code.

SendRec is in early development. We are building in public and prioritizing the compliance architecture before the feature list. If the problem described in this post matches what your team is dealing with, you can follow the project on GitHub or join the waitlist at sendrec.eu.