Tērzēšanas robota vēstures dzēšana un eksportēšana: droša lietotāju kontrole

Tērzēšanas robota vēsture lietotājiem ir ļoti ērta: viņi var pārlasīt atbildes, vēlāk turpināt sarunu vai nodot informāciju atbalsta dienestam. Taču tajā pašā vēsturē var būt ietverti pasūtījumu numuri, problēmu apraksti, kontaktinformācija vai cita jutīga informācija. Tāpēc ikvienam, kurš saglabā sarunas, ir nepieciešams kas vairāk par nepamanāmu slēdzi „Vēsture”. Lietotājiem vajadzētu saprast, kādi dati ir pieejami, kā tos paņemt līdzi, izdzēst vai atsaukt turpmāko piekļuvi.

Šajā rokasgrāmatā ir parādīts praktiski īstenojams produkta un tehniskais modelis tīmekļa vietņu tērzēšanas robotiem. Tas apvieno lietotājdraudzīgumu, datu minimizēšanu, drošu identitātes pārbaudi un saprotamus sistēmas stāvokļus. Šie norādījumi nav individuāla juridiskā konsultācija; konkrētie pienākumi ir atkarīgi no mērķa, juridiskā pamata, sistēmas arhitektūras un skartajiem datiem.

Četras funkcijas viena vēstures slēdža vietā

„Pārvaldīt vēsturi” ir pārāk neprecīzs jēdziens. Saskarnē un aizmugursistēmā (backend) vajadzētu nošķirt četrus dažādus mērķus:

• Apskatīt: lietotāji lasa saglabātās sarunas, pielikumus un atpazīstamos metadatus saprotamā hronoloģijā.
• Eksportēt: viņi saņem kopiju lasāmā formātā un, ja tas ir lietderīgi izmantošanas gadījumam vai juridiski nepieciešams, papildus arī strukturētā, mašīnlasāmā formātā.
• Dzēst: viņi dzēš atsevišķas sarunas vai visu saistīto vēsturi. Saskarnē ir paskaidrots apjoms, termiņi un iespējamie izņēmumi.
• Atsaukt piekļuvi: viņi padara nederīgas kopīgošanas saites, zināmās ierīces vai atsākšanas žetonus (tokens), obligāti neatliekami nedzēšot visus satura datus.

Šī nošķiršana novērš bīstamus pārpratumus. „Izrakstīties” neizdzēš sarunu datus. „Paslēpt vēsturi” nav dzēšana. Un saites derīguma termiņa beigas automātiski nenozīmē, ka pamatā esošie datu ieraksti ir pazuduši. Papildus ir vērts izlasīt mūsu rokasgrāmatu par drošu tērzēšanas robota sarunu turpināšanu.

Sāciet ar skaidru datu modeli

Pirms komandas izstrādā pogas, tām vajadzētu inventarizēt saglabātos objektus. Saruna bieži vien sastāv ne tikai no ziņojumiem. Tajā ietilpst arī sesiju identifikatori, laika spiedogi, saišu norādes uz datnēm, drošības notikumi, atbalsta pieteikumi, atsauksmes un tehniskie žurnāli. Katram objektam ir nepieciešams dokumentēts mērķis, atbildīgā persona, glabāšanas noteikums un dzēšanas ceļš.

Vispārīgās datu aizsardzības regulas 5. pantā cita starpā minēta datu minimizēšana un glabāšanas ierobežošana. 15. pants attiecas un piekļuves tiesībām, 17. pants – uz tiesībām tikt aizmirstam (dzēšanai) ar nosacījumiem un izņēmumiem, bet 20. pants – uz datu pārnesamību to attiecīgajā piemērošanas jomā. No tā neizriet, ka katrai tērzēšanas robota saskarnei jāpiedāvā identiskas funkcijas. Taču produktu komandām datu plūsmas būtu jāveido tā, lai pamatotus pieprasījumus varētu uzticami apstrādāt.

Pirms eksportēšanas un dzēšanas atbilstoši pārbaudiet identitāti

Ikviens, kurš padara vēsturi pieejamu, izmantojot tikai uzminamu saiti vai atkārtoti izmantotu sesijas identifikatoru, pakļauj sevi datu noplūdes riskam. Vienlaikus identitātes pārbaude nedrīkst vispārīgi pieprasīt vairāk personas datu, nekā nepieciešams konkrētajai darbībai. Galīgās EDPB vadlīnijas 01/2022 par datu subjekta tiesībām – piekļuves tiesībām cita starpā apskata identifikāciju, apjomu un drošu kopiju nodrošināšanu. VDAR 12. panta 6. punkts ļauj pieprasīt papildu informāciju identitātes apstiprināšanai, ja pastāv pamatotas šaubas par personas identitāti.

Praksē ir pierādījusies uz risku balstīta gradācija. Pseudonimizētas īsās vēstures parādīšanai tajā pašā ierīcē par priekšnoteikumu var būt derīga, īslaicīga sesija. Pilnīgs eksports, neatgriezeniska dzēšana vai visu ierīču piekļuves atsaukšana drīzāk attaisno atkārtotu autentifikāciju. Pašreizējās NIST vadlīnijas par sesiju pārvaldību apraksta atkārtotu autentifikāciju, laika ierobežojumus un sesijas pārtraukšanu kā atsevišķas kontroles. Konkrētajai stingrībai jāatbilst riskam; NIST prasības ASV federālajām iestādēm nav vispārīgs juridiskais standarts katram uzņēmumam.

Publiskajiem logrīkiem un autorizētajām klientu zonām robežai jāpaliek redzamai. Mūsu raksts par identitāti un datu piekļuvi klientu portālā parāda, kāpēc publiskai tērzēšanai nevajadzētu klusējot kļūt par konta datu kanālu.

Eksportam jābūt saprotamam un pilnībā izskaidrojamam

Labs eksports nav vienkāršs neapstrādāts datubāzes izvilkums. Tas sākas ar pārskatu: izveides periods, ietvertās sarunas, pielikumi, izmantotā laika josla un formāta versija. Tam seko saturs skaidrā secībā. JSON var būt noderīgs strukturētai tālākai apstrādei; HTML vai PDF daudziem cilvēkiem ir vieglāk lasāms. Vai un kādā apjomā portatīvs formāts ir juridiski nepieciešams, jāpārbauda konkrētajā gadījumā.

Ja sistēma ģenerē eksportu asinhroni, saskarnei ir nepieciešams skaidrs statuss: „tiek sagatavots”, „pieejams līdz …”, „beidzies derīguma termiņš” vai „neizdevās”. Lejupielādes saitei jābūt īslaicīgai, neuzminamai un pēc izmantošanas atsaucamai. Noslēpumi, piemēram, iekšējās norādes (prompts), piekļuves atslēgas vai citu personu dati, nedrīkst atrasties pakotnē. Pirms nodrošināšanas servera puses filtram jāpārbauda, vai saiknei ar atbalsta gadījumiem, kopīgotām sarunām vai trešo pušu saturu nav nepieciešama īpaša apstrāde.

Dzēšana kā stāvokļa mašīna, nevis tūlītējs solījums

Poga ar ziņojumu „Viss izdzēsts” ir problemātiska, ja meklēšanas indekss, analītikas krātuve, atbalsta sistēma vai rezerves kopija joprojām satur kopijas. Labāka ir neliela stāvokļu mašīna, kas atspoguļo faktisko procesu.

Prātīgi dzēšanas stāvokļi

1. Pieprasīts: identitāte un vēlamais apjoms ir apstiprināti.
2. Bloķēts: vēsture vairs nav pieejama parastai lietošanai; atsākšanas un kopīgošanas žetoni ir nederīgi.
3. Apstrādē: tiek attīrīta primārā krātuve, meklēšanas indekss, datņu krātuve, analītikas un integrācijas mērķi.
4. Pabeigts: paredzētās aktīvās sistēmas ir attīrītas; atlikušās rezerves kopijas atbilst dokumentētajai rezerves kopēšanas rotācijai vai pamatotam izņēmumam.
5. Daļēji bloķēts: kādu sistēmu neizdevās attīrīt vai datus pagaidām nepieciešams saglabāt. Gadījums tiek izsekojami eskalēts.

Neaizmirstiet par atkarīgajiem datiem

Ziņojumi var norādīt uz datnēm, iegulumiem (embeddings), meklēšanas indeksiem, kvalitātes vērtējumiem, CRM ierakstiem vai atbalsta pieteikumiem. Tāpēc dzēšanas pieprasījumam ir nepieciešams stabils pieprasījuma ID un idempotenti darba soļi: atkārtota izpilde nedrīkst radīt jaunas kopijas vai atcelt jau pabeigtus soļus. Mērījumu datiem jau izstrādes laikā jāizlemj, vai var saglabāt apkopotus rādītājus, ko vairs nevar piesaistīt konkrētai personai. Vairāk par to var izlasīt rakstā par datu ziņā taupīgu tērzēšanas robota analītiku.

Atsaukšana īpaši aizsargā koplietošanas ierīcēs

Viesnīcās, tirdzniecības telpās, darbnīcās vai ģimenes mājsaimniecībās cilvēki tajā pašā ierīcē mainās biežāk. Tāpēc funkcijai „Atsaukt piekļuvi” vajadzētu spēt vairāk par sīkfaila dzēšanu lokāli. Servera pusē zināmajiem sesijas žetoniem, kopīgošanas saitēm un, ja nepieciešams, ierīču piesaistēm jākļūst nederīgām. Saskarnei vajadzētu nošķirt „šī ierīce”, „visas ierīces” un „visas kopīgotās saites”.

Pēc atsaukšanas atpakaļgaitas poga pārlūkprogrammā nedrīkst rādīt jutīgu vēsturi no kešatmiņas. Pārbaudē jāiekļauj paziņojumu priekšskatījumi, pārlūka automātiskā aizpilde un lokālie bezsaistes dati. Vienlaikus lietotājam jāsaņem skaidrs apstiprinājums par to, kuras piekļuves ir pārtrauktas un vai sarunu dati joprojām tiek saglabāti. Tādējādi atsaukšana netiks sajaukta ar dzēšanu.

Veidojiet dzēšanas apstiprinājumu piekļūstamu un kļūdu tolerantu

Neatgriezeniskai darbībai ir nepieciešams mierīgs, saprotams apstiprinājums. WCAG 2.2 skaidrojums par 3.3.4. veiksmes kritēriju attiecas arī uz lietotāja kontrolēto datu mainīšanu vai dzēšanu. Ir paredzēta vismaz viena iespēja atcelt, pārbaudīt vai apstiprināt darbību. Kurš variants ir piemērots, atkarīgs no produkta.

Labos dialogos tiek konkrēti nosauktas „3 sarunas un 2 pielikumi”, nevis tikai vispārīgi „dati”. Primārā un destruktīvā darbība ir vizuāli atšķiramas, sasniedzamas ar tastatūru un nav izskaidrotas tikai ar krāsu. Pēc nosūtīšanas piekļūstama statusa zona paziņo, ka pieprasījums ir pieņemts. Atkritne ar ierobežotu atjaunošanas termiņu var novērst lietošanas kļūdas, taču tā nedrīkst slepeni pretrunāt apsolītajai tūlītējai dzēšanai.

Atbalsta nodošana (handoff) bez ēnas kopijas

Ja saruna tiek nodota cilvēkam, bieži vien tiek izveidots atsevišķs atbalsta pieteikums. Šim objektam var būt cits mērķis, citas piekļuves lomas un citi glabāšanas noteikumi. Tērzēšanas robota vēstures iestatījums nedrīkst šādu pieteikumu ne neredzami izdzēst, ne klusējot ignorēt. Pirms nodošanas saskarnei jāpaskaidro, kāds saturs tiks pārņemts. Vēlāka pieprasījuma gadījumā sistēmai jāatrod sasaiste un jāapstrādā gadījums saskaņā ar spēkā esošajiem noteikumiem.

Ja automātiskā dzēšana neizdodas vai identitāte un apjoms nav skaidrs, procesam ir nepieciešams drošs cilvēka kanāls. Rakstā par cilvēka atbalsta nodošanu tīmekļa vietņu atbalstā aprakstīti konteksta pakotņu un eskalācijas noteikumi. Nododams būtu tikai tas, kas atbildīgajam darbiniekam patiešām ir nepieciešams.

Ieviešanas kontrolsaraksts produktu un atbalsta komandām

1. Inventarizējiet visus sarunas datu objektus un glabāšanas vietas.
2. Modelējiet apskati, eksportēšanu, dzēšanu un atsaukšanu kā atsevišķas tiesības.
3. Jutīgām darbībām veiciet atkārtotu autentifikāciju, balstoties uz riskiem.
4. Strukturējiet eksporta pakotnes saprotami un iestatiet drošus derīguma termiņus.
5. Padariet dzēšanas soļus idempotentus un izsekojiet tos ar pieprasījuma ID.
6. Iekļaujiet meklēšanas indeksu, datnes, analītiku, integrācijas, kešatmiņas un atbalsta gadījumus.
7. Pārbaudiet apstiprinājuma dialogus un statusa ziņojumus ar tastatūru un ekrānlasītāju.
8. Simulējiet koplietošanas ierīces, saites ar beigušos termiņu un pazaudētas ierīces.
9. Redzami eskalējiet daļējas kļūdas, nekopējot jutīgu saturu žurnālos (logs).
10. Regulāri pārbaudiet glabāšanas un dzēšanas noteikumus kopā ar datu aizsardzības speciālistiem un nozares nodaļām.

Svarīgākie testi pirms sistēmas palaišanas

Testa gadījumiem nevajadzētu aptvert tikai veiksmīgo ceļu (happy path). Pārbaudiet paralēlus dzēšanas pieprasījumus, pieteikšanās termiņa beigšanos eksporta laikā, jau atsauktas saites, jaunus ziņojumus tekošas dzēšanas laikā un pieslēgtās sistēmas atteici. Pārbaudiet arī, vai eksports nesatur citu personu ziņojumus no kopīgotiem kontiem un vai izdzēstā datne joprojām ir pieejama, izmantojot veco URL.

Katrai darbībai ir nepieciešams sagaidāmais rezultāts saskarnē, API un atmiņā. Tāpēc labs pieņemšanas meklējums nebeidzas ar zaļu veiksmes paziņojumu. Pēc tam tas pārbauda būtiskās datu krātuves, žetonus un publiskos URL. Notikumu žurnāliem būtu jāpierāda, ka solis tika izpildīts, atkārtoti nesaglabājot izdzēsto sarunas saturu.

Secinājums: lietotāju kontrole ir visaptveroša (end-to-end) īpašība

Uzticams tērzēšanas robots ne tikai padara vēsturi atrodamu. Tas nošķir skatu, eksportu, dzēšanu un atsaukšanu, atbilstoši pārbauda jutīgas darbības un parāda faktisko apstrādes stāvokli. Izšķirošā nozīme ir skaidras lietotāja pieredzes (UX) apvienojumam ar datu modeli, kas zina visas atkarīgās sistēmas.

Iekļaujot šīs funkcijas arhitektūrā, atbalsta procesos un testos jau sākumposmā, jūs samazināt manuālos izņēmuma gadījumus un izvairāties no viltus solījumiem. Plānošanas laikā pārbaudiet arī, kuras ChatReact funkcijas ir piemērotas jūsu tīmekļa vietnei un atbalsta procesam. Sāciet ar datu inventarizāciju un vienu visaptverošu testu: eksportēt vēsturi, atsaukt piekļuves, ierosināt dzēšanu un pierādīt rezultātu visās iesaistītajās sistēmās.

Avoti un papildu norādes

• EUR-Lex: Regula (ES) 2016/679, jo īpaši 5., 12., 15., 17. un 20. pants.
• EDPB: Guidelines 01/2022 on data subject rights – Right of access, Version 2.1.
• NIST SP 800-63B: Session Management.
• W3C: Understanding WCAG 2.2 Success Criterion 3.3.4.