Персональные данные в ИИ-канале: приказ ФСТЭК 2026

Персональные данные в ИИ-канале: что меняет проект приказа ФСТЭК и что делать до 1 сентября

Менеджер копирует переписку с клиентом в чат с нейросетью и просит составить ответ. Бухгалтер загружает скан договора, чтобы вытащить реквизиты. Маркетолог отдает выгрузку из CRM, чтобы получить сегменты. Все трое работают быстрее, и все трое только что вынесли персональные данные за периметр компании, не оставив об этом ни одной записи.

Этот маршрут мы называем ИИ-каналом: путь, по которому данные из ваших систем попадают во внешнюю языковую модель. До лета 2026 года он не был описан ни в одном нормативном документе, и любой разговор о его защите упирался в отсутствие требований. Теперь требования появляются.

Что меняет проект приказа ФСТЭК от 24 июля 2026 года

Здесь разбирается только та часть проекта, что касается ИИ-канала. Отмена приказа № 21 целиком, показатель зрелости Узи, уровни защищенности и классы средств защиты вынесены в отдельный разбор: приказ ФСТЭК № 21 отменяется, что придет взамен.

24 июля на портале regulation.gov.ru опубликован проект приказа ФСТЭК о составе и содержании организационных и технических мер по безопасности персональных данных в информационных системах. Документ должен заменить приказ № 21, который действует с 2013 года. Дата вступления в силу в проекте заявлена как 1 сентября 2026 года.

Для компании, которая уже пользуется нейросетями, в нем важны три вещи.

Риск-ориентированная схема вместо фиксированного перечня. Раньше набор мер переписывался из приложения к приказу и был одинаковым для склада запчастей и для медицинской карты. Теперь состав защиты подбирается под конкретную систему и под уровень риска, а выбор нужно обосновать.

Искусственный интеллект попадает в текст документа. Требования к защите информации при использовании нейросетевых моделей появляются на нормативном уровне впервые. Рядом в проекте стоят облачные среды, виртуализация, программные интерфейсы и интернет вещей, то есть все то, что за последние годы выросло вне классической модели угроз.

Инциденты уходят наружу. Сведения о компьютерных атаках передаются в ГосСОПКА, и история инцидента перестает быть внутренним делом оператора.

Проект проходит обсуждение, формулировки будут меняться, часть требований смягчат. Направление при этом читается однозначно: то, что раньше жило в серой зоне «мы просто пользуемся ChatGPT», становится предметом проверки.

Почему ИИ-канал не попадает в опись информационных систем

Классическая модель угроз строилась вокруг того, что компания контролирует: база, почтовый сервер, файловое хранилище, резервные копии. У каждой такой системы есть владелец, права доступа и журнал событий.

ИИ-канал собирается снизу и стихийно. Сотрудник открывает браузер и вставляет фрагмент документа в чат. Разработчик подключает внешний API к внутреннему сервису, чтобы разобрать заявку. Отдел продаж ставит расширение, которое дописывает письма по истории переписки. Подрядчик приносит бота, обученного на выгрузке из вашей системы.

Ни одна из этих четырех точек не попадает в стандартную опись систем. Формально данные никуда не передавались: их скопировали руками. Фактически они ушли третьему лицу, и следов не осталось. Поэтому после выхода приказа работа начинается с инвентаризации: какая система, какое поле, какой промпт, какой внешний сервис.

Что нашли, когда разобрали собственный ИИ-канал

В августе 2026 года мы разобрали контур eq.team по той же методике, которую применяем у клиентов. Проверяли три канала, куда могли попадать данные людей, оставивших заявку на сайте.

Течь оказалась в почтовом канале, а не в базе, которую все охраняют. Письмо с контактами клиента расходится по ящикам сотрудников, пересылается в мессенджер и оседает в архиве почтового сервиса. Журналы при этом оказались чистыми, хотя подозрение обычно падает именно на них.

Второй находкой стал получатель. Уведомления о заявках приходили на личный почтовый ящик физлица. Это отдельная проблема, и она не лечится техникой: пока корпоративный ящик не заведен и не проверен живой отправкой, менять получателя опасно, потому что цена ошибки это потерянные заявки.

Как устроено маскирование: поле, правило, пример

Принцип, к которому мы пришли: в письмо менеджеру уходят частично скрытые контакты, а полные данные остаются в базе под доступом по учетной записи. Менеджер узнает заявку и понимает, стоит ли за нее браться, а за полным контактом идет по ссылке в письме.

К правилам маскирования добавился срок хранения. Раньше заявки лежали в базе бессрочно, теперь запись удаляется через 365 дней вместе со всеми полями, а письма-уведомления в почтовом ящике живут 90 дней. Год для B2B-заявки это разумный горизонт: то, что не сконвертировалось за такой срок, практически мертво, а хранить персональные данные без конечного срока нельзя.

Отдельная проверка касалась доставки. Мы отправили тестовую заявку через тот же интерфейс, что и живые формы сайта, и убедились, что письмо доходит и контакты в нем скрыты. Это обязательный шаг: защита, из-за которой теряется хотя бы одна заявка, будет отключена бизнесом в первую же неделю.

Где заканчиваются возможности автоматического детектора

Соблазн понятный: поставить инструмент, который сам найдет персональные данные в потоке, и закрыть тему. Мы такой инструмент разрабатываем, поэтому знаем его пределы в цифрах.

Замер на бенчмарке из 2867 сообщений и 4585 размеченных сущностей. Сводно движок находит 92,5 % при 301 ложном срабатывании. Но средняя цифра тут мало что объясняет, поэтому смотреть надо по категориям.

Закономерность простая, и она делит таблицу пополам. Структурированные типы, где есть жесткий формат и контрольная сумма, закрыты на 96,7-98,8 процента. Это 2318 сущностей: документы, государственные идентификаторы, финансы, контакты, техника. Тут работает регулярное выражение, и человеку сверять почти нечего.

Неструктурированные типы идут ниже: ФИО 87,3 процента, адрес 86,5, организации 92,8. Это еще 2263 сущности, и на них приходится 287 из 344 пропусков, то есть 83 процента всех промахов. Причина в том, что фамилия не отличается от названия компании без разбора смысла, а адрес люди пишут десятком способов. Регулярка тут бессильна, работает отдельная модель распознавания сущностей.

Ложные срабатывания смещены в ту же сторону: 231 из 301, то есть 77 процентов, приходятся на организации, адреса и ФИО. Инструмент перестраховывается и помечает лишнее, а специалист снимает лишние метки. Это дешевле обратной ошибки, когда данные уходят наружу незамеченными.

Одну цифру в таблице читать нельзя: ОГРН показывает 14 ложных срабатываний при одном размеченном случае. Метрика нерепрезентативна, движок тянет любые 13-значные и 15-значные числа как ОГРН. Мы это знаем и правим кандидатный фильтр, а в отчете клиенту такие места помечаем отдельно.

Отсюда рабочее правило: инструмент размечает кандидатов, решение по каждому спорному фрагменту принимает человек. Полноту автоматического обнаружения мы не обещаем и пишем это в договор. Компания, которая успокоилась на отчете детектора и подписала на его основании документы, получила ложное чувство безопасности вместо защиты.

Вторая ловушка техническая. Модель распознавания сущностей, которую часто ставят на такие задачи, находит имена, организации и локации, но пропускает телефон и почту, а это основной тип данных в заявке. Мы это проверяли. В горячем пути у нас работают детерминированные правила, а модель разбирает тексты отдельно, по копии из базы. Синхронный сетевой вызов в момент приема заявки добавляет еще и риск для доставки.

Станет ли работы меньше при риск-ориентированной модели

Нет. Обязанность строить одинаковую защиту везде исчезает, но взамен появляется обязанность обосновать, почему для конкретной системы выбран именно такой набор мер. Обоснование пишут руками, и опирается оно на инвентаризацию, которой у большинства компаний пока нет.

На практике это означает три новых регулярных занятия:

1. держать в актуальном виде схему потоков данных, включая внешние сервисы;
2. вести реестр того, что передается наружу, и пересматривать его при каждом новом инструменте;
3. объяснять сотрудникам, что можно и нельзя отправлять, и проверять, что объяснение работает.

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

С чего начинать: схема канала на одном листе

Первый предмет работы, который дает результат сразу, это одностраничная схема. На ней рисуется цепочка: система-источник, конкретное поле, промпт, внешний сервис и точка, где ставится маскирование.

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

Дальше идет реестр по выборке реальных текстов: какой тип данных, сколько раз встретился, в каком процессе, какая статья КоАП и какая сумма штрафа этому соответствует. Мы берем выборку из 200 текстов за последние 30 дней. Выборка описывает канал и не претендует на исчерпывающий перечень того, что есть в системе, и это написано на титульном листе отчета.

Если ИИ уже встроен в рабочие процессы через интеграции, схему стоит рисовать вместе с картой этих интеграций. Мы разбирали такой контур в материале про интеграцию ChatGPT с amoCRM и Битрикс24: там же видно, какие поля сделки уходят в модель при типовой настройке.

Документы, которые придется подготовить

Техническая часть без бумажной не работает: проверяющий читает документы, а не код. Минимальный комплект выглядит так.

Описание метода обезличивания. Готовится по приказу Роскомнадзора № 140 от 19 июня 2025 года, который действует с 1 сентября 2025 года и заменил отмененный № 996. Практичный метод для ИИ-канала это введение идентификаторов: наружу уходит метка вместо значения, а соответствие хранится внутри.

Регламент работы сотрудников с нейросетями. Пять-семь страниц: что можно и нельзя отправлять, как проверить текст за тридцать секунд, что делать при инциденте. Плюс памятка на одну страницу на рабочее место. Регламент, который лежит только в общей папке, никто не открывает, поэтому памятка обязательна.

Инструкция по внедрению маскирования для разработчика. Эндпоинт, авторизация, примеры запросов, формат ответа, обработка ошибок. Проверяется за десять минут: разработчик делает первый запрос и получает маскированный текст.

Контрольный замер. Повторный прогон тех же 200 текстов через 30 дней по той же методике. Отчет на одну страницу с двумя цифрами: было и стало. Без замера непонятно, изменилось ли что-нибудь, кроме количества документов на полке.

Что успеть до 1 сентября своими силами

Работа делится на четыре шага, и каждый можно начать без подрядчика. Ориентиры по трудозатратам взяты из наших проектов и считаются для компании с одним процессом, где используется нейросеть.

1. Опросить отделы и собрать список инструментов. Кто чем пользуется, через браузер или через API, с личного аккаунта или с корпоративного. Ответы почти всегда шире ожиданий руководителя.
2. Нарисовать схему канала. От восьми часов при одном процессе. Дальше время растет пропорционально числу систем, которые касаются канала.
3. Прочитать выборку. От двенадцати часов на реестр по 200 текстам за последние 30 дней с разметкой по типам данных.
4. Написать регламент и памятку. От восьми часов, если схема и реестр уже есть. Без них документ получится общим и работать не будет.

Инвентаризация и схема нужны при любой редакции приказа, поэтому эти часы не пропадут, даже если формулировки в итоговом тексте изменятся. Логика та же, что при аудите точек автоматизации: сначала карта процессов, потом решения по инструментам.

Сколько это стоит, если отдать работу подрядчику

Мы работаем по ставке 2500 ₽/ч с оплатой по факту и без аванса. Разбор ИИ-канала оформлен отдельным пакетом с фиксированной ценой и сроком, чтобы не считать часы задним числом.

Цена пакета 49 000 ₽ при сроке 10 рабочих дней. Пресейл-прогон бесплатный, и это сознательное решение: клиент видит фактическую работу инструмента на своих текстах до оплаты. Если на выборке видно, что основной носитель данных у вас это адреса и имена в свободном тексте, мы называем цифры 87,3 и 86,5 процента вслух и закладываем ручную вычитку в объем работ, а не делаем вид, что автоматика закрывает все.

Пакет закрывает канал, но не отвечает на вопрос, зачем нейросеть стоит в этом процессе. Если внедрение только планируется, разумнее начать с разбора процессов: об этом мы писали в материале про внедрение ИИ в бизнес под ключ.

Частые вопросы

Смежные материалы: где ИИ применяется в бизнесе и внедрение ИИ под ключ. Если нужен разбор процессов до внедрения инструментов, посмотрите автоматизацию процессов.