Brisanje i izvoz povijesti chatbota: Sigurna korisnička kontrola

Povijest razgovora s chatbotom praktična je za korisnike: mogu ponovno pročitati odgovore, nastaviti razgovor kasnije ili proslijediti informacije službi za korisnike. Međutim, ta ista povijest može sadržavati brojeve narudžbi, opise problema, kontakt podatke ili druge osjetljive podatke. Tko god pohranjuje razgovore, treba više od neupadljivog prekidača za „povijest“. Korisnici bi trebali razumjeti koji su podaci prisutni, kako ih mogu ponijeti sa sobom, izbrisati ili opozvati daljnji pristup.

Ovaj vodič prikazuje primjenjiv proizvodni i tehnički model za chatbotove na web-stranicama. On povezuje jednostavnost korištenja, minimizaciju podataka, sigurnu provjeru identiteta i razumljiva stanja sustava. Preporuke ne predstavljaju pojedinačno pravno savjetovanje; konkretne obveze ovise, između ostalog, o svrsi, pravnoj osnovi, arhitekturi sustava i obuhvaćenim podacima.

Četiri funkcije umjesto jednog prekidača za povijest

„Upravljanje poviješću“ je previše neprecizno. U korisničkom sučelju i na pozadinskom sustavu (backend) treba razdvojiti četiri različite namjere:

• Pregled: Korisnici čitaju pohranjene razgovore, privitke i prepoznatljive metapodatke u razumljivoj kronologiji.
• Izvoz: Primaju kopiju u čitljivom formatu te, ako je smisleno za slučaj upotrebe ili pravno potrebno, dodatno u strukturiranom strojno čitljivom formatu.
• Brisanje: Uklanjaju pojedinačne razgovore ili cjelokupnu dodijeljenu povijest. Korisničko sučelje objašnjava opseg, rokove i moguće iznimke.
• Opoziv pristupa: Onemogućuju poveznice za dijeljenje, poznate uređaje ili tokene za nastavak razgovora, bez nužnog trenutnog brisanja svih sadržajnih podataka.

Ovo razdvajanje sprečava opasne nesporazume. „Odjava“ ne briše podatke o razgovoru. „Sakrij povijest“ nije brisanje. A istekla poveznica ne znači automatski da su izvorni podatkovni zapisi nestali. Kao dopunu, vrijedi pročitati naš vodič o sigurnom nastavku razgovora s chatbotom.

Započnite s jasnim modelom podataka

Prije nego što timovi počnu dizajnirati gumbe, trebali bi popisati pohranjene objekte. Razgovor se često ne sastoji samo od poruka. Tu su i identifikatori sesija, vremenske oznake, reference na datoteke, sigurnosni događaji, tiketi podrške, povratne informacije i tehnički dnevnici (logs). Za svaki objekt potrebna je dokumentirana svrha, odgovorna osoba, pravilo hrambe i putanja brisanja.

Opća uredba o zaštiti podataka (GDPR) u članku 5, između ostalog, spominje smanjenje količine podataka i ograničenje pohrane. Članak 15 odnosi se na pravo na pristup, članak 17 na pravo na brisanje s uvjetima i iznimkama, a članak 20 na prenosivost podataka u njihovom području primjene. Iz toga ne slijedi da svako sučelje chatbota mora nuditi identične funkcije. Međutim, timovi za razvoj proizvoda trebali bi izgraditi tokove podataka tako da se legitimni zahtjevi mogu pouzdano obraditi.

Prikladno provjerite identitet prije izvoza i brisanja

Tko god omogući pristup povijesti samo putem pogođene poveznice ili ponovno upotrijebljenog identifikatora sesije, riskira curenje podataka. Istodobno, provjera identiteta ne smije općenito zahtijevati više osobnih podataka nego što je potrebno za konkretnu radnju. Konačne EDPB smjernice 01/2022 o pravima ispitanika bave se, između ostalog, identifikacijom, opsegom i sigurnim pružanjem kopija. Članak 12. stavak 6. GDPR-a dopušta dodatne informacije za potvrdu identiteta ako postoji opravdana sumnja u identitet.

U praksi se dokazalo stupnjevanje temeljeno na riziku. Prikazivanje pseudonimizirane kratke povijesti na istom uređaju može zahtijevati valjanu, kratkotrajnu sesiju. Potpuni izvoz, ireverzibilno brisanje ili opoziv svih uređaja opravdavaju ponovnu autentifikaciju. Aktualna NIST smjernica za upravljanje sesijama opisuje ponovnu autentifikaciju, vremenska ograničenja i prekide sesija kao samostalne kontrole. Konkretna snaga mora odgovarati riziku; NIST specifikacije za američke savezne agencije nisu opće pravno pravilo za svaku tvrtku.

Za javne widgete i prijavljene korisničke račune granica bi trebala ostati vidljiva. Naš članak o identitetu i pristupu podacima u korisničkom portalu objašnjava zašto javni chat ne bi trebala tiho postati kanal za podatke računa.

Izvoz mora biti razumljiv i u potpunosti objašnjiv

Dobar izvoz nije neobrađeni ispis (dump) iz baze podataka. Započinje pregledom: razdoblje stvaranja, uključeni razgovori, privitci, korištena vremenska zona i verzija formata. Nakon toga slijedi sadržaj u jasnom redoslijedu. JSON može biti koristan za strukturiranu daljnju obradu; HTML ili PDF lakše su čitljivi većini ljudi. Je li i u kojem opsegu prijenosni format pravno potreban, treba provjeriti za svaki konkretan slučaj.

Ako sustav generira izvoz asinkrono, korisničko sučelje treba jasan status: „priprema se“, „spremno do…“, „isteklo“ ili „neuspješno“. Poveznica za preuzimanje trebala bi biti kratkotrajna, nemoguća za pogađanje i opoziva nakon upotrebe. Tajne poput internih promptova, pristupnih ključeva ili podataka drugih osoba ne pripadaju u taj paket. Prije isporuke, filtar na strani poslužitelja trebao bi provjeriti zahtijevaju li veze s predmetima podrške, dijeljenim konverzacijama ili sadržajem trećih strana poseban tretman.

Brisanje kao stroj stanja umjesto trenutnog obećanja

Gumb s porukom „Sve je izbrisano“ problematičan je ako indeks pretraživanja, analitička pohrana, sustav podrške ili sigurnosna kopija i dalje sadrže kopije. Bolji je mali stroj stanja (state machine) koji odražava stvarni proces.

Smislena stanja brisanja

1. Zatraženo: Potvrđeni su identitet i željeni opseg.
2. Blokirano: Povijest više nije dostupna za uobičajeno korištenje; tokeni za nastavak i dijeljenje su nevažeći.
3. U obradi: Obrađuju se primarna memorija, indeks pretraživanja, pohrana datoteka, analitički i integracijski ciljevi.
4. Dovršeno: Predviđeni aktivni sustavi su očišćeni; preostale sigurnosne kopije podliježu dokumentiranoj rotaciji sigurnosnih kopija ili opravdanoj iznimci.
5. Djelomično blokirano: Jedan sustav nije se mogao očistiti ili se podaci za sada moraju zadržati. Slučaj se prateće eskalira.

Ne zaboravite zavisne podatke

Poruke se mogu odnositi na datoteke, ugradnje (embeddings), indekse pretraživanja, ocjene kvalitete, CRM zapise ili tikete podrške. Zahtjev za brisanje stoga treba stabilan ID zahtjeva i idempotentne korake rada: ponovno pokretanje ne smije stvoriti nove kopije niti poništiti već dovršene korake. Za podatke mjerenja, već u fazi dizajna treba odlučiti mogu li se zadržati agregirani pokazatelji koji se više ne mogu povezati s pojedincem. Više o tome pročitajte u članku o analitici chatbotova usmjerenoj na minimizaciju podataka.

Opoziv štiti posebno na zajedničkim uređajima

U hotelima, prodajnim prostorima, radionicama ili obiteljskim kućanstvima korisnici se češće izmjenjuju na istom uređaju. Stoga bi „Opoziv pristupa“ trebao moći učiniti više od lokalnog brisanja kolačića. Na strani poslužitelja moraju postati nevažeći poznati tokeni sesija, poveznice za dijeljenje i, ako je primjenjivo, veze s uređajima. Korisničko sučelje trebalo bi razlikovati između „ovaj uređaj“, „svi uređaji“ i „sve dijeljene poveznice“.

Nakon opoziva, gumb za povratak (Back) ne smije prikazivati osjetljivu povijest iz predmemorije (cache). Pregledi u obavijestima, automatsko dovršavanje u pregledniku i lokalni izvanmrežni podaci moraju biti obuhvaćeni provjerom. Istovremeno, korisnik treba dobiti jasnu potvrdu o tome koji su pristupi prekinuti i jesu li podaci o razgovoru i dalje pohranjeni. Tako se opoziv ne miješa s brisanjem.

Učinite potvrdu brisanja pristupačnom i tolerantnom na pogreške

Irreverzibilna radnja zahtijeva smirenu, razumljivu potvrdu. Objašnjenje WCAG 2.2 za kriterij uspješnosti 3.3.4 izričito se odnosi i na izmjenu ili brisanje podataka pod kontrolom korisnika. Predviđena je barem jedna mogućnost poništavanja, provjere ili potvrde. Koja varijanta odgovara, ovisi o proizvodu.

Dobri dijalozi navode konkretno „3 razgovora i 2 privitka“ umjesto samo „podaci“. Primarna i destruktivna radnja vizualno se razlikuju, dostupne su putem tipkovnice i nisu objašnjene samo bojom. Nakon slanja, pristupačno područje statusa javlja da je zahtjev prihvaćen. Smeće s ograničenim rokom oporavka može presresti pogreške u rukovanju, ali ne smije potajno proturječiti obećanom trenutnom brisanju.

Prijenos na podršku bez skrivene kopije

Kada se razgovor prenosi ljudskom agentu, često nastaje zasebni tiket podrške. Ovaj objekt može imati drugu svrhu, druge uloge pristupa i druga pravila pohrane. Postavka povijesti u chatbotu ne smije nevidljivo izbrisati niti tiho zanemariti takav tiket. Prije prijenosa, sučelje bi trebalo objasniti koji se sadržaji preuzimaju. Prilikom kasnijeg zahtjeva, sustav mora pronaći poveznicu i obraditi slučaj prema važećim pravilima.

Ako automatsko brisanje ne uspije ili su identitet i opseg nejasni, procesu je potreban siguran ljudski kanal. Članak o prijenosu na čovječjeg agenta (Human Handoff) u podršci na web-stranici opisuje kontekstne pakete i pravila eskalacije. Trebalo bi prenijeti samo ono što je nadležnom djelatniku doista potrebno.

Popis za provjeru implementacije za timove za proizvod i podršku

1. Popišite sve objekte podataka i lokacije pohrane razgovora.
2. Modelirajte pregled, izvoz, brisanje i opoziv kao zasebna dopuštenja.
3. Za osjetljive radnje ponovno autentificirajte na temelju rizika.
4. Razumljivo strukturirajte pakete za izvoz i postavite sigurna vremena isteka.
5. Učinite korake brisanja idempotentnima i pratite ih pomoću ID-a zahtjeva.
6. Uključite indeks pretraživanja, datoteke, analitiku, integracije, predmemorije i slučajeve podrške.
7. Testirajte dijaloge potvrde i statusne poruke pomoću tipkovnice i čitača zaslona.
8. Simulirajte zajedničke uređaje, istekle poveznice i izgubljene uređaje.
9. Vidljivo eskalirajte djelomične pogreške bez kopiranja osjetljivog sadržaja u dnevnike.
10. Redovito provjeravajte pravila pohrane i brisanja sa stručnjacima za zaštitu podataka i odjelima.

Najvažniji testovi prije puštanja u rad

Testni slučajevi ne bi trebali pokrivati samo idealan scenarij. Provjerite paralelne zahtjeve za brisanje, prijavu koja istječe tijekom izvoza, već opozvane poveznice, nove poruke tijekom brisanja u tijeku i otkazivanje povezanog sustava. Osim toga, provjerite sadrži li izvoz tuđe poruke sa dijeljenih računa i je li izbrisana datoteka još uvijek dostupna putem stare URL adrese.

Za svaku radnju potreban je očekivani rezultat u sučelju, API-ju i pohrani. Dobar prihvatan test stoga ne završava zelenom porukom o uspjehu. On naknadno provjerava mjerodavne pohrane podataka, tokene i javne URL-ove. Dnevnici događaja trebali bi potvrditi da je korak izvršen, bez ponovnog pohranjivanja izbrisanog sadržaja razgovora.

Zaključak: Korisnička kontrola je značajka od početka do kraja (end-to-end)

Pouzdan chatbot ne čini povijest samo pronalazivom. On razdvaja pregled, izvoz, brisanje i opoziv, primjereno provjerava osjetljive radnje i prikazuje stvarni status obrade. Presudna je povezanost jasnog korisničkog iskustva (UX) s modelom podataka koji poznaje sve ovisne sustave.

Tko te funkcije rano integrira u arhitekturu, procese podrške i testiranja, smanjuje ručne iznimne slučajeve i izbjegava lažna obećanja. Prilikom planiranja provjerite i koje ChatReact funkcije odgovaraju vašoj web-stranici i procesu podrške. Započnite s popisom podataka i jednim cjelovitim testom od početka do kraja: izvezite povijest, opozovite pristupe, pokrenite brisanje i dokažite rezultat u svim uključenim sustavima.

Izvori i daljnje napomene

• EUR-Lex: Uredba (EU) 2016/679, posebno članci 5, 12, 15, 17 i 20.
• EDPB: Smjernice 01/2022 o pravima ispitanika – Pravo na pristup, Verzija 2.1.
• NIST SP 800-63B: Upravljanje sesijama.
• W3C: Razumijevanje WCAG 2.2 kriterija uspješnosti 3.3.4.