Rychlé přiznání, než začneme. V předchozích příspěvcích této série jsem se záměrně vyhýbal technickým detailům implementace, protože pokud jde o skutečné inženýrství, jsem asi tak užitečný jako čokoládová páječka. Dokážu vám říct, proč na něčem záleží. Jak na to, to nechávám na lidech, kteří skutečně chodili na správné kurzy.
Tento příspěvek je jiný. Dílčí zpracovatelé a datové toky jsou jednou z mála technických oblastí, kde skutečně vím, o čem mluvím. Strávil jsem roky auditováním těchto věcí, dohadováním se o nich s dodavateli a vysvětlováním je regulátorům. Takže pro jednou mě považujte za krátce kompetentního.
Dobře. Jdeme na to.
Někdy v minulém roce někdo z vašeho týmu přidal SDK. Pak další. Webhook na službu třetí strany. Agent pro monitorování chyb. Nástroj pro nahrávání relací. AI API, kam posíláte uživatelský vstup a dostáváte zpět výstup.
Každé z těchto rozhodnutí se zdálo jako rozhodnutí o nástroji. Každé z nich je také rozhodnutím o správě dat. A tyto dvě věci se zřídka staly ve stejné konverzaci.
Zde je problém: podle GDPR je každá třetí strana, která zpracovává osobní údaje vašich uživatelů vaším jménem, zpracovatelem dat. Jste za ně právně odpovědní. Potřebujete s nimi smlouvu, která stanoví konkrétní věci. Pokud jsou mimo EU, potřebujete právní mechanismus pro zasílání dat tam. A pokud se něco pokazí, regulátoři vás požádají, abyste se zodpovídali za celý řetězec, nejen za svůj vlastní kód.
Většina týmů to nedokáže. Ne proto, že by byli nedbalí, ale proto, že se integrace hromadily rychleji než dokumentace. Takto to napravíte.
Krok jedna: najděte vše, co se dotýká osobních dat
Nezačínejte s tabulkou. Začněte s vaším síťovým provozem.
Vytáhněte všechny odchozí cíle, ke kterým se vaše aplikace připojuje. Síťové protokoly vašeho poskytovatele cloudu, váš odchozí firewall, váš monitorovací nástroj, pokud má viditelnost sítě. To je základní pravda. Vše ostatní je dokumentace, která se může, ale nemusí shodovat s tím, co skutečně běží.
Pak projděte kódovou základnu. Každé SDK třetí strany inicializované při spuštění. Každý API klíč ve vaší konfiguraci. Každý webhook endpoint někde zaregistrovaný. Každé místo, kde voláte externí službu s datovou zátěží, která obsahuje identifikátor uživatele, e-mailovou adresu, uživatelsky generovaný obsah, jméno, ID zařízení, token relace, IP adresu nebo cokoli, co by mohlo být spojeno s konkrétní osobou.
Udělejte si seznam. Najdete věci, na které jste zapomněli. Každý je najde.
Běžná místa, která vývojáři přehlížejí:
- Váš nástroj pro monitorování chyb. Stack trace často obsahují PII – e-mailové adresy ve zprávách o výjimkách, ID uživatelů, těla požadavků zaznamenaná při chybě. Sentry, Datadog, Rollbar, všechny z nich. Zkontrolujte, co posíláte.
- Vaše API AI modelu. Pokud předáváte uživatelský vstup do OpenAI, Anthropic nebo jiného poskytovatele modelu, tento vstup pravděpodobně obsahuje osobní údaje. Jejich podmínky DPA se za poslední dva roky výrazně vyvinuly. Verze, kterou jste přijali při registraci, nemusí odrážet aktuální podmínky. Znovu zkontrolujte.
- Staging a vývojová prostředí. Často jsou připojena ke stejným nástrojům třetích stran jako produkce, někdy s menším dohledem. Data ve stagingu jsou někdy kopírována z produkce. Obojí je důležité.
- Knihovny s vestavěnou analytikou. Některá SDK se ve výchozím nastavení připojují domů. Přečtěte si changelog, když aktualizujete. To není paranoia; stalo se to u široce používaných balíčků a věta „nevěděli jsme, že to knihovna dělá“ nezní dobře před regulátorem.
Krok dva: pro každou integraci položte tři otázky
Jakmile máte seznam, projděte ho systematicky.
Přijímá tato integrace osobní údaje?
Pokud ano, je v rozsahu. Pokud přijímá pouze anonymizovaná, agregovaná data bez odkazu na jednotlivce, můžete ji deprioritizovat. V případě pochybností ji považujte za v rozsahu.
Máte s tímto dodavatelem Smlouvu o zpracování dat (DPA)?
DPA je smlouva, která stanoví pravidla: dodavatel může zpracovávat data pouze na základě vašich pokynů, nemůže je používat pro své vlastní účely (včetně trénování modelů, pokud jste nesouhlasili), musí vás informovat o porušení dostatečně rychle, abyste mohli splnit svou vlastní 72hodinovou lhůtu pro oznámení, a musí vaše data smazat po skončení smlouvy. Většina hlavních dodavatelů má standardní DPA, kterou můžete podepsat nebo odsouhlasit. Najděte ji, podepište ji, uchovejte si kopii.
Dvě věci, které si v DPA skutečně přečtěte, než ji přijmete: zda dodavatel může používat vaše data k vylepšení svého vlastního produktu nebo k trénování svých modelů, a co dělá s vašimi daty, když přestanete platit. Obojí je často horší, než byste předpokládali z marketingového textu.
Kde se data zpracovávají?
Pokud má dodavatel sídlo mimo EU, nebo pokud používá infrastrukturu mimo EU, jedná se o přeshraniční přenos. U dodavatelů z USA zkontrolujte, zda jsou certifikováni podle rámce EU-US Data Privacy Framework – většina hlavních je a je to dohledatelné na seznamu DPF. DPF přežil soudní napadení u Soudního dvora EU v září 2025 a je v současné době platný, ačkoli odvolání k Soudnímu dvoru je stále nevyřízené. Pokud zpracováváte citlivé kategorie dat, je rozumné mít ve své DPA Standardní smluvní doložky (SCC) spolu s certifikací DPF, vzhledem k historii tohoto konkrétního rámce. Pro dodavatele mimo USA, na které se nevztahuje rozhodnutí o odpovídající ochraně, jsou SCC standardním mechanismem. Praktická kontrola: je v DPA zdokumentován mechanismus přenosu a je aktuální? SCC před rokem 2021 jsou neplatné od prosince 2022. Pokud je vaše DPA dostatečně stará, aby na ně odkazovala, je třeba ji aktualizovat.
Krok tři: třídění toho, co najdete
Všechno najednou neopravíte. To je v pořádku. Nikdo nikdy neopravil všechno najednou. Někteří z těch lidí se o to stále snaží. Důležité je vědět, co máte.
Vysoká priorita: integrace přijímající jména, e-mailové adresy, uživatelsky generovaný obsah, behaviorální data nebo cokoli ze zvláštní kategorie, jako jsou zdravotní, finanční nebo lokalizační data. Tyto vyžadují aktuální DPA a zdokumentovaný mechanismus přenosu před čímkoli jiným.
Střední priorita: integrace přijímající pseudonymizované identifikátory, jako jsou interní ID uživatelů, tokeny relací nebo otisky zařízení. Stále v rozsahu, ale s nižší naléhavostí, pokud neexistuje přímá cesta zpět k jednotlivci bez dalších dat.
Prozatím mimo rozsah: integrace přijímající pouze plně anonymizovaná agregovaná data bez rizika reidentifikace. Zdokumentujte, že jste je posoudili a proč jsou mimo rozsah.
Pro cokoli s vysokou prioritou, kde nemáte DPA, ji najděte dnes. Většina dodavatelů je zveřejňuje ve své právní nebo soukromí sekci. Pokud dodavatel odmítne podepsat DPA, je to významný varovný signál. Osobní údaje proudící ke zpracovateli bez DPA jsou porušením GDPR, nikoli mezera, kterou můžete uzavřít později.
Krok čtyři: zapište si to
GDPR vyžaduje, aby většina organizací vedla záznamy o činnostech zpracování. To, co jste právě vytvořili, je základem tohoto záznamu. Pro každou integraci: jaká data k ní jdou, proč, na jakém právním základě, kde se zpracovávají a jaká jsou ochranná opatření.
Tento dokument má dvě publika. Prvním je regulátor, pokud někdy budete potřebovat prokázat svůj soulad. Druhým jsou vaši podnikoví zákazníci, kteří si vyžádají váš seznam dílčích zpracovatelů jako součást due diligence dodavatele. Každá společnost prodávající do regulovaných odvětví dostane tento požadavek. Mít připravenou odpověď je rozdíl mezi hladkým procesem nákupu a zpožděným.
Udržujte to aktuální. Přidejte krok do svého kontrolního seznamu integrací: pokaždé, když se zavede nový nástroj třetí strany, provede se s ním i kontrola zpracovatele. Trvá to dvacet minut na integraci, když to uděláte včas. Trvá to podstatně déle, když to děláte retrospektivně napříč třemi lety nahromaděných nástrojů pod časovým tlakem.
Upřímná verze, proč na tom záleží
Regulátoři neauditují většinu startupů. Bezprostřední riziko vymáhání pro malou společnost je reálné, ale není to primární důvod, proč to dělat.
Primárním důvodem je, že porušení zahrnující data, o kterých jste nevěděli, že je zpracovává dodavatel, kterého jste nezmapovali, je jiná kategorie problému než porušení, které můžete plně zdůvodnit. Jedno je incident. Druhé je důkaz, že vaše správa dat neexistuje. Regulátoři, právníci a podnikoví zákazníci s nimi zacházejí velmi odlišně.
Proveďte audit. Je to pár dní nepříjemného objevování a pak víte, co skutečně máte. To má podstatně větší hodnotu než zásady ochrany osobních údajů, které nikdo nečte.
O autorovi
Yves-Philipp Rentsch
Yves-Philippe is Kolsetu's CISO and DPO with nearly two decades of experience in information security, business continuity, and compliance across finance, software, and fintech. Outside his day-to-day work, he enjoys writing about cybersecurity, data privacy, and the occasional industry rant - usually with the goal of making complex security topics a bit more understandable.
Nedavne clanky

Smazáno z databáze – živé v zálohách
Uživatele jste smazali. Zálohy o tom nevěděly, stejně jako váš logovací pipeline, váš analytický sklad nebo vaše CRM. Další článek z mé série o budování vyhovujících systémů pro vývojáře, kteří chtějí dodávat bez porušování pravidel.

Kolsetu Elba vs Bland AI: Srovnání AI pro dodržování předpisů 2026
Objevte klíčové rozdíly v našem srovnání Kolsetu Elba vs Bland AI: Compliance AI Showdown a vyberte si tu správnou platformu pro váš tým v roce 2026.

Jak hlasoví AI agenti snižují počet nedostavení se v regulovaném zdravotnictví
Hlasová AI snižuje počet zmeškaných schůzek o 40 % při zachování souladu s předpisy na úrovni HIPAA a auditních záznamů pro poskytovatele regulovaného zdravotnictví.
Pokracujte dal
Prejdete na srovnani a oborove stranky pro hlubsi kontext.
Dalsi clanky z blogu
Aktualni clanky o operacni AI a regulovanych workflow postupech.
Srovnat AI platformy
Detailni srovnani konkurence pro enterprise rozhodovani.
Elba vs Bland AI
Rozdily v compliance kontrolach a exekuci workflow.
Workflow ve zdravotnictvi
Jak AI podporuje pacientske operace a kontinuitu pece.
Workflow v pojisteni
Prehled claim procesu, handoff kroku a automatizace odpovedi.
Workflow ve financnich sluzbach
Use-case scenare pro regulovane bankovni a financni operace.