GCP

Google Cloud puts almost the entire AI surface behind one product: Vertex AI. Classic ML training, the Model Garden catalogue, Gemini and Gemma inference, Vertex AI Search, and the Agent Development Kit all sit inside the same project, the same IAM model, and the same SDK. There is no separate GenAI product to procure alongside the ML platform, which keeps the operational surface smaller than platforms that grew their AI layer as a second product line.

Two things genuinely differentiate the stack. Vertex AI Search is the most managed RAG offering of the platforms covered here - ingestion, chunking, embedding, hybrid indexing, and cited generation arrive as one service rather than five components you assemble and keep in sync. And Gemini's context windows are large enough to change design decisions: 1M tokens on Flash, 2M on Pro means documents that would otherwise force a retrieval pipeline can be passed whole.

The counterweight is positional rather than technical. In most JMAN engagements GCP is not already the client's data platform, so choosing it means adding a cloud rather than extending one. Documentation quality is inconsistent compared with Azure, and onboarding takes longer as a result. GCP earns its place on capability, not on incumbency, and is more often an addition to an estate than the default choice for it.

When to choose GCP: the client already runs on Google Cloud or BigQuery, the workload needs model breadth without a second vendor integration, the use case is document-heavy or multimodal, or the team wants a managed RAG service instead of a hand-built retrieval pipeline.

Architecture

The ML platform feeds the generative layer (tuned models land in the same registry as trained ones), and the generative layer backs the agent layer. Document AI enters from the side, turning PDFs and scans into structured text that Vertex AI Search indexes or Gemini reasons over directly. This is the AI service stack only. For the end-to-end GCP data platform underneath it - Cloud Data Fusion for ingestion, Dataproc and Dataflow as a distinct process-and-transform tier, Cloud Workflows for orchestration, Tableau reading the semantic model - see Target Architectures.

---

Built-in AI Capabilities

Data Science & ML

Vertex AI's ML platform predates the GenAI push and shows it. This is the most settled layer in the stack.

Generative AI

Agentic AI

ADK is code-first throughout. There is no visual agent builder for business users on GCP, so treat agent development as an engineering activity with an engineering delivery model. Background on the patterns it implements is in Agents.

---

Document AI

Document AI sits outside the three layers above and is a genuine GCP strength. It ships pre-trained processors for common document types rather than expecting you to train an extractor from scratch.

The specialised processors outperform general OCR on their target document types, and Layout Parser is the more useful default for RAG because structure-aware chunks retrieve better than fixed-size splits. The usual production pattern is a two-stage pipeline: Document AI extracts, then Gemini reasons over what was extracted. Comparison against other OCR options is in OCR and Document Processing.

---

Available Models

Model Garden matters more than the Gemini lineup alone suggests: choosing GCP does not commit the solution to Google models. Route to Claude or an open-weight model through the same endpoint and IAM boundary when the task calls for it, without a second vendor contract.

---

Custom AI Enablement: Managed RAG in One Call

The pattern that distinguishes GCP: point Vertex AI Search at a Cloud Storage bucket, BigQuery dataset, or site, and it handles chunking, embedding, and hybrid indexing on ingest. A single search request then returns both ranked documents and a Gemini-generated summary grounded in them, with citations. The API call is the RAG pipeline.

from google.cloud import discoveryengine_v1 as discoveryengine

client = discoveryengine.SearchServiceClient()
spec = discoveryengine.SearchRequest.ContentSearchSpec

response = client.search(
    request=discoveryengine.SearchRequest(
        serving_config=(
            "projects/my-project/locations/global/collections/default_collection"
            "/dataStores/product-docs-store/servingConfigs/default_search"
        ),
        query="What is the SLA for enterprise support?",
        page_size=5,
        content_search_spec=spec(
            summary_spec=spec.SummarySpec(
                summary_result_count=3,
                model_spec=spec.SummarySpec.ModelSpec(version="gemini-2.0-flash"),
            )
        ),
    )
)

print(response.summary.summary_text)
for result in response.results:
    print(f"  Source: {result.document.derived_struct_data['title']}")

Compare that with the component count of a self-assembled pipeline: a chunker, an embedding job, a vector index, a retriever, a reranker, and a generation call, each versioned and monitored separately. The trade is control. When retrieval quality is good enough out of the box, this is the fastest path to a grounded answer on any of these platforms. When it is not, Vertex AI Vector Search gives back the components, and the assembly work returns with them.

---

Cost Model

GCP AI spend splits across three billing shapes, and mixing them up is the usual source of forecasting errors:

• Managed model inference (Gemini, Gemma, Model Garden) - per token, with input and output priced separately. Gemini Flash and the Gemma tiers sit at the aggressive end of the market, which is a real part of the GCP case at sustained volume.
• Custom training and self-hosted endpoints - billed on compute (CPU, GPU, or TPU hours) for as long as the node runs. An endpoint with no traffic still bills, so idle dev endpoints are a common source of waste.
• Managed services - Vertex AI Search bills on indexed volume and query count, separately from generation. Document AI bills per page processed.

Prices change frequently. Verify against the official pages before any client scoping conversation:

---

GCP vs Azure

Azure is the platform GCP most often displaces or supplements in a JMAN context, so this is the comparison that decides most engagements.

The honest verdict: GCP wins on model breadth, long context, and time-to-first-working-RAG. Azure wins on ecosystem fit, compliance tooling, low-code reach, and the practical fact that the client is usually already there. Full ratings across all five platforms are in the Platform Comparison.

---

Key Takeaways

• Vertex AI unifies classic ML and generative AI under one product, one IAM model, and one SDK. If an engagement does both, that unified surface cuts real operational overhead compared with running two separately governed platforms.
• Vertex AI Search is the strongest managed RAG service of these platforms. It gets a knowledge-base pilot working with less assembly than anything else here, at the cost of the tuning surface you will want when retrieval quality plateaus.
• Gemini's 1M to 2M token context windows change what needs a retrieval pipeline at all, but long context bills per token per turn. Cost the long-context design against the retrieval design rather than assuming it is simpler and cheaper.
• ADK is the cleanest agent framework on any hyperscaler and is code-first only. There is no low-code builder for business users, so scope agent work as engineering work.
• Document AI's specialised processors (invoice, contract, form, layout) outperform general OCR on their target types and are trainable from around 10 labelled examples. Pair extraction with Gemini reasoning rather than asking one model to do both.
• Orchestration and automated compliance monitoring are the weakest areas relative to Azure and AWS. Confirm requirements there early, especially in regulated engagements.
• GCP is rarely the incumbent data platform in a JMAN context. It is usually an addition rather than the default, so the second-cloud overhead belongs in the business case alongside per-token pricing.