LLM, персональные данные и 152-ФЗ

Зачем это вообще

LLM и агенты по типу Codex, Claude Code и т.д. изначально задумывались и использовались для работы с кодом.

Всё больше и больше модели и агенты используются для работы с договорами договорами, таблицами, отвечают на тикеты, разгребают почту, лезут в CRM. А там ФИО, телефоны, ИНН, паспорта. Как только ты отправил такие данные в модель — ты начал обрабатывать персональные данные и попал под 152-ФЗ.

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

Там куча нюансов. Например:

• ИНН — персональные данные. Сам по себе, без имени.

• База, которую легко выгрузить из ЕГРЮЛ, — всё равно твоя зона ответственности.

• Клиентская база в Google Sheets — нарушение, которое нельзя «дооформить».

• Галочка «согласен на обработку» при регистрации не закрывает отправку чужих данных в зарубежную модель.

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

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

Что такое персональные данные

Определение в законе короткое и резиновое. Персональные данные — любая информация, которая прямо или косвенно относится к человеку (ст. 3 152-ФЗ). Закрытого списка нет специально: данные делает персональными не тип, а возможность по ним выйти на конкретного человека.

Удобно делить всё на две группы.

Идентификаторы указывают на человека напрямую: ФИО, телефон, email, паспорт, СНИЛС, ИНН. Это персональные данные всегда.

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

Отдельно про ИНН, потому что это ломает интуицию. ИНН — персональные данные сам по себе, без имени. Это уникальный государственный идентификатор: по нему через открытые сервисы ФНС выходишь на конкретного человека. Та же логика, что с паспортом и СНИЛС. Нюанс: ИНН предпринимателя совпадает с ИНН физлица — это персональные данные. А ИНН компании (ООО) — нет, он про организацию.

Признаки опасны в совокупности. «Выпускник такого-то вуза 2008 года, главный сварщик единственного завода в городе N» — имени нет, а человек определяется однозначно. Это косвенная идентификация. Поэтому вопрос не «какой это тип данных», а «выводит ли это в этом контексте на конкретного человека».

Кроме этого, «Данные из открытого источника» != «можно что угодно». ФИО и ИНН предпринимателей лежат в ЕГРЮЛ, но это всё ещё персональные данные. Реестр открыт для проверки контрагентов, а не для того, чтобы ты собрал из него базу под рассылку. Утечёт такая база — отвечаешь ты, а не ЕГРЮЛ. То, что данные «и так публичные», от штрафа не спасает.

Правила: два уровня требований

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

Первый уровень — общий для всех:

• Основание обработки (ст. 6). Чтобы законно обрабатывать данные, нужно основание. Для сервиса это обычно не «согласие», а «исполнение договора» с клиентом: человек принял оферту — значит, обрабатывать его данные ради услуги можно без отдельной галочки. Согласие нужно для того, что выходит за рамки услуги: рассылки, передача партнёрам.

• Договор поручения (ч. 3 ст. 6). Если данные по твоему заданию обрабатывает кто-то ещё (облако, SaaS, модель) — с ним нужен договор поручения. Без него сама передача обработчику уже нарушение, ещё до всякой утечки.

• Локализация (ч. 5 ст. 18). Первичная запись данных о россиянах должна идти в базу на территории РФ. Нюанс для LLM: вызов модели — это обработка, а не хранение. Если первичная запись у тебя в российской базе, а в модель данные уходят на обработку — локализация не нарушается.

• Уведомление РКН (ст. 22). Ты оператор — уведоми регулятор, что обрабатываешь ПД.

Второй уровень — только при выходе за границу:

• Трансграничная передача (ст. 12). Отправка данных в зарубежный сервис — это трансграничная передача. Нужно отдельное уведомление РКН до начала.

• Адекватность страны. РКН делит страны на «адекватные» и нет (приказ №128). Китай в списке, США — нет. В адекватную можно передавать сразу после уведомления; в неадекватную — только через 10 рабочих дней и если РКН не запретит.

• Согласие на ТГП. Отдельный документ, не пункт в оферте. С сентября 2025 требования к форме жёстче.

Что будет, если нарушить

После 2024-2025 стало серьёзно.

Штраф за саму обработку с нарушением (ст. 13.11 КоАП) — десятки и сотни тысяч рублей по составам, и они складываются. Передал данные без основания, без договора и без уведомления — это не один штраф, а сумма.

Штраф за утечку (с 30 мая 2025) — отдельная история и считается по объёму: миллионы рублей в зависимости от числа пострадавших, за повторную утечку — оборотный штраф, процент от выручки. Плюс при утечке надо за 24 часа уведомить РКН и за 72 — отдать результаты расследования. Не уведомил — ещё один штраф.

Уголовка (ст. 272.1 УК, с конца 2024) карает незаконный оборот персональных данных, и отдельная часть — про трансграничную передачу, до 8 лет. В основном статья целится в тех, кто торгует ворованными базами. Если данные собраны легально, а ты нарушил процедуру передачи — базовый риск административный. Но при масштабе и систематичности грань размывается, поэтому списывать со счетов нельзя.

Точные суммы и части статей я округляю намеренно. Лучше свериться с актуальной редакцией.

Варианты: куда отправлять данные

Разберём по очереди: зарубеж в лоб, российское облако и своё железо. У каждого одна и та же развилка — данные идут с персоналкой или обезличенными. Обезличивание вынес в отдельную главу ниже, пока считаем, что данные настоящие.

Зарубеж в лоб: Claude, OpenAI, DeepSeek

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

• Локализация — выполнимо. Первичная запись у тебя в российской базе, в модель уходит копия на обработку. Не нарушено.

• Уведомление РКН о ТГП — выполнимо. Подаёшь до начала, это процедура.

• Адекватность страны — как повезёт. Китай (DeepSeek) в списке, передавать можно сразу после уведомления. США (OpenAI, Anthropic, Google) — нет: нужно ждать 10 рабочих дней, ждать не запретят ли.

• Согласие субъекта на ТГП — сложно, а на чужих данных невыполнимо. Если через модель идут данные самого клиента (он и есть субъект) — согласие взять можно, но не галочкой в оферте: нужен отдельный документ с получателем, страной и целью, его нельзя делать условием доступа, и его могут отозвать. А если в модель попадают данные третьих лиц — клиентов твоего клиента, его сотрудников, контрагентов — согласие за них дать некому. Плюс есть старая база.

• Договор поручения — невыполнимо. Публичный зарубежный API не подписывает договор по 152-ФЗ и не берёт обязательства российского закона. Это главный стоп, и он не лечится оформлением.

Главная проблема — договор поручения: публичный API его не даёт, и обойти нельзя. Поэтому с настоящими персональными данными путь не «рискованный», а нелегальный. Единственный вариант – обезличивание. Про него дальше.

• Плюс: лучшие модели, минимум возни.

• Минус: с персональными данными это прямое нарушение, которое нельзя закрыть оформлением.

Российское облако

Данные не покидают страну — весь верхний уровень отпадает: ни трансграничной передачи, ни согласия на неё, ни уведомления о ней. Остаётся только первый уровень, и он выполним.

• Договор поручения — выполнимо. Российское облако его даёт, обычно прямо в оферте.

• Локализация — выполнимо. Обработка и так в РФ.

• Основание обработки — выполнимо. Обычно «исполнение договора» с клиентом.

Дальше — два подвида.

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

Чужая open-source модель в РФ-облаке — DeepSeek, Qwen например на Yandex Cloud. Раз обработка идёт на серверах в России, а договор поручения у тебя с российским облаком — трансграничной передачи нет. «Китайская модель» здесь не равно «данные ушли в Китай».

• Плюс: легальный путь для настоящих персональных данных, без верхнего уровня.

• Минус: модели слабее топовых зарубежных; нужно проверить договор и аттестацию провайдера.

Своё железо

Модель крутится в твоём закрытом контуре, наружу ничего не уходит. Выполнять почти нечего из «трудного».

• Трансграничная передача — не применяется. Границы нет.

• Договор поручения — не нужен. Нет третьего лица: обработчик это ты сам.

• Локализация — выполняется сама. Всё в твоём контуре в РФ.

• Базовое остаётся: уведомление РКН (ст. 22) и меры защиты — это твоя зона.

Эталон для самого чувствительного.

• Плюс: максимальный контроль, минимальный юридический риск.

• Минус: нужны GPU и эксплуатация; локальные модели слабее облачных топов.

Обезличивание: главный приём

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

Идея простая: перед отправкой в модель находим в тексте персональные данные и заменяем их на заглушки. «Иван Петров, ИНН 770…» превращается в «NAME, INN». Модель работает с обезличенным текстом, а реальные значения подставляются обратно уже в ответе.

Но весь вопрос в том, насколько это «обезличивание» обратимо.

Обезличивание против псевдонимизации

Закон проводит черту (ст. 3 п. 9, плюс приказ РКН №140 с сентября 2025). Данные обезличены, только если без отдельного ключа восстановить личность нельзя — и этого ключа у получателя нет. Если ключ где-то лежит и связь восстановима — это псевдонимизация, а псевдонимизированные данные остаются персональными.

Поэтому важно не «заменили или нет», а что за заглушка и где живёт ключ. Тут есть спектр.

Стабильный токен из базы — худший случай. Если «Иван Петров» всегда превращается в user_8842, а где-то хранится таблица «user_8842 = Иван» — это псевдоним. Мало того что ключ хранится, так ещё и сам токен становится идентификатором: по нему можно связывать запросы и копить профиль. Это персональные данные.

Эфемерная generic-замена — лучший случай. Заглушка не уникальна: имя становится просто NAME, СНИЛС — SNILS, и так у всех. NAME для Вани и для Саши — одно и то же, в нём ноль информации о человеке. Маппинг «заглушка → оригинал» живёт только в оперативной памяти на время одного запроса, в РФ, и стирается после ответа. Получатель за границей видит обезличенный текст и физически не может восстановить, кто это.

Разница принципиальная. Стабильный токен — псевдоним, по которому человека опознают. Generic-заглушка ближе к зачёркиванию: «здесь было имя». Поэтому эфемерный режим — единственный, где можно всерьёз спорить, что за границу ушли не персональные данные.

Важная оговорка: Российская практика по такому маскированию пока не сложилась и возникает вопрос в интерпретации того или иного решения от регулятора.

Чего маскирование не лечит

Даже идеальная замена прямых идентификаторов оставляет две дыры.

Контекст. Детектор вычищает имена, телефоны, номера — но не текст вокруг. «NAME, главный сварщик единственного завода в городе N, оборот SNILS» — все прямые данные скрыты, а человек опознаётся по описанию. Это косвенная идентификация, и она уезжает за границу в открытом виде.

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

Как маскировать?

Есть 2 варианта: у себя в контуре или на стороне облачного прокси-посредника.

Свой контур. Ставишь детектор персональных данных перед вызовом модели. Оригиналы, карта замен и ключ не покидают периметр — наружу уходит уже обезличенный текст. Бонус — полный контроль: сам крутишь пороги, ловишь сомнительное, держишь поведение fail-closed (детектор не сработал или упал — запрос не уходит) и блокируешь не только персоналку, но и коммерческую тайну.

Из чего собрать. Базовый каркас на опенсорсе — Microsoft Presidio (находит и заменяет сущности) плюс русский NER для имён и организаций (Natasha, DeepPavlov или spaCy). Но из коробки ни один западный инструмент не знает российских идентификаторов — СНИЛС, ИНН, ОГРН, паспорт. Их добавляешь сам. Для структурированных номеров это надёжно: у СНИЛС, ИНН, ОГРН есть контрольные суммы, и regex плюс проверка контрольного числа дают почти нулевой процент ошибок. Слабое звено — имена и организации: русский NER ловит их вероятностно, отсюда и нужен fail-closed.

Это не коробка, а сборка: распознаватели написать, NER подобрать, пороги настроить. Зато всё под твоим контролем.

Облачный прокси-посредник. Сервисы вроде KodikRouter, ProxyAPI, Jay Guard встают между тобой и зарубежной моделью и маскируют на лету. Удобно и быстро, но есть важная развилка.

Важно чтобы посредник реально обезличивал а не просто проксировал. Если посредник реально вычищает персоналку до границы — ок. Если просто проксирует сырые данные, это тот же «зарубеж в лоб», только через российское юрлицо: договор поручения с посредником есть, но конечный OpenAI его всё равно не подписывал, и дыра на месте.

Итого

Сводим всё в один принцип — маршрут по тому, есть ли в запросе персональные данные.

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

• Есть настоящие персональные данные — только российский контур: российское облако с договором поручения или своё железо. Зарубеж в лоб закрыт.

• Особо чувствительное (здоровье, тайны, большие объёмы) — своё железо или изолированный контур, без внешних API вообще.

---

Если хотите разбираться глубже в том, как использовать LLM и AI-агентов в продуктивности, работе, бизнесе и повседневной жизни — подписывайтесь на наш Telegram-канал “Вкалывают роботы”.