Статей про нейросети и 152-ФЗ за последний год вышло много. Почти все написаны с одной из двух позиций: юрист объясняет состав нарушения, либо облачный провайдер объясняет, что нарушения не будет, если взять его облако.
Обе позиции полезные и обе останавливаются ровно там, где начинается моя работа. Юрист говорит «персональные данные не должны попасть к иностранному обработчику». Отлично. Теперь откройте код и покажите строчку, где они туда попадают. Обычно её не одна.
Сразу оговорка: я инженер, не юрист. Ниже нет правовых оценок и рекомендаций, что законно, а что нет — с этим к профильному специалисту. Ниже про то, как устроена система, в которой решение юриста можно выполнить технически, и в каких местах она обычно протекает.
Что технически считается «отдать данные в модель»
Формулировка «мы не отправляем персональные данные в ChatGPT» почти всегда означает «мы не отправляем туда поле ФИО». Отправляется при этом весь остальной объект.
Типовая история: компания подключает модель к разбору входящих обращений. В промпт уходит текст обращения. В тексте обращения — имя, номер телефона, адрес доставки, номер договора, иногда паспортные данные, потому что клиент их сам написал. Поле client_name при этом аккуратно вырезано.
Второй сюжет: модель подключают к базе знаний через RAG. Из базы поднимаются куски документов, куски уходят в контекст. В документах — переписка, акты, договоры. Никто не вырезал ничего, потому что «мы же просто ищем по своим документам».
Третий, самый обидный: данные до модели не доходят вообще, потому что запрос упал на валидации. Но полный текст запроса уже лёг в лог, лог уехал в внешний сервис сбора ошибок, и вот там он и живёт.
Три развилки, и у каждой своя цена
Дальше решение архитектурное, и вариантов ровно три. Смешивать их можно, но выбирать всё равно придётся по каждому потоку данных отдельно.
Не пускать персональные данные в модель. Обезличивание до вызова, работа с суррогатами, обратная подстановка после ответа. Самый дешёвый вариант по инфраструктуре и самый дорогой по инженерной аккуратности. Если получается — вопросы трансграничной передачи, поручения и локализации по этому потоку просто не возникают, потому что передавать нечего.
Российский провайдер модели. GigaChat, YandexGPT, модели через российские облачные платформы. Инфраструктурно почти бесплатно, договорную часть закрывает провайдер. Цена другая: вы привязываетесь к качеству и лимитам конкретной модели, и если ваш сценарий требует чего-то, чего она не умеет, переиграть будет уже дорого. Проверять это надо до внедрения, а не после.
Своя модель в своём контуре. Открытая модель на своём железе или в своём приватном облаке. Данные не покидают периметр вообще. Цена — эксплуатация: GPU, обновления, инференс-сервер, мониторинг, деградация под нагрузкой, и человек, который всё это держит. Для узкой задачи — классификация, извлечение полей, поиск — открытые модели давно достаточны, и вариант рабочий. Для «умного ассистента, который всё понимает» — обычно нет.
Я бы формулировал выбор так: чем уже задача, тем сильнее выигрывают второй и третий варианты. Чем шире и неопределённее — тем больше смысла вкладываться в первый, потому что он единственный не ограничивает вас в выборе модели.
Обезличивание, которое не делается регулярками
Первый вариант выглядит самым простым, пока не начнёшь его писать.
Регулярки ловят то, что имеет формат: телефон, email, номер карты, ИНН, серию паспорта. Это процентов шестьдесят проблемы и самая лёгкая её часть.
Не ловится всё остальное. Имя в середине предложения. Название компании, по которому клиент опознаётся однозначно. Адрес прописью. Номер заказа, по которому в вашей же базе поднимается всё остальное. Комбинация «город плюс должность плюс размер сделки», по которой человек вычисляется без единого прямого идентификатора.
Что работает на практике:
- Суррогаты вместо удаления. Не вырезать сущность, а заменить на стабильный токен:
PERSON_1,ORG_2,PHONE_1. Модель сохраняет связность текста — а она ей нужна, иначе качество падает — но настоящего значения не видит. После ответа подставляете обратно по карте замен, которая живёт только у вас. - Отдельный слой распознавания сущностей. Не регулярки, а NER-модель, работающая локально, до основного вызова. Да, это ещё одна модель в контуре. Зато она маленькая, живёт внутри и не отправляет никуда ничего.
- Белый список полей вместо чёрного. В промпт уходит только то, что явно разрешено. Это принципиально: чёрный список всегда отстаёт от реальности на одно новое поле, которое кто-то добавил в схему на прошлой неделе.
- Проверка на выходе. Перед отправкой прогоняете финальный payload через тот же детектор. Нашлось что-то похожее на ПД — запрос не уходит, инцидент в лог. Этот шаг кажется избыточным ровно до первого раза, когда он срабатывает.
Место, где течёт у всех
Теперь про то, чего нет ни в одной статье по теме, потому что писать про это некому: персональные данные утекают не в модель. Они оседают вокруг неё.
Логи. Отладочный вывод с полным телом запроса — самая частая находка. Ставится на первой неделе разработки, чтобы посмотреть, что уходит в модель, и остаётся навсегда. Если сбор ошибок настроен на внешний сервис, туда всё и уезжает.
Кэш. Кэширование ответов модели — правильная идея, она экономит заметные деньги. Но ключ кэша обычно собирается из запроса, а запрос содержит те самые данные. Я несколько лет занимался кэшированием на Redis с автоматической инвалидацией и могу сказать, что про содержимое ключа при проектировании не думает примерно никто: думают про инвалидацию.
Трассировки и мониторинг. Атрибуты спанов, теги метрик, сообщения об ошибках. Стек с исключением, в котором сериализован входной объект, — классика.
Аналитика промптов. Инструменты для отладки LLM-контуров пишут полный вход и выход, в этом их смысл. Где они это хранят — отдельный вопрос, который стоит задать до подключения, а не после.
Резервные копии. Обезличивание внедрили, старые бэкапы остались. Про них вспоминают последними.
Практический вывод простой: обезличивать надо не на границе с провайдером модели, а на границе с любым внешним получателем данных, включая ваш собственный сбор ошибок. Один слой, через который проходит всё, — дешевле пяти проверок в разных местах и, в отличие от них, не разъезжается через полгода.
Минимум, с которого стоит начать
Прежде чем выбирать модель и провайдера, я бы сделал две вещи.
Первая: составить карту потоков. Какие данные, откуда, в какой момент, кому уходят. Не в виде схемы на созвоне, а построчно по коду. В моей практике эта таблица регулярно оказывается интереснее самого внедрения, потому что показывает пару потоков, о которых не знал никто.
Вторая: определить, какие данные вообще нужны модели для решения задачи. Не «какие есть», а «какие нужны». Чаще всего для классификации обращения не требуется знать, кто его написал. Половина проблемы снимается на этом вопросе, и снимается бесплатно.
Дальше уже можно разговаривать про провайдера, контур и цену.
Стоит добавить, зачем всё это. Штрафы за нарушения в этой области с недавних пор считаются не десятками тысяч, а миллионами, а для повторных — процентом от оборота. То есть техническая аккуратность здесь впервые за долгое время дешевле последствий неаккуратности, и это редкий случай, когда инженерный аргумент и финансовый совпадают.
Отдельно замечу вещь, которая мне нравится в этой задаче. Разделение российского и глобального контуров я делал не для ИИ — тогда речь шла об обычной веб-инфраструктуре, окружениях, деплое и хранении. Работа была скучная. Но архитектура, которая получилась, оказалась ровно той, куда LLM-контур ложится без переделки: периметр уже нарисован, потоки уже разведены, места стыков уже известны. Это к вопросу о том, что под моделью всегда лежит обычный бэкенд, и качество этого бэкенда решает больше, чем выбор модели.
