Архитектурный сдвиг, необходимый для управления агентами ИИ

ИИ больше не является просто чат-ботом, генерирующим текст. В корпоративных средах агенты ИИ выполняют действия, такие как получение конфиденциальных данных, запуск рабочих процессов, вызов инструментов и регистрация активности в различных системах. Автономность полностью меняет обсуждение управления; контроли и процедуры, изначально разработанные для человеческих пользователей и традиционных приложений, не были созданы для управления программным обеспечением, которое может выполнять многоступенчатые действия во время выполнения.

Риск не является теоретическим. Маленькие пробелы в видимости, контроле доступа и аудитности могут быстро накапливаться, превращаясь в сбои во время выполнения, которые трудно обнаружить и еще труднее обратить.

Чтобы идти в ногу с этой новой эрой, управление агентами ИИ не может быть выполнено путем добавления больше документов политики. Для этого требуется управление по дизайну: архитектурный подход, в котором контроли встроены в плоскость управления и обеспечиваются непрерывно во время выполнения. Если агенты будут действовать как цифровые коллеги, они должны унаследовать те же корпоративные ограничения, что и люди, плюс более сильный контроль во время выполнения.

Почему управление ломается в эпоху сходимости

Корпоративная архитектура вступила в эпоху сходимости. Данные и рабочие нагрузки теперь охватывают несколько облаков, частных центров данных и окружений edge.

Существуют организации, которые запускают свои платформы в параллельных системах, потому что они имеют несколько процессов для одновременного управления. Это включает отдельные системы идентификации, пайплайны регистрации, каталоги и утвержденные процессы. Результатом является то, что некоторые называют “платформой Франкенштейна”, где интеграционная нагрузка увеличивается с каждым новым инструментом или облачной средой. На самом деле, эта фрагментация проявляется в повседневной реальности.

Согласно недавнему опросу, 47% респондентов указывают на сложные требования доступа и процессы, а 44% указывают на ограниченную видимость того, где находятся данные, как барьеры для эффективного использования данных.

Именно здесь агенты раскрывают швы между системами.

Чтобы ответить на бизнес-вопрос, агент может потребоваться получить данные из локальной системы ERP, облачного CRM, операционной телеметрии в другом облаке и документов в сотрудничестве. Если организация обеспечивает политику по-разному в каждом месте, агент либо не сможет выполнить задание, либо, что хуже, сможет выполнить его способами, которые вы не можете объяснить или контролировать.

Это момент, когда лидеры корпораций должны обратить внимание. Агенты заставляют поднять планку, требующую согласованности во всех средах и подотчетности во время выполнения.

Управление, по этой причине, выходит на первый план регулирующими органами и службами безопасности. Примером этого является рамка управления рисками ИИ NIST, которая подчеркивает управление рисками на протяжении всего жизненного цикла ИИ, а не только во время его создания. Это напоминание о том, что соблюдение и доверие являются операционными обязанностями, а не одноразовыми проверками.

От политики к платформе

Управление по дизайну означает, что управление перемещается вместе с рабочей нагрузкой, а не реализуется в каждом сегменте. На практике это зависит от трех строительных блоков:

• Единая плоскость управления

Одно место для определения и обеспечения идентификации, доступа, политики, каталогов и полномочий по облакам и центрам данных.

Цель состоит в том, чтобы написать политику один раз и обеспечить ее выполнение где бы ни запускались данные и модели, а не перестраивать системы управления системой за системой. Это предотвращает дрейф поведения агента, когда один и тот же агент ведет себя безопасно в одной среде, но опасно в другой.

Практическая проверка проста: если пользователь не может получить доступ к столбцу, проверьте, что агент, действующий от его имени, также не может получить доступ к нему. Это должно указать на то, выполняются ли написанные политики по всей плоскости.

• Ткань данных, основанная на открытых стандартах

Агентам нужен контекст для работы. Когда этот контекст распределен по разным структурам, принадлежащим разным командам, ткань данных помогает стандартизировать семантику и шаблоны доступа, чтобы агенты не должны были учиться новому набору правил для каждой базы данных.

Открытые форматы таблиц, такие как Apache Iceberg, поддерживают это, позволяя нескольким движкам делиться одной и той же управляемой базой данных без копирования ее в новый сегмент. Это важно, потому что дублирование данных – это место, где управление обычно терпит неудачу. Как только команды начинают копировать “только то, что агенту нужно”, вы создаете новую, менее управляемую среду.

Если агенты могут работать с наборами данных без введения новых пробелов в разрешениях, управление работает так, как предполагалось.

• Наблюдаемость и происхождение в реальном времени

Агенты управляемы только в том случае, если вы можете видеть, что они делают во время выполнения.

Наблюдаемость здесь не является просто “хорошим иметь”, но является основой для контроля во время выполнения и реагирования на инциденты.

Конкретно, необходимо иметь доказательство действий агентов от начала до конца. Агенты должны быть в состоянии доказать действия, такие как какие данные были доступны и какие инструменты были вызваны, и оттуда происхождение может связать выходные данные с входными данными. Это позволяет командам проверять эти решения и устранять неисправности, если необходимо, тем самым доказывая общую соответствие.

Относиться к агентам как к “цифровым коллегам”

Одна из наиболее полезных мысленных моделей – относиться к агентам как к цифровым коллегам.

Вот сравнение, которое разбивает это: как сотрудники имеют доступные бейджи, которые предоставляют доступ к некоторым зданиям и комнатам, но не к другим, управление позволяет агентам иметь доступ с ограничениями. Одним из ключевых дополнений является то, что агенты должны быть осведомлены о том, что им разрешено раскрывать.

Рассмотрим агент поддержки. Он может потребоваться получить доступ к предыдущим случаям поддержки, чтобы решить проблему, но он не может раскрыть конфиденциальные данные другого клиента во время этого. Иначе говоря, агент может использовать ограниченные знания для рассуждения, но все равно должен обеспечивать границы раскрытия. Это не является “проблемой написания подсказок”, которую мы исторически знали, как ориентироваться; вместо этого это проблема идентификации и обеспечения во время выполнения.

Что меняется в 2026 году: агенты переходят от экспериментов к производству

2026 год – это год, когда эксперименты заканчиваются, а агенты занимают место в производстве.

Этот сдвиг заставляет корпорации работать на двух скоростях. Одна – это скорость инноваций, где команды тестируют новые модели, инструменты и рабочие процессы агентов, чтобы получить конкурентное преимущество. А другая – это безопасная скорость, где системы должны соответствовать требованиям соответствия и эксплуатации, которые могут включать строгие контроли доступа и слепые пятна.

Без установленной архитектурной структуры управления эти две скорости будут конфликтовать.

Если команды развертывают этих агентов до того, как они будут управляемы, будет лоскутное одеяло из отдельных контролей и операционных неисправностей. А если происходит обратное, вы получаете режим неисправности, в котором безопасность блокирует все, а инновации перемещаются в тень ИТ, подрывая управление.

Цель состоит не в том, чтобы выбрать скорость. Это построение архитектуры, которая поддерживает обе скорости.

Практический чек-лист для управления агентами во время выполнения

• Если вы строите или масштабируете агентов, важно задать себе следующие вопросы, чтобы выявить, является ли управление действительно архитектурным: Можно ли объяснить, от начала до конца, какие данные агент получил, чтобы произвести ответ или выполнить действие?
• Являются ли решения об доступе последовательными во всех гибридных средах или различаются по платформам?
• Есть ли у вас телеметрия для действий агентов, включая вызовы инструментов, проверки политики и эскалации к людям?
• Можете ли вы ограничить, приостановить или изолировать агент во время выполнения, если он ведет себя неожиданно?
• Есть ли у вас план мониторинга после развертывания, соответствующий вашим регуляторным обязательствам и аппетиту к риску?

Если вы не можете ответить на эти вопросы, относитесь к развертыванию агента как к инциденту, который может произойти в производстве.

Сдвиг управления должен быть архитектурным, или же он не существует

Агенты станут стандартным дополнением к корпоративным операциям. Вопрос в том, станут ли они надежной частью корпоративных операций.

Если агенты не будут управляемы не менее уверенно, чем люди и критически важное программное обеспечение, последствия будут реальными. Мы увидим эти последствия в утечке данных, неисправностях соответствия, операционных сбоев и потере доверия к программам ИИ.

Лидеры должны перестать относиться к управлению агентами как к упражнению по документации. По мере расширения возможностей платформы управление агентами должно быть одним из тех, кто берет на себя надзор за другими ролями. Это означает внедрение контролей в плоскость управления, обеспечение наблюдаемости действий и аудитности решений. А затем масштабирование.

Это то, как вы получаете агентов, которые движутся быстро, не ломая корпорацию.