Google упаковывает Gemini-агентов в Cloud Console: что означает Agent Platform

Повод: не громкий релиз, а след продуктовой сборки

25 июля в новостной выдаче появилась свежая карточка «Agent Platform - Google Cloud Console». На первый взгляд это похоже на тихий запуск новой панели для Gemini-агентов. При ближайшей проверке история тоньше: публичное объявление Gemini Enterprise Agent Platform Google Cloud сделала 22 апреля 2026 года, а июльский сигнал скорее отражает активную доводку документации, интерфейсов и эксплуатационных функций вокруг платформы.

Именно поэтому повод важен. Google не просто добавляет еще один пункт меню в Cloud Console. Компания пытается собрать разрозненные слои агентной разработки в один путь: быстрый прототип, подключение данных и инструментов, развертывание агента, управление версиями, квоты, безопасность, наблюдаемость и корпоративный контроль. Для команд, которые уже работают в Google Cloud, это может стать более понятной дорогой от Gemini API и экспериментального playground к production-сценариям.

Здесь нужна аккуратность в формулировках. Факт: Agent Platform уже объявлена как эволюция Vertex AI. План компании: переносить дальнейшее развитие агентных сервисов в этот контур. Прогноз: enterprise-разработчикам будет все сложнее рассматривать Gemini как просто модельный API. Редакторская интерпретация: Google продает не «умного чатбота», а операционную систему для агентов внутри своего облака.

Свежая дата 25 июля у записи «Agent Platform - Google Cloud Console» важна как индикатор, но не как доказательство отдельного релиза. Первичная публичная точка отсчета находится в апрельском посте Google Cloud: 22 апреля 2026 года компания объявила Gemini Enterprise Agent Platform и описала ее как комплексную платформу для создания, масштабирования, управления и оптимизации агентов. В том же контуре Google прямо связывает платформу с Vertex AI, то есть с существующей корпоративной AI-инфраструктурой, а не с полностью новым продуктом с нуля.

Июльские материалы добавляют другой слой. 23 июля Google Cloud выпустила текст о готовности данных и инфраструктуры к agentic AI, а release notes Agent Platform фиксируют свежие изменения середины июля, включая исправление безопасности 20 июля и статус GA для Memory Bank memory profiles 15 июля. Это не выглядит как один большой запуск. Скорее, перед нами стадия продуктового сшивания, когда консоль, документация, runtime и governance постепенно становятся заметнее для enterprise-пользователя.

Для читателя важно отделить интерфейсный сигнал от факта внедрения. Появление элемента в Cloud Console или новостной карточке Google News само по себе не означает, что все возможности Agent Platform стали общедоступными и зрелыми. Но оно показывает, куда Google ведет разработчиков: из экспериментальных Gemini-инструментов в управляемую облачную среду, где у агента есть жизненный цикл, права, регионы, квоты и эксплуатационная ответственность.

Сегодня мы запускаем Gemini Enterprise Agent Platform.

Источник: Michael Gerstenhaber и Michael Bachman - VP Product Management, Gemini Enterprise; VP/GM, Cloud Foundations, Google Cloud

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

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

«Сегодня мы запускаем Gemini Enterprise Agent Platform.»

Что такое Gemini Enterprise Agent Platform

В апрельском позиционировании Google Cloud Agent Platform описана не как еще один чат-интерфейс, а как слой для всего жизненного цикла AI-агентов. Агент здесь означает программную систему на базе модели, которая не только отвечает текстом, но и планирует действия, вызывает инструменты, обращается к данным, выполняет инструкции в рамках заданных прав и возвращает результат в бизнес-процесс.

Google называет платформу эволюцией Vertex AI. Это принципиальная формулировка. Vertex AI был основным enterprise-контуром Google Cloud для ML и generative AI: модели, пайплайны, развертывание, управление, Model Garden. Теперь компания говорит рынку, что агентная разработка становится следующим уровнем этой инфраструктуры. Не вместо облака и не поверх него в виде отдельного сервиса, а внутри привычного Google Cloud Console, с теми же ожиданиями по IAM, billing, регионам и операционным политикам.

Масштаб вендорской ставки виден по модельному слою. Google заявляет доступ к более чем 200 моделям через Model Garden, включая собственные Gemini, Gemma и Lyria, а также сторонние модели вроде Anthropic Claude. Это маркетинговое продуктное заявление, а не независимый benchmark качества. Но для enterprise-архитектора число важно по другой причине: Google показывает Agent Platform как мульти-модельную фабрику агентов, а не как оболочку только для одной версии Gemini.

В этой логике Gemini остается модельным ядром и брендом ключевых AI-возможностей Google, но Agent Platform отвечает за промышленную упаковку. Модель генерирует рассуждение и действия, а платформа должна обеспечить подключение инструментов, управление агентами, выполнение в runtime, наблюдаемость, безопасность и политику доступа.

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

Agent Platform в таком виде важна не как отдельная кнопка в консоли, а как упаковка этих вопросов в продуктовый контур Google Cloud. Для крупных компаний это знакомый язык: ресурс в проекте, регион, настройки доступа, API, SDK, release notes, квоты, жизненный цикл и ответственность команды-владельца.

Как Google выстраивает путь от прототипа к production

Если разложить стратегию Google на уровни, становится видно, почему Cloud Console здесь важнее, чем кажется. Первый уровень, это быстрый эксперимент: разработчик проверяет идею агента, промпт, инструменты, поведение модели, базовую интеграцию с поиском или корпоративным контекстом. Второй уровень, это сборка агента как управляемого приложения: нужно описать задачи, инструменты, память, данные, ограничения и способ взаимодействия. Третий уровень, это runtime: агент должен быть развернут, обновляем, вызываем из приложений и контролируем в конкретном проекте и регионе.

Документация Agent Platform описывает интерфейсы и пути работы с платформой, а разделы про deployed agents показывают более зрелую эксплуатационную часть: агенты видны на странице Deployments в проекте и регионе, ими можно управлять через консоль, SDK или REST API. Это уже язык не демо, а эксплуатации. Команда должна понимать, где агент развернут, какая версия активна, кто имеет доступ и как его удалить или обновить.

Отдельный смысл в том, что Agent Platform не отменяет код. Google явно пытается совместить low-code и code-first подходы. Визуальные интерфейсы удобны для быстрого проектирования workflow и проверки гипотез, но enterprise-команды обычно требуют контроля через API, библиотеки, инфраструктуру как код, CI/CD и аудит изменений. Поэтому клиентские библиотеки, REST-контур, квоты и runtime-документация становятся не второстепенными деталями, а доказательством, что Google упаковывает агентов как software delivery problem.

Редакторская интерпретация здесь такая: Google пытается выиграть не только качеством Gemini, но и снижением организационного трения. Модельный API легко попробовать. Сложнее превратить агента в сервис, который живет в компании месяцами, проходит security review, подключается к данным, обновляется без хаоса и не превращается в невидимый риск для CISO.

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

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

Данные становятся главным узким местом

Свежий текст Google Cloud от 23 июля полезен тем, что смещает разговор от «какая модель умнее» к вопросу «к чему агент имеет доступ». По данным отчета Google Cloud, 83% организаций считают нужным обновить инфраструктуру для production-grade agentic AI. В том же материале 43% IT-лидеров называют интеграцию с legacy API и data sources крупнейшим инфраструктурным разрывом, 36% указывают на нехватку специализированных высокопроизводительных vector databases, а 81% относят operational complexity и engineering overhead к главным непредвиденным расходам.

Эти числа нужно читать правильно. Это vendor-исследование Google Cloud, а не нейтральная академическая работа, поэтому его нельзя подавать как окончательный срез всего рынка. Но набор проблем выглядит реалистично: агент без доступа к бизнес-контексту остается разговорной моделью; агент с доступом к данным и инструментам становится полезнее, но одновременно опаснее и дороже в эксплуатации.

Для Gemini-экосистемы это ключевой поворот. Большие языковые модели дают агенту способность понимать запрос, строить план и генерировать действия. Но качество реального результата зависит от контекста: какие данные доступны, насколько они свежие, есть ли семантическая разметка, как устроен поиск по корпоративным знаниям, какие API разрешены, где проходят границы полномочий. Google Cloud встраивает этот аргумент в платформенную стратегию: агентная архитектура должна жить рядом с data cloud, хранилищами, поиском, политиками доступа и наблюдаемостью.

По сути, Google продает enterprise-клиенту не обещание «агент все сделает сам», а инфраструктурную дисциплину. Нужно каталогизировать данные, нормализовать доступ, ограничить инструменты, описать полномочия и подготовить эксплуатационную модель. Без этого даже сильная модель Gemini будет работать как талантливый сотрудник, которого посадили в темную комнату с устаревшей папкой документов.

Дело не в возможностях сегодняшних моделей, а в их доступе к бизнес-контексту.

Источник: Sirish Chandrasekaran - VP Product Management, Data Analytics, Google Cloud

Редакторский вывод: для внедрения агентов критичны не только параметры модели, но и состояние корпоративных данных, API, поиска, прав доступа и инженерной поддержки.

В practical terms это означает неприятную, но честную вещь: пилот агента часто ломается не на генерации текста. Он ломается на старых интеграциях, закрытых хранилищах, разрозненных документах, неописанных API и спорных правах. Agent Platform подсвечивает эту проблему, потому что пытается сделать агента частью cloud-инфраструктуры, а не отдельной демонстрацией для презентации.

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

«Дело не в возможностях сегодняшних моделей, а в их доступе к бизнес-контексту.»

Runtime, квоты и управление: где заканчивается демо

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

Документация по Agent Runtime показывает именно этот слой. Развернутые агенты можно просматривать и администрировать в Cloud Console, а также через SDK и REST API. Для enterprise-команд это означает, что агент становится облачным ресурсом. У него есть привязка к проекту и региону, операции жизненного цикла и ожидаемая интеграция с практиками Google Cloud.

Квоты добавляют трезвости. Любая агентная платформа ограничена не только качеством модели, но и лимитами запросов, региональными настройками, доступностью сервисов и стоимостью эксплуатации. Раздел с квотами Agent Platform нужен не для формальности: он показывает, что агентные workloads будут конкурировать за ресурсы как обычные cloud workloads. Это важно при проектировании сценариев поддержки клиентов, внутренних copilots, автоматизации аналитики или операций с большим числом параллельных сессий.

Сильный тезис здесь в том, что agentic AI постепенно переходит из мира prompt engineering в мир platform engineering. Командам нужны не только хорошие инструкции для Gemini, но и SRE-практики: мониторинг, лимиты, rollback, управление секретами, оценка качества ответов, human-in-the-loop для рискованных действий и понятная модель владения сервисом.

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

Безопасность: июльский SSRF-сигнал как проверка зрелости

20 июля release notes Agent Platform зафиксировали security update для SSRF-уязвимости в auto-generated /api-proxy backend endpoint для web apps, созданных в Agent Studio до 1 июля 2026 года. Пользователям рекомендовали regenerate app и redeploy. Это важная деталь, потому что она показывает реальную цену low-code и autogenerated-инфраструктуры вокруг агентов.

SSRF, или server-side request forgery, это класс уязвимостей, при котором злоумышленник пытается заставить сервер выполнить нежелательный запрос от своего имени. В агентных приложениях такие риски особенно чувствительны: агент может иметь доступ к инструментам, данным, внутренним API и секретам. Если слой, который проксирует запросы или соединяет агента с внешним миром, ошибочно настроен, последствия выходят за рамки обычной ошибки интерфейса.

Факт исправления не означает, что Agent Platform небезопасна. Напротив, наличие release notes и инструкции по redeploy говорит о нормальном процессе сопровождения. Но для CIO и CISO это сигнал: агентные конструкторы нельзя воспринимать как игрушечный слой поверх модели. Их нужно включать в secure SDLC, проверять сгенерированный код, ограничивать сетевые маршруты, ревизовать credentials и фиксировать процедуры экстренного обновления.

Здесь Google сталкивается с общей проблемой отрасли. Чем проще компаниям дать агенту инструменты, тем выше риск, что права, сеть и данные будут выданы слишком широко. Поэтому governance в Agent Platform должен быть не декоративной вкладкой, а базовым условием внедрения.

В нормальном production-процессе агентный проект должен проходить те же проверки, что и другое приложение: threat modeling, контроль секретов, ревизию API, тестирование сетевых маршрутов, ограничение прав сервисных аккаунтов и процедуру быстрого redeploy при исправлениях. Удобство low-code не отменяет ответственность за итоговый сервис.

Идентичность агентов и открытый интернет

Пока Google собирает корпоративный контур в Cloud Console, за его пределами идет другой разговор: как агентам действовать в открытом интернете и быть распознаваемыми другими системами. TechCrunch в июле описал инициативу с участием Винта Серфа, связанную с идентификацией и аудитом AI-агентов. Смысл проблемы простой: если агент действует от имени пользователя или компании, внешняя система должна понимать, кто он, какие у него полномочия и можно ли доверять его запросу.

Это напрямую связано с корпоративной платформой Google, хотя не сводится к ней. Внутри Google Cloud можно выстроить identity, registry, gateway и audit trail средствами платформы. Но как только агент выходит к внешним сайтам, платежам, поставщикам или чужим API, возникает межсистемный вопрос доверия. Проприетарные агенты могут хорошо работать внутри своих экосистем, но открытый интернет требует общих правил идентификации, контроля и ответственности.

Для Google это стратегический вызов. Компания сильна в инфраструктуре, браузере, поиске, облаке и моделях. Но агентная экономика не будет состоять только из Gemini-агентов, разговаривающих с сервисами Google. Если рынок пойдет к совместимым агентам, важными станут стандарты, протоколы и признанная модель полномочий. Если же победит закрытая интеграция, Agent Platform станет еще одним способом глубже привязать enterprise-клиента к облаку Google.

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

Именование и идентификация становятся все более важными.

Источник: Vint Cerf - интернет-пионер, бывший вице-президент Google

Редакторский вывод: агентная инфраструктура упирается не только во внутренние IAM-политики, но и в будущие правила доверия между независимыми сервисами в интернете.

Эта тема важна для оценки Agent Platform как части более крупной картины. Cloud Console помогает контролировать агента внутри проекта Google Cloud. Но бизнес-процессы редко заканчиваются внутри одной консоли. Рано или поздно агенту нужно будет взаимодействовать с внешней системой, поставщиком, сайтом, платежным контуром или чужим API. Без проверяемой идентичности и аудита такие сценарии будут оставаться ограниченными.

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

«Именование и идентификация становятся все более важными.»

Российский контекст: полезен паттерн, не обязательно сама платформа

Для российских разработчиков и компаний главный практический вывод не в том, что нужно срочно переносить агентные проекты в Google Cloud. Напротив, доступность, юрисдикция данных, платежи, договорная база и требования к локальному размещению требуют отдельной юридической и технической проверки. Agent Platform завязана на облачный контур Google: Cloud Console, проекты, регионы, runtime, квоты, клиентские библиотеки и эксплуатационные сервисы.

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

Российским enterprise-командам стоит читать историю Agent Platform как чек-лист зрелости. Если внутренний агент умеет только отвечать в чате, это один уровень риска. Если он получает доступ к документам, внутренним API и бизнес-операциям, ему нужны политики, аудит и эксплуатационные процедуры. Google просто формулирует эти требования в виде облачного продукта, но сами требования не исчезают при выборе другого стека.

Здесь есть и конкурентный подтекст. Чем более цельной становится платформа Google, тем выше планка ожиданий к локальным и независимым решениям. Недостаточно дать API к модели. Нужно предложить агентный runtime, безопасность, governance, инструменты разработки, мониторинг и понятную экономику эксплуатации.

В этом смысле Agent Platform полезна даже тем, кто не планирует использовать Google Cloud. Она показывает, какие вопросы придется закрывать любой зрелой агентной системе: кто владелец агента, где хранится конфигурация, как контролируются инструменты, что происходит при ошибке модели, где журнал действий, кто утверждает опасные операции и как быстро отключить сценарий при инциденте.

Что это значит для разработчиков и enterprise-команд

Для разработчиков Agent Platform означает, что навыки работы с Gemini постепенно расширяются. Одного умения писать хороший prompt мало. Нужно понимать инструменты агента, структуру workflow, модель данных, ограничения runtime, работу с регионами, квотами и API управления. В выигрыше окажутся команды, которые рассматривают агента как приложение, а не как диалоговое окно.

Для архитекторов ключевой вопрос звучит иначе: какие действия можно доверить агенту и в каком контуре. Внутренний помощник для поиска по документации, агент поддержки, аналитический агент, автоматизатор DevOps-задач и ассистент для продаж требуют разных уровней доступа. Agent Platform подталкивает к тому, чтобы эти различия были описаны явно, через роли, инструменты, runtime и политику.

Для руководителей важна экономика. Google показывает агентную разработку как следующий слой cloud consumption. Чем больше агентов, сессий, инструментов, данных и наблюдаемости, тем больше значение получают квоты, тарифы, инфраструктурные расходы и vendor lock-in. Это не аргумент против платформы, но аргумент за ранний расчет совокупной стоимости владения.

Для CISO свежие июльские release notes являются напоминанием: агентные приложения наследуют все обычные риски веб-приложений и добавляют новые. Нужно проверять не только модельные ответы, но и маршруты сетевых запросов, прокси, права сервисных аккаунтов, секреты, действия инструментов и логи. Агент, который умеет делать полезные вещи, по определению способен сделать вредные вещи при ошибке проектирования.

Для продуктовых команд главный урок прагматичен. Не стоит начинать с идеи «сделаем универсального агента для всего». Лучше выбрать узкий процесс, описать данные, инструменты, права, точки подтверждения человеком и метрики качества. После этого уже можно решать, достаточно ли API, нужен ли runtime, какие ограничения накладывают квоты и как организовать поддержку.

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

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

• Не называйте июльскую карточку Cloud Console отдельным запуском без дополнительного подтверждения. Корректная формулировка: Google активнее выводит уже объявленную Gemini Enterprise Agent Platform в интерфейсы, документацию и эксплуатационный контур.
• Оценивайте Agent Platform как enterprise-слой вокруг агентов, а не как замену Gemini. Gemini дает модельные возможности, платформа отвечает за жизненный цикл, runtime, governance, квоты и подключение данных.
• Перед пилотом определите границы полномочий агента: какие инструменты он может вызывать, к каким данным обращаться, какие действия требуют подтверждения человеком и как все это логируется.
• Проверяйте статус функций и release notes. Июльское исправление SSRF показывает, что low-code и auto-generated агентные приложения нуждаются в таком же security review, как обычный production-код.
• Считайте стоимость заранее: агентные сценарии упираются не только в цену модели, но и в runtime, хранение, векторную инфраструктуру, наблюдаемость, интеграции и инженерное сопровождение.
• Для российских команд главный урок, это архитектурный паттерн: identity, registry, sandbox, gateway, audit, data governance и human-in-the-loop нужны при любом поставщике модели.

Чек-лист пилота Gemini-агента в production

Этот чек-лист стоит вынести в отдельный PDF для загрузки. Он не заменяет security review, но помогает быстро понять, готов ли агентный сценарий к переходу из демонстрации в управляемый контур.

Задача и границы агента

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

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

Данные и инструменты

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

• Проверьте, какие корпоративные источники действительно нужны агенту.
• Оцените свежесть, структуру и права доступа к этим данным.
• Не подключайте инструменты «на всякий случай».
• Разделите read-only доступ и действия, меняющие состояние систем.
• Зафиксируйте, какие данные нельзя отправлять в модельный или внешний контур.

Runtime и эксплуатация

Пилот становится production-сервисом в тот момент, когда у него появляются пользователи, нагрузка, ожидания доступности и ответственность за результат.

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

Безопасность и аудит

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

• Проведите security review агентного workflow и сгенерированного кода.
• Проверьте сетевые маршруты, прокси и доступ к внутренним API.
• Ограничьте права сервисных аккаунтов минимально необходимым набором.
• Настройте хранение и ротацию секретов.
• Проверьте, что инцидент можно расследовать по логам.

Вывод

Agent Platform в Cloud Console не стоит воспринимать как внезапное появление «секретного продукта» Google. Более точная картина интереснее: Google постепенно превращает Gemini-агентов из набора демонстраций и API-возможностей в управляемый enterprise-продукт внутри Cloud Console.

Это движение отражает зрелость рынка. В 2023–2024 годах главным вопросом было качество ответа модели. В агентной фазе главный вопрос звучит жестче: можно ли безопасно дать модели инструменты, данные и право действовать. Google отвечает на него платформой, где важны не только Gemini и Model Garden, но и runtime, квоты, governance, release notes и корпоративный контекст.

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

Источники

• Google Cloud: Introducing Gemini Enterprise Agent Platform
• Google Cloud: Your AI agents are ready. Is your data?
• TechCrunch: Vint Cerf is working on a plan to unleash AI agents on the open internet
• Google Cloud Blog: Agent Platform - Google Cloud Console
• Google Cloud Docs: Gemini Enterprise Agent Platform release notes
• Google Cloud Docs: Introduction and interfaces for Agent Platform
• Google Cloud Docs: Manage deployed agents
• Google Cloud Docs: Client libraries for Agent Platform

Частые вопросы

Google запустила Agent Platform именно 25 июля 2026 года?

По доступным источникам корректнее говорить иначе: Gemini Enterprise Agent Platform была публично объявлена Google Cloud 22 апреля 2026 года, а июльская карточка в Google Cloud Console и обновления документации показывают дальнейшую сборку платформы в интерфейсах и эксплуатационном контуре.

Agent Platform заменяет Gemini API?

Нет. В статье Agent Platform рассматривается как enterprise-слой вокруг агентной разработки: lifecycle, runtime, governance, квоты, подключение данных, SDK и REST API. Gemini остается модельным ядром и брендом ключевых AI-возможностей Google.

Почему в материале так много внимания данным, а не модели?

Потому что для production-grade агентов качество результата зависит от доступа к бизнес-контексту: корпоративным данным, актуальным источникам, API, политике прав и наблюдаемости. Google Cloud отдельно подчеркивает этот сдвиг в июльском материале о готовности данных к agentic AI.

Что означает июльское исправление SSRF в release notes?

Это сигнал, что low-code и auto-generated агентные приложения нужно проверять как обычный production-код. Сам факт security update не означает, что платформа небезопасна, но показывает необходимость secure SDLC, проверки прокси, сетевых маршрутов, credentials и процедур redeploy.

Полезна ли эта история российским командам, если они не используют Google Cloud?

Да, как архитектурный паттерн. Независимо от поставщика модели командам придется решать вопросы identity, registry, sandbox, gateway, audit, data governance, human-in-the-loop, управления версиями и эксплуатации агентов.

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

Чек-лист пилота Gemini-агента в production

PDF-файл для downloads/: короткая памятка для команды, которая проверяет готовность агентного сценария к production или зрелому пилоту.

Задача и границы агента

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

Данные и инструменты

• Проверьте, какие корпоративные источники нужны агенту.
• Оцените свежесть, структуру и права доступа к данным.
• Не подключайте инструменты без конкретного сценария.
• Разделите read-only доступ и действия, меняющие состояние систем.
• Зафиксируйте данные, которые нельзя отправлять в модельный или внешний контур.

Runtime и эксплуатация

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

Безопасность и аудит

• Проведите security review workflow и сгенерированного кода.
• Проверьте сетевые маршруты, прокси и доступ к внутренним API.
• Ограничьте права сервисных аккаунтов минимально необходимым набором.
• Настройте хранение и ротацию секретов.
• Проверьте, что инцидент можно расследовать по логам.