Natrag na blog
Usklađenost27. kolovoza 2026.9 min čitanjaAžurirano 30. kolovoza 2026.

Provjera davatelja usluge chatbota: DPA, podizvođači i prijenosi u treće zemlje

Praktičan popis za dubinsku provjeru vlasnika web stranica: Kako provjeriti DPA, podizvođače, tokove podataka i prijenose u treće zemlje prije uvođenja chatbota.

Davatelj usluge chatbota može imati uvjerljivu demonstraciju, regiju EU-a i spreman ugovor o obradi podataka (DPA) – no ključna pitanja i dalje ostaju otvorena. Jer podatke ne obrađuje samo vidljivi chatbot. Često su u pružanje usluge uključeni API-ji modela, hosting, vektorske baze podataka, analiza pogrešaka, alati za podršku, e-mail usluge i sigurnosne kopije. Za vlasnike web stranica stoga je važan provjerljivi lanac obrade, a ne buzzword o zaštiti podataka na prodajnoj stranici.

Ovaj popis za provjeru pomaže pri strukturiranoj provjeri davatelja usluge prije kupnje i pokretanja. Ona služi kao praktična orijentacija i nije pravni savjet. Uloge, pravne osnove, obveze informiranja i mehanizmi prijenosa moraju se provjeriti za konkretnu upotrebu; u slučaju povećanog rizika, posebnih kategorija podataka ili otvorenih ugovornih pitanja treba uključiti službenika za zaštitu podataka ili kvalificiranog pravnog savjetnika.

Odrasla stručnjakinja za nabavu provjerava tri zapečaćena crna transportna kofera ispred solarnih panela na sunčanom logističkom dvorištu.
Pouzdan pregled davatelja usluga povezuje ugovor, tok podataka i tehničke dokaze.

Prvo razumjeti tok podataka, zatim procijeniti ugovor

Središnje pitanje nije samo „Gdje se nalazi poslužitelj?“, nego: Koji osobni podaci stižu kojoj pravnoj osobi, kada, iz kojeg razloga i koliko dugo? Posjetitelj u chatu može unijeti imena, e-mail adrese, brojeve kupaca ili slobodan tekst. Osim toga, nastaju IP adrese, vremenske oznake, informacije o uređaju, identifikatori sesije, povijesti razgovora, ocjene i tehnički dnevnici. Čak i iz navodno anonimnog razgovora kombinacijom više obilježja može nastati povezanost s osobom.

Stoga prije pregleda ugovora nacrtajte jednostavnu kartu toka podataka. Ona bi trebala obuhvaćati barem widget preglednika, platformu chatbota, bazu znanja, davatelja modela, usluge analitike i pogrešaka, pristupe podršci, sigurnosne kopije i putanje brisanja. Za svaku postaju bilježe se operator, zemlja, svrha, kategorije podataka, razdoblje pohrane i mogući daljinski pristupi. Izjava o „hostingu u EU-u“, na primjer, ne odgovara na pitanje može li tim za podršku izvan Europskog gospodarskog prostora pristupiti produkcijskim dnevnicima.

Odrediti uloge u zaštiti podataka za svaku svrhu

Je li davatelj usluge izvršitelj obrade ili je za pojedine svrhe sam voditelj obrade, ovisi o njegovoj stvarnoj aktivnosti. Smjernice 07/2020 Europskog odbora za zaštitu podataka objašnjavaju tu razgraničenost. Davatelj usluge može, primjerice, obrađivati podatke o razgovorima prema dokumentiranim uputama, ali za određene vlastite sigurnosne, obračunske ili svrhe razvoja proizvoda zahtijevati drugačiju ulogu. Pobrinite se da se svaka svrha, odgovarajuća uloga i pravna osnova izričito dodijele. DPA ne pokriva automatski samostalne svrhe davatelja usluge.

Provjera DPA-a: Obvezni sadržaji moraju odgovarati stvarnoj usluzi

Članak 28. GDPR-a zahtijeva da voditelji obrade koriste samo izvršitelje obrade koji pružaju dostatna jamstva za provođenje odgovarajućih tehničkih i organizacijskih mjera. Ugovor mora, između ostalog, utvrditi predmet i trajanje, prirodu i svrhu, vrste podataka, kategorije ispitanika te prava i obveze voditelja obrade. Tome se pridodaju dokumentirane upute, povjerljivost, sigurnost, podrška pri ostvarivanju prava ispitanika i ispunjavanju obveza zaštite podataka, brisanje ili povrat te informacije i suradnja pri revizijama.

Usporedite DPA ne samo s predloškom, već i s vašom kartom toka podataka i stvarno ugovorenim paketom. Dobar ugovor jasno imenuje rad chatbota, treniranje odnosno indeksiranje baze znanja, bilježenje dnevnika, pristupe podršci i opcionalne funkcije. Nejasne zbirne pojmove poput „poboljšanja usluge“ treba raščlaniti na konkretne podatke, svrhe, mogućnosti izbora i uloge.

  • Uputa: Je li jasno da se sadržaj i metapodaci obrađuju samo u dokumentirane svrhe klijenta? Koja se konfiguracija smatra uputom?
  • Upotreba za modele: Koriste li se unosni tekstovi (prompti), odgovori ili preneseni sadržaji za opće treniranje modela ili poboljšanje proizvoda? Ako ne, to bi trebalo biti ugovorno i tehnički dokazivo; ako da, uloga i pravna osnova moraju se posebno procijeniti.
  • Brisanje: Postoje li konkretni rokovi za povijesti razgovora, dnevnike, vektorske indekse, sigurnosne kopije i kopije podrške? Što se događa nakon završetka ugovora?
  • Sigurnost: Jesu li opisane kontrole pristupa, izolacija klijenata (multi-tenancy), enkripcija, bilježenje dnevnika, upravljanje ranjivostima i procesi u slučaju incidenata?
  • Podrška: Uređuje li DPA praktično izvoz, ispravak, brisanje, pristup informacijama, sigurnosne incidente i, prema potrebi, procjene učinka na zaštitu podataka?
  • Dokazi: Jesu li dostupna izvješća o reviziji, certifikati ili drugi pouzdani dokazi i odnose li se oni točno na korištene usluge i lokacije?

Certifikati i izvješća o reviziji mogu pružiti važne indicije, ali ne zamjenjuju ni provjeru konkretnog postupka obrade ni odgovarajuće ugovorne klauzule. Čak je i standardizirani DPA dobar samo onoliko koliko su ispunjeni njegovi prilozi i u kojoj je mjeri u skladu s tehničkom stvarnošću.

Podizvođači (podobrađivači): Kontrola imena, zadataka i izmjena

Prema članku 28. stavku 2. GDPR-a, izvršitelj obrade ne smije angažirati drugog izvršitelja obrade bez prethodnog posebnog ili općeg pisanog odobrenja voditelja obrade. U slučaju općeg odobrenja, mora obavijestiti voditelja obrade o planiranim promjenama u pogledu dodavanja ili zamjene te dati mogućnost prigovora. Pitanja i odgovori Europske komisije o standardnim ugovornim klauzulama također pojašnjavaju da puke kategorije nisu dovoljne: pojedinačni podizvođači moraju biti imenovani.

Zatražite ažuran popis koji se može izvesti s pravnim nazivom, zemljom, konkretnom uslugom i obuhvaćenim podacima. Također provjerite je li tvrtka samo ugovorni partner ili stvarno obrađuje podatke na više lokacija. Posebno su relevantni pružatelji modela i ugrađivanja (embeddings), cloud hosting, baze podataka, CDN, nadzor, analiza pogrešaka, podrška, e-mail i sigurnosne kopije. Za svaki unos mora biti vidljivo pohranjuju li se podaci, samo prenose ili u njih osoblje može imati uvid.

Proces izmjena također ulazi u procjenu: Kako se obavještavaju klijenti, koliki je rok prethodne obavijesti i što se događa u slučaju opravdanog prigovora? E-mail na dan promjene bez tehnički ili ugovorno iskoristive reakcije ne vrijedi mnogo. Razjasnite je li moguća alternativna konfiguracija, deaktivacija funkcije ili, ako je potrebno, uredan raskid uz izvoz podataka. Za daljnje podizvođače moraju se prenijeti iste obveze zaštite podataka; prvi izvršitelj obrade ostaje odgovoran voditelju obrade za ispunjavanje njihovih obveza.

Prijenosi u treće zemlje: Provjeriti mehanizam i stvarni učinak

Poglavlje V. GDPR-a primjenjuje se na prijenose osobnih podataka u treće zemlje i na daljnje prijenose. Prijenos ne nastaje samo trajnom pohranom; administrativni pristup, pristup podršci ili dohvat od strane usluge izvan EGP-a također mogu biti relevantni. Stoga svakoj strelici u karti toka podataka dodijelite ciljnu zemlju, primatelja i mehanizam prijenosa.

  1. Odluka o adekvatnosti: Provjerite na redovito ažuriranom popisu Europske komisije jesu li odluka, područje, sektor i konkretni primatelj obuhvaćeni. Kod ograničenih okvira samo sjedište u nekoj zemlji nije dovoljno.
  2. Odgovarajuća jamstva: Ako nedostaje odgovarajuća odluka o adekvatnosti, ovisno o konstelaciji u obzir dolaze instrumenti iz članka 46. GDPR-a. Često se koriste Standardne ugovorne klauzule Europske komisije. Modul, stranke, prilozi, opis prijenosa i tehničke mjere moraju odgovarati stvarnom lancu.
  3. Provjera učinkovitosti: Potpisani SCC dokument ne završava automatski provjeru. Konačne Preporuke 01/2020 EDPB-a opisuju proces temeljen na riziku: upoznati prijenose, odrediti instrument, procijeniti pravo i praksu treće zemlje, prema potrebi utvrditi dodatne mjere, obaviti formalne korake i redovito iznova procjenjivati.

Dodatne tehničke mjere moraju odgovarati konkretnom riziku. Enkripcija je, primjerice, mjerodavna samo ako se uzmu u obzir upravljanje ključevima, prava pristupa i svrha obrade. Pružatelj modela koji mora obrađivati puni tekst u čitljivom obliku i sam ima pristup ključevima predstavlja drugačiju situaciju od čisto enkriptirane pohrane sigurnosnih kopija. Paušalne izjave poput „AES-256“ ili „usklađeno s GDPR-om“ ne zamjenjuju ovo razmatranje. Iznimke prema članku 49. GDPR-a također nisu prikladan uobičajeni put za planiranu, višekratnu SaaS obradu.

Praktični primjer: regija EU-a s globalnim lancem usluga

Pretpostavimo da chatbot svoju glavnu bazu podataka pohranjuje u Frankfurtu. Međutim, odgovore generira API modela američke tvrtke, izvješća o pogreškama šalju se drugoj usluzi, a globalni tim za podršku može otvoriti dnevnike razgovora u slučaju eskalacije. „Pohrana podataka u EU-u“ tada opisuje samo jedan dio sustava.

Due diligence razdvaja četiri pitanja: Koji sadržaji napuštaju EGP radi generiranja odgovora modelom? Pohranjuju li se tamo unosni tekstovi ili se koriste u druge svrhe? Sadrže li izvješća o pogreškama čitljiv tekst, identifikatore ili samo minimizirane tehničke podatke? Pod kojim uvjetima podrška izvan EGP-a može imati pristup podacima? Tek nakon toga mogu se procijeniti instrument prijenosa, dodatne mjere i preostala nesigurnost.

Tehnički gledano, vlasnik web stranice često može smanjiti rizik: isključiti nepotrebna polja dnevnika, redigirati unose prije vanjskih poziva, postaviti kratke rokove čuvanja, odvojiti osjetljiva područja od javnog bota, izolirati izvore znanja po klijentu i bilježiti pristupe podršci uz obvezu odobrenja. Kako uredno odvojiti javni bot i portal za klijente prikazuje članak Javni AI chatbot vs. portal za klijente. Za prenesene datoteke, popis za provjeru datoteka, zaštitu podataka i preusmjeravanje (handoff) dopunjuje provjeru davatelja usluge.

Odluka pomoću semafora umjesto osjećaja

Točka provjereZelenoŽutoCrveno
Tok podatakaPotpun, ažuran i vezan uz paketPojedinačni pristupi ili lokacije pohrane nerazjašnjeniSamo marketinška tvrdnja o regiji EU-a
DPASvrhe, podaci, rokovi i pomoć konkretniPotrebne dopune prije pokretanjaBez jasne vezanosti uz upute ili pravila brisanja
PodizvođačiPoimenični popis sa zemljom i zadatkomProces izmjena nepraktičanSamo kategorije ili nepoznat lanac
Prijenos u treće zemljeMehanizam, opseg i procjena dokazaniMjere još treba verificirati„poslužitelj u EU-u“ treba objasniti sve prijenose
Rad sustavaVlasnik, termin pregleda i izlaz testiraniDokazi bez fiksnog pregledaBez nadzora nakon sklapanja ugovora

Žuta točka ne mora automatski značiti odustajanje od davatelja usluge. No, zahtijeva odgovornu osobu, rok i provjerljivi kriterij prihvaćanja. Crvena točka u središnjem lancu obrade trebala bi blokirati početak rada u produkciji dok se ugovor, konfiguracija ili izbor davatelja usluge ne prilagode. Također dokumentirajte prihvaćene preostale rizike i osobu koja je donijela tu odluku.

Sažeti popis za provjeru prije pokretanja (Go-live) za vlasnike web stranica

  • Karta toka podataka i uloge po svrsi su odobreni.
  • DPA i prilozi odgovaraju paketu, funkcijama, vrstama podataka i rokovima čuvanja.
  • Svi podizvođači dokumentirani su poimence sa zemljom, zadatkom i postupkom obavještavanja o izmjenama.
  • Svaki prijenos u treću zemlju ima odgovarajući, trenutno provjereni mehanizam i, ako je potrebno, dodatne mjere.
  • Treniranje modela ili druga vlastita upotreba podataka iz chata je razjašnjena i konfigurirana kako je dogovoreno.
  • Bilježenje dnevnika, pristup podršci, izvoz podataka, brisanje i završetak ugovora praktično su testirani.
  • Obavijest o zaštiti podataka i sučelje chata objašnjavaju obradu na razumljiv način; korisnike se ne navodi na unos nepotrebnih osjetljivih podataka.
  • Provjereno je je li za konkretnu upotrebu potrebna procjena učinka na zaštitu podataka.
  • Vlasnik (owner) nadzire promjene kod podizvođača, mehanizama prijenosa, funkcija i dokaza o sigurnosti.

Dodatno se isplati usporedba s osnovnim pregledom AI chatbot i GDPR te s vodičem za analitiku chatbota uz štednju podataka. Time se nabava, tehnička konfiguracija i tekući rad ne tretiraju kao odvojeni projekti.

Nastavak provjere nakon sklapanja ugovora

Due diligence nije jednokratna mapa s PDF dokumentima. Utvrdite barem fiksni ritam pregleda i provjere temeljene na događajima. Okidači su novi podizvođači, drugi pružatelj modela, nove funkcije proizvoda, promijenjene lokacije pohrane, sigurnosni incident, isteknuli dokazi ili izmjene odluke o adekvatnosti. Aktualni popis podizvođača i središnje verzije ugovora trebali bi se arhivirati s datumom kako bi kasnije promjene ostale sljedive.

Praktično mjerilo je jednostavno: Može li vaš tim za svaki relevantni tok podataka objasniti tko što i zašto obrađuje, gdje se to događa, koliko dugo podaci ostaju, koja zaštitna mjera djeluje i kako funkcionira izlazak iz sustava? Ako su ti odgovori potkrijepljeni dokazima, opća tvrdnja o zaštiti podataka postaje pouzdana odluka o nabavi. Ako ključne postaje ostanu nepoznate, chatbot još ne bi trebao raditi sa stvarnim podacima posjetitelja.

Pretvorite posjete web-stranici u bolje razgovore

Pokrenite AI chatbota koji je koristan od prvog dana

Natrenirajte ChatReact vašom web-stranicom, dokumentima i potvrđenim činjenicama kako bi posjetitelji dobili brže odgovore, a vaš tim manje ponovljenih zahtjeva.

Povezani članci

Nastavite čitati