Prověření poskytovatele chatbota: DPA, další zpracovatelé a předávání dat do třetích zemí

Poskytovatel chatbota může mít přesvědčivou ukázku, server v EU a připravenou smlouvu o zpracování osobních údajů (DPA) – a přesto mohou zůstat klíčové otázky nezodpovězeny. Data totiž nezpracovává pouze samotný viditelný chatbot. Na poskytování služby se často podílejí modelová API, hosting, vektorové databáze, analýza chyb, nástroje podpory, e-mailové služby a zálohy. Pro provozovatele webových stránek je proto rozhodující ověřitelný řetězec zpracování, nikoli jen marketingové fráze o ochraně osobních údajů na prodejní stránce.

Tento kontrolní seznam pomáhá se strukturovaným prověřením poskytovatele před nákupem a spuštěním. Slouží jako praktická orientace, nikoli jako právní poradenství. Role, právní základy, informační povinnosti a mechanismy předávání musí být posouzeny pro konkrétní použití; v případě zvýšeného rizika, zvláštních kategorií údajů nebo nejasných smluvních otázek byste měli zapojit pověřence pro ochranu osobních údajů nebo využít kvalifikované právní poradenství.

Nejprve pochopte datový tok, teprve pak hodnoťte smlouvu

Ústřední otázka nezní pouze „Kde stojí server?“, ale: Jaké osobní údaje se dostávají k jaké právnické osobě, kdy, z jakého důvodu a na jak dlouho? Návštěvník může do chatu zadat jména, e-mailové adresy, zákaznická čísla nebo volný text. Kromě toho vznikají IP adresy, časová razítka, informace o zařízení, identifikátory relací, historie konverzací, hodnocení a technické protokoly. I ze zdánlivě anonymní konverzace může kombinací několika znaků vzniknout vazba na konkrétní osobu.

Před přezkoumáním smlouvy si proto nakreslete jednoduchou mapu datových toků. Měla by obsahovat minimálně widget v prohlížeči, platformu chatbota, bázi znalostí, poskytovatele modelů, analytické a chybové služby, přístupy podpory, zálohy a cesty pro výmaz. Pro každou stanici zaznamenejte provozovatele, zemi, účel, kategorie údajů, dobu uchovávání a možné vzdálené přístupy. Tvrzení o „EU hostingu“ například neodpovídá na otázku, zda tým podpory mimo Evropský hospodářský prostor může přistupovat k produkčním protokolům.

Určete role v oblasti ochrany osobních údajů pro každý účel

Zda je poskytovatel zpracovatelem, nebo pro některé účely sám správcem, vyplývá ze skutečné činnosti. Pokyny 07/2020 Evropského sboru pro ochranu osobních údajů vysvětlují toto rozlišení. Poskytovatel může například zpracovávat data z konverzací na základě zdokumentovaných pokynů, ale pro určité vlastní bezpečnostní, zúčtovací nebo produktové účely požadovat jinou roli. Nechte explicitně přiřadit každý účel, příslušnou roli a právní základ. DPA automaticky nepokrývá samostatné účely poskytovatele.

KONTROLA DPA: Povinný obsah musí odpovídat reálné službě

Článek 28 GDPR vyžaduje, aby správci využívali pouze ty zpracovatele, kteří poskytují dostatečné záruky vhodných technických a organizačních opatření. Smlouva musí mimo jiné stanovit předmět a dobu trvání, povahu a účel, typy osobních údajů, kategorie subjektů údajů a práva a povinnosti správce. K tomu přistupují doložené pokyny, důvěrnost, bezpečnost, součinnost při uplatňování práv subjektů údajů a povinnostech v oblasti ochrany dat, výmaz nebo vrácení údajů a informace a součinnost při auditech.

Porovnejte DPA nejen se vzorovým seznamem, ale také s vaší mapou datových toků a skutečně zakoupeným tarifem. Dobrá smlouva srozumitelně popisuje provoz chatu, trénování nebo indexaci báze znalostí, protokolování, přístupy podpory a volitelné funkce. Nejasné souhrnné pojmy jako „zlepšování služeb“ by měly být rozpadnuty na konkrétní data, účely, možnosti volby a role.

• Pokyny: Je jasné, že obsah a metadata jsou zpracovávána pouze pro doložené účely zákazníka? Jaká konfigurace se považuje za pokyn?
• Využití pro modely: Jsou prompty, odpovědi nebo nahraný obsah využívány pro obecný trénink modelů nebo zlepšování produktů? Pokud ne, mělo by to být smluvně a technicky ověřitelné; pokud ano, musí být role a právní základ posouzeny samostatně.
• Výmaz: Existují konkrétní lhůty pro historii konverzací, logy, vektorové indexy, zálohy a kopie podpory? Co se stane po ukončení smlouvy?
• Bezpečnost: Jsou popsány řízení přístupu, oddělení dat jednotlivých zákazníků (tenancy), šifrování, protokolování, správa zranitelností a procesy řešení incidentů?
• Podpora: Upravuje DPA prakticky exporty, opravu, výmaz, poskytování informací, bezpečnostní incidenty a případně posouzení vlivu na ochranu osobních údajů (DPIA)?
• Důkazy: Jsou k dispozici auditorské zprávy, certifikace nebo jiné spolehlivé doklady a platí přesně pro využívané služby a lokality?

Certifikáty a auditorské zprávy mohou poskytnout cenné vodítko, nenahrazují však prověření konkrétního postupu zpracování ani odpovídající smluvní ujednání. I standardizovaná DPA je jen tak dobrá, jak dobře jsou vyplněny její přílohy a jak odpovídá technické realitě.

Další zpracovatelé: Kontrolujte jména, úkoly a změny

Podle čl. 28 odst. 2 GDPR nesmí zpracovatel zapojit do zpracování dalšího zpracovatele bez předchozího konkrétního nebo obecného písemného povolení správce. V případě obecného povolení musí zpracovatel informovat o veškerých zamýšlených změnách týkajících se přijetí dalších zpracovatelů nebo jejich nahrazení a poskytnout možnost vyslovit námitku. Otázky a odpovědi Evropské komise ke standardním smluvním doložkám navíc jasně stanovují, že pouhé kategorie nestačí: jednotliví další zpracovatelé musí být jmenovitě uvedeni.

Vyžadujte aktuální, exportovatelný seznam s právním názvem, zemí, konkrétní službou a dotčenými daty. Prověřte také, zda je společnost pouze smluvním partnerem, nebo zda skutečně zpracovává data na více místech. Zvláště relevantní jsou poskytovatelé modelů a embeddingů, cloudový hosting, databáze, CDN, monitoring, analýza chyb, podpora, e-mail a zálohování. U každé položky musí být patrné, zda se data ukládají, pouze přenášejí, nebo zda do nich může nahlížet personál.

Do posouzení patří i proces změn: Jak jsou zákazníci informováni, jaká je lhůta předem a co se stane v případě odůvodněné námitky? E-mail v den provedení změny bez možnosti technické nebo smluvní reakce má malou hodnotu. Ujasněte si, zda je možná alternativní konfigurace, deaktivace funkce nebo v krajním případě řádné ukončení smlouvy včetně exportu dat. Pro navazující další zpracovatele musí být předány stejné povinnosti v oblasti ochrany dat; prvotní zpracovatel zůstává vůči správci odpovědný za plnění jejich povinností.

Předávání do třetích zemí: Prověřte mechanismus a skutečný dopad

Kapitola V GDPR se vztahuje na předávání osobních údajů do třetích zemí a na další předávání. Předání nevzniká pouze trvalým uložením; relevantní může být i administrativní přístup, přístup podpory nebo načtení službou mimo EHP. Přiřaďte proto každé šipce v mapě datových toků cílovou zemi, příjemce a mechanismus předání.

1. Rozhodnutí o odpovídající ochraně: Zkontrolujte na průběžně aktualizovaném seznamu Evropské komise, zda rozhodnutí pokrývá dané území, sektor a konkrétního příjemce. U omezených rámců nestačí pouhá existence pobočky v dané zemi.
2. Vhodné záruky: Pokud chybí odpovídající rozhodnutí o odpovídající ochraně, přicházejí v úvahu v závislosti na konstelaci nástroje podle článku 46 GDPR. Často se používají Standardní smluvní doložky Evropské komise (SCC). Moduly, strany, přílohy, popis předání a technická opatření musí odpovídat reálnému řetězci.
3. Posouzení účinnosti: Podepsaný dokument SCC automaticky nekončí proces prověřování. Finální Doporučení EDPB 01/2020 popisují proces založený na riziku: zmapovat předávání, určit nástroj, posoudit právo a praxi třetí země, případně stanovit dodatečná opatření, vyřídit formální kroky a pravidelně provádět přehodnocení.

Dodatečná technická opatření musí odpovídat konkrétnímu riziku. Šifrování je například vypovídající pouze tehdy, pokud je zohledněna správa klíčů, přístupová práva a účel zpracování. Poskytovatel modelu, který musí zpracovávat nešifrovaný text a sám má přístup ke klíčům, představuje jinou situaci než čistě šifrované záložní úložiště. Paušální tvrzení jako „AES-256“ nebo „v souladu s GDPR“ toto posouzení nenahradí. Výjimky podle článku 49 GDPR rovněž nejsou pohodlným standardním řešením pro plánované, opakované zpracování v rámci SaaS.

Praktický příklad: Region EU s globálním řetězcem služeb

Předpokládejme, že chatbot ukládá svou hlavní databázi ve Frankfurtu. Odpovědi však generuje API modelu od americké společnosti, chybové zprávy odcházejí do další služby a globální tým podpory může při eskalaci otevřít protokoly konverzací. „Ukládání dat v EU“ pak popisuje pouze část systému.

Due diligence rozděluje čtyři otázky: Jaký obsah opouští EHP za účelem generování odpovědí modelem? Ukládají se tam prompty nebo se využívají pro jiné účely? Obsahují chybové zprávy nešifrovaný text, identifikátory nebo pouze minimalizovaná technická data? Za jakých podmínek může k datům přistupovat podpora mimo EHP? Teprve poté lze posoudit nástroj předání, dodatečná opatření a zbytkové riziko.

Technicky může provozovatel webu riziko často snížit: vypnout zbytečná pole logů, redigovat vstupy před externími voláními, nastavit krátké lhůty uchovávání, oddělit citlivé oblasti od veřejného bota, izolovat zdroje znalostí podle zákazníků a protokolovat přístupy podpory s nutností schválení. Jak čistě oddělit veřejného bota od zákaznického portálu, ukazujeme v článku Veřejný AI chatbot vs. zákaznický portál. Pro nahrané soubory doplňuje prověření poskytovatele kontrolní seznam pro kontrolu souborů, ochranu dat a handoff.

Rozhodování pomocí semaforu místo pocitů

Kritérium kontroly	Zelená	Žlutá	Červená
Datový tok	Kompletní, aktuální a vázaný na tarif	Jednotlivé přístupy nebo místa uložení nejasné	Pouze marketingové tvrzení o regionu EU
DPA	Účely, data, lhůty a součinnost konkrétní	Před spuštěním nutná doplnění	Bez jasné vázanosti na pokyny nebo pravidel výmazu
Další zpracovatelé	Jmenovitý seznam se zemí a úkolem	Proces změn nepraktický	Pouze kategorie nebo neznámý řetězec
Předávání do třetích zemí	Mechanismus, rozsah a posouzení doloženy	Opatření je ještě třeba ověřit	„EU server“ má vysvětlit všechna předávání
Provoz	Vlastník, termín revize a exit otestovány	Důkazy bez pevné revize	Žádný monitoring po uzavření smlouvy

Žlutý bod nemusí nutně znamenat odmítnutí poskytovatele. Vyžaduje však odpovědnou osobu, lhůtu a ověřitelné kritérium akceptace. Červený bod v ústředním řetězci zpracování by měl zablokovat ostrý start, dokud nebude upravena smlouva, konfigurace nebo výběr dodavatele. Zdokumentujte také akceptovaná zbytková rizika a osobu, která toto rozhodnutí učinila.

Kompaktní kontrolní seznam pro spuštění pro provozovatele webu

• Mapa datových toků a role pro jednotlivé účely jsou schváleny.
• DPA a její přílohy odpovídají tarifu, funkcím, typům dat a lhůtám uchovávání.
• Všichni další zpracovatelé jsou jmenovitě zdokumentováni se zemí, úkolem a způsobem oznamování změn.
• Každé předávání do třetí země má vhodný, aktuálně prověřený mechanismus a případně dodatečná opatření.
• Trénování modelů nebo jiné vlastní využití dat z chatu je vyjasněno a nakonfigurováno podle dohody.
• Protokolování, přístup podpory, export dat, výmaz a ukončení smlouvy byly prakticky otestovány.
• Informace o ochraně osobních údajů a rozhraní chatu vysvětlují zpracování srozumitelně; uživatelé nejsou naváděni k zadávání zbytečných citlivých dat.
• Je prověřeno, zda je pro konkrétní použití vyžadováno posouzení vlivu na ochranu osobních údajů (DPIA).
• Odpovědná osoba sleduje změny u dalších zpracovatelů, mechanismy předávání, funkce a doklady o bezpečnosti.

Kromě toho se vyplatí provést srovnání se základním přehledem AI chatbot a GDPR a také s návodem pro analytiku chatbota šetrnou k datům. Tím se zajistí, že nákup, technická konfigurace a běžný provoz nebudou řešeny jako oddělené projekty.

Průběžná kontrola i po uzavření smlouvy

Due diligence není jednorázová složka s PDF. Stanovte minimálně pevný cyklus revizí a prověrky na základě událostí. Spouštěči jsou noví další zpracovatelé, jiný poskytovatel modelů, nové funkce produktu, změněná místa uložení, bezpečnostní incident, vypršení platnosti dokladů nebo změny v rozhodnutí o odpovídající ochraně. Aktuální seznam dalších zpracovatelů a klíčové verze smluv by měly být archivovány s datem, aby byly pozdější změny dohledatelné.

Praktické měřítko je jednoduché: Dokáže váš tým u každého relevantního datového toku vysvětlit, kdo co a proč zpracovává, kde se tak děje, jak dlouho data zůstávají, jaká ochranná opatření fungují a jak probíhá ukončení služby? Pokud jsou tyto odpovědi doloženy, stane se z obecného tvrzení o ochraně dat podložené nákupní rozhodnutí. Pokud zůstávají klíčové stanice neznámé, chatbot by ještě neměl pracovat s reálnými daty návštěvníků.