Analitika AI chatbotov z zmanjševanjem obsega podatkov: dogodki, vzorčenje in hramba

Analitika AI chatbotov naj bi pokazala, ali obiskovalci prejmejo ustrezne odgovore, kdaj pogovori spodletijo in na kateri točki bi morala prevzeti človeška ekipa. Vendar podjetjem za to ni treba samodejno shranjevati celotnih pogovorov. Pogosto zadoščajo jasno opredeljeni dogodki, agregirani kazalniki in majhen, nadzorovan vzorec za uredniško preverjanje kakovosti.

Zato se koncept merjenja z zmanjševanjem obsega podatkov ne začne s čim večjim podatkovnim skladiščem, temveč s konkretnimi odločitvami: Kateri kazalnik odgovarja na katero vprašanje? Katera informacija je za to resnično potrebna? Kdo jo sme videti in kdaj bo izbrisana? Ta vodnik opisuje praktično zasnovo za spletne, podporne in produktne ekipe. Ne nadomešča posamičnega pravnega svetovanja.

Začnite z odločitvami, ne s surovimi dnevniki

Mnogo projektov analitike najprej zbere vse podatke in šele pozneje razmišlja, katera analiza je smiselna. Pri chatbotih je takšen pristop še posebej tvegan: prosto besedilo lahko vsebuje imena, e-poštne naslove, številke naročil, zdravstvene podatke ali druge informacije, ki jih obiskovalec vnese prostovoljno ali pomotoma. Tudi če vnosno polje tega ne zahteva, se takšni podatki lahko pojavijo v pogovoru.

Zato najprej opredelite poslovna vprašanja. Želite vedeti, ali je bot rešil zadevo? Potem potrebujete dogodek o rezultatu in pregledno opredelitev pojma »rešeno«. Če želite preveriti kakovost usmerjanja (routinga), pogosto zadoščajo zaznani razred namere (intent class), ciljna pot in dejanski izid. Prispevek KI-Chatbot-Routing testen prikazuje, kako je mogoče takšne rezultate preveriti glede na pričakovane poti.

Splošna uredba o varstvu podatkov (GDPR) v 5. členu med drugim navaja omejitev namena, najmanjši obseg podatkov in omejitev hrambe. Za analitiko to ne pomeni, da obdelava podatkov sploh ni dovoljena. Pomeni pa, da morajo biti namen, obseg in trajanje utemeljeni ter omejeni na najnujnejšo mero. Pravno podlago, obveznosti obveščanja in po potrebi privolitev je treba preveriti za konkretno uporabo.

Oblikovanje vitke taksonomije dogodkov

Taksonomija dogodkov določa, katera spremembe stanja sporoča chatbot. Dobri dogodki opisujejo rezultate, ne celotnega dialoga. Biti morajo dovolj stabilni za primerjave skozi čas in hkrati ostati razumljivi. Začnite z nekaj ključnimi dogodki in jih dopolnjujte le, če je od tega odvisna resnična odločitev.

Možen osnovni nabor vključuje:

• conversation_started za začet dialog brez besedila sporočila,
• answer_delivered z okvirnim tematskim razredom in kodo jezika,
• source_opened za klik na zagotovljeni vir,
• fallback_triggered z nadzorovano kategorijo napake,
• handoff_offered in handoff_accepted za predajo,
• feedback_submitted z omejeno ocenjevalno skalo.

K vsakemu dogodku spadajo le atributi, ki so potrebni za analizo: časovno okno, lokalizacija (locale), tematska kategorija, status rezultata, različica bota ali stanje znanja. Prosto besedilo, celotni naslovi IP, dostopni žetoni, sejni piškotki in neposredni kontaktni podatki standardno ne spadajo v dogodek analitike. OWASP za dnevnike aplikacij prav tako priporoča odstranitev, prikritje ali drugačno zaščito sejnih identifikatorjev, žetonov, občutljivih osebnih podatkov in skrivnosti.

Ločeno obravnavanje podatkov o dogodkih in vsebine pogovorov

Agregirani dogodki in celotni poteki pogovorov imajo različne namene. Dogodki so primerni za trende, levake (funnele) in primerjave. Vsebine pogovorov lahko pomagajo pri uredniški analizi napak, vendar vsebujejo bistveno več konteksta in s tem več potencialno osebnih podatkov. Obe vrsti podatkov ne bi smeli imeti samodejno enakih pravic dostopa, rokov hrambe ali izvoza.

Praktična arhitektura deluje s tremi ravnmi:

1. Kazalniki: agregirane vrednosti, kot so stopnja rešitve, delež neodgovorjenih vprašanj (fallback) ali sprejem predaje (handoff).
2. Dogodki: psevdonimni podatkovni zapisi z omejenimi atributi za časovne in tehnične analize.
3. Vzorci kakovosti: izbrani pogovori za nadzorovan pregled, po možnosti s samodejnim in ročnim prikritjem neposrednih identifikatorjev.

Ta ločitev olajša določanje različnih rokov izbrisa in vlog. Nadzorna plošča za trženje na primer ne potrebuje dostopa do vsebine pogovorov, če ocenjuje le agregirano doseganje ciljev. Kako strokovno opredeliti kazalnike, opisuje vodnik KI-Chatbot-KPIs.

Psevdonimizacija ni anonimizacija

Naključni ID pogovora lahko neposredne identifikatorje odstrani iz analize. Vendar pa podatkov ne naredi samodejno anonimnih. Evropski odbor za varstvo podatkov (EDPB) pojasnjuje, da so psevdonimizirani podatki še naprej osebni podatki, če jih je mogoče z dodatnimi informacijami znova povezati z osebo. Možnost povezovanja in ločeno hranjenje ključa sta zato ključni točki.

Uporabite stabilne identifikatorje le, če to resnično zahteva namen analize. Za dnevni delež neodgovorjenih vprašanj večinoma ni potrebna uporabniška identifikacija, ki bi bila prepoznavna več tednov. Če so potrebni povezani tehnični dogodki, zadostuje kratkotrajna, naključna identifikacija pogovora. Hranite povezovalne tabele ločeno, omejite dostope in dokumentirajte, kdaj se identifikator zamenja ali izbriše.

Ogrodje za zasebnost NIST (Privacy Framework) opisuje »disassociated processing« (ločeno obdelavo) kot pristop za omejevanje opazovanja, povezovanja in identifikacije. V praksi to lahko pomeni zamenjavo atributov s kategorijami, uporabo lokalne predobdelave ali pošiljanje že agregiranih vrednosti v centralni sistem.

Preverjanje kakovosti z nadzorovanim vzorčenjem

Za kakovostno preverjanje vsak pogovor ni enako pomemben. Naključni vzorec daje nevtralnejši pogled na vsakdanje delovanje, medtem ko vzorec na podlagi tveganja ciljno zajame primere napak. Kombinirajte oba pristopa, namesto da berete le izjemno slabe ali izjemno dolge pogovore.

Smiseln načrt pregleda lahko za posamezno obdobje vključuje naslednje skupine:

• majhen naključni vzorec odgovorov, ki delujejo uspešno,
• neodgovorjena vprašanja in primere preusmeritev (fallbacks),
• ponujene in sprejete človeške predaje (human handoffs),
• odgovore na občutljive ali poslovno kritične teme,
• opazna odstopanja med lokalizacijami, napravami ali stanji znanja.

Pred dostopom opredelite, katere vloge smejo videti pogovore, katera polja se prikrijejo in kako ocenjevalci dokumentirajo odstopanja. Prosti komentarji v orodjih za pregled lahko sami po sebi vsebujejo osebne podatke; tudi za to so potrebne jasne smernice. Pregled bi moral voditi do konkretnega ukrepa, na primer popravljenega vira, novega testnega vprašanja ali prilagojenega pravila za predajo.

Načrtovanje hrambe glede na raven podatkov

Enoten rok izbrisa za vse podatke analitike je ugoden, vendar redko natančen. Določite roke glede na raven podatkov in namen. Surove vsebine za kratkoročno analizo napak se lahko izbrišejo bistveno prej kot mesečni, neosebni agregirani podatki. Za dnevnike, pomembne za varnost, pa lahko veljajo drugačne zahteve kot za produktno analitiko.

Za vsak nabor podatkov dokumentirajte:

• namen in odgovorno vlogo,
• vsebovana polja in možne identifikatorje,
• lokacijo shranjevanja in upravičene prejemnike,
• rok, začetek teka roka in mehanizem izbrisa,
• ravnanje z varnostnimi kopijami, izvozi in izpeljanimi kopijami.

OWASP opozarja, da podatkov v dnevnikih ne bi smeli uničiti pred iztekom zahtevanega obdobja in jih tudi ne hraniti dlje od njega. Konkretno trajanje je odvisno od pravnih, pogodbenih, varnostnih in poslovnih zahtev. Zato je treba koncept izbrisa tehnično preizkusiti: Ali so podatkovni zapisi resnično odstranjeni, ali izginejo iz iskalnih indeksov in ali so upoštevani tudi začasni izvozi?

Zaščita dostopov, izvozov in izrednih dogodkov

Samo zmanjševanje obsega podatkov ne ščiti sistema analitike. Vloge bi morale videti le ravni, ki jih potrebujejo za svoje naloge. Produktne ekipe pogosto potrebujejo agregirane trende, ekipa za kakovost izbrane uredniško obdelane pogovore, skrbniki pa tehnične podatke o napakah. Dostopi do surovih podatkov morajo biti zabeleženi v dnevnikih, redno preverjani in ob spremembi vloge odvzeti.

Atribute analitike obravnavajte kot nezanesljive vnose. Odstranite krmilne znake, omejite dolžine polj in preprečite, da bi prirejeno besedilo popačilo mehanizme dnevnika ali analize. Funkcije izvoza potrebujejo enake kontrole dostopa kot uporabniški vmesnik. Izvozi v datoteke CSV ali preglednice ne smejo vsebovati dodatnih polj le zato, ker so tehnično na voljo.

Poleg tega preizkusite izpad beleženja. Chatbot ne bi smel nenadzorovan zapisovati občutljivih podatkov v nadomestni dnevnik, če sistem analitike ni dosegljiv. Določite, kateri minimalni varnostni dogodki morajo ostati ohranjeni in katero merjenje delovanja lahko začasno izpade.

Primerjave lokalizacij brez napačnih sklepov

Večjezična analitika je koristna, če pojmi in imenovalci ostanejo dosledni. Ne primerjajte le absolutnih številk primerov. Večja številka predaj (handoffov) lahko nastane zaradi večjega obiska, drugačnega delovnega časa ali zavestno previdnejšega poteka pogovora. Uporabite stopnje z jasno opredeljenim imenovalcem ter dokumentirajte razlike v usmerjanju, bazi znanja in ponujenih kontaktnih poteh.

Kodo lokalizacije (locale code) shranite kot tehnični atribut, ne kot predvidevanje o poreklu ali identiteti osebe. Redno preverjajte, ali se jezikovna pot in dejanski jezik odgovora ujemata. Za predajo človeku si preberite prispevek Human Handoff im KI-Chatbot.

Kontrolni seznam za analitiko chatbotov z zmanjševanjem obsega podatkov

• Vsak kazalnik je povezan s konkretno odločitvijo in odgovorno osebo.
• Dogodki standardno ne vsebujejo besedila sporočil in neposrednih identifikatorjev.
• Kazalniki, dogodki in vzorci kakovosti so tehnično in organizacijsko ločeni.
• Psevdonimni identifikatorji so kratkotrajni ali utemeljeni; ključi so zaščiteni ločeno.
• Vzorčenje združuje naključne primere s skupinami napak na podlagi tveganja.
• Vloge, prikritje in rezultati pregleda so obvezujoče opredeljeni.
• Roki hrambe in izbrisa veljajo tudi za izvoze, varnostne kopije in iskalne indekse.
• Primerjave lokalizacij uporabljajo dosledne definicije in ustrezne imenovalce.
• Izpad, manipulacija in nepooblaščen izvoz se redno preizkušajo.

Podrobnejšo umestitev glede pravnih podlag, obveznosti obveščanja in pogodbene obdelave podatkov ponuja prispevek KI-Chatbot und DSGVO. Konkretno izvedbo naj preverijo pristojni strokovnjaki za varstvo podatkov in pravni strokovnjaki.

Viri

• Evropska komisija: Načela Splošne uredbe o varstvu podatkov
• Evropski odbor za varstvo podatkov: Smernice o psevdonimizaciji
• NIST Privacy Framework: Guidelines and Tools
• OWASP Logging Cheat Sheet

Tisti, ki analitiko chatbota načrtuje na podlagi odločitev, minimalnih dogodkov in nadzorovanih vzorcev, pridobi uporabne signale kakovosti brez nepotrebno velikega arhiva surovih podatkov. ChatReact se lahko uporablja kot del takšnega procesa z jasnimi viri, večjezičnimi pogovori in opredeljenimi potmi predaje (handoff).