Evaluarea furnizorilor de chatbot: DPA, subprocesatori și transferuri către țări terțe

Un furnizor de chatbot poate prezenta un demo convingător, o regiune UE și un acord de prelucrare a datelor (DPA) gata pregătit – și totuși rămân întrebări cruciale fără răspuns. Pentru că nu doar chatbot-ul vizibil prelucrează date. Frecvent, API-urile modelelor, găzduirea, bazele de date vectoriale, analiza erorilor, instrumentele de suport, serviciile de e-mail și backup-urile sunt implicate în furnizarea serviciului. Pentru administratorii de site-uri web, ceea ce contează este lanțul de prelucrare verificabil, nu un slogan despre protecția datelor pe o pagină de vânzări.

Această listă de verificare ajută la o evaluare structurată a furnizorilor înainte de achiziție și lansare. Este un ghid practic și nu reprezintă consultanță juridică. Rolurile, temeiurile juridice, obligațiile de informare și mecanismele de transfer trebuie verificate pentru cazul specific de utilizare; în caz de risc crescut, categorii speciale de date sau clauze contractuale neclare, trebuie implicați responsabilii cu protecția datelor sau consilieri juridici calificați.

Înțelegeți mai întâi fluxul de date, apoi evaluați contractul

Întrebarea centrală nu este doar „Unde se află serverul?”, ci: Ce date cu caracter personal ajung, când, la ce persoană juridică, din ce motiv și pentru cât timp? Un vizitator poate introduce în chat nume, adrese de e-mail, numere de client sau text liber. În plus, se generează adrese IP, mărci temporale, informații despre dispozitiv, identificatori de sesiune, istoricul conversațiilor, evaluări și jurnale tehnice. Chiar și dintr-o conversație presupus anonimă poate rezulta o identificare personală prin combinarea mai multor caracteristici.

De aceea, desenați o hartă simplă a fluxului de date înainte de a analiza contractul. Aceasta ar trebui să includă cel puțin widget-ul din browser, platforma chatbotului, baza de cunoștințe, furnizorul modelului, serviciile de analiză și de raportare a erorilor, accesul pentru suport, backup-urile și căile de ștergere. Pentru fiecare etapă se înregistrează operatorul, țara, scopul, categoriile de date, durata de stocare și posibilele accesări de la distanță. De exemplu, o afirmație privind „găzduirea în UE” nu răspunde la întrebarea dacă o echipă de suport din afara Spațiului Economic European poate accesa jurnalele de producție.

Determinați rolurile de protecție a datelor pentru fiecare scop

Dacă un furnizor este persoană împuternicită de operator sau este el însuși operator independent pentru anumite scopuri rezultă din activitatea sa reală. Ghidul 07/2020 al Comitetului European pentru Protecția Datelor clarifică această delimitare. De exemplu, un furnizor poate prelucra datele conversaționale pe baza instrucțiunilor documentate, dar poate revendica un alt rol pentru propriile scopuri de securitate, facturare sau dezvoltare de produse. Asigurați-vă că fiecare scop, rolul aferent și temeiul juridic sunt atribuite în mod explicit. Un DPA nu acoperă automat scopurile independente ale furnizorului.

Verificarea DPA: Conținutul obligatoriu trebuie să corespundă serviciului real

Articolul 28 din GDPR impune operatorilor să recurgă doar la persoane împuternicite care oferă garanții suficiente pentru punerea în aplicare a unor măsuri tehnice și organizatorice adecvate. Contractul trebuie să stabilească, printre altele, obiectul și durata, natura și scopul, tipurile de date, categoriile de persoane vizate, precum și drepturile și obligațiile operatorului. La acestea se adaugă instrucțiunile documentate, confidențialitatea, securitatea, asistența pentru exercitarea drepturilor persoanelor vizate și îndeplinirea obligațiilor privind protecția datelor, ștergerea sau returnarea, precum și informațiile și cooperarea pentru audituri.

Comparați acordul DPA nu doar cu o listă tipizată, ci cu harta fluxului de date și cu planul tarifar achiziționat efectiv. Un contract bun precizează în mod clar funcționarea chatului, antrenarea sau indexarea bazei de cunoștințe, jurnalizarea, accesul pentru suport și funcțiile opționale. Termenii vagi precum „îmbunătățirea serviciului” ar trebui detaliați în date concrete, scopuri, opțiuni de configurare și roluri.

• Instrucțiuni: Este clar că conținutul și metadatele sunt prelucrate numai în scopurile documentate ale clientului? Ce configurație este considerată instrucțiune?
• Utilizarea pentru modele: Sunt folosite prompturile, răspunsurile sau fișierele încărcate pentru antrenarea generală a modelelor sau pentru îmbunătățirea produsului? Dacă nu, acest lucru ar trebui să fie verificabil contractual și tehnic; dacă da, rolul și temeiul juridic trebuie evaluate separat.
• Ștergere: Există termene concrete pentru istoricul chatului, jurnale, indici vectoriali, backup-uri și copii de suport? Ce se întâmplă la încetarea contractului?
• Securitate: Sunt descrise controlul accesului, separarea clienților (multi-tenancy), criptarea, jurnalizarea, gestionarea vulnerabilităților și procesele de gestionare a incidentelor?
• Asistență: Reglementează DPA în mod practic exportul, rectificarea, ștergerea, dreptul de acces, incidentele de securitate și, dacă este cazul, evaluarea impactului asupra protecției datelor (DPIA)?
• Dovezi: Sunt disponibile rapoarte de audit, certificări sau alte dovezi solide și se aplică acestea exact serviciilor și locațiilor utilizate?

Certificatele și rapoartele de audit pot furniza indicii importante, dar nu înlocuiesc nici verificarea procesului specific de prelucrare, nici clauzele contractuale adecvate. Un DPA standardizat este util doar în măsura în care anexele sale sunt completate corect și corespund realității tehnice.

Subprocesatori: Controlați numele, sarcinile și modificările

Conform articolului 28 alineatul (2) din GDPR, o persoană împuternicită de operator nu poate contracta o altă persoană împuternicită fără o autorizație scrisă, specifică sau generală, prealabilă a operatorului. În cazul unei autorizații scrise generale, persoana împuternicită trebuie să informeze operatorul cu privire la orice modificări preconizate și să îi ofere posibilitatea de a formula obiecții. În plus, Întrebările și Răspunsurile Comisiei Europene privind Clauzele Contractuale Standard clarifică faptul că simplele categorii nu sunt suficiente: fiecare subprocesator în parte trebuie numit.

Solicitați o listă actualizată, exportabilă, cu denumirea juridică, țara, serviciul concret și datele afectate. De asemenea, verificați dacă o companie este doar partener contractual sau dacă efectuează prelucrări efective în mai multe locații. Deosebit de importanți sunt furnizorii de modele și embeddings, găzduirea cloud, bazele de date, CDN-urile, monitorizarea, analiza erorilor, suportul, e-mailul și backup-ul. Pentru fiecare intrare trebuie să fie clar dacă datele sunt stocate, doar tranzitate sau dacă pot fi vizualizate de către personal.

Procesul de modificare trebuie, de asemenea, evaluat: Cum sunt notificați clienții, care este termenul de preaviz și ce se întâmplă în cazul unei obiecții întemeiate? Un e-mail trimis în ziua modificării, fără o posibilitate de reacție utilă din punct de vedere tehnic sau contractual, are o valoare redusă. Clarificați dacă este posibilă o configurație alternativă, dezactivarea funcției sau, la nevoie, o reziliere ordonată urmată de exportul datelor. Pentru subprocesatorii subsecvenți, trebuie transmise aceleași obligații privind protecția datelor; prima persoană împuternicită rămâne răspunzătoare față de operator pentru îndeplinirea obligațiilor acestora.

Transferuri către țări terțe: Verificați mecanismul și efectul real

Capitolul V din GDPR se aplică transferurilor de date cu caracter personal către țări terțe și transferurilor ulterioare. Un transfer nu rezultă doar din stocarea permanentă; un acces administrativ, un acces pentru suport sau interogarea printr-un serviciu din afara SEE pot fi, de asemenea, relevante. Prin urmare, atribuiți fiecărei săgeți din harta fluxului de date o țară de destinație, un destinatar și un mecanism de transfer.

1. Decizia privind nivelul de protecție adecvat: Verificați pe lista Comisiei Europene actualizată permanent dacă decizia, teritoriul, sectorul și destinatarul specific sunt acoperite. În cazul cadrelor de protecție limitate, simpla prezență a unui sediu într-o țară nu este suficientă.
2. Garanții adecvate: În lipsa unei decizii adecvate, în funcție de situație, pot fi luate în considerare instrumentele prevăzute la articolul 46 din GDPR. Frecvent sunt utilizate Clauzele Contractuale Standard ale Comisiei Europene. Modulul, părțile, anexele, descrierea transferului și măsurile tehnice trebuie să corespundă lanțului real.
3. Testul de eficacitate: Un document SCC semnat nu încheie automat evaluarea. Recomandările finale 01/2020 ale EDPB descriu un proces bazat pe risc: identificarea transferurilor, stabilirea instrumentului, evaluarea legislației și practicii din țara terță, stabilirea de măsuri suplimentare dacă este cazul, îndeplinirea etapelor formale și reevaluarea periodică.

Măsurile tehnice suplimentare trebuie să fie adaptate riscului specific. De exemplu, criptarea este relevantă doar dacă se iau în considerare gestionarea cheilor, drepturile de acces și scopul prelucrării. Un furnizor de modele care trebuie să prelucreze text în clar și are el însuși acces la chei se află într-o situație diferită față de un spațiu de stocare pur criptat pentru backup. Declarațiile generale precum „AES-256” sau „conform GDPR” nu înlocuiesc această analiză. De asemenea, derogările prevăzute la articolul 49 din GDPR nu constituie o cale standard practică pentru prelucrările SaaS planificate și periodice.

Exemplu practic: Regiune UE cu lanț global de servicii

Să presupunem că un chatbot își stochează baza de date principală la Frankfurt. Totuși, răspunsurile sunt generate de un API de model al unei companii din SUA, rapoartele de eroare ajung la un alt serviciu, iar o echipă globală de suport poate deschide jurnalele de conversație în caz de escaladare. În acest caz, afirmația „stocarea datelor în UE” descrie doar o parte din sistem.

Procesul de due diligence separă patru întrebări: Ce conținuturi părăsesc SEE pentru generarea răspunsurilor de către model? Sunt stocate prompturile acolo sau folosite în alte scopuri? Rapoartele de eroare conțin text în clar, identificatori sau doar date tehnice minimizate? În ce condiții poate accesa datele echipa de suport din afara SEE? Abia după aceea pot fi evaluate instrumentul de transfer, măsurile suplimentare și riscul rezidual.

Din punct de vedere tehnic, administratorul site-ului poate reduce adesea riscul: prin dezactivarea câmpurilor de jurnalizare inutile, eliminarea datelor sensibile din introduceri înainte de apelurile externe, setarea unor durate scurte de păstrare, separarea zonelor sensibile de botul public, izolarea surselor de cunoștințe pe fiecare client și jurnalizarea accesului de suport cu aprobare prealabilă. Modul în care un bot public și un portal pentru clienți sunt separate corect este explicat în articolul Chatbot AI public vs. Portal clienți. Pentru fișierele încărcate, lista de verificare privind verificarea fișierelor, protecția datelor și predarea către un agent uman completează evaluarea furnizorilor.

Decizie bazată pe un sistem semaforizat, nu pe intuiție

Punct de verificare	Verde	Galben	Roșu
Fluxul de date	Complet, actualizat și raportat la planul tarifar	Unele accesări sau locații de stocare neclare	Doar afirmații de marketing despre regiunea UE
DPA	Scopurile, datele, termenele și asistența sunt concrete	Sunt necesare completări înainte de lansare	Fără obligația clară de a respecta instrucțiunile sau reguli de ștergere
Subprocesatori	Listă nominală cu țara și sarcina detaliate	Procesul de modificare este nepractic	Doar categorii generale sau lanț necunoscut
Transfer în țări terțe	Mecanismul, domeniul de aplicare și evaluarea sunt documentate	Măsurile necesită încă verificare	Afirmația „Server în UE” este folosită pentru a justifica toate transferurile
Operare	Responsabil desemnat, dată de reevaluare și scenariu de exit testat	Dovezi existente fără un calendar fix de reevaluare	Lipsă de monitorizare după semnarea contractului

Un punct galben nu trebuie să însemne automat respingerea furnizorului. Totuși, acesta necesită un responsabil, un termen limită și un criteriu de acceptare verificabil. Un punct roșu într-un lanț central de prelucrare ar trebui să blocheze lansarea în producție până când contractul, configurația sau alegerea furnizorului sunt ajustate. Documentați, de asemenea, riscurile reziduale asumate și persoana care a luat această decizie.

Listă compactă de verificare înainte de lansare

• Harta fluxului de date și rolurile pentru fiecare scop sunt aprobate.
• DPA și anexele corespund tarifului, funcțiilor, tipurilor de date și termenelor de păstrare.
• Toți subprocesatorii sunt documentați nominal, menționând țara, sarcina și modalitatea de modificare.
• Fiecare transfer către o țară terță are un mecanism adecvat, recent verificat, și măsuri suplimentare dacă este cazul.
• Antrenarea modelelor sau altă utilizare proprie a datelor din chat este clarificată și configurată conform acordului.
• Jurnalizarea, accesul de suport, exportul datelor, ștergerea și încetarea contractului au fost testate practic.
• Notificările privind protecția datelor și interfața de chat explică clar prelucrarea; utilizatorii nu sunt determinați să introducă date sensibile inutile.
• S-a verificat dacă este necesară o evaluare a impactului asupra protecției datelor (DPIA) pentru utilizarea specifică.
• Un responsabil monitorizează modificările privind subprocesatorii, mecanismele de transfer, funcțiile și dovezile de securitate.

În plus, se recomandă o comparare cu prezentarea generală Chatbot-ul AI și GDPR, precum și cu ghidul pentru analitica chatbot-urilor cu minimizarea datelor. Astfel, achiziția, configurația tehnică și operarea continuă nu vor fi tratate ca proiecte izolate.

Continuați verificările și după semnarea contractului

Due diligence nu este un dosar PDF care se verifică o singură dată. Stabiliți cel puțin un ritm fix de reevaluare și verificări declanșate de evenimente specifice. Factorii declanșatori includ noi subprocesatori, schimbarea furnizorului de modele, funcții noi de produs, modificarea locațiilor de stocare, un incident de securitate, expirarea dovezilor de securitate sau modificări ale deciziilor privind nivelul de protecție adecvat. Lista actuală a subprocesatorilor și versiunile contractuale centrale ar trebui arhivate cu dată, astfel încât modificările ulterioare să rămână trasabile.

Criteriul practic este simplu: Poate echipa dumneavoastră să explice, pentru fiecare flux de date relevant, cine ce prelucrează și de ce, unde se întâmplă acest lucru, cât timp rămân datele, ce măsură de protecție se aplică și cum funcționează o procedură de ieșire (exit)? Dacă aceste răspunsuri sunt susținute de dovezi, o simplă afirmație despre protecția datelor devine o decizie de achiziție solidă. Dacă punctele centrale rămân necunoscute, chatbot-ul nu ar trebui să funcționeze încă cu date reale ale vizitatorilor.