Настоящее ИИ-испытание Google Cloud — регламентированный процесс после демо

Кратко

• Предложение Google Cloud в области корпоративного ИИ — это больше не просто вызов модели Gemini. Это операционная поверхность, которая объединяет Gemini Enterprise Agent Platform, наследие Vertex AI, BigQuery, Agent Search, IAM, Cloud Audit Logs, Cloud Run, Workflows и средства контроля ёмкости в единый регламентированный процесс.
• Полезный знаменатель — принятый результат. Ответ модели — лишь один шаг: надёжность в производственной эксплуатации зависит от актуальности данных, прав доступа инструментов, наборов для оценки, журналирования аудита, проектирования квот, контроля затрат, обработки исключительных ситуаций и отката.
• Публичные свидетельства подтверждают глубину средств контроля Google Cloud и спрос на них, но не универсальные результаты у заказчиков. Отчётность Alphabet показывает значительный рост Google Cloud и инвестиции в инфраструктуру, а зарегистрированные инциденты и документация объясняют, почему заказчикам всё ещё нужны собственный надзор и проектирование восстановления.

Главный результат — принятый процесс, а не эффектный ответ

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

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

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

Google Cloud хорошо подходит для этого испытания именно потому, что его публичное предложение теперь шире, чем endpoint модели. В годовом отчёте Alphabet за 2025 год Google Cloud описан как сервис, включающий инфраструктуру, платформы, приложения и другие облачные сервисы, с ИИ-предложениями вроде корпоративной ИИ-инфраструктуры, Vertex AI и Gemini Enterprise, а также кибербезопасностью и аналитикой данных. В том же документе говорится, что выручка Google Cloud за 2025 год составила 58,705 млрд долларов, а форма 10-Q за I квартал 2026 года показывает выручку Google Cloud в 20,028 млрд долларов за квартал — на 63 % больше год к году.

Это не нишевый API для разработчиков. Это крупный корпоративный облачный бизнес, который предлагает заказчикам перенести повторяющиеся рабочие нагрузки на свою инфраструктуру.

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

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

Границы бренда и юридического периметра — не формальность

Объект этой статьи — Google Cloud, облачный бизнес Google, предоставляющий инфраструктуру, данные, безопасность, инструменты совместной работы и корпоративные ИИ-сервисы. Его не следует сводить к Google Search, потребительскому использованию Gemini, анонсам исследований DeepMind, YouTube, Android или любым результатам партнёров и заказчиков, в которых задействована модель Google.

Здесь важна собственная сегментная терминология Alphabet: Google Cloud включает Google Cloud Platform и Google Workspace, а в сервисы GCP входят инфраструктура, платформы, корпоративная ИИ-инфраструктура, Vertex AI, Gemini Enterprise, кибербезопасность и аналитика данных. Это операционная граница данной статьи.

Эта граница также защищает анализ от типичной ошибки. У Google исследования моделей мирового уровня, но заказчик, покупающий Google Cloud, не получает прямой гарантии, что каждый прорыв в моделях превратится в стабильный принятый процесс. Прогресс исследований может улучшить «сырой» ответ. Регламентированный процесс по-прежнему зависит от продуктовой поверхности облака: ролей IAM, доступности в регионах, настроек журналирования по умолчанию, коннекторов данных, квот, уведомлений о жизненном цикле моделей, условий поддержки, SLA, биллинга и управления изменениями.

Результат модели DeepMind и производственный результат Google Cloud связаны, но это не одно и то же свидетельство.

Граница действует и в обратную сторону. Когда в истории заказчика говорится, что Replit запускает Claude на Vertex AI, а Fifth Dimension централизует инференс Gemini и Claude в Vertex AI, эти свидетельства относятся к Google Cloud как к управляемой плоскости контроля для нескольких моделей, а не только к Gemini. Это различие коммерчески важно. Заказчики могут выбирать Google Cloud потому, что он позволяет объединить модели Google, модели партнёров, BigQuery, Cloud Run и средства контроля облачной безопасности в одной архитектуре.

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

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

Google Cloud продаёт поверхность контроля

В текущей документации GoogleGemini Enterprise Agent Platformописан как единая платформа для создания, развёртывания, управления и оптимизации корпоративных агентных систем и решений на основе моделей.Обзор жизненного цикладелит его на этапы создания, масштабирования, управления и оптимизации. В нём перечислены low-code Studio, Agent Development Kit с приоритетом кода, доступ к Model Garden, управляемая среда выполнения, управление сеансами, Memory Bank, уникальная идентичность агента, Agent Registry, Agent Gateway, оценка Gen AI, Cloud Observability и Topology.

Этот список показателен. Он говорит, что Google Cloud понимает: корпоративный ИИ — это не только инференс. Платформа, на которой размещается модель, должна также отвечать на вопросы: кто или что действует, какой инструмент одобрен, какие данные входят в область применения, был ли ответ оценён, наблюдаемо ли действие и как развёрнута среда выполнения. Поэтому корректное сравнение — это не только OpenAI, Anthropic, Microsoft, AWS или open-source модель.

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

Публичные компоненты платформы естественным образом соответствуют производственным вопросам.Agent Registryцентрализует одобренные ИИ-компоненты, MCP-серверы и endpoints, чтобы доступ к инструментам не был разбросан по разрозненным экспериментам.Agent Gatewayиспользует метаданные реестра, идентичность агента и средства политик, формируя телеметрию наблюдаемости взаимодействий.Agent Identityнаделяет агента строго подтверждаемой идентичностью на основе SPIFFE; в документации сказано, что по умолчанию идентичности не разделяются между несколькими рабочими нагрузками и не могут создавать долгоживущие ключи сервисных учётных записей.

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

Преимущество Google Cloud в том, что многие окружающие компоненты уже живут в его облачных активах. IAM, Cloud Audit Logs, BigQuery, Cloud Run, Workflows, Cloud Monitoring, VPC Service Controls и биллинг — это не дополнения из отдельного «любительского» проекта. Это устоявшиеся облачные примитивы, которые можно включить в ИИ-процесс. Слабость та же: как только заказчик выбирает интегрированный путь, цепочка принятия результатов наследует сложность, модель затрат и сценарии отказов облачной платформы.

Опора на данные — первая проблема надёжности

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

У Google Cloud есть серьёзный задел для решения этой проблемы.Обоснование с помощью Agent Searchпозволяет Gemini подключаться к данным сайтов или документов через Agent Search. На странице описаны предварительные условия — разрешения IAM, активация AI Applications и создание хранилища данных, — и сказано, что при обосновании по данным заказчика можно использовать до 10 источников данных Agent Search. Отдельнаяпродуктовая страница Agent Searchпозиционирует сервис как управляемую RAG-систему для корпоративных данных и описывает цитаты, ссылки, контроль источников данных и коннекторы.

Это заметное снижение затрат на разработку. Команда может не собирать вручную каждый компонент — загрузку данных, OCR, разбиение на фрагменты, эмбеддинги, индексацию, поиск и цитирование. Но управляемое обоснование не отменяет работу по определению того, на чём должен основываться принятый ответ. Максимальное число источников данных — это ограничение, под которое нужно проектировать. Коннектор, читающий Jira, SharePoint, Salesforce или хранилище документов, по-прежнему зависит от актуальности, прав доступа и семантики этих систем.

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

BigQuery добавляет второй уровень. В егодокументации по управлению даннымиописаны Knowledge Catalog, обнаружение метаданных, качество данных, профилирование данных, происхождение данных, IAM, контроль доступа на уровне строк и столбцов, VPC Service Controls, журналы аудита, маскирование, шифрование, средства контроля совместного доступа, clean rooms и метрики использования. Это те средства контроля, которые нужны команде данных, прежде чем она сможет принять результат на основе модели из контекста хранилища. Но они добавляют работы. Кто-то должен определить термины глоссария, владельцев, правила качества, политики маскирования, предоставление доступа, загрузку сведений о происхождении и мониторинг использования. Эта работа может быть дешевле, чем создание собственного стека управления данными с нуля, но она не бесплатна.

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

Обязательства по конфиденциальности помогают, но хранение и география всё равно требуют проектирования

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

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

Но формулировка о конфиденциальности — не вся конструкция управления. Вдокументации о нулевом хранении данныхсказано, что Google не использует данные заказчика для обучения или тонкой настройки управляемых моделей без разрешения, но при этом описаны сценарии — например, мониторинг злоупотреблений и режимы обоснования, — в которых условия хранения могут различаться и заказчикам может потребоваться запрашивать исключения или разбираться в отдельных условиях. У обоснования с помощью Google Search и Maps собственные условия хранения. Это не делает платформу небезопасной. Это означает, что заказчику нужно сопоставить каждую включаемую функцию с классом данных, которые он готов раскрыть, и регионом, где они могут обрабатываться.

Региональный вопрос аналогичен. В документации по обоснованию сказано, что AI Applications доступны в глобальных мультирегионах, а также в мультирегионах ЕС и США. Компания, работающая в условиях требований к локализации данных, не может предполагать, что каждая ИИ-функция, модель, коннектор, журнал и путь поддержки имеют одну и ту же географию. Суверенитет данных редко включается одним переключателем. Это цепочка: местонахождение модели, местонахождение хранилища данных, журналы, доступ поддержки, резервное копирование, мониторинг, использование сторонних моделей и доступ сотрудников.

Эта цепочка меняет подход к закупкам. Компания, выбирающая между Google Cloud, другим облачным провайдером, ИИ-функцией в существующем SaaS, open-source моделью в собственной среде или меньшей автоматизацией, должна сравнивать факты о пути данных, а не лозунги. У Google Cloud есть многие нужные управляющие примитивы. Заказчику всё равно предстоит доказать, что выбранный набор функций соответствует его требованиям к локализации, хранению и аудиту.

Права доступа решают, полезен агент или опасен

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

В документации Google Cloud есть несколько полезных примитивов для заказчиков. Вдокументации по IAM для Agent Platformсказано, что доступом можно управлять на уровне проекта или ресурса и что пользовательские роли рекомендуются, когда командам нужно ограничить доступ только необходимыми разрешениями.Agent Identityделает сам агент субъектом доступа, а не прячет каждое действие за одной общей сервисной учётной записью.Agent Gatewayиспользует идентичность и метаданные реестра для решений об авторизации и применения политик.

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

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

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

Здесь помогает интегрированная инфраструктура Google Cloud. Cloud IAM, сервисные учётные записи, политики на уровне ресурсов, VPC Service Controls и журналы аудита знакомы командам облачной безопасности. Но объект управления сместился. Субъектом доступа теперь может быть агент, данными — контекст поиска, а не прямой запрос к базе данных, а результатом — бизнес-действие. Командам безопасности следует относиться к правам агента как к производственным привилегиям, а не как к настройкам написания запросов.

Оценка — функция платформы, а не замена суждению

Google Cloud заслуживает признания за то, что сделал оценку частью истории своей платформы. Вобзоре сервиса оценки Gen AIсказано, что он поддерживает объективную оценку генеративных ИИ-моделей на основе данных и таких сценариев, как миграция моделей, изменение формулировок запросов и тонкая настройка. Адаптивные рубрики описаны как индивидуальные тесты «пройдено/не пройдено» для отдельных запросов, аналогичные модульным тестам в разработке ПО.Документация по оценке агентоврасширяет эту идею на способность агента выполнять задачи и достигать целей.

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

Но инструменты оценки не создают эталонный набор. Заказчику всё равно нужно определить, что такое хороший ответ, собрать репрезентативные примеры, разметить граничные случаи, задать пороги «пройдено/не пройдено», включить негативные примеры, проверить инъекции инструкций, устаревшие данные и несоответствие прав доступа, а также обновлять набор тестов при изменении бизнеса. Если компания нигде не зафиксировала, как человек решает, приемлемо ли резюме о рисках вендора, сервис оценки моделей не сможет вывести всю политику самостоятельно. Он может превратить тест в регулярную процедуру, если организация задаст стандарт.

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

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

Журналы аудита превращают чёрный ящик в записи — но только если их включили и читают

Возможность аудита — одно из самых явных преимуществ Google Cloud перед одиночным вызовом модели. Вдокументации по журналированию аудита Agent Platformсказано, что сервисы Google Cloud ведут журналы аудита, помогающие ответить на вопросы: кто, что, где и когда сделал. Журналы Admin Activity отключить нельзя. Журналы System Event фиксируют автоматические действия Google Cloud, изменяющие ресурсы, и их тоже нельзя отключить. Журналы Data Access включают чтение и запись данных, предоставленных пользователем, но, как сказано в документации, их нужно включать явно.

Отдельнуюстраницу о включении журналов аудита Data Accessлегко пропустить, и при этом она очень важна. В ней сказано, что заказчикам нужно включить эти журналы, чтобы получать записи аудита об использовании endpoint моделей, а для просмотра потокаdata_accessтребуется роль Private Logs Viewer. В общемобзоре Cloud Audit Logsдобавлено, что журналы Data Access вне BigQuery отключены по умолчанию, поскольку они могут быть большими и приводить к затратам.

Это практический компромисс в управлении. Полное журналирование создаёт доказательства, но также порождает расходы, вопросы хранения, вопросы контроля доступа и работу по проверке. Если команда не включит нужные журналы, она может не восстановить, какой запрос, endpoint, источник данных, идентичность или вызов инструмента привели к принятому результату. Если же включить всё без дисциплины маршрутизации и хранения, можно получить большие объёмы чувствительных журналов, которые мало кто просматривает. Возможность аудита — не галочка в чек-листе. Это самостоятельный продукт данных.

Для принятого ИИ-процесса минимальная запись должна включать пользователя или сервис, запросивший работу, идентичность агента, модель и её версию, источники поиска, вызовы инструментов, решения о правах доступа, результат оценки или шаг проверки, итоговый принятый результат и любое последующее действие. Google Cloud документирует несколько звеньев этой цепочки, но сквозная запись пересекает границы продуктов. Заказчику могут понадобиться Cloud Logging, журналы приложений, метаданные заданий BigQuery, телеметрия Agent Gateway, записи системы контроля версий, история заявок и журналы бизнес-систем.

Коммерческий вывод прост: экономия, игнорирующая проверку аудита, завышена. Если модель экономит 20 минут на черновике, но требует 10 минут на проверку доказательств, экономия по принятому результату — не 20 минут. Если журналирование предотвращает одну дорогостоящую ошибку, экономика может быть по-прежнему отличной. В расчёте должна учитываться работа по проверке.

Дрейф версий — издержки надёжности

ИИ-системы меняются чаще, чем традиционные корпоративные процессы. Модели выводятся из эксплуатации, endpoints устаревают, меняются фильтры безопасности, растут контекстные окна, смещаются профили задержек, меняются цены, а модели партнёров появляются и исчезают.Страница Google Cloud о версиях и жизненном цикле моделейсуществует именно потому, что это реальная эксплуатационная проблема. На ней определены термины жизненного цикла для моделей Gemini и эмбеддингов, указаны даты, рекомендации по обновлениям и пути миграции. В примечаниях к выпускам описаны производственные обновления, функции, известные проблемы и выведенная из эксплуатации функциональность.

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

Google Cloud может помочь, публикуя информацию о жизненном цикле и инструменты оценки. Заказчикам всё равно нужна дисциплина миграций. У каждого принятого процесса должна быть по возможности зафиксированная или объявленная модель, набор регрессионных тестов, репрезентативный набор данных, окно изменений, вариант отката или запасной вариант, а также ответственный, который следит за примечаниями к выпускам. Если процесс использует модель партнёра через Vertex AI, заказчик также зависит от жизненного цикла и условий этой партнёрской модели. Выбор из нескольких моделей снижает зависимость от одной модели, но может увеличить объём тестирования.

Это одна из причин, по которым знаменатель «принятый результат» полезен. Одиночный вызов модели может выглядеть дёшево. Регламентированный процесс включает будущие миграции. Если заказчик не может позволить себе тестировать изменения моделей, ему не стоит глубоко автоматизировать работу с высокими последствиями. Если процесс достаточно ценен, регулярная оценка и планирование миграций становятся частью реальной стоимости продукта.

Ёмкость и инциденты делают надёжность вопросом проектирования

У Google Cloud есть масштаб инфраструктуры для обслуживания корпоративного ИИ, но заказчикам не следует путать масштаб с бесконечной ёмкостью. В форме 10-Q за I квартал 2026 года Alphabet указаны неисполненные контрактные обязательства, связанные с Google Cloud, на сумму 462,3 млрд долларов и значительные инвестиции в техническую инфраструктуру. Там также сказано, что капитальные затраты в I квартале 2026 года составили 35,7 млрд долларов и что Alphabet планировал увеличить инвестиции в техническую инфраструктуру по сравнению с 2025 годом. Такой масштаб говорит о спросе и серьёзности намерений.

Он также показывает, что ИИ-ёмкость требует больших капиталовложений.

На продуктовом уровне Google Cloud предлагает несколько концепций потребления и ёмкости. Вобзоре Provisioned Throughputописана подписка с фиксированной стоимостью и фиксированным сроком, которая резервирует пропускную способность для поддерживаемых генеративных ИИ-моделей по моделям и регионам. Там рекомендовано рассматривать этот вариант для приложений реального времени, критически важных нагрузок со стабильно высокой пропускной способностью, предсказуемого пользовательского опыта и детерминированных затрат. Вдокументации по квотамперечислены региональные и модельные лимиты, квоты Agent Runtime, квоты оценки и поведение пакетной обработки. Там отмечено, что пакетный инференс Gemini использует общий пул и может ставить работу в очередь при нехватке ёмкости.

Эти детали — не мелочи для закупок. Они определяют, будет ли процесс надёжным. Агент техподдержки для нескольких внутренних сотрудников легче перенесёт колебания тарифа PayGo, чем система обработки претензий клиентов в часы пиковой нагрузки. Ночная пакетная оценка может подождать в очереди, если результат нужен завтра, но не если от него зависит развёртывание в течение ближайшего часа. Процессу со строгими требованиями к задержке может понадобиться Provisioned Throughput или запасной путь.

Детерминированная стоимость может быть не менее важна, чем детерминированная задержка, поскольку работа с моделями создаёт затраты на токены, поиск, журналирование и проверку, которые трудно предсказать на этапе пилота.

Зарегистрированные инциденты иллюстрируют ту же мысль. 27 февраля 2026 года Google Cloud сообщил обинциденте с Vertex AI Gemini APIпродолжительностью 1 час 58 минут, который затронул глобальный endpoint и регионы США. Первопричиной, согласно отчёту, стало изменение конфигурации сервиса фильтрации безопасности, поддерживающего модели Gemini, что привело к ошибкам перегрузки; устранение включало откат, добавление ёмкости, усиление контрольных точек валидации и улучшение оповещения. 18 июля 2025 годамультипродуктовый инцидент в us-east1затронул продукты, включая Cloud Run, Cloud Workflows, BigQuery, IAM, Cloud Monitoring, Vertex AI Online Prediction и VPC, после проблемы с аппаратным обеспечением в workflow/control plane.

Эти инциденты не доказывают, что Google Cloud необычно ненадёжен. Они доказывают, что регламентированные ИИ-процессы зависят от общих сервисов: API моделей, фильтров безопасности, регионов, сетей, IAM, мониторинга, оркестрации и платформ данных. Устойчивому процессу нужны правило для устаревших данных, правило повторов, запасная модель или очередь, сообщение об ухудшенном режиме, ручной маршрут для срочной работы и способ отличать отказ платформы от отказа модели. Модель может быть исправна, пока endpoint ограничивает частоту запросов. Данные могут быть корректны, пока падает исполнитель процесса.

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

Поэтому надёжность — отчасти свойство продукта, отчасти архитектурный выбор. Google Cloud предлагает SLA и варианты ёмкости. Заказчик всё равно решает, какие задачи заслуживают резервируемой пропускной способности, мультирегиональной архитектуры, ручного запасного пути или меньшей автоматизации.

Откат проще для вычислений, чем для принятого бизнес-состояния

У Google Cloud есть зрелые средства управления развёртыванием программной инфраструктуры.Cloud Runпозволяет командам разделять трафик, постепенно раскатывать ревизию и откатываться к предыдущей. В документации также предупреждается, что изменения трафика не мгновенны и что запросы, находящиеся в пути, продолжают выполняться во время перехода.Workflowsподдерживает конструкции try, retry и обработки исключений.

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

Но откат на уровне бизнеса сложнее, чем откат инфраструктуры. Если агент подготовил черновик ответа, а человек его не отправил, откат прост: отбросить черновик. Если агент обновил поле в CRM, подал форму о соответствии, изменил политику, отправил сообщение, одобрил возврат средств, открыл обращение в поддержку или внёс изменение в код, побочный эффект живёт за пределами endpoint модели. Откат ревизии Cloud Run не отменяет отправку сообщения и не возвращает прежнее понимание клиента. Повтор может усугубить временный сбой, если последующее действие не идемпотентно.

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

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

Истории заказчиков показывают внедрение, а не универсальный ответ

Истории заказчиков Google Cloud — полезный рыночный сигнал, потому что они показывают, какие процессы пытаются выстроить покупатели. Их не следует читать как независимые бенчмарки.

FletcherTechсообщила, что развернула Gemini Enterprise на основных данных за три недели, выдала 31 778 ответов 222 сотрудникам за три месяца и сэкономила более 2500 часов. В истории упомянуты коннекторы данных, Jira, ServiceNow, SharePoint, собственные ИИ-ассистенты и отдельный проект Google Cloud для управления ресурсами, доступом и затратами. Это близко к теме принятого результата: ценность не только в ассистенте, но и во встраивании в повседневные системы и средства контроля.

Fifth Dimensionсообщила, что использует Vertex AI для централизации инференса Gemini и Claude в документоёмких процессах коммерческой недвижимости; в стек входят Cloud SQL, Cloud Storage, Cloud Run и BigQuery. В истории описаны длительные процессы и заявленный целевой показатель надёжности 99,9 %. Это полезный пример Google Cloud как мультимодельной платформы процессов, а не среды только для Gemini.

Replitсообщила, что использует Claude на Vertex AI, Gemini, Cloud Run, Compute Engine, Cloud SQL и BigQuery для поддержки создания и развёртывания ПО с помощью ИИ. В истории сказано, что Replit поддерживает более 35 млн разработчиков и более 100 000 приложений через Cloud Run. Снова вывод архитектурный: агент связан с развёртыванием, данными и инфраструктурой.

Ограничения этих историй не менее важны. В них не раскрыты полные показатели исключений, ложные принятые результаты, минуты проверки человеком, время отката, миграционные работы, упавшие запросы, стоимость очистки данных или то, что происходило при деградации endpoint. Они не бесполезны из-за своей рекламной природы; они полезны, если читать их как свидетельство внедрения. Они показывают, что заказчики переносят реальную работу на ИИ-поверхности Google Cloud. Они не доказывают, что каждая компания сэкономит деньги с учётом затрат на надзор и интеграцию.

Коммерческий аргумент зависит от сокращения общего объёма работы

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

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

Набор альтернатив широк. Ручная работа мало зависит от платформы, но дорога по труду и даёт неоднородные доказательства. ИИ в существующем SaaS может иметь лучшую интеграцию с предметной областью, но более слабое сквозное управление или меньший выбор моделей. Другой облачный или модельный провайдер может предложить лучшую производительность моделей или соответствие экосистеме, но потребовать иной интеграции данных и идентичностей. Open source может снизить зависимость от вендора и улучшить контроль, но увеличить работу по хостингу, безопасности, оценке и эксплуатации.

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

Затраты на переход следует учитывать с самого начала. Если заказчик строит вокруг Google Cloud хранилища данных, наборы для оценки, роли IAM, сервисы Cloud Run, Workflows, происхождение данных BigQuery, маршруты аудита, дашборды и процессы поддержки, он получает связность, но теряет переносимость. Конкурирующую модель можно вызывать через Vertex AI или отдельного провайдера, но система принятия результатов — это нечто большее, чем модель. Она включает журналы, права доступа, средства оценки, контракты данных и паттерны развёртывания.

Это не повод избегать Google Cloud. Это повод заранее проектировать пути выхода. Храните наборы для оценки в переносимых форматах. По возможности держите бизнес-правила вне свободных инструкций. Отделяйте адаптеры моделей от логики процесса. Отслеживайте исходные документы и схемы выходных данных. Делайте записи аудита читаемыми за пределами одной консоли. Лучший исход для заказчика — не нулевая зависимость от вендора, а достаточная модульность, при которой Google Cloud зарабатывает нагрузку, сокращая работу, а не запирая процесс.

Что стоит спросить серьёзному покупателю

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

Применительно к Google Cloud покупателю стоит спросить, нужен ли процессу ассистентский опыт Gemini Enterprise для сотрудников, поверхность создания и управления Agent Platform, обоснование через Agent Search, управление данными BigQuery, развёртывание Cloud Run, оркестрация Workflows — или всё сразу. Покупка всех компонентов без определения задачи создаёт платформенную программу, а не надёжный процесс. Покупка слишком малого создаёт демо модели, которым невозможно управлять.

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

Следует протестировать инъекции инструкций и небезопасную обработку выходных данных, потому что список рисков LLM от OWASP — не теория для систем, передающих выходные данные модели в инструменты.

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

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