Зачем это вообще
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-канал “Вкалывают роботы”.