Multi-Tenant-System für agentische KI

Last reviewed 2026-06-18 UTC

Dieses Dokument enthält eine Referenzarchitektur, die Ihnen beim Entwerfen und Bereitstellen eines Multi-Tenant-agentischen KI-Systems auf Google Cloudhilft. Wenn Ihr Unternehmen generative KI-Bereitstellungen skaliert, benötigen verschiedene Geschäftsbereiche spezialisierte KI-Agenten, die auf spezielle Tools zugreifen, bestimmte Betriebsregeln befolgen und vertrauliche Daten verarbeiten. Geschäftsbereiche können fragmentierte Anwendungssilos innerhalb einer Organisation entwickeln, was zu einem hohen Betriebsaufwand, schwerwiegenden Governance-Lücken und einem Risiko der Datenoffenlegung führen kann. Diese Architektur zeigt, wie Sie ein zentralisiertes System erstellen, mit dem Sie dezentrale Teams mit autonomen KI-Funktionen ausstatten und gleichzeitig einheitliche Sicherheits- und Compliance-Standards aufrechterhalten können.

Die Zielgruppe für dieses Dokument umfasst Architekten, Entwickler und Administratoren, die Multi-Agenten-Systeme für Unternehmen in der Cloud entwickeln und verwalten. In diesem Dokument wird davon ausgegangen, dass Sie grundlegende Kenntnisse der Konzepte von KI, ML und LLM sowie von agentenbasierter KI haben.

Im Abschnitt Bereitstellung dieses Dokuments finden Sie eine Implementierungsstrategie, die Ihnen beim Erstellen und Bereitstellen eines KI-Systems mit mehreren Mandanten und Agenten helfen soll.

Architektur

Das folgende Diagramm zeigt eine Architektur für ein mehrmandantenfähiges, agentenbasiertes KI-System, das einem Hub-and-Spoke-Modell folgt. Das Hub-and-Spoke-Modell ist ein Netzwerkdesign, bei dem eine zentrale Umgebung (Hub) mit mehreren isolierten Umgebungen (Spokes) verbunden ist.

Eine Architektur, die ein mandantenfähiges agentisches KI-System zeigt.

Die Architektur besteht aus den folgenden Komponenten:

Komponente Beschreibung
VPC Service Controls In der Architektur wird VPC Service Controls verwendet, um einen Dienstperimeter auf Organisationsebene zu konfigurieren. Dieser Dienstperimeter bietet eine strenge Sicherheitsgrenze und verhindert Daten-Exfiltration.
Routing-Hub

Der Routing-Hub dient als zentraler Eingangspunkt für die Architektur und umfasst die folgenden Komponenten:

  • Externer Application Load Balancer: Fungiert als zentraler Ingress-Punkt für externe oder interne Nutzer. Der Load-Balancer sorgt dafür, dass nur authentifizierter und sicherer Traffic das Frontend-Portal erreicht.
  • Google Cloud Armor und Model Armor: Der Load Balancer integriert Cloud Armor und Model Armor, um schädliche Prompts am Netzwerkrand zu prüfen und zu bereinigen. Der Routing-Hub verwendet Service Extensions auf dem externen Application Load Balancer, um Model Armor direkt in den Anfragefluss einzubinden.
  • Identity-Aware Proxy (IAP): Erzwingt ein Zero-Trust-Modell, um die Nutzeridentität und den Kontext zu prüfen, bevor eine Anfrage die Anwendung erreicht.
  • Frontend-Portal: Eine serverlose Cloud Run-Anwendung, die als Routing-Engine fungiert, um Anfragen an das entsprechende isolierte Mandantenprojekt weiterzuleiten.
Zentraler Hub für Governance und Sicherheit

Der zentrale Governance- und Sicherheitshub ist ein dediziertes Google Cloud Projekt, das eine zentrale Identity and Access Management (IAM), Protokollierung, Überwachung und Sicherheit für die gesamte Plattform bietet. Dieser Hub umfasst die folgenden Komponenten:

  • Security Command Center: Ein Dienst, der das gesamte Multi-Mandanten-System mit agentischer KI auf Sicherheitsrisiken überwacht.
  • IAM: Ein Framework zur Zugriffssteuerung, mit dem Identitäten und Berechtigungen für die gemeinsam genutzten Hubs und die Mandantenprojekte verwaltet werden. Diese Komponente bietet eine zentrale Verwaltung für alle menschlichen und maschinellen Identitäten.
  • Cloud Logging: Ein System, das Logs aus den freigegebenen Hubs und den isolierten Mandantenprojekten im zentralen Governance- und Sicherheitshub zusammenfasst.
Mandantenprojekte

Jedes Mandantenprojekt ist ein dediziertes Google Cloud Projekt für jede Geschäftseinheit. Einzelne Mandantenprojekte sind isolierte Umgebungen, die die folgenden Komponenten enthalten:

  • Principal Access Boundary-Richtlinie (PAB-Richtlinie): PAB-Richtlinien bieten eine interne, harte Isolation zwischen verschiedenen Geschäftseinheiten und sorgen dafür, dass Prinzipale nur auf Ressourcen innerhalb ihrer genehmigten Grenzen zugreifen können.
  • Agent Runtime on Gemini Enterprise Agent Platform: Eine Laufzeit, in der der Agent der jeweiligen Geschäftseinheit gehostet wird und in der benutzerdefinierter Orchestrierungscode ausgeführt wird, den Sie mit dem Agent Development Kit (ADK) erstellen.
  • Model Armor: Ein verwalteter Sicherheitsdienst, der schädliche Prompts und Antworten prüft und filtert. Sie schützt die Agent- und Rechenressourcen des Mandanten vor Bedrohungen wie Prompt-Injection-Angriffen.
  • MCP-Server (Model Context Protocol):MCP-Server ermöglichen den Zugriff zwischen dem Mandanten-Agent und dem Mandanten-Datenspeicher.
  • Mandantendatenspeicher: Ein dediziertes Daten-Repository wie BigQuery oder AlloyDB for PostgreSQL, in dem spezifische Daten der Geschäftseinheit gespeichert werden. Der Agent führt Retrieval-Augmented Generation (RAG) aus, um genauere Antworten basierend auf dem Kontext im Datenspeicher zu generieren. Um eine strenge Datenhoheit zu gewährleisten, können nur die Mandanten-Agents auf diese Daten zugreifen.
  • Gemini-Modelle: Für die Inferenzbereitstellung verwenden die Agents in dieser Beispielarchitektur das neueste Gemini-Modell auf der Gemini Enterprise Agent Platform.

Agentischer Ablauf

Das Beispielsystem mit mehreren Mandanten in der vorherigen Architektur hat den folgenden Ablauf:

  1. Die Anfrage eines Nutzers wird über einen externen Application Load Balancer weitergeleitet. Im Routing-Hub werden diese Prüfungen durchgeführt, um sicherzustellen, dass nur authentifizierter und sicherer Traffic das Frontend-Portal erreicht:
    1. Cloud Armor wendet Sicherheitsrichtlinien an, um alle anfänglichen auf dem Netzwerkprotokoll der Schicht 4 basierenden DDoS-Angriffe (Distributed Denial of Service) abzufangen. Cloud Armor untersucht die Anfrage und filtert schädlichen Traffic wie SQL-Injection (SQLi), Cross-Site-Scripting (XSS) und bekannte Bot-Signaturen.
    2. Model Armor fängt die Nutzlast ab, um Prompt-Injection-Angriffe oder böswillige Absichten zu erkennen und abzulehnen.
    3. Wenn eine dieser Schichten eine Bedrohung oder einen unbefugten Zugriff erkennt, verwirft der Load Balancer die Anfrage am Netzwerkrand.
    4. Wenn die Sicherheitsebenen keine Bedrohung erkennen und den Zugriff des Nutzers bestätigen, leitet der Load-Balancer den Traffic an den Backend-Dienst weiter.
  2. Wenn die Anfrage alle Prüfungen besteht, leitet der Load-Balancer sie an die Frontend-Plattform weiter, die die folgenden Aktionen ausführt:
    1. Extrahiert die Identität des Nutzers, z. B. die Geschäftseinheit oder Mandanten-ID des Nutzers.
    2. Verwendet IAP, um die Unternehmensidentität des Nutzers und den Gerätestatus zu überprüfen.
    3. Verwendet eine dynamisch verwaltete Registrierung, um den richtigen Zielmandanten zu identifizieren.
  3. Das Frontend-Portal leitet die Anfrage an den Mandanten weiter. Damit der Agent nicht auf andere Mandantenprojekte oder nicht autorisierte Google Cloud-Dienste zugreifen kann, verwendet die Agent Runtime eine PAB-Richtlinie, um die Ressourcen zu begrenzen, auf die der Agent zugreifen kann.
  4. Model Armor verwendet Sensitive Data Protection, um personenidentifizierbare Informationen oder eingeschränkte Inhalte zu prüfen und dynamisch zu maskieren. Model Armor führt eine zusätzliche Prüfung auf schädliche Prompt Injections in der Anfrage durch, um sicherzustellen, dass der Agent nur sichere Daten verarbeitet.

  5. Gemini führt die folgenden Aufgaben aus, um eine Antwort zu generieren:

    1. Führt einen ersten Reasoning-Durchlauf durch, um die Nutzerabsicht zu verstehen.
    2. Wenn Gemini feststellt, dass bestimmte Fakten fehlen, wird ein Plan erstellt, um die spezifischen Datentools des Mandanten aufzurufen:
      1. Um zu prüfen, ob ein Nutzer berechtigt ist, auf die Datenressourcen zuzugreifen, überprüft der Agent die Identität des Nutzers und die Bindungen seiner IAM-Rolle.
      2. Um Kontext abzurufen, führt der Agent über den MCP-Server einen Toolaufruf an den Mandantendatenspeicher aus.
      3. Der Agent erstellt eine fundierte Antwort, indem er seine interne Logik mit den neu abgerufenen, mandantenspezifischen Fakten kombiniert.

    Wenn Gemini keine zusätzlichen Fakten benötigt, wird eine Antwort generiert und an Model Armor gesendet.

  6. Model Armor prüft und maskiert dynamisch alle personenbezogenen Daten oder eingeschränkten Inhalte und sendet die bereinigte Antwort an den Mandanten-Agent. Diese letzte Überprüfung trägt dazu bei, dass keine sensiblen Daten in der Ausgabe preisgegeben werden.

  7. Die Antwort wird vom Tenant-Agent über die Frontend-Plattform und dann über den Load Balancer an den Nutzer zurückgeleitet.

Verwendete Produkte

In dieser Referenzarchitektur werden die folgenden Google Cloud und Open-Source-Produkte und ‑Tools verwendet, die aufgrund ihrer serverlosen Natur, Skalierbarkeit und Sicherheitsfunktionen ausgewählt wurden:

Anwendungsfall

Agentische KI-Systeme mit mehreren Mandanten eignen sich für Unternehmen, die generative KI-Bereitstellungen über eine einzelne Anwendung hinaus skalieren möchten. Um Anwendungsfälle zu identifizieren, für die diese Architektur geeignet ist, analysieren Sie Ihre Geschäftsprozesse und ermitteln Sie verschiedene Teams, die eigene spezialisierte KI-Agents benötigen, die auf eindeutige Tools und vertrauliche Daten zugreifen. So können Sie dezentrale Teams mit autonomen KI-Funktionen ausstatten und gleichzeitig einheitliche Sicherheits- und Compliance-Standards einhalten.

Im Folgenden finden Sie ein Beispiel für einen Anwendungsfall für ein mehrmandantenfähiges agentisches KI-System.

Unternehmensweiter Kundenservice

Sie können diese Referenzarchitektur anpassen, um KI-gestützten Kundenservice in verschiedenen Geschäftsbereichen anzubieten. Wenn Sie beispielsweise eine Elektronik- und eine Haushaltswarenabteilung unterstützen möchten, stellen Sie einen Elektronik- und einen Haushaltswaren-Agenten als zwei separate Agenten in separaten Mandantenprojekten bereit. Diese spezialisierten KI‑Agenten fungieren als intelligente Assistenten, die divisionsspezifische Supportanfragen bearbeiten, indem sie auf eindeutige technische Spezifikationen, Garantien oder Rückgabebedingungen zugreifen. Durch diese Automatisierung können sich die Kundenserviceteams auf komplexere Eskalierungen konzentrieren.

Für diesen Anwendungsfall bietet die Architektur die folgenden Vorteile:

  • Strikte Datenisolation: Das mandantenfähige Design sorgt dafür, dass das Supportwissen für jede Abteilung streng isoliert ist. Die PAB-Richtlinie bietet Schutzmaßnahmen, die dafür sorgen, dass eine Agent-Identität in einem Mandanten nicht auf Daten in einem anderen Mandanten zugreifen kann.
  • Spezialisiertes Agent-Wissen: Da sich jeder Agent in einem isolierten Mandantenprojekt befindet, ruft er den Kontext nur aus dem abteilungsspezifischen Datenspeicher ab. Durch diesen gezielten Abruf wird eine hohe Genauigkeit gewährleistet und verhindert, dass der Agent die Richtlinien verschiedener Geschäftsbereiche verwechselt.
  • Geringeres domänenübergreifendes Risiko: Die Architektur trägt dazu bei, das Risiko einer Datenpanne zwischen Geschäftsbereichen zu eliminieren. Selbst wenn die Identität eines KI-Agents kompromittiert wird, kann der Agent nicht auf unautorisierte Google Cloud Ressourcen zugreifen.

Diese Architektur ist ideal für große Einzelhandelsunternehmen und Unternehmen, die mehrere unterschiedliche Marken oder Geschäftseinheiten verwalten und eine strenge Datenhoheit benötigen.

Designalternativen

In diesem Abschnitt werden alternative Designansätze vorgestellt, die Sie für die Bereitstellung von agentischer KI mit mehreren Mandanten in Google Cloudin Betracht ziehen können.

Bereitstellung für privaten Zugriff

In der in diesem Dokument beschriebenen Architektur greifen Nutzer über das öffentliche Internet über einen zentral bereitgestellten externen Application Load Balancer auf das Mehrmandanten-agentische KI-System zu. Wenn Ihre Organisation ein System benötigt, das über das öffentliche Internet nicht zugänglich ist, können Sie die Architektur an eine der folgenden Strategien für den privaten Zugriff anpassen.

Traffic mit Edge-Sicherheitsrichtlinien blockieren

Wenn Sie nur Traffic von den bestätigten Unternehmens-IP-Adressen Ihrer Organisation zulassen möchten, können Sie Cloud Armor-Sicherheitsrichtlinien so konfigurieren, dass anderer Traffic abgelehnt wird. Diese Sicherheitsregel mit hoher Priorität blockiert alle nicht autorisierten Anfragen am Netzwerkrand. Für eine zusätzliche Sicherheitsebene können Sie IAP verwenden, um eine gültige Unternehmensidentitätssitzung zu erzwingen, und IAM-Berechtigungen für alle Nutzer konfigurieren.

Mit diesem Ansatz können Sie Cloud Armor-Edge-Sicherheitsrichtlinien nutzen, um DDoS-Schutz und WAF-Filterung, z. B. SQLi und XSS, auszulagern. Außerdem wird ein Zero-Trust-Ansatz geboten. Die Frontend-IP-Adresse des externen Application Load Balancers bleibt jedoch öffentlich und entspricht möglicherweise nicht den Compliance-Anforderungen einiger Organisationen.

Traffic über einen internen Application Load Balancer weiterleiten

Die Architektur in diesem Dokument verwendet einen externen Application Load Balancer, der robuste Cloud Armor-Richtlinien, erweiterte Sicherheitsfunktionen und eine geringere betriebliche Komplexität im Vergleich zu internen Load Balancern bietet. Die Verwendung eines externen Load-Balancers bedeutet jedoch, dass der Traffic über das öffentliche Internet geleitet wird.

Wenn Sie den gesamten Traffic im privaten Google-Netzwerk halten möchten, können Sie einen internen Application Load Balancer verwenden. Die Verwendung eines internen Application Load Balancer unterstützt IAP für die Identitätsüberprüfung. Bei einem globalen externen Application Load Balancer werden IAP-Richtlinien auf der Edge-Ebene ausgewertet. Im Gegensatz dazu werden Richtlinien bei einem internen Application Load Balancer auf der Ebene des internen Netzwerks ausgewertet. Da der Traffic nie das öffentliche Internet durchläuft, können Sie mit einem internen Application Load Balancer strenge Anforderungen an die Datenhoheit und an die Verwendung von öffentlichen IP-Adressen erfüllen.

Um eine geringe Latenz aufrechtzuerhalten und die regionalen Anforderungen an den Datenstandort zu erfüllen, stellen Sie in jeder primären Region einen regionalen internen Application Load Balancer bereit. Mit einem regionalen internen Application Load Balancer leiten Sie Traffic aus lokalen Umgebungen über Cloud Interconnect oder Cloud VPN direkt an die interne IP-Adresse des Load Balancers weiter. Ein regionaler interner Application Load Balancer unterstützt regionales Cloud Armor für internen WAF-Schutz. Im Vergleich zu einem externen Application Load Balancer unterstützen regionale interne Application Load Balancer jedoch nur eine begrenzte Anzahl von Cloud Armor-Sicherheitsrichtlinien. Außerdem fehlen erweiterte Sicherheitsfunktionen und die betriebliche Komplexität wird erhöht.

Um die Latenz weiter zu minimieren und die Hochverfügbarkeit zu gewährleisten, damit Ihre Anforderungen an die Notfallwiederherstellung erfüllt werden, können Sie einen regionenübergreifenden internen Application Load Balancer bereitstellen. Bei einem regionenübergreifenden internen Application Load Balancer verwenden Sie Cloud DNS mit Routingrichtlinien zur Standortbestimmung, um die interne URL der Anwendung in den regionenübergreifenden internen Application Load Balancer in derGoogle Cloud Region aufzulösen, die dem Nutzer am nächsten ist. Eine regionenübergreifende Konfiguration unterstützt jedoch keine Cloud Armor-Integration.

Computing-Infrastruktur

Um einen serverlosen Ansatz zu priorisieren, der eine einfachere Verwaltung und einen geringeren Betriebsaufwand bietet, wird in der Architektur in diesem Dokument Cloud Run für die Compute-Infrastruktur verwendet. Sie können auch containerisierte Anwendungen in GKE-Clustern ausführen. Google Kubernetes Engine (GKE) ist eine Engine zur Containerorchestrierung, die die Bereitstellung, Skalierung und Verwaltung von Containeranwendungen automatisiert. GKE unterstützt sowohl interne als auch externe Application Load Balancer vollständig. Informationen zur Auswahl eines Compute-Dienstes für Ihre Arbeitslasten in Google Cloudfinden Sie unter Anwendungen inGoogle Cloudhosten.

MCP-Server (Model Context Protocol)

Damit die Komponenten Ihres agentenbasierten Systems interagieren können, müssen Sie klare Kommunikationsprotokolle festlegen. MCP ist ein offenes Protokoll, das eine standardisierte Schnittstelle für den Zugriff und die Nutzung von erforderlichen Tools, Daten und anderen Diensten durch KI-Agenten bietet.

Wenn Sie Ihre Mandanten-Agents mit Ihrem Datenspeicher verbinden möchten, sollten Sie die Anforderungen Ihrer Anwendung berücksichtigen, um eine der folgenden MCP-Serverbereitstellungsoptionen auszuwählen. Berücksichtigen Sie bei der Auswahl zwischen lokalen und gemeinsam genutzten MCP-Bereitstellungen die Kompromisse zwischen Datenisolation und betrieblicher Effizienz.

  • Lokaler MCP-Server: Ein lokaler MCP-Server oder ein mandantenspezifischer MCP-Server ist ein MCP-Server, den Sie in jedem Mandantenprojekt bereitstellen und der Agenten Zugriff auf Datenspeicher und Tools bietet, die für die jeweilige Geschäftseinheit spezifisch sind.

    Im Folgenden finden Sie wichtige Funktionen und Überlegungen zu lokalen MCP-Servern:

    • Netzwerk: Ein VPC Service Controls-Perimeter auf Projektebene und eine PAB-Richtlinie bieten integrierte Sicherheit und Isolation, wodurch der Zugriff über Mandantengrenzen hinweg verhindert wird.
    • Verwaltung: Einzelne Entwickler- und Operations-Teams verwalten Mandantenprojekte unabhängig voneinander. Diese Isolation bietet Autonomie für jede Geschäftseinheit.
    • Sicherheit: Die festen IAM-Grenzen des Mandantenprojekts tragen dazu bei, laterale Risikoflächen zu minimieren. Außerdem sind keine komplexen Identitätszuordnungen erforderlich.

    Lokale MCP-Server bieten maximale Isolation und können den Zugriff auf höchst sensible oder regulierte Daten verarbeiten. Wenn Sie jedoch mehrere lokale MCP-Server bereitstellen, erhöhen Sie die Betriebslast. Wir empfehlen lokale MCP-Server für Anwendungen, die einen eingeschränkten Zugriff auf Datenspeicher erfordern, die möglicherweise vertrauliche Informationen enthalten.

  • Gemeinsam genutzter MCP-Server: Ein gemeinsam genutzter oder globaler MCP-Server ist ein MCP-Server, den Sie in einem Projekt mit gemeinsam genutzten Diensten bereitstellen. Gemeinsame MCP-Server bieten Zugriff auf Tools und Systeme, die für mehrere Mandanten üblich sind.

    Im Folgenden finden Sie wichtige Funktionen und Überlegungen zu gemeinsam genutzten MCP-Servern:

    • Netzwerk: Damit der Traffic nicht über das öffentliche Internet geleitet wird, benötigen gemeinsam genutzte MCP-Server eine private Verbindung, z. B. Private Service Connect oder VPC-Netzwerk-Peering.
    • Verwaltung: Ein zentrales Operations-Team verwaltet die Implementierung für das gesamte System. Durch diese konsolidierte Verwaltung wird die betriebliche Effizienz optimiert und die Notwendigkeit, lokale Implementierungen in mehreren Mandanten zu duplizieren, entfällt.
    • Sicherheit: Sie übertragen die Identität des Endnutzers sicher vom Agent im Mandantenprojekt an den gemeinsam genutzten MCP-Server. Damit Nutzer nur auf Daten zugreifen oder diese ändern können, für die sie eine Berechtigung haben, verwendet der freigegebene MCP-Server die weitergegebene Nutzeridentität, um eine detaillierte Zugriffssteuerung im Backend-System zu erzwingen.

    Gemeinsam genutzte MCP-Server zentralisieren die Verwaltung für gängige Tools, wodurch Duplizierungen reduziert und die betriebliche Effizienz optimiert wird. Gemeinsam genutzte MCP-Server reduzieren zwar den Verwaltungsaufwand, erfordern aber eine robuste Identitätsübertragung und Autorisierungslogik, um einen sicheren Zugriff zu gewährleisten. Wir empfehlen die Verwendung von gemeinsam genutzten MCP-Servern für die Interaktion mit gängigen Unternehmenssystemen und ‑tools wie Tools für die Spesenabrechnung, HR-Systeme (Human Resources), unternehmensweite Wissensdatenbanken oder Anwesenheitsmanager.

In dieser Architektur verwenden Sie MCP-Server, um die Verbindung zwischen Ihren Mandanten-Agents und Ihren Datenspeichern zu standardisieren. Je nach den Anforderungen Ihrer Arbeitslast können Sie auch andere Arten von Agent-Tools verwenden, um Ihre Agents mit bestimmten externen APIs und Systemen zu verbinden. Weitere Informationen zur Interaktion von Agent-Tools finden Sie unter Agent-Tools.

Designaspekte

In den folgenden Abschnitten werden Designfaktoren, Best Practices und Empfehlungen beschrieben, die Sie berücksichtigen sollten, wenn Sie diese Referenzarchitektur verwenden, um eine Topologie zu entwickeln, die Ihren spezifischen Anforderungen an Sicherheit, Zuverlässigkeit, Kosten und Leistung entspricht. Die Anleitung in diesem Abschnitt ist nicht vollständig. Je nach den Anforderungen Ihrer Arbeitslast und den von Ihnen verwendeten Produkten und Funktionen müssen möglicherweise zusätzliche Designfaktoren und Kompromisse berücksichtigt werden.

Sicherheit, Datenschutz und Compliance

In diesem Abschnitt werden Designüberlegungen und Empfehlungen beschrieben, mit denen Sie eine Topologie in Google Cloud entwerfen können, die die Sicherheits-, Datenschutz- und Compliance-Anforderungen Ihrer Arbeitslast erfüllt.

Komponente Designüberlegungen und ‑empfehlungen
Virtual Private Cloud (VPC) Mandantenisolation: Bei dieser Architektur stellen Sie jeden Mandanten in einem dedizierten Google Cloud Projekt bereit. Um eine strenge Sicherheitsgrenze zu schaffen, kombinieren Sie die Isolation auf Mandantenprojektebene mit der PAB-Richtlinie und VPC Service Controls auf Organisationsebene.
IAM Zugriffssteuerung: Um das Prinzip der geringsten Berechtigung zu implementieren, verwenden Sie ein rollenbasiertes Zugriffsmodell. Sie können beispielsweise benutzerdefinierte IAM-Rollen definieren, um sicherzustellen, dass ein Entwickler, der einen Agent in einem Mandanten erstellt, nicht auf Daten in einem anderen Mandanten zugreifen kann.
Cloud Armor

WAF-Schutz am Edge und intern: Cloud Armor bietet Sicherheits- und WAF-Schutz, um das Frontend-Portal vor DDoS-Angriffen und Web-Schwachstellen zu schützen. Ein globaler externer Application Load Balancer unterstützt die gesamte Palette der erweiterten Edge-Funktionen, z. B. Bot-Verwaltung und Google Cloud Armor Adaptive Protection.

Wenn Sie einen regionalen internen Application Load Balancer bereitstellen, funktioniert Cloud Armor mit einer eingeschränkten Gruppe von Standard-WAF-Richtlinien. Die eingeschränkten Richtlinien sind auf interne Netzwerkbegrenzungen zugeschnitten und umfassen Richtlinien wie SQLi- und XSS-Schutz. Weitere Informationen finden Sie unter Cloud Armor in andere Google-Produkte integrieren.
Agent Platform

Endpunkte für gemeinsam genutzte Modelle: Um Missbrauch zu verhindern und eine faire Nutzung von Endpunkten für gemeinsam genutzte Modelle zu gewährleisten, können Sie eine der folgenden Strategien implementieren:

  • Ratenbegrenzung auf Mandantenebene: Kontingente werden im Frontend-Portal für jeden Mandanten erzwungen, bevor Anfragen den freigegebenen Endpunkt erreichen. So erzwingen Sie die Kontingente:
    1. Extrahieren Sie die Mandantenidentität aus dem IAP-Kontext.
    2. Verfolgen Sie die Nutzung anhand vordefinierter Limits für jeden Mandanten mit einem externen Speicher wie Memorystore for Redis.
    3. Lehnen Sie Anfragen von Mandanten ab, die ihre Limits überschreiten.
  • API Gateway: Wenn Sie Kontingente pro Mandant mithilfe von API-Schlüsseln und Nutzungsplänen erzwingen möchten, implementieren Sie API Gateway vor dem freigegebenen Endpunkt.
Cloud Run

Inhaltsrendering: Um die Sicherheit des Frontend-Portals zu verbessern, sollten Sie serverseitiges Rendering (SSR) gegenüber clientseitigem Rendering (CSR) bevorzugen. Im Vergleich zu CSR bietet SSR folgende Vorteile:

  • Führt Anwendungslogik aus und verwaltet Secrets in einer kontrollierten Google Cloud Umgebung.
  • Reduziert die clientseitige Angriffsfläche und verhindert, dass sensible Daten an den nicht vertrauenswürdigen Browser des Nutzers weitergegeben werden.
  • Beschränkt die Datenoffenlegung, indem nur das erforderliche HTML an den Client gesendet wird.
  • Zentrale Ausgabecodierung zum Schutz vor Cross-Site-Scripting-Angriffen (XSS)
Security Command Center Zentrale Sicherheitsüberwachung: Mit den Tools im Security Command Center können Sie Bedrohungen erkennen und Sicherheitsrichtlinien wie die Multi-Faktor-Authentifizierung (MFA) und die Datenverschlüsselung erzwingen.

Weitere Sicherheitsempfehlungen

Zuverlässigkeit

In diesem Abschnitt werden Designüberlegungen und Empfehlungen zum Erstellen und Betreiben einer zuverlässigen Infrastruktur für Ihre Bereitstellung in Google Cloudbeschrieben.

Komponente Designüberlegungen und ‑empfehlungen
Cloud Load Balancing Globales Routing: Ein globaler externer Application Load Balancer bietet eine einzelne Anycast-IP-Adresse, die den Nutzer-Traffic automatisch zum nächstgelegenen geografischen Google Edge weiterleitet. Diese Konfiguration reduziert die Latenz durch die Secure Sockets Layer (SSL)-Terminierung am Edge. Außerdem wird so die Hochverfügbarkeit gewährleistet, wenn es in einer Region zu einem Ausfall kommt, da der Traffic intelligent an fehlerfreie regionale Backends weitergeleitet wird.
Mandant Fehlertoleranz: Um Fehler auf Agentenebene zu tolerieren oder zu beheben, stellen Sie Agents in isolierten Mandantenprojekten bereit. Diese Isolation trägt dazu bei, dass betriebliche Probleme oder Sicherheitsvorfälle auf eine einzelne Geschäftseinheit beschränkt bleiben und sich nicht auf andere Ressourcen oder Geschäftseinheiten auswirken.
Agent Platform Kapazitätsplanung: Wenn die Anzahl der Anfragen an das Modell die zugewiesene Kapazität überschreitet, gibt das Modell den Fehlercode 429 zurück. Für geschäftskritische Arbeitslasten, die einen gleichbleibend hohen Durchsatz erfordern, können Sie den Durchsatz mit bereitgestelltem Durchsatz reservieren.
Agent Runtime

Serverlose Skalierbarkeit: Agents, die in Agent Runtime bereitgestellt werden, werden unabhängig nach Bedarf skaliert. Ein plötzlicher Anstieg der Nutzung in einem Mandanten führt nicht dazu, dass die Rechenressourcen erschöpft sind oder die Verfügbarkeit eines Agents in einem anderen Mandantenprojekt beeinträchtigt wird.

Fehlerbehandlung: Zur Behandlung vorübergehender Fehler wie Ratenbeschränkungen mit dem Fehlercode 429 wird in der Logik für die Agent-Orchestrierung exponentieller Backoff verwendet. Wenn eine Kontext-Deadline überschritten wird, führt der KI-Agent ein ordnungsgemäßes Herunterfahren durch und meldet dem Nutzer den teilweisen Fortschritt. Beispielsweise kann eine Kontext-Deadline aufgrund langsamer Tool-Aufrufe, der Latenz von Drittanbieter-APIs, der Verarbeitung großer Datasets oder rechenintensiver Verarbeitung überschritten werden.

Zuverlässigkeitsgrundsätze und ‑empfehlungen speziell für KI- und ML-Arbeitslasten finden Sie im Well-Architected Framework unter KI- und ML-Perspektive: Zuverlässigkeit.

Operative Effizienz

In diesem Abschnitt werden die Faktoren beschrieben, die Sie bei der Verwendung dieser Referenzarchitektur zum Entwerfen einer Google Cloud Topologie berücksichtigen sollten, die Sie effizient betreiben können.

Komponente Designüberlegungen und ‑empfehlungen
Google Cloud Observability Zentralisiertes Monitoring: Mit Logging und Monitoring können Sie den Zustand und die Leistung der gesamten Plattform überwachen. Sie können Benachrichtigungen einrichten, um Probleme proaktiv zu erkennen und zu beheben, ohne Zugriff auf sensible Daten zu gewähren.
Alle Produkte in der Architektur Standardisierte Bereitstellungen: Wenn Sie die Agent Platform in einem standardisierten Mandantenarchitekturmuster verwenden, können Sie eine konsistente Baseline für das Onboarding neuer Mandanten festlegen. Um den Betriebsaufwand zu verringern, automatisieren Sie den Bereitstellungsprozess mit IaC-Tools (Infrastructure as Code) wie Terraform. Terraform-Code, mit dem Sie ein agentisches KI-System mit mehreren Mandanten erstellen und bereitstellen können, finden Sie im Abschnitt Bereitstellung in diesem Dokument.

Prinzipien und Empfehlungen für operative Exzellenz, die speziell für KI- und ML-Arbeitslasten gelten, finden Sie im Well-Architected Framework unter KI- und ML-Perspektive: Operative Exzellenz.

Kostenoptimierung

Dieser Abschnitt enthält Anleitungen zur Optimierung der Kosten für die Einrichtung und den Betrieb einer Google Cloud Topologie, die Sie mithilfe dieser Referenzarchitektur erstellen.

Komponente Designüberlegungen und ‑empfehlungen
Agent Platform

Tokenverbrauch: Um Kosten zu verwalten und zu verhindern, dass Ihr KI-Modell Kontextfenster überschreitet, verwenden Sie die folgenden Strategien zum Verwalten des Kontexts für das KI-Modell:

  • Kontext zusammenfassen: Anstatt eine gesamte Sitzungsunterhaltung als Kontext zu speichern, können Sie ein KI-Modell verwenden, um ältere Unterhaltungen und weniger wichtige Informationen zusammenzufassen.
  • Ausgabe kürzen: Weniger relevante oder ausführliche Teile von Tool-Ausgaben oder abgerufenen Kontext identifizieren und entfernen. Wenn Sie beispielsweise nur die Spaltennamen aus Ihren Daten benötigen, können Sie überflüssige Metadaten aus einem Datenbankschema-Abruf entfernen. Für diese Strategie ist eine benutzerdefinierte Logik erforderlich, mit der mithilfe von Heuristiken, Filtern oder einem kleinen Sprachmodell (Small Language Model, SLM) die wichtigsten Informationen extrahiert werden.
  • Maximales Token-Limit: Um Endlosschleifen zu vermeiden und die Kosten zu kontrollieren, erzwingen Sie ein maximales Token-Limit für die Sitzung.

Modellendpunkte: Um API-Kontingente und die Ressourcennutzung zu verwalten, können Sie Agent Platform-Endpunkte in einer dedizierten oder einer freigegebenen Konfiguration bereitstellen:

  • Dedizierte Endpunkte: Wenn Sie Endpunkte in jedem Mandantenprojekt bereitstellen, sorgen Sie für eine inhärente Kontingentisolierung. Die Nutzung jedes Mandanten wird auf sein eigenes Projektkontingent angerechnet, wodurch Auswirkungen zwischen Mandanten verhindert werden. Im Vergleich zu freigegebenen Endpunkten ist die Kontingentverwaltung bei dedizierten Endpunkten einfacher. Bei dedizierten Endpunkten können Sie jedoch nicht von den potenziellen Kosteneinsparungen eines gemeinsam genutzten Endpunkts profitieren.
  • Gemeinsame Endpunkte: Um die Kosten zu optimieren, können Sie einen gemeinsamen Endpunkt im zentralen Governance- und Sicherheitshub hosten. Da alle Mandanten denselben Kontingentpool nutzen, müssen Sie zur Vermeidung böswilliger Angriffe Abhilfestrategien wie die Ratenbegrenzung auf Mandantenebene oder die Kontingenterzwingung mit API Gateway implementieren. Im Vergleich zu dedizierten Endpunkten sind freigegebene Endpunkte kostengünstiger. Gemeinsam genutzte Endpunkte erfordern jedoch zusätzlichen Entwicklungsaufwand und können zu Latenz und Verwaltungsaufwand führen.

Informationen zu den Kosten auf der Agent Platform finden Sie unter Kosten für das Erstellen und Bereitstellen von KI-Modellen auf der Agent Platform.
Cloud Run Instrumentation: Mit der Instrumentation können Sie die Leistung überwachen, Probleme beheben und die Ressourcennutzung für jeden Mandanten verfolgen. Um den Mandanten für jede Anfrage zu identifizieren, extrahieren Sie die Nutzeridentität aus dem Kontext, den IAP bereitstellt. Informationen zur Instrumentierung Ihrer Anwendung finden Sie unter Instrumentierungsansatz auswählen.
Model Armor Zentrale Filterung von Prompts: Um eine strenge Governance und eine Zero-Trust-Haltung zu erzwingen, wird Model Armor in dieser Architektur auf zwei Ebenen bereitgestellt: im Routing-Hub und in jedem Mandantenprojekt. Dieser zweischichtige Ansatz trägt zwar zur Datenhoheit bei, erhöht aber die Latenz und die Betriebskosten. Um Kosten und Systemkomplexität zu reduzieren, filtern Sie alle Prompts und Antworten, indem Sie Model Armor ausschließlich im Routing-Hub bereitstellen.
Alle Produkte in der Architektur

Gemeinsame Infrastruktur: Gemeinsame Kerninfrastrukturkomponenten wie das Frontend-Portal, der zentrale Governance- und Sicherheitshub und die Agent Platform können die Kosten senken, da Sie nicht für jeden Agent einen separaten, benutzerdefinierten Stack erstellen müssen.

Plattform-Aufwand: Um die gemeinsamen Kosten des zentralen Governance- und Sicherheits-Hubs zu verteilen, verwenden Sie ein Zuweisungsmodell, das Ihren Tracking-Funktionen und Nutzungsmustern entspricht. Wir empfehlen, eines der folgenden Kostenaufteilungsmodelle zu verwenden:

  • Gleichmäßige Aufteilung: Bei diesem Modell werden die gemeinsamen Kosten gleichmäßig auf alle Mandanten verteilt. Verwenden Sie dieses Modell, wenn die Plattform ein grundlegendes Dienstprogramm ist oder wenn der Aufwand für die detaillierte Analyse die Kostenvorteile überwiegt.
  • Proportionale Zuweisung: Bei einem proportionalen Modell oder Chargeback-Prozess werden die gemeinsamen Kosten auf Grundlage des Anteils der direkten Kosten zugewiesen, die für jeden Mandanten anfallen. Verwenden Sie dieses Modell, wenn der Mandantenverbrauch stark variiert und Sie über eine robuste Telemetrie verfügen, z. B. Resource Manager-Labels und Log-Parsing, um Kosten genau zuzuordnen.
  • Feste Zuweisung: Bei einem festen oder gestuften Modell werden die gemeinsamen Kosten anhand von unternehmensdefinierten Koeffizienten zugewiesen. Verwenden Sie dieses Modell, wenn Mandanten unterschiedliche Service Level Agreements (SLAs) benötigen. Mit einer festen Modellzuweisung können Sie für Premium-Funktionen mit dedizierten Ressourcen im Vergleich zu Standardfunktionen mit gemeinsam genutzten Ressourcen feste Preise berechnen.

Weitere Informationen zur Zuweisung von Kosten für gemeinsam genutzte Dienste finden Sie unter Cloud FinOps: Zuweisung von Kosten für gemeinsam genutzte Dienste.

Zentrale Kostenverwaltung: Wenn Sie die Gesamtbetriebskosten (TCO) Ihres agentischen KI-Systems genau erfassen und Kosten einzelnen Geschäftseinheiten zuordnen möchten, verwenden Sie Labels und Cloud Billing-Exportdaten. Weitere Informationen dazu, wie Sie Labels verwenden können, um Kostenbewusstsein zu fördern, finden Sie unter Kostenbewusstsein fördern.

Mit dem Google Cloud Preisrechner können Sie die Kosten für Ihre Google Cloud -Ressourcen schätzen.

Kostenoptimierungsgrundsätze und ‑empfehlungen speziell für KI- und ML-Arbeitslasten finden Sie im Well-Architected Framework unter KI- und ML-Perspektive: Kostenoptimierung.

Bereitstellung

Verwenden Sie das Terraform-Beispiel für agentische KI mit mehreren Mandanten, das auf GitHub verfügbar ist, um diese Referenzarchitektur bereitzustellen.

Nächste Schritte

Beitragende

Autor*innen:

Weitere Beitragende: