AIRun и AIGate: исполнение задачи и контроль доступа
Как AIRun запускает агентов, а AIGate проверяет обращения к моделям и инструментам: маршруты, ключи, согласования и история выполнения.
У корпоративного ИИ-агента есть две связанные задачи: выполнить поручение пользователя и обращаться к данным в пределах выданных прав. Для проектирования системы полезно отдельно описать исполнение, проверки доступа и сами источники. Это помогает понять, где настраивать ограничение и какой журнал открывать при разборе ошибки.
AIRun управляет каталогом и версиями агентов, задачами, чатами, автоматизациями и историей исполнения. AIGate предоставляет подключённый контур проверки обращений к моделям и инструментам: права, политики, согласования и связанный аудит шлюза. Совместная работа требует настройки маршрутов и доступов.
Как проходит запуск
Пользователь выбирает опубликованного агента и ставит задачу. В Kubernetes AIRun создаёт отдельный Job для этого запуска. Исполнитель получает контекст через API платформы и отправляет ей события. Обращения к модели и инструментам также передаются через сервер AIRun.
Рекомендуемый маршрут к модели выглядит так: Job агента → AIRun → AIGate → сервис модели. Маршрут к корпоративным инструментам: Job → AIRun → AIGate / MCP Hub → разрешённый источник. Доступ к одному источнику при этом не должен расширять права на остальные.
Такая схема позволяет оставлять долгоживущие ключи моделей и источников на серверной стороне. Под использует токен своего запуска. Сетевые ограничения пода настраиваются на доступ к AIRun и необходимому DNS; их фактическое действие проверяют с учётом сетевого плагина кластера.
Почему важно различать маршруты модели
Профиль модели определяет её идентификатор, инструкцию и параметры генерации. Помимо маршрута через AIGate, профиль может использовать прямой OpenAI-совместимый API: Job → AIRun → сервис модели. В этом случае запросы модели обходят AIGate, и политики LLM-маршрута шлюза к ним не применяются.
AIRun продолжает учитывать состояние запуска и собственные лимиты. Прямой маршрут модели не предоставляет агенту прямого доступа к корпоративным инструментам: они остаются за AIGate / MCP Hub. Совместимость выбранного сервиса проверяют на нужных операциях и параметрах, включая потоковые ответы.
Выбор маршрута также определяет, куда передаётся контекст. До загрузки рабочих данных согласуют модель, провайдера, разрешённые категории сведений и исходящие соединения. Название интерфейса само по себе не отвечает на эти вопросы.
Что означает согласование действия
Для операции записи заранее задают инструмент, целевой объект, допустимые параметры и согласующего. Настроенная политика может удерживать вызов до решения человека. Участник должен видеть, какое конкретно изменение ему предлагают разрешить.
Отказ и истечение ожидания отражаются в результате запуска. Заблокированное действие нельзя показывать как выполненное. Новая операция проходит проверку заново согласно политике. В пилоте этот путь проверяют на учебном объекте, сопоставляя историю с его состоянием до и после вызова.
Согласование не делает внешнюю операцию обратимой. Обновление версии агента или восстановление AIRun не возвращает автоматически изменённые данные другой системы. Для них требуется отдельный порядок компенсации или восстановления.
Где искать доказательства выполнения
История AIRun отвечает на вопросы о задаче, версии исполнителя, шагах, статусах и расходе запуска. Журнал AIGate показывает наблюдаемые обращения и решения политик шлюза. Эти сведения имеют разные источники и сопоставляются по идентификаторам запуска и вызова.
При разборе проверяют всю цепочку: был ли вызов разрешён, ответил ли источник и какое изменение действительно произошло. Такая проверка помогает отделить ошибку прав от недоступности системы и неверного вывода модели. Критерии для первого внедрения описаны в статье о приёмке пилота, а постановка задачи – в материале о проверяемом результате.