Компания ЗИКС завершила проект по контролю и защите информации, которую сотрудники заказчика передавали в публичные сервисы искусственного интеллекта. Работы выполнены на крупном медиапроизводственном объекте на базе InfoWatch Traffic Monitor и InfoWatch Device Monitor.
Политика есть. Вопрос в том, работает ли она
У заказчика выстроена система информационной безопасности: действует политика конфиденциальности, определены уровни доступа, сотрудники знакомы с правилами и понимают, какие материалы допустимо передавать во внешние сервисы, а какие нет.
Проблема не в отсутствии правил. Проблема в том, что между правилом и его соблюдением всегда стоит человек.
Сотрудник срочно готовит документ и просит нейросеть сократить текст, не потеряв смысл. Инженер разбирает инцидент и вставляет в чат-бот фрагмент логов вместе с адресами. Аналитик проверяет формулировку и прикладывает кусок договора. Никто не действует со злым умыслом — в моменте это обычная рабочая задача, которую нужно решить быстрее.
Особая категория — руководители. Здесь запрет не работает в принципе: человек, отвечающий за скорость и эффективность решений, не откажется от инструмента, который эту скорость даёт. Попытка перекрыть доступ приведёт либо к обходу через личное устройство, либо к конфликту вокруг формального правила при сохранении фактического использования.
Поэтому задача ставилась не как «запретить», а как «сделать видимым и управляемым»: понимать, что именно уходит наружу, видеть нарушения установленных правил и корректировать их на уровне процессов.
Почему это стало обязательной задачей
Использование генеративных моделей в рабочих процессах за последние два года стало массовым. При этом инфраструктурно ничего не изменилось: тот же браузер, тот же рабочий компьютер, тот же зашифрованный HTTPS-трафик к внешнему ресурсу. Новый канал передачи данных не проектировался и не включался в модель угроз — он возник внутри процессов компании.
Стандартный DLP такой канал не закрывает. Готовые политики рассчитаны на почту, мессенджеры, файлообменники и съёмные носители. Для ИИ-сервисов домен может быть известен, а содержимое передаваемых данных — нет. Без расшифровки на стороне компании видно факт обращения к сайту, но не видно, что туда отправлено.
Полный запрет проблему не решает, а переносит её в теневую зону: использование уходит на личные устройства, и компания теряет даже факт события.
Что чаще всего уходит в чат-боты
Отдельная задача проекта — понять, какие категории данных передаются чаще. Это нужно не для оценки дисциплины, а для приоритизации правил: закрывать в первую очередь то, что реально уходит.
В типовом профиле такого трафика доминируют рабочие материалы, а не осознанная передача закрытых документов: фрагменты текстов и договоров для переписывания или проверки формулировок, таблицы и выгрузки, код и конфигурационные файлы, схемы, чертежи и сканы, тексты для перевода, персональные данные в примерах, сетевые идентификаторы при разборе технических задач.
Общий признак у всех пунктов один: сотрудник решает рабочую задачу и не воспринимает происходящее как передачу корпоративных данных внешнему получателю. С точки зрения архитектуры сети это именно она.
Задача
Сотрудники заказчика передавали служебную информацию в ChatGPT, DeepSeek, Grok, Copilot, Telegram-боты и другие сервисы.
Требовался инструмент контроля, а не блокировка: фиксировать, что уходит во внешние сервисы, классифицировать данные по категориям и видеть нарушения установленных правил.
Объекты защиты, зафиксированные на старте: персональные данные (ФИО, адрес электронной почты, телефон), рабочая и проектная документация, инженерные схемы и чертежи, сетевая топология, IP-адреса, DNS-имена и домены организации, конфигурационные файлы.
Решение
Специалисты ЗИКС настроили комплекс правил и политик в InfoWatch Traffic Monitor в связке с InfoWatch Device Monitor.
Выявление канала. Реализован двухуровневый подход. Первый уровень — отслеживание входящего и исходящего трафика к известным сервисам генеративного ИИ по списку доменов. Второй — распознавание чат-ботов по признакам интерфейса: структуре HTML-страницы, наличию поля ввода и элементов управления. Второй механизм принципиален: он позволяет выявлять новые площадки, которые не попадут ни в один фиксированный перечень. Без него через несколько месяцев после внедрения значительная часть канала оказалась бы вне зоны видимости.
Контроль содержимого. Организована расшифровка веб-трафика на клиентских машинах с установкой доверенных сертификатов через InfoWatch Device Monitor. Параллельно в тестовом режиме прорабатывается перехват по протоколу ICAP как основа следующего этапа: он снимает необходимость агентской установки на каждое устройство и открывает контроль сценариев, недоступных при хостовом перехвате.
Отделение полезной нагрузки. Значительная часть обмена с веб-сервисами — служебные данные: cookie, ключи сессий, технические заголовки. Если анализировать их наравне с полезной нагрузкой, система генерирует поток событий без смысловой ценности. Совместно с аналитиком вендора составлены правила выделения полезной нагрузки и отсечения служебной части.
Политики по объектам защиты. Настроено выявление персональных данных, рабочей документации, сетевой топологии, IP-адресов и DNS-имён, конфигурационных файлов. Контролируется как исходящий трафик сотрудников, так и ответы ИИ-сервисов: обратное направление тоже является передачей данных. Отдельно проработаны категории, которые редко покрываются типовыми шаблонами DLP, — ввод сетевых идентификаторов в чат-бот, загрузка документов в онлайн-конвертеры, передача инженерных схем.
Результат
Заказчик получил контроль над каналом, который ранее оставался вне зоны видимости службы безопасности. Система фиксирует факты передачи чувствительной информации во внешние ИИ-сервисы и формирует события, пригодные для реагирования.
Практическая ценность не в самой фиксации, а в возможности работать с причинами. Появляется картина: какие подразделения и категории данных чаще попадают в события, где правило сформулировано недостаточно ясно, где сотруднику не хватает разрешённого инструмента. Это даёт основу для точечной корректировки политики вместо тотальных запретов.
Отдельный результат — оптимизация событий: очистка от избыточных и ложных срабатываний, настройка индексации по инженерным схемам. Без этого этапа система формально работала бы, но фактически не использовалась бы: служба безопасности перестаёт смотреть в интерфейс, который выдаёт шум.
Выводы
Работа с ИИ-каналом начинается не с настройки политик, а с перечня защищаемых данных — без него проект превращается в бесконечную настройку «на всё». Целью не стоит делать запрет: он вытесняет использование в теневую зону и лишает компанию информации о происходящем. На реестр доменов нельзя полагаться как на единственный механизм — сервисы появляются быстрее, чем обновляются списки. Очистку от служебного трафика нужно планировать отдельным этапом с собственным бюджетом времени, а взаимодействие с вендором — закладывать в сроки: часть требуемого функционала может отсутствовать на момент старта.
И главное: регулярная передача одной и той же категории данных — чаще вопрос не дисциплины, а отсутствия удобного внутреннего инструмента.
Комментарий
«Основная сложность в таких проектах — не техническая, а управленческая. У сотрудников есть политика и понимание правил, но есть и работа, которую нужно сделать быстро. Наша задача — не поймать человека на нарушении, а сделать канал прозрачным: показать, что и куда уходит, отделить нормальное рабочее использование от рискованного и дать службе безопасности возможность реагировать на реальные инциденты, а не на шум», — отметили в Компании ЗИКС.
