Jak fungují vektorové databáze a kde v nich unikají osobní data?

Jak vektorová databáze funguje v rámci RAG a proč je to riziko pro osobní data

Text přímo vektorová databáze neukládá. Na vektory vysoké dimenzionality ho systém převede, kde zachytí sémantický význam. Při dotazu uživatel vyhledá nejbližší vektory a předá přidružené úseky do kontextu jazykového modelu. Problém tkví v tom, že embedding není jednosměrná hašovací funkce. Z vektoru lze s dostatečnou přesností odvodit původní text, což potvrzují výzkumné útoky typu embedding inversion. V českém prostředí to znamená, že pokud firma nahraje do znalostní báze smlouvy s rodnými čísly, diagnózy pacientů nebo interní maily, leží v databázi ve formě, kterou útočník s přístupem k indexu částečně nebo plně deanonymizuje. Riziko se zvyšuje, když se vektory sdílejí mezi více aplikacemi bez oddělení tenantů.

Kde v praxi nejčastěji k úniku osobních dat dojde

Nejkritičtější body jsou čtyři: indexace nevyčištěných dat, logování dotazů a odpovědí, sdílení indexu bez izolace a únik přes výstup generativního modelu. První situace nastává, když tým datových inženýrů nahraje do Pinecone, Weaviate nebo Qdrant surová PDF bez předchozího NER filtrování · rodná čísla, účty, zdravotní kódy tak vstoupí do vektorového prostoru. Druhý vektor útoku jsou aplikační logy: mnoho RAG orchestrací (LangChain, LlamaIndex) ve výchozím nastavení loguje celý prompt včetně načtených chunků do stdout nebo monitorovacích nástrojů typu LangSmith, kde k nim mají přístup vývojáři bez oprávnění k osobním datům. Třetí riziko představuje multi-tenant architektura bez row-level security · jeden klient v SaaS řešení může dotazem dosáhnout k vektorům druhého klienta, pokud databáze nevyžaduje tenant ID v každém dotazu. Čtvrtý kanál je generativní model sám: pokud do kontextu dostane citlivý chunk, může ho vypsat v odpovědi i při pokusu o odmítnutí, což je známý fenomén context leakage.

Jak nastavit přístupová práva a autorizaci v RAG pipeline

Efektivní ochrana vyžaduje vrstvený model: na úrovni vektorové databáze musí existovat metadata pole owner_id, department, classification a každý dotaz musí být obohacen o filtr where owner_id == current_user.id. V praxi to znamená, že aplikace předá identitu uživatele (např. z JWT tokenu) do retrieveru jako parametr filtru, ne jako součást přirozeného jazyka. Pro české firmy s odděleními HR, finance a IT se hodí role-based access control mapovaný na metadata chunků: chunky ze smluv mají department: legal, chunky z mezd department: hr. Pokud databáze filtr na úrovni metadat nepodporuje (starší verze ChromaDB), je nutné nasadit proxy vrstvu, která ověří přístup před dotazem na index. V auditech CIAD se ukazuje, že chybějící filtr na úrovni vektoru je nejčastější důvod nalezení při pentestech RAG systémů.

Kontrolní seznam pro bezpečné nasazení vektorové databáze

1. Klasifikace dat před indexací · spusťte NER model (např. spaCy s českým modelem) a zahashujte nebo zamaskujte identifikátory před vkládáním do embedding modelu.
2. Šifrování v klidu i přenosu · vyžadujte TLS 1.3 pro připojení k databázi a AES-256 pro diskové úložiště; u spravovaných služeb ověřte, že klíče spravujete vy (BYOK).
3. Izolace tenantů · buď fyzicky oddělené indexy, nebo logické oddělení přes povinný filtr tenant_id v každém dotazu; otestujte pokus o cross-tenant dotaz.
4. Minimalizace logů · vypněte logování chunků v produkci, logujte pouze hash dotazu, počet vrácených výsledků a latenci.
5. Audit trail přístupů · zaznamenávejte kdo, kdy a jaké metadata filtrovat dotazoval; uchovávejte logy minimálně rok dle GDPR povinnosti evidence zpracování.
6. Test inverze embeddingů · pravidelně (kvartálně) spusťte testovací sadu útoků na vlastním indexu a měřte success rate rekonstrukce textu.
7. Smluvní úpravy s dodavatelem · u cloudových vektorových DB (Pinecone, Weaviate Cloud, Azure AI Search) vyžádejte DPA, SCC a potvrzení, že podpora nemá přístup k datům bez vašeho souhlasu.

Kritéria výběru dodavatele vektorové databáze pro regulované sektory

Pro bankovnictví, zdravotnictví a veřejnou správu by výběr měl respektovat tato pravidla: certifikace ISO 27001 a SOC 2 Type II jsou povinné, ne volitelné. Databáze musí podporovat šifrování klíčů zákazníkem (CMEK) a nabízet audit logy exportovatelné do SIEM. Funkce row-level security nebo document-level ACL musí být nativní, ne doimplementovaná přes aplikační kód. Lokalita datacentra v EU (ideálně v ČR nebo Německu) zjednodušuje přenosy podle Schrems II. SLA na dostupnost 99,9 % s penalizacemi a RPO nula pro metadata. Cena se pohybuje od stovek korun měsíčně pro menší open-source nasazení (Qdrant, Milvus na vlastních serverech) po desítky tisíc korun u plně spravovaných enterprise plánů s dedikovanými uzly. Malá firma do 50 zaměstnanců bez bezpečnostního týmu obvykle vybere spravovanou službu s mocnými výchozími nastaveními; velká korporace s vlastním SOC nasadí open-source cluster do vlastního VPC s hardened obrazy.

Termíny a povinnosti vyplývající z GDPR a AI Actu

Pokud do vektorové databáze vstoupí osobní data, zpracovatel (firma) musí provést DPIA (posudek dopadu na ochranu dat) před produkčním nasazením · v praxi to trvá 2 až 4 týdny včetně konzultace s DPO. V případě úniku (např. zjištění, že embeddingy byly přístupné neoprávněné osobě) máte 72 hodin na oznámení úřadu (ÚOOÚ v ČR) a bez zbytečného odkladu i dotčeným subjektům, pokud hrozí vysoké riziko. AI Act přidává povinnost registrace vysokoryzikového AI systému (RAG pro rozhodování o úvěrech, diagnózy) v evropském registru a pravidelný monitoring přesnosti a biasu. Pro české subjekty platí, že evidence zpracování musí obsahovat i vektorovou databázi jako kategorii příjemců dat, včetně popisu technických opatření (šifrování, RBAC, pseudonymizace). Termín pro dodržení AI Actu pro vysokoryzikové systémy je 2. srpna 2026, ale DPIA a GDPR platí již nyní.

Koho to týká a jak se liší přístup podle velikosti a sektoru

Mikro a malé firmy (do 50 zaměstnanců, obrat do 10 mil. Kč) bez interního IT bezpečnostního týmu by měly využívat spravované RAG platformy s vestavěnou ochranou (např. Azure AI Search s RBAC, Pinecone s metadata filtrem) a externího DPO na hodinovém základu. Střední firmy (50 až 250 zaměstnanců, regulované sektory jako leasing, pojišťovny, nemocnice) potřebují vlastní bezpečnostního architekta, nasazení open-source vektorové DB (Qdrant, Weaviate) do Kubernetes clusteru s PodSecurityPolicies, síťovou segmentací a pravidelnými pen-testy. Velké enterprise a veřejná správa vyžadují air-gapped nasazení, hardwarové bezpečnostní moduly (HSM) pro klíče, formální certifikaci produktu podle Common Criteria EAL4+ a kontinuální monitoring úniků dat (DLP) i na úrovni embeddingů. Ve všech případech platí: pokud nemáte jistotu, zda vektorová databáze obsahuje osobní data, předpokládejte, že ano, a aplikujte opatření dle výše uvedeného checklistu.

Co to znamená: Vektorová databáze není jen technické úložiště pro AI, ale datová schránka s osobními údaji v kódované podobě. Rozhodnutí o nasazení RAG musí začít klasifikací dat a modelem přístupových práv, ne výběrem embedding modelu. Firma, která neimplementuje filtr na úrovni vektoru, šifrování s vlastními klíči a audit trail přístupů, porušuje GDPR a riskuje sankce i poškození reputation. Proveďte DPIA před produkčním startem, nasaďte kontrolní seznam výše a naplánujte kvartální test inverze embeddingů · to je minimální standard pro odpovědné využívání RAG v českém právním prostředí.