Как обнаружить, что AI-ассистент тайно сохраняет личные данные

«Нейросети встраивают в приложения как удобных помощников, и мы верим, что они «просто работают». Но однажды мой локальный ассистент начал сохранять ненужные данные. Оказалось, это стандартная опция для разработчиков, которую легко упустить из виду, но она создаёт риски нарушения требований 152-ФЗ о локализации данных. В истории ниже — как я это обнаружил и исправил.»

Тихий сбор данных: как его обнаружить

Изначально ассистент был настроен на запуск в локальной сети. Он обрабатывал запросы через API, и всё казалось под контролем. Но однажды, проверяя логи для отладки другого сервиса, я заметил странные записи. Система логировала не только технические ошибки, но и часть содержания пользовательских запросов — обрывки фраз, упоминания файлов и проектов.

Первая мысль, это баг или случайность. Однако при ближайшем рассмотрении выяснилось, что это была не ошибка, а функционал, включенный по умолчанию в одной из библиотек. Разработчики заложили его для аналитики, чтобы «улучшать качество ответов», но в контексте корпоративного использования и требований ФСТЭК это превращалось в несанкционированное накопление персональных данных.

Анатомия проблемы: где прячется сбор

Настройки, приводящие к такому поведению, редко лежат на поверхности. Они скрыты в конфигурационных файлах, переменных окружения или параметрах инициализации модели. Чаще всего это выглядит как безобидный флаг save_conversation, enable_telemetry или log_prompts, установленный в True.

Ключевая проблема в том, что документация редко акцентирует внимание на последствиях этих настроек для соответствия российскому законодательству. Разработчики фреймворков ориентируются на глобальную практику, где сбор данных для обучения — обычное дело. В российской регуляторике такая практика без явного информированного согласия пользователя и без обеспечения локализации хранения нарушает базовые принципы 152-ФЗ.

Что именно попадает в логи

Текст запросов и ответов: Полные или частичные формулировки, которые могут содержать коммерческую тайну или персональные данные.
Метаданные сессии: Идентификаторы пользователей, временные метки, данные об устройстве.
Контекст диалога: История нескольких сообщений для поддержания связности, которая хранится дольше необходимого.
Данные об ошибках: Вместе с описанием сбоя могут логироваться и те данные, которые его вызвали.

Почему это критично с точки зрения 152-ФЗ и ФСТЭК

Закон № 152-ФЗ «О персональных данных» требует, чтобы обработка (включая сбор и хранение) осуществлялась с определённой целью, на законных основаниях и с согласия субъекта. Автоматическое логирование содержания запросов к AI-ассистенту редко подпадает под заявленные при информировании пользователя цели обработки.

Более того, если логи с данными граждан РФ отправляются или хранятся на серверах за пределами страны, это прямое нарушение требования о локализации. ФСТЭК в своих рекомендациях и требованиях к защите информации (например, в приказе № 239) также уделяет внимание контролю за передачей и некриптографическим методам защиты данных при их обработке. Случайное накопление неучтённых данных ломает всю построенную модель угроз и защиты.

Пошаговый аудит: как проверить свой ассистент

Чтобы исключить риски, необходим системный подход к проверке.

Анализ конфигурации: Проверьте все файлы конфигурации (.env, config.yaml, settings.py) на наличие параметров, связанных с логированием, аналитикой, телеметрией, сохранением истории или улучшением моделей.
Изучение кода инициализации: Найдите в коде место, где создаётся или загружается модель AI-ассистента. Посмотрите аргументы, передаваемые в конструктор или функцию загрузки.
Мониторинг исходящего трафика: Настройте простой мониторинг (например, с помощью tcpdump или средств межсетевого экрана) на предмет подключений к неожиданным внешним доменам в момент работы ассистента.
Проверка директорий логов: Определите, куда приложение пишет логи. Проверьте содержимое этих файлов на предмет фрагментов диалогов.
Тестовый прогон: Запустите ассистент с тестовыми, но узнаваемыми данными (например, уникальной фразой). Через некоторое время проверьте логи и временные файлы на присутствие этой фразы.

Решение: отключаем нежелательное поведение

Обнаружив источник проблемы, отключение обычно сводится к изменению одной-двух настроек. Вот типичные меры для разных сценариев:

Для локальных LLM-фреймворков (Llama.cpp, Ollama): Установите переменные окружения, отключающие телеметрию. Например, для некоторых решений помогает export DO_NOT_TRACK=1 или явное указание в конфиге telemetry: false.
При использовании API-обёрток: Внимательно изучите параметры клиентской библиотеки. Часто там есть опции вроде stream=False или extra_body={"disable_logging": True}, которые нужно явно передать при вызове.
В кастомных решениях: Прямое редактирование кода, отвечающего за логирование. Замените или оберните вызовы стандартных логгеров, чтобы они обрезали или хешировали тело запроса, оставляя только служебную информацию.

Важно не просто отключить логирование, а перевести его в безопасный режим: записывать только факт обращения, статус выполнения и технические детали без сохранения конфиденциального содержимого.

Проактивная защита: настройка с учётом регуляторики

После точечного исправления стоит выстроить процессы, чтобы проблема не повторилась.

Во-первых, внесите проверки конфигурации на наличие «опасных» флагов в процедуру развёртывания (deployment checklist). Во-вторых, настройте регулярный (например, ежеквартальный) аудит логов на предмет утечек чувствительных данных. В-третьих, рассмотрите использование промежуточного прокси-сервера или шлюза для всех запросов к AI-моделям. Этот шлюз будет отвечать за очистку метаданных, анонимизацию и контроль соответствия сессий политикам компании.

С юридической точки зрения, обновите документы: Политику обработки персональных данных и Реестр процессов обработки. Явно укажите в них использование AI-ассистента, цели обработки данных через него и меры, принятые для предотвращения неконтролируемого сохранения информации.

Итог

AI-ассистенты становятся частью инфраструктуры, но их настройки по умолчанию созданы не для наших регуляторных реалий. Случайное логирование данных, это не баг, а часто заложенная возможность, которая конфликтует с 152-ФЗ. Обнаружить это можно только внимательным аудитом конфигурации и трафика. Решение же лежит на стыке технических правок — отключения «помощных» функций аналитики — и административных мер: обновления политик и внедрения процедур контроля. Без этого даже самый локальный и, казалось бы, безопасный инструмент может незаметно создать серьёзный комплаенс-риск.