Ștergerea și exportarea istoricului chatbotului: Control sigur pentru utilizatori

Un istoric al chatului este practic pentru utilizatori: aceștia pot reciti răspunsurile, pot relua o conversație mai târziu sau pot transmite informații către echipa de suport. Cu toate acestea, aceeași istorie poate conține numere de comandă, descrieri ale problemelor, date de contact sau alte informații sensibile. Prin urmare, oricine stochează conversații are nevoie de mai mult decât de un comutator discret pentru „Istoric”. Utilizatorii ar trebui să înțeleagă ce date sunt prezente, cum le pot lua cu ei, cum le pot șterge sau cum pot revoca accesul ulterior.

Acest ghid prezintă un model tehnic și de produs realizabil pentru chatboturile de pe site-urile web. El îmbină ușurința în utilizare, minimizarea datelor, verificarea sigură a identității și stările transparente ale sistemului. Recomandările nu constituie consultanță juridică individuală; obligațiile concrete depind, printre altele, de scop, temeiul juridic, arhitectura sistemului și datele vizate.

Patru funcții în loc de un singur comutator de istoric

„Gestionarea istoricului” este un termen prea vag. În interfață și în backend, ar trebui separate patru intenții distincte:

• Vizualizare: Utilizatorii citesc conversațiile stocate, fișierele atașate și metadatele vizibile într-o cronologie clară.
• Exportare: Aceștia primesc o copie într-un format lizibil și, dacă este util sau cerut din punct de vedere legal pentru cazul de utilizare, suplimentar într-un format structurat, lizibil automat.
• Ștergere: Aceștia elimină conversații individuale sau întregul istoric asociat. Interfața explică scopul, termenele și posibilele excepții.
• Revocarea accesului: Aceștia invalidează linkurile de partajare, dispozitivele cunoscute sau tokenurile de reluare, fără a șterge neapărat imediat toate datele de conținut.

Această separare previne neînțelegerile periculoase. „Deconectarea” nu șterge datele conversației. „Ascunderea istoricului” nu reprezintă o ștergere. Iar un link expirat nu înseamnă automat că înregistrările subiacente au dispărut. În plus, merită să consultați ghidul nostru despre reluarea în siguranță a conversațiilor din chatbot.

Începeți cu un model de date clar

Înainte ca echipele să proiecteze butoane, ar trebui să inventarieze obiectele stocate. O conversație constă adesea în mai mult decât simple mesaje. Se adaugă identificatori de sesiune, marcaje temporale, referințe la fișiere, evenimente de securitate, tichete de suport, feedback și jurnale tehnice. Pentru fiecare obiect este nevoie de un scop documentat, un responsabil, o regulă de păstrare și o cale de ștergere.

Regulamentul general privind protecția datelor (GDPR) menționează la Articolul 5, printre altele, minimizarea datelor și limitarea legată de stocare. Articolul 15 privește dreptul de acces, Articolul 17 dreptul la ștergere („dreptul de a fi uitat”) cu condițiile și excepțiile sale, iar Articolul 20 portabilitatea datelor în domeniile lor respective de aplicare. Aceasta nu înseamnă că fiecare interfață de chatbot trebuie să ofere funcții identice. Însă echipele de produs ar trebui să construiască fluxurile de date astfel încât solicitările legitime să poată fi procesate cu succes.

Verificați adecvat identitatea înainte de export și ștergere

Oricine face un istoric accesibil doar printr-un link ușor de ghicit sau printr-un identificator de sesiune reutilizat riscă scurgeri de date. În același timp, o verificare a identității nu trebuie să solicite mai multe date cu caracter personal decât este necesar pentru acțiunea respectivă. Ghidurile finale EDPB 01/2022 privind dreptul de acces tratează, printre altele, identificarea, domeniul de aplicare și furnizarea sigură a copiilor. Articolul 12 alineatul 6 din GDPR permite informații suplimentare pentru confirmarea identității atunci când există îndoieli întemeiate.

În practică, o abordare eșalonată în funcție de risc s-a dovedit eficientă. Afișarea unui istoric scurt pseudonimizat pe același dispozitiv poate necesita o sesiune validă, de scurtă durată. Un export complet, o ștergere ireversibilă sau revocarea tuturor dispozitivelor justifică mai degrabă o reautentificare. Ghidul curent NIST privind gestionarea sesiunilor descrie reautentificarea, limitele de timp și terminarea sesiunii ca controale de sine stătătoare. Nivelul de securitate trebuie să se potrivească riscului; cerințele NIST pentru agențiile federale din SUA nu sunt o cerință legală generală pentru orice companie.

Pentru widgeturile publice și zonele autentificate ale clienților, limita ar trebui să rămână vizibilă. Articolul nostru despre identitate și accesul la date în portalul clienților arată de ce un chat public nu ar trebui să devină discret un canal de date pentru cont.

Un export trebuie să fie ușor de înțeles și complet explicabil

Un export bun nu este o simplă descărcare brută din baza de date. El începe cu o privire de ansamblu: perioada creării, conversațiile incluse, fișierele atașate, fusul orar utilizat și versiunea formatului. Apoi urmează conținutul într-o ordine clară. JSON poate fi util pentru procesarea structurată ulterioară; HTML sau PDF este mai ușor de citit pentru mulți oameni. Dacă și în ce măsură este necesar un format portabil din punct de vedere legal, ar trebui verificat pentru fiecare caz în parte.

Dacă sistemul generează exportul în mod asincron, interfața are nevoie de un status clar: „se pregătește”, „disponibil până la …”, „expirat” sau „eșuat”. Linkul de descărcare ar trebui să fie de scurtă durată, imposibil de ghicit și revocabil după utilizare. Informațiile confidențiale, cum ar fi prompturile interne, cheile de acces sau datele altor persoane, nu aparțin pachetului. Înainte de furnizare, un filtru la nivel de server ar trebui să verifice dacă legăturile cu cazurile de suport, conversațiile partajate sau conținuturile terților necesită un tratament special.

Ștergerea ca mașină de stări, nu ca o promisiune instantanee

Un buton cu mesajul „Totul a fost șters” este problematic dacă indexul de căutare, stocarea pentru analiză, sistemul de suport sau copiile de rezervă conțin în continuare copii. Este mai bună o mașină de stări simplă, care să reflecte procesul real.

Stări utile de ștergere

1. Solicitat: Identitatea și volumul dorit sunt confirmate.
2. Blocat: Istoricul nu mai este accesibil pentru utilizarea normală; tokenurile de reluare și partajare sunt invalide.
3. În procesare: Stocarea primară, indexul de căutare, stocarea de fișiere, destinațiile de analiză și integrare sunt procesate.
4. Finalizat: Sistemele active vizate sunt curățate; copiile de rezervă rămase fac obiectul rotației documentate a backupurilor sau al unei excepții motivate.
5. Parțial blocat: Un sistem nu a putut fi curățat sau datele trebuie păstrate temporar. Cazul este escaladat în mod trasabil.

Nu uitați de datele dependente

Mesajele pot face trimitere la fișiere, embeddings, indecși de căutare, evaluări ale calității, înregistrări CRM sau tichete de suport. Solicitarea de ștergere are de aceea nevoie de un ID de solicitare stabil și de pași de lucru idempotenți: O nouă rulare nu trebuie să genereze copii noi sau să anuleze pașii deja efectuați. Pentru datele de măsurare, ar trebui să se decidă încă din faza de proiectare dacă indicatorii agregați, care nu mai pot fi atribuiți, pot fi păstrați. Citiți mai multe despre acest subiect în articolul despre analiza datelor din chatboturi cu minimizarea datelor.

Revocarea protejează în special pe dispozitivele folosite la comun

În hoteluri, spații comerciale, ateliere sau locuințe de familie, persoanele schimbă mai des același dispozitiv. De aceea, „Revocarea accesului” ar trebui să poată face mai mult decât să șteargă un cookie local. La nivel de server, tokenurile de sesiune cunoscute, linkurile de partajare și, dacă este cazul, legăturile de dispozitiv trebuie să devină invalide. Interfața ar trebui să facă diferența între „acest dispozitiv”, „toate dispozitivele” și „toate linkurile partajate”.

După revocare, butonul „Înapoi” din browser nu ar trebui să afișeze un istoric sensibil dintr-un cache. Previzualizările din notificări, completarea automată a browserului și datele locale offline ar trebui incluse în verificare. În același timp, utilizatorul ar trebui să primească o confirmare clară cu privire la accesările încheiate și dacă datele conversației rămân stocate în continuare. Astfel, revocarea nu este confundată cu ștergerea.

Proiectați confirmarea ștergerii să fie accesibilă și tolerantă la erori

O acțiune ireversibilă are nevoie de o confirmare clară și ușor de înțeles. Explicația WCAG 2.2 privind criteriul de succes 3.3.4 se referă în mod explicit și la modificarea sau ștergerea datelor controlabile de către utilizator. Este prevăzută cel puțin o posibilitate de anulare, verificare sau confirmare. Varianta potrivită depinde de produs.

Dialogurile bune menționează concret „3 conversații și 2 fișiere atașate” în loc de un simplu „Date”. Acțiunea primară și cea distructivă sunt distincte vizual, accesibile de la tastatură și nu sunt explicate doar prin culoare. După trimitere, o zonă de status accesibilă anunță că solicitarea a fost acceptată. Un coș de reciclare cu un termen limitat de recuperare poate remedia erorile de operare, dar nu trebuie să contrazică în secret o ștergere imediată promisă.

Preluarea de către suport fără copii secundare ascunse

Când o conversație este transferată către un operator uman, se creează adesea un tichet de suport separat. Acest obiect poate avea un alt scop, alte roluri de acces și o altă regulă de păstrare. Setarea istoricului din chatbot nu trebuie să șteargă invizibil un astfel de tichet și nici să îl ignore în tăcere. Înainte de transfer, interfața ar trebui să explice ce conținuturi vor fi preluate. În cazul unei solicitări ulterioare, sistemul trebuie să găsească legătura și să trateze cazul conform regulilor aplicabile.

Dacă o ștergere automată eșuează sau identitatea și volumul datelor sunt neclare, procesul are nevoie de un canal uman sigur. Articolul despre Human Handoff în suportul pe site-uri web descrie pachetele de context și regulile de escaladare pentru acest lucru. Ar trebui transmis doar ceea ce îi este cu adevărat necesar angajatului responsabil.

Listă de verificare pentru echipele de produs și suport

1. Inventariați toate obiectele de date și locațiile de stocare ale unei conversații.
2. Modelați vizualizarea, exportul, ștergerea și revocarea ca permisiuni separate.
3. Reautentificați în funcție de risc pentru acțiunile sensibile.
4. Structurați pachetele de export pe înțelesul tuturor și setați timpi siguri de expirare.
5. Faceți pașii de ștergere idempotenți și urmăriți-i cu un ID de solicitare.
6. Includeți indexul de căutare, fișierele, analizele, integrările, cache-urile și tichetele de suport.
7. Testați dialogurile de confirmare și mesajele de status cu tastatura și cititorul de ecran.
8. Simulați dispozitive utilizate la comun, linkuri expirate și dispozitive pierdute.
9. Escaladați vizibil erorile parțiale, fără a copia conținuturi sensibile în jurnale (logs).
10. Verificați regulat regulile de păstrare și ștergere împreună cu responsabilii de protecția datelor și departamentele de specialitate.

Cele mai importante teste înainte de lansare

Cazurile de testare nu ar trebui să acopere doar scenariul ideal. Verificați solicitările paralele de ștergere, o autentificare care expiră în timpul exportului, linkurile deja revocate, mesajele noi primite în timpul unei ștergeri în curs și eșecul unui sistem conectat. Verificați, de asemenea, dacă un export conține mesaje străine din conturi partajate și dacă un fișier șters este încă accesibil printr-un URL vechi.

Pentru fiecare acțiune este nevoie de un rezultat așteptat în interfață, API și stocare. Un test bun de acceptanță nu se termină așadar la un mesaj verde de succes. El verifică ulterior spațiile de stocare ale datelor relevante, tokenurile și URL-urile publice. Jurnalele de evenimente ar trebui să dovedească că un pas a fost executat, fără a stoca din nou conținutul șters al conversației.

Concluzie: Controlul utilizatorului este o proprietate cap-la-cap

Un chatbot de încredere nu doar că face istoricul ușor de găsit. El separă vizualizarea, exportul, ștergerea și revocarea, verifică adecvat acțiunile sensibile și arată starea reală de procesare. Decisivă este conexiunea dintre un UX clar și un model de date care cunoaște toate sistemele dependente.

Oricine integrează aceste funcții devreme în arhitectură, procesele de suport și teste reduce cazurile excepționale manuale și evită promisiunile false. În timpul planificării, verificați și ce funcționalități ChatReact se potrivesc site-ului dvs. web și procesului dvs. de suport. Începeți cu un inventar al datelor și un singur test cap-la-cap: exportați istoricul, revocați accesările, declanșați ștergerea și dovediți rezultatul în toate sistemele implicate.

Surse și referințe suplimentare

• EUR-Lex: Regulamentul (UE) 2016/679, în special Articolele 5, 12, 15, 17 și 20.
• EDPB: Ghidul 01/2022 privind drepturile persoanelor vizate – Dreptul de acces, Versiunea 2.1.
• NIST SP 800-63B: Session Management.
• W3C: Înțelegerea Criteriului de Succes WCAG 2.2 3.3.4.