Ogni cliente ha il suo sito, il suo hosting, i suoi strumenti: WordPress, un pannello di gestione server, WhatsApp Business, un calendario, una cartella cloud. Gestirli uno per uno, con accessi separati e procedure diverse, è il motivo per cui molti consulenti IT restano bloccati sotto una manciata di clienti. Negli ultimi mesi ho affrontato questo problema in prima persona, collegando un singolo agente AI a decine di sistemi diversi appartenenti a clienti differenti. Il risultato è un’architettura multi-tenant che permette a un solo assistente di operare su infrastrutture eterogenee senza mescolare i dati e senza moltiplicare il lavoro manuale.
In questo articolo spiego come ho impostato questa gestione multi-cliente con agenti AI, quali accorgimenti di sicurezza sono indispensabili e perché questo modello conviene a qualsiasi azienda che fornisce servizi a più clienti contemporaneamente.
Il problema: un assistente, molti clienti, zero confusione
Quando un agente AI deve occuparsi di più clienti, il rischio principale non è tecnico ma organizzativo: un comando pensato per il sito del cliente A che viene eseguito per errore sui dati del cliente B. Ho affrontato questo problema con il Model Context Protocol (MCP), lo standard che permette di collegare un modello AI a sistemi esterni tramite connettori dedicati. Invece di dare all’agente un unico accesso generico “a tutto”, ogni cliente ha il proprio connettore isolato: un server MCP per il sito WordPress, uno per l’hosting, uno per WhatsApp, uno per il calendario. L’agente vede i sistemi come strumenti separati, ciascuno con il proprio perimetro.
Isolamento dei dati: un connettore per contesto, non un accesso universale
La regola che seguo è semplice: nessun credenziale condivisa tra clienti diversi. Ogni connettore MCP viene configurato con le proprie chiavi API, la propria utenza SSH o il proprio token, e non esiste un percorso che permetta all’agente di “saltare” da un contesto cliente a un altro senza che sia esplicitamente previsto. Questo significa che:
- un connettore per il sito WordPress del cliente A non ha visibilità sui contenuti del cliente B;
- gli accessi SSH ai server sono per macchina, non per account universale, così un errore di comando resta circoscritto a un solo ambiente;
- i dati sensibili (contatti, email, messaggi) restano nel loro sistema di origine: l’agente li legge quando serve, ma non li duplica in un archivio centrale non necessario.
Questo approccio richiede più tempo in fase di configurazione rispetto a un accesso unico “master”, ma elimina la classe di errori più pericolosa: quella in cui un’azione automatizzata finisce sul sistema sbagliato.
Permessi granulari e conferma per le azioni rischiose
Non tutti i connettori hanno lo stesso livello di rischio. Leggere una lista di articoli pubblicati è un’operazione sicura da automatizzare; riavviare un server o cancellare un utente non lo è. Per questo distinguo sempre tra azioni reversibili, che l’agente può eseguire in autonomia, e azioni distruttive o difficili da annullare, per cui è sempre richiesta una conferma esplicita da parte mia. Ho approfondito questo principio, che vale per qualsiasi agente AI collegato a sistemi reali, nell’articolo su human-in-the-loop e supervisione umana. Nel contesto multi-cliente questo criterio diventa ancora più importante, perché un’operazione rischiosa eseguita per errore non danneggia solo un progetto interno, ma il sistema di un cliente pagante.
Osservabilità: sapere sempre cosa ha fatto l’agente, e dove
Con decine di connettori attivi, la domanda “cosa ha fatto l’agente ieri sul sistema del cliente X?” deve avere una risposta immediata. Ogni azione rilevante viene registrata con timestamp, sistema coinvolto e esito, in modo da poter ricostruire in pochi minuti qualsiasi intervento. Questo è lo stesso principio che descrivo in dettaglio parlando di osservabilità degli agenti AI in produzione: senza tracciamento, un agente multi-tenant è una scatola nera che nessuno può controllare né correggere in caso di problema.
Un caso concreto: l’assistenza remota su più macchine
Un esempio pratico di questo modello è la dashboard di assistenza remota che uso per intervenire sui computer dei clienti senza bisogno di password condivise o accessi manuali complicati: l’ho raccontata nell’articolo su assistenza remota sicura con ccc.cornelcaba.com. Ogni dispositivo si collega in autonomia a una rete privata, e l’agente (io compreso, quando opero manualmente) raggiunge la macchina giusta senza rischiare di agire su quella sbagliata. Lo stesso principio di isolamento per dispositivo si applica, su scala più ampia, alla gestione multi-tenant degli agenti AI: ogni “bersaglio” è identificato in modo univoco e non ambiguo.
Perché conviene: scalare senza assumere
Il vantaggio di business di questa architettura è diretto: posso seguire più clienti contemporaneamente senza che il tempo dedicato a ciascuno cresca linearmente. Le attività ripetitive — controllare lo stato di un server, pubblicare un contenuto, verificare un backup, rispondere a una richiesta ricorrente — vengono gestite dall’agente all’interno del perimetro del cliente giusto, mentre il tempo umano si concentra su decisioni, relazione e interventi che richiedono davvero giudizio. È lo stesso approccio che uso nella gestione quotidiana dell’hosting dei clienti descritta in HestiaCP: come gestisco l’hosting dei miei clienti, esteso ora a tutti i sistemi collegati, non solo al server web.
Come iniziare, senza rifare tutto da zero
Non serve costruire subito un’infrastruttura complessa. I passi che consiglio a un’azienda che vuole adottare questo modello sono:
- partire da un solo processo ripetitivo per cliente (es. pubblicazione contenuti, monitoraggio server, gestione ticket) e collegarlo con un connettore dedicato;
- definire da subito quali azioni sono automatizzabili e quali richiedono conferma umana;
- attivare un log delle azioni fin dal primo giorno, anche minimale, per non dover rincorrere la tracciabilità in un secondo momento;
- aggiungere nuovi clienti e nuovi connettori solo dopo aver validato che l’isolamento tra i primi funziona davvero.
Conclusione
La gestione multi-cliente con agenti AI non è solo una questione di efficienza: è un modo per offrire un servizio più reattivo mantenendo un controllo rigoroso su ciò che l’automazione può e non può fare. Se la tua azienda gestisce sistemi per più clienti, filiali o reparti e vuoi capire come impostare un’architettura simile in sicurezza, contattami: valutiamo insieme quali processi automatizzare per primi e come strutturare l’isolamento tra i tuoi ambienti. Trovi maggiori dettagli sui progetti che gestisco su cornelcaba.com.
