AI-агенты Google: как масштабировать систему без деградации данных

Отчёт Google: не релиз Gemini, а разговор о фундаменте для агентов

13 августа 2026 года Google Cloud опубликовал результаты исследования о масштабировании AI-агентов, подготовленного совместно с MIT Technology Review Insights. Главный повод здесь не новая модель Gemini, не обновление Gemini API и не отдельный релиз Vertex AI. Google предлагает смотреть на агентов как на системы, чьё качество в production определяется доступом к данным, их смыслом, свежестью и управляемостью.

Исследование посвящено trustworthy data, то есть данным, которым система может обоснованно доверять при поиске, рассуждении и выполнении действий. Авторы связывают масштабирование агентов с готовностью корпоративной информации: структурированных записей, документов, событийных потоков, политик доступа и описаний бизнес-сущностей. Это принципиально иной акцент, чем привычный вопрос о том, какую LLM выбрать.

В опросе 300 руководителей в области данных и технологий только 10% сообщили о широком использовании агентов в бизнесе, тогда как 69% планируют прийти к такому внедрению в течение двух лет. Это не прогноз рынка и не подтверждение будущих внедрений. Но разрыв между текущим использованием и планами показывает, почему инженерная дисциплина вокруг данных становится важнее очередной демонстрации автономности.

В открытом изложении исследования 55% опрошенных называют legacy data systems препятствием для масштабирования агентов. Средняя самооценка доли корпоративных данных, доступных AI, составляет 45%. Эти цифры нельзя читать как точный срез мировой экономики: в доступных материалах не раскрыты полевая методика, география, квоты, способ рекрутирования и определение доступности данных. Корректнее считать их индикатором восприятия проблемы среди опрошенных руководителей.

Google называет целевую архитектурную рамку Agentic Data Cloud. Это термин и позиционирование поставщика, а не независимый отраслевой стандарт. Однако практический смысл переносим и за пределы Google Cloud: агенту необходимы единые правила доступа к источникам, семантический контекст, контроль безопасности и работа с актуальным состоянием процессов.

Редакционная метафора «пластиковые данные» здесь означает не синтетические датасеты и не model collapse. Речь о другом риске: агент выглядит убедительно, но действует на неполном, устаревшем, конфликтующем или лишённом бизнес-смысла контексте. В таком случае проблема начинается ещё до того, как модель сформулирует ответ.

• Факт: Google Cloud опубликовал отчёт о готовности данных для AI-агентов.
• План респондентов: 69% намерены широко внедрять агентов в следующие два года.
• Не следует утверждать, что Google представила новую Gemini-модель, Gemini API или GA-функцию Vertex AI.

Почему агент деградирует раньше, чем модель успевает ошибиться

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

Например, retrieval может вернуть документ, который формально подходит по ключевым словам, но уже отменён новой политикой. Индекс может не обновиться после изменения договора. Система прав доступа может скрыть критическую часть контекста, не объяснив агенту причину неполноты. Наконец, агент способен выбрать верный API, но вызвать его в неверной последовательности или передать рискованные параметры.

Это разные классы отказов, и метрика качества финального текста не обнаружит их все. IEEE Spectrum отдельно обращает внимание на сценарий тихой деградации: агент извлекает документы и формирует связные ответы, пока база знаний постепенно устаревает. Метрики доступности сервиса, задержки и доли ошибок API могут оставаться в норме, хотя бизнес-решение уже неверно.

Поэтому качество production-агента нельзя сводить к uptime модели или субъективной оценке полезности чата. Нужно проверять весь путь от найденного источника до результата во внешнем процессе.

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

Доступ к данным важен, но процент подключения не должен становиться KPI

Google сообщает о корреляции между более широким доступом AI к корпоративным данным и большей уверенностью респондентов в качестве агентных решений. В группе, которую исследование называет data leaders, AI доступно более 70% enterprise data; у data laggards показатель составляет 30% или меньше. В целом точности и релевантности решений агентов доверяют 51% респондентов, среди laggards таких 22%.

Это важный сигнал, но не причинный закон. Нельзя вывести из опроса, что подключение 70% данных автоматически сделает агента точным. Более зрелые компании могли одновременно инвестировать в каталог данных, интеграции, безопасность, людей, процессы контроля и оценку качества. Именно эти сопутствующие факторы могут объяснять часть различий.

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

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

Первый контур: контракт данных для каждого источника

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

Такой контракт превращает подключение данных в управляемый интерфейс, а не в неконтролируемую выдачу текста. Для каждого источника стоит закрепить бизнес-владельца, назначение, идентификаторы сущностей, схему, приоритет при конфликте, дату последнего обновления, ожидаемую частоту обновления, классификацию чувствительности, правила хранения и удаления.

Отдельно необходимы версии документов, индексов и embedding-моделей. Embedding-модель преобразует текст в вектор для семантического поиска и влияет на то, какие фрагменты вообще увидит агент. Если версию индекса или модели нельзя связать с конкретным запуском, расследование ошибки быстро превращается в догадку.

Google среди приоритетов выделяет открытие доступа к разным типам данных, добавление governance и бизнес-контекста, а также переход от пакетных обновлений к streaming- и event-driven-контурам там, где решение зависит от свежего состояния. Это не означает, что все базы нужно физически переносить в одно хранилище. Смысл в согласованном доступе и понятных правилах, а не в обязательной централизации.

• Укажите владельца и утверждённый сценарий использования каждого источника.
• Задайте SLO свежести: сколько времени данные могут оставаться без обновления для конкретной задачи.
• Пометьте каноническую версию записи и правила разрешения конфликтов.
• Версионируйте документ, индекс, схему инструмента и embedding-модель.

Второй контур: оценивать поиск, ответ и траекторию по отдельности

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

На уровне траектории проверяются выбор инструментов, последовательность вызовов, параметры и достигнутый бизнес-результат. Google Cloud поддерживает примеры и инструменты для evaluation, а в собственных инженерных материалах подчёркивает необходимость проверять не только финальный ответ, но и выполнение многошаговых сценариев.

Для агентов это принципиально: один и тот же правдоподобный текст может быть итогом безопасной цепочки действий либо маскировать неверный поиск и опасный вызов инструмента. Команде не стоит переносить демонстрационные пороги качества в production без адаптации.

Порог зависит от стоимости ошибки, домена, доступности эксперта и того, имеет ли агент право что-либо менять. Для помощника по внутренней базе знаний допустим один профиль риска; для агента, создающего заказы, меняющего доступы или отвечающего на запросы клиентов, нужен другой.

• Retrieval: recall авторитетных источников, свежесть, права доступа и место в выдаче.
• Ответ: groundedness, полнота и корректное обозначение неопределённости.
• Траектория: корректность tool calls, параметров и порядка шагов.
• Исход: достигнута ли бизнес-цель и не возник ли побочный эффект.

Третий контур: трасса должна объяснять каждый запуск агента

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

Без такой цепочки команда видит симптом, но не может уверенно найти источник деградации. Минимальный журнал production-run включает идентификаторы запроса, сессии и пользователя; версии системного промпта, модели и маршрута; идентификаторы и версии найденных источников; их дату актуальности и позицию в выдаче; параметры и результаты tool calls; ошибки и задержки; решение policy layer; финальный ответ; факт действия во внешней системе; пользовательскую коррекцию и стоимость запуска.

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

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

• Храните ID и версию каждого использованного источника, а не только текст ответа.
• Фиксируйте вход и результат каждого вызова инструмента.
• Разделяйте технический успех API и подтверждённый бизнес-исход.
• Связывайте пользовательскую жалобу или ручную отмену с конкретной трассой.

Четвёртый контур: стоп-условия важнее красивых алертов

Наблюдаемость помогает расследовать уже случившуюся ошибку. Для действий с необратимым эффектом нужны предохранители до выполнения команды. Базовый набор включает allowlist разрешённых инструментов, разделение прав чтения и записи, лимиты суммы или количества операций, лимиты повторных попыток, sandbox для тестирования и обязательное подтверждение человеком в сценариях высокого риска.

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

Это особенно важно в сервис-деске, CRM, ERP, закупках и документообороте, где внешне безупречный ответ может запустить неверный процесс. Архитектура Google Cloud полезна как пример распределения управляемых компонентов, но сама по себе не заменяет проектирование прав и бизнес-ограничений.

Vertex AI и связанные с ним средства не гарантируют, что организация правильно определила границы полномочий агента. Модель, оркестрация, инструменты и данные остаются разными слоями системы, за которые команда отвечает отдельно.

• Запретите запись во внешние системы по умолчанию, затем выдавайте права точечно.
• Ограничивайте допустимые параметры инструментов, а не только список API.
• Требуйте human approval для платежей, удаления, изменения прав и иных высокорисковых операций.
• Проверяйте, что агент умеет остановиться и передать кейс человеку.

Цитата в переводе

«Клиенты не уверены в LLM и обеспокоены ими.»

Цитата в переводе

«Особенно когда вы хотите развернуть такой датасет для коммерческого, неакадемического использования.»

Непрерывная оценка и реальность бенчмарков

Единственный benchmark перед релизом не защищает от дрейфа. Меняются документы, политики, схемы инструментов, права пользователей, версии моделей и внешние API. Поэтому production-процессу нужны два контура: offline-набор критических сценариев и online-проверка выборки реальных трасс.

В offline-набор необходимо включать конфликтующие документы, устаревшие правила, сбои инструментов, сложные многоходовые задачи и попытки манипулировать контекстом. В online-контуре полезно регулярно размечать production-трассы экспертами, сопоставлять их с эталонными исходами, анализировать отменённые действия и пользовательскую обратную связь.

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

Независимый фон здесь отрезвляет. IEEE Spectrum описывает бенчмарки агентных систем, в которых работа с реалистичными производственными задачами остаётся трудной для мультимодальных моделей: среди проблем называют галлюцинации, подсчёт объектов и измерения. Это не прямой тест конкретной корпоративной конфигурации Google Cloud и не опровержение опроса Google. Но это веская причина не подменять проверку собственной системы презентационными метриками.

• Запускайте регрессионный набор после изменения модели, промпта, индекса, политики или tool schema.
• Включайте в оценку задачи, где агент обязан отказаться от действия.
• Анализируйте не только среднюю оценку, но и редкие дорогие ошибки.
• Разделяйте демонстрацию на benchmark и доказанное качество в конкретном бизнес-процессе.

Что это означает для команд в России

Для российских команд наиболее переносима не конкретная облачная конфигурация Google, а дисциплина AgentOps и DataOps: каталог авторитетных источников, владельцы данных, версионирование, разделение прав, трассы запусков и регулярная оценка. Она применима к агентам над внутренними базами знаний, CRM, Service Desk, ERP и системами документооборота независимо от выбранной модели или инфраструктуры.

Первый практический шаг не требует строить автономную мультиагентную систему. Достаточно выбрать один сценарий с понятным бизнес-результатом, составить реестр источников, определить допустимые действия и собрать 30–50 реальных тестовых кейсов, включая неудобные исключения.

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

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

• Начните с реестра источников и их владельцев, а не с подключения всех корпоративных папок.
• Сделайте трассировку обязательной до выдачи агенту прав на действия.
• Оценивайте цепочку retrieval, ответ, tool calls и бизнес-исход.
• Масштабируйте автономность только после того, как система научилась безопасно отказываться и эскалировать.

Что это означает на практике

Ниже собраны действия, с которых можно начать аудит или запуск первого агентного сценария. Чек-лист не заменяет архитектурное решение, оценку рисков и требования к защите данных, но помогает не перепутать подключение модели с готовностью системы к production.

Вывод

Google Cloud предлагает не магическое средство от ошибок AI-агентов, а полезную рамку: качество зависит от доступа, семантики, свежести, governance и наблюдаемости данных. Сам отчёт основан на самооценках 300 руководителей, поэтому его нельзя использовать как доказательство причинной связи между объёмом доступных данных и точностью.

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

Источники

• Research report: Scaling AI agents with trustworthy data | Google Cloud Blog
• Scaling AI agents with trustworthy data | Google Cloud
• AI agent benchmarks | IEEE Spectrum
• AI reliability | IEEE Spectrum
• EvalBench | GoogleCloudPlatform on GitHub
• Reasoning Engine overview | Google Cloud
• Applied AI engineering samples | GoogleCloudPlatform on GitHub
• Trace example | Google Cloud documentation

Практический чек-лист

Чек-лист: минимальный контур надёжного AI-агента

Используйте этот список перед расширением доступа агента к корпоративным данным или выдачей прав на действия. Для скачивания подготовьте файл downloads/checklist-ai-agent-production.pdf и добавьте его отдельной строкой на лист Downloads.

Источники и контекст

• Для каждого источника назначен бизнес-владелец и определён разрешённый сценарий использования.
• Заданы каноническая версия записи, правила разрешения конфликтов и SLO свежести.
• Версии документа, индекса, схемы инструмента и embedding-модели фиксируются и доступны для проверки.
• Права пользователя и агента проверяются до выдачи контекста.

Оценка

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

Наблюдаемость и безопасность

• Для каждого запуска сохраняется трасса с источниками, версиями, tool calls и результатами.
• Технический успех API не подменяется подтверждённым бизнес-исходом.
• Запись во внешние системы закрыта по умолчанию, разрешения выдаются точечно.
• Для высокорисковых операций предусмотрены лимиты, sandbox, stop-условия и human approval.
• Агент умеет безопасно отказаться от действия и передать кейс человеку.

Непрерывная проверка

• Есть регрессионный набор с устаревшими, конфликтующими и неполными данными.
• Набор запускается после изменения модели, промпта, индекса, политики или схемы инструмента.
• Команда регулярно разбирает production-трассы, отменённые действия и обратную связь пользователей.
• Редкие дорогостоящие ошибки анализируются отдельно от средней оценки качества.