Vertex AI: Gemini in Produktion bringen

Mit Vertex AI wird aus Ihrem Gemini-Prototyp, bisher eine clevere Demo, ein System, dem Ihr Unternehmen echte Nutzer, echte Daten und echtes Geld anvertrauen kann. Bisher haben Sie Gemini über die Gemini APIAPIApplication Programming Interface: eine standardisierte Schnittstelle, über die Anwendungen kommunizieren und Daten austauschen, ohne die interne Funktionsweise der jeweils anderen zu kennen.Vollständige Definition ansehen → und Google AI Studio aufgerufen. Dieser Weg ist ideal, um schnell zu bauen und zu iterieren. Aber sobald Ihr Projekt Enterprise-Sicherheit, regionale Datenkontrolle, Audit Trails oder planbare Skalierung braucht, steigen Sie auf Vertex AI um, die Managed Platform von Google Cloud für den produktiven Einsatz von KI.

Diese Lektion behandelt diesen Umstieg: wann Sie wechseln, was sich tatsächlich ändert und wie Sie die Entscheidung treffen, ohne sie zu zerdenken.

Zwei Türen zu denselben Modellen

Sie kennen bereits die Gemini API auf ai.google.dev. Sie bekommen dort einen API-Key, ein großzügiges Free Tier und den schnellstmöglichen Weg von der Idee zum funktionierenden Aufruf. Das wird manchmal auch Gemini Developer API genannt.

Vertex AI ist die zweite Tür zu *denselben* Gemini-Modellen (der Gemini-3-Familie mit Pro und Flash sowie älteren Versionen, die noch unterstützt werden), allerdings eingebettet in die Infrastruktur von Google Cloud: IAM (Identity and Access Management), VPC-Networking, regionale Endpoints, Logging und Quota-Management. Dieselbe Modellintelligenz, eine völlig andere operative Oberfläche.

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

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

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-Authentifizierung)
prod = genai.Client(
    vertexai=True,
    project="my-gcp-project",
    location="us-central1",
)

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

Modell-IDs ändern sich, wenn Google Versionen veröffentlicht und abkündigt. Prüfen Sie daher die aktuelle Liste auf der Seite zu den Vertex-AI-Modellversionen, bevor Sie eine ID festschreiben. Für Gemini-2.5-Modelle etwa sind auf Vertex Abkündigungstermine veröffentlicht. In Produktion gehört die Modell-ID in die Konfiguration, und Sie verfolgen die Retirement-Termine genauso wie bei jeder anderen Abhängigkeit.

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

Was sich beim Wechsel tatsächlich ändert

1. Authentifizierung und Zugriffskontrolle

Bei der Developer API ist ein API-Key ein Bearer TokenTokenEin Token ist die grundlegende Texteinheit, die Sprachmodelle verarbeiten, oft ein Wortfragment, ein ganzes Wort oder ein Satzzeichen und nicht ein einzelnes Zeichen.Vollständige Definition ansehen →: Wer ihn besitzt, kann ihn nutzen. Für einen Prototyp ist das in Ordnung, für Produktion gefährlich.

Vertex nutzt IAM. Sie weisen einem Service Account (einer nicht-menschlichen Identität für Ihre App) eine bestimmte Rolle wie roles/aiplatform.user zu. Der Zugriff ist eingegrenzt, widerrufbar und wird pro Identität protokolliert. Sie kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen beantworten, „wer Gemini wann und von wo aufgerufen hat“, weil jede Anfrage durch die Cloud Audit Logs läuft.

# Einem Service Account die Berechtigung erteilen, 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 ResidencyData ResidencyDie Anforderung, Daten physisch in einem bestimmten Land oder einer Region zu speichern und zu verarbeiten, oft aus rechtlichen oder vertraglichen Gründen.Vollständige Definition ansehen → und der Data-Governance-Vertrag

Aus diesem Grund können regulierte Branchen (Gesundheitswesen, Finanzen, öffentlicher Sektor) die Developer API oft gar nicht nutzen. Mit Vertex können Sie die Verarbeitung an eine Region binden (die 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 der Google-Modelle verwendet, und Sie bekommen dazu vertragliche Zusagen. Aktuelle Details zur Governance finden Sie unter cloud.google.com/vertex-ai. Beachten Sie, dass nicht jedes Modell in jeder Region verfügbar ist.

3. Networking und Isolation

Vertex-AI-Endpoints können über Private Service Connect innerhalb Ihrer VPC (Virtual Private Cloud) liegen, sodass der Traffic zu Gemini nie über das öffentliche Internet läuft. Zusammen mit VPC Service Controls bauen Sie einen Perimeter, der verhindert, dass Daten abfließen, selbst wenn Credentials kompromittiert werden.

4. Quotas, Skalierung und Provisioned Throughput

Das Free Tier und die Pay-as-you-go-Limits der Developer API sind fürs Bauen ausgelegt. Vertex bietet ein richtiges Quota-Management und eine Option namens Provisioned Throughput: Sie reservieren dedizierte Kapazität, damit Sie bei einer Traffic-Spitze nicht ausgerechnet im ungünstigsten Moment ins Rate Limit laufen. Sie tauschen etwas Flexibilität gegen garantierte, planbare Performance. Bei einer kundenseitigen App im großen MaMaEinsatz von Software, um wiederkehrende Marketingaufgaben und Kampagnen zu automatisieren und Personalisierung in großem Maßstab über Kanäle wie E-Mail, Web und Social zu ermöglichen.Vollständige Definition ansehen →ßstab ist genau diese Planbarkeit das Produkt.

5. Grounding und Enterprise-RAGRAGVerfahren, mit dem ein KI-Modell aus Ihren eigenen Dokumenten antwortet, indem es relevante Passagen abruft, bevor es eine Antwort erzeugt.Vollständige Definition ansehen →

RAG kennen Sie bereits konzeptionell. Vertex macht es betriebsfähig. Grounding with Google Search gibt es hinter beiden Türen, aber Vertex ergänzt Vertex AI Search und Grounding auf Basis *Ihrer eigenen* Data Stores: Sie binden einen Korpus interner Dokumente an, und Gemini antwortet daraus mit Quellenangaben, betrieben als Managed Service statt als Eigenbau, den Sie pflegen müssen. Das ist die produktionsreife Version des RAG, das Sie früher in diesem Lernpfad als Prototyp gebaut haben.

Wann Sie wechseln sollten (und wann nicht)

Wechseln Sie nicht, nur weil „Produktion“ ernst klingt. Die Developer API bewältigt echte Workloads problemlos. Wechseln Sie, wenn einer dieser Punkte zutrifft:

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

Bleiben Sie bei der Developer API, wenn Sie prototypisieren, ein internes Tool mit geringem Risiko bauen, ein Nebenprojekt ausliefern oder schnell vorankommen wollen und der Governance-Aufwand Sie nur bremsen würde.

Ein konkretes Entscheidungsbeispiel

Ein mittelgroßererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → Krankenversicherer baut einen internen Assistenten, der Fragen von Mitarbeitenden zu den Richtlinien der Leistungsabwicklung beantwortet. Das Team baut den Prototyp an einem Nachmittag in AI Studio: Richtlinien-PDFs einfügen, Grounding anbinden, ein Gem an ein paar Kollegen verteilen. Es funktioniert hervorragend.

Dann beschließt das Team, den Assistenten an 4.000 Mitarbeitende auszurollen und an Live-Leistungsdaten anzubinden. Jetzt ändern sich die Fragen:

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

Keine dieser Anforderungen war während des Prototyps sichtbar. Alle sind beim Rollout nicht verhandelbar. **Das ist der Auslöser für die Migration: die *Pflichten* rund um das Modell, nie das Modell selbst.** Der Nachmittagsprototyp und das Produktivsystem laufen auf *demselben* gemini-3-flash. Nur das Gebäude hat sich geändert.

Wie das mit dem restlichen Gemini-Stack zusammenhängt

Vertex ist kein separates Universum. Es ist die Produktionsschicht unter den Tools, die Sie bereits 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. Derselbe Agent-Code, produktives Hosting.
• Gemini Code Assist und die Gemini CLI bleiben in Ihrem Entwickler-Workflow, egal durch welche Tür Sie ausliefern. Sie helfen Ihnen beim Schreiben des Deployment-Codes; Teil der Runtime sind sie nicht.
• Apps Script und Gemini in Workspace sind eine ganz andere Ebene: Sie leben in Docs, Gmail und Sheets und dienen der 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 kontrollierten Endpoint“.

Eine saubere Merkhilfe: AI Studio und die Developer API sind zum Bauen da. Workspace und Gems sind zum Nutzen da. Vertex AI ist für den Betrieb im großen Maßstab unter Regeln da.

Die Migration ist vor allem Konfiguration, kein Rewrite

Da das SDK dasselbe ist, ist die Portierung eines funktionierenden Prototyps meist überschaubar. Die eigentliche Arbeit steckt im Cloud-Setup drumherum, nicht in der KI-Logik.

Eine minimale Konfiguration in Produktionsform sieht so aus:

# App-Konfiguration: dasselbe Modell, produktive Ausrichtung
model: gemini-3-flash            # aktuelle IDs und Retirement-Termine prüfen
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 EngineeringPrompt EngineeringPrompt Engineering ist die Praxis, Texteingaben so zu gestalten und zu verfeinern, dass große Sprachmodelle präzise, relevante und verlässliche Ergebnisse liefern.Vollständige Definition ansehen →, Ihre Tool-Definitionen, Ihre Modellwahl: All das wird übernommen. Was Sie ergänzen, sind 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 wird unverändert übertragen.

Ein ehrlicher Vorbehalt

Vertex AI bringt operatives Gewicht mit: Google-Cloud-Projekte, IAM, Billing-Setup, Networking-Entscheidungen. Für jemanden mit etwas technischem Hintergrund ist das ein echter Sprung in der Komplexität, und für viele Projekte ist es schlicht überdimensioniert. Der Fehler besteht darin, „sicherheitshalber“ zu früh zu wechseln 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 Pflicht Sie dazu zwingt, nicht ein Ehrgeiz.

Key Takeaways

• Dieselben Modelle, anderes Gebäude. Vertex AI liefert dieselben Gemini-Modelle wie die Developer API; Sie ändern die SDK-Konfiguration (vertexai=True plus project und location), nicht Ihre Prompts oder Ihre Logik.
• Wechseln Sie wegen Pflichten, nicht aus dem Bauch heraus. Auslöser für die Migration ist ein konkreter Bedarf: Data Residency, IAM-Zugriffskontrolle, Audit Logs, planbare Skalierung oder Managed RAG. Trifft nichts davon zu, bleiben Sie bei der Developer API und kommen weiter schnell voran.
• Identität ersetzt den API-Key. Auf Vertex läuft der Zugriff über Service Accounts und IAM-Rollen. Dadurch wird „wer hat was getan“ auditierbar und widerrufbar, genau das, was regulierte Teams verlangen.
• Die Region ist eine Grundsatzentscheidung. 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 Produktionsausrichtung.
• Legen Sie Modell-IDs in der Konfiguration fest und behalten Sie Retirement-Termine im Blick. Gemini-Versionen werden nach einem veröffentlichten Zeitplan abgekündigt; behandeln Sie die Modell-ID wie jede andere Abhängigkeit, die Sie aktualisieren.
• Ihr Prototyp ist kein Wegwerfprodukt. Da die Intelligenz unverändert übertragen wird, investieren Sie zuerst in gute Prompts, Grounding und Agent-Logik auf der einfachen API und migrieren dann, wenn die Regeln es verlangen.