Slet og eksporter chatbot-historik: Sikker brugerkontrol

En chatbot-historik er praktisk for brugerne: De kan genlæse svar, fortsætte en samtale senere eller overdrage information til supporten. Men den samme historik kan indeholde ordrenumre, problembeskrivelser, kontaktoplysninger eller andre følsomme oplysninger. Gemmer man samtaler, har man derfor brug for mere end en usynlig "historik"-knap. Brugerne bør forstå, hvilke data der findes, hvordan de kan tage dem med sig, slette dem eller tilbagekalde den videre adgang.

Denne guide viser en praktisk produkt- og teknikmodel til website-chatbots. Den kombinerer brugervenlighed, dataminimering, sikker identitetskontrol og gennemskuelige systemtilstande. Anvisningerne udgør ikke individuel juridisk rådgivning; konkrete forpligtelser afhænger blandt andet af formål, retsgrundlag, systemarkitektur og de berørte data.

Fire funktioner i stedet for én enkelt historik-knap

"Administrer historik" er for uklart. I brugerfladen og i backend bør fire forskellige hensigter adskilles:

• Visning: Brugerne læser gemte samtaler, vedhæftede filer og synlige metadata i en forståelig kronologi.
• Eksport: De modtager en kopi i et læsbart format og, hvis det er relevant eller juridisk krævet for anvendelsen, desuden i et struktureret, maskinlæsbart format.
• Sletning: De fjerner enkelte samtaler eller hele den tilknyttede historik. Brugerfladen forklarer omfang, frister og eventuelle undtagelser.
• Tilbagekaldelse af adgang: De gør delingslinks, kendte enheder eller genoptagelses-tokens ugyldige uden nødvendigvis at slette alt indhold med det samme.

Denne adskillelse forhindrer farlige misforståelser. "Log ud" sletter ikke samtaledata. "Skjul historik" er ikke en sletning. Og et udløbet link betyder ikke automatisk, at de underliggende dataposter er forsvundet. Supplerende kan du læse vores guide til sikker genoptagelse af chatbot-samtaler.

Start med en klar datamodel

Før teams designer knapper, bør de kortlægge de gemte objekter. En samtale består ofte ikke kun af beskeder. Derudover kommer sessions-ID'er, tidsstempler, filreferencer, sikkerhedshændelser, support-tickets, feedback og tekniske logfiler. For hvert objekt kræves et dokumenteret formål, en ansvarlig, en opbevaringsregel og en slettevej.

Databeskyttelsesforordningen nævner i artikel 5 blandt andet dataminimering og opbevaringsbegrænsning. Artikel 15 vedrører indsigtsretten, artikel 17 retten til sletning med forudsætninger og undtagelser, og artikel 20 dataportabilitet inden for deres respektive anvendelsesområder. Det betyder ikke, at enhver chatbot-brugerflade skal tilbyde identiske funktioner. Men produktteams bør opbygge datastrømme således, melem berettigede anmodninger kan behandles pålideligt.

Kontroller identitet i et passende omfang før eksport og sletning

Hvis man kun gør en historik tilgængelig via et gætbart link eller et genanvendt sessions-ID, risikerer man datalækage. Samtidig må en identitetskontrol ikke generelt kræve flere personoplysninger end nødvendigt for den konkrete handling. De endelige EDPB-retningslinjer 01/2022 om indsigtsret behandler blandt andet identifikation, omfang og sikker levering af kopier. Artikel 12, stk. 6, i GDPR tillader yderligere oplysninger til identitetsbekræftelse, hvis der er rimelig tvivl om identiteten.

I praksis har en risikobaseret opdeling vist sig velfungerende. At vise en pseudonym, kort historik på den samme enhed kan kræve en gyldig, kortvarig session. En samlet eksport, en uigenkaldelig sletning eller tilbagekaldelse af alle enheder retfærdiggør i højere grad en ny autentificering. Den aktuelle NIST-retningslinje for sessionsstyring beskriver genautentificering, tidsgrænser og sessionsterminering som selvstændige kontroller. Den konkrete styrke skal passe til risikoen; NIST-krav for amerikanske føderale myndigheder er ikke et generelt juridisk krav til alle virksomheder.

For offentlige widgets og loggede kundeområder bør grænsen være synlig. Vores artikel om identitet og dataadgang i kundeportalen viser, hvorfor en offentlig chat ikke stiltiende bør blive til en kontodatakanal.

En eksport skal være forståelig og fuldt ud forklarbar

En god eksport er ikke et råt dump fra databasen. Den starter med en oversigt: oprettelsesperiode, indeholdte samtaler, vedhæftede filer, anvendt tidszone og formatversion. Derefter følger indholdet i en klar rækkefølge. JSON kan være hensigtsmæssigt til struktureret viderebehandling; HTML eller PDF er nemmere at læse for mange mennesker. Hvorvidt og i hvilket omfang et bærbart format kræves juridisk, bør vurderes i det konkrete tilfælde.

Genererer systemet eksporten asynkront, skal brugerfladen vise en entydig status: "forberedes", "klar indtil...", "udløbet" eller "fejlet". Download-linket bør være kortvarigt, ikke-gætbart og tilbagekaldeligt efter brug. Hemmeligheder som interne prompts, adgangsnøgler eller andres data hører ikke hjemme i pakken. Før levering bør et server-side filter kontrollere, om relationer til supportsager, delte samtaler eller tredjepartsindhold kræver særlig håndtering.

Sletning som tilstandsmaskine i stedet for øjeblikkeligt løfte

En knap med meddelelsen "Alt er slettet" er problematisk, hvis søgeindeks, analysearkiv, supportsystem eller backup stadig indeholder kopier. Det er bedre med en lille tilstandsmaskine, der afspejler den faktiske proces.

Hensigtsmæssige slettetilstande

1. Anmodet: Identitet og ønsket omfang er bekræftet.
2. Låst: Historikken er ikke længere tilgængelig for normal brug; genoptagelses- og delings-tokens er ugyldige.
3. Under behandling: Primært lager, søgeindeks, fillager, analyse- og integrationsmål behandles.
4. Afsluttet: De planlagte aktive systemer er ryddet; resterende sikkerhedskopier er underlagt den dokumenterede backup-rotation eller en begrundet undtagelse.
5. Delvist blokeret: Et system kunne ikke ryddes, eller data skal foreløbigt bevares. Sagen eskalerers gennemskueligt.

Glem ikke afhængige data

Beskeder kan henvise til filer, embeddings, søgeindeks, kvalitetsvurderinger, CRM-dataposter eller support-tickets. Sletteanmodningen har derfor brug for et stabilt anmodnings-ID og idempotente arbejdstrin: En ny kørsel må ikke oprette nye kopier eller rulle allerede udførte trin tilbage. For måledata bør det besluttes allerede ved designet, om aggregerede nøgletal, der ikke længere kan henføres til en person, kan bevares. Læs mere om dette i artiklen om dataminimeret chatbot-analytics.

Tilbagekaldelse beskytter især på delte enheder

På hoteller, i salgslokaler, værksteder eller familiehusstande skifter personer oftere på den samme enhed. Derfor bør "Tilbagekald adgang" kunne mere end blot at slette en cookie lokalt. På serversiden skal kendte sessions-tokens, delingslinks og eventuelle enhedstilknytninger gøres ugyldige. Brugerfladen bør skelne mellem "denne enhed", "alle enheder" og "alle delte links".

Efter tilbagekaldelse må tilbage-knappen ikke vise en følsom historik fra en cache. Forhåndsvisninger i meddelelser, browser-autofuldførelse og lokale offline-data bør inkluderes i kontrollen. Samtidig bør brugeren modtage en klar bekræftelse af, hvilke adgange der er afsluttet, og om samtaledata stadig er gemt. På den måde forveksles tilbagekaldelse ikke med sletning.

Gør slettebekræftelsen tilgængelig og fejltolerant

En uigenkaldelig handling kræver en rolig, forståelig bekræftelse. WCAG 2.2-forklaringen til succeskriterium 3.3.4 refererer udtrykkeligt også til ændring eller sletning af brugerkontrollerede data. Der kræves mindst én mulighed for omstødelse, kontrol eller bekræftelse. Hvilken variant der passer, afhænger af produktet.

Gode dialoger nævner konkret "3 samtaler og 2 vedhæftede filer" i stedet for blot "data". Den primære og den destruktive handling er visuelt adskilt, tilgængelige via tastatur og ikke kun forklaret ved hjælp af farve. Efter afsendelse oplyser et tilgængeligt statusområde, at anmodningen er modtaget. En papirkurv med en begrænset genoprettelsesfrist kan opfange betjeningsfejl, men må ikke i det skjulte modstride en promised øjeblikkelig sletning.

Support-handoff uden skyggekopi

Overdrages en samtale til et menneske, opstår der ofte en separat support-ticket. Dette objekt kan have et andet formål, andre adgangsroller og en anden opbevaringsregel. Historikindstillingen i chatbotten må hverken usynligt slette eller stiltiende ignorere en sådan ticket. Før overdragelsen bør brugerfladen forklare, hvilket indhalt der overføres. Ved en senere anmodning skal systemet finde sammenkædningen og behandle sagen efter de gældende regler.

Hvis en automatisk sletning fejler, eller hvis identitet og omfang er uklart, skal processen have en sikker menneskelig kanal. Artiklen om Human Handoff i website-support beskriver kontekstpakker og eskaleringsregler til dette formål. Der bør kun overdrages det, som den ansvarlige medarbejder reelt har brug for.

Implementeringstjekliste til produkt- og supportteams

1. Kortlæg alle dataobjekter og opbevaringssteder for en samtale.
2. Modeler visning, eksport, sletning og tilbagekaldelse som adskilte rettigheder.
3. Genautentificer risikobaseret for følsomme handlinger.
4. Strukturer eksportpakker forståeligt og fastsæt sikre udløbstider.
5. Gør slettetrin idempotente og spor dem med et anmodnings-ID.
6. Inkluder søgeindeks, filer, analytics, integrationer, caches og supportsager.
7. Test bekræftelsesdialoger og statusmeddelelser med tastatur og skærmlæser.
8. Simuler delte enheder, udløbne links og mistede enheder.
9. Eskaler delvise fejl synligt uden at kopiere følsomt indhold til logfiler.
10. Gennemgå opbevarings- og sletteregler regelmæssigt med databeskyttelsesansvarlige og fagafdelinger.

De vigtigste tests før go-live

Testcases bør ikke kun dække "happy path". Test parallelle sletteanmodninger, et login der udløber under eksport, allerede tilbagekaldte links, nye beskeder under en igangværende sletning og svigt af et tilsluttet system. Kontroller desuden, om en eksport indeholder fremmede beskeder fra delte konti, og om en slettet fil stadig er tilgængelig via en gammel URL.

For enhver handling kræves et forventet resultat i brugerflade, API og lagring. En god godkendelsestest slutter derfor ikke ved en grøn succesmeddelelse. Den kontrollerer efterfølgende de relevante datalagringstjenester, tokens og offentlige URL'er. Hændelseslogge bør dokumentere, at et trin er udført, uden at gemme det slettede samtaleindhold igen.

Konklusion: Brugerkontrol er en ende-til-ende-egenskab

En troværdig chatbot gør ikke kun historikken nem at finde. Den adskiller visning, eksport, sletning og tilbagekaldelse, kontrollerer følsomme handlinger i et passende omfang og viser den reelle behandlingsstatus. Afgørende er forbindelsen mellem en klar UX og en datamodel, der kender alle afhængige systemer.

Integrerer man disse funktioner tidligt i arkitektur, supportprocesser og tests, reducerer man manuelle undtagelsestilfælde og undgår falske løfter. Undersøg ved planlægningen også, hvilke ChatReact-funktioner der passer til dit website og din supportproces. Start med en datakortlægning og en enkelt ende-til-ende-test: Eksporter historik, tilbagekald adgange, udløs sletning og påvis resultatet i alle involverede systemer.

Kilder og supplerende information

• EUR-Lex: Forordning (EU) 2016/679, især artikel 5, 12, 15, 17 og 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.