Почему среда исполнения становится товаром, а управление — конкурентным преимуществом

Среда исполнения становится товаром

Вспомните 2008 год. Чтобы запустить веб-приложение, нужно было купить серверы, установить стойки и нанять специалистов по эксплуатации. AWS сменила вопрос с «как это запустить?» на «что я хочу создать?». Вычисления стали инфраструктурой, а инфраструктура — товаром.

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

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

Все они решают один вопрос: где работает мой агент?

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

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

О пробеле в управлении почти никто не говорит

При оценке среды исполнения стоит также спросить:

• Кто разрешил развернуть этого агента?
• Какие границы действий агента задокументированы?
• Можете ли вы показать аудитору каждое решение агента за последние 90 дней?
• Если агент причинил вред, сможете ли вы точно восстановить, почему это произошло?
• Соответствует ли он требованиям Закона ЕС об искусственном интеллекте?

Закон ЕС об искусственном интеллекте вступает в силу поэтапно. Согласно статье 113 с поправками от июля 2026 года, основные требования главы III к высокорисковым системам из приложения III применяются с 2 декабря 2027 года, а к системам по статье 6(1) и приложению I — с 2 августа 2028 года, с учётом переходных положений. Сначала определите территориальную сферу действия, классификацию системы и свою роль оператора.

Статья 9 требует непрерывной системы управления рисками, а не разовой проверки. Риски необходимо выявлять, определять, оценивать и снижать на протяжении всего жизненного цикла системы.

Для высокорисковых систем статья 12 требует автоматически регистрировать события с прослеживаемостью, соответствующей предполагаемому назначению, чтобы поддерживать выявление и мониторинг рисков. Определите нужные события и контекст; это не означает, что каждое развёртывание должно хранить все входные и выходные данные.

Статья 14 требует мер человеческого контроля. Система должна быть спроектирована так, чтобы люди могли её понимать, вмешиваться и отменять её действия. Это должно работать на практике и подтверждаться документированными средствами контроля.

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

Статья 15 требует точности, устойчивости и кибербезопасности на протяжении всего жизненного цикла, уделяя особое внимание ошибкам и сбоям.

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

Явно укажите пробелы при проверке развёртывания и назначьте ответственного и проверенный способ снижения каждого риска.

Почему управление создаёт преимущество

Среда исполнения универсальна. Одна и та же среда подходит агенту юридических документов, поддержки клиентов и оптимизации цепочки поставок. Она не привязана к конкретной отрасли — именно поэтому становится товаром.

Управление учитывает отраслевую специфику. «Безопасность» агента для медицинской диагностики означает не то же, что для агента маркетинговых текстов. Правила для агента финансовых консультаций отличаются от правил для внутреннего агента кадровой политики. Отраслевые конституции управления — точные границы поведения, разрешённые действия, условия эскалации и требования к аудиту для определённого типа агента в конкретном нормативном контексте — это интеллектуальная собственность, которую можно защитить.

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

Рассмотрим, как инфраструктура управления работает на практике:

Incoming agent request
        |
        v
[Governance Proxy]
  - Verify request against constitutional rules
  - Check permitted action scope
  - Record the decision with selected integrity controls
  - Apply the rules selected for this workflow
  - Wait for human approval where policy requires it
        |
        v
[Runtime] (Managed Agents / LangGraph / custom)
  - Execute only after permission and required approval
        |
        v
[Response]
  - Post-execution logging
  - Deviation detection
  - Execution evidence update

Среду исполнения можно заменить, а прокси управления — нет. В нём заложены допустимый для организации уровень риска, отраслевые нормативные требования, формат журнала аудита, нужный команде соответствия, и логика эскалации для её рабочего контекста.

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

Прокси-паттерн на практике

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

Минимальный вариант выглядит так:

async function governedAgentCall(
  request: AgentRequest,
  runtime: AgentRuntime,
  governance: GovernanceLayer
): Promise<AgentResponse> {
  // Pre-execution: verify, log, potentially block
  const decision = await governance.evaluate(request);

  if (decision.requiresHumanReview) {
    return await governance.escalate(request, decision.rationale);
  }

  if (!decision.permitted) {
    await governance.logRejection(request, decision.rationale);
    throw new GovernanceViolation(decision.rationale);
  }

  const auditId = await governance.openAuditRecord(request, decision);

  // Runtime execution - could be Managed Agents, LangGraph, anything
  const response = await runtime.execute(request);

  // Post-execution: log result, check for deviation
  await governance.closeAuditRecord(auditId, response);
  await governance.detectDeviations(request, response, decision);

  return response;
}

Объект среды исполнения передаётся извне. Сегодня его можно направить на Managed Agents, а завтра — на LangGraph Cloud. Неизменной остаётся логика уровня управления: функции evaluate, escalate, openAuditRecord и detectDeviations. Именно на этом уровне строится ваш подход к соблюдению требований.

Сложность не в самом паттерне, а в содержимом функций управления: конституционных правилах допустимого поведения, оценке рисков для определения порогов эскалации, проверке хеш-цепочки для выявления изменений в записях аудита и формальной проверке внутренней согласованности правил.

Именно эта работа создаёт конкурентное преимущество.

Что это значит для разработки на Managed Agents

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

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

Для этого нужен уровень управления, расположенный над уровнем среды исполнения.

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

Зафиксируйте применимые даты и правовой источник в плане развёртывания. Назначьте ответственных за классификацию, проверку рисков и ведение доказательств, чтобы изменение сферы действия или законодательства приводило к обновлению.

Вопрос, который действительно важен

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

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

Вопрос не в том, где работает ваш агент.

Вопрос в том, можете ли вы доказать его безопасность.

Среда исполнения определяет, как выполнять. Управление — как доказывать. Одно становится инфраструктурой, другое даёт конкурентное преимущество.

Arbitra — уровень управления ИИ-агентами, не привязанный к среде исполнения. Он работает с Managed Agents, LangGraph и собственными средами. Если вы создаёте агентов для регулируемых областей, свяжитесь с нами, чтобы узнать об инфраструктуре управления.