Во многих компаниях служба информационной безопасности узнаёт о работающих ИИ-проектах постфактум. Это системная проблема: технология стала слишком доступной, а процессы управления за ней не успели.
Автор: Андрей Хлебников, руководитель департамента технического развития Infosecurity “Софтлайн Решения” (ГК Softline).
В ИБ-сообществе есть старая шутка: безопасность — единственная функция в компании, которая узнаёт о проектах из новостей. Раньше это было преувеличением. Сейчас, на фоне быстрого внедрения ИИ, шутка стала слишком похожа на рабочую реальность. Для бизнес-планирования квартал или полгода — небольшой срок. Для ИИ-проекта этого часто хватает, чтобы появилось решение, которое уже приносит пользу и обрабатывает реальные данные. А потом его случайно обнаруживает директор по ИБ.
Причина проста: порог входа резко снизился. Раньше почти любое новое ИТ-решение требовало бюджета, участия ИТ-департамента и нескольких месяцев согласований. Теперь команда из трёх человек за выходные может собрать рабочий инструмент на базе публичного API. И нередко именно так и происходит.
Анатомия опоздания Сценарий почти всегда одинаковый. Бизнес видит возможность: автоматизировать рутину, ускорить обработку обращений, упростить работу с документами. Ценность понятна, облачные ИИ-сервисы доступны, деньги у подразделения есть. Согласование с центральным ИТ кажется лишним, особенно если в компании ещё нет понятных правил для таких случаев. Про согласование с ИБ вспоминают ещё реже. Система запускается, работает, показывает результат. Потом появляется вторая, третья, десятая. Через полгода в компании уже набор разрозненных решений: одни работают с клиентскими данными, другие — с финансовыми документами, третьи — с внутренними регламентами. Архитектура разная, подходы разные, ответственность размыта. И это ещё без учёта сотрудников, которые ничего не разрабатывают, а просто отправляют рабочие документы в условный DeepSeek.
Ключевые вызовы при попытках начать защиту ИИ В этот момент директор по ИБ оказывается в неудобной позиции. Запретить всё уже поздно: решения работают, бизнес видит от них эффект. Проверить и исправить всё сразу тоже невозможно, потому что сначала надо понять, что именно проверять и где эти решения вообще находятся.
Что реально происходит с рисками Самый очевидный риск — утечка данных. Сотрудник загрузил конфиденциальный документ в публичный чат-бот, и дальше компания уже не контролирует, где окажется эта информация: в логах сервиса, в инфраструктуре провайдера, в обучающих данных или у третьих лиц. Риск реальный, с ним нужно работать, но он не единственный.
Меньше внимания обычно получают риски агентских систем. Агент — это уже не чат-бот, который просто отвечает на вопросы. Это система с памятью, инструментами и возможностью действовать: отправлять запросы, менять данные, запускать операции, принимать решения по контексту. Если такому агенту дать широкий доступ к внутренним системам, право совершать транзакции или менять записи, поверхность атаки становится другой по масштабу.
У сотрудника-человека тоже есть доступы и инструменты, но есть ещё интуиция, опыт и понимание ситуации. Нетипичный запрос может насторожить человека. Агент устроен иначе: у него есть доступы, инструменты и склонность буквально выполнять полученные инструкции. Для злоумышленника это удобное сочетание.
Локальные модели не решают проблему автоматически. Они снижают часть рисков, связанных с передачей данных во внешние сервисы, но остаются другие угрозы: промпт-инъекции, ошибки в архитектуре, небезопасные компоненты, некорректные права доступа. В некоторых случаях локальная сборка из открытых компонентов может быть рискованнее облачного сервиса: облачные платформы хотя бы целенаправленно защищают владельцы, а локальное решение могло вообще не проходить проверку до выхода в прод.
Первая реакция некоторых CISO понятна: запретить всё, что не разрешено явно. Закрыть внешние API, заблокировать публичные модели, ввести жёсткие согласования, сделать получение разрешений долгим и неудобным. Логика выглядит простой: если мы не можем контролировать, лучше остановить.
Но запрет работает плохо. Во-первых, уже запущенные системы никуда не исчезают, а риски прошлого использования нельзя отменить задним числом. Во-вторых, бизнес уже увидел ценность ИИ-инструментов. Если официальный путь станет непроходимым, появится неофициальный — тот самый теневой ИИ, только ещё менее видимый для ИБ. В-третьих, новые сервисы появляются слишком быстро, чтобы успевать за ними одними блокировками. Запрет сам по себе не стратегия, а попытка выиграть время. Иногда это нужно, но проблему он не решает.
С чего начать, когда поезд уже ушёл Догнать поезд можно. Для этого сначала придётся признать реальность: ИИ в компании уже используется, даже если в реестрах и политиках его пока нет.
Первый шаг — инвентаризация. Не большой аудит на несколько месяцев и не немедленная разработка регламентов. Сначала достаточно честно выписать: какие ИИ-сценарии уже есть, какие системы используются, кто ими пользуется, какие данные туда попадают, кто является владельцем и кто заинтересован в результате. Такая работа занимает несколько дней и даёт главное — понимание масштаба.
Второй шаг — разговор с людьми, а не только с документами. Политику можно написать быстро, но без диалога с продуктовыми командами, инициативными группами и теми сотрудниками, которые реально собирают ИИ-решения, она останется формальностью. Именно они знают, что делает система, зачем она нужна бизнесу, из каких частей состоит, какие данные обрабатывает и что сломается, если её внезапно отключить.
Третий шаг — описать и приоритизировать рисковые сценарии, то есть честно ответить на вопрос: что случится, если что-то пойдёт не так. Jailbreak информационного чат-бота на сайте и jailbreak агента с доступом к финансовым транзакциям — разные по последствиям истории. Ресурсы ИБ ограничены, поэтому начинать нужно там, где риск действительно может ударить по бизнесу.
Смена парадигмы Главное изменение, которое принесли LLM, — цель уже не в том, чтобы инцидентов не было вообще. Они будут даже у зрелых компаний и при серьёзных инвестициях в защиту. Цель в другом: чтобы ситуация оставалась управляемой, а критичные сценарии были заранее описаны и подготовлены. Это противоположность режиму постоянного тушения пожаров.
Разница между зрелым и незрелым подходом не в самом факте инцидента, а в том, понимала ли компания такой сценарий заранее и была ли готова действовать. Поэтому ИБ догоняет поезд не для того, чтобы всё запретить. Задача — вернуть управляемость. А значит, кибербезопасность ИИ должна рассматриваться не как внешний контроль, а как часть системы управления компанией.
Комментарии