GDPR to nezakazuje, ale říká něco nepříjemnějšího: musíte umět vysvětlit, proč modelu posíláte rodné číslo Jana Nováka, když má jen shrnout jeho smlouvu. A část téhle povinnosti jde vynutit architekturou, ne směrnicí. GDPR doesn't forbid it, but it says something less comfortable: you have to be able to explain why you're sending the model Jan Novák's birth number when all it has to do is summarize his contract. And part of that obligation can be enforced by architecture rather than by a policy document.
Firmy se často soustředí na otázku, jestli osobní údaje do externího LLM vůbec smějí poslat. Mnohem zajímavější je podle mě otázka, která přichází potom: které z těch údajů tam skutečně poslat potřebují. Companies tend to focus on whether they may send personal data to an external LLM at all. The more interesting question, in our view, is the one that comes next: which of that data they actually need to send.
Nejde přitom jen o ChatGPT. Stejná otázka platí pro Copilota, Gemini, Claude i pro AI funkce vestavěné do systémů, které už ve firmě běží. Rozhodující není jméno nástroje, ale jestli AI běží ve vaší infrastruktuře, nebo mimo ni. And this isn't only about ChatGPT. The same question applies to Copilot, Gemini, Claude and to AI features built into systems the company already runs. What matters isn't the tool's name, but whether the AI runs inside your infrastructure or outside it.
To je otázka minimalizace — povinnost, kterou firmy běžně míjejí. A část téhle povinnosti lze vynutit technicky, místo abychom spoléhali jen na směrnici a na člověka. That's a question of data minimization — an obligation companies routinely skip past. And part of it can be enforced technically, instead of relying on a policy and a person remembering it.
„Kvůli GDPR nesmíme osobní údaje posílat do AI, která neběží u nás“ je zkratka, ne pravidlo. GDPR externí zpracování nezakazuje. Ukládá povinnosti: mít právní základ, vědět, komu data předáváte, zabezpečit je a poslat jen to, co je nezbytné. "GDPR means we can't send personal data to AI that doesn't run on our own infrastructure" is a shortcut, not a rule. GDPR doesn't forbid external processing. It imposes obligations: have a legal basis, know who you're passing data to, secure it, and send only what's necessary.
Hodně firem podceňuje, že samotné předání dat dalšímu systému je „zpracování“ — GDPR pod ten pojem zahrnuje i použití nebo zpřístupnění údajů přenosem. Otázka „trénuje na tom provider?“ řeší jen část problému: i bez tréninku se data zpracovávají, a někdo za to odpovídá. Many companies underestimate that handing data to another system is itself "processing" — GDPR's definition covers use or disclosure by transmission. The question "does the provider train on it?" only solves part of the problem: even without training, the data is being processed, and someone is accountable for it.
Lidé přitom do modelů vkládají smlouvy, reklamace, životopisy, zápisy ze schůzek i HR dokumenty. S nimi jména, telefony, adresy, rodná čísla, IBANy a SPZ. Meanwhile people paste contracts, complaints, CVs, meeting notes and HR documents into models. And with them names, phone numbers, addresses, birth numbers, IBANs and licence plates.
Pět otázek rozhoduje o tom, jestli je vaše používání LLM obhajitelné: Five questions decide whether your use of an LLM is defensible:
| Článek GDPRGDPR article | Otázka, kterou řešíThe question it answers | Co to znamená pro provoz LLMWhat it means for running an LLM |
|---|---|---|
| Čl. 6Art. 6 | Proč ta data zpracováváme?Why are we processing this data? | „AI nám pomáhá“ není účel ani právní základ."AI helps us" is neither a purpose nor a legal basis. |
| Čl. 5 odst. 1 písm. c)Art. 5(1)(c) | Potřebuje model všechny údaje?Does the model need all the data? | Rozsah omezený na nezbytné. Rodné číslo model ke shrnutí smlouvy nepotřebuje.Scope limited to what's necessary. A model doesn't need a birth number to summarize a contract. |
| Čl. 13/14Art. 13/14 | Vědí lidé, komu nebo jakým kategoriím příjemců mohou být data zpřístupněna?Do people know to whom, or to which categories of recipients, their data may be disclosed? | Privacy notice musí odpovídat reálnému zpracování, ne šuplíkové šabloně.The privacy notice has to match real processing, not a template in a drawer. |
| Čl. 28Art. 28 | Kdo data zpracovává?Who is processing the data? | Nestačí, že zaměstnanec AI službu používá — firma musí mít jasno v roli providera a tam, kde vystupuje jako zpracovatel, odpovídající smluvní vztah (DPA).An employee simply using an AI service isn't enough — the company must be clear about the provider's role and, where it acts as a processor, have the matching contract (DPA) in place. |
| Čl. 32 a čl. 25Art. 32 and Art. 25 | Jak je chráníme?How are we protecting it? | Nařízení jmenuje pseudonymizaci a šifrování výslovně, a to už při návrhu systému.The regulation names pseudonymization and encryption explicitly — and does so already at the design stage. |
| Čl. 5 odst. 2Art. 5(2) | Umíme dodržování pravidel doložit?Can we demonstrate that we comply? | Nestačí pravidla jen nastavit — správce musí být schopen doložit, že principy GDPR skutečně dodržuje.Setting the rules isn't enough — the controller must be able to demonstrate that the GDPR principles are actually being complied with. |
Práh dál posouvají tři situace: přenos mimo EHP (kapitola V, čl. 44+), zvláštní kategorie údajů, například údaje o zdraví nebo biometrické údaje používané za účelem jedinečné identifikace osoby (čl. 9) a vysoce rizikové zpracování, které může vyžadovat DPIA (čl. 35). Na žádnou z nich nestačí odpověď „máme firemní AI“. Three situations raise the bar further: transfers outside the EEA (Chapter V, Art. 44+), special categories of data, such as health data or biometric data used for the purpose of uniquely identifying a person (Art. 9), and high-risk processing that may require a DPIA (Art. 35). For none of them is "we have a company AI" an answer.
AI Act nezavádí povinnost anonymizovat před každou inferencí. Recitál 69 ale výslovně odkazuje na minimalizaci dat a na data protection by design and by default a mezi možná technická opatření řadí anonymizaci a šifrování, včetně technologií, které umožní pracovat s daty bez předávání původních hodnot mezi stranami. Pseudonymizace před externí inferencí tedy není povinnost přikázaná AI Actem. Je to ale architektura, která jde přímo ve směru privacy principů, na něž AI Act odkazuje — a především principů GDPR. The AI Act doesn't introduce an obligation to anonymize before every inference. Recital 69, however, explicitly refers to data minimization and to data protection by design and by default, and lists anonymization and encryption among possible technical measures, including technologies that allow working with data without passing the original values between parties. So pseudonymization before external inference isn't an AI Act mandate. It is, though, an architecture that points straight at the privacy principles the AI Act refers to — and above all at the principles of GDPR.
Druhá vrstva je AI gramotnost. Čl. 4 ukládá poskytovatelům a zavádějícím subjektům přijímat opatření na podporu rozvoje AI gramotnosti lidí, kteří jejich jménem s AI systémy pracují — Evropská komise jako příklad používá zaměstnance, kteří v ChatGPT píšou reklamní texty nebo překládají, a mají znát riziko halucinací. Povinnost platí od 2. února 2025; od srpna 2026 už běží také dohled a vymáhání. The second layer is AI literacy. Art. 4 requires providers and deployers to take measures to foster AI literacy among the people who work with AI systems on their behalf — the European Commission's own example is employees who use ChatGPT to write ad copy or translate, and who should know about the risk of hallucinations. The obligation has applied since 2 February 2025; since August 2026, supervision and enforcement are running too.
Firma tak řeší dvě vrstvy současně: umí lidé AI bezpečně používat (AI Act), a co se děje s osobními údaji, které do ní posílají (GDPR). So a company is dealing with two layers at once: can people use AI safely (AI Act), and what happens to the personal data they send into it (GDPR).
Rozdíl mezi „nedávej tam rodné číslo“ a systémem, ve kterém se rodné číslo ven prostě nedostane.The difference between "don't put the birth number in there" and a system where the birth number simply doesn't get out.
Směrnice spoléhá na to, že si na ni zaměstnanec v tu chvíli vzpomene. Architektura na tom závisí míň — pokud je nastavená jako výchozí, ne jako volitelný krok, kterým se musí ještě někdo proklikat. A policy relies on the employee remembering it in that exact moment. Architecture depends on that far less — provided it's the default, not an optional step someone still has to click through.
V praxi to vypadá jako privacy vrstva mezi uživatelem a externím modelem. Dokument se před odesláním převede na placeholdery: [PERSON_1], [PERSONAL_ID_1], [IBAN_1], [PHONE_1]. Externí model dostane jen tuhle podobu, odpoví s placeholdery, a uvnitř kontrolovaného prostředí se odpověď převede zpět na reálné hodnoty. Model původní identifikátory k téhle práci nepotřeboval — v tomto průchodu je neviděl. In practice it looks like a privacy layer between the user and the external model. Before the document is sent, it's turned into placeholders: [PERSON_1], [PERSONAL_ID_1], [IBAN_1], [PHONE_1]. The external model only ever gets that version, answers with placeholders, and inside the controlled environment the answer is mapped back to real values. The model never needed the original identifiers for this job — in this pass, it didn't see them.
Říká se tomu anonymizace, ale pokud systém drží mapování [PERSON_1] → Jan Novák a umí hodnotu vrátit, jde z pohledu GDPR o pseudonymizaci. EDPB k tomu upozorňuje, že pseudonymizovaná data zůstávají osobními údaji, pokud je lze pomocí dalších informací přiřadit konkrétní osobě. People call it anonymization, but if the system keeps a mapping of [PERSON_1] → Jan Novák and can restore the value, then in GDPR terms it's pseudonymization. The EDPB points out that pseudonymized data remains personal data where it can be attributed to a specific person using additional information.
Pseudonymizace tedy GDPR nevypíná. Dělá něco jiného: výrazně omezuje množství původních identifikátorů, které musí opustit vaše prostředí. Pseudonymizace je přitom jedním z opatření, která čl. 25 a čl. 32 výslovně zmiňují. So pseudonymization doesn't switch GDPR off. It does something else: it substantially reduces how many original identifiers ever have to leave your environment. And pseudonymization is one of the measures Art. 25 and Art. 32 name explicitly.
Privacy vrstva běží před externí inferencí — a každé maskování se zapisuje do auditu.The privacy layer runs before external inference — and every masking operation is written to the audit trail.
V Auredu proto pseudonymizaci nedáváme uživateli jako volitelný přepínač. Privacy vrstva detekuje osobní údaje a identifikátory včetně českých specifik — například rodná čísla nebo IČO s kontrolními součty — vytvoří pro konkrétní request dočasné mapování, externímu modelu odešle pseudonymizovaný obsah a jeho odpověď následně rehydratuje na reálné hodnoty. Stejný princip používáme i při volání nástrojů, ne jen na první vstup. That's why, in Auredo, pseudonymization isn't an optional switch for the user. The privacy layer detects personal data and identifiers — including Czech specifics such as birth numbers or company IDs with checksums — creates a temporary mapping for that one request, sends the pseudonymized content to the external model, and then rehydrates its answer back to the real values. The same principle applies to tool calls, not just to the first input.
Ke každému požadavku navíc vedeme auditní stopu toho, co se v něm detekovalo a pseudonymizovalo — jaké typy údajů, kolikrát. Nejde jen o to, že se identifikátory a další osobní údaje schovají, ale o to, že je zpětně dohledatelné, co přesně model v dané chvíli neviděl. On top of that, every request carries an audit trail of what was detected and pseudonymized in it — which types of data, and how many times. The point isn't only that identifiers and other personal data get hidden; it's that you can go back and show exactly what the model didn't see at that moment.
Datová vrstva běží on-prem nebo v privátním EU cloudu — ven putuje jedině volání na jazykový model, a i toho providera si vybíráte vy, včetně modelu ve vlastní síti. Detaily nasazení a síťové topologie rozebírá stránka Bezpečnost. The data layer runs on-prem or in a private EU cloud — the only thing that leaves is the call to the language model, and you pick that provider yourself, including a model inside your own network. Deployment details and network topology are covered on the Security page.
Nejčastější námitka proti privacy vrstvě není právní, ale uživatelská: „zpomalí to chat.“ Detekce, redakce a rehydratace jsou práce navíc, a u chatu rozhoduje TTFT (Time To First Token) — jak rychle uživatel uvidí první znak odpovědi místo prázdné obrazovky. The most common objection to a privacy layer isn't legal, it's about user experience: "it'll slow the chat down." Detection, redaction and rehydration are extra work, and in chat what matters is TTFT (time to first token) — how fast the user sees the first character instead of an empty screen.
Testovali jsme to ve třech nezávislých kolech na třech LLM; tohle je nejpodrobnější z nich: 48 běhů = 4 syntetické datasety (dokumenty o 5, 15 a 50 stranách a tabulka s 5 000 řádky, se širokou paletou osobních, kontaktních a platebních údajů — jména, adresy, rodná čísla, IBANy, doklady a další, tedy plným rozsahem toho, co privacy vrstva dnes detekuje) × 3 modely (OpenAI gpt-4o-mini, Mistral-small-3.2-24B, Qwen3.6-35B-a3b) × 2 režimy (vypnuto / enforce) × 2 opakování. Rovnou k metodice: to je n = 2 na kombinaci — malý vzorek, ze kterého nejde dělat statistickou generalizaci. Nepředstírám, že jde o rigorózní benchmark, jen o měření, ze kterého už je vidět tvar problému. We tested it in three independent rounds across three LLMs; this is the most detailed one: 48 runs = 4 synthetic datasets (documents of 5, 15 and 50 pages, plus a table with 5,000 rows, carrying a wide range of personal, contact and payment data — names, addresses, birth numbers, IBANs, ID numbers and more, the full range the privacy layer detects today) × 3 models (OpenAI gpt-4o-mini, Mistral-small-3.2-24B, Qwen3.6-35B-a3b) × 2 modes (off / enforce) × 2 repetitions. On methodology, up front: that's n = 2 per combination — a small sample you can't generalize from statistically. I'm not pretending this is a rigorous benchmark, just a measurement that already shows the shape of the problem.
n = 2 na buňku, rozptyl mezi běhy byl místy velký — orientační, ne přesné. U tří dokumentů vyšel režim enforce rychleji; u tabulky se 75 000 údaji pomaleji.n = 2 per cell, variance between runs was sometimes large — indicative, not exact. On the three documents enforce came out faster; on the table with 75,000 data points it came out slower.
Ten poslední řádek nezakrýváme: u tabulky se 75 000 pseudonymizovanými údaji byl enforce pomalejší, ne rychlejší — dvacetkrát víc dat než u 50stránkového dokumentu (3 750) posunulo rozdíl z −0,19 s na +1,21 s. Ano, při desítkách tisíc údajů v jednom požadavku ke zpomalení reálně dochází. Zůstává to ale v řádu jedné sekundy — v celkové délce odpovědi na takhle velký vstup to uživatel v praxi neodliší od běžného kolísání rychlosti modelu. We're not hiding that last row: on the table with 75,000 pseudonymized data points, enforce was slower, not faster — twenty times more data than the 50-page document (3,750) moved the difference from −0.19 s to +1.21 s. Yes, at tens of thousands of data points in a single request the slowdown is real. But it stays in the order of one second — across the full length of an answer to an input that large, users won't tell it apart from the model's ordinary speed fluctuation.
Kromě rychlosti jsme sledovali i to, jestli se údaje vrátí správně: ve všech dokončených bězích se jméno, rodné číslo i IBAN vrátily přesně tak, jak měly — 100 %. Beyond speed, we also tracked whether the data comes back correctly: in every completed run the name, birth number and IBAN came back exactly as they should have — 100%.
Nebylo to ojedinělé měření: v dalším kole (80 běhů) vyšel souhrnný rozdíl OFF vs. ENFORCE na −0,03 s, prakticky nula, a pseudonymizace i rehydratace fungovaly na 100 %. V žádném z obou kol se privacy vrstva neprojevila jako systematické zpomalení — jen šum podle velikosti dokumentu a zátěže LLM providera. This wasn't a one-off: in another round (80 runs) the aggregate OFF vs. ENFORCE difference came out at −0.03 s, essentially zero, with pseudonymization and rehydration working at 100%. In neither round did the privacy layer show up as a systematic slowdown — only noise driven by document size and the LLM provider's load.
Poznámka k metodice: syntetická data, jedna implementace, tři provideři, malý počet opakování. Čísla platí pro tuhle vrstvu, tyhle modely a tyhle datasety — nejde o obecný benchmark ani univerzální slib. A note on methodology: synthetic data, one implementation, three providers, a small number of repetitions. The numbers hold for this layer, these models and these datasets — this is not a general benchmark, nor a universal promise.
Nejdůležitější otázka podle mě není, jestli osobní údaje do externího LLM poslat smíte. V řadě případů můžete. Zajímavější je: které z nich tam skutečně poslat potřebujete? The most important question, to me, isn't whether you may send personal data to an external LLM. In many cases you can. The more interesting one is: which of it do you actually need to send?
Pokud model dokáže úkol splnit bez jména, rodného čísla nebo IBANu, privacy by default může zajistit, že je vůbec neuvidí. A naše měření ukazují ještě jednu praktickou věc: uživatel za to nemusí platit pomalejším chatem — 3,89 s bez privacy vrstvy, 3,85 s s ní. Nejde tedy jen o to AI povolit nebo zakázat. Jde o to navrhnout infrastrukturu tak, aby AI standardně dostávala jen data, která opravdu potřebuje. If the model can do the job without a name, a birth number or an IBAN, privacy by default can make sure it never sees them. And our measurements show one more practical thing: users don't have to pay for it with a slower chat — 3.89 s without the privacy layer, 3.85 s with it. So this isn't only about permitting or banning AI. It's about designing the infrastructure so that AI gets, by default, only the data it genuinely needs.
Napište nám, jaký typ dokumentů to je — rádi probereme, které údaje z něj model vůbec nepotřebuje vidět.Tell us what kind of document it is — we'll gladly go through which parts of it the model never needs to see.
GDPR (nařízení EU 2016/679): čl. 4 (definice zpracování), čl. 5 odst. 1 písm. c) (minimalizace), čl. 5 odst. 2 (odpovědnost a doložitelnost), čl. 6 (právní základ), čl. 9 (zvláštní kategorie údajů), čl. 13/14 (informační povinnost), čl. 25 (data protection by design and by default), čl. 28 (zpracovatel), čl. 32 (zabezpečení), čl. 35 (DPIA), kapitola V / čl. 44+ (přenosy do třetích zemí) — EUR-Lex. AI Act (nařízení EU 2024/1689): recitál 69, čl. 4 (AI gramotnost; povinnost od 2. 2. 2025, dohled a vymáhání od srpna 2026) — EUR-Lex. EDPB: stanovisko k pseudonymizaci. Interní měření TTFT (Auredo): dvě ze tří nezávislých testovacích kol (80 a 48 běhů, tři LLM) citovaná v článku; třetí kolo (n = 1, s timeouty na straně LLM providera) je pro srovnání OFF/ENFORCE statisticky nepoužitelné a v článku se necituje. GDPR (EU Regulation 2016/679): Art. 4 (definition of processing), Art. 5(1)(c) (minimization), Art. 5(2) (accountability), Art. 6 (legal basis), Art. 9 (special categories), Art. 13/14 (information duty), Art. 25 (data protection by design and by default), Art. 28 (processor), Art. 32 (security), Art. 35 (DPIA), Chapter V / Art. 44+ (third-country transfers) — EUR-Lex. AI Act (EU Regulation 2024/1689): Recital 69, Art. 4 (AI literacy; applicable from 2 February 2025, supervision and enforcement from August 2026) — EUR-Lex. EDPB: opinion on pseudonymization. Internal TTFT measurement (Auredo): two of three independent test rounds (80 and 48 runs, three LLMs) are cited in this article; the third round (n = 1, with timeouts on the LLM provider's side) is statistically unusable for an OFF/ENFORCE comparison and is not cited.
Ozvěte se — ukážeme vám Auredo a probereme, jak konkrétně vám pomůže.Get in touch — we'll show you Auredo and discuss how it can help you.
