Vestlusboti ajaloo kustutamine ja eksportimine: Turvaline kasutajakontroll

Vestlusboti ajalugu on kasutajale mugav: nad saavad vastuseid uuesti lugeda, vestlust hiljem jätkata või edastada teavet klienditoele. Sama ajalugu võib aga sisaldada tellimuse numbreid, probleemikirjeldusi, kontaktandmeid või muud tundlikku teavet. Kes vestlusi salvestab, vajab seepärast enamat kui lihtsalt ühte märkamatut „ajaloo“ lülitit. Kasutajad peaksid mõistma, millised andmed on olemas, kuidas neid kaasa võtta, kustutada või edasist juurdepääsu tühistada.

See juhend näitab rakendatavat toote- ja tehnilist mudelit veebisaidi vestlusbottidele. See ühendab kasutajasõbralikkuse, andmete minimeerimise, turvalise isikutuvastuse ja jälgitavad süsteemiolekuid. Need juhised ei ole individuaalne õigusnõustamine; konkreetsed kohustused sõltuvad muuhulgas eesmärgist, õiguslikust alusest, süsteemi arhitektuurist ja asjaomastest andmetest.

Neli funktsiooni üheainuse ajaloolüliti asemel

„Ajaloo haldamine“ on liiga ebatäpne. Kasutajaliideses ja taustasüsteemis tuleks eristada nelja erinevat kavatsust:

• Vaatamine: Kasutajad loevad salvestatud vestlusi, manuseid ja tuvastatavaid metaandmeid arusaadavas kronoloogias.
• Eksportimine: Nad saavad koopia loetavas formaadis ning, kui see on kasutusjuhu jaoks mõistlik või seadusega nõutud, lisaks struktureeritud masinloetavas formaadis.
• Kustutamine: Nad eemaldavad üksikud vestlused või kogu seostatud ajaloo. Liides selgitab ulatust, tähtaegu ja võimalikke erandeid.
• Juurdepääsu tühistamine: Nad muudavad jagamislingid, tuntud seadmed või taasalustamise märgid (tokenid) kehtetuks, ilma et peaksid tingimata kõiki sisuandmeid kohe kustutama.

See eristamine hoiab ära ohtlikud arusaamatused. „Logi välja“ ei kustuta vestlusandmeid. „Peida ajalugu“ ei tähenda kustutamist. Ja aegunud link ei tähenda automaatselt, et selle aluseks olevad andmekirjed on kadunud. Lisaks tasub lugeda meie juhendit vestlusboti vestluste turvalise jätkamise kohta.

Alustage selge andmemudeliga

Enne kui meeskonnad hakkavad nuppe kujundama, peaksid nad salvestatud objektid inventariseerima. Vestlus ei koosne sageli vaid sõnumitest. Lisanduvad seansitunnused, ajatemplid, failiviited, turvasündmused, klienditue piletid, tagasiside ja tehnilised logid. Iga objekti jaoks on vaja dokumenteeritud eesmärki, vastutajat, säilitamise reeglit ja kustutusteed.

Isikuandmete kaitse üldmäärus nimetab artiklis 5 muuhulgas andmete minimeerimist ja säilitamise piirangut. Artikkel 15 käsitleb juurdepääsuõigust, artikkel 17 kustutamisõigust koos tingimuste ja eranditega ning artikkel 20 andmete ülekanditavust nende vastavas kohaldusalas. Sellest ei tulene, et iga vestlusboti liides peaks pakkuma identseid funktsioone. Tootemeeskonnad peaksid aga andmevood ehitama nii, et õigustatud päringuid saaks usaldusväärselt töödelda.

Kontrollige isikusamasust enne eksporti ja kustutamist asjakohaselt

Kes võimaldab juurdepääsu ajaloole vaid äraarvatava lingi või taaskasutatud seansitunnuse kaudu, riskib andmelekkeid tekitada. Samal ajal ei tohi isikutuvastus nõuda üldistatult rohkem isikuandmeid kui konkreetse toimingu jaoks vajalik. EDPB lõplikud suunised 01/2022 juurdepääsuõiguse kohta käsitlevad muuhulgas identifitseerimist, ulatust ja koopiate turvalist pakkumist. IKÜM artikli 12 lõige 6 lubab küsida täiendavat teavet isikusamasuse kinnitamiseks, kui tekib põhjendatud kahtlus isiku suhtes.

Praktikas on end tõestanud riskipõhine tasemete seadmine. Pseudonüümse lühiajaloo kuvamine samas seadmes võib eeldada kehtivat, lühiajalist seanssi. Täielik eksport, tagasipööramatu kustutamine või kõigi seadmete juurdepääsu tühistamine õigustab pigem korduvautentimist. Praegune NISTi seansihaldusjuhend kirjeldab korduvautentimist, ajapiiranguid ja seansi lõpetamist iseseisvate kontrollimeetmetena. Konkreetne tugevus peab vastama riskile; NISTi nõuded USA föderaalasutustele ei ole seejuures üldine õiguslik nõue iga ettevõtte jaoks.

Avalike vidinate ja sisselogitud kliendialade vahel peaks piir jääma nähtavaks. Meie artikkel isikusamasusest ja andmejuurdepääsust kliendiportaalis näitab, miks avalik vestlus ei tohiks vaikimisi muutuda konto andmekanaliks.

Eksport peab olema arusaadav ja täielikult selgitatav

Hea eksport ei ole andmebaasi toorandmete väljavõte. See algab ülevaatega: loomise ajavahemik, sisalduvad vestlused, manused, kasutatud ajavöönd ja formaadi versioon. Sellele järgneb sisu selges järjekorras. JSON võib olla mõistlik struktureeritud edasitöötlemiseks; HTML või PDF on paljudele inimestele kergemini loetav. Seda, kas ja millises ulatuses on porditav formaat õiguslikult nõutud, tuleks kontrollida konkreetse juhu puhul.

Kui süsteem loob ekspordi asünkroonselt, vajab liides selget olekut: „ettevalmistamisel“, „valmis kuni...“, „aegunud“ või „ebatõnnestunud“. Allalaadimislink peaks olema lühiajaline, mitte-äraarvatav ja pärast kasutamist tühistatav. Saladused, nagu sisesed juhised (promptid), juurdepääsuvõtmed või teiste inimeste andmed, ei kuulu paketti. Enne pakkumist peaks serveripoolne filter kontrollima, kas seosed klienditoe juhtumite, jagatud vestluste või kolmandate osapoolte sisuga nõuavad erikohtlemist.

Kustutamine kui olekumasin, mitte kohene lubadus

Nupp sõnumiga „Kõik kustutatud“ on problemaatiline, kui otsinguindeks, analüütikahoidla, klienditoe süsteem või varukoopia sisaldavad endiselt koopiaid. Parem on väike olekumasin, mis kajastab tegelikku protsessi.

Mõistlikud kustutusalased olekud

1. Taotletud: Isikusamasus ja soovitud ulatus on kinnitatud.
2. Blokeeritud: Ajalugu ei ole tavapäraseks kasutamiseks enam kättesaadav; taasalustamise ja jagamise märgid (tokenid) on kehtetud.
3. Töötlemisel: Püriandmebaas, otsinguindeks, failihoidla, analüütika- ja integratsioonieesmärgid töödeldakse läbi.
4. Lõpetatud: Ettenähtud aktiivsed süsteemid on puhastatud; ülejäänud turvakoopiad alluvad dokumenteeritud varukoopiate rotatsioonile või põhjendatud erandile.
5. Osaliselt blokeeritud: Mõnda süsteemi ei saanud puhastada või andmed tuleb praegu säilitada. Juhtumit eskaleeritakse jälgitavalt.

Ärge unustage sõltuvaid andmeid

Sõnumid võivad viidata failidele, vektoresitustele (embeddings), otsinguindeksitele, kvaliteedihinnangutele, CRM-i kirjetele või klienditoe piletitele. Kustutustaotlus vajab stabiilset taotluse ID-d ja idempotentseid töösamme: uuesti käivitamine ei tohi luua uusi koopiaid ega tühistada juba tehtud samme. Mõõteandmete puhul tuleks juba projekteerimisel otsustada, kas agregeeritud, enam mitte seostatavaid näitajaid saab säilitada. Rohkem sellest saab lugeda artiklist andmesäästliku vestlusboti analüütika kohta.

Tühistamine kaitseb eriti ühiselt kasutatavates seadmetes

Hotellides, müügisaalides, töökodades või peremajapidamistes vahetuvad inimesed samas seadmes sagedamini. Seetõttu peaks „juurdepääsu tühistamine“ suutma teha enamat kui lihtsalt küpsise kohapealset kustutamist. Serveri poolel peavad tuntud seansitokenid, jagamislingid ja vajaduse korral seadme seosed muutuma kehtetuks. Liides peaks eristama valikuid „see seade“, „kõik seadmed“ ja „kõik jagatud lingid“.

Pärast tühistamist ei tohi tagasinupp kuvada tundlikku ajalugu vahemälust. Teavituste eelvaated, brauseri automaattäide ja kohalikud võrguühenduseta andmed kuuluvad kontrollimisele. Samal ajal peaks kasutaja saama selge kinnituse, millised juurdepääsud lõpetati ja kas vestlusandmed on endiselt salvestatud. Nii ei aja kasutajad tühistamist segi kustutamisega.

Kujundage kustutamiskinnitus ligipääsetavaks ja veakindlaks

Pöördumatu toiming vajab rahulikku ja arusaadavat kinnitust. WCAG 2.2 selgitus edukriteeriumi 3.3.4 kohta viitab selgesõnaliselt ka kasutaja juhitavate andmete muutmisele või kustutamisele. Ettenähtud on vähemalt üks võimalus tagasivõtmiseks, kontrollimiseks või kinnitamiseks. Milline variant sobib, sõltub tootest.

Head dialoogid nimetavad konkreetselt „3 vestlust ja 2 manust“, mitte lihtsalt „andmed“. Peamine ja destruktiivne toiming on visuaalselt eristatavad, klaviatuuriga ligipääsetavad ega ole selgitatud ainult värvi abil. Pärast saatmist teatab ligipääsetav olekuala, et päring on vastu võetud. Piiratud taastamisajaga prügikast saab vältida kasutusvigu, kuid see ei tohi salaja vastu rääkida lubatud kohesele kustutamisele.

Klienditoele üleandmine ilma varjukoopiata

Kui vestlus antakse üle inimestele, tekib sageli eraldi klienditoe pilet. Sellel objektil võib olla teine eesmärk, teised juurdepääsurollid ja teine säilitamise reegel. Vestlusboti ajaloo seadistus ei tohi sellist piletit ei nähtamatult kustutada ega vaikimisi ignoreerida. Enne üleandmist peaks liides selgitama, milline sisu üle võetakse. Hilisema päringu korral peab süsteem leidma seose ja töötlema juhtumit vastavalt kehtivatele reeglitele.

Kui automaatne kustutamine ebaõnnestub või isikusamasus ja ulatus on ebaselged, vajab protsess turvalist inimkanalit. Artikkel inimlikust üleandmisest veebisaidi klienditoes kirjeldab selleks kontekstipakette ja eskaleerimise reegleid. Üle kanda tuleks vaid see, mida asjaomane töötaja tõesti vajab.

Rakendamise kontrollnimekiri toote- ja klienditoe meeskondadele

1. Inventariseerige kõik vestluse andmeobjektid ja salvestuskohad.
2. Mudeldage vaatamine, eksport, kustutamine ja tühistamine eraldiseisvate õigustena.
3. Korduvautentige tundlike toimingute puhul riskipõhiselt.
4. Struktureerige ekspordipaketid arusaadavalt ja määrake turvalised aegumisajad.
5. Muutke kustutamissammud idempotentseks ja jälgige neid taotluse ID abil.
6. Kaasake otsinguindeks, failid, analüütika, integratsioonid, vahemälud ja klienditoe juhtumid.
7. Testige kinnitusdialooge ja olekuteateid klaviatuuri ning ekraanilugejaga.
8. Simuleerige ühiselt kasutatavaid seadmeid, aegunud linke ja kaotatud seadmeid.
9. Eskaleerige osalised vead nähtavalt, ilma tundlikku sisu logidesse kopeerimata.
10. Kontrollige säilitus- ja kustutusreegleid regulaarselt koos andmekaitse ja spetsialistidega.

Kõige olulisemad testid enne avaldamist

Testjuhtumid ei peaks katma ainult ideaalset teekonda. Kontrollige paralleelseid kustutamispäringuid, ekspordi ajal aeguvat sisselogimist, juba tühistatud linke, uusi sõnumeid käimasoleva kustutamise ajal ja ühendatud süsteemi katkemist. Lisaks kontrollige, kas eksport sisaldab võõraid sõnumeid jagatud kontodelt ja kas kustutatud fail on vana URL-i kaudu veel kättesaadav.

Iga toimingu jaoks on vaja oodatavat tulemust liideses, API-s ja salvestusruumis. Hea vastuvõtutest ei lõpe seepärast rohelise eduteatega. See kontrollib seejärel asjakohaseid andmehoidlaid, tokeneid ja avalikke URL-e. Sündmuste logid peaksid tõendama, et samm viidi läbi, ilma et kustutatud vestlussisu uuesti salvestataks.

Kokkuvõte: Kasutajakontroll on otsast lõpuni omadus

Usaldusväärne vestlusbot ei tee ajalugu vaid hõlpsasti leitavaks. See eraldab vaatamise, ekspordi, kustutamise ja tühistamise, kontrollib tundlikke toiminguid asjakohaselt ning näitab tegelikku töötlemisolekut. Otsustav on selge kasutajakogemuse ühendamine andmemudeliga, mis tunneb kõiki sõltuvaid süsteeme.

Kes integreerib need funktsioonid varakult arhitektuuri, klienditoe protsessidesse ja testidesse, vähendab manuaalseid erijuhtumeid ja väldib valelubadusi. Kontrollige planeerimisel ka seda, millised ChatReact-funktsioonid sobivad teie veebisaidi ja klienditoe protsessiga. Alustage andmete inventuurist ja ühest ainukesest otsast lõpuni testist: eksportige ajalugu, tühistage juurdepääsud, algatage kustutamine ja tõendage tulemust kõigis seotud süsteemides.

Allikad ja lisamärkused

• EUR-Lex: Määrus (EL) 2016/679, eriti artiklid 5, 12, 15, 17 ja 20.
• 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.