Posúdenie poskytovateľa chatbota: Zmluva o spracovaní osobných údajov, subdodávatelia a prenosy do tretích krajín

Poskytovateľ chatbota môže predložiť presvedčivé demo, región EÚ a hotovú zmluvu o spracovaní osobných údajov (DPA) – a napriek tomu zostávajú kľúčové otázky otvorené. Údaje totiž nespracúva len viditeľný chatbot. Na poskytovaní služby sa často podieľajú modelové API, hosting, vektorové databázy, analýza chýb, nástroje podpory, e-mailové služby a zálohy. Pre prevádzkovateľov webových stránok je preto rozhodujúci overiteľný dodávateľský reťazec spracovania, nie marketingové frázy o ochrane osobných údajov na predajnej stránke.

Tento checklist pomáha pri štruktúrovanom posúdení poskytovateľa pred nákupom a spustením do prevádzky. Slúži ako praktická orientácia a nepredstavuje právne poradenstvo. Roly, právne základy, informačné povinnosti a mechanizmy prenosu sa musia posúdiť pre konkrétne nasadenie; pri zvýšenom riziku, osobitných kategóriách údajov alebo otvorených zmluvných otázkach treba prizvať zodpovednú osobu pre ochranu osobných údajov (DPO) alebo využiť kvalifikované právne poradenstvo.

Najprv pochopte dátový tok, potom hodnoťte zmluvu

Ústredná otázka neznie len „Kde sa nachádza server?“, ale: Aké osobné údaje sa kedy dostávajú k akej právnickej osobe, z akého dôvodu a na ako dlho? Návštevník môže v chate zadať mená, e-mailové adresy, zákaznícke čísla alebo voľný text. Okrem toho vznikajú IP adresy, časové pečiatky, informácie o zariadení, identifikátory relácie, história rozhovorov, hodnotenia a technické logy. Aj z údajne anonymného rozhovoru môže kombináciou viacerých znakov vzniknúť väzba na konkrétnu osobu.

Pred preskúmaním zmluvy si preto nakreslite jednoduchú mapu dátových tokov. Mala by obsahovať minimálne prehliadačový widget, platformu chatbota, bázu znalostí, poskytovateľa modelu, analytické a chybové služby, prístupy podpory, zálohy a cesty vymazania. Pre každú stanicu sa zaznamená prevádzkovateľ, krajina, účel, kategórie údajov, doba uchovávania a možné vzdialené prístupy. Tvrdenie o „hosting v EÚ“ napríklad neodpovedá na otázku, či tím podpory mimo Európskeho hospodárskeho priestoru môže pristupovať k produkčným logom.

Určite roly ochrany údajov pre každý účel

To, či je poskytovateľ sprostredkovateľom alebo pre jednotlivé účely sám prevádzkovateľom, vyplýva zo skutočnej činnosti. Usmernenia 07/2020 Európskeho výboru pre ochranu údajov (EDPB) vysvetľujú toto rozhraničenie. Poskytovateľ môže napríklad spracúvať dáta z rozhovorov na základe zdokumentovaných pokynov, ale pre určité vlastné bezpečnostné, zúčtovacie alebo produktové účely si môže nárokovať inú rolu. Nechajte si explicitne priradiť každý účel, príslušnú rolu a právny základ. Zmluva o spracovaní osobných údajov (DPA) automaticky nepokrýva samostatné účely poskytovateľa.

Kontrola zmluvy DPA: Povinný obsah musí zodpovedať reálnej službe

Článok 28 GDPR vyžaduje, aby prevádzkovatelia využívali len sprostredkovateľov, ktorí poskytujú dostatočné záruky na prijatie primeraných technických a organizačných opatrení. Zmluva musí okrem iného stanoviť predmet a dobu trvania, povahu a účel, typy údajov, kategórie dotknutých osôb, ako aj práva a povinnosti prevádzkovateľa. K tomu pristupujú zdokumentované pokyny, mlčanlivosť, bezpečnosť, súčinnosť pri právach dotknutých osôb a povinnostiach v oblasti ochrany údajov, vymazanie alebo vrátenie, ako aj informácie a súčinnosť pri auditoch.

Porovnajte DPA nielen s vzorovým zoznamom, ale s vašou mapou dátových tokov a skutočne predplateným balíkom služieb. Dobrá zmluva jednoznačne pomenúva prevádzku chatu, trénovanie resp. indexovanie bázy znalostí, logovanie, prístupy podpory a voliteľné funkcie. Nejasné zberné pojmy ako „zlepšovanie služieb“ by mali byť rozmenené na konkrétne údaje, účely, možnosti voľby a roly.

• Pokyny: Je jasné, že obsah a metadáta sa spracúvajú len na zdokumentované účely zákazníka? Aká konfigurácia sa považuje za pokyn?
• Využitie pre modely: Používajú sa výzvy (prompty), odpovede alebo nahraný obsah na všeobecné trénovanie modelov alebo vylepšovanie produktov? Ak nie, malo by to byť zmluvne a technicky overiteľné; ak áno, rola a právny základ sa musia posúdiť osobitne.
• Vymazanie: Existujú konkrétne lehoty pre históriu rozhovorov, logy, vektorové indexy, zálohy a kópie pre podporu? Čo sa stane po skončení zmluvy?
• Bezpečnosť: Sú popísané kontroly prístupu, oddelenie zákazníckych dát (tenant isolation), šifrovanie, logovanie, manažment zraniteľností a procesy riešenia incidentov?
• Súčinnosť: Upravuje DPA praktickým spôsobom export, opravu, vymazanie, prístup, bezpečnostné incidenty a prípadne posúdenie vplyvu na ochranu osobných údajov (DPIA)?
• Dôkazy: Sú k dispozícii správy z auditov, certifikácie alebo iné spoľahlivé doklady a vzťahujú sa presne na používané služby a lokality?

Certifikáty a správy z auditov môžu poskytnúť dôležité vodidlá, nenahrádzajú však ani preskúmanie konkrétneho procesu spracovania, ani primerané zmluvné doložky. Aj štandardizovaná zmluva DPA je len taká dobrá, ako jej vyplnené prílohy a zhoda s technickou realitou.

Subdodávatelia: Kontrola mien, úloh a zmien

Podľa článku 28 ods. 2 GDPR nesmie sprostredkovateľ zapojiť ďalšieho sprostredkovateľa bez predchádzajúceho osobitného alebo všeobecného písomného povolenia. Pri všeobecnom povolení musí informovať o zamýšľaných zmenách týkajúcich sa doplnenia alebo výmeny a poskytnúť možnosť namietania. Otázky a odpovede Európskej komisie k štandardným zmluvným doložkám navyše objasňujú, že samotné kategórie nestačia: jednotliví subdodávatelia musia byť konkrétne menovaní.

Vyžadujte aktuálny, exportovateľný zoznam s právnym názvom, krajinou, konkrétnou službou a dotknutými údajmi. Skontrolujte tiež, či je spoločnosť len zmluvným partnerom alebo skutočne spracúva dáta na viacerých miestach. Zvlášť relevantní sú poskytovatelia modelov a embeddingov, cloudový hosting, databázy, CDN, monitoring, analýza chýb, podpora, e-mail a zálohovanie. Pri každej položke musí byť zrejmé, či sa údaje ukladajú, iba prenášajú, alebo do nich môže nahliadnuť personál.

Do posúdenia patrí aj proces zmien: Ako sú zákazníci informovaní, aká je lehota vopred a čo sa stane v prípade odôvodnenej námietky? E-mail v deň zmeny bez technicky alebo zmluvne použiteľnej reakcie nemá veľkú hodnotu. Vyjasnite si, či je možná alternatívna konfigurácia, deaktivácia funkcie alebo v najhoršom prípade riadne ukončenie vrátane exportu dát. Pre ďalších subdodávateľov v reťazci musia byť postúpené rovnaké povinnosti ochrany údajov; prvý sprostredkovateľ zostáva voči prevádzkovateľovi zodpovedný za plnenie ich povinností.

Prenosy do tretích krajín: Skontrolujte mechanizmus a reálny účinok

Kapitola V GDPR sa vzťahuje na prenosy osobných údajov do tretích krajín a na ďalšie prenosy. Prenos nevzniká len trvalým uložením; relevantný môže byť aj administratívny prístup, prístup podpory alebo načítanie službou mimo EHP. Priraďte preto každej šípke v mape dátových tokov cieľovú krajinu, príjemcu a mechanizmus prenosu.

1. Rozhodnutie o primeranosti: Skontrolujte na priebežne aktualizovanom zozname Európskej komisie, či sú rozhodnutie, územie, sektor a konkrétny príjemca pokrytí. Pri obmedzených rámcoch nestačí len samotné sídlo v danej krajine.
2. Primerané záruky: Ak chýba vhodné rozhodnutie o primeranosti, do úvahy prichádzajú v závislosti od konštelácie nástroje podľa článku 46 GDPR. Často sa používajú štandardné zmluvné doložky Európskej komisie (SCC). Modul, zmluvné strany, prílohy, opis prenosu a technické opatrenia musia zodpovedať reálnemu reťazcu.
3. Test účinnosti: Podpísaný dokument SCC automaticky nekončí provierku. Finálne odporúčania EDPB 01/2020 popisujú proces založený na riziku: poznať prenosy, určiť nástroj, posúdiť právo a prax tretej krajiny, prípadne stanoviť doplňujúce opatrenia, vybaviť formálne kroky a pravidelne prehodnocovať.

Doplňujúce technické opatrenia musia zodpovedať konkrétnemu riziku. Šifrovanie má výpovednú hodnotu len vtedy, ak sa zohľadňuje správa kľúčov, prístupové práva a účel spracovania. Poskytovateľ modelu, ktorý musí spracúvať nešifrovaný text a sám má prístup ku kľúčom, je v inej situácii ako čisto šifrované zálohové úložisko. Paušálne vyhlásenia ako „AES-256“ alebo „v súlade s GDPR“ toto posúdenie nenahrádzajú. Výnimky podľa článku 49 GDPR taktiež nie sú pohodlnou štandardnou cestou pre plánované, opakujúce sa SaaS spracovanie.

Praktický príklad: región EÚ s globálnym reťazcom služieb

Predpokladajme, že chatbot ukladá svoju hlavnú databázu vo Frankfurte. Odpovede však generuje modelové API americkej spoločnosti, chybové hlásenia smerujú do ďalšej služby a globálny tím podpory môže pri eskalácii otvoriť protokoly rozhovorov. „Ukladanie dát v EÚ“ potom popisuje iba časť systému.

Due diligence oddeľuje štyri otázky: Aký obsah opúšťa EHP na generovanie odpovedí modelom? Ukladajú sa tam výzvy (prompty) alebo sa používajú na iné účely? Obsahujú chybové hlásenia nešifrovaný text, identifikátory alebo len minimalizované technické dáta? Za akých podmienok môže podpora pristupovať z krajín mimo EHP? Až potom je možné posúdiť prenosový nástroj, doplňujúce opatrenia a zostatkové riziko.

Technicky môže prevádzkovateľ webu riziko často znížiť: vypnúť nepotrebné polia v logoch, redigovať vstupy pred externými volaniami, nastaviť krátke lehoty uchovávania, oddeliť citlivé oblasti od verejného bota, izolovať zdroje znalostí podľa zákazníkov a logovať prístupy podpory s podmienkou schválenia. Ako čisto oddeliť verejného bota a zákaznícky portál, ukazuje článok Verejný AI chatbot vs. zákaznícky portál. Pre nahraté súbory dopĺňa posúdenie poskytovateľa checklist pre kontrolu súborov, ochranu údajov a handoff.

Rozhodnutie pomocou semaforu namiesto pocitov

Bod kontroly	Zelená	Žltá	Červená
Dátový tok	Úplný, aktuálny a viazaný na balík služieb	Jednotlivé prístupy alebo miesta uloženia nejasné	Len marketingové tvrdenie o regióne EÚ
Zmluva DPA	Účely, dáta, lehoty a súčinnosť sú konkrétne	Pred spustením sú potrebné doplnenia	Žiadna jasná viazanosť pokynmi ani pravidlá vymazania
Subdodávatelia	Menný zoznam s krajinou a úlohou	Nepraktický proces zmien	Iba kategórie alebo neznámy reťazec
Prenos do tretích krajín	Mechanizmus, rozsah a posúdenie doložené	Opatrenia je ešte potrebné overiť	„server v EÚ“ má vysvetliť všetky prenosy
Prevádzka	Vlastník, termín revízie a exit otestované	Dôkazy bez pevnej revízie	Žiadny monitoring po uzavretí zmluvy

Žltý bod nemusí automaticky hovoriť proti poskytovateľovi. Vyžaduje si však zodpovednú osobu, lehotu a overiteľné kritérium prevzatia. Červený bod v kľúčovom reťazci spracovania by mal zablokovať ostrý štart, kým sa neupraví zmluva, konfigurácia alebo výber poskytovateľa. Zdokumentujte aj akceptované zostatkové riziká a osobu, ktorá toto rozhodnutie prijala.

Kompaktný Go-live checklist pre prevádzkovateľov webu

• Mapa dátových tokov a roly pre každý účel sú schválené.
• DPA a prílohy zodpovedajú balíku služieb, funkciám, typom údajov a lehotám uchovávania.
• Všetci subdodávatelia sú menovite zdokumentovaní s krajinou, úlohou a spôsobom oznamovania zmien.
• Každý prenos do tretej krajiny má vhodný, aktuálne preverený mechanizmus a prípadne doplňujúce opatrenia.
• Trénovanie modelov alebo iné vlastné využitie chatových dát je vyjasnené a nakonfigurované podľa dohody.
• Logovanie, prístup podpory, export dát, vymazanie a ukončenie zmluvy boli prakticky otestované.
• Informácie o ochrane osobných údajov a rozhranie chatu vysvetľujú spracovanie zrozumiteľne; používatelia nie sú navádzaní na zadávanie zbytočných citlivých údajov.
• Je preverené, či je pre konkrétne nasadenie potrebné posúdenie vplyvu na ochranu údajov (DPIA).
• Určená zodpovedná osoba monitoruje zmeny týkajúce sa subdodávateľov, prenosových mechanizmov, funkcií a bezpečnostných dokladov.

Doplnkovo sa oplatí porovnanie so základným prehľadom AI chatbot a GDPR ako aj s návodom pre dátovo úspornú analytiku chatbota. Vďaka tomu sa obstarávanie, technická konfigurácia a bežná prevádzka neposudzujú ako oddelené projekty.

Pokračujte v kontrole aj po uzavretí zmluvy

Due diligence nie je jednorazový zakladač s PDF dokumentmi. Nastavte si minimálne pevný rytmus revízií a provierky vyvolané udalosťami. Spúšťačom sú noví subdodávatelia, iný poskytovateľ modelu, nové produktové funkcie, zmenené miesta uloženia, bezpečnostný incident, exspirujúce certifikáty alebo zmeny v rozhodnutí o primeranosti. Aktuálny zoznam subdodávateľov a kľúčové verzie zmlúv by mali byť archivované s dátumom, aby boli neskoršie zmeny spätne sledovateľné.

Praktické meradlo je jednoduché: Dokáže váš tím pri každom relevantnom dátovom toku vysvetliť, kto, čo a prečo spracúva, kde sa to deje, ako dlho údaje zostávajú, aké ochranné opatrenie platí a ako funguje prípadný exit? Ak sú tieto odpovede podložené dôkazmi, zo všeobecného tvrdenia o ochrane údajov sa stane spoľahlivé rozhodnutie o obstarávaní. Ak kľúčové stanice zostávajú neznáme, chatbot by ešte nemal pracovať s reálnymi dátami návštevníkov.