Чек-лист 152-ФЗ для LLM: что проверить до пилота

Зачем этот чек-лист нужен до пилота

Команда перед пилотом обычно смотрит на одно: насколько хорошо модель отвечает. Это важно, но этого мало. Если заранее не проверить путь данных, удачный демо-сценарий быстро превращается в спор с ИБ, юристами и закупкой.

Проблема чаще всего не в самом ответе модели. Ломается другое: где остаются промпты, кто видит логи, сколько живут бэкапы, попадают ли в запрос ФИО, телефон, номер договора или комментарии оператора. Чек-лист по 152-ФЗ нужен именно для этого слоя. Его проще всего пропустить на старте.

Пилот почти всегда собирает больше данных, чем команда планировала. Разработчики включают подробные логи для отладки, аналитики сохраняют примеры запросов, менеджеры пересылают скриншоты в чаты, подрядчик просит выгрузку. Если это не разобрать заранее, риски накапливаются еще до запуска.

Что считать персональными данными в вашем сценарии

Персональные данные начинаются не там, где в схеме есть отдельное поле "ФИО", а там, где человека можно узнать по запросу целиком. Для LLM это частая ловушка. Часть данных лежит в явных полях, а часть прячется в тексте, вложенных комментариях и служебных заметках.

Сначала соберите очевидные поля: ФИО, телефон, email, адрес, дату рождения, номер документа, номер договора, клиентский ID, если по нему можно быстро выйти на человека. В банке к этому часто добавляются фрагменты карты, история обращений и данные анкеты. В ритейле - адрес доставки, телефон получателя и комментарий к заказу. В SaaS - рабочая почта, подпись в тикете, имя сотрудника и данные аккаунта.

Потом проверьте свободный текст. Клиент сам пишет лишнее чаще, чем кажется: "Меня зовут Иван", "Перезвоните на этот номер", "Живу по адресу...". Сотрудник тоже может вставить лишнее в промпт, если копирует переписку из CRM или help desk. Именно такие куски чаще всего проходят мимо формальных правил, потому что никто не пометил их как отдельные поля.

Не ограничивайтесь данными клиентов. В запросах часто есть сведения о сотрудниках, подрядчиках, курьерах, кандидатах и партнерах. Если менеджер отправил в модель письмо с подписью, внутренний номер и рабочий email уже ушли вместе с текстом. Для 152-ФЗ разница небольшая: это тоже персональные данные.

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

Обычно хватает простых замен: ФИО на "клиент_1", полного адреса на город или регион, точной даты рождения на возрастную группу, телефона и email на маску, номера договора на внутренний токен. Если поле не влияет на ответ модели, убирайте его до отправки и до записи в логи. Это часто снижает риск без большой переделки процесса.

Где данные проходят по пути запроса

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

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

Карта потока данных

На такой схеме быстро появляются одни и те же узлы: форма или чат-виджет, backend и API-шлюз, очереди, логи приложения, мониторинг, хранилища, бэкапы, архивы, а также BI, CRM, антифрод и другие системы, куда уходит копия события.

После этого отдельно отметьте тестовые среды и песочницы. Именно там часто лежат старые дампы с реальными данными, доступ к которым давно никто не пересматривал. Если разработчики гоняют боевые диалоги в staging, это уже часть контура риска, даже если пилот еще не стартовал.

Потом проверьте, кто на самом деле видит промпты и ответы. Список почти всегда шире, чем кажется: разработчики, поддержка, аналитики, подрядчики, дежурная смена, сотрудники с доступом к админке. Если в интерфейсе можно открыть полный текст запроса без маскирования PII, это лучше зафиксировать сразу, а не после закупки.

Для каждого узла отметьте еще одну вещь: данные остаются в РФ или уходят за ее пределы. Смотрите не только на LLM-провайдера, но и на логирование, error tracking, облачные бэкапы и продуктовую аналитику. Даже если запросы к моделям идут через российский шлюз и хранятся в РФ, ваш frontend, CRM или мониторинг могут отправлять те же данные в другой контур.

Хорошая схема помещается на одну страницу. Если на ней есть "непонятные" стрелки, у вас уже есть список мест, которые нужно проверить до пилота.

Что проверить в логах

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

Начните с простого правила: в логах должен оставаться только минимум, нужный для поддержки сервиса. В большинстве случаев достаточно времени запроса, технического request_id, модели, кода ответа, числа токенов, стоимости и короткой причины ошибки. Полные prompts и ответы почти никогда не нужны на постоянной основе.

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

Перед пилотом проверьте базовые вещи: какие поля пишутся в application logs, access logs и трассировку по умолчанию; сохраняются ли полный prompt, ответ модели, tool arguments и вложения; кто видит эти записи по ролям; сколько дней они хранятся; куда логи уходят дальше - в аналитику, SIEM, тестовые выгрузки, почту или служебные чаты.

Отдельно пересмотрите права доступа. Частая ошибка банальна: доступ к логам есть у всей команды, потому что так удобнее. Для пилота это уже лишнее. Полный доступ нужен тем, кто реально разбирает инциденты. Остальным обычно хватает обезличенных записей и метрик.

Если вы используете LLM-шлюз, смотрите не только логи приложения, но и логи самого шлюза. Важно, чтобы маскирование PII срабатывало до записи служебных событий, а не после. Есть и простой бытовой тест: попросите команду показать последний пример выгрузки для разбора ошибки. Если в нем виден сырой prompt с данными клиента, логирование к пилоту еще не готово.

Что проверить в бэкапах

О бэкапах часто вспоминают слишком поздно. Команда удаляет чувствительные данные из продовой базы, а через неделю находит те же записи в ночной копии, тестовом восстановлении или архиве у подрядчика.

Этот пункт нельзя считать формальностью. Если в запросах, логах или вложениях есть персональные данные, резервные копии тоже попадают в зону контроля.

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

Потом проверьте защиту копий. Шифрование должно работать и при передаче, и при хранении. Отдельно запросите список сотрудников и ролей, которые могут читать, скачивать и восстанавливать архивы. Если доступ слишком широкий, это уже плохой сигнал.

С местом хранения лучше не гадать. Попросите схему размещения и подтверждение, что копии остаются в российских ЦОДах, включая архивные и аварийные площадки. Если используете внешний шлюз или провайдера, это лучше проверять по договорным и техническим документам, а не по презентации.

Что спросить у поставщика

Можно ограничиться четырьмя вопросами. Какие данные входят в каждую резервную копию? Где физически лежат копии и архивы? Кто может восстановить данные и по какой заявке? Как команда удаляет данные из уже созданных бэкапов?

Отдельный тест нужен для удаления. Возьмите один тестовый набор с PII, проведите удаление по регламенту и проверьте, исчезли ли эти данные из новых копий, старых архивов и тестовых восстановлений. Многие команды проверяют только прод. Этого мало.

Что зафиксировать внутри команды

Запишите, кто запускает восстановление, кто согласует операцию, где остается след и как команда проверяет состав поднятых данных. Нормальная схема оставляет аудит-трейл: заявка, ответственный, время восстановления, контур, причина и результат проверки.

Если поставщик отвечает расплывчато или не показывает, как удаляет данные из копий, пилот лучше не начинать.

Как проверить маскирование PII и согласия

Маскирование должно срабатывать до отправки запроса в модель. Если номер карты или паспорт уже ушли во внешний API, поздняя очистка логов мало что исправит. Даже при работе через единый шлюз этот шаг лучше ставить в вашем приложении или на входном прокси, до вызова модели.

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

Проверьте хотя бы такие случаи: номер карты в слитном виде и с пробелами, паспортные данные в разных форматах, телефон с +7, 8 и без разделителей, email в обычной форме и с опечатками, а также фразы, где несколько типов PII встречаются сразу.

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

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

Нужен и понятный текст на случай, когда клиент пишет лишнее. Короткая фраза работает лучше длинного предупреждения: "Не отправляйте номер карты, паспорт и другие личные данные в чат. Если вопрос требует этих данных, мы переведем вас в защищенный канал".

Если согласия нет, решите это заранее, а не в день пилота. Рабочих вариантов обычно три: блокировать ввод с PII, пропускать только обезличенный запрос или переводить диалог сотруднику. Худший вариант - принять данные, а потом думать, что с ними делать.

Как собрать аудит-трейл без дыр

Аудит-трейл нужен не для отчета. Он должен отвечать на простой вопрос: кто отправил запрос, зачем, какие данные ушли в модель и что потом с этим запросом делали люди и системы.

Если через три месяца ИБ или юристы попросят поднять один спорный кейс, записи должны собрать картину без догадок. Фраза "примерно так работало" здесь не поможет.

Сначала фиксируйте контекст запроса: ID пользователя или сервиса, роль, систему-источник, бизнес-цель и время. Цель лучше брать из справочника, а не писать свободным текстом. Тогда вы быстро увидите, где был скоринг заявки, а где тест разработчика на боевых данных.

Потом сохраняйте техническую версию вызова: версию промпта, модель, провайдера, параметры вроде temperature и max tokens, а также правила маскирования, которые сработали перед отправкой. Если команда поменяла промпт в пятницу вечером, это должно быть видно в журнале, а не в переписке.

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

Отдельно логируйте ручные действия. Просмотр логов оператором, выгрузка в CSV, передача инцидента в ИБ, ручная разметка и удаление по регламенту должны оставлять след с именем сотрудника и причиной. Иначе самая слабая часть процесса окажется вне контроля.

Тихое редактирование аудит-трейла лучше запретить. Нужны только дописываемые записи, версии и отметка о том, кто внес изменение. Если платформа дает встроенные аудит-трейлы, это упрощает задачу, но принцип везде один: запись нельзя переписать задним числом, можно только добавить новое событие.

Простой тест перед пилотом: возьмите один запрос клиента и попробуйте восстановить его путь за 10 минут. Если команда не может сделать это без ручного поиска по пяти системам, в аудит-трейле уже есть дыра.

Как пройти проверку шаг за шагом

Проверку лучше вести не перепиской на две недели, а одной рабочей сессией на 60-90 минут. На ней должны быть владелец продукта, ИБ, юристы и закупка. Если хотя бы одна роль выпадает, команда почти всегда пропускает неприятные детали: где останутся логи, кто подпишет договор и как доказать маршрут данных.

Работать нужно не с абстрактным "чатом с ИИ", а с одним живым сценарием. Возьмите реальный путь запроса: поле ввода клиента, API-шлюз, модель, логирование, выгрузки в аналитику, бэкапы и архив. На каждом шаге ответьте на три вопроса: какие данные проходят, кто их видит и где они хранятся.

Рабочий порядок

1. Выберите один сценарий с риском выше среднего. Для банка это может быть обращение клиента в поддержку, для ритейла - поиск товара с историей заказа, для SaaS - тикет с данными аккаунта.
2. Пройдите весь путь руками. Смотрите не только на продовый контур, но и на тестовые среды, консоли провайдеров, алерты и резервные копии.
3. Зафиксируйте риски в таблице. У каждого пункта должен быть владелец, срок и статус.
4. Попросите поставщика ответить письменно по каждому спорному месту: где лежат логи и бэкапы, как работает маскирование PII, есть ли аудит-трейлы, кто имеет доступ и как это отражено в договоре.

Письменный ответ нужен по простой причине: он помогает, когда закупка сравнивает провайдеров, а ИБ просит доказательства вместо обещаний на звонке. Если поставщик работает через OpenAI-совместимый эндпоинт, этого недостаточно. Нужны точные ответы про хранение в РФ, обработку персональных данных и доступ к служебной информации.

Пилот не стоит запускать, пока не закрыты красные зоны. Красная зона - это не только явное нарушение. Достаточно одного неясного места, например непонятного хранения бэкапов или отсутствия аудит-трейла по запросам. Если по пункту нет владельца и даты закрытия, переносите старт.

Пример одного сценария для банка, ритейла и SaaS

Один и тот же риск выглядит по-разному в каждом продукте, но лечится почти одинаково. Пользователь присылает полезный текст для LLM, а вместе с ним - персональные данные, которые не должны попасть в лог, бэкап и служебные следы в открытом виде.

В банке клиент пишет в чат номер заявки, доход за месяц и короткий вопрос по статусу. Модуль перед отправкой в модель заменяет эти поля на метки вроде "[application_id]" и "[income]". Модель получает смысл запроса, но не видит исходные значения. В лог уходит уже очищенный текст, а не сырой ввод.

В ритейле картина похожая. Клиент отправляет адрес доставки, номер заказа и просит поменять время привоза. Для ответа модели не нужен полный адрес. Система может оставить город и тип запроса, а улицу, квартиру и номер заказа скрыть до записи в лог и до попадания в бэкап.

В SaaS риск часто прячется в тикетах. Пользователь копирует письмо из переписки, а там уже есть почта, имя коллеги и детали инцидента. Если команда просто отправляет весь текст в LLM API, она сама создает лишнюю проблему. Нормальный путь другой: парсер находит email и имена, заменяет их маркерами, а в аудит-трейле сохраняются request_id, время, версия промпта, факт маскирования и признак согласия, если он нужен для сценария.

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

Частые ошибки перед пилотом и закупкой

Многие команды смотрят на интерфейс, качество ответов и скорость, но не проверяют весь маршрут запроса. Это самая типичная ошибка. Данные уходят не только в модель, но и в API-шлюз, логи, мониторинг, очереди, бэкапы и иногда в систему поддержки. Если этой схемы нет на одном листе, проверка еще не закончена.

Другая проблема связана с поставщиком. Он может уверенно говорить о соответствии требованиям, но не показывать, где хранятся логи, кто имеет к ним доступ, как долго они лежат и что остается в резервных копиях. Для закупки таких обещаний мало. Если вы берете LLM API-шлюз, попросите показать маршрут одного запроса и пример аудит-трейла по нему.

Тестовые данные тоже подводят чаще, чем кажется. В пилот попадает выгрузка "для примера", а в ней уже есть живые телефоны, email, номера договоров или адреса доставки. В банке это может быть заявка клиента, в ритейле - история заказа, в SaaS - текст обращения в поддержку. Формально это уже обработка персональных данных, а не безобидный тест.

Согласие нередко живет только в договоре или общей политике, но продукт его не проверяет в момент запроса. Пользователь мог не дать согласие на такой канал, а система все равно отправляет его данные в LLM. Это видно только при проверке реальной логики, а не документов.

С удалением та же история. Команда чистит запись в продовой базе и считает задачу закрытой, но копии остаются в логах, кэше, векторном хранилище и бэкапах. Потом приходит запрос на удаление, а следы все еще лежат в нескольких местах.

Перед пилотом задайте четыре прямых вопроса: где лежат логи, бэкапы и аварийные копии; какие поля система маскирует до отправки запроса; как продукт проверяет согласие в момент обращения; что именно удаляется, если субъект просит стереть данные. Если на любой вопрос команда отвечает общими словами, пилот лучше не запускать.

Быстрая проверка перед стартом

Перед пилотом полезно прогнать один реальный сценарий целиком, а не проверять документы по отдельности. Такой проход часто снимает половину споров между ИБ, юристами и продуктовой командой за 15 минут.

Если у вас бот отвечает на обращения клиентов, возьмите один типовой запрос с ФИО, телефоном и номером заказа. Дальше проверьте не идеальную схему на слайде, а фактический путь данных: что уходит в модель, что пишется в логи, что попадает в бэкап и кто потом может это выгрузить.

Для старта достаточно убедиться в пяти вещах. Есть карта потока данных по одному живому сценарию. Для логов задан срок хранения и назначен тот, кто реально удаляет их по регламенту. PII убирается или маскируется до отправки запроса в модель. Платформа хранит логи и бэкапы в РФ, и это подтверждено договором и настройками. Аудит-трейл фиксирует доступ к данным, экспорт, смену промптов, маршрутизации и настроек.

На этом этапе слабые места становятся видны быстро. Очень часто проблема не в самой модели, а в том, что тестовый стенд пишет сырой prompt в debug-лог, а потом этот лог лежит месяцами.

Что сделать дальше

Не проверяйте все на вымышленном кейсе. Возьмите один реальный сценарий: диалог клиента с поддержкой банка, возврат заказа в ритейле или обращение из SaaS-кабинета. Пройдите его вместе с ИБ, владельцем продукта и инженером, который будет подключать API. Так вы быстро увидите, где появляются персональные данные, что уходит в модель и что система пишет в служебные записи.

Потом соберите ответы поставщика в один файл. Он нужен, чтобы закупка, аудит и команда смотрели на одну и ту же картину: где хранятся логи и сколько времени их держат, где лежат бэкапы и кто имеет к ним доступ, как сервис маскирует PII до отправки и в логах, что попадает в аудит-трейл по каждому запросу, какие согласия или внутренние основания нужны для вашего сценария.

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

Если вам нужен российский шлюз для LLM, такие пункты стоит сверить отдельно. У RU LLM, по данным сервиса, логи и бэкапы хранятся в РФ, маскирование PII и аудит-трейлы встроены в каждый запрос, а подключение идет через OpenAI-совместимый эндпоинт без смены SDK, кода и промптов. Это не отменяет вашу собственную проверку, но сильно сокращает список неизвестных перед пилотом.

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