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

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

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

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

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

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

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

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

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

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

С 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-ФЗ и о классификации ИСПДн; здесь мы её не повторяем.

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

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

Шлюз закрывает канал утечки в модель, но не заменяет базовое соответствие: если ИСПДн ещё не приведена в порядок, начинать нужно с неё — карта персональных данных, модель угроз и уровень защищённости. Как это устроено как работа, разобрано на странице приведение ИСПДн в соответствие 152-ФЗ.