GDPR и ИИ в службе поддержки: пользовательские идентификаторы имеют значение
Ваша служба поддержки использует ИИ для составления ответов и проверки тикетов. Производительность выросла. Затем ваш DPO изучает настройку.
Типичное сообщение клиента содержит имя, адрес электронной почты и ID заказа. Имя и адрес электронной почты — персональные данные. ID заказа — тоже. Он связывает запись с Анной Смирновой в вашей базе данных заказов. ИИ-поставщик может сопоставить его с другими данными. Если обучающие данные утекут, по этому ID её можно будет повторно идентифицировать.
Отправка любого из этих элементов внешнему ИИ-поставщику без правового основания является нарушением GDPR.
Почему ID заказов являются персональными данными
Статья 4 GDPR даёт широкое определение персональных данных. Оно охватывает любую информацию, относящуюся к идентифицированному или идентифицируемому лицу. Идентифицируемость включает косвенную идентификацию по ссылке на идентификатор.
ID заказа вроде ORD-4521893 — косвенный идентификатор. Сам по себе он не называет Анну Смирнову. В паре с вашей базой данных заказов — называет.
Статья 4(5) GDPR регулирует псевдонимизацию. ID заказов — псевдонимы. Для раскрытия стоящего за ними лица нужен второй источник. Когда вы отправляете один такой ID внешнему ИИ-поставщику, вы передаёте персональные данные. Требуются правовое основание и Соглашение об обработке данных.
Поставщик может не располагать вашей базой данных. Это не снимает вашей ответственности. Вы передали персональные данные. GDPR по-прежнему применяется.
Стандартный пробел в анонимизации
Команды поддержки нередко внедряют обнаружение ПДн для соответствия GDPR. Стандартные инструменты удаляют распространённые типы сущностей.
Стандартное обнаружение охватывает имена клиентов, адреса электронной почты, номера телефонов и номера кредитных карт. Эти типы выявляются корректно.
Стандартное обнаружение не охватывает ID заказов в формате ORD-XXXXXXX. Оно пропускает номера счетов, ссылки на тикеты, внутренние пользовательские ID и ID подписок. Эти типы не выявляются.
Результат выглядит так: «Здравствуйте, я [PERSON_1], мой заказ ORD-4521893 ещё не прибыл. Пожалуйста, напишите мне на [EMAIL_1]».
ID заказа по-прежнему виден. Любой, кто имеет доступ к CRM, немедленно найдёт Анну Смирнову. Анонимизация неполна. В этом и состоит пробел в соответствии.
Расширение для браузера: обнаружение на уровне браузера
Агенты поддержки, работающие с Claude, ChatGPT или Gemini, работают в браузере. Расширение для браузера блокирует утечку пользовательских идентификаторов.
Вот как это работает. Агент вставляет сообщение клиента в AI-инструмент. Расширение определяет, что целевая платформа является ИИ-сервисом. Оно удаляет стандартные ПДн. Затем применяет пользовательские паттерны, соответствующие формату ваших ID заказов, номеров счетов и любых других пользовательских идентификаторов вашей команды. Агент видит только очищенное сообщение. Необработанные данные до ИИ не доходят.
Команда по соответствию настраивает пользовательские паттерны один раз. Она делится пресетом со всеми агентами. Агентам не нужно управлять этим самостоятельно. Они вставляют сообщение. Расширение делает всё остальное.
MCP-сервер: обнаружение на уровне API
Некоторые платформы обращаются к ИИ через API. Intercom использует ИИ для составления ответов. Zendesk применяет ИИ для подсказок. MCP-сервер добавляет анонимизацию на уровне API для таких конфигураций.
Вот как устроен процесс. Сообщение клиента поступает в платформу поддержки. Оно проходит через MCP-эндпоинт до отправки в ИИ. Эндпоинт удаляет стандартные и пользовательские сущности. Очищенное сообщение отправляется в ИИ. ИИ возвращает ответ. Персональные данные не были переданы. Затем агент читает и редактирует ответ в платформе поддержки.
Агенты не замечают изменений в своей работе. Процесс выглядит так же. Пользовательские сущности настраиваются один раз в конфигурации MCP. Все последующие вызовы API используют полное обнаружение сущностей.
Контрольный список DPO по внедрению
1. Составьте карту всех потоков данных в ИИ.
Перечислите места, где агенты используют ИИ. Включите браузерные инструменты, API-инструменты и загрузки файлов.
2. Перечислите все типы идентификаторов в сообщениях клиентов.
Стандартные ПДн — имена, адреса электронной почты, телефоны — охвачены по умолчанию. Пользовательские идентификаторы — ID заказов, ссылки на тикеты, номера счетов — требуют пользовательских паттернов.
3. Добавьте паттерны пользовательских сущностей.
Определите каждый формат. Протестируйте на образцах сообщений. Сохраните в командный пресет.
4. Внедрите на нужном уровне.
Браузерный ИИ: используйте расширение для браузера с общим пресетом. API-интегрированный ИИ: используйте MCP-сервер или предобработку на уровне API.
5. Обновите ваш ROPA.
Зафиксируйте, что ИИ в службе поддержки использует автоматическую анонимизацию. Перечислите охватываемые типы пользовательских идентификаторов. Это ваша документация о технических мерах защиты.
6. Протестируйте настройку.
Прогоните образцы сообщений со всеми типами идентификаторов. Убедитесь, что ничего не достигает ИИ. Шаблоны документов см. в руководстве по правовому соответствию.
Команда поддержки SaaS: практический пример
Команда поддержки SaaS-компании использует Claude через внутреннюю AI-платформу. Сообщения клиентов содержат имена, адреса электронной почты, ID заказов и ID подписок. Некоторые названия функциональных флагов также несут внутренние идентификаторы.
До проверки GDPR: все данные передавались в ИИ. ID заказов и подписок включались.
После настройки обнаружения пользовательских сущностей:
ORD-XXXXXXX и SUB-XXXXXXXX были добавлены как пользовательские сущности. Расширение для браузера развёрнуто с общим пресетом. DPO провёл тестирование и подтвердил, что все идентификаторы удаляются до обработки ИИ.
Изменение в работе агентов: никакого. Агенты работают так же. Анонимизация выполняется в фоновом режиме. У DPO есть задокументированная мера защиты.
Заключение
Соответствие GDPR при использовании ИИ в службе поддержки — это не только удаление имён и адресов электронной почты. ID заказов, номера счетов и ссылки на тикеты являются персональными данными. Стандартные инструменты их пропускают. Настройка пользовательских сущностей закрывает этот пробел.
Шаги просты. Определите форматы ваших идентификаторов. Протестируйте их на образцах сообщений. Внедрите в команде. DPO может завершить это за один день. После этого все данные клиентов удаляются до их поступления во внешние ИИ-системы. С этого момента выигрыш в соответствии сохраняется постоянно.