Samtalehukommelse i AI-chatbotten: Husk, ret og glem i tide

„Husk min foretrukne leveringsadresse“ kan gøre en website-chatbot praktisk. Men den samme mekanisme kan også føre gamle, forkerte eller følsomme oplysninger med over i senere samtaler. Ofte blandes tre ting sammen: det kortvarige forløb i en session, et kompakt resumé til fortsættelse og en permanent brugerprofil. De har forskellige formål, risici og opbevaringsfrister.

En god samtalehukommelse gemmer derfor ikke så meget som muligt. Den gemmer få, klart begrundede fakta med oprindelse, gyldighed og synlig kontrol. Denne vejledning viser en teknisk og redaktionel model, der forener nytte, korrekthed og databeskyttelse.

Adskil tre lagringstyper rent

Sessionskontekst indeholder de seneste beskeder, så opfølgende spørgsmål forbliver forståelige. Den slutter efter en kort inaktivitetsfrist eller ved eksplicit afslutning af chatten. Fortsættelsesresuméer reducerer et længere forløb til den nødvendige arbejdsstatus, for eksempel et åbent supportemne. Permanente egenskaber gælder på tværs af sessioner, for eksempel en sprogindstilling, som brugeren bevidst har gemt.

Adskillelsen forhindrer, at en fuldstændig chatlog bliver til en ubegrænset profil. Hver lagringstype får sit eget formål, adgang, udløb og slettevej. En teknisk tabel med et felt „memory“ uden denne adskillelse er svær at kontrollere og endnu sværere at rydde op i pålideligt.

Husk kun eksplicitte og egnede fakta

En chatbot bør ikke automatisk udlede en permanent egenskab af ethvert udsagn. „Jeg har brug for en regning på engelsk i dag“ betyder ikke nødvendigvis, at engelsk er den langsigtede præference. Gem kun oplysninger permanent, hvis nytten rækker ud over den aktuelle session, og hvor lagringen er forventelig for brugeren.

Særligt følsomme oplysninger, frie helbredsoplysninger, betalingsdata, adgangskoder og engangskoder hører ikke hjemme i en generel chathukommelse. Til forretningsmæssige transaktioner er det relevante fagsystem som regel det rette opbevaringssted. Chatbotten kan hente en godkendt reference i stedet for at oprette en ekstra skyggekopi.

Et huskeled kræver metadata

Gem en påmindelse som et struktureret datasæt, ikke som en ukontrolleret tekstblok. Nyttige felter er:

• Værdi og type: f.eks. foretrukket sprog eller valgt produktområde.
• Oprindelse: eksplicit brugerinput, bekræftet resumé eller verificeret fagsystem.
• Formål: hvorfor værdien er nødvendig i den næste samtale.
• Gyldighedsområde: bruger, organisation, website og eventuelt locale.
• Tidspunkt og udløb: hvornår det er gemt, senest bekræftet og automatisk slettet.
• Tillidsstatus: ubekræftet udledning, bekræftet eller verificeret.

Frie modelresuméer kan være nyttige, men skal forblive genkendelige som sådanne. De må ikke i det stille blive til verificerede kundedata.

Spørg synligt før lagring

Hvis en oplysning skal bruges ud over den aktuelle session, har brugerfladen brug for en forståelig beslutning. Angiv den konkrete værdi, formålet og en mulighed for sletning. En lille bekræftelse som „Gem dette sprog til fremtidige chats?“ er klarere end et generelt samtykke til tilpassede tjenester.

Afhængigt af formålet kan det juridiske grundlag variere og skal vurderes projektspecifikt. Brugerfladen bør ikke gennemtvinge det med mørke mønstre (dark patterns). Afvisning må ikke unødigt forhindre normal adgang til chatten. Logfør beslutningen adskilt fra det gemte indhold.

At huske er altid også at hente

Ved næste samtale må hele profilen ikke blindt kopieres ind i enhver prompt. Først kontrolleres identitet og tenant, og derefter indlæses kun de egenskaber, der er nødvendige for den aktuelle intent. Et spørgsmål om en regning kræver måske sprog og kundenummer, men ingen tidligere produktklage.

Vis desuden modellen oprindelse og alder. Et gammelt, ubekræftet resumé bør udløse et afklarende spørgsmål. En værdi fra et autoritativt system kan derimod bruges målrettet. På den måde skjules usikkerhed ikke bag flydende formuleringer.

Rettelse som en normal produktsti

Mennesker skifter mening, og modeller opsummerer forkert. Tilbyd derfor en visning af „Hvad chatbotten husker“ med redigering og sletning. I samtalen bør et udsagn som „Det passer ikke mere“ identificere den berørte værdi og bekræfte før ændringen.

Rettelser skal nå ud til alle relevante lag: profil, søgeindeks, cache og afledt resumé. Hvis man kun ændrer det synlige felt, mens en gammel embedding fortsat giver resultater, opstår der tilbagefald, som er svære at forklare. Før en audit-log over ændringen uden unødigt at forevige den slettede følsomme værdi i loggen.

Gennemtving udløb og sletning teknisk

Artikel 5 i GDPR fastslår dataminimering og opbevaringsbegrænsning. Omsæt disse principper til automatiske regler. Sessionstekst kan forsvinde efter kort tid, fortsættelsesstatus efter sagens afslutning og præferencer efter en længere, men defineret inaktivitet. „Ubegrænset, hvis det bliver nyttigt senere“ er ikke en holdbar frist.

En sletteanmodning kræver en gennemskuelig kæde. Primært datasæt, embedding, cache, analyseeksport og backup-regel skal tænkes med. Backups kan teknisk set have andre frister, men må ikke indlæse slettede data tilbage i den aktive tjeneste. Test sletning regelmæssigt med mærkede testdata.

Ingen skjult modeltræning fra chats

Produkthukommelse og modeltræning er adskilte formål. At en bruger lader en oplysning gemme til næste supportkontakt, betyder ikke automatisk samtykke til at forbedre en generel model. Hold trænings- eller evalueringsdatasæt organisatorisk og teknisk adskilt, og anonymiser kun, hvis anonymiseringen reelt er holdbar.

EDPB fremhæver i sin udtalelse om AI-modeller, at spørgsmålet om, hvorvidt en model er anonym, skal vurderes fra sag til sag. En simpel fjernelse af synlige navne er ikke automatisk nok. For mange website-teams er det derfor enklere og sikrere som standard ikke at behandle produktive chats som et træningskorpus.

Mål kvalitet og sikkerhed

En hukommelse kræver sine egne test. Test for forkert kortlægning mellem brugere og tenants, udløbne værdier, modstridende oplysninger, tilbagekaldelse, eksport og fuldstændig sletning. Mål ikke kun, hvor ofte hukommelsen bruges, men også hvor ofte brugere retter den eller finder den overraskende.

Et Golden Set kan indeholde scenarier som: to personer på samme enhed, rolleskift i en organisation, ændret leveringsadresse, sprogskift, slettet konto og en følsom oplysning, der aldrig må gemmes. Hvert release skal bevise, at isolation og udløb fortsat fungerer.

En pragmatisk implementeringsplan

1. Kortlæg lagringstyper og formål.
2. Definer oprindelse, gyldighed og frist for hver type.
3. Start med en ufarlig, eksplicit bekræftet præference.
4. Begræns hentning til tenant, identitet og aktuel intent.
5. Stil visning, rettelse, eksport og sletning til rådighed.
6. Inkluder afledte lagringer og cacher i slettekæden.
7. Test isolation, udløb og genoprettelse regelmæssigt.

Konklusion: En god hukommelse kan forklare, hvorfor den ved noget

En nyttig chatbot-hukommelse er lille, struktureret og kontrollerbar. Den adskiller kortvarig kontekst fra permanente egenskaber, gemmer kun egnede fakta og gør oprindelse samt udløb synlige. Brugere kan rette eller slette oplysninger uden at skulle oprette en supportsag.

Start ikke med spørgsmålet om, hvilke data der teknisk kan gemmes. Start med en enkelt oplysning, hvor den fremtidige nytte er klar – og design samtidig vejen til, hvordan den bekræftes, berigtiges og glemmes fuldstændigt.

Kilder

• EUR-Lex: Generel forordning om databeskyttelse, særligt artikel 5
• EDPB: Udtalelse 28/2024 om AI-modeller og personoplysninger
• EDPB: Fundamentals of Secure AI Systems with Personal Data
• NIST Privacy Framework