ГК Softline: ИИ-системы появляются раньше, чем ИБ успевает их проверить
Компании подключают языковые модели быстрее, чем службы безопасности успевают разобраться, где они используются и какие данные через них проходят. Для ИБ это уже не просто новый сервис в сети. Поведение модели трудно описать заранее, а вместе с доступом к внутренним системам она может получить возможность не только отвечать на вопросы, но и выполнять действия.
Такую систему можно сравнить с новым сотрудником: он быстро включается в работу, помогает решать задачи и доступен круглосуточно. При этом нельзя с уверенностью предсказать, как он ответит на следующий запрос. Иногда модель ошибается, иногда дает уверенный ответ там, где данных недостаточно. Для бизнеса эта гибкость полезна, но она же усложняет защиту.
Почему привычной проверки недостаточно
Вендорские решения тоже бывают «черными ящиками»: даже при доступе к коду компания не всегда может проверить каждую его строку. Но у классического ПО есть ожидаемое поведение. Можно описать входные данные, результат и признаки отклонения от нормы. На этом строится значительная часть защитных механизмов.
Языковая модель работает иначе. Она предназначена для неоднозначных запросов, неполных данных и контекста, который меняется по ходу разговора. Модель может понять неточно сформулированную задачу и дать полезный ответ. Но ту же способность учитывать контекст можно использовать против нее. Риск связан не только с ошибкой в коде: он возникает из самого способа взаимодействия с системой.
Один из примеров — промпт-инъекция. Злоумышленник помещает вредоносные указания в текст, который обрабатывает модель, и пытается заставить ее отклониться от заданной задачи. Частный случай такого воздействия — jailbreak: попытка обойти установленные для модели правила с помощью специально составленных инструкций. Антивирус или сетевой экран не остановят такую фразу только потому, что она опасна для поведения модели. Для них это текст.
Мы в Softline считаем, что привычные меры защиты остаются основой, но не закрывают все риски ИИ-системы. Проверять нужно не только инфраструктуру и доступы, но и то, как модель работает с полученным содержимым, какие инструкции принимает и к каким действиям это может привести.
Три уровня неопределенности
Первый уровень — поведение самой модели. Даже одинаковый запрос не всегда дает одинаковый ответ. Это нормальная для языковой модели вариативность, которую необходимо учитывать при проверке ее работы.
Второй уровень — поведение пользователей. Сотрудники находят способы применять удобный инструмент шире, чем предполагалось при запуске. Не обязательно со злым умыслом: задача может измениться, а вместе с ней меняются и данные, которые передают модели. Проверка первоначального сценария уже не описывает фактическое использование системы.
Третий уровень — цепочки и агентские системы. Когда модель получает доступ к инструментам, базам данных и внешним интерфейсам, она перестает быть только средством подготовки ответа. Агент может выбирать дальнейшие действия на основе меняющегося контекста. Поэтому важно понимать не только качество его ответа, но и то, что ему разрешено делать.
В ИБ-проектах Softline мы видим, что риски возникают и вокруг самой модели. Шлюзы, базы знаний, коннекторы и инструменты агентов образуют инфраструктуру со своими настройками и доступами. К поведению модели в контексте добавляются промпт-инъекции, отравление обучающих данных и чрезмерная самостоятельность агентов. Одной проверки модели или одного средства защиты здесь недостаточно: значение имеет вся схема ее работы.
Кто запустил систему и кто за нее отвечает
Защиту ИИ не приходится изобретать с нуля. Сложность часто в том, что о ней вспоминают после запуска, когда система уже обрабатывает рабочие данные и ею пользуются сотрудники.
Типичный сценарий начинается с задачи отдельной команды. Маркетинг, операционный блок или продуктовая команда находит рутинную работу, которую можно упростить с помощью ИИ. Первый прототип появляется быстро. У подразделения есть бюджет, а согласование с ИТ и ИБ кажется лишним: инструмент решает локальную задачу и, как представляется команде, больше никого не затрагивает.
Затем у системы появляются новые пользователи и задачи. Она начинает обрабатывать клиентские данные, получает связи с внутренними сервисами, а иногда и возможность принимать решения или выполнять действия самостоятельно. Таких инструментов в компании может стать несколько, при этом у службы ИБ нет полного перечня. Так формируется теневой ИИ.
Проблема становится особенно заметной при инциденте. Сначала приходится выяснять, кто подключил систему, какие данные в нее передавали, к чему она имела доступ и какие действия могла выполнить. Без этих сведений трудно определить последствия для бизнес-процесса и решить, какие доступы нужно ограничить. Вопрос об ответственности тоже нельзя откладывать до этого момента: у системы должен быть владелец, который знает, как она используется, и отвечает за изменения после запуска.
Для нас в Softline важно начинать работу с инвентаризации. Какие ИИ-системы уже применяются? Для каких задач и кем? Какие данные в них попадают? Есть ли связи с внутренними системами и доступ к инструментам? Честные ответы на эти вопросы, собранные в реестре, дают основу для оценки риска. Пока такой картины нет, невозможно выбрать меры защиты под реальные сценарии работы.
Следующий шаг — определить границы для каждой системы. Какие данные ей можно передавать, какие доступы необходимы для задачи, что агент вправе делать самостоятельно и кто согласует расширение его возможностей. При изменении задачи, состава данных или интеграций эти решения нужно пересматривать. Иначе защищенным остается первоначальный прототип, а не система, которой компания пользуется сейчас.
ИИ может быть полезен бизнесу именно потому, что гибко работает с запросами и контекстом. Управленческая задача состоит в том, чтобы эта гибкость не превращалась в неизвестные ИБ доступы и действия. Для этого служба ИБ должна видеть ИИ-системы с момента их запуска, знать владельца каждой из них и контролировать изменения в данных, интеграциях и степени самостоятельности.
