DI čatbota analītikas izveide, ievērojot datu minimizēšanu: notikumi, izlase un glabāšana

DI čatbota analītikai ir jāparāda, vai apmeklētāji saņem piemērotas atbildes, kad sarunas neizdodas un kurā brīdī darbs būtu jānodod cilvēku komandai. Tomēr uzņēmumiem nav automātiski pilnībā jāsaglabā katra saruna. Bieži vien pietiek ar skaidri definētiem notikumiem, apkopotiem rādītājiem un mazu, kontrolētu izlasi redakcionālai kvalitātes pārbaudei.

Datu minimizēšanā balstīta mērījumu koncepcija tāpēc nesākas ar pēc iespējas lielāku datu krātuvi, bet gan ar konkrētiem lēmumiem: kurš rādītājs atbild uz kuru jautājumu? Kura informācija tam patiešām ir nepieciešama? Kurš drīkst to redzēt, un kad tā tiks dzēsta? Šajā rokasgrāmatā ir aprakstīta praktiski pielietojama struktūra tīmekļa vietņu, atbalsta un produktu komandām. Tā neaizstāj individuālas juridiskās konsultācijas.

Sākt ar lēmumiem, nevis ar jēllogiem

Daudzi analītikas projekti vispirms apkopo visu un tikai vēlāk apsver, kura analīze ir lietderīga. Čatbotu gadījumā šāda pieeja ir īpaši riskanta: brīvais teksts var saturēt vārdus, e-pasta adreses, pasūtījumu numurus, veselības datus vai citu informāciju, ko apmeklētājs ievada brīvprātīgi vai nejauši. Pat ja ievades laukā tas netiek prasīts, šādi dati var parādīties sarunā.

Tāpēc vispirms definējiet biznesa jautājumus. Vai vēlaties uzzināt, vai bots atrisināja lietotāja problēmu? Tad jums ir nepieciešams rezultāta notikums un saprotama „atrisināts” definīcija. Ja nepieciešams pārbaudīt maršrutēšanas kvalitāti, bieži vien pietiek ar atpazīto nodoma (intent) klasi, mērķa maršrutu un faktisko iznākumu. Rakstā KI-Chatbot-Routing testen ir parādīts, kā šādus rezultātus var pārbaudīt attiecībā pret paredzētajiem ceļiem.

Vispārīgās datu aizsardzības regulas (VDAR) 5. pantā cita starpā ir minēta nolūka ierobežošana, datu minimizēšana un glabāšanas ierobežošana. Analītikas kontekstā tas nenozīmē, ka datus vispār nedrīkst apstrādāt. Tas nozīmē, ka mērķim, apjomam un ilgumam jābūt pamatotam un ierobežotam līdz nepieciešamajam apjomam. Juridiskais pamats, informēšanas pienākumi un, ja nepieciešams, piekrišana ir jāizvērtē konkrētajam lietojumam.

Izstrādāt vienkāršu un efektīvu notikumu taksonomiju

Notikumu taksonomija nosaka, par kādām stāvokļa izmaiņām čatbots ziņo. Labi notikumi (events) raksturo rezultātus, nevis visu dialogu. Tiem jābūt pietiekami stabiliem salīdzinājumam laikā un vienlaikus viegli saprotamiem. Sāciet ar dažiem pamata notikumiem un papildiniet tos tikai tad, ja no tā ir atkarīgs reāls lēmums.

Iespējamais pamata komplekts ietver:

• conversation_started sāktam dialogam bez ziņojuma teksta,
• answer_delivered ar aptuvenu tēmas klasi un valodas kodu,
• source_opened klikšķim uz nodrošinātā avota,
• fallback_triggered ar kontrolētu kļūdas kategoriju,
• handoff_offered un handoff_accepted nodošanai cilvēkam,
• feedback_submitted ar ierobežotu novērtēšanas skalu.

Katram notikumam ir pievienoti tikai tie atribūti, kas nepieciešami analīzei: laika logs, valodas un reģiona iestatījums (locale), tēmas kategorija, rezultāta statuss, bota versija vai zināšanu stāvoklis. Brīvais teksts, pilnas IP adreses, piekļuves žetoni (access tokens), sesiju sīkdatnes un tiešie kontakta dati pēc noklusējuma neietilpst analītikas notikumā. OWASP lietojumprogrammu žurnāliem (logs) tāpat iesaka noņemt, maskēt vai citādi aizsargāt sesiju identifikatorus, žetonus, jutīgus personas datus un noslēpumus.

Apstrādāt notikumu datus un sarunu saturu atsevišķi

Apkopotajiem notikumiem un pilniem sarunu ierakstiem ir dažādi mērķi. Notikumi ir piemēroti tendencēm, piltuvēm (funnels) un salīdzinājumiem. Sarunu saturs var palīdzēt redakcionālajā kļūdu analīzē, taču tas satur daudz vairāk konteksta un tādējādi arī vairāk potenciālo personas datu. Abiem datu veidiem nevajadzētu automātiski piemērot vienādas piekļuves tiesības, glabāšanas termiņus vai eksportēšanas iespējas.

Praktiski pielietojama arhitektūra darbojas trīs līmeņos:

1. Rādītāji: apkopotas vērtības, piemēram, atrisināšanas līmenis, atkāpšanās (fallback) īpatsvars vai nodošanas (handoff) pieņemšana.
2. Notikumi: pseidonimizētas datu kopas ar ierobežotiem atribūtiem laika un tehniskajām analīzēm.
3. Kvalitātes izlases: atlasītas sarunas kontrolētai pārbaudei, vēlams ar tiešo identifikatoru automātisku un manuālu rediģēšanu (maskēšanu).

Šī nošķiršana atvieglo dažādu dzēšanas termiņu un lomu pārvaldību. Piemēram, mārketinga panelim (dashboard) nav jāpiekļūst sarunu saturam, ja tas izvērtē tikai apkopoto mērķu sasniegšanu. Kā profesionāli definēt rādītājus, ir aprakstīts rokasgrāmatā KI-Chatbot-KPIs.

Pseidonimizācija nav anonimizācija

Nejauši ģenerēts sarunas ID var palīdzēt novērst tiešo identifikatoru parādīšanos analīzē. Tomēr tas automātiski nepadara datus par anonīmiem. Eiropas Datu aizsardzības kolēģija uzsver, ka pseidonimizēti dati joprojām ir personas dati, ja tos ar papildu informāciju var atkal sasaistīt ar konkrētu personu. Tāpēc iespēja sasaistīt datus un atslēgas atsevišķa glabāšana ir būtiski aspekti.

Izmantojiet stabilus identifikatorus tikai tad, ja analīzes mērķis to patiešām prasa. Kasdienai atkāpšanās (fallback) īpatsvara noteikšanai parasti nav nepieciešams lietotāja ID, kas ir atpazīstams vairākas nedēļas. Ja ir nepieciešami saistīti tehniskie notikumi, var pietikt ar īslaicīgu, nejaušu sarunas identifikatoru. Glabājiet sasaistes tabulas atsevišķi, ierobežojiet piekļuvi un dokumentējiet, kad identifikators tiek rotēts vai dzēsts.

NIST Privātuma satvars (Privacy Framework) apraksta "nošķirto apstrādi" (disassociated processing) kā pieeju, lai ierobežotu novērojamību, sasaistāmību un identifikāciju. Praktiski tas var nozīmēt atribūtu aizstāšanu ar kategorijām, lokālas priekšapstrādes izmantošanu vai tikai jau apkopotu vērtību nosūtīšanu uz centrālo sistēmu.

Kvalitātes pārbaude, izmantojot kontrolētu izlasi

Kvalitatīvajai pārbaudei ne katra saruna ir vienlīdz svarīga. Nejaušā izlase sniedz neitrālāku skatu uz ikdienu, savukārt uz risku balstīta izlase mērķtiecīgi aptver kļūdu gadījumus. Kombinējiet abas pieejas, nevis lasiet tikai īpaši sliktas vai īpaši garas sarunas.

Pārskatāms pārbaudes plāns katram laika periodam var ietvert šādas grupas:

• mazu nejaušo izlasi no atbildēm, kas šķiet veiksmīgas,
• atkāpšanās (fallback) gadījumus un neatbildētus jautājumus,
• piedāvātās un pieņemtās nodošanas cilvēkam (human handoffs),
• atbildes par jutīgām vai biznesam kritiskām tēmām,
• ievērojamas atšķirības starp valodu iestatījumiem (locales), ierīcēm vai zināšanu līmeņiem.

Pirms piekļuves piešķiršanas definējiet, kuras lomas drīkst redzēt sarunas, kuri lauki tiek maskēti un kā pārbaudītāji dokumentē novirzes. Brīvie komentāri pārbaudes rīkos paši var saturēt personas datus; arī tam ir nepieciešamas skaidras vadlīnijas. Pārbaudei vajadzētu novest pie konkrētas rīcības, piemēram, labota avota, jauna testa jautājuma vai pielāgota handoff noteikuma.

Glabāšanas plānošana pēc datu līmeņiem

Vienots dzēšanas termiņš visiem analītikas datiem ir ērts, bet reti precīzs. Nosakiet termiņus katram datu līmenim un mērķim. Jēlsaturu īstermiņa kļūdu analīzei var dzēst daudz ātrāk nekā ikmēneša nepersoniskos apkopojumus. Savukārt ar drošību saistītiem žurnāliem var piemērot citu prasību nekā produkta analītikai.

Katrai datu kopai dokumentējiet:

• mērķi un atbildīgo lomu,
• ietvertos laukus un iespējamos identifikatorus,
• glabāšanas vietu un pilnvarotos saņēmējus,
• termiņu, termiņa sākumpunktu un dzēšanas mehānismu,
• rezerves kopiju (backups), eksportu un atvasināto kopiju apstrādi.

OWASP norāda, ka žurnālu dati nav jāiznīcina pirms nepieciešamā laika posma, kā arī nav jāglabā ilgāk par to. Konkrētais ilgums ir atkarīgs no juridiskajām, līgumiskajām, drošības un darbības prasībām. Tāpēc dzēšanas koncepcija ir tehniski jāpārbauda: vai datu kopas patiešām tiek dzēstas, vai tās pazūd no meklēšanas indeksiem un vai tiek ņemti vērā arī pagaidu eksporti?

Piekļuves, eksporta un kļūdu gadījumu aizsardzība

Datu minimizēšana vien neaizsargā analītikas sistēmu. Lomām vajadzētu redzēt tikai tos līmeņus, kas nepieciešami to uzdevumu veikšanai. Produkta komandām bieži vien ir nepieciešamas apkopotas tendences, kvalitātes komandām — atlasītas rediģētas sarunas, bet administratoriem — tehniskie kļūdu dati. Piekļuve jēldatiem ir jāreģistrē žurnālā, regulāri jāpārbauda un jāatsauc, mainoties lomām.

Apstrādājiet analītikas atribūtus kā neuzticamus ievaddatus. Noņemiet vadības rakstzīmes, ierobežojiet lauku garumu un novērsiet to, ka manipulēti teksti kropļo žurnālu formātus vai analīzi. Eksportēšanas funkcijām ir nepieciešamas tādas pašas piekļuves kontroles kā lietotāja saskarnei. CSV vai tabulu eksporti nedrīkst saturēt papildu laukus tikai tāpēc, ka tie ir tehniski pieejami.

Pārbaudiet arī žurnālfailu veidošanas atteici. Čatbotam nevajadzētu nekontrolēti ierakstīt jutīgus datus rezerves žurnālā, ja analītikas sistēma nav sasniedzama. Nosakiet, kuriem minimālajiem drošības notikumiem ir jāsaglabājas un kurus produkta mērījumus var īslaicīgi izlaist.

Valodu un reģionu (locale) salīdzināšana bez kļūdainiem secinājumiem

Daudzvalodu analītika ir noderīga, ja termini un saucēji paliek konsekventi. Nesalīdziniet tikai absolūtos gadījumu skaitļus. Lielāks hanofff nodošanas skaits var rasties no lielākas satiksmes (traffic), citiem pakalpojumu sniegšanas laikiem vai apzināti piesardzīgāka dialoga. Izmantojiet rādītājus ar skaidri definētu saucēju un dokumentējiet atšķirības maršrutēšanā, zināšanu bāzē un piedāvātajos kontaktu ceļos.

Saglabājiet valodas kodu (locale code) kā tehnisku atribūtu, nevis kā pieņēmumu par personas izcelsmi vai identitāti. Regulāri pārbaudiet, vai valodas ceļš un faktiskā atbildes valoda sakrīt. Informāciju par nodošanu cilvēkiem skatiet rakstā Human Handoff im KI-Chatbot.

Datu minimizēšanai atbilstošas čatbota analītikas kontrolsaraksts

• Katrs rādītājs ir saistīts ar konkrētu lēmumu un atbildīgo personu.
• Notikumi pēc noklusējuma nesatur ziņojuma tekstu un tiešos identifikatorus.
• Rādītāji, notikumi un kvalitātes izlases ir tehniski un organizatoriski nošķirtas.
• Pseidonimizētie identifikatori ir īslaicīgi vai pamatoti; atslēgas tiek aizsargātas atsevišķi.
• Izlasē tiek kombinēti nejauši gadījumi ar uz risku balstītām kļūdu grupām.
• Lomas, maskēšana un pārbaudes rezultāti ir saistoši definēti.
• Glabāšanas un dzēšanas termiņi attiecas arī uz eksportēšanu, rezerves kopijām un meklēšanas indeksiem.
• Valodu/reģionu salīdzinājumos tiek izmantotas konsekventas definīcijas un piemēroti saucēji.
• Regulāri tiek testēti atteices, manipulāciju un neatļautas eksportēšanas scenāriji.

Papildu informāciju par juridiskajiem pamatiem, informēšanas pienākumiem un apstrādātāja līgumiem atradīsiet rakstā KI-Chatbot und DSGVO. Lūdziet atbildīgajiem datu aizsardzības un juridiskajiem ekspertiem pārbaudīt konkrēto ieviešanu.

Avoti

• Eiropas Komisija: Vispārīgās datu aizsardzības regulas pamatprincipi
• Eiropas Datu aizsardzības kolēģija: Pseidonimizācijas vadlīnijas
• NIST Privacy Framework: Vadlīnijas un rīki
• OWASP Žurnālfailu izveides špikeris (Logging Cheat Sheet)

Plānojot čatbota analītiku, balstoties uz lēmumiem, minimāliem notikumiem un kontrolētām izlasēm, tiek iegūti noderīgi kvalitātes signāli bez nevajadzīgi liela jēldatu arhīva. ChatReact var tikt izmantots kā daļa no šāda procesa ar skaidriem avotiem, daudzvalodu dialogiem un definētiem nodošanas (handoff) ceļiem.