Pokalbių boto istorijos ištrynimas ir eksportavimas: Saugi naudotojų kontrolė

Pokalbių boto istorija naudotojams yra patogi: jie gali perskaityti atsakymus, vėliau pratęsti pokalbį arba perduoti informaciją klientų aptarnavimo komandai. Tačiau toje pačioje istorijoje gali būti užsakymų numerių, problemų aprašymų, kontaktinių duomenų ar kitų jautrių duomenų. Todėl visiems, kurie saugo pokalbius, reikia daugiau nei nepastebimo mygtuko „Istorija“. Naudotojai turėtų suprasti, kokie duomenys yra saugomi, kaip juos parsisiųsti, ištrinti arba atšaukti tolesnę prieigą prie jų.

Šiame vadove pateikiamas praktiškai įgyvendinamas produktų ir techninis modelis, skirtas svetainių pokalbių botams. Jame derinamas patogumas naudotojui, duomenų mažinimas, saugus tapatybės patikrinimas ir aiškios sistemos būsenos. Šios rekomendacijos nėra individuali teisinė konsultacija; konkrečios prievolės priklauso nuo tikslo, teisinio pagrindo, sistemos architektūros ir susijusių duomenų.

Keturios funkcijos vietoje vieno istorijos jungiklio

„Valdyti istoriją“ yra per daug neapibrėžta sąvoka. Sąsajoje ir pagrindinėje sistemoje (backend) turėtų būti atskirti keturi skirtingi tikslai:

• Peržiūrėti: naudotojai skaito išsaugotus pokalbius, prisegtus failus ir atpažįstamus metaduomenis aiškia chronologine tvarka.
• Eksportuoti: jie gauna kopiją lengvai skaitomu formatu ir, jei tai prasminga arba teisiškai būtina pagal naudojimo atvejį, papildomai struktūrizuotu, mašininio skaitymo formatu.
• Ištrinti: jie pašalina atskirus pokalbius arba visą susijusią istoriją. Sąsajoje paaiškinama apimtis, terminai ir galimos išimtys.
• Atšaukti prieigą: jie panaikina bendrinimo nuorodų, žinomų įrenginių ar tęsimo žetonų (tokens) galiojimą, nebūtinai iš karto ištrindami visą turinį.

Šis atskyrimas padeda išvengti pavojingų nesusipratimų. „Atsijungti“ neištrina pokalbių duomenų. „Paslėpti istoriją“ nėra ištrynimas. O pasibaigus nuorodos galiojimui, tai automatiškai nereiškia, kad susiję duomenų įrašai dingo. Taip pat verta perskaityti mūsų vadovą apie saugų pokalbių boto seanso pratęsimą.

Pradėkite nuo aiškaus duomenų modelio

Prieš kuriant mygtukus, komandos turėtų inventorizuoti saugomus objektus. Pokalbis dažniausiai susideda ne tik iš pranešimų. Jį taip pat sudaro seansų identifikatoriai, laiko žymos, nuorodos į failus, saugumo įvykiai, aptarnavimo užklausos, atsiliepimai ir techniniai žurnalai (logs). Kiekvienas objektas turi turėti dokumentuotą tikslą, atsakingą asmenį, saugojimo taisyklę ir ištrynimo eigą.

Bendrajame duomenų apsaugos reglamente (BDAR) 5 straipsnyje, poleg kitų dalykų, minimas duomenų kiekio mažinimas ir saugojimo trukmės apribojimas. 15 straipsnis reglamentuoja teisę susipažinti su duomenimis, 17 straipsnis – teisę būti pamirštam (ištrynimą) su atitinkamomis sąlygomis ir išimtimis, o 20 straipsnis – teisę į duomenų perkeliamumą. Iš to neplaukia, kad kiekviena pokalbių boto sąsaja privalo siūlyti identiškas funkcijas. Tačiau produktų komandos turėtų taip sukurti duomenų srautus, kad pagrįstos užklausos būtų patikimai apdorojamos.

Tinkamai patikrinkite tapatybę prieš eksportavimą ir ištrynimą

Suteikiant prieigą prie istorijos tik per atspėjamą nuorodą arba pakartotinai naudojamą seanso ID, kyla duomenų nuttekėjimo rizika. Kartu tapatybės patikrinimas negali reikalauti daugiau asmens duomenų, nei būtina konkrečiam veiksmui atlikti. Galutinėse EDPB gairėse 01/2022 dėl teisės susipažinti su duomenimis, poleg kitų dalykų, nagrinėjamas identifikavimas, apimtis ir saugus kopijų pateikimas. BDAR 12 straipsnio 6 dalis leidžia prašyti papildomos informacijos tapatybei patvirtinti, jei kyla pagrįstų abejonių.

Praktikoje pasiteisina rizika pagrįstas lygiavimasis. Pseudoniminės trumposios istorijos rodymas tame pačiame įrenginyje gali reikalauti tik galiojančio, trumpalaikio seanso. Tačiau pilnas eksportavimas, negrįžtamas ištrynimas arba visų įrenginių prieigos atšaukimas reikalauja pakartotinio autentifikavimo. Dabartinėse NIST seansų valdymo gairėse pakartotinis autentifikavimas, laiko limitai ir seanso nutraukimas aprašomi kaip savarankiškos kontrolės priemonės. Konkretus saugumo lygis turi atitikti riziką; NIST reikalavimai JAV federalinėms agentūroms nėra visuotinis teisinis reikalavimas kiekvienai įmonei.

Viešiems valdikliams (widgets) ir prisijungusių klientų zonoms ši riba turėtų išlikti aiški. Mūsų straipsnyje apie tapatybę ir duomenų prieigą klientų portale paaiškinama, kodėl viešas pokalbis neturėtų tyliai tapti paskyros duomenų kanalu.

Eksportas turi būti suprantamas ir visiškai paaiškinamas

Geras eksportas nėra tik žali duomenys iš duomenų bazės. Jis prasideda nuo apžvalgos: sukūrimo laikotarpis, įtraukti pokalbiai, priedai, naudota laiko juosta ir formato versija. Toliau seka turinys aiškia tvarka. JSON formatas gali būti naudingas struktūrizuotam apdorojimui; HTML arba PDF daugeliui žmonių yra lengviau skaitomas. Ar ir kokia apimtimi portabilus formatas yra teisiškai reikalaujamas, turėtų būti įvertinta kiekvienu konkrečiu atveju.

Jei sistema eksportą generuoja asinchroniškai, sąsajai reikalinga aiški būsena: „ruošiama“, „paruošta iki …“, „pasibaigė galiojimas“ arba „nepavyko“. Atsisiuntimo nuoroda turėtų būti trumpalaikė, neatspėjama ir atšaukiama po panaudojimo. Slapti duomenys, pvz., vidinės užklausos (prompts), prieigos raktai ar kitų asmenų duomenys, neturi patekti į paketą. Prieš pateikiant duomenis, serverio filtras turėtų patikrinti, ar ryšiai su aptarnavimo atvejais, bendrinamais pokalbiais ar trečiųjų šalių turiniu reikalauja specialaus apdorojimo.

Ištrynimas kaip būsenų mašina, o ne momentinis pažadas

Mygtukas su pranešimu „Viskas ištrinta“ yra problemiškas, jei paieškos indekse, analitikos saugykloje, aptarnavimo sistemoje ar atsarginėse kopijose vis dar yra kopijų. Geriau naudoti nedidelę būsenų mašiną, kuri atspindi tikrąjį procesą.

Prasmingos ištrynimo būsenos

1. Pateikta užklausa: tapatybė ir pageidaujama apimtis yra patvirtintos.
2. Užblokuota: istorija nepasiekiama įprastam naudojimui; tęsimo ir bendrinimo žetonai nebegalioja.
3. Apdorojama: valoma pagrindinė saugykla, paieškos indeksas, failų saugykla, analitikos ir integracijos tikslai.
4. Užbaigta: numatytos aktyvios sistemos yra išvalytos; likusios atsarginės kopijos tvarkomos pagal dokumentuotą rotaciją arba pagrįstą išimtį.
5. Dalinai užblokuota: vienos iš sistemų nepavyko išvalyti arba duomenis laikinai privaloma išsaugoti. Atvejis sistemingai perduodamas aukštesniam lygmeniui.

Neužmirškite priklausomų duomenų

Pranešimai gali nuorodyti į failus, vektorius (embeddings), paieškos indeksus, kokybės įvertinimus, CRM įrašus ar aptarnavimo užklausas. Todėl ištrynimo užklausai reikia stabilaus užklausos ID ir idempotentiškų darbo žingsnių: pakartotinis paleidimas neturi sukurti naujų kopijų arba atšaukti jau atliktų veiksmų. Analitikos duomenims jau projektavimo metu turėtų būti nuspręsta, ar agreguoti, nebesusiejami rodikliai gali būti išsaugoti. Daugiau apie tai skaitykite straipsnyje apie atsakingą ir duomenis taupančią pokalbių botų analitiką.

Atšaukimas ypač apsaugo bendrai naudojamuose įrenginiuose

Viešbučiuose, pardavimo vietose, dirbtuvėse ar šeimos ūkiuose žmonės dažniau keičiasi prie to paties įrenginio. Todėl funkcija „Atšaukti prieigą“ turėtų gebėti daugiau nei tik ištrinti slapuką vietinėje naršyklėje. Serverio pusėje žinomi seansų žetonai, bendrinimo nuorodos ir, jei taikoma, įrenginių sąsajos turi tapti negaliojančiomis. Sąsaja turėtų skirti: „šis įrenginys“, „visi įrenginiai“ ir „visos bendrinamos nuorodos“.

Atšaukus prieigą, paspaudus mygtuką „Atgal“, naršyklė neturėtų rodyti jautrios istorijos iš podėlio (cache). Pranešimų peržiūros, naršyklės automatinis užpildymas ir vietiniai neprisijungus pasiekiami duomenys turėtų būti patikrinti. Kartu naudotojas turėtų gauti aiškų patvirtinimą, kurios prieigos buvo nutrauktos ir ar pokalbių duomenys vis dar saugomi. Taip išvengiama atšaukimo supainiojimo su ištrynimu.

Ištrynimo patvirtinimą padarykite prieinamą ir tolerantišką klaidoms

Negrįžtamam veiksmui reikalingas ramus, suprantamas patvirtinimas. WCAG 2.2 paaiškinimas dėl 3.3.4 sėkmės kriterijaus aiškiai taikomas ir naudotojo valdomų duomenų keitimui ar ištrynimui. Numatoma bent viena galimybė atšaukti, patikrinti arba patvirtinti veiksmą. Kuris variantas tinka, priklauso nuo produkto.

Geri dialogai nurodo konkrečiai „3 pokalbiai ir 2 priedai“, o ne tiesiog „duomenys“. Pagrindinis ir naikinamasis veiksmai yra vizualiai atskiriami, pasiekiami klaviatūra ir paaiškinti ne tik spalva. Išsiuntus užklausą, prieinama būsenos sritis praneša, kad užklausa priimta. Šiukšliadėžė su ribotu atstatymo terminu gali apsaugoti nuo naudojimo klaidų, tačiau neturi slapta prieštarauti pažadėtam momentiniam ištrynimui.

Perdavimas klientų aptarnavimui be šešėlinės kopijos

Kai pokalbis perduodamas žmogui, dažnai sukuriama atskira aptarnavimo užklausa (bilietas). Šis objektas gali turėti kitą tikslą, kitus prieigos vaidmenis ir kitą saugojimo taisyklę. Pokalbių boto istorijos nustatymas neturi nei nematomai ištrinti tokio bilieto, nei tyliai jo ignoruoti. Prieš perduodant, sąsajoje turėtų būti paaiškinta, koks turinys bus perkeltas. Vėlesnės užklausos metu sistema turi rasti šį ryšį ir apdoroti atvejį pagal galiojančias taisykles.

Jei automatinis ištrynimas nepavyksta arba tapatybė ir apimtis yra neaiškios, procesui reikalingas saugus žmogiškasis kanalas. Straipsnyje apie perdavimą žmogui svetainės aptarnavime aprašomi konteksto paketai ir eskalavimo taisyklės. Perduoti reikėtų tik tai, ko atsakingam darbuotojui tikrai reikia.

Įgyvendinimo kontrolinis sąrašas produktų ir palaikymo komandoms

1. Inventorizuoti visus pokalbio duomenų objektus ir saugojimo vietas.
2. Modeliuoti peržiūrą, eksportavimą, ištrynimą ir atšaukimą kaip atskiras teises.
3. Jautriems veiksmams taikyti rizika pagrįstą pakartotinį autentifikavimą.
4. Atsakingai struktūrizuoti eksporto paketus ir nustatyti saugius galiojimo terminus.
5. Ištrynimo žingsnius padaryti idempotentinius ir sekti juos naudojant užklausos ID.
6. Įtraukti paieškos indeksą, failus, analitiką, integracijas, podėlius ir aptarnavimo atvejus.
7. Išbandyti patvirtinimo dialogus ir būsenos pranešimus klaviatūra ir ekrano skaitytuve.
8. Simuliuoti bendrai naudojamus įrenginius, pasibaigusias nuorodas ir prarastus įrenginius.
9. Matomai eskaluoti dalines klaidas, nekopijuojant jautraus turinio į žurnalus.
10. Reguliariai tikrinti saugojimo ir ištrynimo taisykles su duomenų apsaugos specialistais ir padaliniais.

Svarbiausi testai prieš paleidimą

Testavimo atvejai turėtų apimti ne tik sėkmingą scenarijų. Patikrinkite lygiagrečias ištrynimo užklausas, prisijungimo galiojimo pabaigą eksportavimo metu, jau atšauktas nuorodas, naujus pranešimus vykstant ištrynimui ir prijungtos sistemos gedimą. Taip pat patikrinkite, ar eksporte nėra svetimų pranešimų iš bendrinamų paskyrų ir ar ištrintas failas vis dar pasiekiamas per seną URL adresą.

Kiekvienam veiksmui reikalingas tikėtinas rezultatas sąsajoje, API ir saugykloje. Todėl geras priėmimo testas nesibaigia žaliu sėkmės pranešimu. Po to tikrinamos atitinkamos duomenų saugyklos, žetonai ir viešieji URL adresai. Įvykių žurnalai turėtų įrodyti, kad žingsnis buvo atliktas, iš naujo neišsaugant ištrinto pokalbio turinio.

Išvada: naudotojų kontrolė yra visapusiška savybė

Patikimas pokalbių botas ne tik padaro istoriją lengvai randamą. Jis atskiria peržiūrą, eksportavimą, ištrynimą ir atšaukimą, tinkamai tikrina jautrius veiksmus ir rodo tikrąją apdorojimo būseną. Svarbiausia – aiškios vartotojo patirties (UX) ir duomenų modelio, žinančio visas priklausomas sistemas, derinys.

Iš anksto integravus šias funkcijas į architektūrą, palaikymo procesus ir testus, sumažėja rankinio apdorojimo išimčių ir išvengiama melagingų pažadų. Planuodami taip pat patikrinkite, kurios ChatReact funkcijos tinka jūsų svetainei ir aptarnavimo procesui. Pradėkite nuo duomenų inventoriaus ir vieno visapusiško testo: eksportuokite istoriją, atšaukite prieigas, paleiskite ištrynimą ir patikrinkite rezultatą visose susijusiose sistemose.

Šaltiniai ir papildoma informacija

• EUR-Lex: Reglamentas (ES) 2016/679, ypač 5, 12, 15, 17 ir 20 straipsniai.
• EDPB: Gairės 01/2022 dėl duomenų subjekto teisių – teisė susipažinti su duomenimis, 2.1 versija.
• NIST SP 800-63B: Seansų valdymas.
• W3C: WCAG 2.2 sėkmės kriterijaus 3.3.4 supratimas.