A 2026 builder's guide reflects the law as at September 2026. This is guidance, not legal advice. Sources are cited throughout so you can follow the reasoning, but national law moves, official translations lag behind it, and how any of it lands depends on facts specific to your deployment. Each country row in the appendices carries a confidence rating for that reason: read it as a guide to how soon to confirm that row with your own advisers, never as a substitute for doing so.
Table of contents
Every video product is becoming an AI product. Live transcription, meeting summaries, real-time translation, note-taking assistants and generative avatars were research demos two years ago. Now they ship as standard. If you build or embed video, you're almost certainly adding at least one of them this year.
The rules didn't wait for you to catch up. The transparency obligations of the EU AI Act have applied since 2 August 2026, and some AI uses, like inferring emotions in a workplace or an education setting, have been prohibited outright since 2 February 2025 (Future of Privacy Forum). And because the AI Act is an EU Regulation, it reaches you the moment your output is used by someone in the EU, wherever your company is incorporated (Article 2, EU AI Act).
Here's the uncomfortable part: the obligation usually lands on the builder, not the model vendor. If you add a chatbot, a synthetic voice or an avatar to your product, you're often the one who has to disclose it, label it, or in some cases not ship it at all.
One distinction is worth flagging before you read any further, because it changes who owes what. The AI Act's duties attach to a role, not just to 'the builder'. Ship a feature under your own brand and you're very likely its provider, carrying the heaviest duties. Use someone else's AI system to run your own business, without modifying or rebranding it, and you're a deployer, with lighter but still real duties. Most embedders end up as both at once: a deployer of the vendor's underlying system, and the provider of the branded feature they ship to their own customers, who then become deployers in turn. Work out which hat applies to each feature before you rely on any 'you' in the chapters that follow.
This guide is written for the person making that call: the CTO, the founding engineer, the product lead embedding video into a real product. It separates the AI features that are genuinely low-risk from the handful that carry hard obligations or bans, feature by feature, and it shows what 'compliant' actually requires in practice, so you can design it in from the start rather than retrofit it under a deadline.
It's not legal advice. It's a working map (built from the AI Act text and current guidance) of what really applies to real-time video, and what doesn't.
No. There is one AI law, applied across all 27 member states. Teams entering the EU market often assume that 'AI compliance in Europe' means reconciling 27 national rulebooks. For the AI Act itself, it doesn't. The EU AI Act is a Regulation, not a Directive, so it applies directly and uniformly in every member state without national transposition (European Commission). Spain, Germany and Ireland read from the same text.
What this changes for you is simple: the core question, 'does my AI feature trigger an obligation?', has the same answer across the EU. You don't need 27 analyses. You need one, done well.
Three things, and none of them is the AI Act itself:
So here's the honest cross-border model: one AI Act analysis, plus a national layer for consent and data handling that is real work, not an afterthought. Recording consent and workplace-monitoring rules vary enough, country by country, that the two appendices at the end of this guide set them out country by country. The local ePrivacy transposition varies too, and you'll need to check that separately. It's still one AI Act analysis, though, not 27 of them.
The other thing to get straight is the timing. Not everything landed at once on 2 August 2026:
What took effect on 2 August 2026 was transparency, not the full high-risk regime. If your roadmap includes synthetic media or conversational AI, that's your immediate work. If it includes emotion or biometric features, the question isn't 'when': parts of it are already banned.
The rest of this guide takes each AI feature you might add to a video product and places it on that map.
The AI Act doesn't regulate 'AI' as one thing: it regulates specific uses, by the risk they pose. For a video product, that sorts the features you might add into five bands, running from 'ship it, no special step' to 'don't build this'. Below is each band, the obligation that attaches, and the practical action to take.
Noise suppression, background blur and virtual backgrounds, auto-framing and appearance touch-up carry no specific AI Act obligation. They don't generate content presented as real, act as an agent towards the user, or infer emotion or identity. Your only duty is the ordinary one: this processing sits under the same lawful basis and privacy notice as the call itself.
Two edges are worth watching, and they run along different axes. The first is likeness: appearance filters that heavily alter how a person looks can, in principle, drift towards the synthetic-content rules in Tier 4 if the result could be mistaken for reality. Ordinary beautification doesn't cross that line.
The second is place, which the synthetic-media rules cover less obviously: they read as though they're only about people. A virtual background stays in Tier 1 while it's a blur, a palm-tree beach or a generic office: nobody is deceived by any of those. A photorealistic backdrop that a viewer would plausibly take for where you actually are is a different proposition, and it belongs in Tier 4. That band explains why, and who owes what.
Transcription, live captions, per-participant speaker attribution and text translation convert or carry across what was said without changing its meaning. That's a faithful reproduction, not generated synthetic media, so Article 50's marking rules don't apply. The real work here is GDPR. Recording and transcribing a conversation is processing personal data: you need a lawful basis, a clear notice before capture, data minimisation and a retention limit. Attributing speech to a named participant raises identifiability, so control who can read transcripts by role. Where the conversation is sensitive (health in telehealth, legal matters, therapy), you're handling special-category data under Article 9, which typically means explicit consent and a data-protection impact assessment.
Meeting summaries sit a step apart, and it's worth treating them separately. A summary isn't a reproduction of the call: it's new text, generated by selecting, reordering and condensing what was said, which is a different thing from transcribing it. The better reading is that Article 50(2)'s marking duty is aimed at synthetic media, not at minutes of a meeting, and nothing about a summary changes who said what or invents anything that wasn't said. But no regulator guidance has confirmed this either way, so treat it as an open question rather than a settled one. Marking a summary as AI-generated costs almost nothing and puts the question beyond argument, so if you ship summaries, mark them and move on.
This is the band most video products live in, and it's entirely workable. It sits inside your existing privacy programme rather than becoming a labelling exercise.
The moment an AI speaks to a user, Article 50(1) applies: you must inform people they're interacting with an AI system, unless it's already obvious (EU AI Act, Article 50). That covers an in-call chatbot or assistant, a 'companion' that answers questions, and an AI note-taker that joins the meeting. The note-taker carries a second duty: it's recording, so the national recording-consent rules in Appendix A apply, and the disclosure must happen before capture. Agentic features that act on the meeting (creating tickets, scheduling follow-ups) need the same interaction disclosure, and where an automated action significantly affects someone, a human should stay in the loop. In engineering terms the obligation is light: a visible, honest 'you are talking to AI', and a real consent step.
One trap doesn't sort by technique the way the tiers do, so it needs calling out separately: if a feature's output helps make an employment decision, screening a candidate, scoring an interview, rating a worker's performance, it's high-risk under Annex III of the AI Act regardless of which tier it would otherwise sit in, and those obligations apply from 2 December 2027. An AI note-taker that also scores 'engagement' or feeds a productivity rating isn't just Tier 3 any more. Treat 'this analyses a person for a hiring or workplace decision' as its own trigger, separate from emotion or biometric use.
Article 50 covers anything that generates a person or their voice: AI avatars, voice cloning, speech-to-speech translation with a synthetic voice, real-time dubbing with lip-sync, digital twins that attend for you, deepfakes and face-swaps. It also covers synthetic places: the definition reaches objects, places, entities and events, not only people, provided the result would falsely appear authentic. That's why the fake-location case from Tier 1 lands here. Commission guidance puts clearly unrealistic content outside the definition, so a cartoon backdrop is plainly outside it. The test isn't whether the image shows somewhere real, because most stock backdrops do: it's whether a viewer would take it for where you actually are. A beach nobody believes you're sitting on stays outside. A bank branch you could plausibly be sitting in doesn't.
Providers of the generative system must mark the output as artificially generated in a machine-readable form. In practice, that means embedding provenance metadata such as C2PA Content Credentials, often alongside IPTC metadata fields, the approach the European Commission's Code of Practice on transparency points to, though the Act itself doesn't name a specific standard. Deployers, separately, must disclose deepfakes to the people who see them. Marking has applied to new systems since 2 August 2026; systems already on the market were given until 2 December 2026 (DLA Piper). GDPR adds a consent dimension: you're reproducing someone's face or voice, which is their personal data, and biometric special-category data if it's used to identify them, so you need the represented person's permission, not only the label. The short version: generate it, mark it, disclose it, and get consent from whoever's being synthesised.
Who owes what is worth separating, because the two duties fall in different places. The deployer, meaning whoever actually uses the feature on a given call, owes the disclosure. The provider's machine-readable marking duty carries an exemption for tools that perform an assistive, standard editing function without substantially altering the input or its meaning, and removing a background is usually treated as exactly that sort of routine edit. Replacing it with a real place is arguably not, because it changes what the picture asserts about where the speaker is, and there's no guidance on that point yet. So if you build the feature, treat the marking question as open. If you let your users pick their own backdrop, the disclosure duty is theirs, and your job is to make it possible for them to meet it.
For the obvious abuse case, though, labelling is the least of it. Putting yourself in a bank to persuade a counterparty is fraud whatever the metadata says, and from 10 July 2027 the Anti-Money Laundering Regulation tightens non-face-to-face customer due diligence specifically because video can be manipulated. If your product is used for remote onboarding or identity checks, treat a convincing fake location as a security problem first and a transparency obligation second.
This is the band where features are banned rather than merely regulated. Inferring emotions in a workplace or an education setting is prohibited outright, and has been since 2 February 2025, with only medical or safety exceptions (Future of Privacy Forum). So 'sentiment scoring' of employees in a meeting tool, or emotion-based engagement tracking of students, isn't something you make compliant. You don't build it for those contexts. Biometric categorisation that sorts people by sensitive traits (race, religion, political opinion, trade union membership, sexual orientation and similar) is likewise prohibited, with narrow carve-outs for labelling lawfully acquired datasets and for law enforcement, neither of which is likely to apply to a video product. Other biometric uses (emotion recognition outside work and education, identification by face, demographic inference) count as high-risk rather than banned. That's a heavier obligation set, but one the Digital Omnibus has deferred to 2 December 2027 (Jones Walker). For those high-risk uses, and only those, Article 50(3) has since 2 August 2026 also required you to inform anyone exposed to an emotion-recognition or biometric-categorisation system. Disclosure is not a route to running the banned kinds. If the feature reads a body or a face to judge who someone is or how they feel, start by assuming it isn't allowed, and go looking for a narrow exception before you build anything.
The pattern holds together: the low bands ask nothing beyond good privacy hygiene, the middle bands ask for honesty (tell people it's AI, mark what's synthetic), and the top band asks for restraint. Almost every compliant AI video product is built by staying in Tiers 1 to 3, adding Tier 4 with proper marking and consent, and treating Tier 5 as off-limits unless a narrow exception genuinely applies. The next chapter goes deeper into the GDPR layer running underneath all five tiers.
For most video products, GDPR is the larger, more certain obligation. The AI Act sits on top of it; it doesn't replace it. Every feature in Chapter 3 that touches a recording, a transcript, a face or a voice is processing personal data, and the same handful of GDPR duties apply regardless of which AI tier the feature sits in.
Start with lawful basis. Recording a call and running AI over it needs a basis under Article 6, usually consent or legitimate interest. Consent is the obvious candidate, and sometimes it's the right one: for a call with customers, prospects or other outside parties, asking and getting a clear yes is often the cleanest route, because participants reasonably expect to be asked. It gets weaker fast inside an employment relationship, though. EU regulators treat consent given by an employee to their employer as inherently shaky, because an employee who's required to attend a work meeting can't meaningfully refuse a request from the person who manages them. For internal, staff-facing recording and AI features, don't lean on consent as your basis: build it on legitimate interest instead, with a documented balancing test you can show on request, or on the contract you have with the employee where the processing is genuinely necessary to it. Whatever basis you choose, name it before capture, not in a buried policy.
Transparency is the duty that actually does the work on most calls (Articles 13 and 14). Whatever lawful basis sits underneath, people still need to know, in plain terms and up front, that AI will transcribe, summarise or otherwise process what they say, and a clear notice matters more in practice than which Article 6 box you ticked. This is where the AI Act's Article 50 disclosures and GDPR's notice obligation meet: a single honest line, 'this call is recorded and processed by AI for X', can satisfy both, if it's specific.
Special-category data (Article 9) is the sharpest edge. Health information in a telehealth consultation, biometric data used to identify a person and anything else revealing a protected trait all need more than ordinary consent: they need explicit consent or another Article 9 condition, and almost always a data-protection impact assessment (DPIA, Article 35). If your product serves regulated verticals, assume Article 9 applies and design for it.
Then there's the trap that catches AI features specifically: secondary use. Using recordings or transcripts to train or improve a model is a new purpose, separate from delivering the call, and it needs its own lawful basis and notice. Purpose limitation and data minimisation (Article 5) mean you can't quietly repurpose meeting data as training data. Summaries and attribution also create new personal data about people, which inherits the same obligations as the source.
Two more things get under-scoped routinely. Data-subject rights (access and erasure in particular) mean recordings, transcripts and their AI-derived artefacts must be findable and deletable on request. If you can't delete a transcript cleanly, you have a problem before you have a feature. And the processor chain: your AI vendor acts as a processor on your behalf, so you need a data-processing agreement, a current sub-processor list, and clarity on where each processing step actually happens.
That last point leads straight into the question certifications don't answer: jurisdiction. Where your AI runs, and whose law can reach it, decides whether 'EU-compliant' is real or just on paper.
A certification tells you a vendor follows a recognised security process. It doesn't tell you which government can compel access to your data. Those are two different questions, and only the second is a sovereignty question. Yet it's the one most vendor comparisons skip.
The distinction that matters is this: data residency is about where data physically sits; data sovereignty is about whose law governs it. Hosting in an EU region of a US-controlled cloud gives you residency (the servers are in Frankfurt or Dublin) but not sovereignty. The operating company remains subject to US law, including the CLOUD Act, which can compel disclosure of data held by US providers regardless of where the servers are (CSIS, 'The CLOUD Act and Transatlantic Trust'). An EU postcode on the data centre doesn't change the jurisdiction of the company holding the keys.
This is why ISO 27001, SOC 2 and HIPAA attestations, useful as they are, don't settle the sovereignty question. They're evidence of security and process maturity: a US-incorporated vendor can hold all three and still be compellable under US law. The certification is real. It simply answers whether a vendor's security is well run, not whose courts can reach the data.
What actually determines the answer is the operational chain: who is incorporated where, which sub-processors sit in the flow, and which court or agency could actually compel one of them to hand over access. This is also where the GDPR point from the last chapter bites: if your AI processing runs on US-controlled infrastructure, you also have an international transfer, and the current transfer frameworks (the Standard Contractual Clauses, or the EU-US Data Privacy Framework) don't remove CLOUD Act exposure. A related guide covers the three layers of video sovereignty in more depth: Digital Samba's guide to EU sovereignty for video infrastructure.
AI features make this sharper. Each one can add its own data flow. A transcription engine, a summarisation model, an avatar service: every AI vendor you add is another link in the chain, and another jurisdiction question. The practical test for any AI-in-video feature is three plain questions: where does the model inference actually run, who operates it, and under whose law? If the honest answer to any of them is 'a US-controlled vendor', residency alone won't make it sovereign.
The same test cuts against EU-incorporated vendors too, not just US-controlled ones. An EU company isn't immune from compelled disclosure: national security and law-enforcement powers exist in every member state, and from 18 August 2026 the EU's own e-Evidence Regulation lets a judicial authority in any member state order a service provider established in another member state to produce or preserve data directly, without the older mutual-legal-assistance route. 'EU jurisdiction' answers the CLOUD Act question specifically. It doesn't mean no government can compel access, only that the government doing the compelling, and the legal safeguards around the request, are EU ones rather than US ones.
None of this means certifications are worthless: you should still want them, for what they attest. It means they're the wrong instrument for the sovereignty question. When your buyers, or your buyers' buyers, require European data sovereignty, the thing to verify is the jurisdiction of the operational chain, end to end, and that's a question you can only answer by asking it of every vendor in the stack, including the AI ones.
Run this before you ship any AI feature into a video product. It turns the previous chapters into a sequence of yes/no checks. Work top to bottom: a 'no' is a task, not something to wave through.
Used honestly, this list is most of the work.
A guide like this is easy to write and harder to live by, so here's where we stand, plainly.
Digital Samba is a European company, incorporated in Barcelona and operated under EU law, and the video runs on European infrastructure. Meetings are served from data centres across Europe, including Germany, the Netherlands and France, with European capacity for scaling. That matters for the jurisdiction question in Chapter 5: we are not an EU region of a US provider. The meeting itself runs on European infrastructure we operate: the media servers, the relays, the recorders and the storage behind them, with no US hyperscaler in the path. European customers can keep meeting content and processing in European locations. Our own back office uses ordinary business tools for billing and customer records; they never touch meeting media, recordings or transcripts. The entity you contract with sits under EU jurisdiction, and the infrastructure behind it is European. As Chapter 5 explains, that changes which government can compel access, not whether one can at all.
On AI specifically, we have deliberately stayed in the low-risk bands. On the device we offer the Tier 1 features: background blur, virtual backgrounds and noise suppression, which run in the participant's own browser. On virtual backgrounds, we ship a stock set and it's deliberately generic: offices, interiors, landscapes and abstracts, with no real, identifiable place among them, so nothing we supply can put a participant somewhere they aren't. Users can also upload their own image, and what that depicts, along with any disclosure it attracts, sits with you. In Tier 2 we offer transcription, live captions and meeting summaries, and we mark our summaries as AI-generated rather than wait for the guidance to settle. We generate no synthetic people or voices, and nothing in Tier 5. The one place we sit near Tier 4 is the background-replacement mechanism itself rather than our stock images, and there the provider-side marking question is genuinely open, so we'll mark if the position settles that way.
The speech features run through a European sub-processor that hosts its own inference in the EU, under our data-processing agreement, so audio and transcripts stay within Europe, and no customer meeting data is used to train or fine-tune any model, ours or a vendor's.
The sub-processor does not retain what it processes: audio and transcripts pass through and are not stored on their side. On our side, whether transcripts and summaries are stored at all is your setting, at account level or per room. Transcription is off until you switch it on, and once you do, storage is on by default, so if you want live captions without a written record you turn storage off. With storage off, no summary can be produced either. Stored transcripts and summaries are encrypted at rest and kept until you delete them, and we give you delete endpoints at both the room and the session level that destroy the text rather than just hiding it. We set no retention period of our own, because that's your decision to make, not ours.
End-to-end encryption and our speech features cannot run at the same time. Transcription, captions and summaries need a decrypted stream, so when end-to-end encryption is on they're refused rather than quietly downgraded, and no audio is forwarded to the transcription service at all. That's the proof our end-to-end encryption is genuinely end to end. The on-device features are unaffected, because they never leave the participant's browser. Our transcripts attribute speech per participant stream, so a speaker's identity is known directly rather than guessed, and where a stream carries more than one voice, such as a shared room device or a phone bridge, it's attributed to that stream.
We also give you pieces to build the controls the earlier chapters call for. For the pre-join notice Appendix A recommends, the notice text and its checkbox label are yours to set through the API, and an in-call indicator runs whenever recording or transcription is active, on every start path including automatic and API-triggered ones. What we don't do is record the answer for you, so if you need to evidence consent per participant, that belongs in your own system, wired up through our webhooks. Access is controlled too: the account owner decides who inside your account can open recordings and download transcripts, and that's restricted to admins by default. And there are webhooks for the events an audit trail needs, including session start and end, participant join and leave, recording start, stop, availability and deletion, and transcript and summary availability.
And we take our own advice. As we add new AI to our own products, we hold ourselves to the same framework this guide describes: disclose the AI, keep the processing in Europe, and retain only what you've asked us to keep. We're not claiming to make you compliant. That's yours to own. What we offer is a video layer that starts you on the right side of the map, with no surprises waiting on it later.
The AI Act is harmonised, so the AI-feature obligations in this guide are identical in every EU country. What varies is the layer outside it. This appendix covers the first half of that layer: whether you may record a conversation at all, and what happens if you share the recording afterwards. Appendix B covers the second half, the workplace rules on deploying recording or monitoring to staff. Both sit on top of the EU-wide GDPR baseline, which needs a lawful basis and a notice before you record.
Three terms, used throughout. One-party means a participant may lawfully record a conversation they're part of. All-party means every participant must agree, and the statute says so directly. Effectively all-party means the practical answer is the same, but it rests on a narrower basis: a civil consent duty, a regulator's guidance, or an inferred reading of a general privacy offence, rather than a criminal rule that flatly requires everyone's consent.
The criminal columns use a short vocabulary. No (non-participants only) means the offence catches someone outside the conversation, a third party intercepting it, but not a participant recording a call they're on. No (civil) and No (civil only) mean the act isn't a crime but is still actionable, usually under personality rights or data-protection law. Conditional means liability turns on facts a court decides case by case. Unconfirmed means no applicable offence could be identified. Not verified means no answer is stated for that row, which is not the same as the answer being no, so treat sharing as its own question everywhere. Cells beginning Only if or Only for carry their own condition: the act is criminal only where that condition is met. A cell can also split by medium, where the answer differs for audio and for video.
The safe default that works everywhere. Capture all-party consent through a pre-join notice, before recording starts. Because 'everyone agreed' is the strictest of the national standards, meeting it satisfies the one-party countries automatically, and it's the simplest thing to build. The detail below tells you where the stakes are higher, not where you can safely do less.
Recording and sharing are two separate questions. Even in a one-party country, where a participant may lawfully record a call they're on, publishing that recording or passing it to someone else is restricted separately and is often a distinct offence. The table has a column for each, so check both before you assume a green light in one covers the other.
Audio and video are covered by different provisions. Several national rules reach only the spoken word, Germany's §201 StGB for example, while images and video sit under separate articles with their own conditions. A video call captures both, so both need checking.
The buckets sort on one question only: whose agreement you need before recording. Whether a participant risks criminal liability is separate, and the two criminal columns answer it, so a country can require everyone's consent while treating a breach as civil rather than criminal.
The criminal columns concern criminal liability only. Even where no criminal offence catches a participant, recording can still be unlawful under GDPR or national data-protection law, and the safe default above applies whatever a row says. Confidence runs High, Med-High, Med, Low. It's our confidence in the position stated, which is a different thing from how much work went into confirming it: a long-settled rule can sit at High without a fresh check. Two rows can describe a similar duty and still carry different ratings, because the rating tracks how settled that country's position is rather than how closely its wording matches another row's. It describes the recording-model column; the two criminal columns say in their own words where they're unconfirmed or unverified, so a row can read High beside a sharing cell that has no answer yet. Eleven rows carry the strongest evidence, being the jurisdictions where a participant's own criminal exposure was the live question and so the costliest to state wrongly: Croatia, Cyprus, France, Germany, Greece, Lithuania, Luxembourg, Portugal, Slovakia, Slovenia and Switzerland. Seven of those rest on the statute text itself. The other four, Switzerland, Portugal, Slovakia and Lithuania, rest on several independent legal sources that agree with each other rather than on consolidated statute text, and they carry an asterisk. For the remaining 21 rows, take the confidence value as a considered view rather than a sourced one, and treat the row as a starting point for your own advisers. Every cell names the instrument it relies on; the sources line below links some of those instruments, and a link there tells you nothing about how well evidenced the row is. No rating here replaces a conversation with your own advisers. Take it as a guide to how soon to have that conversation: at High, confirm the row before you rely on it in a specific case; below High, confirm it before you design around it at all. Start with the rows flagged as residual questions in the 'At a glance' list, which are the ones most likely to move.
| Country | Recording model | Key law | Criminal to record? | Criminal to share? | Confidence |
|---|---|---|---|---|---|
| Germany | All-party (audio only, and only for non-public speech) | §201 StGB (audio); §201a StGB and the Kunsturhebergesetz (KUG) cover video/images, but only in narrow situations | Yes (audio); no (video)1 | Yes2 | High |
| France | All-party (a participant needs the other side's consent, but the law presumes consent if the recording is done openly and nobody who could object does so) | Code pénal Art. 226-1 (capture) and Art. 226-2 (retention, use or sharing) | Only if covert3 | Yes4 | High |
| Switzerland (non-EU) | All-party (no valid consent from anyone on the call means the recording is unlawful) | Art. 179ter StGB (a participant recording without the others' consent); Art. 179bis StGB (a third party recording without any participant's consent, a separate and harsher offence) | Yes, ≤1 yr5 | Yes, ≤1 yr5 | High* |
| Italy | One-party | Art. 615-bis / 617 CP | No (non-participants only) | Only if covertly made26 | High |
| UK (non-EU) | One-party | Investigatory Powers Act 2016 | No (non-participants only) | No (civil only)25 | High |
| Spain | One-party (STC 114/1984) | Código Penal Art. 197 | No (non-participants only)6 | Only if seriously harmful27 | High |
| Netherlands | One-party | Sr Art. 139a/139b | No (non-participants only) | No (civil only)28 | High |
| Poland | One-party | Kodeks karny Art. 267 | No (non-participants only) | No (civil only)29 | High |
| Ireland | One-party | Postal & Telecom Services Act 1983 s.98 | No (non-participants only) | No (civil only)32 | High |
| Austria | Effectively all-party (a civil personality-rights consent duty, not a criminal rule) | §120 StGB | No (civil) | Yes, ≤1 yr33 | Med |
| Belgium | One-party | Art. 314bis Code pénal | No (non-participants only) | Only with intent to harm30 | High |
| Bulgaria | One-party in criminal law; prudent all-party (Constitution Art. 32(2)) | Constitution Art. 32(2); no recording offence in the Criminal Code | No (civil)7 | No (civil only)38 | High |
| Croatia | All-party (a participant needs the other party's authorisation to record; a narrow, court-assessed public-interest exception exists under Art. 143(4)) | Kazneni zakon Art. 143 (recording and sharing of non-public spoken words); Art. 144 covers only image capture in a dwelling or a space specially protected from view, so an ordinary video call falls under Art. 143 | Yes, ≤3 yr8 | Yes, ≤3 yr8 | High |
| Cyprus | All-party (confirmed by 2025-26 Court of Appeal rulings) | Law 92(I)/1996, Arts 2 & 3(1)(a), as amended by 216(I)/2015 and 13(I)/2020 | Yes, ≤10 yr9 | Yes, ≤10 yr9 | High22 |
| Czechia | One-party (Civil Code §88 licence) | Civil Code §§84-90; Criminal Code §180 | No (civil) | Yes10 | High |
| Denmark | One-party | Straffeloven §263(2) | No (non-participants only) | Only for private content35 | High |
| Estonia | One-party (inferred) | Penal Code §137 | No (non-participants only) | Not verified | Med20 |
| Finland | One-party | Criminal Code Ch. 24 §5 (audio), §6 (video) | No (non-participants only) | Only if widely shared37 | High |
| Greece | All-party | Penal Code Art. 370A (Law 4619/2019 codification, as amended by Law 5002/2022) | Yes, felony ≤10 yr11 | Yes, felony ≤10 yr11 | Med-High24 |
| Hungary | Effectively all-party (Civil Code consent duty, covering both making and using a recording) | Civil Code §2:48(1), consent for creating & using a recording | No (civil) | Not verified39 | High |
| Latvia | One-party (inferred) | Criminal Law §144-145 | No (non-participants only) | Not verified | Med40 |
| Lithuania | Effectively all-party: no dedicated recording statute, so the basis is an inferred reading of a general privacy offence rather than a bright-line consent rule | Criminal Code Art. 167 (collection), Art. 168 (sharing or use) | Conditional12 | Yes12 | Med*23 |
| Luxembourg | All-party (consent is presumed if the recording is done openly and known to all participants) | Law of 11 Aug 1982, Art. 2 | Only if covert13 | Yes13 | High |
| Malta | Unresolved (verify locally) | No Cap. 9 provision found; DPA Cap. 586 has no interception clause | Unconfirmed | Not verified | Low19 |
| Portugal | All-party (Art. 199(1)(a) applies even if the words were directed at the recorder; being a participant is expressly no defence) | Código Penal Art. 199 (Art. 197 raises the penalty in aggravating circumstances; Art. 198 requires a private complaint) | Yes14 | Yes14 | High* |
| Romania | One-party (a participant may record where they have a legitimate interest) | Cod Penal Art. 226 | Conditional15 | Yes, ≤2 yr36 | Med-High |
| Slovakia | Effectively all-party (Civil Code §12 personality-rights consent duty) | Civil Code §11-13 (consent to record/use, civil); Criminal Code §377 (a separate, narrower offence, see next columns) | No (civil)16 | Yes16 | High* |
| Slovenia | Effectively all-party in practice: the regulator treats any meeting or call recording as needing every participant's consent, though the criminal code itself is narrower and fact-specific | Criminal Code Art. 137 (audio), Art. 138 (video) | Conditional17 | Yes17 | High |
| Sweden | One-party | Brottsbalken Ch. 4 §9a | No (non-participants only) | Only for listed content31 | High |
| Norway (EEA) | One-party | Straffeloven §205 | No (non-participants only) | Only for private content34 | High |
| Iceland (EEA) | One-party | Penal Code 19/1940 Ch. XXV | No (non-participants only) | Not verified | Med21 |
| Liechtenstein (EEA) | One-party | StGB §120 (sharing criminal under §120(2)) | No (non-participants only) | Yes18 | High |
Several of these notes flag rows whose position is less settled than the rest; those are the rows listed as residual questions above the table.
On the asterisks: the mark is an instruction rather than an adjustment, and the rating shown is untouched, so read those four as one notch below the same rating on a row taken from official statute text. Slovakia deserves particular care: its criminal threshold has three separate elements, so the position is easy to state more strongly than the statute does. Have the current national text checked before you act on it.
Sources: Germany §201 StGB, France Art. 226-2 Code pénal, Switzerland (FDPIC guidance), Italy, Sweden (Brottsbalken 4:9 a §), Belgium (Art. 314bis), Denmark (Straffeloven §263), Liechtenstein (StGB §120), Hungary (Civil Code §2:48), Bulgaria (Criminal Code), Croatia (Kazneni zakon Art. 143-144), Cyprus (Law 92(I)/1996), Portugal (Código Penal Art. 199), Slovenia (KZ-1 Art. 137), Luxembourg (Law of 11 Aug 1982, Art. 2), Greece (Penal Code Art. 370A), Slovakia (Criminal Code 300/2005).
Recording consent answers whether you may capture a conversation. It says nothing about whether you may deploy a recording or monitoring feature to employees in the first place, which is a separate duty owed to a representative body rather than to the people on the call. Individual consent cannot cure it: in the strongest jurisdictions a works council or a statutory bar can stop deployment however freely everyone on the call agreed.
The ladder below and the table share one vocabulary, four levels of deploy-blocking power:
The statutory bars turn on purpose, not on capability. Where a country bars monitoring outright, the prohibition is written around systems meant to track how employees behave or perform, so a recording or transcription feature deployed for meeting notes usually falls outside it. That cuts both ways. Swiss labour guidance names this product category almost exactly, microphones that record employees' conversations and AI that analyses speech patterns, so a customer deploying the feature in order to score staff is inside the bar, and no amount of consent cures that. A consent right such as Croatia's carries no purpose element at all, and applies either way. Germany is where that distinction is easiest to get wrong, because §87(1)(6) reads like a purpose test and is applied as a capability one: the Bundesarbeitsgericht holds that an installation is 'dazu bestimmt' to monitor whenever it is objectively able to collect behaviour or performance data about identifiable employees, and the employer's reason for deploying it doesn't matter (1 ABR 16/23, 16 July 2024). The same court has held that a system needs no recording function at all to be caught.
What that means for a German rollout. Recording, transcription and AI summaries clear that bar comfortably, and Microsoft 365, Teams included, has been treated as falling under §87(1)(6) (Bundesarbeitsgericht, 1 ABR 20/21, 8 March 2022). So where your customer has a works council, a works agreement covering the recording and AI features is the normal route to deployment, and 'we only use it for meeting notes' isn't an argument that keeps you outside the rule. For a company-wide rollout the right sits with the Gesamtbetriebsrat, so that's one group-level agreement rather than one per site.
The rule column names each instrument by its local short form (BetrVG, ArbVG, WOR, MBL, ICER and so on) rather than translating it, so the name matches what your own advisers will search for.
Employee thresholds sit inside the rule column rather than in one of their own, because several countries have more than one: Greece is 50+, or 20+ where there's no union; Luxembourg's co-decision right starts above 150 employees, with information only below that; Hungary's notice duty has no threshold at all, while the council opinion needs a representative at 16+ and a council at 51+; Finland is 20+ with the full duty at 50+; Denmark's turns on the applicable collective agreement rather than headcount alone.
Confidence here is our confidence in the works-council position specifically, on the same High to Low scale as Appendix A. Ten rows rest on national statutory text: Bulgaria, Croatia, Germany, Hungary, Latvia, Liechtenstein, Luxembourg, Malta, Portugal and Switzerland. The other 22 rest on comparative sources, mostly national implementations of Directive 2002/14/EC, so take those ratings as a considered view rather than a sourced one. As in Appendix A, a link in the sources line below tells you nothing about how well evidenced the row is.
| Country | Works-council / monitoring rule | Deploy-blocking power | Confidence |
|---|---|---|---|
| Germany | §87(1)(6) BetrVG: agreement before deploying any system objectively able to monitor (5+); conciliation substitutes | Veto | High |
| France | CSE inform + consult, Art. L2312-8 (50+) | Consult only | High |
| Switzerland (non-EU) | ArGV 3 Art. 26 bars behaviour-monitoring systems; Arts. 5-6 + ArG Art. 48 inform + consult, all sizes | Consult only | High |
| Italy | Art. 4 Statuto dei Lavoratori: union accord or labour-inspectorate authorisation | Negotiate first | High |
| UK (non-EU) | ICER 2004: inform + consult on employee request (50+); no standing duty | Consult only | High |
| Spain | Estatuto de los Trabajadores Arts. 64.5(f), 64.4(d): inform + consult, not veto (works council 50+); AI/algorithm transparency | Consult only | High |
| Netherlands | WOR Art. 27: consent right, measure voidable without it (50+) | Veto | High |
| Poland | Kodeks pracy Art. 222/223: monitoring rules + notice; no veto | Consult only | Med |
| Ireland | I&C Act 2006: inform/consult on employee request (50+), nothing monitoring-specific | Consult only | High |
| Austria | §96(1)(3) ArbVG: works agreement required, true veto (council 5+) | Veto | High |
| Belgium | CBA 68 (camera) + CBA 81 (e-comms): inform/consult, all sizes | Consult only | High |
| Bulgaria | Labour Code Arts 7a, 130c-130d: general inform/consult (50+; 20+ separate units), nothing monitoring-specific | Consult only | High |
| Croatia | Labour Act Art. 151(1)(7): prior works-council consent to processing or disclosing worker data (20+) | Veto | Med-High |
| Cyprus | I&C Law 78(I)/2005: general inform/consult (30+), nothing monitoring-specific | Consult only | Med |
| Czechia | Labour Code §316(2)-(3): serious reason + notice, no co-determination | Consult only | High |
| Denmark | Cooperation-committee duty via the applicable collective agreement (around 35+, not universal) | Consult only | Med |
| Estonia | No monitoring-specific veto; Trustee Act inform/consult (30+) | Consult only | High |
| Finland | Co-operation Act 1333/2021: negotiate before monitoring (20+, full duty at 50+) | Negotiate first | High |
| Greece | Law 1767/1988 Art. 12: works council co-decides on audiovisual monitoring (50+; 20+ if no union) | Veto | High |
| Hungary | Labour Code §11/A: written notice, all sizes; §264(2)(d): council opinion (rep 16+, council 51+) | Consult only | High |
| Latvia | No works councils; Labour Law s.11 inform + consult before decisions on working conditions, reps electable 5+ | Consult only | Med-High |
| Lithuania | Labour Code Art. 27: rules + notice; council 20+, no veto | Consult only | Med |
| Luxembourg | L.414-9(1): delegation must agree to behaviour/performance monitoring (150+); L.261-1 inform only below | Veto | High |
| Malta | I&C Regs 2006 (S.L. 452.96): general inform/consult (50+), nothing monitoring-specific | Consult only | High |
| Portugal | Código do Trabalho Arts. 425(c), 424(1)(j): consult council, AI/monitoring info right; no veto (any size) | Consult only | High |
| Romania | Law 190/2018 Art. 5: notice, consult reps, DPIA, retention cap | Consult only | High |
| Slovakia | Labour Code §13(4): serious reason + notice + consult | Consult only | High |
| Slovenia | ZVOP-2 Art. 78: consult the representative trade union before video surveillance | Consult only | High |
| Sweden | MBL §11: union negotiation before important changes (agreement-triggered) | Negotiate first | High |
| Norway (EEA) | Working Environment Act §9-1/§9-2: consult reps before deployment | Consult only | High |
| Iceland (EEA) | I&C Act 151/2006: inform/consult (50+) | Consult only | Med |
| Liechtenstein (EEA) | ArV III Art. 9 + ArG Art. 45: consult before deciding, all sizes; Art. 59 bars behaviour-only systems | Consult only | High |
Sources: Germany §87(1)(6) BetrVG, France Art. L2312-8, Switzerland ArGV 3, Switzerland ArG, Bulgaria Labour Code, Croatia Labour Act, Hungary Act I of 2012, Latvia Darba likums, Liechtenstein ArV III, Luxembourg Labour Code, L.414-9, Malta S.L. 452.96, Portugal Código do Trabalho, Portugal Lei 13/2023.
One limit on what this appendix maps. It covers the general rules on monitoring and employee representation. Telework rules can sit on top of them, and Portugal's are the clearest example: Article 170(5) of the Código do Trabalho bars capturing image, sound, written exchanges or activity history where doing so could affect a teleworker's right to privacy, and breach is treated as a serious offence. The better reading is that it targets privacy-invasive means of control rather than any capture at all, but how far it reaches an ordinary recorded meeting isn't settled. If you record people working from home, treat Portugal as a row to raise early.
Both appendices are a starting point for the conversation with your own legal advisers, not a substitute for it. Confirm the current national position with local counsel before relying on any single row.
Two limits on the safe default in Appendix A are worth restating. It isn't a lawful basis under GDPR: the consent it describes is about not committing a recording offence, which is a separate question from Article 6, and Chapter 4 explains why consent is often the wrong basis to build on, particularly for staff-facing calls. And it can't cure a works-council duty, which is why the Veto tier above matters even when every participant has agreed.
National criminal, data-protection and labour law all change over time. The positions in both appendices reflect the law as at August 2026; re-check any single row against the current national text before relying on it in a specific case.
Yes, most likely. The Act applies when an AI system's output is used by people in the EU, regardless of where the provider is established. If EU users can reach your AI feature, you're in scope.
Two matter for video: inferring the emotions of people in a workplace or an education setting, and biometric categorisation that sorts people by sensitive traits such as race, religion, political opinion, trade union membership or sexual orientation. Both are prohibited under Article 5 and have been in force since 2 February 2025. They are not future obligations.
Since 2 August 2026, Article 50 has required you to tell users when they're interacting with an AI system, disclose deepfakes, and mark AI-generated audio, image, video and text in a machine-readable form. If your system was already on the market before that date, you have until 2 December 2026 to add the marking.
Not for transcription, captions or translation: these carry across what was said without changing its meaning, so Article 50's marking rules are unlikely to apply, and they're a GDPR responsibility (lawful basis, notice, retention) rather than an AI-labelling one. Summaries are less settled: a summary is new text, not a reproduction of the call, so the same reasoning is weaker, and no guidance confirms it either way. Marking a summary as AI-generated costs you nothing, so it's the safer choice if you ship one.
Outside a workplace or education setting, emotion and sentiment analysis is treated as high-risk rather than banned, with those obligations deferred to 2 December 2027, though you've had to inform anyone exposed to it since 2 August 2026. Inside work or school, there's no such route: inferring emotions there has been prohibited outright since 2 February 2025.
It depends on the country, so the safe default is to capture all-party consent through a pre-join notice before recording starts. Switzerland is a clear example: a participant recording without the others' consent commits an offence. Germany is the same for audio, though narrower than it first looks, because the offence covers the spoken word rather than the video of a call. France works a little differently but points the same way: French law presumes consent once recording is done openly and participants are told and don't object, and it's genuinely covert recording that's criminal, so a pre-join notice that gives people the chance to object is exactly what satisfies the French rule too. One thing consent doesn't cover: in Germany, the Netherlands and Austria among others, a works council can block deployment of a recording or monitoring feature outright, regardless of individual consent (see Appendix B's ladder).
It can. The AI Act's definition of a deepfake covers content resembling existing places, not only people, so a backdrop a viewer would take for where you actually are can fall inside it. Blur, cartoons and a beach nobody believes you're on don't: the question isn't whether the image shows a real place, it's whether it would be taken as authentic. The duty to disclose falls on whoever uses the feature on the call rather than the vendor who built it. And if the point of the fake location is to convince someone you're somewhere official, fraud law and remote identity-verification rules are the larger exposure.
Not on its own. Data in an EU region of a US-controlled provider still sits under US law, including the CLOUD Act. That's residency, not sovereignty. What decides it is the jurisdiction of the company and sub-processors that actually operate the service.
Only with its own lawful basis and notice: training is a new purpose, separate from running the call, so under GDPR's purpose-limitation rule, you can't quietly reuse meeting data as training data.