Sistema di AI agentica multi-tenant

Last reviewed 2026-06-18 UTC

Questo documento fornisce un'architettura di riferimento per aiutarti a progettare e implementare un sistema di AI agentica multi-tenant su Google Cloud. Man mano che la tua organizzazione aumenta le implementazioni dell'AI generativa, le diverse unità aziendali richiedono agenti AI specializzati che accedono a strumenti unici, seguono regole operative specifiche ed elaborano dati sensibili. Le unità aziendali potrebbero sviluppare silos di applicazioni frammentati all'interno di un'organizzazione, il che può causare elevati costi operativi, gravi lacune di governance e un rischio di esposizione dei dati. Questa architettura mostra come creare un sistema centralizzato che ti consente di fornire ai team decentralizzati funzionalità di AI autonome, mantenendo al contempo sicurezza e conformità unificate.

Il pubblico di destinazione di questo documento include architetti, sviluppatori e amministratori che creano e gestiscono sistemi multi-agente di livello enterprise nel cloud. Il documento presuppone che tu abbia una conoscenza di base dei concetti di AI, ML e LLM e dell'AI agentica.

La sezione Deployment di questo documento fornisce una strategia di implementazione per aiutarti a creare e implementare un sistema di AI agentica multi-tenant.

Architettura

Il seguente diagramma mostra un'architettura per un sistema di AI agentica multi-tenant che segue un modello hub-and-spoke. Un modello hub e spoke è una progettazione di rete in cui un ambiente centrale, noto come hub, si connette a più ambienti isolati, noti come spoke.

Un'architettura che mostra un sistema di AI agentica multi-tenant.

L'architettura è costituita dai seguenti componenti:

Componente Descrizione
Controlli di servizio VPC L'architettura utilizza i Controlli di servizio VPC per configurare un perimetro di servizio a livello di organizzazione. Questo perimetro di servizio fornisce un limite di sicurezza rigoroso e impedisce l'esfiltrazione di dati.
Hub di routing

L'hub di routing funge da punto di ingresso centrale per l'architettura e include i seguenti componenti:

  • Bilanciatore del carico delle applicazioni esterno: Funge da punto di ingresso centrale per utenti esterni o interni. Il bilanciatore del carico garantisce che solo il traffico autenticato e sicuro raggiunga il portale frontend.
  • Google Cloud Armor e Model Armor: il bilanciatore del carico integra Cloud Armor e Model Armor per ispezionare e ripulire i prompt dannosi al perimetro della rete. L'hub di routing utilizza Service Extensions sul bilanciatore del carico delle applicazioni esterno per integrare Model Armor direttamente nel flusso di richieste.
  • Identity-Aware Proxy (IAP): applica un modello Zero Trust per verificare l'identità e il contesto dell'utente prima che qualsiasi richiesta raggiunga l'applicazione.
  • Portale frontend: un'applicazione Cloud Run serverless che funge da motore di routing per indirizzare le richieste al progetto tenant isolato appropriato.
Hub centrale per la governance e la sicurezza

L'hub centrale di governance e sicurezza è un progetto Google Cloud dedicato che fornisce Identity and Access Management (IAM), logging, monitoraggio e sicurezza centralizzati per l'intera piattaforma. Questo hub include i seguenti componenti:

  • Security Command Center: un servizio che monitora l'intero sistema di AI agentica multi-tenant per rilevare i rischi per la sicurezza.
  • IAM: un framework di controllo dell'accesso che gestisce le identità e le autorizzazioni negli hub condivisi e nei progetti tenant. Questo componente fornisce una governance centralizzata per tutte le identità umane e delle macchine.
  • Cloud Logging: Un sistema che aggrega i log dagli hub condivisi e dai progetti tenant isolati nell'hub centrale di governance e sicurezza.
Progetti tenant

Ogni progetto tenant è un progetto Google Cloud dedicato per ogni unità aziendale. I singoli progetti tenant sono ambienti isolati che includono i seguenti componenti:

Flusso agentico

Il sistema multi-tenant di esempio nell'architettura precedente ha il seguente flusso:

  1. La richiesta di un utente viene instradata tramite un bilanciatore del carico delle applicazioni esterno. All'interno dell'hub di routing, vengono completati questi controlli per garantire che solo il traffico autenticato e sicuro raggiunga il portale frontend:
    1. Cloud Armor applica criteri di sicurezza per assorbire eventuali attacchi DDoS (Distributed Denial of Service) iniziali basati sul protocollo di rete di livello 4. Cloud Armor ispeziona la richiesta e filtra il traffico dannoso, come SQL injection (SQLi), cross-site scripting (XSS) e firme di bot noti.
    2. Model Armor intercetta il payload per rilevare e rifiutare attacchi di prompt injection o intenti dannosi.
    3. Se uno di questi livelli rileva una minaccia o un accesso non autorizzato, il bilanciatore del carico elimina la richiesta all'edge di rete.
    4. Se i livelli di sicurezza non rilevano minacce e convalidano l'accesso dell'utente, il bilanciatore del carico indirizza il traffico al servizio di backend.
  2. Se la richiesta supera tutti i controlli, il bilanciatore del carico la indirizza alla piattaforma frontend, che esegue le seguenti azioni:
    1. Estrae l'identità dell'utente, ad esempio l'unità aziendale o l'ID tenant dell'utente.
    2. Utilizza IAP per verificare l'identità aziendale e l'integrità del dispositivo dell'utente.
    3. Utilizza un registro gestito dinamicamente per identificare il tenant di destinazione corretto.
  3. Il portale frontend indirizza la richiesta al tenant. Per garantire che l'agente non possa accedere ad altri progetti tenant o a servizi Google Cloudnon autorizzati, Agent Runtime utilizza una policy PAB per limitare le risorse a cui l'agente può accedere.
  4. Model Armor utilizza Sensitive Data Protection per ispezionare e mascherare dinamicamente qualsiasi informazione che consente l'identificazione personale (PII) o contenuto con limitazioni. Model Armor esegue un controllo aggiuntivo per rilevare prompt injection dannosi dalla richiesta per garantire che l'agente elabori solo dati sicuri.

  5. Gemini esegue le seguenti attività per generare una risposta:

    1. Esegue un passaggio di ragionamento iniziale per comprendere l'intenzione dell'utente.
    2. Se Gemini determina di non disporre di fatti specifici, genera un piano per chiamare gli strumenti di dati specifici del tenant:
      1. Per verificare se un utente ha l'autorizzazione per accedere alle risorse di dati, l'agente verifica l'identità dell'utente e i binding dei ruoli IAM.
      2. Per recuperare il contesto, l'agente esegue una chiamata allo strumento tramite il server MCP al datastore del tenant.
      3. L'agente crea una risposta fondata combinando la sua logica interna con i fatti appena recuperati specifici per il tenant.

    Se Gemini non ha bisogno di ulteriori fatti, genera una risposta e la invia a Model Armor.

  6. Model Armor ispeziona e maschera dinamicamente qualsiasi PII o contenuto con limitazioni e invia la risposta sanificata all'agente tenant. Questa ispezione finale contribuisce a garantire che non si verifichino perdite di dati sensibili nell'output.

  7. La risposta viene reindirizzata all'utente dall'agente tenant tramite la piattaforma frontend e poi tramite il bilanciatore del carico.

Prodotti utilizzati

Questa architettura di riferimento utilizza i seguenti prodotti e strumenti open source Google Cloud , scelti per la loro natura serverless, scalabilità e funzionalità di sicurezza:

Caso d'uso

I sistemi di AI agentica multi-tenant sono adatti alle organizzazioni aziendali che vogliono scalare le implementazioni di AI generativa oltre una singola applicazione. Per identificare i casi d'uso per cui questa architettura è adatta, analizza i processi aziendali e identifica i diversi team che richiedono i propri agenti AI specializzati che accedono a strumenti unici e dati sensibili. Questo approccio ti aiuta a consentire ai team decentralizzati di usufruire di funzionalità di AI autonome, mantenendo al contempo la conformità aziendale e la sicurezza unificata.

Di seguito è riportato un esempio di caso d'uso per un sistema di AI agentica multi-tenant.

Servizio clienti a livello aziendale

Puoi adattare questa architettura di riferimento per fornire un servizio clienti basato sull'AI in diverse divisioni aziendali. Ad esempio, per supportare una divisione di elettronica e una divisione di prodotti per la casa, devi implementare un agente di elettronica e un agente di prodotti per la casa come due agenti separati in progetti tenant separati. Questi agenti AI specializzati fungono da assistenti intelligenti che gestiscono le richieste di assistenza specifiche per la divisione accedendo a specifiche tecniche, garanzie o politiche di reso uniche. Questa automazione consente ai team di assistenza umana di concentrarsi su riassegnazioni più complesse dei clienti.

Per questo caso d'uso, l'architettura offre i seguenti vantaggi:

  • Isolamento rigoroso dei dati: la progettazione multi-tenant garantisce che le conoscenze di assistenza per ogni divisione siano rigorosamente isolate. Il criterio PAB fornisce misure di salvaguardia che contribuiscono a garantire che l'identità di un agente in un tenant non possa accedere ai dati di un altro tenant.
  • Conoscenza specializzata dell'agente: poiché ogni agente si trova in un progetto tenant isolato, l'agente recupera il contesto solo dal datastore specifico della divisione. Questo recupero mirato garantisce un'elevata precisione e impedisce all'agente di confondere le norme delle diverse unità aziendali.
  • Rischio cross-domain ridotto: l'architettura contribuisce a eliminare il rischio di esposizione dei dati tra le unità aziendali. Anche se l'identità di un agente viene compromessa, l'agente non può accedere a risorse non autorizzate. Google Cloud

Questa architettura è ideale per le grandi organizzazioni e aziende di vendita al dettaglio che gestiscono più marchi o unità aziendali distinti e che richiedono una rigorosa sovranità dei dati.

Alternative di progettazione

Questa sezione presenta approcci di progettazione alternativi che puoi prendere in considerazione per il deployment dell'AI agentica multi-tenant in Google Cloud.

Deployment dell'accesso privato

Nell'architettura descritta in questo documento, gli utenti accedono al sistema di AI agentica multi-tenant su internet pubblico tramite un bilanciatore del carico delle applicazioni esterno esposto centralmente. Se la tua organizzazione richiede un sistema che rimanga inaccessibile da internet pubblico, puoi adattare l'architettura per utilizzare una delle seguenti strategie di accesso privato.

Bloccare il traffico con le policy di sicurezza perimetrale

Per consentire il traffico solo dagli indirizzi IP aziendali verificati della tua organizzazione, puoi configurare le policy di sicurezza di Cloud Armor in modo da negare qualsiasi altro traffico. Questa regola di sicurezza ad alta priorità blocca tutte le richieste non autorizzate all'edge di rete. Per un ulteriore livello di sicurezza, puoi utilizzare IAP per richiedere una sessione di identità aziendale valida e puoi configurare le autorizzazioni IAM per tutti gli utenti.

Questo approccio ti consente di sfruttare le policy di sicurezza perimetrale di Cloud Armor per eseguire l'offload della mitigazione DDoS e del filtro WAF, ad esempio SQLi e XSS, e offre un'esperienza zero-trust. Tuttavia, l'indirizzo IP frontend del bilanciatore del carico delle applicazioni esterno rimane pubblico e potrebbe non soddisfare i requisiti di conformità di alcune organizzazioni.

Instradare il traffico tramite un bilanciatore del carico delle applicazioni interno

L'architettura descritta in questo documento utilizza un bilanciatore del carico delle applicazioni esterno, che fornisce policy Cloud Armor robuste, funzionalità di sicurezza più avanzate e una complessità operativa inferiore rispetto ai bilanciatori del carico interni. Tuttavia, l'utilizzo di un bilanciatore del carico esterno significa che il traffico attraversa internet pubblico.

Per mantenere il traffico interamente all'interno della rete Google privata, puoi utilizzare un bilanciatore del carico delle applicazioni interno. L'utilizzo di un bilanciatore del carico delle applicazioni interno supporta IAP per la verifica dell'identità. Un bilanciatore del carico delle applicazioni esterno globale valuta i criteri IAP nel livello edge. Al contrario, un bilanciatore del carico delle applicazioni interno valuta i criteri a livello di rete interno. Poiché il traffico non attraversa mai la rete internet pubblica, l'utilizzo di un bilanciatore del carico delle applicazioni interno ti aiuta a soddisfare i rigorosi requisiti di sovranità dei dati e di indirizzo IP pubblico zero.

Per mantenere una bassa latenza e rispettare i requisiti di residenza dei dati regionali, deploy un bilanciatore del carico delle applicazioni interno regionale in ogni regione principale. Con un bilanciatore del carico delle applicazioni interno regionale, indirizzi il traffico dagli ambienti on-premise tramite Cloud Interconnect o Cloud VPN direttamente all'indirizzo IP interno del bilanciatore del carico. Un bilanciatore del carico delle applicazioni interno regionale supporta Cloud Armor regionale per la protezione WAF interna. Tuttavia, rispetto a un bilanciatore del carico delle applicazioni esterno, i bilanciatori del carico delle applicazioni interni regionali supportano un insieme limitato di policy di sicurezza Cloud Armor, non dispongono di funzionalità di sicurezza avanzate e aumentano la complessità operativa.

Per ridurre ulteriormente la latenza e garantire l'alta affidabilità per soddisfare i requisiti di ripristino di emergenza, puoi eseguire il deployment di un bilanciatore del carico delle applicazioni interno tra regioni. Con un bilanciatore del carico delle applicazioni interno tra regioni, utilizzi Cloud DNS con policy di routing in base alla geolocalizzazione per risolvere l'URL interno dell'applicazione nel bilanciatore del carico delle applicazioni interno tra regioni nella regioneGoogle Cloud più vicina all'utente. Tuttavia, una configurazione interregionale non supporta alcuna integrazione di Cloud Armor.

Infrastruttura di calcolo

Per dare la priorità a un approccio serverless-first che offra una gestione più semplice e un overhead operativo inferiore, l'architettura descritta in questo documento utilizza Cloud Run per la sua infrastruttura di calcolo. Puoi anche eseguire applicazioni containerizzate su cluster GKE. Google Kubernetes Engine (GKE) è un motore di orchestrazione dei container che automatizza il deployment, la scalabilità e la gestione delle applicazioni containerizzate. GKE supporta completamente i bilanciatori del carico delle applicazioni interni ed esterni. Per informazioni su come scegliere un servizio di calcolo per i tuoi carichi di lavoro su Google Cloud, consulta Hosting di applicazioni suGoogle Cloud.

Server Model Context Protocol (MCP)

Per consentire l'interazione tra i componenti del sistema agentico, devi stabilire protocolli di comunicazione chiari. MCP è un protocollo aperto che fornisce un'interfaccia standardizzata per consentire agli agenti di accedere e utilizzare gli strumenti, i dati e gli altri servizi necessari.

Per connettere gli agenti tenant al datastore, valuta i requisiti dell'applicazione per scegliere tra le seguenti opzioni di deployment del server MCP. Quando scegli tra implementazioni MCP locali e condivise, valuta i compromessi tra isolamento dei dati ed efficienza operativa.

  • Server MCP locale: un server MCP locale o specifico per il tenant è un server MCP che viene implementato in ogni progetto tenant e che fornisce agli agenti l'accesso a datastore e strumenti specifici per quella business unit.

    Di seguito sono riportate le funzionalità e le considerazioni chiave per i server MCP locali:

    • Rete: un perimetro dei Controlli di servizio VPC a livello di progetto e una policy PAB forniscono sicurezza e isolamento intrinseci, il che contribuisce a garantire l'assenza di accesso cross-tenant.
    • Gestione: i singoli team di sviluppatori e operazioni gestiscono i progetti tenant in modo indipendente. Questo isolamento fornisce autonomia a ogni unità aziendale.
    • Sicurezza: i limiti IAM fissi del progetto tenant contribuiscono a ridurre al minimo le superfici di rischio laterali e non richiedono mappature complesse delle identità.

    I server MCP locali offrono il massimo isolamento e possono gestire l'accesso ai dati altamente sensibili o regolamentati. Tuttavia, se esegui il deployment di più server MCP locali, aumenti il carico operativo. Consigliamo i server MCP locali per le applicazioni che richiedono un accesso restrittivo ai datastore che potrebbero contenere informazioni sensibili.

  • Server MCP condiviso: un server MCP condiviso, o un server MCP globale, è un server MCP che viene implementato in un progetto di servizi condivisi. I server MCP condivisi forniscono l'accesso a strumenti e sistemi comuni a più tenant.

    Di seguito sono riportate le funzionalità e le considerazioni chiave per i server MCP condivisi:

    • Rete: per garantire che il traffico non attraversi internet pubblico, i server MCP condivisi richiedono una connettività privata, ad esempio Private Service Connect o peering di rete VPC.
    • Gestione: un team operativo centralizzato gestisce l'implementazione per l'intero sistema. Questa gestione consolidata ottimizza l'efficienza operativa ed elimina il requisito di duplicare le implementazioni locali in più tenant.
    • Sicurezza: propaghi in modo sicuro l'identità dell'utente finale dall'agente nel progetto tenant al server MCP condiviso. Per garantire che gli utenti possano accedere o modificare solo i dati per cui dispongono dell'autorizzazione, il server MCP condiviso utilizza l'identità utente propagata per applicare il controllo dell'accesso dell'accesso granulare al sistema di backend.

    I server MCP condivisi centralizzano la gestione degli strumenti comuni, il che riduce la duplicazione e ottimizza l'efficienza operativa. Sebbene i server MCP condivisi riducano l'overhead di gestione, richiedono una propagazione dell'identità e una logica di autorizzazione solide per mantenere l'accesso sicuro. Consigliamo server MCP condivisi per le interazioni con sistemi e strumenti aziendali comuni, come strumenti di report delle spese, sistemi di risorse umane (RU), knowledge base a livello aziendale o gestori delle presenze.

In questa architettura, utilizzi i server MCP per standardizzare la connessione tra gli agenti tenant e i datastore. A seconda dei requisiti del tuo carico di lavoro, potresti utilizzare altri tipi di strumenti per agenti per connettere i tuoi agenti a sistemi e API esterni specifici. Per ulteriori informazioni sulle interazioni con gli strumenti dell'agente, vedi Strumenti dell'agente.

Considerazioni sulla progettazione

Le sezioni seguenti descrivono i fattori di progettazione, le best practice e i suggerimenti da prendere in considerazione quando utilizzi questa architettura di riferimento per sviluppare una topologia che soddisfi i tuoi requisiti specifici di sicurezza, affidabilità, costi e prestazioni. Le indicazioni riportate in questa sezione non sono esaustive. A seconda dei requisiti del tuo carico di lavoro e dei prodotti e delle funzionalità che utilizzi, potrebbero esserci ulteriori fattori di progettazione e compromessi da prendere in considerazione.

Sicurezza, privacy e conformità

Questa sezione descrive le considerazioni e i consigli di progettazione per progettare una topologia in Google Cloud che soddisfi i requisiti di sicurezza, privacy e conformità del tuo carico di lavoro.

Componente Considerazioni e consigli sulla progettazione
Virtual Private Cloud (VPC) Isolamento dei tenant: in questa architettura, esegui il deployment di ogni tenant in un progetto Google Cloud dedicato. Per creare un limite di sicurezza rigoroso, combina l'isolamento a livello di progetto tenant con la policy PAB e i Controlli di servizio VPC a livello di organizzazione.
IAM Controllo dell'accesso: per implementare il principio del privilegio minimo, utilizza un modello di accesso basato sulle persona. Ad esempio, puoi definire ruoli IAM personalizzati per garantire che uno sviluppatore che crea un agente in un tenant non possa accedere ai dati in un altro tenant.
Cloud Armor

Protezione WAF interna e perimetrale: Cloud Armor fornisce protezione WAF e di sicurezza per difendere il portale frontend da attacchi DDoS e vulnerabilità web. Un bilanciatore del carico delle applicazioni esterno globale supporta la suite completa di funzionalità edge avanzate, come la gestione dei bot e la protezione adattiva di Google Cloud Armor.

Se esegui il deployment di un bilanciatore del carico delle applicazioni interno regionale, Cloud Armor opera con un insieme limitato di policy WAF standard. Il set limitato di policy è personalizzato per i confini della rete interna e include policy come la protezione SQLi e XSS. Per saperne di più, consulta Integrazione di Cloud Armor con altri prodotti Google.
Agent Platform

Endpoint del modello condiviso: per prevenire abusi e garantire un utilizzo corretto degli endpoint del modello condiviso, implementa una delle seguenti strategie:

  • Limitazione della frequenza a livello di tenant: applica le quote nel portale frontend per ogni tenant prima che le richieste raggiungano l'endpoint condiviso. Applica le quote nel seguente modo:
    1. Estrai l'identità del tenant dal contesto IAP.
    2. Monitora l'utilizzo rispetto ai limiti predefiniti per ogni tenant utilizzando un archivio esterno come Memorystore for Redis.
    3. Rifiuta le richieste dei tenant che superano i limiti.
  • API Gateway: per applicare quote per tenant utilizzando chiavi API e piani di utilizzo, implementa API Gateway prima dell'endpoint condiviso.
Cloud Run

Rendering dei contenuti: per migliorare la postura di sicurezza del portale frontend, dai la priorità al rendering lato server (SSR) rispetto al rendering lato client (CSR). Rispetto al CSR, l'SSR offre i seguenti vantaggi:

  • Esegue la logica dell'applicazione e gestisce i secret all'interno di un ambiente Google Cloud controllato.
  • Riduce la superficie di attacco lato client e impedisce la perdita di dati sensibili nel browser non attendibile dell'utente.
  • Limita l'esposizione dei dati inviando al client solo l'HTML necessario.
  • Fornisce la codifica centralizzata dell'output per difendersi dagli attacchi cross-site scripting (XSS).
Security Command Center Monitoraggio centralizzato della sicurezza: per monitorare le minacce e applicare le norme di sicurezza, come l'autenticazione a più fattori (MFA) e la crittografia dei dati, utilizza gli strumenti di Security Command Center.

Altri consigli per la sicurezza

Affidabilità

Questa sezione descrive considerazioni e consigli di progettazione per creare e gestire un'infrastruttura affidabile per il tuo deployment in Google Cloud.

Componente Considerazioni e consigli sulla progettazione
Cloud Load Balancing Routing globale: un bilanciatore del carico delle applicazioni esterno globale fornisce un singolo indirizzo IP anycast che instrada automaticamente il traffico utente al Google Edge geografico più vicino. Questa configurazione riduce la latenza tramite la terminazione Secure Sockets Layer (SSL) perimetrale. Garantisce inoltre l'alta affidabilità se una regione subisce un'interruzione, perché reindirizza in modo intelligente il traffico ai backend regionali integri.
Tenant Tolleranza agli errori: per tollerare o gestire gli errori a livello di agente, deploya gli agenti in progetti tenant isolati. Questo isolamento contribuisce a garantire che i problemi operativi o gli incidenti di sicurezza rimangano all'interno di una singola unità aziendale e non influiscano su altre risorse o unità aziendali.
Agent Platform Pianificazione della capacità: se il numero di richieste al modello supera la capacità allocata, il modello restituisce il codice di errore 429. Per i workload business critical che richiedono un throughput costantemente elevato, puoi riservare il throughput utilizzando il throughput riservato.
Agent Runtime

Scalabilità serverless: gli agenti di cui è stato eseguito il deployment su Agent Runtime vengono scalati in modo indipendente in base alla domanda. Un picco improvviso di utilizzo in un tenant non esaurisce le risorse di calcolo né influisce sulla disponibilità di un agente in un altro progetto tenant.

Gestione degli errori: per gestire gli errori temporanei come i limiti di frequenza del codice di errore 429, la logica di orchestrazione degli agenti utilizza il backoff esponenziale. Se viene superata una scadenza del contesto, l'agente esegue un arresto controllato e comunica all'utente l'avanzamento parziale. Ad esempio, una scadenza del contesto può essere superata a causa di chiamate lente agli strumenti, latenza dell'API di terze parti, elaborazione di set di dati di grandi dimensioni o elaborazione a elevato utilizzo di risorse di calcolo.

Per principi e consigli di affidabilità specifici per i workload AI e ML, consulta Prospettiva AI e ML: affidabilità nel framework Well-Architected.

Efficienza operativa

Questa sezione descrive i fattori da considerare quando utilizzi questa architettura di riferimento per progettare una topologia Google Cloud che puoi gestire in modo efficiente.

Componente Considerazioni e consigli sulla progettazione
Google Cloud Observability Monitoraggio centralizzato: Logging e Monitoring ti consentono di monitorare l'integrità e le prestazioni dell'intera piattaforma. Puoi configurare avvisi per rilevare e risolvere in modo proattivo i problemi senza consentire l'accesso ai dati sensibili.
Tutti i prodotti nell'architettura Deployment standardizzati: l'utilizzo di Agent Platform all'interno di un pattern di architettura tenant standardizzato consente di stabilire una base di riferimento coerente quando onboard nuovi tenant. Per ridurre il carico operativo, automatizza il deployment utilizzando strumenti Infrastructure as Code (IaC) come Terraform. Per il codice Terraform che puoi utilizzare per creare e implementare un sistema di AI agentica multi-tenant, consulta la sezione Deployment di questo documento.

Per principi e consigli di eccellenza operativa specifici per i workload di AI e ML, consulta Prospettiva AI e ML: eccellenza operativa nel framework Well-Architected.

Ottimizzazione dei costi

Questa sezione fornisce indicazioni per ottimizzare il costo di configurazione e gestione di una topologia Google Cloud che crei utilizzando questa architettura di riferimento.

Componente Considerazioni e consigli sulla progettazione
Agent Platform

Consumo di token: per gestire i costi ed evitare che il modello di AI superi le finestre contestuali, utilizza le seguenti strategie per gestire il contesto del modello di AI:

  • Riepilogo del contesto: anziché salvare l'intera conversazione di una sessione come contesto, utilizza un modello di AI per riepilogare le conversazioni meno recenti e le informazioni meno importanti.
  • Elimina output: Identifica e rimuovi le parti meno pertinenti o più verbose degli output degli strumenti o del contesto recuperato. Ad esempio, se hai bisogno solo dei nomi delle colonne dei tuoi dati, puoi rimuovere i metadati in eccesso da un recupero dello schema del database. Questa strategia richiede una logica personalizzata che utilizza euristiche, filtri o un modello linguistico di piccole dimensioni (SLM) per estrarre le informazioni più importanti.
  • Limite massimo di token: per evitare loop infiniti e controllare i costi, applica un limite massimo di token per sessione.

Endpoint del modello: per gestire le quote API e l'utilizzo delle risorse, puoi eseguire il deployment degli endpoint di Agent Platform in una configurazione dedicata o condivisa:

  • Endpoint dedicati: quando esegui il deployment degli endpoint all'interno di ogni progetto tenant, fornisci un isolamento della quota intrinseco. L'utilizzo di ogni tenant viene conteggiato in base alle quote del proprio progetto, il che impedisce l'impatto tra tenant. Rispetto agli endpoint condivisi, gli endpoint dedicati offrono una gestione delle quote più semplice. Tuttavia, gli endpoint dedicati ti impediscono di sfruttare i potenziali risparmi sui costi di un endpoint condiviso.
  • Endpoint condivisi: per ottimizzare i costi, puoi ospitare un endpoint condiviso nell'hub centrale di governance e sicurezza. Poiché tutti i tenant condividono lo stesso pool di quote, per prevenire attacchi dannosi, devi implementare strategie di mitigazione come limitazione di frequenza a livello di tenant o l'applicazione delle quote con API Gateway. Rispetto agli endpoint dedicati, gli endpoint condivisi sono più convenienti. Tuttavia, gli endpoint condivisi richiedono un ulteriore impegno tecnico e possono introdurre latenza e overhead di gestione.

Per informazioni sui costi su Agent Platform, consulta Costo di creazione e deployment di modelli di AI in Agent Platform.
Cloud Run Strumentazione: la strumentazione ti consente di monitorare le prestazioni, risolvere i problemi e monitorare l'utilizzo delle risorse per ogni tenant. Per identificare il tenant per ogni richiesta, estrai l'identità dell'utente dal contesto fornito da IAP. Per informazioni su come instrumentare l'applicazione, vedi Scegliere un approccio di instrumentazione.
Model Armor Filtro dei prompt centralizzato: per applicare una governance rigorosa e una postura Zero Trust, questa architettura implementa Model Armor in due livelli: nell'hub di routing e all'interno di ogni progetto tenant. Sebbene questo approccio a due livelli contribuisca a garantire la sovranità dei dati, aumenta la latenza e i costi operativi. Per ridurre i costi e la complessità del sistema, filtra tutti i prompt e le risposte eseguendo il deployment di Model Armor esclusivamente nell'hub di routing.
Tutti i prodotti nell'architettura

Infrastruttura condivisa: i componenti dell'infrastruttura di base condivisa, come il portale frontend, l'hub centrale di governance e sicurezza e Agent Platform, possono ridurre i costi rispetto alla creazione di uno stack personalizzato separato per ogni agente.

Overhead della piattaforma: per distribuire i costi condivisi dell'hub centrale di governance e sicurezza, utilizza un modello di allocazione adatto alle tue funzionalità di monitoraggio e ai tuoi pattern di utilizzo. Ti consigliamo di utilizzare uno dei seguenti modelli di allocazione dei costi:

  • Allocazione con divisione equa: un modello di divisione equa distribuisce i costi condivisi in parti uguali tra tutti gli inquilini. Utilizza questo modello quando la piattaforma è un'utilità di base o quando l'overhead del monitoraggio granulare supera i vantaggi in termini di costi.
  • Allocazione proporzionale: un modello proporzionale, o processo di storno di addebito, alloca i costi condivisi in base alla proporzione dei costi diretti sostenuti da ciascun tenant. Utilizza questo modello quando il consumo del tenant varia drasticamente e disponi di una telemetria solida, ad esempio etichette Resource Manager e analisi dei log, per attribuire i costi in modo accurato.
  • Allocazione fissa: un modello fisso o a livelli alloca i costi condivisi in base a coefficienti definiti dall'attività. Utilizza questo modello quando i tenant richiedono accordi sul livello del servizio (SLA) diversi. Un'allocazione del modello fissa ti consente di addebitare tariffe fisse per le funzionalità dedicate premium rispetto a quelle condivise standard.

Per ulteriori informazioni su come allocare i costi dei servizi condivisi, consulta Cloud FinOps: Shared services cost allocation.

Gestione centralizzata dei costi: per monitorare con precisione il costo totale di proprietà (TCO) del tuo sistema di AI agentica e attribuire i costi alle singole unità aziendali, utilizza le etichette e i dati di esportazione di fatturazione Cloud. Per saperne di più su come utilizzare le etichette per la consapevolezza dei costi, consulta Promuovere una cultura della consapevolezza dei costi.

Per stimare il costo delle tue risorse Google Cloud , utilizza il Google Cloud Calcolatore prezzi.

Per principi e consigli di ottimizzazione dei costi specifici per i workload AI e ML, consulta Prospettiva AI e ML: ottimizzazione dei costi nel framework Well-Architected.

Deployment

Per eseguire il deployment di questa architettura di riferimento, utilizza l'esempio multi-tenant AI agentica Terraform disponibile su GitHub.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: