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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Фабрика данных, основанная на открытых стандартах

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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