Smazání a export historie chatbota: Bezpečná kontrola v rukou uživatele

Historie chatbota je pro uživatele praktická: mohou si zpětně přečíst odpovědi, pokračovat v konverzaci později nebo předat informace podpoře. Tatáž historie však může obsahovat čísla objednávek, popisy problémů, kontaktní údaje nebo jiné citlivé informace. Každý, kdo ukládá konverzace, proto potřebuje víc než jen nenápadné tlačítko „Historie“. Uživatelé by měli mít jasno v tom, jaká data existují, jak si je mohou odnést, smazat nebo jak odvolat další přístup k nim.

Tento průvodce představuje realizovatelný produktový a technický model pro webové chatboty. Propojuje uživatelskou přívětivost, minimalizaci dat, bezpečné ověření identity a srozumitelné stavy systému. Uvedená doporučení nepředstavují individuální právní poradenství; konkrétní povinnosti závisí mimo jiné na účelu, právním základu, architektuře systému a dotčených datech.

Čtyři funkce namísto jediného tlačítka historie

Pojem „Spravovat historii“ je příliš nejasný. V uživatelském rozhraní i na backendu by měly být odděleny čtyři různé záměry:

• Zobrazit: Uživatelé si čtou uložené konverzace, přílohy a rozpoznatelná metadata v přehledné chronologii.
• Exportovat: Obdrží kopii ve čtivém formátu a – pokud je to pro daný případ použití smysluplné nebo právně vyžadované – navíc v strukturovaném strojem čitelném formátu.
• Smazat: Odstraní jednotlivé konverzace nebo celou přiřazenou historii. Rozhraní vysvětluje rozsah, lhůty a možné výjimky.
• Odvolat přístup: Zneplatní odkazy pro sdílení, známá zařízení nebo tokeny pro obnovení relace, aniž by museli okamžitě mazat veškerá obsahová data.

Toto oddělení předchází nebezpečným nedorozuměním. „Odhlásit se“ nesmaže data konverzací. „Skrýt historii“ neznamená smazání. A vypršený odkaz automaticky neznamená, že odpovídající datové záznamy zmizely. Doporučujeme také náš návod pro bezpečné pokračování v konverzaci s chatbotem.

Začněte s jasným datovým modelem

Než týmy navrhnou tlačítka, měly by provést inventuru uložených objektů. Konverzace se často neskládá jen ze zpráv. Přidávají se identifikátory relací, časová razítka, odkazy na soubory, bezpečnostní události, tikety podpory, zpětná vazba a technické protokoly. Pro každý objekt je potřeba zdokumentovaný účel, odpovědná osoba, pravidlo uchovávání a cesta ke smazání.

Obecné nařízení o ochraně osobních údajů (GDPR) zmiňuje v článku 5 mimo jiné minimalizaci údajů a omezení uložení. Článek 15 se týká práva na přístup, článek 17 práva na výmaz s podmínkami a výjimkami, článek 20 práva na přenositelnost údajů v příslušném rozsahu působnosti. Z toho nevyplývá, že každé rozhraní chatbota musí nabízet identické funkce. Produktové týmy by však měly datové toky navrhnout tak, aby bylo možné oprávněné žádosti spolehlivě zpracovat.

Před exportem a smazáním přiměřeně ověřte identitu

Kdo zpřístupní historii pouze přes uhodnutelný odkaz nebo opakovaně použitý identifikátor relace, riskuje únik dat. Ověření identity však zároveň nesmí paušálně vyžadovat více osobních údajů, než je pro konkrétní akci nutné. Finální pokyny EDPB 01/2022 k právu na přístup řeší mimo jiné identifikaci, rozsah a bezpečné poskytování kopií. Článek 12 odst. 6 GDPR umožňuje vyžádat si dodatečné informace k potvrzení identity, pokud existují důvodné pochybnosti o totožnosti.

V praxi se osvědčilo odstupňování podle míry rizika. Zobrazení pseudonymní krátké historie na stejném zařízení může vyžadovat pouze platnou relaci s krátkou životností. Celkový export, ireverzibilní smazání nebo odvolání přístupu ze všech zařízení naopak odůvodňuje opětovné autentizování. Aktuální doporučení NIST pro správu relací popisují reautentizaci, časové limity a ukončování relací jako samostatné prvky kontroly. Konkrétní síla zabezpečení musí odpovídat riziku; požadavky NIST pro americké federální úřady přitom nejsou paušálním právním předpisem pro každou firmu.

Pro veřejné widgety a přihlášené klientské sekce by hranice měla zůstat jasně viditelná. Náš článek o identitě a přístupu k datům v klientském portálu vysvětluje, proč by se veřejný chat neměl tichým způsobem měnit v kanál pro přístup k údajům z účtu.

Export musí být srozumitelný a plně vysvětlitelný

Dobrý export není jen syrový výpis z databáze. Začíná přehledem: období vytvoření, obsažené konverzace, přílohy, použité časové pásmo a verze formátu. Následuje samotný obsah v jasném pořadí. JSON může mít smysl pro strukturované další zpracování; HTML nebo PDF je pro většinu lidí snáze čitelné. Zda a v jakém rozsahu je přenosný formát právně vyžadován, by mělo být posouzeno pro konkrétní případ.

Pokud systém generuje export asynchronně, potřebuje uživatelské rozhraní jednoznačný stav: „připravuje se“, „připraveno do…“, „vypršelo“ nebo „selhalo“. Odkaz ke stažení by měl mít krátkou platnost, být neuhodnutelný a po použití odvolatelný. Tajné informace jako interní prompty, přístupové klíče nebo data jiných osob do balíčku nepatří. Před poskytnutím by mal serverový filtr prověřit, zda propojení na případy podpory, sdílené konverzace nebo obsah třetích stran nevyžadují zvláštní zacházení.

Smazání jako stavový stroj namísto okamžitého příslibu

Tlačítko s hlášením „Vše smazáno“ je problematické, pokud vyhledávací index, analytické úložiště, systém podpory nebo zálohy stále obsahují kopie. Lepší je drobný stavový stroj, který zachycuje skutečný průběh procesu.

Smysluplné stavy mazání

1. Vyžádáno: Identita a požadovaný rozsah jsou potvrzeny.
2. Blokováno: Historie již není přístupná pro běžné použití; tokeny pro obnovení a sdílení jsou neplatné.
3. Zpracovává se: Probíhá vyčištění primárního úložiště, vyhledávacího indexu, datového úložiště, analytických a integračních cílů.
4. Dokončeno: Určené aktivní systémy jsou vyčištěny; zbývající záložní kopie podléhají zdokumentované rotaci záloh nebo odůvodněné výjimce.
5. Částečně zablokováno: Některý ze systémů nebylo možné vyčistit nebo data musí zatím zůstat zachována. Případ se trasovatelně eskaluje.

Nezapomínejte na závislá data

Zprávy mohou odkazovat na soubory, embeddingy, vyhledávací indexy, hodnocení kvality, záznamy v CRM nebo tikety podpory. Požadavek na smazání proto potřebuje stabilní ID žádosti a idempotentní pracovní kroky: Opakované spuštění nesmí vytvořit nové kopie ani vrátit již hotové kroky. U měřicích dat by mělo být již při návrhu rozhodnuto, zda si lze ponechat agregované metriky, které již nelze přiřadit ke konkrétnímu uživateli. Více se dozvíte v článku o analytice chatbotů s ohledem na minimalizaci dat.

Odvolání přístupu chrání zejména na sdílených zařízeních

V hotelích, prodejnách, dílnách nebo domácnostech se na stejném zařízení častěji střídají různí lidé. Proto by možnost „Odvolat přístup“ měla umět víc než jen lokálně smazat cookie. Na straně serveru musí dojít ke zneplatnění známých relačních tokenů, odkazů pro sdílení a případně i vazeb na zařízení. Rozhraní by mělo rozlišovat mezi možnostmi „toto zařízení“, „všechna zařízení“ a „všechny sdílené odkazy“.

Po odvolání přístupu nesmí tlačítko „Zpět“ v prohlížeči zobrazit citlivou historii z mezipaměti. Náhledy v oznámeních, automatické doplňování v prohlížeči a lokální offline data patří do prověrky. Uživatel by zároveň měl dostat jasné potvrzení, které přístupy byly ukončeny a zda jsou data konverzací i nadále uložena. Odvolání přístupu se tak nezamění se smazáním.

Navrhněte potvrzení o smazání přístupně a s tolerancí k chybám

Návratná akce vyžaduje klidné a srozumitelné potvrzení. Vysvětlení WCAG 2.2 k kritériu úspěšnosti 3.3.4 se výslovně vztahuje i na změnu nebo mazání dat spravovaných uživatelem. Počítá se minimálně s jednou možností pro zpětné vrácení, kontrolu nebo potvrzení. Která varianta je vhodná, závisí na daném produktu.

Dobře navržené dialogy uvádějí konkrétně „3 konverzace a 2 přílohy“ namísto pouhého výrazu „data“. Primární a destruktivní akce jsou vizuálně odlišitelné, přístupné z klávesnice a nejsou vysvětleny pouze barvou. Po odeslání oznámí přístupná stavová oblast, že požadavek byl přijat. Kosič s omezenou lhůtou pro obnovení může zachytit chyby obsluhy, nesmí však tajně protiřečit příslobenému okamžitému smazání.

Předání podpoře bez stínové kopie

Pokud je konverzace předána lidskému operátorovi, často vznikne samostatný tiket podpory. Tento objekt má možná jiný účel, jiná přístupová práva a jiná pravidla pro uchovávání. Nastavení historie v chatbotu nesmí takový tiket ani neviditelně smazat, ani tichým způsobem ignorovat. Před předáním by mělo rozhraní vysvětlit, jaký obsah se přenáší. Při pozdějším požadavku musí systém toto propojení dohledat a zpracovat případ podle platných pravidel.

Pokud automatické smazání selže nebo není jasná identita a rozsah, proces vyžaduje bezpečný lidský kanál. Článek o Human Handoffu v podpoře na webu popisuje kontextové balíčky a pravidla eskalace. Předávat by se mělo pouze to, co příslušný pracovník skutečně potřebuje.

Implementační kontrolní seznam pro produktové a podpůrné týmy

1. Proveďte inventuru všech datových objektů a míst uložení konverzace.
2. Nakonfigurujte zobrazení, export, smazání a odvolání přístupu jako samostatná oprávnění.
3. Pro citlivé akce vyžadujte reautentizaci na základě rizika.
4. Strukturujte balíčky pro export srozumitelně a nastavte bezpečné doby expirace.
5. Zajistěte idempotentnost kroků mazání a sledujte je pomocí ID žádosti.
6. Zahrňte vyhledávací index, soubory, analytiku, integrace, mezipaměti a případy podpory.
7. Otestujte potvrzovací dialogy a stavová hlášení pomocí klávesnice a čtečky obrazovky.
8. Simulujte sdílená zařízení, vypršené odkazy a ztracená zařízení.
9. Zviditelněte a eskalujte částečné chyby, aniž byste kopírovali citlivý obsah do logů.
10. Pravidelně revidujte pravidla uchovávání a mazání s pověřencem pro ochranu osobních údajů a odbornými týmy.

Nejdůležitější testy před spuštěním (Go-live)

Testovací případy by neměly pokrývat pouze ideální průběh. Prověřte souběžné požadavky na smazání, vypršení přihlášení během exportu, již odvolané odkazy, nové zprávy během probíhajícího mazání a výpadek připojeného systému. Zkontrolujte také, zda export neobsahuje cizí zprávy ze sdílených účtů a zda je smazaný soubor stále přístupný přes starou URL adresu.

Každá akce vyžaduje očekávaný výsledek v uživatelském rozhraní, API a úložišti. Dobrý akceptační test proto nekončí u zelené potvrzovací zprávy. Následně prověřuje rozhodující datová úložiště, tokeny a veřejné URL adresy. Protokoly událostí by měly dokládat, že byl krok proveden, aniž by znovu ukládaly smazaný obsah konverzace.

Závěr: Kontrola uživatele je vlastnost typu end-to-end

Důvěryhodný chatbot nejen zpřístupní historii. Odděluje zobrazení, export, smazání a odvolání přístupu, přiměřeně ověřuje citlivé akce a zobrazuje skutečný stav zpracování. Rozhodující je propojení jasného UX s datovým modelem, který zná všechny závislé systémy.

Kdo tyto funkce začlení včas do architektury, procesů podpory a testování, sníží množství manuálních výjimek a předejde falešným příslibům. Při plánování prověřte také, které funkce ChatReact odpovídají vašemu webu a procesům podpory. Začněte inventurou dat a jediným kompletním end-to-end testem: exportujte historii, odvolejte přístupy, spusťte smazání a ověřte výsledek ve všech zapojených systémech.

Zdroje a další informace

• EUR-Lex: Nařízení (EU) 2016/679, zejména články 5, 12, 15, 17 a 20.
• EDPB: Pokyny 01/2022 k právům subjektů údajů – Právo na přístup, verze 2.1.
• NIST SP 800-63B: Správa relací (Session Management).
• W3C: Porozumění WCAG 2.2 kritériu úspěšnosti 3.3.4.