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