Компании запускают ИИ-ассистентов для поддержки, поиска по документам и разбора заявок.
Обычно это простой пилот: подняли модель, подключили базу знаний, дали попробовать.
Проблемы начинаются позже...
В промпт попадает имя клиента, почта, текст обращения, номер договора. Запрос уходит в лог, ответ в историю чата, копия в векторную базу.
Через пару месяцев никто не может сказать, где лежат эти данные и кто к ним имеет доступ. На этом месте эксперимент превращается в обработку персональных данных.
"Модель стоит внутри, значит рисков нет"
Это не так! Локальное размещение убирает часть рисков передачи данных наружу, но требования 152-ФЗ остаются.
Компания всё равно должна понимать, какие данные обрабатывает, зачем, где хранит, кто получает доступ и когда удаляет.
К тому же локальная модель пишет логи, хранит историю диалогов, шлёт телеметрию, использует внешние эмбеддинги или сторонний поиск.
На схеме "всё внутри", а один компонент отправляет текст наружу.
Внешняя LLM не запрещена, но тогда проверяют условия обработки, место хранения, сроки удаления, использование данных для обучения и субподрядчиков.
Фразы "мы не обучаемся на ваших данных" в рекламе мало, это должно быть в договоре.
Что закон считает персональными данными
Любая информация, по которой прямо или косвенно можно определить человека. В ИИ-проектах это ФИО, телефон, почта, номер договора и заявки, текст переписки с клиентом, резюме, кадровые, медицинские и финансовые сведения, а также комбинации полей и логов, по которым человека можно восстановить.
Разработчик видит "просто JSON". Для закона формат не важен.
Пять вопросов до запуска агента
1) Какие данные попадут в промпт. Что сотрудник вставит в чат в понедельник утром: письмо клиента, карточку из CRM, договор? Часто ФИО и телефон модели не нужны, нужен сам текст проблемы.
2) Кто и на каком основании обрабатывает. Проверьте в договоре с поставщиком: перечень данных, запрет использовать их самостоятельно, срок хранения промптов, удаление, субподрядчиков.
3) Где данные на каждом шаге. Не только модель: интерфейс, API-шлюз, журнал запросов, хранилище документов, векторная база, мониторинг, резервные копии, внешние интеграции. Передача за пределы РФ рассматривается отдельно.
4) Что попадает в логи. Частый провал: сохранение промптов отключили, потом включили подробный лог для отладки, и через неделю там вся переписка с клиентами. Решите заранее, что сохраняется, кто видит, сколько хранится, маскируются ли контакты.
5) Как реализовать права человека. Если нельзя удалить запись разом из базы, кэша, истории диалога, векторного индекса и бэкапа, значит жизненный цикл данных не описан.
Что советую сделать на этой неделе
- Выпишите все ИИ-сценарии и поля данных в запросах.
- Нарисуйте маршрут от интерфейса до модели и логов.
- Уберите из промптов лишнее.
- Отключите сохранение запросов, где оно не нужно.
- Проверьте договоры поставщиков.
- Тестируйте на синтетических данных: если агента нельзя проверить без реальных, сценарий недостаточно обезличен.
Отдельный риск: веб-поиск
Если сотрудник отправляет в поиск фразу из обращения клиента, наружу уходит больше, чем планировалось.
Безопаснее по шагам:
убрать идентификаторы, сформировать нейтральный запрос, получить источники, а потом использовать их в работе.
Поисковый слой должен получать минимум данных.
Мы строим срезAI как инфраструктуру веб-поиска для ИИ-агентов. Но никакой API сам по себе не делает процесс соответствующим 152-ФЗ: ответственность начинается с архитектуры заказчика.
Поэтому в рабочих сценариях мы рекомендуем не передавать в поиск ФИО, контакты и исходные тексты обращений.
Если у вас уже есть ИИ-агент или локальная LLM, начните с трёх вопросов:
1) какие ПДн попадают в промпты сейчас?
2) где хранятся запросы и ответы?
3) кто подтвердит, что поставщик не использует их иначе?
Если нет точного ответа хотя бы на один, это повод для инвентаризации.
А что у вас было самым сложным при запуске ИИ: выбор модели, защита промптов, логи или согласование с юристами?
