Google вирішує питання інфраструктури, а не управління
На Google I/O 2026 було представлено Managed Agents у Gemini API. Цей інструмент надає корпоративним командам кероване середовище виконання (managed runtime). Він забезпечує роботу пісочниць (sandboxes), ін'єкцію облікових даних та збереження стану (persistent state).
Це вирішує проблему інфраструктури. Але це не вирішує проблему, яка губить проєкти ШІ-агентів.
Більшість команд зосереджуються не на тому. Вони створюють ефектні демо-версії. Вони показують, як агент бронює квиток або відповідає на запитання. Такі демо виглядають добре, але зазнають невдачі в реальних умовах (production).
Справжні корпоративні робочі процеси потребують більшого, ніж просто чат-інтерфейс. Робота агента підтримки не завершена лише тоді, коли він відповів на запитання. Вона завершена тоді, коли він оновив тікет, оформив повернення коштів і сповістив клієнта через різні системи, такі як Salesforce або ServiceNow.
Стандартні конфігурації RAG не справляються тут, оскільки їм бракує трьох речей:
- Відсутність стану: Кожна розмова починається з чистого аркуша.
- Відсутність доступу на запис: Вони можуть читати дані, але не можуть оновлювати записи.
- Відсутність авторизації: Немає способу обмежити доступ до чутливих дій.
Google створила двигун за допомогою свого Managed Agents API. Але вони не створили гальма. API забезпечує виконання, але ви повинні контролювати межі довіри (trust boundaries).
Наступні 12 місяців у сфері корпоративного ШІ належатимуть командам, які опанують управління (governance). Якщо ви сприйматимете це як проблему інтеграції бекенду, ви зазнаєте невдачі. Якщо ви сприйматимете це як проблему управління системами, ви зможете випускати продукти.
Використовуйте цей 7-рівневий фреймворк для створення агентів, готових до експлуатації:
- Interface: UI або тригер.
- Orchestrator: розбиває цілі на кроки та керує етапами схвалення людиною.
- Model: механізм міркування всередині пісочниці.
- Tool/API Layer: кожна інтеграція з мінімальним і чітко визначеним обсягом повноважень.
- Knowledge Layer: RAG для підтримки робочого процесу.
- Sandbox: ізольоване середовище виконання.
- Audit: логи для кожної дії та можливість скасувати помилки.
Не обирайте постачальника, виходячи з того, що може робити його агент. Обирайте постачальника, виходячи з того, як він контролює те, що агенту дозволено робити.
Дотримуйтесь цих правил під час пілотних проєктів:
- Класифікуйте робочі процеси за рівнем ризику.
- Спочатку створіть легкі API-обгортки (wrappers) для застарілих систем.
- Призначайте рівні ризику конкретним діям, а не цілим робочим процесам.
- Тестуйте моменти, коли агент має передати справу людині.
- Моніторте частоту схвалень, щоб виявити точки тертя (friction points).
Інфраструктура тепер стала звичайним товаром. Довіра та контроль — це нові фактори диференціації.
Optional learning community: https://t.me/GyaanSetuAi