+180 XP

Vertex AI: Gemini in die Produktion bringen

# Vertex AI: Gemini in die Produktion bringen

Vertex AI ist der Punkt, an dem Ihr Gemini-Prototyp aufhört, eine schicke Demo zu sein, und zu einem System wird, dem Ihr Unternehmen echte Nutzer, echte Daten und echtes Geld anvertrauen kann. Bisher haben Sie Gemini über die Gemini API und Google AI Studio aufgerufen. Dieser Weg ist perfekt, um schnell zu bauen und zu iterieren. Sobald Ihr Projekt aber Enterprise-Sicherheit, regionale Datenkontrolle, Audit Trails oder planbare Skalierung braucht, wechseln Sie zu Vertex AI, der Managed-Plattform von Google Cloud für den Betrieb von KI.

In dieser Lektion geht es um diesen Wechsel: wann er sinnvoll ist, was sich tatsächlich ändert und wie Sie die Entscheidung treffen, ohne sie zu zerdenken.

Zwei Türen zu denselben Modellen

Die Gemini API auf ai.google.dev kennen Sie schon. Sie gibt Ihnen einen API-Key, ein großzügiges Free Tier und die schnellste mögliche Schleife von der Idee zum funktionierenden Call. Sie wird manchmal auch Gemini Developer API genannt.

Vertex AI ist die zweite Tür zu *denselben* Gemini-Modellen (Pro, Flash und die übrigen), nur eingebettet in die Maschinerie von Google Cloud: IAM (Identity and Access Management), VPC-Networking, regionale Endpoints, Logging und Quota-Management. Gleiche Modellintelligenz, ganz andere operative Oberfläche.

Das zentrale Denkmodell: Sie wechseln nicht das Modell, Sie wechseln das Gebäude, in dem das Modell wohnt. AI Studio ist eine Werkstatt. Vertex AI ist eine regulierte Fabrikhalle.

Der Unterschied im Code ist kleiner, als Sie vielleicht befürchten. Gleiches SDK, andere Konfiguration:

python
from google import genai

# Developer API: nur ein Key
dev = genai.Client(api_key="YOUR_API_KEY")

# Vertex AI: Projekt + Region, kein Key (nutzt Google Cloud Auth)
prod = genai.Client(
    vertexai=True,
    project="my-gcp-project",
    location="us-central1",
)

response = prod.models.generate_content(
    model="gemini-2.5-flash",
    contents="Summarize this support ticket in one sentence.",
)
print(response.text)

Beachten Sie, was verschwunden ist: der API-Key. Auf Vertex kommt die Identität aus Google-Cloud-Credentials (ein Service Account oder Ihr eigener gcloud-Login), nicht aus einem String, den Sie in den Code kopieren. Genau diese eine Änderung ist der Kern dafür, warum Unternehmen wechseln.

Was sich beim Wechsel tatsächlich ändert

1. Authentifizierung und Zugriffskontrolle

Bei der Developer API ist ein API-Key ein Bearer Token: wer ihn hat, kann ihn nutzen. Für einen Prototyp ist das in Ordnung, in der Produktion gefährlich.

Vertex nutzt IAM. Sie geben einem Service Account (einer nicht-menschlichen Identität für Ihre App) eine bestimmte Rolle wie roles/aiplatform.user. Der Zugriff ist eingegrenzt, widerrufbar und pro Identität geloggt. Sie können beantworten, „wer hat Gemini wann und von wo aufgerufen“, weil jeder Request durch Cloud Audit Logs läuft.

bash
# Einem Service Account die Berechtigung geben, Vertex-AI-Modelle aufzurufen
gcloud projects add-iam-policy-binding my-gcp-project \
  --member="serviceAccount:app@my-gcp-project.iam.gserviceaccount.com" \
  --role="roles/aiplatform.user"

2. Data Residency und der Data-Governance-Vertrag

Das ist der Grund, warum regulierte Branchen (Gesundheitswesen, Finanzen, öffentlicher Sektor) die Developer API oft überhaupt nicht nutzen können. Vertex erlaubt Ihnen, die Verarbeitung an eine Region zu binden (das location im Code oben), sodass Daten zum Beispiel in der EU bleiben. Außerdem erhalten Sie die Enterprise-Data-Governance-Bedingungen, die die meisten Rechtsabteilungen verlangen: Ihre Prompts und Outputs werden nicht zum Training von Googles Modellen verwendet, und Sie bekommen vertragliche Zusagen dazu. Die aktuellen Governance-Details finden Sie unter cloud.google.com/vertex-ai.

3. Networking und Isolation

Vertex-AI-Endpoints können über Private Service Connect innerhalb Ihrer VPC (Virtual Private Cloud) liegen, sodass Traffic zu Gemini nie das öffentliche Internet durchläuft. In Kombination mit VPC Service Controls bauen Sie einen Perimeter, der Datenabfluss verhindert, selbst wenn ein Credential kompromittiert wird.

4. Quotas, Skalierung und Provisioned Throughput

Das Free Tier und die Pay-as-you-go-Limits der Developer API sind fürs Bauen gedacht. Vertex gibt Ihnen echtes Quota-Management und eine Option namens Provisioned Throughput: Sie reservieren dedizierte Kapazität, damit ein Traffic-Spike Sie nicht im schlechtesten Moment ins Rate-Limit laufen lässt. Sie tauschen etwas Flexibilität gegen garantierte, planbare Performance. Für eine kundenseitige App im Maßstab ist diese Planbarkeit das Produkt.

5. Grounding und Enterprise-RAG

RAG haben Sie konzeptionell verstanden. Vertex operationalisiert es. Grounding with Google Search gibt es an beiden Türen, aber Vertex ergänzt Vertex AI Search und Grounding gegen *Ihre eigenen* Data Stores: Sie verbinden ein Korpus interner Dokumente, und Gemini antwortet daraus mit Zitationen, als Managed Service statt als Infrastruktur, die Sie selbst pflegen. Das ist die produktionsreife Version des RAG, das Sie früher in diesem Pfad prototypisiert haben.

Wann Sie wechseln sollten (und wann nicht)

Wechseln Sie nicht, nur weil „Produktion“ seriös klingt. Die Developer API trägt echte Workloads problemlos. Wechseln Sie, wenn einer dieser Punkte zutrifft:

  • Eine Compliance- oder Rechtsanforderung verlangt Data Residency, Audit Logs oder vertragliche Datenbedingungen.
  • Sie brauchen Zugriffskontrolle auf IAM-Niveau statt geteilter API-Keys.
  • Sie brauchen planbare Skalierung (Provisioned Throughput, formale SLAs, Quota-Garantien).
  • Sie sind schon auf Google Cloud und wollen einheitliches Billing, Monitoring und Networking.
  • Sie brauchen Managed RAG oder MLOps (Modellevaluierung, Deployment-Pipelines, Monitoring von Quality Drift).

Bleiben Sie auf der Developer API, wenn Sie prototypisieren, ein internes Tool mit geringem Risiko bauen, ein Side Project veröffentlichen oder schnell unterwegs sind und der Governance-Overhead Sie nur bremsen würde.

Gemini on Vertex AI vs the Gemini API

Watch on YouTube

Ein konkretes Entscheidungsbeispiel

Ein mittelgroßer Krankenversicherer baut einen internen Assistenten, der Mitarbeiterfragen zur Leistungsrichtlinie beantwortet. Das Team prototypisiert ihn an einem Nachmittag in AI Studio: Richtlinien-PDFs einfügen, Grounding verdrahten, ein Gem an einige Kollegen ausrollen. Es funktioniert hervorragend.

Dann entscheiden sie, ihn an 4.000 Mitarbeitende auszurollen und an Live-Leistungsdaten anzubinden. Jetzt ändern sich die Fragen:

  • Die Leistungsdaten enthalten Gesundheitsinformationen von Versicherten. Dürfen sie die EU verlassen? Nein. → Vertex mit einer EU-Region.
  • Wer darf das System abfragen, und können wir das nachweisen? → IAM-Rollen plus Cloud Audit Logs.
  • Was passiert bei der Spitzenlast am Montagmorgen? → Provisioned Throughput, damit der Assistent im Ansturm nicht ins Rate-Limit läuft.
  • Wo liegt das Richtlinien-Korpus? → Vertex AI Search, managed, mit Zitationen, statt eines selbstgebauten Vector Stores, den jemand babysitten muss.

Keine dieser Anforderungen war während des Prototyps sichtbar. Alle sind beim Rollout nicht verhandelbar. Das ist der Migrationsauslöser: nicht das Modell, sondern die *Verpflichtungen* rund um das Modell. Der Nachmittags-Prototyp und das Produktionssystem laufen auf *demselben* gemini-2.5-flash. Nur das Gebäude hat sich geändert.

Wissenscheck

1. Was ist laut dem zentralen Denkmodell der Lektion der grundlegende Unterschied zwischen der Gemini Developer API und Vertex AI?

2. Warum beschreibt die Lektion das Verschwinden des API-Keys als „den Kern dafür, warum Unternehmen wechseln“?

3. Ein Team baut einen schnellen Prototyp und will die schnellste mögliche Schleife von der Idee zu einem funktionierenden Gemini-Call. Welchen Weg empfiehlt die Lektion, und warum?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE operativen Fähigkeiten aus, die die Lektion mit dem Wechsel zu Vertex AI verbindet.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Aussagen aus, die korrekt widerspiegeln, was sich bei der Migration von Code von der Developer API zu Vertex AI ändert (und was nicht).

Wählen Sie alle richtigen Antworten aus.

Wie das mit dem übrigen Gemini-Stack zusammenhängt

Vertex ist kein separates Universum. Es ist die Produktionsebene unter den Tools, die Sie schon kennen:

  • Agent Development Kit (ADK): Die Agents, die Sie mit ADK bauen, können Sie lokal entwickeln und dann auf Vertex AI Agent Engine deployen, eine Managed Runtime, die Sessions, Skalierung und State für Sie übernimmt. Gleicher Agent-Code, Produktions-Hosting.
  • Gemini Code Assist und die Gemini CLI bleiben Teil Ihres Entwickler-Workflows, unabhängig davon, durch welche Tür Sie ausliefern. Sie helfen Ihnen, den Deployment-Code zu schreiben; sie sind nicht Teil der Runtime.
  • Apps Script und Gemini in Workspace sind eine ganz andere Ebene: Sie leben in Docs, Gmail und Sheets für die Produktivität von Endnutzern. Dort hosten Sie keine skalierte Anwendung. Verwechseln Sie nicht „Gemini hilft mir, eine E-Mail zu schreiben“ mit „Gemini bedient 4.000 Mitarbeitende über einen governierten Endpoint“.

Eine klare Merkhilfe: AI Studio und die Developer API sind fürs Bauen. Workspace und Gems sind fürs Nutzen. Vertex AI ist fürs Betreiben im Maßstab unter Regeln.

Die Migration ist vor allem Konfiguration, kein Rewrite

Weil das SDK geteilt wird, ist das Portieren eines funktionierenden Prototyps meist klein. Die echte Arbeit ist das umgebende Cloud-Setup, nicht die KI-Logik.

Eine minimale produktionsnahe Konfiguration sieht so aus:

yaml
# app config: same model, production posture
model: gemini-2.5-flash
vertex:
  project: my-gcp-project
  location: europe-west4        # EU data residency
  use_provisioned_throughput: true
grounding:
  datastore: claims-policy-corpus   # Vertex AI Search
  include_citations: true
auth:
  service_account: app@my-gcp-project.iam.gserviceaccount.com

Ihr Prompt Engineering, Ihre Tool-Definitionen, Ihre Modellwahl: alles wird übernommen. Dazu kommen Identität, Region, Kapazität und Governance. Diese Asymmetrie ist die gute Nachricht. Zeit, die Sie investieren, um Ihren Prototyp exzellent zu machen, ist beim Wechsel nicht verloren; die Intelligenz überträgt sich unangetastet.

Ein ehrlicher Vorbehalt

Vertex AI bringt operatives Gewicht mit: Google-Cloud-Projekte, IAM, Billing-Setup, Networking-Entscheidungen. Für einen leicht technischen Profi ist das ein echter Sprung in der Komplexität, und für viele Projekte ist es tatsächlich überdimensioniert. Der Fehler ist, zu früh zu wechseln, „um sicher zu sein“, und in Cloud-Konfiguration zu versinken, bevor Sie validiert haben, dass überhaupt jemand das Produkt will. Validieren Sie auf der Developer API. Migrieren Sie, wenn eine Verpflichtung, nicht ein Ehrgeiz, Sie dazu zwingt.

Wichtigste Erkenntnisse

  • Gleiche Modelle, anderes Gebäude. Vertex AI liefert dieselben Gemini-Modelle wie die Developer API; Sie wechseln die SDK-Konfiguration (vertexai=True plus project und location), nicht Ihre Prompts oder Ihre Logik.
  • Wechseln Sie wegen Verpflichtungen, nicht wegen Bauchgefühl. Der Migrationsauslöser ist ein konkreter Bedarf: Data Residency, IAM-Zugriffskontrolle, Audit Logs, planbare Skalierung oder Managed RAG. Trifft nichts davon zu, bleiben Sie auf der Developer API und bleiben Sie schnell.
  • Identität ersetzt den API-Key. Auf Vertex läuft der Zugriff über Service Accounts und IAM-Rollen, was „wer hat was getan“ auditierbar und widerrufbar macht, genau das, was regulierte Teams brauchen.
  • Die Region ist eine Entscheidung erster Klasse. Setzen Sie location, um die Verarbeitung innerhalb einer Jurisdiktion zu halten, und kombinieren Sie das mit VPC Service Controls und Provisioned Throughput für eine echte Produktionsaufstellung.
  • Ihr Prototyp ist kein Wegwerfprodukt. Weil die Intelligenz unangetastet übertragen wird, investieren Sie zuerst in gute Prompts, gutes Grounding und gute Agent-Logik auf der einfachen API und migrieren dann, wenn die Regeln es verlangen.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • Die Surface an den Einsatz anpassen: AI Studio, API, Gems, dann Vertex AI
Vollständiges Action Playbook ansehen