Pokalbių botų tiekėjų tikrinimas: DPA, duomenų subtvarkytojai ir duomenų perdavimas į trečiąsias šalis

Pokalbių boto tiekėjas gali pateikti įtikinančią demonstraciją, ES regioną ir parengtą duomenų tvarkymo sutartį (DPA) – ir vis tiek gali likti neatsakytų esminių klausimų. Taip yra todėl, kad duomenis tvarkyti gali ne tik matomas pokalbių botas. Paslaugos teikime dažnai dalyvauja modelių API, priegloba (hostingas), vektorių duomenų bazės, klaidų analizė, pagalbos įrankiai, el. pašto paslaugos ir atsarginės kopijos. Todėl svetainės valdytojui svarbiausia yra patikrinama duomenų tvarkymo grandinė, o ne privatumo šūkiai pardavimo puslapyje.

Šis kontrolinis sąrašas padeda struktūruotai patikrinti tiekėją prieš perkant paslaugą ir pradedant ją naudoti. Tai praktinis orientyras, o ne teisinė konsultacija. Vaidmenys, teisiniai pagrindai, informavimo prievolės ir perdavimo mechanizmai turi būti patikrinti konkrečiam naudojimo atvejui; esant didesnei rizikai, tvarkant specialiųjų kategorijų duomenis arba kilus neaiškumams dėl sutarties, reikėtų pasitelkti duomenų apsaugos pareigūną arba kvalifikuotą teisininką.

Pirmiausia supraskite duomenų srautą, tik tada vertinkite sutartį

Pagrindinis klausimas yra ne tik „Kur stovi serveris?“, bet ir: kokie asmens duomenys, kada, kokiam juridiniam asmeniui ir dėl kokios priežasties perduodami, taip pat kiek laiko jie saugomi? Lankytojas pokalbio lange gali įvesti vardus, el. pašto adresus, kliento numerius arba laisvą tekstą. Papildomai generuojami IP adresai, laiko žymos, įrenginio informacija, sesijų identifikatoriai, pokalbių istorija, įvertinimai ir techniniai logai. Net iš tariamai anoniminio pokalbio, sujungus kelis požymius, gali atsirasti sąsaja su asmeniu.

Todėl prieš tikrindami sutartį nusipieškite paprastą duomenų srauto žemėlapį. Jame turėtų būti bent naršyklės valdiklis (widget), pokalbių boto platforma, žinių bazė, modelio tiekėjas, analizės ir klaidų paslaugos, pagalbos komandos prieiga, atsarginės kopijos bei trynimo keliai. Kiekvienai stotelei užfiksuokite valdytoją, šalį, tikslą, duomenų kategorijas, saugojimo trukmę ir galimą nuotolinę prieigą. Pavyzdžiui, teiginys apie „ES hostingą“ neatsako į klausimą, ar pagalbos komanda iš už Europos ekonominės erdvės ribų gali pasiekti gamybinius logus.

Duomenų apsaugos vaidmenų nustatymas pagal tikslą

Tai, ar tiekėjas yra duomenų tvarkytojas, ar atskirais tikslais pats tampa duomenų valdytoju, priklauso nuo jo faktinės veiklos. Europos duomenų apsaugos valdybos gairės 07/2020 paaiškina šį diferencijavimą. Tiekėjas gali tvarkyti pokalbių duomenis pagal dokumentais įformintus nurodymus, tačiau tam tikriems savo saugumo, atsiskaitymo ar produkto tikslams teigti, kad jam tenka kitas vaidmuo. Užtikrinkite, kad kiekvienas tikslas, atitinkamas vaidmuo ir teisinis pagrindas būtų aiškiai priskirti. DPA automatiškai neapima savarankiškų tiekėjo tikslų.

DPA tikrinimas: privalomas turinys turi atitikti realią paslaugą

BDAR 28 straipsnis reikalauja, kad duomenų valdytojai naudotųsi tik tais tvarkytojais, kurie pakankamai garantuoja tinkamų techninių ir organizacinių priemonių taikymą. Sutartyje, be kita ko, turi būti nustatytas tvarkymo dalykas ir trukmė, pobūdis ir tikslas, duomenų tipai, duomenų subjektų kategorijos bei duomenų valdytojo teisės ir pareigos. Taip pat turi būti įtraukti dokumentuoti nurodymai, konfidencialumas, saugumas, pagalba užtikrinant duomenų subjektų teises ir duomenų apsaugos prievoles, duomenų ištrynimas arba grąžinimas bei informacija ir bendradarbiavimas atliekant auditus.

Palyginkite DPA ne tik su pavyzdiniu sąrašu, bet ir su savo duomenų srauto žemėlapiu bei faktiškai užsakytu paslaugų planu. Gera sutartis aiškiai įvardija pokalbių palaikymą, žinių bazės mokymą ar indeksavimą, registravimą (logging), pagalbos prieigas ir pasirenkamas funkcijas. Neaiškios bendros sąvokos, tokios kaip „paslaugų gerinimas“, turėtų būti išskaidytos į konkrečius duomenis, tikslus, pasirinkimo galimybes ir vaidmenis.

• Nurodymai: Ar aišku, kad turinys ir metaduomenys tvarkomi tik dokumentais pagrįstais kliento tikslais? Kokia konfigūracija laikoma nurodymu?
• Naudojimas modeliams: Ar užklausos (prompts), atsakymai ar įkeltas turinys naudojamas bendram modelių mokymui ar produkto gerinimui? Jei ne, tai turėtų būti sutartyje ir techniškai atsekama; jei taip, vaidmuo ir teisinis pagrindas turi būti įvertinti atskirai.
• Ištrynimas: Ar nustatyti konkretūs terminai pokalbių istorijai, logams, vektorių indeksams, atsarginėms kopijoms ir pagalbos sistemos kopijoms? Kas vyksta pasibaigus sutarčiai?
• Saugumas: Ar aprašyta prieigos kontrolė, klientų atskyrimas, šifravimas, registravimas, pažeidžiamumų valdymas ir incidentų procesai?
• Pagalba: Ar DPA praktiškai reglamentuoja eksportą, ištaisymą, ištrynimą, informavimą, saugumo incidentus ir, jei reikia, poveikio duomenų apsaugai vertinimą?
• Įrodymai: Ar yra prieinamos audito ataskaitos, sertifikatai ar kiti patikimi įrodymai ir ar jie galioja būtent naudojamoms paslaugoms bei vietoms?

Sertifikatai ir audito ataskaitos gali suteikti svarbios informacijos, tačiau nepakeičia nei konkretaus duomenų tvarkymo veiksmo patikrinimo, nei tinkamų sutarties sąlygų. Net ir standartinė DPA yra tik tiek gera, kiek užpildyti jos priedai ir kiek ji atitinka techninę realybę.

Duomenų subtvarkytojai: pavadinimų, užduočių ir pakeitimų kontrolė

Pagal BDAR 28 straipsnio 2 dalį duomenų tvarkytojas negali pasitelkti kito duomenų tvarkytojo be išankstinio konkretaus arba bendro raštiško duomenų valdytojo leidimo. Bendro leidimo atveju tvarkytojas turi informuoti apie planuojamus papildymus ar pakeitimus ir suteikti galimybę paprieštarauti. Europos Komisijos klausimuose ir atsakymuose dėl standartinių sutarties sąlygų taip pat aiškiai nurodyta, kad vien kategorijų nepakanka: turi būti nurodyti konkretūs duomenų subtvarkytojai.

Reikalaukite aktualaus, eksportuojamo sąrašo su teisiniu pavadinimu, šalimi, konkrečia paslauga ir susijusiais duomenimis. Taip pat patikrinkite, ar įmonė yra tik sutarties partneris, ar faktiškai tvarko duomenis keliose vietose. Ypač svarbūs yra modelių ir įterpinių (embedding) tiekėjai, debesijos priegloba, duomenų bazės, CDN, stebėsena (monitoringas), klaidų analizė, pagalba, el. paštas ir atsarginės kopijos. Kiekvienam įrašui turi būti aišku, ar duomenys saugomi, tik perduodami, ar gali būti peržiūrimi personalo.

Pakeitimų procesas taip pat turi būti vertinamas: kaip informuojami klientai, koks yra pranešimo terminas ir kas vyksta pagrįsto prieštaravimo atveju? El. laiškas pakeitimo dieną be techniškai ar sutartimi panaudojamos reakcijos galimybės yra mažai vertingas. Išsiaiškinkite, ar įmanoma alternatyvi konfigūracija, funkcijos išjungimas arba prireikus tvarkingas sutarties nutraukimas kartu su duomenų eksportu. Vėlesniems duomenų subtvarkytojams turi būti perduotos tos pačios duomenų apsaugos prievolės; pirminis duomenų tvarkytojas išlieka atsakingas duomenų valdytojui už jų prievolių įvykdymą.

Perdavimas į trečiąsias šalis: mechanizmo ir faktinio poveikio patikrinimas

BDAR V skyrius taikomas asmens duomenų perdavimui į trečiąsias šalis ir tolimesniam jų perdavimui. Perdavimas gali įvykti ne tik per ilgalaikį saugojimą; administracinė prieiga, pagalbos komandos prieiga arba duomenų gavimas per paslaugą už EEE ribų taip pat gali būti reikšmingas. Todėl kiekvienai strėlytei duomenų srauto žemėlapyje priskirkite paskirties šalį, gavėją ir perdavimo mechanizmą.

1. Tinkamumo sprendimas: Nuolat atnaujinamame Europos Komisijos sąraše patikrinkite, ar sprendimas apima šalį, teritoriją, sektorių ir konkretų gavėją. Esant ribotoms sistemoms, vien buvimo tam tikroje šalyje nepakanka.
2. Tinkamos apsaugos priemonės: Jei nėra tinkamo sprendimo dėl tinkamumo, priklausomai nuo situacijos taikomi BDAR 46 straipsnio priemonės. Dažnai naudojamos Europos Komisijos standartinės sutarties sąlygos (SCC). Modulis, šalys, priedai, perdavimo aprašymas ir techninės priemonės turi atitikti realią grandinę.
3. Veiksmingumo patikrinimas: Pasirašytas SCC dokumentas automatiškai neužbaigia patikrinimo. Galutinės EDAB rekomendacijos 01/2020 aprašo rizika grindžiamą procesą: žinoti perdavimus, nustatyti priemonę, įvertinti trečiosios šalies teisę ir praktiką, jei reikia, nustatyti papildomas priemones, atlikti formalumus ir reguliariai vertinti iš naujo.

Papildomos techninės priemonės turi atitikti konkrečią riziką. Pavyzdžiui, šifravimas yra prasmingas tik tada, kai atsižvelgiama į raktų valdymą, prieigos teises ir tvarkymo tikslą. Modelio tiekėjas, kuris turi tvarkyti atvirą tekstą ir pats gali pasiekti raktus, yra visai kas kita nei tik užšifruota atsarginių kopijų saugykla. Bendri teiginiai, tokie kaip „AES-256“ arba „atitinka BDAR“, šio vertinimo nepakeičia. BDAR 49 straipsnio išimtys taip pat nėra patogus standartinis būdas reguliariam, planuotam SaaS duomenų tvarkymui.

Praktinis pavyzdys: ES regionas su pasauline paslaugų grandine

Tarkime, pokalbių botas savo pagrindinę duomenų bazę saugo Frankfurte. Tačiau atsakymus generuoja JAV įmonės modelio API, klaidų ataskaitos siunčiamos kitai paslaugai, o pasaulinė pagalbos komanda iškilus problemoms gali atidaryti pokalbių logus. Tokiu atveju „duomenų saugojimas ES“ apibūdina tik dalį sistemos.

Due Diligence atskiria keturis klausimus: koks turinys palieka EEE modelio atsakymui sugeneruoti? Ar ten saugomos užklausos (prompts), ar naudojamos kitiems tikslams? Ar klaidų ataskaitose yra atviras tekstas, identifikatoriai, ar tik minimizuoti techniniai duomenys? Kokiomis sąlygomis pagalbos tarnyba už EEE ribų gali gauti prieigą? Tik po to galima įvertinti perdavimo priemonę, papildomas priemones ir likutinę riziką.

Techniškai svetainės valdytojas dažnai gali sumažinti riziką: išjungti nereikalingus logų laukus, redaguoti įvestis prieš išorinius kvietimus, nustatyti trumpus saugojimo terminus, atskirti jautrias sritis nuo viešo boto, izoliuoti žinių šaltinius pagal klientus ir registruoti pagalbos prieigas bei reikalauti joms patvirtinimo. Kaip švariai atskirti viešą botą ir kliento portalą, parodyta straipsnyje Viešas DI pokalbių botas vs. klientų portalas. Įkeltiems failams tiekėjo patikrinimą papildo kontrolinis sąrašas Failų patikrinimas, duomenų apsauga ir perdavimas skambučių centrui.

Sprendimas naudojant šviesoforo principą, o ne nuojautą

Patikros punktas	Žalia	Geltona	Raudona
Duomenų srautas	Visiškas, aktualus ir susijęs su tarifu	Kai kurios prieigos ar saugojimo vietos neaiškios	Tik rinkodaros teiginys apie ES regioną
DPA	Tikslai, duomenys, terminai ir pagalba konkrečiai apibrėžti	Reikia papildymų prieš pradedant naudoti	Nėra aiškaus nurodymų laikymosi ar ištrynimo
Duomenų subtvarkytojai	Sąrašas su pavadinimais, šalimi ir užduotimi	Pakeitimų procesas nepraktiškas	Tik kategorijos arba nežinoma grandinė
Perdavimas į trečiąsias šalis	Mechanizmas, apimtis ir vertinimas pagrįsti	Priemonės dar turi būti patikrintos	„ES serveris“ turi paaiškinti visus perdavimus
Eksploatacija	Atsakingas asmuo paskirtas, peržiūros data nustatyta, pasitraukimo procesas išbandytas	Įrodymai be fiksuotos peržiūros	Jokios stebėsenos sudarius sutartį

Geltonas taškas nebūtinai reiškia, kad tiekėjas netinka. Tačiau jam reikalingas atsakingas asmuo, terminas ir patikrinamas priėmimo kriterijus. Raudonas taškas esminėje duomenų tvarkymo grandinėje turėtų blokuoti gamybinį paleidimą, kol sutartis, konfigūracija ar tiekėjo pasirinkimas bus pakoreguoti. Taip pat dokumentuokite priimtą likutinę riziką ir asmenį, priėmusį šį sprendimą.

Kompaktiškas kontrolinis sąrašas svetainių valdytojams prieš paleidimą

• Duomenų srauto žemėlapis ir vaidmenys pagal tikslus yra patvirtinti.
• DPA ir priedai atitinka tarifą, funkcijas, duomenų tipus ir saugojimo terminus.
• Visi duomenų subtvarkytojai yra dokumentuoti nurodant pavadinimą, šalį, užduotį ir pakeitimo tvarką.
• Kiekvienas perdavimas į trečiąją šalį turi tinkamą, šiuo metu patikrintą mechanizmą ir, jei reikia, papildomas priemones.
• Modelių mokymas ar kitoks pokalbių duomenų naudojimas savo reikmėms yra išaiškintas ir sukonfigūruotas kaip sutarta.
• Registravimas, pagalbos prieiga, duomenų eksportas, ištrynimas ir sutarties pabaiga buvo praktiškai išbandyti.
• Duomenų apsaugos pranešimas ir pokalbių sąsaja suprantamai paaiškina duomenų tvarkymą; vartotojai neskatinami įvesti nereikalingų jautrių duomenų.
• Patikrinta, ar konkrečiam naudojimui reikalingas poveikio duomenų apsaugai vertinimas.
• Atsakingas asmuo (Owner) stebi duomenų subtvarkytojų, perdavimo mechanizmų, funkcijų ir saugumo įrodymų pakeitimus.

Papildomai verta palyginti su pagrindine apžvalga DI pokalbių botas ir BDAR bei su instrukcija dėl duomenis taupančios pokalbių boto analitikos. Taip pirkimas, techninė konfigūracija ir kasdienis darbas nebus traktuojami kaip atskiri projektai.

Tęskite tikrinimą ir sudarę sutartį

Due Diligence nėra vienkartinis PDF segtuvas. Nustatykite bent fiksuotą peržiūros ritmą ir įvykiais pagrįstus patikrinimus. Priežastys gali būti nauji duomenų subtvarkytojai, kitas modelio tiekėjas, naujos produkto funkcijos, pasikeitusios saugojimo vietos, saugumo incidentas, besibaigiantys įrodymai arba tinkamumo sprendimo pakeitimai. Aktualus duomenų subtvarkytojų sąrašas ir pagrindinės sutarties versijos turėtų būti archyvuojamos su data, kad vėlesni pakeitimai būtų atsekami.

Praktinis matas yra paprastas: ar jūsų komanda gali paaiškinti kiekvieną svarbų duomenų srautą – kas, ką ir kodėl tvarko, kur tai vyksta, kiek laiko duomenys išlieka, kokia apsaugos priemonė taikoma ir kaip veikia paslaugos atsisakymas? Jei šie atsakymai pagrįsti įrodymais, bendras teiginys apie duomenų apsaugą tampa patikimu pirkimo sprendimu. Jei pagrindinės stotelės lieka nežinomos, pokalbių botas dar neturėtų dirbti su tikrais lankytojų duomenimis.