Atpakaļ uz blogu
Atbilstība2026. gada 27. augusts9 min lasīšanaAtjaunināts 2026. gada 30. augusts

Čatbota piegādātāju pārbaude: Datu apstrādes līgums, apakšapstrādātāji un trešo valstu datu pārsūtīšana

Praktisks rūpības (due diligence) pārbaudes saraksts tīmekļa vietņu uzturētājiem: Kā pārbaudīt DAL, apakšapstrādātājus, datu plūsmas un trešo valstu pārsūtīšanu pirms čatbota ieviešanas.

Čatbota piegādātājs var uzrādīt pārliecinošu demo versiju, ES reģionu un gatavu Datu apstrādes līgumu (DAL) – un tomēr izšķiroši jautājumi paliek neatbildēti. Jo datus apstrādā ne tikai redzamais čatbots. Bieži vien pakalpojuma nodrošināšanā ir iesaistīti modeļu API, hostings, vektoru datubāzes, kļūdu analīzes rīki, atbalsta rīki, e-pasta pakalpojumi un rezerves kopijas. Tīmekļa vietņu uzturētājiem tāpēc svarīga ir pārbaudāma apstrādes ķēde, nevis datu aizsardzības sauklis pārdošanas lapā.

Šis pārbaudes saraksts palīdz veikt strukturētu piegādātāja pārbaudi pirms iegādes un palaišanas. Tā ir praktiska orientācija, nevis juridiska konsultācija. Lomas, juridiskie pamati, informēšanas pienākumi un pārsūtīšanas mehānismi ir jāpārbauda konkrētajam lietojumam; paaugstināta riska, īpašu datu kategoriju vai neskaidru līguma jautājumu gadījumā jāiesaista datu aizsardzības speciālisti vai kvalificēti juriskonsulti.

Pieaugusi iepirkumu eksperte saulainā loģistikas pagalmā pie saules paneļiem pārbauda trīs aizzīmogotus melnus transportēšanas koferus.
Uzticama piegādātāja pārbaude apvieno līgumu, datu plūsmu un tehniskos pierādījumus.

Vispirms izprotiet datu plūsmu, pēc tam izvērtējiet līgumu

Galvenais jautājums nav tikai "Kur atrodas serveris?", bet gan: Kādi personas dati, kad, kurai juridiskajai personai un kāda iemesla dēļ nonāk, kā arī cik ilgi tie tiek glabāti? Apmeklētājs čatā var ievadīt vārdus, e-pasta adreses, klientu numurus vai brīvu tekstu. Papildus veidojas IP adreses, laika spiedogi, ierīču informācija, sesiju identifikatori, sarunu vēsture, vērtējumi un tehniskie protokoli. Arī no šķietami anonīmas sarunas, apvienojot vairākas pazīmes, var izveidoties sasaiste ar personu.

Tāpēc pirms līguma pārbaudes uzzīmējiet vienkāršu datu plūsmas karti. Tajā jāiekļauj vismaz pārlūkprogrammas logrīks, čatbota platforma, zināšanu bāze, modeļa piegādātājs, analītikas un kļūdu pakalpojumi, atbalsta personāla piekļuve, rezerves kopijas, kā arī dzēšanas ceļi. Katrai stacijai tiek reģistrēts operators, valsts, mērķis, datu kategorijas, glabāšanas ilgums un iespējamā attālinātā piekļuve. Paziņojums par "ES hostingu", piemēram, neatbild uz jautājumu, vai atbalsta komanda ārpus Eiropas Ekonomikas zonas var piekļūt produkcijas vides žurnāliem.

Datu aizsardzības lomu noteikšana katram mērķim

Tas, vai piegādātājs ir apstrādātājs vai atsevišķiem mērķiem pats ir pārzinis, izriet no faktiskās darbības. Eiropas Datu aizsardzības kolēģijas pamatnostādnes 07/2020 skaidro šo nošķīrumu. Piegādātājs var, piemēram, apstrādāt sarunu datus saskaņā ar dokumentētiem norādījumiem, bet noteiktiem saviem drošības, norēķinu vai produkta mērķiem uzņemties citu lomu. Pieprasiet skaidri nošķirt katru mērķi, attiecīgo lomu un juridisko pamatu. DAL automātiski nenosedz piegādātāja patstāvīgos mērķus.

DAL pārbaude: Obligātajam saturam jāatbilst reālajam pakalpojumam

VDAR 28. pants pieprasa, lai pārziņi izmantotu tikai tādus apstrādātājus, kas sniedz pietiekamas garantijas par atbilstošiem tehniskajiem un organizatoriskajiem pasākumiem. Līgumā cita starpā jānosaka apstrādes priekšmets un ilgums, veids un mērķis, datu veidi, datu subjektu kategorijas, kā arī pārziņa tiesības un pienākumi. Tāpat jābūt dokumentētiem norādījumiem, konfidencialitātei, drošībai, atbalstam datu subjektu tiesību nodrošināšanā un datu aizsardzības pienākumiem, dzēšanai vai atdošanai, kā arī informācijai un līdzdalībai auditā.

Salīdziniet DAL ne tikai ar parauga sarakstu, bet arī ar savu datu plūsmas karti un faktiski izvēlēto tarifu plānu. Labs līgums saprotami raksturo čata darbību, zināšanu bāzes apmācību vai indeksēšanu, žurnālfailu veidošanu, atbalsta personāla piekļuvi un papildu funkcijas. Neskaidri vispārīgi jēdzieni, piemēram, "pakalpojuma uzlabošana", būtu jāsadala konkrētos datos, mērķos, izvēles iespējās un lomās.

  • Norādījumi: Vai ir skaidrs, ka saturs un metadati tiek apstrādāti tikai dokumentētiem klienta mērķiem? Kāda konfigurācija skaitās kā norādījums?
  • Izmantošana modeļiem: Vai uzvednes (prompts), atbildes vai augšupielādētais saturs tiek izmantots vispārējai modeļu apmācībai vai produkta uzlabošanai? Ja nē, tam jābūt līgumā un tehniski izsekojamam; ja jā, loma un juridiskais pamats jāvērtē atsevišķi.
  • Dzēšana: Vai ir konkrēti termiņi sarunu vēsturei, logfailiem, vektoru indeksiem, rezerves kopijām un atbalsta kopijām? Kas notiek pēc līguma izbeigšanās?
  • Drošība: Vai ir aprakstīta piekļuves kontrole, klientu nodalīšana, šifrēšana, žurnālieraksti, ievainojamību pārvaldība un incidentu procesi?
  • Atbalsts: Vai DAL praktiski regulē eksportu, labošanu, dzēšanu, informācijas sniegšanu, drošības incidentus un nepieciešamības gadījumā novērtējumu par ietekmi uz datu aizsardzību?
  • Pierādījumi: Vai ir pieejami audita ziņojumi, sertifikāti vai citi ticami pierādījumi un vai tie attiecas tieši uz izmantotajiem pakalpojumiem un atrašanās vietām?

Sertifikāti un pārbaudes ziņojumi var sniegt svarīgas norādes, taču tie neaizstāj ne konkrētā apstrādes procesa pārbaudi, ne atbilstošas līguma klauzulas. Arī standartizēts DAL ir tikai tik labs, cik labi ir tā aizpildītie pielikumi un atbilstība tehniskajai realitātei.

Apakšapstrādātāji: Nosaukumu, uzdevumu un izmaiņu kontrole

Saskaņā ar VDAR 28. panta 2. punktu apstrādātājs nedrīkst piesaistīt citu apstrādātāju bez iepriekšējas specifiskas vai vispārējas rakstiskas pārziņa atļaujas. Vispārējas atļaujas gadījumā apstrādātājs informē pārzini par jebkurām plānotajām izmaiņām attiecībā uz citu apstrādātāju pievienošanu vai nomaiņu, tādējādi dodot pārzinim iespēju iebilst. Eiropas Komisijas jautājumi un atbildes par līguma standartklauzulām arī skaidri norāda, ka ar vienkāršām kategorijām nepietiek: katram apakšapstrādātājam jābūt nosauktam vārdā.

Pieprasiet pašreizējo, eksportējamo sarakstu ar juridisko nosaukumu, valsti, konkrēto pakalpojumu un skartajiem datiem. Pārbaudiet arī, vai uzņēmums ir tikai līgumpartneris vai faktiski veic apstrādi vairākās vietās. Īpaši svarīgi ir modeļu un iegulšanas (embedding) nodrošinātāji, mākoņhostings, datubāzes, CDN, monitorings, kļūdu analīze, atbalsts, e-pasts un rezerves kopēšana. Katram ierakstam jābūt skaidram, vai dati tiek glabāti, tikai pārsūtīti vai tos var apskatīt personāls.

Izmaiņu process arī ir daļa no novērtējuma: Kā klienti tiek informēti, cik ilgs ir paziņošanas termiņš un kas notiek pamatota iebilduma gadījumā? E-pasts izmaiņu dienā bez tehniski vai līgumiski izmantojamas reakcijas iespējas ir mazvērts. Noskaidrojiet, vai ir iespējama alternatīva konfigurācija, funkcijas deaktivizēšana vai sliktākajā gadījumā sakārtota līguma izbeigšana ar datu eksportu. Nākamā līmeņa apakšapstrādātājiem ir jānodod tālāk tie paši datu aizsardzības pienākumi; pirmais apstrādātājs paliek atbildīgs pārziņa priekšā par to pienākumu izpildi.

Datu pārsūtīšana uz trešajām valstīm: Pārbaudiet mehānismu un faktisko ietekmi

VDAR V nodaļa attiecas uz personas datu nosūtīšanu uz trešajām valstīm un tālāku nosūtīšanu. Datu pārsūtīšana var notikt ne tikai ar ilgstošu glabāšanu; arī administratīvā piekļuve, atbalsta personāla piekļuve vai datu ieguve, ko veic pakalpojums ārpus EEZ var būt būtiska. Tāpēc katrai bultiņai datu plūsmas kartē piešķiriet mērķa valsti, saņēmēju un pārsūtīšanas mehānismu.

  1. Lēmums par aizsardzības līmeņa pietiekamību: Pārbaudiet pastāvīgi atjauninātajā Eiropas Komisijas sarakstā, vai lēmums, teritorija, sektors un konkrētais saņēmējs ir ietverti. Ierobežotu sistēmu gadījumā ar vienkāršu pārstāvniecību kādā valstī nepietiek.
  2. Atbilstošas garantijas: Ja nav piemērota lēmuma par pietiekamību, atkarībā no situācijas var apsvērt VDAR 46. panta instrumentus. Bieži tiek izmantotas Eiropas Komisijas līguma standartklauzulas (SCC). Modulim, pusēm, pielikumiem, pārsūtīšanas aprakstam un tehniskajiem pasākumiem jāatbilst reālajai ķēdei.
  3. Efektivitātes pārbaude: Parakstīts SCC dokuments automātiski nebeidz pārbaudi. Galīgās EDAK ieteikumi 01/2020 apraksta uz risku balstītu procesu: pārsūtīšanas apzināšana, instrumenta noteikšana, trešās valsts tiesību un prakses novērtēšana, nepieciešamības gadījumā papildu pasākumu noteikšana, formālo soļu veikšana un regulāra pārvērtēšana.

Papildu tehniskajiem pasākumiem jāatbilst konkrētajam riskam. Šifrēšana, piemēram, ir nozīmīga tikai tad, ja tiek ņemta vērā atslēgu pārvaldība, piekļuves tiesības un apstrādes mērķis. Modeļa piegādātājs, kuram jāapstrādā skaidrs teksts un kurš pats var piekļūt atslēgām, ir cita situācija nekā tīra šifrēta rezerves kopiju krātuve. Vispārīgi paziņojumi, piemēram, "AES-256" vai "atbilst VDAR", neaizstāj šo izvērtējumu. VDAR 49. panta izņēmumi arī nav ērts standarta veids plānotai, regulārai SaaS apstrādei.

Praktisks piemērs: ES reģions ar globālu pakalpojumu ķēdi

Pieņemsim, ka čatbots savu galveno datubāzi glabā Frankfurtē. Tomēr atbildes ģenerē ASV uzņēmuma modeļa API, kļūdu ziņojumi nonāk citā pakalpojumā, un globālā atbalsta komanda eskalācijas gadījumā var atvērt sarunu protokolus. Tādā gadījumā "Datu glabāšana ES" raksturo tikai daļu no sistēmas.

Pienācīga rūpība (due diligence) nošķir četrus jautājumus: Kāds saturs pamet EEZ modeļa atbildes ģenerēšanai? Vai tur tiek glabātas uzvednes vai izmantotas citiem mērķiem? Vai kļūdu ziņojumi satur skaidru tekstu, identifikatorus vai tikai minimizētus tehniskos datus? Ar kādiem nosacījumiem atbalsta dienests ārpus EEZ var piekļūt datiem? Tikai pēc tam var novērtēt pārsūtīšanas instrumentu, papildu pasākumus un atlikušo risku.

Tehniski tīmekļa vietnes uzturētājs bieži var samazināt risku: atslēgt nevajadzīgus žurnālu laukus, rediģēt ievadi pirms ārējiem izsaukumiem, iestatīt īsus glabāšanas termiņus, nošķirt jutīgas zonas no publiskā bota, izolēt zināšanu avotus atbilstoši klientam un protokolēt atbalsta personāla piekļuvi ar nepieciešamu apstiprinājumu. Kā tīri nošķirt publisko botu no klientu portāla, parādīts rakstā Publisks AI čatbots vs. klientu portāls. Augšupielādētajiem failiem piegādātāju pārbaudi papildina pārbaudes saraksts par failu pārbaudi, datu aizsardzību un nodošanu darbiniekiem (handoff).

Lēmums ar luksoforu, nevis intuīciju

Pārbaudes punktsZaļšDzeltensSarkans
Datu plūsmaPilnīga, aktuāla un saistīta ar tarifuAtsevišķas piekļuves vai glabāšanas vietas nav skaidrasTikai mārketinga paziņojums par ES reģionu
DALMērķi, dati, termiņi un palīdzība ir konkrētiPirms palaišanas nepieciešami papildinājumiNav skaidru norādījumu vai dzēšanas nosacījumu
ApakšapstrādātājiSaraksts ar nosaukumiem, valsti un uzdevumuIzmaiņu process ir nepraktisksTikai kategorijas vai nezināma ķēde
Datu pārsūtīšana uz trešajām valstīmMehānisms, apjoms un vērtējums ir pamatotiPasākumi vēl jāverificē"ES serverim" vajadzētu izskaidrot visas pārsūtīšanas
DarbībaAtbildīgais ir noteikts, pārskatīšanas datums fiksēts un izejas process pārbaudītsPierādījumi bez fiksētas pārskatīšanasNav monitoringa pēc līguma noslēgšanas

Dzeltens punkts automātiski nenozīmē, ka piegādātājs nav piemērots. Taču tam nepieciešams atbildīgais, termiņš un pārbaudāms pieņemšanas kritērijs. Sarkanajam punktam centrālajā apstrādes ķēdē vajadzētu bloķēt darbības uzsākšanu, līdz tiek pielāgots līgums, konfigurācija vai piegādātāja izvēle. Dokumentējiet arī pieņemtos atlikušos riskus un personu, kura pieņēmusi šo lēmumu.

Kompakts pārbaudes saraksts pirms palaišanas tīmekļa vietņu uzturētājiem

  • Datu plūsmas karte un lomas katram mērķim ir apstiprinātas.
  • DAL un tā pielikumi atbilst tarifam, funkcijām, datu veidiem un glabāšanas termiņiem.
  • Visi apakšapstrādātāji ir dokumentēti pēc nosaukuma, valsts, uzdevuma un izmaiņu kārtības.
  • Katrai datu pārsūtīšanai uz trešo valsti ir atbilstošs, pašlaik pārbaudīts mehānisms un, ja nepieciešams, papildu pasākumi.
  • Modeļa apmācība vai cita čata datu izmantošana savām vajadzībām ir noskaidrota un nokonfigurēta kā norunāts.
  • Žurnālieraksti, atbalsta personāla piekļuve, datu eksports, dzēšana un līguma izbeigšana ir praktiski pārbaudīti.
  • Datu aizsardzības paziņojumi un čata saskarne saprotami izskaidro apstrādi; lietotāji netiek mudināti ievadīt nevajadzīgus jutīgus datus.
  • Ir pārbaudīts, vai konkrētajam lietojumam ir nepieciešams novērtējums par ietekmi uz datu aizsardzību.
  • Atbildīgā persona uzrauga izmaiņas apakšapstrādātāju sarakstā, pārsūtīšanas mehānismos, funkcijās un drošības apliecinājumos.

Papildus ir vērts salīdzināt ar pamata pārskatu AI čatbots un VDAR, kā arī pamācību par datus taupošu čatbota analītiku. Tādējādi iegāde, tehniskā konfigurācija un kārtējā ekspluatācija netiek uztverti kā atsevišķi projekti.

Turpiniet pārbaudi arī pēc līguma noslēgšanas

Pienācīga rūpība nav vienreizēja PDF mape. Iestatiet vismaz regulāru pārbaudes ritmu un notikumu izraisītas pārbaudes. Iemesli pārbaudei ir jauni apakšapstrādātāji, cits modeļa piegādātājs, jaunas produkta funkcijas, izmainītas glabāšanas vietas, drošības incidents, pierādījumu derīguma termiņa beigas vai izmaiņas lēmumā par aizsardzības līmeņa pietiekamību. Pašreizējais apakšapstrādātāju saraksts un galvenās līgumu versijas jāarhivē ar datumu, lai vēlākas izmaiņas būtu izsekojamas.

Praktiskais kritērijs ir vienkāršs: Vai jūsu komanda katrai būtiskajai datu plūsmai var izskaidrot, kurš ko un kāpēc apstrādā, kur tas notiek, cik ilgi dati paliek, kāds aizsardzības pasākums darbojas un kā notiek pakalpojuma izbeigšana? Ja šīs atbildes ir pamatotas, vispārīgs paziņojums par datu aizsardzību kļūst par pamatotu iepirkuma lēmumu. Ja galvenās stacijas paliek nezināmas, čatbotam vēl nevajadzētu strādāt ar reāliem apmeklētāju datiem.

Pārvērtiet vietnes apmeklējumus par labākām sarunām

Palaidiet AI čata robotu, kas ir noderīgs no pirmās dienas

Apmāciet ChatReact ar savu vietni, dokumentiem un apstiprinātiem faktiem, lai apmeklētāji saņemtu ātrākas atbildes, un jūsu komanda saņem mazāk atkārtotu pieprasījumu.

Saistītie raksti

Turpināt lasīt