Chatbot-historian poistaminen ja vieminen: Turvallinen käyttäjänhallinta

Chatbot-historia on käyttäjälle kätevä: vastauksia voi lukea jälkikäteen, keskustelua voi jatkaa myöhemmin tai tiedot voi siirtää asiakastukeen. Sama historia voi kuitenkin sisältää tilausnumeroita, ongelmakuvauksia, yhteystietoja tai muita arkaluonteisia tietoja. Keskusteluja tallentava tiimi tarvitsee siksi enemmän kuin huomaamattoman "Historia"-kytkimen. Käyttäjien tulee ymmärtää, mitä tietoja on olemassa, miten he voivat ottaa ne mukaansa, poistaa ne tai peruuttaa tulevan pääsyn niihin.

Tämä opas esittelee toteutuskelpoisen tuote- ja teknisen mallin verkkosivustojen chateille. Se yhdistää käyttäjäystävällisyyden, tietojen minimoinnin, turvallisen identiteetin tarkistuksen ja läpinäkyvät järjestelmätilat. Nämä ohjeet eivät ole yksilöllistä oikeudellista neuvontaa; konkreettiset velvoitteet riippuvat muun muassa käyttötarkoituksesta, oikeusperusteesta, järjestelmäarkkitehtuurista ja kyseessä olevista tiedoista.

Neljä toimintoa yhden historiakytkimen sijaan

"Hallitse historiaa" on liian epämääräinen käsite. Käyttöliittymässä ja taustajärjestelmässä tulisi erottaa toisistaan neljä eri tarkoitusta:

• Katsele: Käyttäjät lukevat tallennettuja keskusteluja, liitteitä ja tunnistettavia metatietoja selkeässä aikajärjestyksessä.
• Vie: Käyttäjät saavat kapea-alaisen kopion luettavassa muodossa ja, jos se on käyttötapauksen kannalta mielekästä tai lain mukaan pakollista, lisäksi jäsennellyssä koneellisesti luettavassa muodossa.
• Poista: Käyttäjät poistavat yksittäisiä keskusteluja tai koko niihin liittyvän historian. Käyttöliittymä selittää laajuuden, määräajat ja mahdolliset poikkeukset.
• Peruuta pääsy: Käyttäjät mitätöivät jakolinkit, tunnetut laitteet tai jatkamistunnisteet ilman, että kaikkia sisältötietoja tarvitsee välttämättä poistaa välittömästi.

Tämä erottelu ehkäisee vaarallisia väärinkäsityksiä. "Kirjaudu ulos" ei poista keskustelutietoja. "Piilota historia" ei tarkoita poistamista. Vanhentunut linkki ei myöskään automaattisesti tarkoita, että sen taustalla olevat tietueet olisivat kadonneet. Suosittelemme tutustumaan myös oppaaseemme koskien Chatbot-keskustelujen turvallista jatkamista.

Aloita selkeästä tietomallista

Ennen kuin tiimit suunnittelevat painikkeita, heidän tulee kartoittaa tallennetut objektit. Keskustelu ei useinkaan koostu vain viesteistä. Mukana on istuntotunnisteita, aikaleimoja, tiedostoviittauksia, turvallisuustapahtumia, tukipyyntöjä, palautetta ja teknisiä lokeja. Jokaiselle objektille tarvitaan dokumentoitu käyttötarkoitus, vastuuhenkilö, säilytyssääntö ja poistopolku.

Yleinen tietosuoja-asetus (GDPR) mainitsee artiklassa 5 muun muassa tietojen minimoinnin ja säilytyksen rajoittamisen. Artikla 15 koskee oikeutta saada pääsy tietoihin, artikla 17 oikeutta poistaa tiedot ehtoineen ja poikkeuksineen, sekä artikla 20 oikeutta siirtää tiedot järjestelmästä toiseen soveltamisalueellaan. Tästä ei seuraa, että jokaisen chatbot-käyttöliittymän pitäisi tarjota identtiset toiminnot. Tuotetiimien tulee kuitenkin rakentaa tietovirrat niin, että oikeutetut pyynnöt voidaan käsitellä luotettavasti.

Tarkista henkilöllisyys asianmukaisesti ennen vientiä ja poistamista

Joka tarjoaa pääsyn historiaan vain arvattavan linkin tai uudelleenkäytetyn istuntotunnisteen kautta, ottaa tietovuotoriskin. Samalla henkilöllisyyden tarkistus ei saa yleisesti vaatia enempää henkilötietoja kuin tietty toiminto edellyttää. Lopulliset EDPB:n ohjeet 01/2022 rekisteröidyn oikeuksista (oikeus saada pääsy tietoihin) käsittelevät muun muassa tunnistamista, laajuutta ja turvallista kopioiden toimittamista. GDPR:n 12 artiklan 6 kohta sallii lisätietojen pyytämisen henkilöllisyyden vahvistamiseksi, jos henkilöllisyydestä on perusteltua syytä epäillä.

Käytännössä riskiin perustuva porrastus on osoittautunut toimivaksi. Pseudonyymin lyhyen historian näyttäminen samalla laitteella voi vaatia voimassa olevan, lyhytkestoisen istunnon. Koko historian vienti, pysyvä poistaminen tai kaikkien laitteiden pääsyn peruuttaminen vaatii ennemmin uudelleentunnistautumista. Nykyinen NIST-ohjeistus istuntojen hallinnasta kuvaa uudelleentunnistautumisen, aikarajat ja istunnon päättämisen erillisinä valvontamekanismeina. Konkreettisen tason on vastattava riskiä; Yhdysvaltain liittovaltion virastoille suunnatut NIST-vaatimukset eivät sinänsä ole yleinen legal-vaatimus kaikille yrityksille.

Julkisten widgettien ja kirjautuneiden asiakasalueiden välisen rajan tulisi pysyä selkeänä. Artikkelimme koskien tunnistautumista ja tietoon pääsyä asiakasportaalissa selittää, miksi julkinen chat ei saa hienovaraisesti muuttua tilitietokanavaksi.

Viennin on oltava ymmärrettävä ja täysin selitettävissä

Hyvä vienti ei ole raaka tietokantatuloste. Se alkaa yleiskatsauksella: luontiajankohta, mukana olevat keskustelut, liitteet, käytetty aikavyöhyke ja muotoiluversio. Tämän jälkeen sisällöt seuraavat selkeässä järjestyksessä. JSON voi olla hyödyllinen rakenteellista jatkokäsittelyä varten; HTML tai PDF on monille helpommin luettavissa. Se, vaaditaanko siirrettävää muotoa lain mukaan ja missä laajuudessa, on tarkistettava tapauskohtaisesti.

Jos järjestelmä luo viennin asynkronisesti, käyttöliittymä tarvitsee selkeän tilan: "valmistellaan", "valmis asti…", "vanhentunut" tai "epäonnistunut". Latauslinkin tulisi olla lyhytikäinen, vaikeasti arvattava ja mitätöitävissä käytön jälkeen. Salaisuudet, kuten sisäiset kehotteet (promptit), pääsyavaimet tai muiden henkilöiden tiedot, eivät kuulu pakettiin. Ennen luovuttamista palvelinpuolen suodattimen tulee tarkistaa, vaativatko yhteydet tukitapauksiin, jaettuihin keskusteluihin tai kolmansien osapuolten sisältöihin erityiskäsittelyä.

Poistaminen tilakoneena välittömän lupauksen sijaan

Painike viestillä "Kaikki poistettu" on ongelmallinen, jos hakuindeksi, analytiikkavarasto, tukijärjestelmä tai varmuuskopio sisältävät edelleen kopioita. Parempi ratkaisu on pieni tilakone, joka kuvaa todellista prosessia.

Järkevät poistotilat

1. Pyydetty: Henkilöllisyys ja toivottu laajuus on vahvistettu.
2. Lukittu: Historia ei ole enää saatavilla normaalissa käytössä; jatkamis- ja jakotunnisteet ovat mitätöityjä.
3. Käsittelyssä: Ensisijaista tallennustilaa, hakua, tiedostovarastoa, analytiikka- ja integraatiokohteita käydään läpi.
4. Valmis: Suunnitellut aktiiviset järjestelmät on puhdistettu; jäljellä olevat varmuuskopiot noudattavat dokumentoitua varmuuskopiointisykliä tai perusteltua poikkeusta.
5. Osittain estetty: Jotain järjestelmää ei voitu puhdistaa tai tiedot on säilytettävä toistaiseksi. Tapaus eskaloidaan jäljitettävästi.

Älä unohda riippuvaisia tietoja

Viestit voivat viitata tiedostoihin, vektori-upotuksiin (embeddings), hakuhakemistoihin, laatuarvioihin, CRM-tietoihin tai tukipyyntöihin. Poistopyyntö tarvitsee siksi pysyvän pyyntötunnisteen (ID) ja idempotentit työvaiheet: Uusi suoritus ei saa luoda uusia kopioita tai perua jo tehtyjä vaiheita. Mittaustietojen osalta tulisi jo suunnitteluvaiheessa päättää, voidaanko aggregoidut tunnusluvut, joita ei voi enää yhdistää käyttäjään, säilyttää. Lisää tästä löydät artikkelista tietoja minimoiva chatbot-analytiikka.

Pääsyn peruuttaminen suojaa erityisesti yhteiskäyttölaitteilla

Hotelleissa, myymälöissä, työpajoissa tai perheissä ihmiset vaihtuvat usein samalla laitteella. Siksi "Peruuta pääsy" -toiminnon pitäisi pystyä muuhunkin kuin evästeen poistamiseen paikallisesti. Palvelinpuolella tunnetut istuntotunnisteet, jakolinkit ja mahdolliset laitesidonnaisuudet on mitätöitävä. Käyttöliittymän tulisi erottaa toisistaan "tämä laite", "kaikki laitteet" ja "kaikki jaetut linkit".

Peruuttamisen jälkeen Takaisin-painike ei saa näyttää arkaluonteista historiaa selaimen välimuistista. Ilmoitusten esikatselut, selaimen automaattinen täydennys ja paikalliset offline-tiedot kuuluvat tarkistuksen piiriin. Samalla käyttäjän tulee saada selkeä vahvistus siitä, mitkä pääsyoikeudet on lopetettu ja ovatko keskustelutiedot edelleen tallennettuina. Näin pääsyn peruuttamista ei sekoiteta tietojen poistamiseen.

Tee poiston vahvistuksesta saavutettava ja virhesietoinen

Pysyvä toiminto vaatii rauhallisen ja ymmärrettävän vahvistuksen. WCAG 2.2 -ohjeistus onnistumiskriteerille 3.3.4 koskee nimenomaisesti myös käyttäjän hallinnoimien tietojen muuttamista tai poistamista. Tarjolla tulee olla vähintään yksi mahdollisuus perumiseen, tarkistamiseen tai vahvistamiseen. Tuotteeseen sopiva vaihtoehto riippuu sovelluksesta.

Hyvät dialogit nimeävät konkreettisesti esim. "3 keskustelua ja 2 liitettä" pelkän "Tiedot"-sanan sijaan. Ensisijainen ja tuhoisa toiminto ovat visuaalisesti erotettavissa, saavutettavissa näppäimistöllä eikä niitä ole selitetty pelkällä väriepäsuhdalla. Lähettämisen jälkeen saavutettava tilatiedote ilmoittaa pyynnön vastaanottamisesta. Roskakori rajoitetulla palautusajalla voi estää käyttövirheitä, mutta se ei saa salaa sotia luvattua välitöntä poistoa vastaan.

Tukitiimille siirto ilman haamukopioita

Kun keskustelu siirretään ihmisille, syntyy usein erillinen tukipyyntö (ticket). Tällä objektilla voi olla eri käyttötarkoitus, eri pääsyroolit ja eri säilytyssääntö. Chatbotin historia-asetus ei saa poistaa tällaista tikettiä näkymättömästi eikä myöskään sivuuttaa sitä hiljaisesti. Ennen siirtoa käyttöliittymän tulee selittää, mitä sisältöjä siirretään. Myöhemmän pyynnön yhteydessä järjestelmän on löydettävä yhteys ja käsiteltävä tapaus voimassa olevien sääntöjen mukaisesti.

Jos automaattinen poisto epäonnistuu tai henkilöllisyys ja laajuus ovat epäselviä, prosessi tarvitsee turvallisen inhimillisen kanavan. Artikkeli koskien Human Handoffia verkkosivutuessa kuvaa kontekstipaketit ja eskalointisäännöt tätä varten. Vain se tulee siirtää, mitä toiminnasta vastaava työntekijä todella tarvitsee.

Toteutuksen tarkistuslista tuote- ja tukitiimeille

1. Kartoita kaikki keskustelun tietiobjektit ja tallennuspaikat.
2. Mallinna katselu, vienti, poisto ja peruutus erillisiksi oikeuksiksi.
3. Uudelleentunnista käyttäjä riskiperusteisesti kriittisiä toimintoja varten.
4. Rakenna vientipakettien rakenne ymmärrettävästi ja aseta turvalliset vanhentumisajat.
5. Tee poistovaiheista idempotentteja ja seuraa niitä pyyntötunnisteella (ID).
6. Ota mukaan hakuindeksi, tiedostot, analytiikka, integraatiot, välimuistit ja tukitapaukset.
7. Testaa vahvistusdialogit ja tilailmoitukset näppäimistöllä ja ruudunlukuohjelmalla.
8. Simuloi yhteiskäyttölaitteita, vanhentuneita linkkejä ja kadonneita laitteita.
9. Eskaloi osittaiset virheet näkyvästi ilman arkaluonteisten sisältöjen kopioimista lokeihin.
10. Tarkista säilytys- ja poistosäännöt säännöllisesti tietosuojavastaavan ja liiketoiminta-alueiden kanssa.

Tärkeimmät testit ennen julkaisua

Testitapausten ei pitäisi kattaa vain ihannepolkua (happy path). Testaa rinnakkaisia poistopyyntöjä, viennin aikana vanhenevaa kirjautumista, jo peruutettuja linkkejä, uusia viestejä käynnissä olevan poiston aikana sekä integroidun järjestelmän toimintahäiriötä. Tarkista myös, sisältääkö vienti vieraita viestejä jaetuilta tileiltä ja onko poistettu tiedosto edelleen saatavilla vanhan URL-osoitteen kautta.

Jokaisella toiminnolla on oltava odotettu tulos käyttöliittymässä, API:ssa ja tallennustilassa. Hyvä hyväksyntätesti ei siksi pääty vihreään onnistumisilmoitukseen. Se tarkistaa sen jälkeen oleelliset tietovarastot, tunnisteet ja julkiset URL-osoitteet. Tapahtumalokien tulisi osoittaa, että vaihe suoritettiin, tallentamatta poistettua keskustelusisältöä uudelleen.

Johtopäätös: Käyttäjän hallintaoikeus on päästä päähän -ominaisuus

Luotettava chatbot ei vain tee historiasta löydettävää. Se erottaa katselun, viennin, poistamisen ja pääsyn peruuttamisen, tarkistaa arat toiminnot asianmukaisesti ja näyttää todellisen käsittelytilan. Ratkaisevaa on selkeän UX:n yhdistäminen tietomalliin, joka tuntee kaikki riippuvaiset järjestelmät.

Ne, jotka integroivat nämä toiminnot varhaisessa vaiheessa arkkitehtuuriin, tukiprosesseihin ja testaukseen, vähentävät manuaalisia poikkeustapauksia ja välttävät katteettomia lupauksia. Tarkista suunnittelun yhteydessä myös, mitkä ChatReact-ominaisuudet sopivat verkkosivustollesi ja tukiprosessiisi. Aloita tietojen kartoituksella ja yhdellä päästä päähän -testillä: vie historia, peruuta pääsyoikeudet, käynnistä poisto ja todenna tulos kaikissa osallistuvissa järjestelmissä.

Lähteet ja lisätiedot

• EUR-Lex: Asetus (EU) 2016/679, erityisesti artiklat 5, 12, 15, 17 ja 20.
• EDPB: Guidelines 01/2022 on data subject rights – Right of access, Versio 2.1.
• NIST SP 800-63B: Session Management.
• W3C: Understanding WCAG 2.2 Success Criterion 3.3.4.