​

Google Vertex AI — Inferenz in Ihrem Konto

​

Was auf Vertex läuft und was nicht

​

Wie viele Cloud-Anbieter Sie verwenden können

​

Voraussetzungen

• Ein Google Cloud-Projekt mit aktivierter Abrechnung.
• Die Agent Platform API (Vertex AI API) ist in diesem Projekt aktiviert (der Dienst aiplatform.googleapis.com).
• Ein Dienstkonto in Ihrem Projekt mit der Rolle Agent Platform User (roles/aiplatform.user) und eine dieser beiden Möglichkeiten, damit SecureAI als dieses Konto handeln kann:
  • Option A – ein JSON-Schlüssel für dieses Dienstkonto.
  • Option B – schlüssellos (Identitätswechsel): Sie gewähren dem im Panel angezeigten SecureAI-Dienstkonto die Rolle Service Account Token Creator (roles/iam.serviceAccountTokenCreator) für Ihr Dienstkonto, und es wird kein Schlüssel gespeichert. Diese Option ist nur verfügbar, wenn Ihre SecureAI-Bereitstellung sie anbietet; andernfalls zeigt das Panel sie deaktiviert mit dem Hinweis Keyless access is not enabled on this deployment.
• Admin-Berechtigung für den Bereich Integrationen von SecureAI. Mit Leseberechtigung können Sie die Konfiguration ansehen, aber nicht ändern.

​

Schritt 1. Das Projekt in Google Cloud vorbereiten

gcloud config set project MY_PROJECT

# 1. Agent Platform API (Vertex AI API) aktivieren
gcloud services enable aiplatform.googleapis.com

# 2. Ein eigenes Dienstkonto für SecureAI erstellen
gcloud iam service-accounts create secureai-vertex --display-name="SecureAI Vertex"

# 3. Ihm die minimale Rolle zum Aufrufen von Modellen gewähren
gcloud projects add-iam-policy-binding MY_PROJECT \
  --member="serviceAccount:secureai-vertex@MY_PROJECT.iam.gserviceaccount.com" \
  --role="roles/aiplatform.user"

# 4. Nur Option A: den JSON-Schlüssel erzeugen
gcloud iam service-accounts keys create key.json \
  --iam-account=secureai-vertex@MY_PROJECT.iam.gserviceaccount.com

​

Option B: SecureAI ohne Schlüssel autorisieren

1. Öffnen Sie in SecureAI das Vertex AI-Panel (siehe Schritt 2), wählen Sie Keyless (impersonation) und geben Sie die E-Mail-Adresse Ihres Dienstkontos unter Your service account to impersonate ein.
2. Das Panel zeigt den auszuführenden Befehl an, bereits ausgefüllt mit dem SecureAI-Dienstkonto Ihrer Bereitstellung. Kopieren Sie ihn mit Copy und führen Sie ihn in der Cloud Shell aus. Er sieht so aus:
   gcloud iam service-accounts add-iam-policy-binding secureai-vertex@MY_PROJECT.iam.gserviceaccount.com \
     --member="serviceAccount:SECUREAI_ACCOUNT" \
     --role="roles/iam.serviceAccountTokenCreator"
   
   Die Rolle wird für Ihr Dienstkonto gewährt, nicht für das Projekt: SecureAI kann nur als dieses Konto handeln, das seinerseits nur roles/aiplatform.user besitzt.

​

Offene Modelle (Llama, DeepSeek, Qwen, gpt-oss)

​

Schritt 2. Das Projekt in SecureAI verbinden

1. Gehen Sie zu Admin → Integrations, öffnen Sie die Kategorie AI providers und klicken Sie auf die Karte Google Vertex AI — Inference on your account.
2. Füllen Sie unter Connection Folgendes aus:

   Feld	Was einzugeben ist
   Google Cloud project ID	Die Projekt-ID (zum Beispiel my-project-123), nicht der Anzeigename.
   Vertex AI location	Belassen Sie zu Beginn global: Dort befinden sich die Standardmodelle Gemini 3 preview. Wenn Sie Datenresidenz benötigen, geben Sie eine Region ein (us-central1, europe-west4…): SecureAI sendet jede Anfrage an den von Ihnen gewählten regionalen Endpunkt, und wo Google sie verarbeitet, hängt von den Datenresidenz-Zusagen von Google ab. Mit global wählt Google die Region. Offene Modelle benötigen eine Region.
   Authentication	Option A: Lassen Sie Service-account key (JSON) ausgewählt und fügen Sie den vollständigen Inhalt von key.json in Service-account key JSON ein. Option B: Wählen Sie Keyless (impersonation), geben Sie die E-Mail-Adresse Ihres Dienstkontos unter Your service account to impersonate ein und führen Sie den Befehl aus, den das Panel anzeigt (siehe Option B: SecureAI ohne Schlüssel autorisieren oben).

   
3. Klicken Sie auf Save. Es wird noch kein Verkehr geroutet: Die Integration wird ausgeschaltet gespeichert, damit Sie sie zuerst testen können.

​

Schritt 3. Auswählen, was auf Vertex läuft

• Only these model families – die Familien, die Sie ankreuzen (Gemini, gpt-oss, DeepSeek, Llama, Qwen), laufen auf Ihrem Vertex; jedes andere Modell läuft weiterhin bei den Anbietern von SecureAI. Das ist die konservativste Art zu beginnen (Standard: nur Gemini).
• Remap everything to Vertex – alle LLM-Aufrufe laufen auf Ihrem Vertex. Modelle ohne Vertex-Entsprechung werden von einem Standardmodell bedient.

​

Schritt 4. Die Verbindung testen

1. Klicken Sie bei gespeicherter Integration unter Connection test auf Test connection.
2. SecureAI sendet eine minimale Anfrage an jedes Standardmodell, über denselben Pfad, den der echte Verkehr nutzen wird (Gateway, Richtlinien und Belege eingeschlossen), und zeigt jedes Ergebnis mit seiner Latenz an.
   
3. Wenn ein Modell fehlschlägt, zeigt das Panel den Grund an. Siehe den Abschnitt Fehlerbehebung am Ende dieser Seite.

​

Was die Identität sonst noch kann

​

Schritt 5. Das Routing prüfen und einschalten

1. Öffnen Sie Routing preview → Show which lane serves each model. Für jedes Modell des Katalogs wird angezeigt, ob Ihr Vertex es bedienen wird (und mit welchem Vertex-Modell) oder SecureAI, und welche Modelle vor den Nutzern ausgeblendet werden. Die Vorschau simuliert die eingeschaltete Integration, sodass Sie die Auswirkung prüfen können, bevor Sie sie aktivieren.
2. Wenn der Test erfolgreich ist, schalten Sie Route traffic to Vertex AI ein und klicken Sie erneut auf Save. Wenn Sie nicht speichern, bleibt der Schalter nicht eingeschaltet. Zum Einschalten müssen ein Projekt und eine Anmeldeinformation konfiguriert sein. Wenn Ihr Plan keinen weiteren Cloud-Anbieter erlaubt oder sich das Routing mit einem anderen überschneidet, lehnt SecureAI dies ab und erklärt den Grund (siehe Wie viele Cloud-Anbieter Sie verwenden können oben).
   
3. Die Karte wird grün: Routing to Vertex. Ist sie gespeichert, aber ausgeschaltet, zeigt sie in Gelb Configured · not routing to Vertex.

​

Schritt 6. In der Modellauswahl überprüfen

​

Was abgerechnet wird und an wen

• Die LLM-Nutzung stellt Google Ihrem Konto in Rechnung, nicht SecureAI. Sie sehen die Belastung in Ihrer Google Cloud-Abrechnung, mit Ihren Rabatten und CUDs angewendet.
• SecureAI zeigt die Kosten der auf Vertex bedienten Turns als Schätzung zum Listenpreis nur für Analysezwecke an. Sie dient als Referenz: Sie enthält Ihre Rabatte nicht, daher kann der tatsächliche Betrag von Google niedriger sein.
• Auf Ihrem Vertex bediente Turns zählen nicht zur Ausgabenobergrenze des Seats des jeweiligen Nutzers, es sei denn, Sie schalten Apply each seat’s spend cap to turns served in your account ein. Die Seat-Stufe gilt weiterhin: Ein Nutzer kann nur Modelle seiner Stufe oder darunter verwenden, auch wenn Ihr Vertex sie bedient.
• Ein Govern BYO-Seat kann nur Modelle verwenden, die auf der eigenen Infrastruktur Ihrer Organisation bereitgestellt werden: diejenigen, die Ihr Vertex (oder ein anderer verbundener Cloud-Anbieter) bedient, und die selbst gehosteten Modelle auf Ihren Servern. Jedes andere Modell wird abgelehnt, und die Auswahl bietet ihm Auto nicht an.

​

Sicherheit und Compliance

• Verschlüsselte Anmeldeinformationen oder gar keine. Bei Option A wird der Dienstkontoschlüssel verschlüsselt gespeichert (AES-256-GCM) und nie an den Browser zurückgegeben, nicht einmal an einen Administrator; der Bildschirm zeigt nur die E-Mail-Adresse des Kontos. Bei Option B wird kein Schlüssel gespeichert: SecureAI fordert bei Google kurzlebige Tokens an, die als Ihr Dienstkonto handeln.
• Der Pfad bleibt geschützt. Jeder Aufruf läuft über das SMLTP-Gateway von SecureAI: DLP, ein signiertes Autorisierungstoken pro Anfrage und ein überprüfbarer signierter Beleg.
• Datenresidenz. Mit einer festgelegten Region (zum Beispiel europe-west4) sendet SecureAI jede Anfrage an den Endpunkt dieser Region und wendet die Residenzrichtlinien Ihrer Organisation an. Wo Google die Anfrage verarbeitet, hängt von den Datenresidenz-Zusagen von Google ab.
• Schlägt geschlossen fehl. Wenn die Konfiguration nicht gelesen oder das Token von Google nicht abgerufen werden kann, wird die Anfrage abgelehnt; sie wird nicht an einen anderen Anbieter gesendet, es sei denn, Sie haben den Fallback erlaubt.
• Audit. Das Speichern, Testen oder Trennen der Integration wird im Aktivitätsprotokoll erfasst, mit den Namen der geänderten Felder und nie mit dem Schlüssel.
• Minimale Berechtigungen sichtbar. Der Verbindungstest prüft, was die Identität der Verbindung im Projekt sonst noch tun kann, und warnt, wenn sie Berechtigungen außerhalb von KI hat (siehe Was die Identität sonst noch kann in Schritt 4).
• Minimale Berechtigungen. roles/aiplatform.user genügt für die Inferenz; die Integration muss weder Ihr IAM noch Ihre Abrechnung lesen.

​

Trennen

• Option A: Wenn Sie den Schlüssel nicht mehr verwenden, widerrufen Sie ihn (Dienstkonten → Schlüssel).
• Option B: Entfernen Sie die Rolle roles/iam.serviceAccountTokenCreator, die Sie dem SecureAI-Dienstkonto für Ihr Dienstkonto gewährt haben (Dienstkonten → Ihr Konto → Berechtigungen).

​

Fehlerbehebung

​

Aktuelle Einschränkungen

• Claude und Mistral auf Vertex werden nicht unterstützt (sie verwenden eine andere API).
• Embeddings, Re-Ranking, OCR, der Admin-Assistent, die Bildgenerierung und die Echtzeit-Sprache bleiben bei von SecureAI verwalteten Anbietern.
• Ein Vertex-Projekt und ein Standort pro Organisation.
• Wie viele Inferenzanbieter Sie gleichzeitig aktivieren können, hängt von Ihrem Plan ab (Scale: 1, Enterprise: bis zu 3). Siehe Azure AI Foundry — Inference on your account und Amazon Bedrock — Inference on your account.
• Der Claude Code-Proxy verwendet Anthropic direkt und läuft nicht über Vertex.

​

Verwandte

• Google Cloud — Discovery – Inventar der Agenten, Modelle, Identitäten und Kosten des Projekts.
• Azure AI Foundry — Inference on your account
• Amazon Bedrock — Inference on your account
• Übersicht Cloud-KI-Anbieter
• Signierte Belege