Регламент ИИ и 152-ФЗ: что учесть
До запуска ИИ я проверяю три вещи: какие персональные данные получает модель, на каком основании и куда они уходят. Запретить ввод ФИО недостаточно: данные могут остаться в ответах, логах и резервных копиях.
В регламенте я закрепляю:
- Данные и основания: цели обработки, разрешённые сведения, маскирование и запреты.
- Среду и передачу: условия SaaS, частного облака или своих серверов, локализацию, иностранных получателей и подрядчиков.
- Доступ и контроль: права сотрудников и агентов, действия только после одобрения человека.
- Защиту: состав логов, сроки хранения и проверяемое удаление копий.
- Запуск и ответственность: согласования, пилот, проверку изменений и порядок действий при инциденте.
_Размещение на своих серверах само по себе не обеспечивает соблюдение 152-ФЗ._ Я оцениваю весь путь данных, а перед масштабированием - результаты пилота. Для инцидентов, подпадающих под часть 3.1 статьи 21, учитываю сроки уведомления Роскомнадзора: 24 часа для первичного сообщения и 72 часа для результатов внутреннего расследования - от момента выявления.

Персональные данные в 2025 году. Новые требования 152-ФЗ.
Зафиксируйте правовые основания, локализацию и передачу данных
Когда определите, какие данные допустимо использовать, закрепите в регламенте цели обработки, правовые основания, роли участников и список внешних провайдеров. Укажите страну обработки[1].
Запишите цели, правовые основания и роли
Важно не просто решить, можно ли использовать ИИ, а установить, на каком основании и в каком контуре будут обрабатываться данные. По статьям 5 и 6 проверяйте основание для каждой конкретной операции, а не для работы с ИИ в целом[3][4][7].
Для каждой новой операции запишите цель обработки, её связь с первоначальной целью сбора и отдельное правовое основание: согласие или другое основание, предусмотренное законом. Согласие не означает автоматического разрешения на новую обработку. Для специальных категорий данных отдельно проверьте ограничения статьи 10[1].
Если привлекаете подрядчика, укажите платформу, субпроцессоров и роль каждого участника. В веб-формах разместите предупреждение и запретите ввод данных, которые нельзя передавать модели[1].
Затем проверьте, где обрабатываются данные и кому они передаются.
Проверьте локализацию и трансграничную передачу
Проверьте всю цепочку: не уходят ли данные за пределы России через модель, логи, вложения или службу поддержки провайдера.
При сборе и первичной записи персональных данных граждан РФ база должна находиться в России. Российская копия не легализует зарубежную обработку. Проверяйте не только промпты, но и вложения, эмбеддинги (векторные представления) и логи, если они содержат персональные данные. Отдельно проверьте доступ иностранной поддержки и субподрядчиков.
До передачи данных иностранным получателям направьте предварительное уведомление в Роскомнадзор[1]. После уведомления выдержите установленный срок до начала передачи.
Выберите среду ИИ и настройте доступы
Когда маршрут данных и риски передачи описаны, выберите контур, в котором сможете соблюдать установленные правила.
152-ФЗ не требует размещать любой ИИ on-premises - на собственных серверах. Выбор зависит от типа данных и прав агента. Чем выше риск, тем строже должны быть изоляция и контроль.
До выбора платформы запросите у поставщика сведения о субподрядчиках. Уточните, где именно данные хранятся, обрабатываются и попадают в журналы событий [1][2].
Сравните SaaS, частное облако и on-premises
Зафиксируйте в регламенте выбранную среду и то, как она соответствует установленным правилам локализации и передачи данных.
| Критерий | SaaS / облако | Частное облако / гибридный контур | On-premises |
|---|---|---|---|
| Где находятся данные | В инфраструктуре провайдера | Часть данных - в облаке, чувствительные персональные данные - в локальном контуре | В локальном контуре |
| Доступ провайдера | Провайдер технически видит данные в пределах сервиса | Зависит от архитектуры и условий доступа | Только если предусмотрен технический доступ |
| Требования к соблюдению 152-ФЗ | Проверка провайдера и договорных условий | Проверка распределения данных и доступа между контурами | Внутренняя организация защиты и контроля |
| Лучше подходит для | Маркетинг, внешняя поддержка | CRM/ERP, смешанные данные | Финансы, HR, юридические задачи и безопасность |
Затем настройте роли и права: агент не должен видеть лишние данные или выполнять действия, требующие согласования, без одобрения.
Ограничьте права сотрудников и ИИ-агентов
Используйте принцип наименьших привилегий: выдавайте агенту только нужные для задачи права, не выходя за пределы доступа сотрудника к исходным системам.
Для каждого сценария задайте отдельную роль, а для агентов создайте отдельные учётные записи. В регламенте опишите права сотрудников и агентов, а также порядок подтверждения действий [5][6].
| Роль | Чтение | Запись и действия | Кто согласует | Ручной режим |
|---|---|---|---|---|
| Агент продаж | История сделок | Черновики; отправка и изменения в CRM - после одобрения | Руководитель продаж | Ручной ввод |
| Агент подбора | Резюме и расшифровки интервью | Черновики приглашений и отказов | Ответственный HR | Ручной отбор |
| Финансовый агент | Счета и графики | Без права записи | Финансовый директор | Ручная авторизация платежей |
| Агент коммуникаций | Командные каналы | Черновики сообщений | Руководитель подразделения | Ручная отправка |
Требуйте проверки решений, которые влияют на людей
Даже правильно выбранный контур не позволяет полностью передать ИИ любую задачу.
Статья 16 ограничивает решения, основанные исключительно на автоматизированной обработке, если они порождают юридические последствия для человека или затрагивают его права и законные интересы. Для таких сценариев в HR, финансах и продажах закрепите в регламенте, что финальное решение принимает сотрудник [4][3].
Для каждого существенного вывода требуйте ссылку на источник - фрагмент резюме, запись разговора или документ. Расширяйте автономность агента поэтапно, с учётом этих ограничений и с сохранением контроля со стороны человека.
Установите правила маскирования, хранения и логирования
Когда контур и права доступа выбраны, закрепите правила защиты запросов, ответов и логов. Даже разрешённую среду нужно проверить перед запуском. Объедините требования статьи 19 и меры защиты в предзапусковой чек-лист:
- Для каждой проверки укажите актив, угрозу, меру защиты, способ мониторинга, ответственного и доказательство проверки.
- Включите запросы, ответы, файлы, эмбеддинги, диагностические логи и резервные копии.
- Зафиксируйте обязательные меры защиты и ограничения для ИИ: фильтрацию запросов, изоляцию памяти и контроль вызовов инструментов.
- Подтвердите результат протоколом или техническим отчётом. Отметки «настроено» недостаточно.
Маскируйте данные до отправки в модель
Определите, какие данные можно передавать модели, и настройте маскирование до отправки. Маскирование не делает данные обезличенными. Автоматически удаляйте из текста контактные данные: телефоны, e-mail и мессенджеры [2][3]. Храните ключи восстановления отдельно и ограничьте доступ к ним. Не допускайте попадания личных чатов в общую память агента.
Задайте сроки хранения и удаления каждой копии
Установите сроки хранения и удаления всех копий - один срок для всего ИИ-контура не подойдёт. Для запросов, ответов, файлов, эмбеддингов, логов и резервных копий укажите цель и срок хранения, событие, по которому запускается удаление, исполнителя и способ подтверждения.
При удалении исходных данных зафиксируйте и удаление связанных копий: в поисковом индексе, подключённых системах и у провайдера. Если автоматического удаления нет, предусмотрите ручной процесс, выполнение которого можно проверить [1].
Защитите логи и ограничьте их содержимое
Закрепите состав журналов и правила их защиты. Логи нужны, чтобы выявлять нарушения прав людей, утечки и обход ограничений.
- Что логировать: ID сотрудника и агента, время, источник, категорию данных, инструмент и результат. Настройте выявление необычных запросов, массовых выгрузок, попыток внедрить инструкции через документы и действий за пределами разрешений.
- Что не логировать: по умолчанию не сохраняйте полный текст запросов и документов. Записывайте только краткие события.
- Как защищать: ограничьте доступ, защитите журналы от несанкционированного изменения и задайте для них отдельный срок хранения. Без маскирования, ограничений доступа или защищённых журналов запуск запрещён.
Утвердите регламент, запустите пилот и пересматривайте правила
Когда маршруты данных, контуры и ограничения определены, закрепите ответственных и порядок запуска.
Назначьте ответственных и соберите доказательства готовности
Распределите обязанности между владельцем процесса, ответственным за ПДн, юристом, ИБ и ИТ. В регламенте укажите, кто запускает ИИ-агента, кто подтверждает его действия и кто подаёт стоп-сигнал - приостанавливает сценарий при нарушении правил. Регламент утверждает руководитель.
В пакет на утверждение включите регламент ИИ, правила для сотрудников, реестр потоков данных, условия работы подрядчиков, матрицу доступа, график хранения и порядок реагирования на инциденты. Покажите связь между целями, основаниями, категориями данных, маршрутами и мерами защиты. Если неизвестны места или сроки хранения, субподрядчики либо полномочия агента, запуск нужно заблокировать. Пометка on-premises не заменяет эти сведения.
Готовность контура сначала подтвердите на пилоте, а не при промышленном запуске.
До пилота проверьте цели, основания, категории данных и маршруты. За это отвечают ответственный за ПДн и юрист. Подтверждение готовности - подписанная оценка рисков и схема потоков. Проверку проводят перед пилотом и после существенных изменений.
До промышленного запуска проверьте договоры, доступы, маскирование, хранение, удаление и контроль человеком. Ответственные - юрист, ИБ и ИТ. Подтверждающие документы - договоры, выгрузка настроек и протокол испытаний. Проверку проводят перед запуском и после существенных изменений.
Во время работы ИБ и ИТ сверяют доступы и фактические потоки данных. Результат фиксируют в отчёте с закрытыми замечаниями. Периодичность - ежеквартально, а также после изменения ролей или интеграций.
Пересматривайте изменения и реагируйте на инциденты
До включения любого изменения модели, промпта, интеграции, субподрядчика или прав агента оцените его влияние. Сохраняйте согласования, версии настроек и результаты проверок. На пилоте ежемесячно проверяйте шаблоны запросов на запрещённые идентификаторы. Условия подрядчиков проверяйте при изменениях и не реже раза в год.
Для сообщений об инцидентах назначьте единый канал и руководителя реагирования. ИТ отключает затронутую интеграцию и отзывает токены, ИБ сохраняет доказательства. Юрист и ответственный за ПДн определяют обязанности по уведомлению.
Основание по части 3.1 статьи 21 - неправомерная или случайная передача либо доступ к ПДн, повлёкшие нарушение прав субъектов. Оба срока отсчитываются от выявления такого инцидента: до 24 часов - первичное уведомление Роскомнадзора, до 72 часов - сведения о результатах внутреннего расследования. Второй срок не означает, что за это время нужно завершить все восстановительные работы.[8][9][10]
Измерьте результаты пилота до масштабирования
После настройки контроля и реагирования на инциденты проверьте, даёт ли сценарий измеримый эффект.
Ограничьте пилот одним процессом, одним отделом и только разрешёнными данными. Заранее задайте срок пилота. Сравните время выполнения задачи, долю ручных исправлений, попытки превысить права, стоимость задачи и долю записей, прошедших проверки маскирования и хранения.
При внедрении со Слаживанием зафиксируйте результаты диагностики и пилота в решении: расширять / доработать и повторить / остановить. Его принимает назначенный руководитель. Помощь команды внедрения не заменяет ответственность оператора и не гарантирует соответствие 152-ФЗ.
FAQs
Как понять, что после маскирования данные всё ещё персональные?
Данные остаются персональными, пока связаны с конкретным человеком или позволяют однозначно его идентифицировать. Просто убрать имя и телефон не всегда достаточно. Человека могут выдать косвенные сведения: особые должностные обязанности, история взаимодействия или факты из контекста.
В «Слаживании» этот риск снижают за счёт удаления контактных данных до отправки текста в модель. Для обработки особо чувствительной информации с соблюдением 152-ФЗ рекомендуется локальное развёртывание (on-prem): данные не покидают инфраструктуру компании.
Как проверить, использует ли провайдер мои данные для обучения ИИ?
Проверьте политику обработки данных платформы: правила зависят от провайдера и способа развёртывания. В политике Слаживания перечислены текущие поставщики моделей. Там же указано, что текст запросов может передаваться в языковые модели через сервисы-посредники.
Для защиты данных используют обезличивание, а для работы с чувствительной информацией - локальное развёртывание (on-prem). Если политика не даёт ясного ответа, используются ли ваши данные для обучения ИИ, уточните это у администратора сервиса.
Как удалить данные из резервных копий, не нарушив сроки хранения?
Чтобы удалить персональные данные из резервных копий и при этом соблюсти сроки хранения, данные очищают вручную на всех уровнях хранения системы. Для запроса на удаление напишите на leo@dovbenko.me.
Данные удалят из всех мест, где они есть на момент запроса: базы заявок, карточек в CRM и истории переписки. Когда удаление завершится, вы получите уведомление с перечнем удалённых данных.