Прослушать эту статью
0:00 10:57
Когда ИИ-агент наносит ущерб, руководители должны уметь объяснить, почему ему было разрешено действовать. Перед советом директоров, аудитором или регулятором им необходимо доказать, что права, средства контроля и разрешения агента соответствовали масштабу возможных последствий сбоя.
Рассмотрение защитных барьеров как простого переключателя «вкл/выкл» скрывает это решение. Распределение защитных барьеров по уровням риска делает его прозрачным: каждый агент проходит через общий базовый уровень, после чего получает более строгие средства контроля по мере роста его доступа, полномочий и потенциального вреда.
Внутренний агент, работающий только в режиме чтения, создает гораздо меньше рисков, чем тот, который имеет доступ к регулируемым данным, может вызывать привилегированные инструменты, отправлять внешние сообщения или изменять систему учета. Уровень надзора для каждого из них должен отражать эту разницу.
Основные выводы
- Ранжирование защитных барьеров по риску соотносит уровень надзора с масштабом бизнес-воздействия. Самые строгие меры контроля необходимы там, где доступ и полномочия агента создают последствия, которые организации будет трудно сдержать или обратить вспять.
- Каждому агенту необходимы средства контроля на границах ввода и вывода данных. Входные данные включают пользовательские промпты и неавторизованный контент, поступающий через поисковую выдачу, API, инструменты и других агентов.
- Полномочия агента определяют то, что руководству, возможно, придется защищать. Доступ к конфиденциальным данным, внешние коммуникации, системные изменения и финансовые транзакции требуют более пристального контроля.
- Действия с высоким уровнем воздействия требуют жестких ограничений за пределами модели. Лимиты транзакций, разрешения, одобренные получатели и обязательные согласования должны обеспечиваться до выполнения операций.
- Ранжирование барьеров по риску продолжается на протяжении всего жизненного цикла агента. Новые инструменты, разрешения, источники данных и автономность могут изменить уровень подверженности рискам после развертывания.
Почему ваш уровень рисков должен определять уровень защитных барьеров
Ваша организация уже принимает решения о предоставлении доступа на пропорциональной основе. Управление доступом на основе ролей (RBAC), OAuth, классификация данных и политики доступа определяют, кто может получить доступ к системе, что они могут видеть и что могут изменять. Защитные барьеры агентов распространяют эту логику рисков на этап выполнения.
Ранжирование барьеров по риску — это практика сопоставления глубины и размещения средств контроля во время выполнения с доступом агента к данным, разрешениями на инструменты, полномочиями на действия и потенциальными последствиями.
Степень подверженности рискам может меняться по мере развития рабочего процесса. Чтение утвержденного документа несет один уровень риска. Передача информации в инструмент, который обновляет запись о клиенте или инициирует транзакцию, повышает ставки. Каждое новое разрешение расширяет круг последствий, которые организации, возможно, придется объяснять после инцидента.
Начните с общего базового уровня. Добавьте меры принудительного контроля там, где агент получает доступ к конфиденциальной информации или полномочия производить значимые результаты. Защитные барьеры снижают вероятность и impacto небезопасного поведения, но ни один набор элементов управления не может предотвратить все сбои.
Ответственность руководства заключается в том, чтобы показать: уровень надзора был осознанным, пропорциональным и утвержденным до того, как агент начал действовать.
Установите минимальный уровень, который должен пройти каждый агент
Каждому агенту необходим контроль над информацией, поступающей в рабочий процесс, и значимым контентом, покидающим его.
Первоначальный запрос пользователя — это лишь одна граница ввода. Как только агент начинает извлекать документы, собирать данные со страниц, вызывать API, взаимодействовать с инструментами или обмениваться информацией с другими агентами, каждый результат становится новым источником потенциально недоверенного ввода. Извлеченный документ или ответ инструмента могут содержать вредоносные или противоречивые инструкции, точно так же, как и промпт пользователя. Это область косвенных инъекций промптов, которую должны охватывать граничные элементы управления.
Для внутреннего агента, работающего только в режиме чтения с утвержденной информацией, эти средства контроля могут покрыть большую часть соответствующих рисков. Как только агент задействует привилегированные инструменты или предпринимает действия, одних граничных проверок становится недостаточно для устранения разрыва между тем, что агент получает, и тем, что он делает в конечном итоге.
Руководители должны знать, где начинаются эти пробелы, потому что именно там расширяется ответственность организации.
Что вам придется объяснять, когда что-то пойдет не так
Как только агент выходит за рамки задач, связанных только с чтением, его инструменты становятся одним из самых четких индикаторов бизнес-рисков. Права на запись в производственные базы данных, внешние коммуникации, финансовые транзакции, выполнение кода и конфиденциальные персональные данные — все это увеличивает тяжесть последствий неправильного решения.
Для инструментов с более высоким уровнем риска защитные барьеры должны оценивать предлагаемые действия до их выполнения. Неуспешные проверки требуют четкой реакции, такой как блокирование действия, использование более безопасного резервного варианта или эскалация уполномоченному лицу.
Организации также необходима запись о том, какой инструмент был вызван, какие разрешения были активны, какие проверки политик выполнялись и что изменилось в результате. Без этих доказательств руководители могут знать, что что-то пошло не так, но не смогут объяснить, каким образом агенту было разрешено это сделать.
Чтобы определить, насколько глубоким должен быть этот контроль, оцените каждого агента по пяти критериям:
- К каким данным он имеет доступ? Публичная или уже классифицированная информация создает иные риски, чем данные клиентов, финансовые, кадревые, медицинские или другие конфиденциальные данные.
- Что он может записывать, выполнять или инициировать? Доступ на чтение несет меньше операционных полномочий, чем разрешение на изменение систем учета, выполнение кода, связь с клиентом или инициирование транзакции.
- В рамках каких полномочий он работает? Более широкие разрешения и повышенный уровень доступа увеличивают спектр и серьезность действий, доступных агенту.
- Насколько обратимы его действия? Сгенерированная сводка обычно может быть отклонена. Платеж, удаленная запись, измененное право или внешнее сообщение могут быть гораздо труднее отменить.
- Как далеко может распространиться сбой? Изолированная ошибка имеет иной профиль риска, чем действие, затрагивающее последующие системы, клиентов, бизнес-процессы или других агентов.
Эти вопросы переводят техническую инвентаризацию в плоскость управленческого решения о том, какие последствия организация готова принять.
Решите, какие действия требуют жесткого ограничения
Проверки на основе моделей хорошо работают там, где элемент управления требует интерпретации. Они могут выявлять инъекции промптов, небезопасный контент, отклонения от темы или контекстно-зависимые нарушения политик.
Жесткие бизнес-ограничения требуют детерминированного контроля вне модели. Перед выполнением высокоэффективного инструмента проверки политик могут подтвердить разрешения, лимиты транзакций, одобренных получателей, обязательные поля, классификацию данных, списки разрешенных элементов и требования к утверждению.
Модель может предложить действие. Детерминированная политика определяет, разрешено ли это действие. Когда последствия трудно обратить вспять, уполномоченное лицо может принять окончательное решение.
Инвестируйте в надзор там, где сбой обходится дороже всего
Каждая проверка политики требует времени, вычислительных ресурсов или человеческого внимания. Руководители должны распределять этот надзор в соответствии с рисками.
Низкорисковому агенту суммирования может потребоваться легкая проверка ввода и вывода. Множественные шлюзы согласования будут расходовать ресурсы на проверку, не покрывая при этом риски, которые этот агент не создает.
Агент, который изменяет клиентские записи, осуществляет внешние коммуникации или инициирует транзакции, требует иного подхода к расчетам. Проверка разрешений и предполагаемых действий требует времени, но альтернативой могут стать несанкционированная запись, утечка данных, расследование, устранение последствий или внимание со стороны регулирующих органов.
Ранжирование рисков с помощью защитных барьеров делает это распределение очевидным. Самые строгие меры контроля необходимы там, где сбой будет труднее всего локализовать, обратить вспять или объяснить.
Практичный способ распределения контроля
Предприятиям не нужно внедрять универсальную таксономию. Задача заключается в том, чтобы соотнести реальные возможности агента с соответствующим уровнем контроля.
Практичная модель ранжирования рисков защитных барьеров может выглядеть следующим образом:
Предоставление существующему агенту прав на запись, подключение нового сервера Model Context Protocol (MCP) или расширение его прав доступа к данным могут изменить его профиль риска, даже если модель и промпт остаются прежними.
Ранжирование рисков защитных барьеров продолжается на протяжении всего жизненного цикла агента. Каждое изменение в доступе, инструментах или уровне автономности должно вызывать необходимость принятия решения о том, способна ли организация по-прежнему обеспечивать существующий уровень надзора.
Создайте отчет, который можно отстоять
Уровень риска имеет малую ценность, если никто не может доказать, кто его назначил, какие средства контроля он требует и кто может вмешаться. Прежде чем агент попадет в продакшен, создайте управленческий отчет, который сможет изучить совет директоров, аудитор, регулятор или группа реагирования на инциденты.
- Укажите ответственное лицо и утверждающий орган. Определите, кто отвечает за производительность и риски агента, кто утвердил его операционный объем и кто может изменить или отозвать это утверждение.
- Задокументируйте, к чему агент имеет право получать доступ и что он может делать. Зафиксируйте данные, инструменты, API и нижестоящие системы, к которым он может обращаться, а также то, что он может читать, записывать, выполнять или инициировать.
- Запишите уровень риска, средства контроля и обоснование. Укажите, почему агент получил такую классификацию, какие средства контроля на уровне входа, выхода и инструментов применяются, и кто подписал это решение.
- Определите жесткие ограничения и полномочия по эскалации. Укажите, какие действия требуют детерминированного контроля или одобрения человека. Назовите тех, кто может проводить расследования, ограничивать разрешения, инициировать перехват управления, откатывать релиз или приостанавливать работу агента.
- Установите триггеры проверок и требования к доказательствам. Определите, что должно сохраняться для аудита и расследования. Новые инструменты, более широкие разрешения, другие источники данных и повышенная автономность должны вызывать необходимость переоценки.
Этот отчет дает руководству больше, чем просто доказательство существования средств контроля. Он показывает, как организация связала полномочия с надзором и кто взял на себя ответственность за это решение.
Убедитесь, что средства контроля работают
Назначение уровня риска устанавливает необходимые средства контроля. Руководству по-прежнему нужны доказательства того, что эти средства работали должным образом.
Эти доказательства получаются путем отслеживания вызовов инструментов, контекста удостоверений и разрешений, принятия политик, нижестоящих действий и событий эскалации. Вызов инструмента может удовлетворять техническому интерфейсу, но нарушать бизнес-правило. Действие может выполняться в неверном контексте разрешений. Агент может регулярно сталкиваться с условиями, которые должны вызывать проверку человеком.
Эти паттерны становятся заметными, когда организация может отслеживать поведение по всему пути выполнения. Полученный отчет помогает руководству ответить на конкретные вопросы: какая учетная запись авторизовала действие? Какая политика применялась? Получал ли агент исключение? Кто был уведомлен? Что изменилось в нижестоящих системах?
Руководству нужны доказательства, которые оно может предоставить во время аудита или после инцидента — не описание средств контроля, которые должны были работать, а запись того, что произошло на самом деле.
Для более глубокого изучения практик наблюдаемости и мониторинга, которые поддерживают актуальность системы, прочитайте материал «Работайте уверенно: наблюдаемость и мониторинг агентов для корпоративного ИИ».
Часто задаваемые вопросы
Что такое ранжирование рисков защитных барьеров?
Ранжирование рисков защитных барьеров — это метод сопоставления глубины и размещения средств контроля выполнения с рисками, создаваемыми доступом к данным, разрешениями, инструментами, действиями и нижестоящим влиянием ИИ-агента. Возможности с более высоким уровнем риска получают дополнительные средства контроля ближе к моменту выполнения.
Какие защитные барьеры должны быть у каждого ИИ-агента?
У каждого агента должен быть минимальный набор средств контроля в отношении информации, поступающей в рабочий процесс, и важных результатов, покидающих его. Средства контроля входных данных должны охватывать как исходный запрос пользователя, так и извлеченные документы, ответы API, результаты работы инструментов и другой ненадежный контекст, вводимый во время выполнения.
Когда ИИ-агенту необходимы средства контроля на уровне инструментов?
Средства контроля на уровне инструментов приобретают все большее значение, когда агент может получать доступ к конфиденциальным данным, осуществлять запись в системы учета, взаимодействовать с внешними ресурсами, выполнять код, инициировать транзакции или запускать другие важные рабочие процессы. Действия с более серьезными последствиями также могут требовать детерминированного соблюдения политик или одобрения человека перед выполнением.
Устраняют ли защитные барьеры ИИ риски агентов?
Нет. Защитные барьеры снижают вероятность и потенциальное воздействие небезопасного или несанкционированного поведения. Командам по-прежнему необходимы соответствующие разрешения, наблюдаемость, тестирование, аудируемость, процедуры эскалации и постоянный пересмотр для управления остаточными рисками.
Когда следует переоценивать уровень риска защитных барьеров агента?
Переоценивайте ранжирование рисков защитных барьеров всякий раз, когда агент получает новые инструменты, разрешения, источники данных, рабочие процессы или автономность. Изменения в подключенных системах могут изменить уровень риска, даже если модель, промпты и основная логика агента остаются прежними.