Usuwanie i eksportowanie historii czatu: Bezpieczna kontrola użytkownika

Historia czatu jest praktyczna dla użytkowników: mogą ponownie przeczytać odpowiedzi, kontynuować rozmowę później lub przekazać informacje do działu wsparcia. Ta sama historia może jednak zawierać numery zamówień, opisy problemów, dane kontaktowe lub inne wrażliwe informacje. Każdy, kto zapisuje rozmowy, potrzebuje czegoś więcej niż niepozornego przełącznika „Historia”. Użytkownicy powinni rozumieć, jakie dane są przechowywane, jak mogą je pobrać, usunąć lub cofnąć dalszy dostęp do nich.

Ten przewodnik przedstawia możliwy do wdrożenia model produktowy i techniczny dla chatbotów internetowych. Łączy on wygodę użytkowania, minimalizację danych, bezpieczną weryfikację tożsamości oraz przejrzyste stany systemu. Wskazówki te nie stanowią indywidualnej porady prawnej; konkretne obowiązki zależą między innymi od celu, podstawy prawnej, architektury systemu i rodzaju przetwarzanych danych.

Cztery funkcje zamiast jednego przełącznika historii

Hasło „Zarządzaj historią” jest zbyt ogólne. W interfejsie i w systemie backendowym należy rozróżnić cztery odrębne intencje:

• Przeglądanie: Użytkownicy czytają zapisane rozmowy, załączniki i widoczne metadane w zrozumiałej chronologii.
• Eksportowanie: Otrzymują kopię w czytelnym formacie oraz, jeśli jest to uzasadnione lub wymagane prawnie, dodatkowo w ustrukturyzowanym formacie nadającym się do odczytu maszynowego.
• Usuwanie: Usuwają pojedyncze rozmowy lub całą przypisaną historię. Interfejs wyjaśnia zakres, terminy i ewentualne wyjątki.
• Cofanie dostępu: Unieważniają linki do udostępniania, znane urządzenia lub tokeny wznowienia sesji, bez konieczności natychmiastowego usuwania wszystkich treści.

To rozróżnienie zapobiega niebezpiecznym nieporozumieniom. „Wylogowanie” nie usuwa danych rozmowy. „Ukrycie historii” to nie to samo co jej usunięcie. A wygasły link nie oznacza automatycznie, że leżące u jego podstaw rekordy danych zniknęły. Warto uzupełnić tę wiedzę, czytając nasz przewodnik na temat bezpiecznego kontynuowania rozmów z chatbotem.

Rozpocznij od jasnego modelu danych

Zanim zespoły zaczną projektować przyciski, powinny skatalogować przechowywane obiekty. Rozmowa często składa się nie tylko z wiadomości. Dochodzą do tego identyfikatory sesji, znaczniki czasu, odnośniki do plików, zdarzenia bezpieczeństwa, zgłoszenia wsparcia, opinie i logi techniczne. Każdy obiekt wymaga udokumentowanego celu, osoby odpowiedzialnej, reguły przechowywania oraz ścieżki usuwania.

W Ogólnym rozporządzeniu o ochronie danych (RODO), w artykule 5 wymieniono m.in. minimalizację danych i ograniczenie przechowywania. Artykuł 15 dotyczy prawa dostępu przysługującego osobie, której dane dotyczą, artykuł 17 – prawa do usunięcia danych („prawa do bycia zapomnianym”) wraz z warunkami i wyjątkami, a artykuł 20 – prawa do przenoszenia danych w odpowiednim zakresie zastosowania. Nie oznacza to, że każdy interfejs ChatReact musi oferować identyczne funkcje. Zespoły produktowe powinny jednak tak budować przepływy danych, aby uprawnione żądania mogły być niezawodnie obsługiwane.

Odpowiednio weryfikuj tożsamość przed eksportem i usunięciem

Każdy, kto udostępnia historię wyłącznie za pośrednictwem łatwego do odgadnięcia linku lub ponownie używanego identyfikatora sesji, ryzykuje wyciek danych. Jednocześnie weryfikacja tożsamości nie może rutynowo wymagać większej ilości danych osobowych, niż jest to konieczne do wykonania danej akcji. Ostateczne wytyczne EDPB 01/2022 dotyczące prawa dostępu omówiono m.in. kwestie identyfikacji, zakresu i bezpiecznego dostarczania kopii. Artykuł 12 ust. 6 RODO zezwala na żądanie dodatkowych informacji w celu potwierdzenia tożsamości, jeśli istnieją uzasadnione wątpliwości co do tożsamości osoby występującej z żądaniem.

W praktyce sprawdza się podejście stopniowalne, oparte na ryzyku. Wyświetlanie pseudonimowej, krótkiej historii na tym samym urządzeniu może wymagać jedynie ważnej, krótkotrwałej sesji. Pełny eksport, nieodwracalne usunięcie lub cofnięcie dostępu dla wszystkich urządzeń uzasadnia ponowną uwierzytelnienie. Aktualne wytyczne NIST dotyczące zarządzania sesją opisują ponowne uwierzytelnianie, limity czasowe i zamykanie sesji jako odrębne mechanizmy kontrolne. Konkretny poziom zabezpieczeń musi odpowiadać ryzyku; wymogi NIST dla amerykańskich agencji federalnych nie stanowią bezwzględnego wymogu prawnego dla każdej firmy.

W przypadku publicznych widgetów i zalogowanych stref klienta granica ta powinna pozostać widoczna. Nasz artykuł na temat tożsamości i dostępu do danych w portalu klienta wyjaśnia, dlaczego publiczny czat nie powinien cicho stawać się kanałem dostępu do danych konta.

Eksport musi być zrozumiały i w pełni przejrzysty

Dobry eksport to nie zrzut surowych danych z bazy. Zaczyna się od przeglądu: zakres dat utworzenia, zawarte rozmowy, załączniki, użyta strefa czasowa i wersja formatu. Następnie prezentowane są treści w jasnej kolejności. Format JSON może być przydatny do ustrukturyzowanego dalszego przetwarzania; HTML lub PDF są łatwiejsze do odczytania dla większości ludzi. To, czy i w jakim zakresie format przenośny jest wymagany prawnie, należy przeanalizować dla konkretnego przypadku.

Jeśli system generuje eksport asynchronicznie, interfejs wymaga jednoznacznego statusu: „w trakcie przygotowywania”, „gotowy do…”, „wygasł” lub „błąd”. Link do pobrania powinien być krótkotrwały, niemożliwy do odgadnięcia i unieważniany po użyciu. Poufne informacje, takie jak wewnętrzne prompt-y, klucze dostępu czy dane innych osób, nie powinny znajdować się w pakiecie. Przed udostępnieniem filtr po stronie serwera powinien sprawdzić, czy powiązania ze zgłoszeniami wsparcia, udostępnionymi konwersacjami lub treściami stron trzecich nie wymagają specjalnego traktowania.

Usuwanie jako maszyna stanów zamiast natychmiastowej obietnicy

Przycisk z komunikatem „Wszystko usunięte” jest problematyczny, jeśli indeks wyszukiwania, archiwum analityczne, system wsparcia lub kopia zapasowa nadal zawierają kopie. Lepszym rozwiązaniem jest niewielka maszyna stanów, która odzwierciedla rzeczywisty proces.

Sensowne stany usuwania

1. Zażądano: Tożsamość i żądany zakres zostały potwierdzone.
2. Zablokowano: Historia nie jest już dostępna do normalnego użytku; tokeny wznowienia i udostępniania są nieważne.
3. W trakcie przetwarzania: Pamięć główna, indeks wyszukiwania, magazyn plików, cele analityczne i integracyjne są czyszczone.
4. Zakończono: Przewidziane aktywne systemy zostały wyczyszczone; pozostałe kopie zapasowe podlegają udokumentowanej rotacji backupów lub uzasadnionemu wyjątkowi.
5. Częściowo zablokowano: Jednego z systemów nie udało się wyczyścić lub dane muszą narazie zostać zachowane. Sprawa jest w sposób identyfikowalny przekazywana wyżej.

Nie zapominaj o danych zależnych

Wiadomości mogą odwoływać się do plików, osadzeń (embeddings), indeksów wyszukiwania, ocen jakości, rekordów CRM lub zgłoszeń wsparcia. Żądanie usunięcia wymaga zatem stabilnego ID żądania oraz idempotentnych kroków roboczych: ponowne uruchomienie procesu nie może tworzyć nowych kopii ani cofać już wykonanych kroków. W przypadku danych pomiarowych już na etapie projektowania należy zdecydować, czy zagregowane, niemożliwe do przypisania wskaźniki mogą zostać zachowane. Więcej na ten temat znajdziesz w artykule o analityce chatbotów zgodnej z zasadą minimalizacji danych.

Cofanie dostępu chroni szczególnie na urządzeniach współdzielonych

W hotelach, salach sprzedaży, warsztatach czy gospodarstwach domowych z jednego urządzenia często korzysta wiele osób. Dlatego funkcja „Cofnij dostęp” powinna potrafić więcej niż tylko lokalne usunięcie pliku cookie. Po stronie serwera znane tokeny sesji, linki udostępniania i ewentualne powiązania urządzeń muszą zostać unieważnione. Interfejs powinien rozróżniać opcje: „to urządzenie”, „wszystkie urządzenia” oraz „wszystkie udostępnione linki”.

Po cofnięciu dostępu przycisk „Wstecz” w przeglądarce nie może pokazywać wrażliwej historii z pamięci podręcznej (cache). Podglądy w powiadomieniach, autouzupełnianie w przeglądarce oraz lokalne dane offline powinny zostać uwzględnione w weryfikacji. Jednocześnie użytkownik powinien otrzymać jasne potwierdzenie, które dostępy zostały zakończone i czy dane rozmowy są nadal przechowywane. Zapobiega to myleniu cofnięcia dostępu z usunięciem danych.

Zaprojektuj potwierdzenie usunięcia jako dostępne i tolerancyjne na błędy

Nieodwracalna akcja wymaga spokojnego, zrozumiałego potwierdzenia. Wyjaśnienie WCAG 2.2 do kryterium sukcesu 3.3.4 odnosi się jednoznacznie również do modyfikowania lub usuwania danych kontrolowanych przez użytkownika. Przewiduje ono co najmniej jedną możliwość cofnięcia, weryfikacji lub potwierdzenia. Wybór odpowiedniego wariantu zależy od produktu.

Dobre okna dialogowe podają konkretnie „3 rozmowy i 2 załączniki” zamiast ogólnego „dane”. Akcja podstawowa i akcja destrukcyjna są wyraźnie rozróżnialne wizualnie, dostępne z poziomu klawiatury i objaśnione nie tylko za pomocą koloru. Po wysłaniu żądania dostępny obszar statusu informuje, że zgłoszenie zostało przyjęte. Kosz z ograniczonym czasem na przywrócenie danych może wyłapać błędy obsługi, ale nie może po cichu przeczyć obietnicy natychmiastowego usunięcia.

Przekazanie do wsparcia (handoff) bez tworzenia ukrytych kopii

Gdy rozmowa jest przekazywana człowiekowi, często powstaje osobne zgłoszenie w systemie wsparcia (ticket). Obiekt ten może mieć inny cel, inne role dostępu i inne reguły przechowywania. Ustawienie historii w chatbocie nie może ani niewidocznie usuwać takiego zgłoszenia, ani go milcząco ignorować. Przed przekazaniem rozmowy interfejs powinien wyjaśnić, jakie treści zostaną przejęte. W przypadku późniejszego żądania system musi odnaleźć to powiązanie i obsłużyć sprawę zgodnie z obowiązującymi zasadami.

Jeśli automatyczne usunięcie nie powiedzie się lub tożsamość i zakres są niejasne, proces wymaga bezpiecznego kanału obsługi przez człowieka. Artykuł na temat Human Handoff w wsparciu na stronie WWW opisuje pakiety kontekstowe i reguły eskalacji. Przekazywane powinno być tylko to, czego odpowiedni pracownik naprawdę potrzebuje.

Lista kontrolna wdrożenia dla zespołów produktowych i wsparcia

1. Zinwentaryzuj wszystkie obiekty danych i miejsca przechowywania rozmowy.
2. Zaprojektuj przeglądanie, eksport, usuwanie i cofanie dostępu jako odrębne uprawnienia.
3. Wprowadź ponowne uwierzytelnianie oparte na ryzyku dla wrażliwych operacji.
4. Zadbaj o przejrzystą strukturę pakietów eksportowych i ustaw bezpieczne czasy wygaśnięcia.
5. Zapewnij idempotentność kroków usuwania i śledź je za pomocą ID żądania.
6. Uwzględnij indeks wyszukiwania, pliki, analitykę, integracje, pamięć podręczną i zgłoszenia wsparcia.
7. Przetestuj okna dialogowe potwierdzenia i komunikaty statusu za pomocą klawiatury i czytnika ekranu.
8. Symuluj sytuacje korzystania ze współdzielonych urządzeń, wygasłych linków i utraconych urządzeń.
9. Eskaluj częściowe błędy w widoczny sposób, nie kopiując wrażliwych treści do logów.
10. Regularnie weryfikuj zasady przechowywania i usuwania z działem ochrony danych i zespołami biznesowymi.

Najważniejsze testy przed uruchomieniem (go-live)

Przypadki testowe nie powinny obejmować wyłącznie scenariuszy pomyślnych. Przetestuj równoległe żądania usunięcia, wygaśnięcie sesji podczas eksportu, już unieważnione linki, nowe wiadomości przychodzące podczas trwającego usuwania oraz awarię połączonego systemu. Sprawdź również, czy eksport nie zawiera cudzych wiadomości ze współdzielonych kont oraz czy usunięty plik jest nadal dostępny pod starym adresem URL.

Każda akcja wymaga oczekiwanego rezultatu w interfejsie, API i magazynie danych. Dobry test odbiorczy nie kończy się zatem na zielonym komunikacie o sukcesie. Następnie weryfikuje kluczowe magazyny danych, tokeny i publiczne adresy URL. Logi zdarzeń powinny potwierdzać, że dany krok został wykonany, nie zapisując ponowie usuniętej treści rozmowy.

Podsumowanie: Kontrola użytkownika to cecha typu end-to-end

Godny zaufania chatbot nie tylko umożliwia odnalezienie historii. Rozdzielają przeglądanie, eksport, usuwanie i cofanie dostępu, odpowiednio weryfikuje wrażliwe akcje i pokazuje rzeczywisty stan przetwarzania. Kluczowe jest połączenie przejrzystego UX z modelem danych, który uwzględnia wszystkie systemy zależne.

Integracja tych funkcji na wczesnym etapie architektury, procesów wsparcia i testów redukuje ręczne wyjątki i pozwala uniknąć fałszywych obietnic. Podczas planowania sprawdź również, które funkcje ChatReact pasują do Twojej witryny i procesu wsparcia. Zacznij od inwentaryzacji danych i jednego testu end-to-end: wyeksportuj historię, cofnij dostęp, zainicjuj usunięcie i zweryfikuj rezultat we wszystkich zaangażowanych systemach.

Źródła i dalsze wskazówki

• EUR-Lex: Rozporządzenie (UE) 2016/679, w szczególności artykuły 5, 12, 15, 17 i 20.
• EDPB: Guidelines 01/2022 on data subject rights – Right of access, Wersja 2.1.
• NIST SP 800-63B: Session Management.
• W3C: Understanding WCAG 2.2 Success Criterion 3.3.4.