СлаживаниеБлог

Регламент ИИ и 152-ФЗ: что учесть

2026-10-22 · Слаживание

До запуска ИИ я проверяю три вещи: какие персональные данные получает модель, на каком основании и куда они уходят. Запретить ввод ФИО недостаточно: данные могут остаться в ответах, логах и резервных копиях.

В регламенте я закрепляю:

  • Данные и основания: цели обработки, разрешённые сведения, маскирование и запреты.
  • Среду и передачу: условия SaaS, частного облака или своих серверов, локализацию, иностранных получателей и подрядчиков.
  • Доступ и контроль: права сотрудников и агентов, действия только после одобрения человека.
  • Защиту: состав логов, сроки хранения и проверяемое удаление копий.
  • Запуск и ответственность: согласования, пилот, проверку изменений и порядок действий при инциденте.

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

ИИ и 152-ФЗ: путь от проверки данных до масштабирования
ИИ и 152-ФЗ: путь от проверки данных до масштабирования

Персональные данные в 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 и истории переписки. Когда удаление завершится, вы получите уведомление с перечнем удалённых данных.

← Все статьи