Изтриване и експортиране на историята в чатбот: Сигурен потребителски контрол

Историята на разговора с чатбот е практична за потребителите: те могат да препрочитат отговори, да продължат разговор по-късно или да предадат информация на поддръжката. Същата история обаче може да съдържа номера на поръчки, описания на проблеми, данни за контакт или друга чувствителна информация. Всеки, който съхранява разговори, се нуждае от нещо повече от незабележим бутон „История“. Потребителите трябва да разбират какви данни съществуват, как да ги вземат със себе си, да ги изтрият или да оттеглят бъдещия достъп до тях.

Това ръководство показва приложим продуктов и технически модел за уебсайт чатботs. То съчетава потребителско удобство, минимализъм на данните, сигурна проверка на самоличността и проследими системни състояния. Указанията не представляват индивидуална правна консултация; конкретните задължения зависят, наред с другото, от целта, правното основание, системната архитектура и засегнатите данни.

Четири функции вместо един-единствен бутон за историята

„Управление на историята“ е твърде общо概念. В интерфейса и в бекенда трябва да се разграничат четири различни намерения:

• Преглед: Потребителите четат съхранените разговори, прикачени файлове и разпознаваеми метаданни в хронологичен и разбираем вид.
• Експортиране: Те получават копие в четлив формат и, ако е уместно за случая или се изисква по закон, допълнително в структуриран машинночетим формат.
• Изтриване: Премахват отделни разговори или цялата асоциирана история. Интерфейсът обяснява обхвата, сроковете и възможните изключения.
• Оттегляне на достъп: Невалидират линкове за споделяне, познати устройства или токени за възобновяване, без задължително веднага да изтриват всички съдържателни данни.

Това разделение предотвратява опасни недоразумения. „Изход“ не изтрива данни от разговори. „Скриване на историята“ не е изтриване. А изтекъл линк не означава автоматично, че базовите записи са изчезнали. В допълнение си струва да прочетете нашето ръководство за сигурно продължаване на чатбот разговори.

Започнете с ясен модел на данните

Преди екипите да проектират бутони, те трябва да инвентаризират съхраняваните обекти. Един разговор често се състои не само от съобщения. Към него се добавят идентификатори на сесии, времеви печати, референции към файлове, събития за сигурност, билети за поддръжка, обратна връзка и технически логове. За всеки обект е необходима документирана цел, отговорник, правило за съхранение и път за изтриване.

Общият Регламент относно защитата на данните (GDPR) споменава в Член 5, наред с другото, свеждането на данните до минимум и ограничението на съхранението. Член 15 засяга правото на достъп, Член 17 – правото на изтриване с неговите условия и изключения, а Член 20 – преносимостта на данните в съответната им област на приложение. От това не следва, че всеки чатбот интерфейс трябва да предлага идентични функции. Продуктовите екипи обаче трябва да изградят потоците от данни така, че легитимните искания да могат да се обработват надеждно.

Адекватно потвърждаване на самоличността преди експорт и изтриване

Всеки, който прави дадена история достъпна само чрез лесно предсказуем линк или повторно използван сесиен идентификатор, рискува изтичане на данни. В същото време проверката на самоличността не бива да изисква повече лични данни, отколкото са необходими за конкретното действие. Окончателните На насоки 01/2022 на EDPB относно правото на достъп разглеждат, наред с другото, идентификацията, обхвата и сигурното предоставяне на копия. Член 12, параграф 6 от GDPR позволява допълнителна информация за потвърждаване на самоличността, ако съществуват обосновани съмнения.

В практиката се е доказал подходът на градиране въз основа на риска. показването на псевдонимизирана кратка история на същото устройство може да изисква валидна, краткотрайна сесия. Пълен експорт, необратимо изтриване или оттегляне на достъпа от всички устройства по-скоро оправдават повторна автентикация. Текущите насоки на NIST за управление на сесии описват реавтентикацията, времевите лимити и прекратяването на сесии като самостоятелни контроли. Конкретната нива на сигурност трябва да съответства на риска; изискванията на NIST за федералните агенции в САЩ не са общовалидно правно изискване за всяка компания.

За обществени уеб джаджи и автентикирани клиентски зони границата трябва да остане видима. Нашата публикация относно идентичността и достъпа до данни в клиентския портал показва защо публичният чат не трябва мълчаливо да се превръща в канал за данни от акаунта.

Експортът трябва да бъде разбираем и напълно обясним

Добрият експорт не е просто суров дъмпове от базата данни. Той започва с преглед: период на създаване, съдържащи се разговори, прикачени файлове, използвана часова зона и версия на формата. След това съдържанието следва в ясна последователност. JSON може да бъде полезен за структурирана последваща обработка; HTML или PDF е по-лесен за четене от повечето хора. Дали и в какъв обхват преносимият формат се изисква по закон, трябва да се провери за конкретния случай.

Ако системата генерира експорта асинхронно, интерфейсът се нуждае от ясен статус: „подготвя се“, „готов до…“, „изтекъл“ или „неуспешен“. Линкът за изтегляне трябва да бъде краткотраен, непредвидим и възможност за оттегляне след употреба. Конфиденциални данни като вътрешни промптове, ключове за достъп или данни на други лица нямат място в пакета. Преди предоставяне, филтър от страна на сървъра трябва да провери дали връзките с казуси за поддръжка, споделени разговори или съдържание от трети страни изискват специално третиране.

Изтриването като машина на състоянията, а не като незабавно обещание

Бутон със съобщение „Всичко е изтрито“ е проблематичен, ако индексът за търсене, хранилището за анализи, системата за поддръжка или архивите все още съдържат копия. По-добре е да се използва малка машина на състоянията (state machine), която да отразява действителния процесс.

Разумни състояния на изтриване

1. Заявено: Самоличността и желания обхват са потвърдени.
2. Блокирано: Историята вече не е достъпна за нормална употреба; токените за възобновяване и споделяне са невалидни.
3. В обработка: Основното хранилище, индексът за търсене, хранилището за файлове, целите за анализи и интеграции се изчистват.
4. Завършено: Предвидените активни системи са изчистени; оставащите резервни копия подлежат на документираната ротация на архивите или на обосновано изключение.
5. Частично блокирано: Дадена система не е могла да бъде изчистена или данните трябва временно да бъдат запазени. Казусът се ескалира по проследим начин.

Не забравяйте зависимите данни

Съобщенията могат да реферират към файлове, ембединги (embeddings), индекси за търсене, оценки на качеството, CRM записи или билети за поддръжка. Затова искането за изтриване се нуждае от стабилен ID на заявката и идемпотентни стъпки: повторно изпълнение не трябва да създава нови копия или да отменя вече извършени стъпки. За показателите от измервания още при проектирането трябва да се реши дали агрегираните, неасоциирани данни могат да бъдат запазени. Повече за това ще намерите в статията относно аналитичност за чатбот с ограничаване на данните.

Оттеглянето защитава особено при споделени устройства

В хотели, търговски обекти, сервизи или семейни домакинства хората често сменят потребителя на едно и също устройство. Затова „Оттегляне на достъп“ трябва да може да прави повече от просто да изтрие бисквитка локално. На сървърно ниво известните сесийни токени, линкове за споделяне и, ако е приложимо, обвързвания с устройства трябва да станат невалидни. Интерфейсът трябва да прави разлика между „това устройство“, „всички устройства“ и „всички споделени линкове“.

След оттегляне, бутонът „Назад“ в браузъра не трябва да показва чувствителна история от кеша. Предварителните прегледи в известията, автодовършването в браузъра и локалните офлайн данни подлежат на проверка. В същото време потребителят трябва да получи ясно потвърждение кои достъпи са прекратени и дали данните от разговора продължават да се съхраняват. Така оттеглянето няма да се бърка с изтриване.

Направете потвърждението за изтриване достъпно и устойчиво на грешки

Необратимо действие се нуждае от спокойно, разбираемо потвърждение. Обяснението към Критерий за успеваемост 3.3.4 от WCAG 2.2 изрично се отнася и за промяна или изтриване на данни под контрола на потребителя. Предвидена е поне една възможност за отмяна, проверка или потвърждение. Кой вариант е подходящ, зависи от продукта.

Добрите диалогови прозорци посочват конкретно „3 разговора и 2 прикачени файла“ вместо просто „данни“. Основното и деструктивното действие са визуално разграничими, достъпни чрез клавиатура и не са обяснени само чрез цвят. След изпращане достъпна зона за статус съобщава, че заявката е приета. Кошче с ограничен срок за възстановяване може да улови грешки при работа, но не трябва тайно да противоречи на обещано незабавно изтриване.

Прехвърляне към поддръжка (Support handoff) без скрити копия

Ако разговор се препредаде на човек, често се създава отделен билет за поддръжка. Този обект може да има различна цел, различни роли за достъп и различно правило за съхранение. Настройката за историята в чатбот не трябва нито невидимо да изтрива такъв билет, нито мълчаливо да го пренебрегва. Преди прехвърлянето интерфейсът трябва да обясни кои съдържания се пренасят. При последващо запитване системата трябва да открие връзката и да обработи случая според действащите правила.

Ако автоматичното изтриване се провали или самоличността и обхватът са неясни, процесът се нуждае от сигурен човешки канал. Публикацията за прехвърляне към човек (Human Handoff) в поддръжката на уебсайт описва контекстните пакети и правилата за ескалация за тази цел. Трябва да се препредава само това, от което съответният служител наистина се нуждае.

Чеклист за внедряване от продуктови и поддържащи екипи

1. Инвентаризирайте всички обекти с данни и места за съхранение на даден разговор.
2. Моделирайте прегледа, експорта, изтриването и оттеглянето като отделни права.
3. Изисквайте повторна автентикация въз основа на риска за чувствителни действия.
4. Структурирайте пакетите за експорт разбираемо и задайте сигурни срокове на валидност.
5. Направете стъпките по изтриване идемпотентни и ги проследявайте с ID на заявката.
6. Включете индекса за търсене, файловете, анализите, интеграциите, кешовете и казусите за поддръжка.
7. Тествайте диалозите за потвърждение и статусите с клавиатура и екранен четец.
8. Симулирайте споделени устройства, изтекли линкове и изгубени устройства.
9. Ескалирайте видимо частични грешки, без да копирате чувствително съдържание в логовете.
10. Редовно проверявайте правилата за съхранение и изтриване с екипите по защита на данните и бизнес звената.

Най-важните тестове преди пускане в реална среда (Go-live)

Тестовите сценарии не трябва да покриват само идеалния път. Проверете паралелни заявки за изтриване, изтичане на сесията по време на експорт, вече оттеглени линкове, нови съобщения по време на текущо изтриване и отказ на свързана система. Освен това проверете дали експортът съдържа чужди съобщения от споделени акаунти и дали изтрит файл е все още достъпен чрез стар URL адрес.

За всяко действие е необходим очакван резултат в интерфейса, API и хранилището. Добрият приемочно-предавателен тест затова не завършва със зелено съобщение за успех. Той проверява след това съответните хранилища на данни, токени и публични URL адреси. Логовете за събития трябва да доказват, че дадена стъпка е изпълнена, без отново да записват изтритото съдържание на разговора.

Заключение: Потребителският контрол е цялостно (End-to-End) качество

Надеждният чатбот прави историята не просто откриваема. Той разделя прегледа, експортирането, изтриването и оттеглянето, проверява адекватно чувствителните действия и показва реалния статус на обработка. Решаваща е връзката между ясен UX и модел на данните, който познава всички зависими системи.

Всеки, който интегрира тези функции рано в архитектурата, процесите на поддръжка и тестовете, намалява ръчните изключения и избягва фалшиви обещания. При планирането проверете и кои функции на ChatReact пасват на вашия уебсайт и процес на поддръжка. Започнете с инвентаризация на данните и един-единствен цялостен тест: експортиране на историята, оттегляне на достъпите, задействане на изтриването и доказване на резултата във всички участващи системи.

Източници и допълнителни бележки

• EUR-Lex: Регламент (ЕС) 2016/679, по-специално Членове 5, 12, 15, 17 и 20.
• EDPB: Guidelines 01/2022 on data subject rights – Right of access, Версия 2.1.
• NIST SP 800-63B: Session Management.
• W3C: Understanding WCAG 2.2 Success Criterion 3.3.4.