Чому середовище виконання стало товаром, а управління — конкурентною перевагою

Рівень середовища виконання стає товаром

Згадайте 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 і власними середовищами. Якщо ви створюєте агентів для регульованих середовищ, зв’яжіться з нами, щоб дізнатися про нашу інфраструктуру управління.