Vymazanie a export histórie chatbota: Bezpečná kontrola zo strany používateľa

História chatbota je pre používateľov praktická: môžu si spätne prečítať odpovede, pokracovať v konverzácii neskôr alebo odovzdať informácie zákazníckej podpore. Rovnaká história však môže obsahovať čísla objednávok, popisy problémov, kontaktné údaje alebo iné citlivé informácie. Každý, kto ukladá konverzácie, preto potrebuje viac než len nenápadný prepínač „História“. Používatelia by mali rozumieť tomu, aké údaje sú k dispozícii, ako si ich môžu vziať so sebou, vymazať ich alebo odvolať ďalší prístup.

Tento sprievodca zobrazuje realizovateľný produktový a technický model pre webových chatbotov. Spája používateľskú prívetivosť, minimalizáciu údajov, bezpečnú overenie identity a sledovateľné stavy systému. Tieto pokyny nepredstavujú individuálne právne poradenstvo; konkrétne povinnosti závisia okrem iného od účelu, právneho základu, architektúry systému a dotknutých údajov.

Štyri funkcie namiesto jediného prepínača histórie

„Spravovať históriu“ je príliš nepresné. V rozhraní a na backende by sa mali oddeliť štyri rôzne zámery:

• Zobrazenie: Používatelia si čítajú uložené konverzácie, prílohy a rozpoznateľné metadáta v zrozumiteľnej chronológii.
• Export: Získajú kópiu v čitateľnom formáte a, ak je to pre daný prípad použitia zmysluplné alebo právne vyžadované, dodatočne aj v štruktúrovanom strojovo čitateľnom formáte.
• Vymazanie: Odstránia jednotlivé konverzácie alebo celú priradenú históriu. Rozhranie vysvetľuje rozsah, lehoty a možné výnimky.
• Odvolanie prístupu: Zneplatnia odkazy na zdieľanie, známe zariadenia alebo tokeny na pokračovanie bez toho, aby museli okamžite vymazať všetky obsahové údaje.

Toto oddelenie zabraňuje nebezpečným nedorozumeniam. „Odhlásiť sa“ nevymaže údaje o konverzácii. „Skryť históriu“ nie je vymazanie. A expirovaný odkaz automaticamente neznamená, že zodpovedajúce dátové záznamy zmizli. Doplnkovo si môžete prečítať nášho sprievodcu pre bezpečné pokračovanie v konverzáciách s chatbotom.

Začnite s jasným dátovým modelom

Kým tímy začnú navrhovať tlačidlá, mali by vykonať inventúru uložených objektov. Konverzácia často pozostáva nie len zo správ. Pridávajú sa identifikátory relácie, časové pečiatky, odkazové súbory, bezpečnostné udalosti, tikety podpory, spätná väzba a technické protokoly. Pre každý objekt je potrebný zdokumentovaný účel, zodpovedná osoba, pravidlo uchovávania a cesta na vymazanie.

Všeobecné nariadenie o ochrane údajov uváca v článku 5 okrem iného minimalizáciu údajov a obmedzenie uchovávania. Článok 15 sa týka práva na prístup, článok 17 práva na vymazanie s podmienkami a výnimkami, článok 20 prenosnosti údajov v ich príslušnom rozsahu pôsobnosti. Z toho nevyplýva, že každé rozhranie chatbota musí ponúkať identické funkcie. Produktové tímy by však mali dátové toky stavat tak, aby bolo možné oprávnené žiadosti spoľahlivo spracovať.

Primerane overte identitu pred exportom a vymazaním

Kto sprístupní históriu len cez odhadnuteľný odkaz alebo opakovane použitý identifikátor relácie, riskuje únik údajov. Zároveň overenie identity nesmie paušálne vyžadovať viac osobných údajov, než je potrebné pre konkrétnu akciu. Finálne usmernenia EDPB 01/2022 o práve na prístup riešia okrem iného identifikáciu, rozsah a bezpečné poskytovanie kópií. Článok 12 odsek 6 GDPR umožňuje dodatočné informácie na potvrdenie identity, ak existujú dôvodné pochybnosti o identite.

V praxi sa osvedčilo odstupňovanie založené na riziku. Zobrazenie pseudonymnej krátkej histórie na rovnakom zariadení môže vyžadovať platnú, krátkodobú reláciu. Celkový export, ireverzibilné vymazanie alebo odvolanie prístupu zo všetkých zariadení skôr odôvodňuje opätovnú autentifikáciu. Aktuálne usmernenie NIST k správe relácií opisuje reautentifikáciu, časové limity a ukončenie relácie ako samostatné kontrolné mechanizmy. Konkrétna sila musí zodpovedať riziku; požiadavky NIST pre federálne úrady USA pritom nie sú paušálnou právnou požiadavkou pre každú spoločnosť.

Pre verejné widgety a prihlásené klientske zóny by hranica mala zostať viditeľná. Náš článok o identite a prístupe k údajom v klientskom portáli ukazuje, prečo by sa verejný čet nemal ticho zmeniť na dátový kanál účtu.

Export musí byť zrozumiteľný a úplne vysvetliteľný

Dobrý export nie je surový výpis z databázy. Začína prehľadom: obdobie vytvorenia, obsiahnuté konverzácie, prílohy, použitá časová zóna a verzia formátu. Nasleduje obsah v jasnom poradí. JSON môže byť zmysluplný pre štruktúrované ďalšie spracovanie; HTML alebo PDF je pre mnohých ľudí ľahšie čitateľné. Či a v akom rozsahu je prenosný formát právne vyžadovaný, by sa malo posúdiť pre konkrétny prípad.

Ak systém generuje export asynchrónne, rozhranie potrebuje jednoznačný stav: „pripravuje sa“, „pripravené do…“, „expirované“ alebo „zlyhalo“. Odkaz na stiahnutie by mal byť krátkodobý, neodhadnuteľný a po použití odvolateľný. Tajomstvá ako interné prompt-y, prístupové kľúče alebo údaje iných osôb do balíka nepatria. Pred poskytnutím by mal serverový filter skontrolovať, či vzťahy k prípadom podpory, zdieľaným konverzáciám alebo obsahu tretích strán nevyžadujú osobitné zaobchádzanie.

Vymazanie ako stavový stroj namiesto okamžitého sľubu

Tlačidlo s hláškou „Všetko vymazané“ je problematické, ak vyhľadávací index, analytické úložisko, systém podpory alebo záloha naďalej obsahujú kópie. Lepší je malý stavový stroj, ktorý zobrazuje skutočný proces.

Zmysluplné stavy vymazania

1. Vyžiadané: Identita a požadovaný rozsah sú confirmed.
2. Blokované: História už nie je dostupná pre bežné používanie; tokeny na pokračovanie a zdieľanie sú neplatné.
3. V spracovaní: Primárne úložisko, vyhľadávací index, súborové úložisko, analytické a integračné cieľové objekty sa spracovávajú.
4. Dokončené: Určené aktívne systémy sú vyčistené; zostávajúce záložné kópie podliehajú zdokumentovanej rotácii záloh alebo odôvodnenej výnimke.
5. Čiastočne blokované: Jedno zo systémov sa nepodarilo vyčistiť alebo údaje musia zatiaľ zostať zachované. Prípad sa sledovateľne eskaluje.

Nezabúdajte na závislé údaje

Správy môžu odkazovať na súbory, embeddingy, vyhľadávacie indexy, hodnotenia kvality, záznamy v CRM alebo tikety podpory. Žiadosť o vymazanie preto potrebuje stabilné ID žiadosti a idempotentné pracovné kroky: Opätovné spustenie nesmie vytvoriť nové kópie ani vrátiť už dokončené kroky. Pre namerané údaje by sa malo už pri návrhu rozhodnúť, či sa môžu zachovať agregované, už nepriraditeľné ukazovatele. Viac sa o tom dočítate v článku o analytike chatbotov šetrnej k údajom.

Odvolanie prístupu chráni najmä na zdieľaných zariadeniach

V hoteloch, predajných priestoroch, dielňach alebo rodinných domácnostiach sa ľudia na rovnakom zariadení striedajú častejšie. Preto by „Odvolať prístup“ malo dokázať viac ako len lokálne vymazať cookie. Na strane servera musia známe tokeny relácií, odkazy na zdieľanie a prípadne väzby na zariadenia zneplatnieť. Rozhranie by malo rozlišovať medzi „toto zariadenie“, „všetky zariadenia“ a „všetky zdieľané odkazy“.

Po odvolaní prístupu nesmie tlačidlo „Späť“ zobraziť citlivú históriu z vyrovnávacej pamäte. Náhľady v oznámeniach, automatické dopĺňanie v prehliadači a lokálne offline údaje patria do kontroly. Zároveň by mal používateľ dostať jasné potvrdenie, ktoré prístupy boli ukončené a či sú údaje o konverzácii naďalej uložené. Tým sa zabráni zamieňaniu odvolania prístupu s vymazaním.

Navrhnite potvrdenie o vymazaní prístupne a tolerantne voči chybám

Návratný krok vyžaduje pokojné a zrozumiteľné potvrdenie. Vysvetlenie WCAG 2.2 k kritériu úspešnosti 3.3.4 sa výslovne vzťahuje aj na zmenu alebo vymazanie údajov kontrolovaných používateľom. Predpokladá sa minimálne jedna možnosť vrácania zmien, kontroly alebo potvrdenia. Ktorá verzia vyhovuje, závisí od produktu.

Dobré dialógy uvádzajú konkrétne „3 konverzácie a 2 prílohy“ namiesto len „údaje“. Primárna a deštruktívna akcia sú vizuálne rozlíšiteľné, dostupné pomocou klávesnice a nevysvetlené len samotnou farbou. Po odoslaní prístupná stavová oblasť hlási, že žiadosť bola prijatá. Kôš s obmedzenou lehotou na obnovenie môže zachytiť chyby pri obsluhe, ale nesmie tajne odporovať prísľubu okamžitého vymazania.

Odovzdanie podpore bez tieňovej kópie

Ak sa konverzácia odovzdá ľuďom, často vznikne samostatný tiket podpory. Tento objekt má možný iný účel, iné prístupové roly a iné pravidlo uchovávania. Nastavenie histórie v chatbotovi nesmie takýto tiket ani neviditeľne vymazať, ani ticho ignorovať. Pred odovzdaním by malo rozhranie vysvetliť, ktoré obsahy budú prevzaté. Pri neskoršej žiadosti musí systém nájsť prepojenie a spracovať prípad podľa platných pravidiel.

Ak automatické vymazanie zlyhá alebo ak sú identita a rozsah nejasné, proces potrebuje bezpečný ľudský kanál. Článok o ľudskom odovzdaní (Human Handoff) v podpore na webe opisuje kontextové balíky a pravidlá eskalácie. Odovzdať by sa malo len to, čo príslušný pracovník skutočne potrebuje.

Implementačný kontrolný zoznam pre produktové tímy a tímy podpory

1. Spravte inventúru všetkých dátových objektov a miest uloženia konverzácie.
2. Modelujte zobrazenie, export, vymazanie a odvolanie ako samostatné oprávnenia.
3. Pre citlivé akcie sa znova autentifikujte na základe rizika.
4. Strukturujte exportné balíky zrozumiteľne a nastavte bezpečné časy expirácie.
5. Urobte kroky vymazania idempotentné a sledujte ich pomocou ID žiadosti.
6. Zahrňte vyhľadávací index, súbory, analytiku, integrácie, vyrovnávacie pamäte a prípady podpory.
7. Otestujte potvrdzovacie dialógy a stavové hlásenia pomocou klávesnice a čítačky obrazovky.
8. Simulujte zdieľané zariadenia, expirované odkazy a stratené zariadenia.
9. Viditeľne eskalujte čiastočné chyby bez kopírovania citlivého obsahu do logov.
10. Pravidelne kontrolujte pravidlá uchovávania a vymazania s oddelením ochrany údajov a odbornými útvarmi.

Najdôležitejšie testy pred spustením do prevádzky

Testovacie prípady by nemali pokrývať len ideálnu cestu. Skontrolujte paralelné žiadosti o vymazanie, prihlásenie expirované počas exportu, už odvolané odkazy, nové správy počas prebiehajúceho vymazávania a výpadok prepojeného systému. Okrem toho skontrolujte, či export neobsahuje cudzie správy zo zdieľaných účtov a či je vymazaný súbor stále dostupný cez starú URL adresu.

Pre každú akciu je potrebný očakávaný výsledok v rozhraní, API a úložisku. Dobrý akceptačný test sa preto nekončí zeleným hlásením o úspechu. Následne preverí rozhodujúce dátové úložiská, tokeny a verejné URL adresy. Protokoly udalostí by mali dokazovať, že krok bol vykonaný, bez opätovného uloženia vymazaného obsahu konverzácie.

Záver: Kontrola používateľom je vlastnosť typu end-to-end

Dôveryhodný chatbot nerobí históriu len vyhľadateľnou. Oddeľuje zobrazenie, export, vymazanie a odvolanie prístupu, primerane preveruje citlivé akcie a zobrazuje skutočný stav spracovania. Rozhodujúce je spojenie jasného UX s dátovým modelom, ktorý pozná všetky závislé systémy.

Kto integrovať tieto funkcie včas do architektúry, procesov podpory a testov, znižuje manuálne výnimočné prípady a vyhýba sa falošným sľubom. Pri plánovaní skontrolujte aj to, ktoré funkcie ChatReact vyhovujú vašej webovej stránke a procesu podpory. Začnite s inventúrou údajov a jediným end-to-end testom: exportovať históriu, odvolať prístupy, spustiť vymazanie a preukázať výsledok vo všetkých zúčastnených systémoch.

Zdroje a ďalšie upozornenia

• EUR-Lex: Nariadenie (EÚ) 2016/679, najmä články 5, 12, 15, 17 a 20.
• EDPB: Usmernenia 01/2022 o právach dotknutých osôb – Právo na prístup, Verzia 2.1.
• NIST SP 800-63B: Správa relácií.
• W3C: Porozumenie kritériu úspešnosti WCAG 2.2 3.3.4.