## Управляемая экосистема для корпоративного ИИ
Корпоративный ИИ перешел от стадии пилотных проектов к производственной эксплуатации быстрее, чем большинство программ управления успевали за этим следить. Агенты теперь работают во всех основных облачных средах и у всех поставщиков моделей, создаваясь центральными командами, бизнес-подразделениями и разработчиками. Каждый из них рассуждает с помощью моделей, вызывает инструменты, считывает данные и все чаще передает работу другим агентам.
ServiceNow Super Intelligence Control Tower — это ответ от ServiceNow: центральный хаб для обнаружения, защиты, управления, наблюдения и измерения показателей ИИ в любой системе, у любого агента или ресурса на предприятии.
Альянс Control Tower Alliance расширяет этот хаб до масштабов более крупной экосистемы управления ИИ. Это означает интеграцию с самими поставщиками вывода (инференса), платежами и монетизацией, безопасностью и — в случае с Kong — с обеспечением связности ИИ (AI Connectivity).
Этот альянс важен, потому что он принимает то, о чем индустрия долго не решалась сказать вслух. Как выразился Амит Завери (Amit Zavery), президент, директор по продуктам и главный операционный директор ServiceNow, в сегодняшнем анонсе: «Ни одно решение, каким бы мощным оно ни было, не способно видеть все и защитить все в одиночку». Управление ИИ теперь является проблемой уровня всей экосистемы. Компании, которые создают модели, управляют облаками, защищают агентов и связывают их между собой, должны работать сообща вокруг единой системы учета, чтобы клиенты получали средства управления с первого дня, а не надстраивали их задним числом.
## Диспетчерский пункт хорош лишь настолько, насколько он способен видеть... и обеспечивать соблюдение правил
Метафора диспетчерского пункта очень удачна, поэтому к ней стоит отнестись серьезно. Диспетчерский пункт в аэропорту не просто ведет реестр воздушных судов и пилотов. Он видит воздушное пространство в режиме реального времени, каждый полет на радаре, и может направить любой из них в любой момент. Его полномочия проистекают из этого обзора в реальном времени.
Управление ИИ работает точно так же. Большинство предприятий сегодня могут записать свою политику в отношении ИИ: какие модели одобрены, к каким данным агент может прикасаться, кто владеет каждой системой и сколько команда может потратить. Гораздо меньше тех, кто может доказать, что эта политика соблюдается для каждого запроса в реальном времени. И еще меньше тех, кто действительно может *применять* эту политику для каждого запроса.
Самые сложные аспекты управления происходят в тот момент, когда агент обращается к модели, вызывает инструмент, считывает данные или передает управление другому агенту. Диспетчерский пункт, который не способен видеть эти моменты или реагировать на них, **осуществляет управление лишь на бумаге**.
Именно поэтому Kong и ServiceNow состоят в этом альянсе вместе. ServiceNow обеспечивает организационный взгляд: инвентаризацию ИИ-ресурсов, информацию о том, кто ими владеет, насколько они рискованны и что бизнес разрешил им делать. Это место, где политика определяется, утверждается и отслеживается на платформе, которая уже обрабатывает более 100 миллиардов рабочих процессов в год. Kong привносит глубокий опыт работы на этапе выполнения и расширяет возможности Control Tower в области связности среды выполнения. Kong находится непосредственно на пути самого трафика — между агентами и всем, с чем они соединяются, — именно там, где политика либо соблюдается, либо нет. Диспетчерскому пункту ИИ необходимы оба компонента.
Если организационный диспетчерский пункт решает, что ИИ разрешено делать, то что-то должно гарантировать, что это действительно происходит при каждом запросе и в реальном времени. Это и есть диспетчерский пункт среды выполнения ( runtime control tower), и именно для этого создан Kong.
У диспетчерского пункта среды выполнения есть четыре задачи:
- - **Видеть каждое соединение:** Агенты общаются с моделями, инструментами и API на базе протокола MCP, потоками данных и событий, а также с другими агентами. Диспетчерский пункт среды выполнения располагается на всех этих путях, во всех облаках, у всех поставщиков моделей и во всех моделях развертывания.
- - **Знать, кто совершает вызов:** он проверяет, какой именно агент делает каждый вызов, и передает идентификационные данные пользователя, от имени которого он действует, во все нижестоящие сервисы.
- - **Обеспечивали соблюдение правил для каждого запроса:** Он авторизует доступ в соответствии с политикой, защищает промпты и ответы от конфиденциальных данных и небезопасного контента, а также ограничивает потребление до того, как бюджет будет исчерпан, а не после того, как придет счет.
- - **Глубоко измерять то, что произошло на самом деле:** Он учитывает токены и относит их к конкретной команде, приложению и агенту, а также регистрирует и отслеживает каждый вызов, чтобы оставались доказательства соблюдения политики.
Kong Konnect с платформами Kong AI, API и Event Gateways в основе выполняет эту задачу уже сегодня для того ИИ-трафика, который предприятия *уже* пропускают через Kong.
Диспетчерский пункт среды выполнения также должен быть нейтральным. Предприятия запускают ИИ на AWS, Google, Microsoft, OpenAI, NVIDIA и на собственной инфраструктуре — зачастую одновременно, — и каждая платформа управляет только собственным трафиком. Лидерство среди моделей меняется каждую неделю, постоянно появляются новые правила суверенитета, а модели с открытыми весами становятся все лучше. Мы называем это решение **стратегической переносимостью** (strategic portability): единая политика среды выполнения на любой платформе, позволяющая командам менять поставщиков без перестройки своих средств контроля.
Соедините оба диспетчерских пункта вместе, и управление превратится в замкнутый цикл. Политика определяется в организационном диспетчерском пункте, исполняется и измеряется в диспетчерском пункте среды выполнения, а данные о том, что произошло, поступают обратно к владельцам политики, чтобы они могли ее усовершенствовать.
Организационный диспетчерский пункт знает, что должно произойти. Диспетчерский пункт среды выполнения гарантирует это и отчитывается о том, что произошло на самом деле.
Сегодняшний день — это только начало. В предстоящие месяцы мы сможем рассказать гораздо больше о том, как Kong и ServiceNow будут сотрудничать в рамках альянса и что это значит для клиентов, создающих свой диспетчерский пункт ИИ как на уровне организации, так и в среде выполнения.
А пока предприятия, которые масштабируют ИИ безопасно, — это те, которые могут определить политику один раз, внедрить ее везде и доказать ее соблюдение. Мы рады строить это будущее вместе с ServiceNow и другими компаниями-основателями.
Узнайте больше об альянсе ServiceNow Control Tower Alliance(https://newsroom.servicenow.com/press-releases/details/2026/ServiceNow-launches-Control-Tower-Alliance-to-help-enterprises-adopt-AI-safely-at-scale/default.aspx)ServiceNow Control Tower Alliance и посмотрите, как _Kong AI Gateway_(https://konghq.com/products/kong-ai-gateway) _Kong AI Gateway_ управляет ИИ-трафиком сегодня.
**Темы**
Алекс Дрэг (Alex Drag)
Руководитель отдела продуктового маркетинга
# Управление затратами на токены ИИ: почему расходы на ИИ выходят из-под контроля (и как это исправить)
Эта публикация основана на вебинаре Kong, посвященном управлению затратами на токены. Посмотрите его ниже или читайте далее для получения подробного разбора. Управление затратами на токены — это то, как бизнес отслеживает, контролирует и регулирует свои расходы на использование ИИ-моделей, точно так же, как он уже отслеживает
Kong
# Ваша многоагентная система надежна ровно настолько, насколько надежен ее контекстный слой
Многоагентные рабочие процессы зависят от контекста. Каждый вызов между агентами и каждый вызов агента к инструменту представляет собой либо извлечение данных (получение информации, необходимой агенту), либо мутацию (изменение состояния, от которого будут зависеть последующие агенты). На этапе прототипирования
Уго Герреро (Hugo Guerrero)
# Архитектурное решение, с которым придется жить вашей многоагентной системе
Многоагентные системы в своей основе являются системами распределения контекста. Каждый агент в вашем рабочем процессе является потребителем и производителем контекста. Все интересные архитектурные вопросы сводятся к тому, как этот контекст перемещается. Две операции определяют все:
Уго Герреро (Hugo Guerrero)
# Как общаются ИИ-агенты: управление контекстом в многоагентных рабочих процессах
ИИ-агент — это не магия. Это механизм рассуждений, принимающий решения на основе того, что ему известно в данный момент. Это «что ему известно» и есть его контекст — информация, доступная ему прямо сейчас. Контекст — это всё. Дайте агенту неверный контекст,
Хьюго Герреро
# Новый рассвет: Тень корпоративного ИИ — триллионы токенов, ноль управления
Вы не можете управлять тем, чего не видите. Расходы на ИИ достигнут 2,59 триллиона долларов в 2026 году. Я регулярно делюсь тем, что мы видим в продакшене в Kong. Это не прогнозы аналитиков, а реальный трафик, проходящий через Kong AI Gateway от
Аугусто Мариетти
# Хватит латать дыры. Начните создавать: стек Kong Context Mesh
В вашей инфраструктуре уже есть сырьевые материалы: вычисления (виртуальные машины, контейнеры, бессерверные вычисления), потоковая передача событий (Kafka, Kinesis, Pub/Sub, RabbitMQ), хранилища данных (хранилища, базы данных, объектные хранилища) и эндпоинты ИИ (любые размещенные или автономные LLM). Хотя
Хьюго Герреро
# От микросервисов к ИИ-трафику — Kong как единая плоскость управления
Анатомия архитектурной сложности. Современные архитектуры теперь оперируют тремя различными шаблонами трафика. Каждый из них предъявляет уникальные требования. Традиционные подходы рассматривают их отдельно. Такое разделение создает ненужную сложность. Трафик Север-Юг API
Kong
