«Управление» стало обязательным элементом маркетинговых заявлений об ИИ в корпоративном секторе. Вендоры систем управления доступом, безопасности, оркестровки, инфраструктуры и платформ данных предлагают продукты для обеспечения безопасности агентов, управления ими и контроля. Это привлекает заслуженное внимание к проблеме, которую предприятиям необходимо решать. Поскольку масштаб заявлений растет, директорам по информационным технологиям и руководителям подразделений рисков необходимо точнее понимать, за что именно они платят.
Если присмотреться к этим предложениям, их возможности различаются. Некоторые ограничивают доступ агента, тестируют его поведение перед запуском или собирают записи для аудита. Ваши риски зависят от того, как связаны эти возможности и где заканчивается зона их покрытия. Оценка вендора должна показать, распространяются ли элементы контроля на ваших агентов, применяются ли ваши бизнес-правила и продолжают ли они работать по мере изменения того и другого.
Один этаж, ни одного цикла
Средства контроля в таком стеке проверяют поведение, ограничивают доступ, останавливают активность и документируют результаты. Каждое из них служит важной цели и имеет границы, которые заявления об управлении должны четко обозначать.
Стоит опасаться шаблона «один этаж и ни одного цикла»: это полезная функция, преподносимая как полноценное управление, но с минимальной ясностью относительно того, что происходит после развертывания. Стек без жизненного цикла неполноценен. Покупателям нужны доказательства того, что средства контроля останутся эффективными по мере изменения агентов, правил и среды.
Два пробела заслуживают особого внимания.
- Первый — это отсутствие фундамента: неполное представление о том, какие агенты существуют и к чему у них есть доступ. Платформа может жестко контролировать зарегистрированных агентов, оставляя незарегистрированных без присмотра. Такие неизвестные агенты могут раскрыть клиентские данные, не столкнувшись ни с одним из проверенных вами средств контроля.
- Второй — отсутствие жизненного цикла. После того как агент проходит проверку перед запуском, кто-то может подключить другой инструмент, заменить его модель или расширить его разрешения. каждое такое изменение способно повлиять на поведение и защиту. Утвержденное в прошлом разрешение мало говорит о текущем уровне риска агента.
Пробел в жизненном цикле работает в обе стороны. Ограничение, введенное без тестирования, может нарушить нормальную работу, в результате чего команда отключит его для восстановления работоспособности сервиса. Управление должно учитывать это давление посредством тестирования, авторизованных изменений и проверок работоспособности защиты.
Фундамент и непрерывный жизненный цикл
Фундамент начинается с реестра: актуального учета каждого агента и его структуры, включая модель, инструменты, учетные записи, через которые он действует, и данные, к которым он имеет доступ. Когда торговый агент получает доступ к другой базе данных клиентов, его владелец должен видеть это изменение и проверять соответствующие разрешения.
Каждому агенту также необходима уникальная идентификация, чтобы проверяющие могли отслеживать его действия отдельно от действий его разработчика. С таким фундаментом управление превращается в цикл, который работает до тех пор, пока функционирует сам агент.
Жизненный цикл охватывает пять этапов использования агента:
- Определение задает правила работы агента на основе существующих бизнес-обязательств и принятых решений о рисках. Для торгового агента эти правила определяют, какие клиентские записи он может использовать, с какими сервисами может связываться и какие действия требуют утверждения.
- Тестирование проверяет агента на соответствие этим правилам перед выпуском и после значимых изменений. Тест должен подтвердить, что торговый агент может выполнить одобренный запрос клиента и при этом противостоять инструкциям по отправке защищенных данных в другое место.
- Принудительное исполнение применяет правила в процессе работы агента. Инструмент мониторинга фиксирует запрещенную передачу данных и сообщает о ней службе безопасности уже постфактум. Средство контроля принудительного исполнения предотвращает передачу данных по неконтролируемому маршруту. Покупателям необходимо знать, какие действия продукт может предотвратить, а о каких — только сообщить.
- Доказательство сохраняет свидетельства о том, что произошло и почему. В случае с попыткой передачи данных это означает идентификацию агента, правила, которое заблокировало действие, а также любых подтверждений или отмен, повлиявших на решение.
- Адаптация обновляет средства контроля по мере изменения агентов, требований и среды. Если торговый агент получает новый сторонний инструмент, его разрешения требуют проверки, а средства защиты — повторного тестирования. Это изменение возвращает процесс в начало цикла.
15 вопросов, которые стоит задать любому вендору систем управления ИИ
Эти вопросы охватывают весь жизненный цикл управления — от фундамента, обеспечивающего видимость агентов, до процесса, поддерживающего их соответствие правилам. Сегодня ни один вендор не отвечает на все 15 вопросов, и любая компания, утверждающая обратное, либо слишком узко определяет управление, либо продает вам дорожную карту на будущее. Ваша задача — не найти идеальный результат, а оценить покрытие, направление и архитектурное соответствие вашим операционным требованиям.
Задавайте эти вопросы каждому вендору. Привязывайте ответы к вашим рабочим процессам и операционным средам. Зафиксируйте, что работает уже сейчас, для чего требуются дополнительные инструменты и чем ваша команда будет управлять самостоятельно после развертывания. Ответы с пометкой «флаг» указывают на утверждения, которые требуют более пристального внимания.
Фундамент: реестр агентов и идентификация
1. Можете ли вы показать нам каждого работающего агента, из чего он состоит и когда меняется его структура?
Агент может получить доступ к конфиденциальным клиентским данным уже после первоначального утверждения, подвергая бизнес рискам из-за изменений, которые никто не проверял. Запросите реестр, который отслеживает модели, инструменты, доступ к данным и учетные записи, с отчетами об изменениях для ответственного владельца. Покупатели могут услышать термин «спецификация материалов ИИ» (AI-BOM). Спросите, как агенты, созданные в других местах, попадают в реестр и как обнаруживаются незарегистрированные агенты.
Флаг: Вендор заявляет о видимости всех ваших агентов, но описывает только те, что созданы на его собственной платформе.
2. Есть ли у каждого агента собственная идентичность, отдельная от человека, который его создал?
Агенты, действующие через общие учетные записи сотрудников, лишают следователей возможности отделить действия агента от решений конкретного человека. Попросите вендора показать, как сохраняется отслеживаемость активности, когда разработчик меняет роль или уходит из компании.
Флаг: Прослеживаемость зависит от учетной записи разработчика. Если этот человек увольняется или меняет роль, цепочка аудита прерывается.
Определение: бизнес-правила и требования соответствия нормативным требованиям
3. Можем ли мы применять наши существующие правила и использовать уже имеющиеся инструменты управления рисками и комплаенса?
Раздельные своды правил могут привести к тому, что руководство по рискам одобряет одно ограничение, в то время как агенты действуют на основе других принципов. Спросите, как существующие требования транслируются на уровень контроля агентов и как собранные свидетельства возвращаются в текущие системы команды.
Флаг: Интеграция означает ручное копирование данных между системами без процесса синхронизации правил и доказательств.
4. Какие нормативные фреймворки поддержи «из коробки» и как собранные доказательства соотносятся с их требованиями?
Аудит может застопориться, если журналы активности не дают ответа на вопрос о конкретном требовании. Спросите, какие обязательства в рамках Закона об ИИ ЕС (EU AI Act) или рекомендации из Фреймворка управления рисками ИИ NIST поддерживаются. Запросите пример, связывающий требование, средство контроля и подтверждающие доказательства.
Флаг: Вендор утверждает, что логи готовы к аудиту, но не может показать, какому именно требованию соответствует конкретная запись в журнале.
Тест: поведение агента и эффективность средств контроля
5. Как мы можем попытаться заставить агента вести себя неправильно перед запуском?
Предвзятые ответы, вымышленная информация или агент, подвергшийся манипуляциям посредством внедрения промптов (prompt injection), могут подвергнуть клиентов риску. Потребуйте показать результаты намеренных попыток заставить агента нарушить его собственные правила, а также уточните, блокирует ли неудачный тест релиз.
Признак: Поставщик демонстрирует успешные результаты стандартных тестов, но не предоставляет доказательств намеренных попыток взлома агента.
6. Каков план действий на случай, если изменение правил приводит к сбоям?
Ограничение, призванное защитить клиентские данные, может вызвать сбой в работе, если оно также блокирует утвержденные рабочие процессы. Узнайте, как быстро можно восстановить предыдущее состояние, кто получает уведомления и что делает поставщик для изоляции изменений правил от работающих агентов. Затем спросите, какие меры предпринимает поставщик для снижения этого риска до применения правил: поэтапное внедрение (staging), ограничение области применения изменений на подмножество агентов или тестирование на записанном трафике.
Признак: Единственный ответ поставщика — применить изменение и следить за возможными проблемами.
Обеспечение соблюдения: предотвращение, границы и исключения
7. Если наш агент по продажам попытается отправить клиентские данные во внешний инструмент, что остановит его до того, как данные покинут систему?
Предупреждение, полученное после того, как передача уже произошла, означает, что вам придется иметь дело с инцидентом безопасности данных. Попросите продемонстрировать превентивные меры и предоставить четкий отчет о том, какие именно передачи продукт способен только фиксировать в отчетах. Уточните, какие средства контроля или дополнительные инструменты необходимы для вашего рабочего процесса.
Признак: Поставщик заявляет о полной видимости, но не может показать, что именно предотвращает передачу, а лишь то, что фиксирует ее в отчетах.
8. Где находятся ваши средства контроля и что остается за их пределами?
Заблокированная передача данных через одно соединение все равно может обернуться инцидентом, если агент доберется до того же пункта назначения по другому маршруту. Попросите поставщика задокументировать, где заканчиваются полномочия каждого средства контроля и за какую защиту за этими пределами отвечает покупатель.
Признак: Поставщик утверждает, что весь трафик контролируется, но не может указать, какие соединения проходят через средства контроля, а какие нет.
9. Что происходит, когда средство контроля дает сбой или кто-то отключает его?
Вышедшее из строя средство контроля может обнажить данные, а необъяснимая остановка — прервать обслуживание. Уточните, останавливается ли агент, продолжает ли работу или запрашивает одобрение; кто получает уведомление; и каким образом санкционируется и регистрируется любое отключение. Попросите поставщика объяснить, что происходит с уже выполняющейся работой.
Признак: Поставщик говорит, что администратор может отключить функцию, но не может объяснить, что происходит с текущими задачами или как фиксируется такое решение.
Подтверждение: доказательства и подотчетность
10. Можете ли вы объяснить то или иное действие или заблокированную попытку, включая агента, правила и стоящие за этим согласования?
Руководству и проверяющим необходимо понимать, почему то или иное действие было разрешено и кто санкционировал исключения. Запись должна указывать версию правила и предоставлять проверяющим достаточно контекста для оценки того, была ли блокировка обоснованной или она прервала законную работу.
Признак: В журнале указано, успешно ли прошло действие, но не указано, какое правило применялось или кто одобрил исключение.
11. Как мы узнаем, что средство предотвращения вышло из строя незаметно?
Команда может быть уверена в своей защищенности, поскольку оповещения продолжают поступать, даже если блокирующий элемент за ними не работает. Спросите, какие доказательства подтверждают, что работает именно предотвращение (а не только обнаружение), как информация о разрыве между ними доходит до ответственного лица и как выглядит последняя проверка.
Признак: Поставщик указывает на зеленую панель мониторинга, но не может предоставить доказательств того, что функции предотвращения, а не просто мониторинга, активны.
Адаптация: изменения и авторизация
12. Когда требуется срочное ограничение, каков самый быстрый путь к его внедрению?
Критически важное ограничение может затянуться, если каждое изменение требует простоя или повторного развертывания. Уточните, какие обновления вступают в силу во время работы, а какие требуют окна обслуживания. Попросите поставщика разобрать сценарий, требующий быстрой реакции (например, блокировку недавно обнаруженной уязвимости данных), и объяснить, сколько времени занимает внедрение с момента принятия решения.
Признак: Поставщик не может описать шаги или временные рамки применения срочного ограничения.
13. Кто может одобрять, изменять или отзывать разрешения агента, и фиксируется ли каждое изменение?
Нечеткое разграничение полномочий может оставить конфиденциальный доступ открытым после отпадения бизнес-необходимости. Запросите историю согласований, информацию о том, как уполномоченный владелец может отозвать доступ и когда этот отзыв вступает в силу.
Признак: Поставщик говорит, что владелец может удалить доступ, но не может показать, кто обладает такими полномочиями и как фиксируется отзыв.
В различных средах: согласованность и переносимость
14. Действуют ли те же правила, средства контроля и доказательства в нашем облаке, дата-центре и изолированных системах?
Неравномерная защита может оставить дата-центр или удаленный сайт уязвимыми при использовании политики, которая работает в облаке. Пройдите один и тот же рабочий процесс через каждую среду. Уточните, что обеспечивает соблюдение правил при недоступности внешних сервисов, где хранятся записи и как они передаются группе по управлению рисками в дальнейшем. Включите в рассмотрение агентов, созданных вне платформы поставщика. Попросите поставщика определить, что работает сегодня, а что требует дополнительных средств контроля или переработки.
Признак: Поставщик заявляет о полной поддержке облака, но переносит другие среды в план развития (roadmap).
15. Насколько все зависит от вашей инфраструктуры и что мы можем забрать с собой при переходе?
Смена платформы может прервать соблюдение требований или сделать исторические свидетельства непригодными для использования во время аудита. Уточните, какие правила, согласования и записи остаются применимые в других местах, а какие средства контроля требуют замены. Запросите пример того, что можно экспортировать и что потребуется сделать вашей команде для этого. Если вы замените модель или фреймворк, использованный для создания агента, какие правила и доказательства останутся действительными, а что потребует повторного тестирования?
Признак: Поставщик говорит, что вы можете экспортировать свои данные, но не может показать, остаются ли политики и аудиторские записи применимыми за пределами их платформы.
Попросите каждого поставщика задокументировать то, что его продукт не покрывает. Явное ограничение — это то, к чему можно подготовиться. Оставшийся без ответа вопрос — это нерешенный риск.
Где прекращается управление в рамках одной среды
Управление, встроенное в платформу агента, сокращает объем работы по интеграции и держит средства контроля близко к агенту. Вопрос в том, насколько далеко простирается это покрытие. Управление, ограниченное одной средой, оставляет вашу команду ответственной за защиту за ее пределами.
Представьте страховую компанию со службой поддержки клиентов в облаке и данными о претензиях в собственном дата-центре. Если она переносит агента в дата-центр или добавляет агента, созданного в другом месте, проверкой станет то, распространяются ли на них те же правила, механизмы обеспечения их соблюдения и доказательства. На изолированных объектах средства контроля должны работать без внешних сервисов, а записи должны храниться локально до тех пор, пока их можно будет передать.
Страховая компания должна определять политику, владеть своими данными и сохранять и то, и другое при смене инфраструктуры. Спросите, что останется пригодным для использования, а что потребует переработки. Интегрированное управление должно поддерживать ваши правила и ваши доказательства во всех средах, где работают ваши агенты.
Установление стандарта для управляемых агентов
У управляемого агента должен быть идентифицируемый владелец, актуальная запись в реестре и прослеживаемый набор правил. Ваша организация должна уметь демонстрировать, как эти правила тестируются и применяются, объяснять зафиксированные решения и поддерживать работоспособность процесса по мере изменения агента. Этот стандарт применим везде, где работает агент.
Контрольный список задает минимальный стандарт оценки для всего процесса управления. Отсутствие ответа на вопрос указывает на задачу, у которой должен быть владелец, на элемент контроля, который необходимо обеспечить, или на решение о развертывании, требующее проверки. Поставщики должны четко обозначать свой вклад и ограничения, чтобы ваша команда могла с ними работать.
Начните с одного агента, который работает с важными данными или выполняет значимые действия, и пройдите с ним весь жизненный цикл в тех средах, где он запускается. Изучение подтверждающих материалов на каждом этапе покажет, где ваше управление работает, а где остаются риски. Разрыв между заявлениями об управлении и его практической реализацией — это источник корпоративных рисков.
Узнайте, как DataRobot определяет единую политику и обеспечивает ее соблюдение на протяжении всего жизненного цикла агента.
