Безопасность персональных данных при интеграции сторонних ИИ в Узбекистане
Когда бот отправляет сообщение клиента во внешний API, вы передаёте персональные данные третьей стороне за пределы страны. Это надо спроектировать, а не обнаружить постфактум.
Что именно вы передаёте
В типичном ИИ-боте наружу уходит гораздо больше, чем кажется: текст сообщения, история диалога, имя из профиля Telegram, а нередко и телефон, адрес доставки, номер заказа, попавшие в контекст промпта.
Первое действие — составить точный перечень полей, покидающих ваш контур. Не по проектной документации, а по реальным логам исходящих запросов. В проектах такого типа список почти всегда шире, чем предполагала команда.
Второе действие — определить, какие из этих полей действительно нужны модели для выполнения задачи. Для классификации обращения не нужен ни телефон, ни адрес. Для формулировки ответа о статусе заказа достаточно статуса, а не всей карточки клиента.
Требования по локализации данных
В Узбекистане действует требование о хранении персональных данных граждан на серверах, размещённых на территории страны, с ведением реестра баз персональных данных. Это относится к вашей системе хранения, и проектировать нужно от этого.
Практическое следствие: основная база с ФИО, телефонами и адресами живёт на локальном хостинге или в локальном ЦОД, а во внешний ИИ-сервис уходит обезличенный минимум. Такая архитектура снимает большую часть вопросов.
Регулирование меняется, и трактовки бывают разными. Перед запуском сервиса, который массово обрабатывает данные граждан, стоит получить заключение юриста, специализирующегося на локальном законодательстве, а не полагаться на общие статьи.
Технические меры
Псевдонимизация: вместо телефона отправляйте внутренний идентификатор, вместо имени — обращение по роли. Сопоставление держите в своей базе. Модель прекрасно работает с «клиент №4821».
Маскирование на лету: перед отправкой прогоняйте текст через фильтр, вырезающий номера телефонов, номера карт и паспортные данные. Клиенты регулярно пишут такое в чат сами, без всякого запроса с вашей стороны.
Настройки провайдера: у крупных API есть режимы, при которых данные не используются для обучения, и корпоративные условия с ограниченным сроком хранения. Включайте их явно и фиксируйте в договоре, а не полагайтесь на дефолты.
Логи — самое слабое место
Логи диалогов обычно содержат всё то, что вы старательно не передавали наружу, и лежат в открытом виде в системе мониторинга, к которой имеет доступ вся команда разработки.
Правила простые: маскировать чувствительные поля в логах, ограничить срок хранения, разграничить доступ по ролям, вести журнал обращений к логам. Резервные копии тоже входят в контур и тоже требуют шифрования.
Отдельно решите вопрос с выгрузками для аналитики. Таблица с диалогами, выгруженная в облачный сервис для построения отчёта, — типичный канал утечки, который никто не считает интеграцией.
Согласия и прозрачность
Пользователь должен понимать, что общается с ботом и что обработка выполняется с применением автоматизированных систем. Одна честная строка при первом запуске снимает больше претензий, чем страница юридического текста.
В политике конфиденциальности перечислите категории обрабатываемых данных, цели, срок хранения и факт передачи обработчикам. Документ должен быть на русском и узбекском, а не только на английском.
Дайте возможность запросить удаление данных и реализуйте её технически, а не декларативно. Кнопка удаления, которая ничего не удаляет из бэкапов и логов, хуже отсутствия кнопки.
Что проверить перед запуском
Перехватите исходящий трафик на тестовом стенде и посмотрите глазами, что уходит в API. Это пятиминутная проверка, которая регулярно обнаруживает передачу лишних полей.
Проверьте поведение при промпт-инъекции: попробуйте заставить бота выдать данные другого пользователя или содержимое системного промпта. Изоляция контекста между диалогами должна быть жёсткой.
Опишите процедуру на случай инцидента: кто отключает интеграцию, как уведомляются клиенты, где хранится журнал. Разбираться в этом во время инцидента поздно.