Чек-лист 152-ФЗ для LLM-сервиса перед первым запуском

Почему запуск стопорится на персональных данных

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

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

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

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

Даже хороший чек-лист 152-ФЗ для LLM-сервиса сам по себе ничего не решает, если у решения нет владельца. Запуск не должен одобрять один разработчик или только менеджер продукта. Решение обычно принимают вместе технический владелец сервиса, ИБ, юрист или privacy-специалист и бизнес-владелец процесса, который понимает, зачем сервису вообще нужны эти данные.

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

Какие данные проходят через сервис

В чек-листе 152-ФЗ для LLM-сервиса многие команды смотрят только на текст запроса. Этого мало. Через сервис проходят не только сообщения из чата, но и служебные поля, вложения, метаданные, ошибки и следы отладки.

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

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

Быстрый тест выглядит просто: возьмите один реальный сценарий и пройдите его по шагам. Например, оператор поддержки открывает карточку клиента, пишет вопрос в чат, прикладывает PDF и нажимает отправить. После этого нужно увидеть, какие данные попали в приложение, в API-шлюз, в модель и в ответ.

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

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

Где хранятся логи и бэкапы

Для 152-ФЗ мало знать, что у сервиса есть логи и резервные копии. Нужно знать, где они лежат физически. Если основная база стоит в РФ, а бэкап уезжает в зарубежное облако по настройке "по умолчанию", это уже слабое место.

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

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

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

Полезно пройти по цепочке руками. Откройте схему обработки запроса и отметьте все места, где появляется запись: API-шлюз, приложение, очереди, APM, SIEM, helpdesk, BI и песочницы аналитиков. У каждой точки должен быть понятный ответ на три вопроса: зачем она хранит данные, как долго и кто это контролирует.

Если вы используете прокси вроде RU LLM, этот вопрос нужно закрыть и на стороне провайдера. В RU LLM логи и бэкапы хранятся на серверах в РФ. Но даже в таком случае команде стоит проверить свои внутренние копии. Обычно именно они остаются вне общего контура и потом создают проблемы.

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

Как закрыть PII до запроса в модель

Модели редко нужен сам человек. Им нужен смысл запроса. Если пользователь пишет: "Иван Петров, договор 45821, мой телефон 8...", то для ответа модели обычно хватает такого вида: "[CLIENT_NAME], договор [CONTRACT_ID], телефон [PHONE]". Сначала отделите данные, без которых ответ не меняется, от данных, которые реально нужны для задачи.

Обычно в первую очередь скрывают ФИО, телефон, email, номер договора, адрес и любые свободные поля, где человек мог указать паспорт, ИНН или дату рождения. Один и тот же тип данных лучше заменять одинаково в пределах одной сессии. Тогда модель не теряет нить разговора и понимает, что [CLIENT_NAME] из первого сообщения и [CLIENT_NAME] из второго - это один и тот же человек.

Где ставить маскирование

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

На практике команды часто делают два слоя. Клиент убирает очевидные поля, а шлюз повторно проверяет запрос. Если вы используете единый LLM-шлюз, например RU LLM, это особенно удобно: политика маскирования PII может идти вместе с маршрутизацией запросов и не расползаться по разным сервисам.

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

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

Кто и что видит внутри команды

Проблемы с 152-ФЗ часто начинаются не в модели, а внутри команды. Если у нескольких человек есть полный доступ к логам, промптам и тестовым наборам, риск уже слишком высокий.

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

Минимальная схема ролей

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

Такой порядок в начале чуть менее удобен. Зато потом он избавляет от неприятных вопросов на внутренней проверке и от лишнего ручного разбора инцидентов.

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

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

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

Как вести аудит-трейлы без лишнего шума

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

Для чек-листа 152-ФЗ для LLM-сервиса лучше собирать меньше событий, но делать каждую запись понятной. Один запрос - одна проверяемая запись. У нее должен быть request_id, автор запроса и понятный сценарий: поддержка, поиск по базе знаний, внутренний ассистент, обработка заявки.

Что писать в журнал

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

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

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

Как не утонуть в событиях

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

Пример простой. Оператор поддержки отправил вопрос клиента в LLM, а система перед этим скрыла телефон и номер договора. В аудит-трейле должны остаться роль оператора, сценарий вызова, версия правила маскирования, модель, провайдер и время запроса. Если команда использует единый шлюз вроде RU LLM, такой формат проще держать одинаковым для разных моделей и провайдеров.

Порядок запуска по шагам

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

Дальше лучше идти по короткой и жесткой последовательности:

1. Соберите 10-15 реальных примеров запросов и ответов. На них быстро видно, где PII проскакивает в промпт, системные сообщения или трассировки.
2. Включите маскирование до отправки в модель и проверьте его руками. Смотрите не только на отдельные поля, но и на фразы вроде "позвоните мне по номеру..." или "мой адрес...".
3. Проверьте, где живут логи, дампы, кэши и резервные копии. Часто сама модель находится в одном месте, а логи по умолчанию уходят в другой сервис.
4. Раздайте доступ по минимуму. Разработчику редко нужен полный просмотр сырых диалогов, а оператору поддержки не нужен экспорт журналов.
5. Проведите пробный запуск на ограниченном трафике и разберите каждый спорный случай: кто увидел данные, что записалось в аудит, можно ли это объяснить проверяющему.

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

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

Пример: чат для клиентской поддержки

Представьте чат банка или SaaS-сервиса. Клиент пишет: "Не могу продлить договор 458921, списание прошло дважды". Оператору нужен ответ быстро, но в запрос к модели нельзя отправлять все подряд.

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

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

До маскировки в сыром запросе могут быть договор 458921, телефон, почта и фраза оператора из CRM. После маскировки в логе должно остаться что-то вроде: "договор [CONTRACT_ID]", "телефон [PHONE]", "email [EMAIL]". Смысл сохраняется, а лишние персональные данные не лежат в истории в открытом виде.

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

Отдельный вопрос - кто поднимет историю ответа, если клиент оспаривает результат. Оператору первой линии обычно хватает текста ответа и ID запроса. Руководитель смены может видеть цепочку сообщений без открытых PII. Полную историю доступа стоит оставить очень узкому кругу: службе ИБ, владельцу процесса и сотруднику, который отвечает за персональные данные. Каждый просмотр лучше писать в аудит-трейл: кто открыл запись, когда и по какой причине.

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

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

Даже аккуратный чек-лист 152-ФЗ для LLM-сервиса часто срывается на мелочах. Обычно проблема не в модели, а в том, как команда собирает, хранит и показывает данные внутри своей системы.

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

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

Часто промахиваются и с правами доступа. Аналитику редко нужен тот же доступ, что у инженера поддержки или администратора. Подрядчику тем более не нужно видеть исходные обращения клиентов, если ему хватает обезличенной выборки. Один общий уровень доступа для всех - плохая идея, даже если команда маленькая.

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

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

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

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

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

Это и есть рабочий чек-лист 152-ФЗ для LLM-сервиса - не теория, а несколько пунктов, которые нужно подтвердить руками.

• Нарисуйте простую схему движения данных. Пользовательский ввод, pre-processing, вызов модели, логи, бэкапы и архивы - у каждого шага должен быть понятный владелец и место хранения.
• Проверьте контур хранения. Если система пишет логи запросов, ответов и ошибок, а также резервные копии, все это должно лежать в согласованной инфраструктуре в РФ, а не в случайных сервисах по настройке "по умолчанию".
• Убедитесь, что маскирование PII срабатывает до отправки в модель и что одинаковые сущности заменяются одинаково хотя бы в рамках одной сессии.
• Пересмотрите роли доступа. Кто видит сырые данные, кто работает только с масками, кто может менять правила логирования и кто отвечает за аудит.
• Прогоните один реальный сценарий целиком и поднимите все следы запроса: что ушло в модель, что осталось в логах, кто получил доступ и можно ли это быстро объяснить на проверке.

Если хотя бы на один пункт команда отвечает расплывчато, лучше остановиться и исправить схему до пилота.

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

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

Для чек-листа 152-ФЗ для LLM-сервиса это особенно полезно. У юристов, безопасности, разработки и продукта часто оказываются разные версии одной и той же настройки. Один документ убирает лишние споры перед запуском.

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

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

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

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

Если вам нужен OpenAI-совместимый эндпоинт внутри РФ, сравнивайте по простым вопросам: нужно ли менять код, где лежат логи и резервные копии, как маскируются персональные данные, есть ли аудит по каждому запросу и как разделены роли доступа. Например, RU LLM на rullm.com дает OpenAI-совместимый API-шлюз, где команда может менять только base_url и продолжать использовать прежние SDK, код и промпты. При этом логи и бэкапы остаются в РФ, а маскирование PII и аудит-трейлы встроены в каждый запрос.

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