До 2025 года штрафы за нарушения в области персональных данных были величиной, которую крупная компания могла считать издержкой. Сейчас это не так.
С 30 мая 2025 года действуют поправки, введённые Федеральным законом № 420-ФЗ от 30.11.2024: ответственность за утечки дифференцирована по объёму, а за повторное нарушение введены оборотные штрафы — процент от годовой выручки. Параллельно Федеральный закон № 421-ФЗ ввёл в Уголовный кодекс статью 272.1 об ответственности за незаконный оборот персональных данных.
Для проектов с ИИ это существенно, потому что такие системы обрабатывают данные в новых местах: в запросах к модели, в журналах, в индексах для поиска.
Оговорка: я не юрист. Ниже — общая картина и то, что можно сделать технически. Правовую оценку и квалификацию даёт юрист; размеры и составы стоит сверять с действующей редакцией КоАП.
Что изменилось
| Что | Как стало |
|---|---|
| Дифференциация | ответственность зависит от числа субъектов и идентификаторов в утечке |
| Первое нарушение | значительные суммы, растущие с объёмом утечки |
| Повторное нарушение | оборотный штраф: 1–3% годовой выручки, до 500 млн ₽ |
| Для банков | процент считается от размера собственных средств |
| Уголовная ответственность | ст. 272.1 УК за незаконные сбор, хранение, использование, распространение ПД |
Ключевое изменение — не размер, а принцип. Оборотный штраф означает, что цена нарушения масштабируется вместе с бизнесом, и для крупной компании она перестаёт быть предсказуемой строкой расходов.
Второе по важности — уголовная ответственность. Она адресована физическим лицам, и это меняет отношение к вопросу у конкретных сотрудников.
Где риск возникает в проектах с ИИ
Системы с моделями создают новые места, где персональные данные оказываются вне привычного контура.
В запросах к внешней модели. Текст уходит поставщику — «Можно ли передавать персональные данные в нейросеть».
В журналах. Запросы и ответы записываются для диагностики и часто хранятся дольше и доступны шире, чем исходные данные. Один из самых недооценённых каналов.
В индексе для поиска. Документы разрезаны на фрагменты и лежат в отдельном хранилище со своими правами доступа — «Разграничение доступа в RAG».
В выгрузках для проверки качества. Наборы реальных случаев, собранные для тестирования, — это те же данные в ещё одном месте.
В дообученной модели. Если модель обучалась на данных, они могут воспроизводиться в ответах, и разграничить доступ невозможно.
У сотрудников. Публичные сервисы, куда вставляют документы, — «Утечка данных через нейросеть».
Что снижает риск технически
Меры, которые находятся в зоне подрядчика по ИИ, а не юриста.
Не передавать лишнего. Пересмотр состава запроса: часто персональные данные попадают в модель без необходимости. Самая дешёвая мера и самая результативная.
Обезличивание перед отправкой во внешнюю модель, с измеренной долей пропусков — «Обезличивание данных».
Локальное размещение там, где данные не должны покидать контур — «Локальное развёртывание LLM».
Ограничение доступа к журналам и срок хранения. Обезличивание при записи, если полный текст не нужен.
Фильтрация по правам при поиске, а не инструкцией модели.
Журналирование обращений к данным: кто, что и когда запрашивал. Нужно и для разбора инцидента.
Порядок действий при инциденте, известный сотрудникам заранее. Сроки уведомления регулятора исчисляются часами, и разбираться в этот момент поздно.
Последний пункт — организационный, но он определяет, во что превратится инцидент.
Что относится к юристу
Разделение зон здесь важно.
К юристу: правовые основания обработки, оформление политики и согласий, оценка достаточности принятых мер, порядок уведомления регулятора, квалификация произошедшего, взаимодействие при проверке.
Ко мне как к подрядчику по ИИ: где физически находятся данные, что уходит наружу, кто имеет доступ, что записывается в журналы, какова измеренная доля пропусков при обезличивании.
Полезная практика: подготовить для юриста техническое описание — какие данные, куда, зачем, кто видит, сколько хранится. С таким описанием он даст ответ по существу; на вопрос «мы используем ИИ, всё в порядке?» содержательного ответа не бывает.
Разбор: проверка перед запуском
Задача. Компания собиралась запускать ассистента поддержки, работающего с обращениями клиентов. Перед запуском провели проверку.
Что нашли.
Данные передавались российскому поставщику по корпоративному договору, запросы для обучения не использовались. Здесь всё было в порядке.
Журнал диалогов хранился бессрочно и был доступен всей группе разработки — шире, чем исходная система, из которой брались данные. В журнале лежали полные тексты обращений с контактами.
Набор для проверки качества — 200 реальных обращений — лежал в общей папке проекта.
Порядка действий при инциденте не было. На вопрос «что делать, если данные утекли» ответа не нашлось ни у кого.
Что сделали.
Ограничили доступ к журналу до тех, кому он нужен, и установили срок хранения. Полные тексты стали обезличиваться при записи, а идентификаторы для диагностики хранились отдельно.
Проверочный набор обезличили — для оценки качества классификации имена и телефоны не требовались.
Написали короткий порядок действий при инциденте: кто уведомляет, кого, в какие сроки, что фиксировать. Полторы страницы.
Пересмотрели состав запроса: в модель стал уходить текст обращения без карточки клиента.
Что стоит отметить. Ни одна из мер не потребовала серьёзных вложений. Самая трудоёмкая — обезличивание — заняла несколько дней. Все они были сделаны до запуска, когда это дёшево; после инцидента те же меры делаются в спешке и уже не помогают.
Что стоит забрать. Проверка нашла проблемы не там, где ожидалось. Канал, ради которого затевалась, был в порядке; риски обнаружились в служебных местах — журналах и тестовых выгрузках, которые не воспринимались как хранилища персональных данных.
Частые вопросы
Какие сейчас штрафы за утечку персональных данных?
С 30 мая 2025 года ответственность дифференцирована по объёму утечки, а за повторное нарушение введён оборотный штраф — 1–3% годовой выручки, до 500 миллионов рублей. Параллельно введена уголовная ответственность по статье 272.1 УК за незаконный оборот персональных данных. Конкретные составы и суммы стоит сверять с действующей редакцией.
Касается ли это проектов с ИИ?
Напрямую: системы с моделями создают новые места, где данные оказываются вне привычного контура — запросы к внешней модели, журналы диалогов, индексы для поиска, выгрузки для тестирования. Каждое из них требует тех же ограничений, что и исходные данные.
Что делать, если данные уже ушли в публичный сервис?
Это ситуация для юриста и порядка действий при инциденте, который должен существовать заранее: сроки уведомления регулятора исчисляются часами. Технически — зафиксировать, что именно и когда ушло, чтобы можно было оценить объём.
Какие технические меры снижают риск?
Не передавать лишнего — пересмотр состава запроса часто убирает персональные данные вовсе. Дальше: обезличивание с измеренной долей пропусков, локальное размещение модели, ограничение доступа к журналам и срока их хранения, фильтрация по правам при поиске.
Помогает ли локальное развёртывание?
Оно снимает один конкретный риск — передачу данных третьему лицу. Остальные требования к обработке персональных данных сохраняются: локальное размещение не отменяет 152-ФЗ и не освобождает от ответственности за утечку из вашего контура.
Что подготовить для юриста?
Техническое описание: какие данные обрабатываются, куда передаются, кто имеет доступ, что записывается в журналы, сколько хранится, какие меры приняты и с какой измеренной результативностью. С таким описанием юрист даст ответ по существу.
Что дальше
Что и куда передаётся — «Можно ли передавать персональные данные в нейросеть». Каналы, о которых забывают, — «Утечка данных через нейросеть». Технические меры — «Обезличивание данных». Базовые требования — «152-ФЗ и нейросети».
Проверка систем перед запуском и подготовка технического описания для юриста — часть аудита и работы по внедрению ИИ.