# ИИ-агенты и 152-ФЗ: как не отдать персональные данные в LLM

Canonical: https://www.kt-team.ru/blog/ii-agenty-152-fz

Source: https://www.kt-team.ru/blog/ii-agenty-152-fz

24.07.2026

## Главное

- **ПДн попадают в LLM не из базы, а из промпта.** Четыре типовых канала: тикет с ФИО клиента, выгрузка CRM в контекст, транскрипт звонка, резюме кандидата.
- **Шлюз обезличивания даёт проверяемую границу.** ПДн заменяются токенами до отправки и восстанавливаются в ответе — провайдер модели и его логи видят только обезличенный текст.
- **Контур выбирают по данным.** Прямой API — только для текста без ПДн; шлюз + облако — для рабочих процессов; локальная модель — для данных, которые не должны покидать периметр.
- **Штрафы стали оборотными.** С 30.05.2025 повторная утечка стоит 1–3% годовой выручки (от 20 до 500 млн ₽), неуведомление об инциденте — отдельный состав (закон № 420-ФЗ).
- **Это инженерная рамка, не юрзаключение.** Статья показывает, какие технические меры снимают риск и какие вопросы закрыть с юристом до запуска агента.

## Где ИИ-агент отдаёт ПДн в LLM

152-ФЗ регулирует не «использование ИИ», а обработку персональных данных — сведений, которые прямо или косвенно идентифицируют человека. Поэтому первый инженерный вопрос при запуске ИИ-агента — не «можно ли нам LLM», а «какие поля процесса — ПДн и в какой момент они оказываются в промпте». Как под этот scope выбирать саму модель — отдельный разбор в статье [о зарубежных LLM под 152-ФЗ](/blog/zarubezhnye-llm-pod-152-fz).

Канал первый — промпт оператора или агента. Сотрудник поддержки вставляет в запрос тикет целиком: ФИО, телефон, номер договора. Агент делает то же автоматически, когда собирает контекст задачи из карточки клиента. Один запрос — один субъект ПДн, но таких запросов тысячи в месяц.

Канал второй — выгрузка CRM в контекст. Чтобы агент «знал клиентов», ему передают сегмент базы: историю заказов с именами и контактами. Один такой промпт — уже не единичный субъект, а сотни или тысячи записей. Именно объём затронутых субъектов определяет категорию штрафа при утечке.

Канал третий — транскрипты звонков. Записи разговоров с клиентами уходят в модель для саммари или контроля качества. В расшифровке — ФИО, телефоны, адреса доставки, а иногда и сведения о здоровье или финансах, которые закон защищает строже обычных ПДн.

Канал четвёртый — резюме и анкеты. HR-агент, который ранжирует кандидатов, работает с концентратом ПДн: контакты, даты рождения, места работы. Тот же риск создают ИИ-функции внутри SaaS-сервисов, включённые «по умолчанию», — контур компании их не видит.

Передача такого текста в облачную LLM — это обработка ПДн с участием третьего лица. Отсюда вопросы, которые закрываются до запуска, а не после: основание обработки и поручение обработки (ч. 3 ст. 6 152-ФЗ), локализация первичного сбора в российской базе (ч. 5 ст. 18; с 01.07.2025 первичный сбор через зарубежные базы прямо запрещён), а для зарубежных API — уведомление Роскомнадзора о трансграничной передаче до её начала (ст. 12).

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

## Архитектура: шлюз между агентом и моделью

Приложение → шлюз (обезличивание, политики, журнал) → LLM (облачная или локальная) → обратная подстановка в ответе. Ветки отказа: прямой вызов API в обход шлюза (ПДн в промпте и логах провайдера), теневой ИИ (личный ChatGPT сотрудника — контур не видит и не журналирует), логи вендора (история запросов у провайдера — вне вашего контроля и ретенции).

## Как эту схему закрывает LLM & Security Gateway

[LLM & Security Gateway](/instruments/llm-gateway) реализует схему как отдельный компонент: шлюз и карта обезличивания разворачиваются в периметре заказчика, а приложения переключаются на него сменой base URL — эндпоинт совместим с форматом OpenAI, клиентский код не переписывается. Обезличивание работает на уровне каждого вызова, поэтому защищает и одиночные запросы, и многошаговые агентные цепочки с RAG.

Ключи провайдеров хранятся в самом шлюзе, командам выдаются виртуальные ключи с мгновенным отзывом — это закрывает ветку «в обход шлюза»: у приложений и сотрудников прямых ключей нет. Каждый запрос журналируется с моделью, объёмом токенов и стоимостью. Тот же принцип на уровне одной системы показывает [security gate ИИ-агента для 1С](/product-pages/ai-agent-1c): модель не подключается к базе напрямую, а действует через проверяемые инструменты с контролем прав.

## Три контура работы с LLM: что допустимо в каждом

Контур выбирают по данным процесса, а не по моде. Стоимость в таблице качественная: рублёвые порядки под вашу конфигурацию считает [калькулятор ИИзации](/solutions/ai-for-business#ai-calc), а место шлюза в смете агента разобрано в статье [о стоимости ИИ-агента](/blog/skolko-stoit-ii-agent).

| Контур | Какие данные допустимы | Ключевые риски | Стоимость (качественно) |
| --- | --- | --- | --- |
| Прямой вызов облачного API | Только текст без ПДн: регламенты, код, обезличенная статистика | ПДн в промптах и логах провайдера; трансграничная передача без уведомления; нет журнала — инцидент нечем расследовать | Минимальная на старте: только токены |
| Шлюз + облачная модель | Рабочие процессы с ПДн: тикеты, CRM, транскрипты — наружу уходит обезличенный текст | Пропуск детектора ПДн — инцидент; карта соответствия — защищаемый актив в РФ-контуре | Токены плюс внедрение и эксплуатация шлюза — отдельная строка TCO |
| Локальная модель | Данные, которые не должны покидать периметр даже обезличенными: спецкатегории, охраняемые тайны | Капзатраты на GPU и команду; качество ниже фронтир-моделей; экономику решает утилизация железа | Максимальная: железо, инфраструктура, эксплуатация |

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

## Оборотные штрафы: почему «мы никому не скажем» — не стратегия

С 30 мая 2025 года действуют поправки закона № 420-ФЗ от 30.11.2024 в ст. 13.11 КоАП. Утечка ПДн 1–10 тыс. субъектов стоит юрлицу 3–5 млн ₽, свыше 100 тыс. — 10–15 млн ₽, утечка биометрии — 15–20 млн ₽. Повторная утечка переводит штраф в оборотный: 1–3% годовой выручки, от 20 до 500 млн ₽. Неуведомление Роскомнадзора об инциденте — отдельный состав, 1–3 млн ₽; работа без уведомления о начале обработки — 100–300 тыс. ₽.

Параллельно закон № 421-ФЗ от 30.11.2024 ввёл в Уголовный кодекс ст. 272.1 — ответственность за незаконный оборот ПДн, где трансграничная передача названа отягчающим обстоятельством. Полная юридическая база — обязанности оператора, документы, уровни защищённости — разобрана в статьях [об обработке ПДн по 152-ФЗ](/blog/152-fz-personal-data-processing) и [о классификации ИСПДн](/blog/personal-data-security-system-152fz-guide); здесь мы её не повторяем.

Стратегия «мы просто никому не скажем» ломается о механику закона. Оператор обязан уведомить Роскомнадзор об инциденте в течение 24 часов и отчитаться о результатах расследования за 72 часа (ч. 3.1 ст. 21); молчание — отдельный штраф поверх самой утечки. И утечки всплывают извне — в продаваемых базах и мониторинге регулятора, а не только из ваших отчётов.

Для ИИ-контура есть и третья причина. Без шлюза и журнала компания сама не знает, что ушло в модель: нечем ни доказать, что ПДн наружу не уходили, ни оценить объём инцидента. Журнал запросов — не бюрократия, а единственный ответ на вопрос «какие данные покидали контур» — и при инциденте, и при проверке.

## Что закрыть до запуска агента с доступом к клиентским данным

- Карта ПДн процесса составлена: какие поля попадают в промпты, контекст и логи и сколько субъектов затрагивает один запрос и весь поток.
- Контур выбран по данным и зафиксирован письменно: прямой API — только без ПДн, шлюз — для рабочих процессов, локальная модель — для того, что не выходит из периметра.
- Шлюз — единственный маршрут к моделям: прямые ключи провайдеров у приложений отозваны, детектор ПДн проверен на ваших данных, а не на демо-примерах.
- Теневой ИИ закрыт не запретом, а альтернативой: сотрудникам доступен корпоративный контур, личные аккаунты для рабочих данных исключены политикой и техникой.
- Юридические вопросы закрыты с юристом: основание обработки, поручение по ч. 3 ст. 6, локализация первичного сбора, уведомление о трансграничной передаче по ст. 12.
- Журналирование включено и защищено: запрос, применённая политика, маскированные сущности, модель и ответ — в РФ-контуре, с ретенцией и минимизацией ПДн в самом журнале.
- Процедура инцидента отрепетирована: кто в течение 24 часов уведомляет Роскомнадзор и кто готовит отчёт о расследовании за 72 часа.
- Память агента, кэш и RAG-индексы проверены: реальные ПДн не оседают в векторной базе, few-shot-примерах и истории диалогов.

## Когда хватает обезличивания, а когда нужна локальная модель

Обезличивание закрывает случаи, когда ПДн — вкрапление в тексте, а не предмет задачи: тикет, письмо, транскрипт. Модель работает со смыслом обращения, реальные имена и телефоны ей не нужны — их заменяют токенами без потери качества. Локальная модель нужна, когда задача построена на данных конкретного человека (скоринг клиента, работа с медкартой), когда в потоке спецкатегории и охраняемые тайны или когда риск-профиль не допускает передачу наружу даже обезличенного текста. Это расчёт, а не вера: сопоставьте классы данных с контурами из таблицы и посчитайте стоимость в [калькуляторе ИИзации](/solutions/ai-for-business#ai-calc).

## Частые вопросы об ИИ-агентах и 152-ФЗ

**Можно ли отправлять данные клиентов в ChatGPT или Claude?**
В исходном виде — это передача ПДн внешнему провайдеру со всеми вопросами поручения, локализации и трансграничной передачи; их квалифицирует юрист. Инженерный путь — контур, в котором наружу уходит обезличенный текст: тогда спор «можно или нельзя» превращается в проверяемое «что именно уходит». Механика — на схеме выше.

**Что такое обезличивание и снимает ли оно требования 152-ФЗ?**
Обезличивание заменяет идентифицирующие поля так, что без отдельно хранимой карты соответствия текст не привязать к человеку. Для оператора обработка ПДн продолжается: требования 152-ФЗ к компании не исчезают, а карта соответствия сама становится защищаемым активом. Снимается конкретный риск: провайдер модели и его логи не получают ПДн. С 01.09.2025 требования к обезличиванию дополнительно задаёт закон № 233-ФЗ.

**Локальная модель решает всё?**
Нет. Она снимает передачу данных третьему лицу, но не отменяет 152-ФЗ внутри компании: основания обработки, защита ИСПДн, разграничение доступов и журнал нужны так же — уровни защищённости разобраны в [отдельной статье](/blog/personal-data-security-system-152fz-guide). Добавляются капзатраты на GPU и разрыв в качестве с фронтир-моделями, поэтому локальный контур — осознанный выбор под класс данных, а не ответ по умолчанию.

**Нужно ли согласие субъекта на обработку данных ИИ-агентом?**
152-ФЗ не выделяет «обработку ИИ» в отдельный режим — действуют общие основания ст. 6, и согласие лишь одно из них. Подходит ли вашему потоку договорное основание и надо ли обновлять политику обработки и текст согласия — вопросы юристу, с картой ПДн процесса на руках. Инженерная сторона того же вопроса — минимизация: чем меньше ПДн реально уходит в модель, тем короче список оснований, которые придётся защищать.

**Что журналировать в контуре ИИ-агента?**
Минимум: кто вызвал, какая политика применена, какие сущности замаскированы, какая модель ответила, объём токенов и время. Сам журнал держите в защищённом РФ-контуре и минимизируйте в нём ПДн, иначе журнал становится ещё одной ИСПДн. Такой след отвечает на оба вопроса проверки: «что уходило наружу» и «кто имел доступ».

**Сотрудники уже пользуются личным ChatGPT — что делать?**
Запрет без альтернативы не работает: задачи никуда не деваются, поток просто уходит в тень. Рабочая связка — корпоративный доступ к моделям через шлюз (та же скорость, но с обезличиванием и журналом) плюс политика, закрывающая личные аккаунты для рабочих данных. Когда легальный путь удобнее, теневой ИИ перестаёт быть массовым.

## Проверить LLM-контур до запуска агента

Покажите один процесс с клиентскими данными. Разберём его на карту ПДн, контур инференса, шлюз, журнал и список вопросов для вашего юриста — до того, как агент получит доступ к данным. Как устроен шлюз — на странице [LLM & Security Gateway](/instruments/llm-gateway).

## Источники

Дата проверки: 24.07.2026

- 152-ФЗ «О персональных данных», ст. 6 — условия обработки, поручение обработки (КонсультантПлюс): https://www.consultant.ru/document/cons_doc_LAW_61801/315f051396c88f1e4f827ba3f2ae313d999a1873/
- 152-ФЗ, ст. 12 — трансграничная передача, уведомление Роскомнадзора до начала (КонсультантПлюс): https://www.consultant.ru/document/cons_doc_LAW_61801/e4ebbe1780de623c7cf32a59ca82a7bb523a25dd/
- 152-ФЗ, актуальная редакция — ст. 18 (локализация), ст. 21 (уведомление об инциденте: 24/72 часа): https://www.consultant.ru/document/cons_doc_LAW_61801/
- КоАП РФ, ст. 13.11 в редакции закона № 420-ФЗ от 30.11.2024 (КонсультантПлюс): https://www.consultant.ru/document/cons_doc_LAW_34661/1f421640c6775ff67079ebde06a7d2f6d17b96db/
- КонсультантПлюс — обзор «Персональные данные: новые штрафы с 30 мая 2025 года»: https://www.consultant.ru/legalnews/28492/
- Федеральный закон от 28.02.2025 № 23-ФЗ — запрет первичного сбора ПДн через зарубежные БД с 01.07.2025: http://publication.pravo.gov.ru/document/0001202502280034
- Федеральный закон от 08.08.2024 № 233-ФЗ — обезличенные персональные данные, с 01.09.2025 (Гарант): https://base.garant.ru/409493125/
- b-152.ru — закон о ПДн 2025–2026: 420-ФЗ, 421-ФЗ, ст. 272.1 УК: https://b-152.ru/zakon-o-personalnyh-dannyh-2025
- 152-audit.ru — таблица штрафов по ст. 13.11 КоАП (2026): https://152-audit.ru/shtrafy
- Роскомнадзор — портал уведомлений о трансграничной передаче ПДн: https://pd.rkn.gov.ru/cross-border-transmission/