Questo articolo è il seguito naturale di Da N8N a Google Cloud Se non l’hai letto, fallo prima: spiega perché abbiamo abbandonato N8N e costruito la nostra infrastruttura RAG su Google Cloud Platform.
Questo articolo racconta cosa succede dopo — quando un chatbot smette di essere un esperimento e diventa qualcosa che vendi ai tuoi clienti.
Da uno a tre: il momento in cui capisci di avere un prodotto
Quando abbiamo lanciato Marvin — il nostro assistente interno per Hosting4Agency — pensavamo di aver risolto un problema nostro. Helpdesk di livello 1, risposte sulle FAQ, supporto prevendita. Funzionava, e funzionava bene.
Poi ci hanno chiesto: “ma potreste farlo anche per noi?”
La prima richiesta è arrivata da The Red House Company, gestori di appartamenti di lusso a Venezia. Volevano un chatbot che aiutasse gli ospiti a trovare casa, verificare disponibilità e prenotare — tutto in chat, senza moduli, senza telefonate. Qualcosa di più di un semplice FAQ bot: un agente che conosce gli appartamenti, capisce le date, chiama le API del gestionale e crea ordini reali su WooCommerce.
La seconda da “Una famosa RIR di cui facciamo parte”, una associazione di imprese culturali e creative. Volevamo aiutare i soci a navigare tra bandi europei, progetti attivi e servizi — un assistente che conoscesse il sito meglio di qualsiasi operatore.
In poche settimane avevamo tre chatbot in produzione. E ci siamo trovati a rispondere a una domanda che non avevamo ancora affrontato davvero: come si gestisce una piattaforma multi-cliente basata su AI?
L’architettura che scala: un progetto GCP, tre agenti separati
La scelta fondamentale è stata tenere tutto su un unico progetto Google Cloud Platform (elan42-stage), con risorse separate per ogni cliente. Non tre infrastrutture diverse: una sola, con isolamento logico e billing separata.
Ogni chatbot ha:
- Un bucket dedicato su Cloud Storage (elan42-stage-rag-marvin, elan42-stage-rag-redhouse, elan42-stage-rag-rir) — il corpus di documenti da cui il bot attinge per rispondere
- Un datastore su Vertex AI Agent Builder (ex Gemini Agent Builder) — il motore di ricerca semantica che indicizza i documenti e risponde alle query RAG
- Un agente su Dialogflow CX con il proprio Playbook, la propria persona e i propri tool
- Una pagina HTML ospitata su un bucket Cloud Storage pubblico, embedded via iframe nei siti dei clienti
Semplice sulla carta, molto meno senza un’architettura chiara.
La Knowledge Base: ogni bot sa solo quello che deve sapere
Uno dei problemi classici dei chatbot aziendali è la contaminazione delle risposte: il bot mischia informazioni di contesti diversi, inventa dettagli, cita cose che non esistono.
La nostra soluzione è strutturale: ogni agente ha accesso solo al proprio datastore su Vertex AI Agent Builder. Marvin non sa nulla degli appartamenti di Red House. Tobia non sa nulla dei bandi europei della RIR.
Oltre al corpus RAG (documenti scritti dal corpus del sito), ogni progetto ha una Knowledge Base LLM-wiki — una serie di file Markdown strutturati scritti appositamente per il modello, con informazioni che il sito non esprime in modo esplicito ma che il bot deve conoscere. Niente prezzi (regola editoriale ferrea), niente dati personali — solo conoscenza pubblica, curata.
Il corpus viene caricato su Cloud Storage come text/plain. Dettaglio tecnico non ovvio: Vertex AI Agent Builder rifiuta i file Markdown perché li interpreta come text/markdown. I nostri script rinominano automaticamente i .md in .txt all’upload. Piccola cosa, ore di debug la prima volta.
Il “Tastone Rosso” per ogni cliente
Uno dei pezzi di cui andiamo più fieri è la semplicità operativa. Quando un cliente aggiorna il proprio sito, o quando vogliamo arricchire la knowledge base, basta un comando:
python3 projects/redhouse/sync_redhouse.py
Questo script — il nostro “Tastone Rosso” — svuota il bucket Cloud Storage del cliente, ricarica tutti i file aggiornati e lancia l’import su Vertex AI Agent Builder con riconciliazione completa (FULL). In pochi minuti il bot sa già le cose nuove.
Stessa logica per tutti e tre i bot. Stesso pattern, parametri diversi.
Passwordless by default: niente file .json in giro
Fino a qualche settimana fa, ogni sviluppatore che voleva eseguire gli script doveva avere un file service-account.json sul proprio computer. File che viaggiano via email, finiscono in cartelle sbagliate, rimangono nei backup.
Abbiamo eliminato completamente questo pattern. Tutti gli script usano ora Application Default Credentials (ADC) di Google Cloud:
gcloud auth application-default login
Un solo comando, il browser si apre, ti autentichi con il tuo account ELAN42, e hai accesso a tutto ciò per cui sei autorizzato. Nessun file. Nessuna password condivisa. Nessun rischio.
I segreti sensibili — come il bearer token che autentica Dialogflow CX verso il plugin WordPress di Red House — vivono in Secret Manager su Google Cloud Platform, accessibili solo agli account del gruppo elan42-stage@elan42.com.
L’accesso è governato da Cloud IAM: ogni collaboratore ha i permessi minimi necessari, assegnati al gruppo, non al singolo. Aggiungi un nuovo sviluppatore al gruppo Google Workspace e in cinque minuti può lavorare sul progetto, senza che tu gli mandi nulla.
Tobia prenota davvero: l’integrazione con WordPress e WooCommerce
Il chatbot di Red House non è solo un FAQ bot. Tobia — questo il suo nome, il leone di San Marco della Serenissima — può fare cose concrete:
- Cercare appartamenti disponibili per date e numero di ospiti, interrogando in tempo reale Krossbooking (il PMS di Red House)
- Presentare le opzioni con prezzi e link diretti
- Raccogliere i dati dell’ospite in chat
- Creare una prenotazione reale su WooCommerce e restituire un link di pagamento sicuro
- Tenere la casa “in opzione” per 10 minuti mentre l’ospite paga
Tutto questo avviene tramite il nostro plugin WordPress ELAN42-chatbot, che espone un set di endpoint REST autenticati. Dialogflow CX chiama questi endpoint tramite un tool OpenAPI, con autenticazione bearer token conservata su Secret Manager.
Il risultato: un cliente che scrive “ho una casa vicino alla Biennale per 2 persone la prima settimana di settembre?” riceve in chat disponibilità reale, prezzi reali e un link per pagare. Senza moduli. Senza aspettare.
Billing separata per cliente: i label di Cloud Storage
Quando gestisci chatbot per clienti diversi su un unico progetto GCP, la billing è un problema reale. Come sai quanto sta costando il bot di Red House vs quello della RIR?
La risposta di Google Cloud Platform sono i resource label: coppie chiave-valore che puoi applicare a ogni risorsa (bucket, datastore, agente). Noi usiamo cliente=redhouse e cliente=rir su ogni risorsa.
Nel Cloud Billing puoi poi filtrare i costi per label e avere un report preciso per cliente. Non perfetto — alcune risorse condivise non si labelizzano facilmente — ma sufficiente per un foglio di rendicontazione mensile.
La Gen2: Conversational Messenger e l’embed via Cloud Storage
Con la migrazione al nuovo progetto GCP abbiamo anche aggiornato il pattern di embed.
Il vecchio sistema usava Dialogflow Messenger direttamente nei siti, con project-id e agent-id hardcoded nell’HTML. Funzionava, ma era fragile: ogni migrazione richiedeva di mettere mano al codice del sito cliente.
Il nuovo pattern (che chiamiamo Gen2) usa:
- Una pagina HTML statica ospitata su un bucket Cloud Storage pubblico (elan42-stage-marvin-web, elan42-stage-tobia-web, elan42-stage-rir-web)
- Un Conversational Messenger abilitato sull’agente Dialogflow CX (API unauthenticated)
- Un semplice <iframe> nel sito cliente che punta alla pagina GCS
Il vantaggio: se dobbiamo migrare un agente o cambiare progetto GCP, aggiorniamo la pagina nel bucket e l’iframe del cliente non cambia. Zero interventi sui siti in produzione.
Il prossimo passo: Google Agent Development Kit
Dobbiamo essere onesti con voi (e con noi stessi): l’architettura attuale, basata su Dialogflow CX Generative Playbooks, è la generazione precedente dello stack Google.
Google ha rilasciato 3 settimane fa l’Agent Development Kit (ADK) — un framework Python open source per costruire agenti AI multi-step, con orchestrazione nativa, tool use strutturato e integrazione profonda con Vertex AI e Gemini. È più flessibile, più potente, e probabilmente dove tutto il mondo sta andando.
I nostri Playbook funzionano bene oggi. Ma abbiamo già pianificato la migrazione. ADK permette di definire il comportamento dell’agente in codice Python invece che in un’interfaccia grafica — il che significa versionamento, testing, CI/CD. Tutto quello che uno sviluppatore si aspetta.
Ma … ne parleremo in un prossimo articolo! 🤞🏼
Cosa abbiamo imparato
Costruire una piattaforma AI multi-cliente su Google Cloud Platform ci ha insegnato alcune cose che non si trovano facilmente nella documentazione:
- Il corpus è il prodotto: la qualità delle risposte dipende quasi interamente dalla qualità dei documenti. L’infrastruttura è un mezzo, non un fine.
- Isola tutto: bucket, datastore, agente, web bucket separati per ogni cliente. Sembra ridondante, è essenziale.
- Passwordless from day one: Application Default Credentials e Secret Manager non sono “best practice da grande azienda” — sono il modo corretto di lavorare anche in un team piccolo.
- Il bot deve fare cose: un chatbot che risponde solo a domande è utile. Un chatbot che verifica disponibilità, crea prenotazioni e restituisce link di pagamento è un prodotto.
Iscriviti alla Newsletter!
Con CIAO, la rubrica AI di ELAN42, continueremo a raccontare cosa sta succedendo nel mondo dell’intelligenza artificiale attraverso casi reali, tecnologie e strategie che utilizziamo nei nostri progetti.
Se la tua azienda vorrebbe un chatbot AI per dare assistenza post o pre vendita ai tuoi clienti, forse è arrivato il momento di scriverci.
Contattaci a info@elan42.com per scoprire come la nostra digital agency ELAN42 può portare i tuoi assistenti AI verso l’eccellenza
Contattaci
"*" indica i campi obbligatori
