Сотрудник вставляет в чат-бот фрагмент договора, выгрузку из CRM или кусок исходного кода — чтобы быстрее составить письмо, свести таблицу или разобраться в чужом модуле. Он не обходит защиту и не нарушает периметр. Он просто пользуется удобным инструментом, а данные при этом уходят на внешний сервер.
Задача службы безопасности здесь не в том, чтобы запретить нейросети, а в том, чтобы отделить работу с сервисом от вывода в него защищаемых данных. Разберём, как это устроено технически.
Почему угроза выросла именно сейчас
ИИ перестал быть экспериментом и вошёл в ежедневную работу. По данным опроса «Сбер2В Аналитика» за июнь 2026 года, 46% российских работодателей внедрили искусственный интеллект в производственные процессы: каждый четвёртый сотрудник таких компаний пользуется нейросетями ежедневно, ещё 40% — несколько раз в неделю.
Объёмы передаваемых данных растут соответственно. В отчёте Zscaler ThreatLabz за 2026 год, построенном на анализе почти 990 миллиардов транзакций примерно девяти тысяч организаций, объём данных, переданных в ИИ-приложения, вырос за год на 93% и превысил 18 тысяч терабайт.
При этом значительная часть использования остаётся вне поля зрения работодателя. Мы разбирали это отдельно в материале о теневом ИИ и о том, почему запреты не работают. Здесь сосредоточимся на технической стороне: что именно нужно контролировать.
Почему блокировка доменов не решает задачу
Первое, что делают в большинстве компаний, — закрывают домены ИИ-сервисов на прокси или межсетевом экране. У этого подхода три конкретных технических ограничения.
Список сервисов не поддаётся ведению. Новые чат-боты, переводчики, генераторы презентаций и помощники в редакторах кода появляются еженедельно. Плюс функции ИИ встраиваются в привычные офисные приложения и браузеры — блокировать их отдельным доменом уже не получится.
Блокировка выключает видимость, а не канал. Когда сервис недоступен с рабочей машины, сотрудник открывает его на личном телефоне и перепечатывает или фотографирует данные с экрана. Событие не фиксируется вообще: для системы защиты ничего не произошло.
Домен ничего не говорит о содержимом. Обращение к ИИ-сервису само по себе не нарушение — в нём могут формулировать письмо клиенту, а могут вставлять клиентскую базу. Контроль на уровне адреса не различает эти два случая, поэтому выбор сводится к «запретить всем» или «разрешить всё».
Граница проходит по содержимому, а не по каналу
Отсюда следует принцип, на котором строится рабочая схема: контролируется не факт обращения к сервису, а то, что в него отправляют.
Для системы защиты это совсем другая задача. Трафик идёт на легитимный домен с хорошей репутацией, по обычному HTTPS, инициирован легальным пользователем в рабочее время с корпоративной машины, и внутри нет вредоносного кода. Ни антивирусу, ни системе обнаружения вторжений тут не на что реагировать — они решают другие задачи. Нужен анализ содержимого, то есть функциональность DLP-системы.
Важная деталь, которую часто упускают при настройке: в диалог с нейросетью данные чаще вставляют текстом, чем прикладывают файлом. Скопировали таблицу из Excel, вставили в поле ввода, получили ответ. Если контроль настроен только на передачу файлов, такой сценарий пройдёт мимо. Поэтому связка «буфер обмена плюс перехват вводимого текста» здесь важнее, чем контроль вложений.
Разрешительный режим: три уровня контроля
Рабочая модель — не запрет, а разрешительный режим: сервисами пользоваться можно, выводить в них защищаемые категории данных нельзя. Технически это раскладывается на три уровня.
Уровень 1. Что происходит на устройстве
| Механизм | Что даёт |
|---|---|
| Контроль буфера обмена | Перехват копирования, вплоть до блокировки вставки в поле ввода браузера и очистки буфера |
| Перехват вводимого текста | Фиксируется содержание запроса к сервису, а не только факт обращения к домену |
| Контроль состава установленного ПО | Выявление десктопных клиентов ИИ-сервисов, о которых служба безопасности может не знать |
| Анализ снимков экрана с распознаванием текста | Реакция на защищаемые данные, отображённые на экране, независимо от способа их появления |
Уровень 2. Что уходит наружу
| Механизм | Что даёт |
|---|---|
| Контроль содержимого документов | Открытие, отправка или копирование документа с ключевыми словами либо подходящего под шаблон сопровождается событием или запретом |
| Шаблоны и регулярные выражения | Типовые форматы персональных данных: банковские карты, контакты, пользовательские выражения PCRE |
| Запрет отправки файлов | Через файлообменники, почтовые сайты, чаты и социальные сети |
| Карантин | Заблокированные к передаче файлы сохраняются для разбора — доказательная база и материал для настройки правил |
Уровень 3. Точечные ограничения
| Механизм | Что даёт |
|---|---|
| Блокировка отдельных сервисов | Закрывается конкретный сервис при сохранении доступа к остальным — в отличие от запрета всей категории |
| Маркировка документов | Скрытые метки на конфиденциальных файлах и запрет их вывода за пределы разрешённого периметра |
Логика простая: третий уровень применяется точечно и к заведомо неприемлемым сервисам, основная работа приходится на первые два. Так сотрудник продолжает пользоваться инструментом, а служба безопасности контролирует не его поведение вообще, а конкретные категории данных.
Отдельный вопрос: ИИ внутри самого средства защиты
Современные средства защиты сами используют модели искусственного интеллекта: классифицируют выводимые файлы, анализируют переписки, разбирают голосовые звонки, строят отчёты по текстовому описанию, распознают лица и текст.
Ключевой вопрос к вендору: где выполняются эти функции — локально или во внешнем сервисе. Если анализ документов уходит в облачный API стороннего провайдера, средство защиты само становится каналом передачи данных за пределы контролируемой зоны. Ровно тех данных, ради которых его и внедряли.
Что уточнить в коммерческом предложении, а не в устной беседе:
- какие функции продукта используют большие языковые модели;
- выполняются они на сервере заказчика или во внешнем сервисе;
- если во внешнем — что именно туда передаётся;
- где размещаются серверная часть и база данных.
Для операторов персональных данных и субъектов КИИ это не формальность: ответ напрямую влияет на модель угроз.
Что готовят регуляторы
До недавнего времени специальных требований по этому поводу не существовало. Сейчас ситуация меняется.
В проекте приказа ФСТЭК России, который должен заменить приказ № 21 для операторов персональных данных, появилось отдельное направление — защита информации при использовании искусственного интеллекта. Аналогичное мероприятие предусмотрено и в методическом документе к приказу ФСТЭК № 117, действующему для государственных информационных систем с 1 марта 2026 года.
Добавьте к этому ответственность за сами утечки: с 30 мая 2025 года за утечку персональных данных действуют оборотные штрафы. Если в чат-бот ушла клиентская база, это утечка персональных данных — независимо от того, что сотрудник действовал без злого умысла.
Подробный разбор нового приказа и требований к защите информации при использовании ИИ мы опубликуем, когда документ будет подписан.
Примечания
Приведённые исследования — данные аналитических компаний, полученные на разных выборках и по разным методикам. Они показывают порядок величин и направление тренда, но не являются официальной статистикой.
Требования приведены по тексту проекта приказа: на дату публикации он не подписан, формулировки и нумерация пунктов могут измениться. Содержание мер по направлению защиты информации при использовании искусственного интеллекта будет раскрыто методическими документами ФСТЭК России.
Контроль работы сотрудников требует юридического оформления: локальные нормативные акты, ознакомление работников под подпись, запрет использования корпоративных ресурсов в личных целях, соблюдение требований 152-ФЗ к обработке данных самих работников.
«Стахановец» сертифицирован ФСТЭК России (сертификат № 5078) по четвёртому уровню доверия и включён в единый реестр российского ПО. ИИ-функции работают локально в рамках вашей инфраструктуры — обрабатываемые документы не покидают контролируемую зону.
