Чего не хватает корпоративным agentic AI: слой оркестрации и governance
AI-фреймворки для агентов не были созданы для проверки каждого действия на соответствие политикам и требованиям комплаенса. Для этого нужен отдельный слой.
За последний год экосистема корпоративного ИИ получила огромный набор возможностей, но ноль согласия о том, как этим управлять.
Разработчики теперь располагают внушительным набором инструментов для создания AI-агентов: frameworks от OpenAI, Claude tooling от Anthropic, LangChain, LangGraph, CrewAI, Microsoft AutoGen и растущий список альтернатив. Каждое решение обещает координировать цепочки рассуждений, управлять многошаговым выполнением задач и подключать агентов к инструментам и API. Для экспериментов прогресс оказался значительным. Команды теперь могут собирать сложные agent workflows за дни там, где два года назад на это уходили месяцы.
Но я видел этот паттерн и раньше. За более чем два десятилетия работы с distributed systems platforms я наблюдал один и тот же сценарий почти при каждом крупном инфраструктурном сдвиге: инструменты для потребления новой возможности появляются раньше, чем инфраструктура для её управления. Разрыв не сразу заметен в средах разработки. Он становится очевиден в production.
Именно там сегодня и находится enterprise AI.
Что не умеют agent frameworks
Современные agent frameworks по сути являются системами координации. Они определяют, что система должна делать: какие инструменты вызывать, как выстраивать последовательность задач, как делегировать работу между агентами. Это сложная работа, и с ней они стали справляться довольно хорошо.
Но они редко отвечают на вопрос, где этим задачам разрешено выполняться и при каких условиях.
Возьмём на первый взгляд простой workflow: суммировать customer support transcripts с помощью LLM. В development environment реализация выглядит чисто: агент вызывает API модели, передаёт транскрипт и возвращает summary. Но в production в enterprise тот же запрос может затрагивать dataset, который нельзя выводить за пределы конкретного географического региона, model, не одобренную для regulated data, и audit requirement, который требует трассируемой записи о том, что произошло.
Это не проблемы планирования, для которых был создан agent framework. Это проблемы execution governance. Большинство frameworks молчаливо предполагают, что кто-то решает их где-то в другом месте стека. Во многих enterprise-средах этого не делает никто. Gartner прогнозирует, что к концу 2027 года будет отменено более 40% проектов в области agentic AI, и называет недостаточный risk control одной из главных причин провала — именно этот разрыв и отражает цифра.
Что на самом деле делает отсутствующий слой
Чтобы закрыть эти governance-проблемы, нужен дополнительный слой между agent logic и execution: он оценивает каждое действие агента с точки зрения политик о том, где могут находиться данные, какие models могут их обрабатывать, кто authorized запрос и как действие вписывается в организационный контекст. Agent framework определяет, что система должна сделать. Orchestration layer определяет, можно ли и где это может произойти. Разделение этих обязанностей позволяет обоим слоям развиваться независимо. Это также означает, что можно внедрять новые agent frameworks без перестройки модели governance с нуля.
Это разделение будет знакомо всем, кто работал в эпоху Kubernetes. Kubernetes не интересует, что находится внутри вашего контейнера. Он находит capacity, распределяет ресурсы и следит, чтобы всё работало. Orchestration layer для agentic AI играет аналогичную роль: ему не важно, какой agent framework сгенерировал запрос. Он обеспечивает условия, при которых этот запрос может выполняться.
Более богатые модели авторизации
Традиционный enterprise access control строится вокруг простого вопроса: может ли user X получить доступ к resource Y? Для автономных агентов этого недостаточно.
Реалистичное authorization decision для агентского запроса может выглядеть так:
request = {
"agent": "support-summary-agent",
"task": "summarize",
"dataset": "customer_support_logs",
"model": "external_llm_api",
"delegated_by": "user_4821"
}
policy = evaluate_policy(request)
if policy.allowed:
route_to_execution(policy.execution_environment)
else:
raise AuthorizationError(policy.reason)
Policy engine здесь оценивает классификацию dataset, статус одобрения model, правила географической обработки и chain of delegation, который инициировал запрос. Это может означать перенаправление задачи во внутренний inference cluster вместо публичной API-конечной точки либо блокировку запроса, если compliant execution environment не существует. С точки зрения агента задача всё равно выполняется. Orchestration layer гарантирует, что она запускается в среде, соответствующей enterprise policy.
Почему ontologies — это несущая инфраструктура
Чтобы orchestration layer принимал правильные решения, ему недостаточно просто размечать данные. Он должен понимать, как связаны между собой entities, участвующие в запросе, и рассуждать над этими связями, чтобы определить, что разрешено.
Снова рассмотрим пример с customer support transcript. Metadata подсказывает, что dataset содержит PII (personally identifiable information). Ontology позволяет системе рассуждать по связанному графу: задача работает с dataset, содержащим personal data; эти данные регулируются GDPR; политика организации требует обработки в одобренной EU environment; выбранная model работает за пределами этой границы. Из этих четырёх связанных фактов orchestration layer может сделать вывод, что запрос нужно перенаправить или заблокировать. Система рассуждала по отношениям между сущностями, а не сверялась с жёстко заданным правилом, привязанным к конкретному dataset.
Именно это делает enforcement policy, execution routing, data locality и audit decisions вычислимыми в runtime. Ontology можно построить почти для любого набора entity-relationship, который enterprise должен контролировать: datasets, models, agents, users, regulations, tasks, environments. Важны те отношения, которые определяют решения, нужные governance layer. Access control lists могут ограничить, кто трогает ресурс, но они не умеют рассуждать по связанному набору entities. Именно на такое рассуждение опирается orchestration layer.
Провенанс решений как обязательное требование
Enterprise-системам также нужна auditability. Когда автоматизированные агенты запускают действия в нескольких системах, организация должна уметь восстановить путь решения, который привёл к результату. От этого зависит compliance. От этого зависят incident response и базовое операционное доверие.
Orchestration layer создаёт записи, описывающие инициирующую identity, агента, модель, источники данных, политики, проверенные во время авторизации, и практически всё остальное, что организация решит сохранять в своей ontology. Эта chain of custody позволяет командам расследовать инциденты и подтверждать compliance, не превращая production AI systems в операционные black boxes.
Регуляторы и аудиторы больше не удовлетворяются знанием того, что AI system должен был делать по замыслу. Им нужен фактический след того, что система сделала в конкретном случае, на каком основании и с каким эффектом — то, чего не дают dashboards, но что может обеспечить хорошо спроектированный orchestration layer. EU AI Act делает это явным: согласно Article 12 и Article 17, high-risk AI systems должны вести документацию, делающую решения traceable и auditable, с записями, достаточными для последующего расследования.
Что это значит для enterprise-команд
Agent frameworks будут продолжать улучшаться. Проблемы координации, которые они решают, реальны, и экосистема будет зрелеть дальше. Но архитектурная задача для enterprises сместилась. Речь уже не в первую очередь о координации агентов. Речь об управлении тем, как эти агенты взаимодействуют с реальной инфраструктурой, реальными данными и реальными обязательствами по compliance.
Паттерны для этого уже существуют: contextual authorization, enforcement of data locality, ontology-aware policy evaluation, decision provenance. Чего не хватает большинству организаций, так это признания, что эти возможности должны жить в отдельном слое, который работает независимо от того, какой agent framework находится над ним. Постройте этот слой, и всё остальное станет управляемым.
—
New Tech Forum — площадка, где технологические лидеры, включая вендоров и других внешних авторов, могут подробно обсуждать новые enterprise-технологии. Отбор материалов субъективен и основан на технологиях, которые редакция считает важными и наиболее интересными для читателей InfoWorld. InfoWorld не принимает маркетинговые материалы к публикации и оставляет за собой право редактировать весь присланный контент. Все вопросы направляйте на doug_dineley@foundryco.com.
Материал — перевод статьи с английского.