SaaS Multi-Tenant:
Segregare i dati in modo corretto

Q: Database dedicato, schema separato o riga condivisa: come si sceglie?

Si sceglie in base a chi sono i clienti, alla compliance interna ed esterna, non alle preferenze tecniche che si conoscono o che sono comode realizzare. Database dedicato quando un cliente può chiedere per contratto che i suoi dati stiano separati, o quando serve poterlo ripristinare da solo, garantirne l'isolamento e la federazione. Schema separato come compromesso frequente. Riga condivisa quando i tenant sono molti e piccoli e il costo per tenant deve restare basso (e in base ai dati). La scelta pesa soprattutto sui costi operativi, sulla manutenzione e sui backup.

Q: Come si garantisce che un tenant non veda i dati di un altro?

Non affidandosi alla disciplina di chi scrive le query. L'isolamento va imposto in un punto solo e sotto il codice applicativo, non bypassabile, con il filtro sul tenant applicato a livello di accesso ai dati e non ripetuto a mano in ogni funzione. La regola pratica: se una query scritta male può restituire i dati di un altro cliente, l'architettura è già sbagliata, indipendentemente da quanto è bravo il team.

Q: Cosa cambia quando si aggiunge l'AI a un SaaS multi-tenant?

Cambia che l'isolamento deve valere anche per il recupero dei dati. Un indice vettoriale costruito senza separazione fra tenant è un modo silenzioso di far uscire i dati di un cliente nella risposta data a un altro, e non lascia traccia in nessun log applicativo. Il filtro per tenant va applicato al recupero, prima che il contesto arrivi al modello.

Low-angle shot of a modern symmetrical concrete building, with the text "DATA SEGREGATION" and Volcanic Minds realistically engraved into the facade.

Il "Data Leakage" tra clienti SaaS è ormai all'ordine del giorno

Integrare l'intelligenza artificiale o nuove funzionalità in una piattaforma SaaS non è solo una sfida di implementazione. Senza una strategia di segregazione dei dati rigorosa e una Privacy & Security by Design reale, il rischio di un "context leak" (ovvero la fuga di informazioni tra un tenant e l'altro) diventa una certezza statistica, dipende solo se tocca a te ora o dopo. Se la struttura di base è debole, magari un multi-tenant implementato solo "sulla carta" dove la sicurezza è delegata a semplici filtri software, il disastro è solo questione di tempo.

In questo articolo analizziamo concettualmente come costruire un'architettura SaaS AI multi-tenant sicura, proteggendo la privacy senza sacrificare le performance, partendo dalle fondamenta del database fino agli Agenti AI.

Filtrare per tenant_id è un rischio

Molte aziende approcciano il multi-tenancy in modo superficiale: usano un unico database relazionale e aggiungono una colonna `tenant_id` a tutte le tabelle: dai dati anagrafici alle preferenze, fino ai dati PII (Personally Identifiable Information).

Diciamolo: questo non è vero multi-tenancy

È un database condiviso protetto da un filtro applicativo. Se il tuo codice ha una falla, se una query viene scritta male o se un attacco di SQL injection va a segno, i dati di tutti i tuoi clienti sono esposti. La sicurezza è delegata alla perfezione del codice, che sappiamo non esistere.

Il vero multi-tenancy richiede un isolamento a livello di database applicativo. Questo significa dividere i dati in istanze di database separate o database distinti. Certo, complica la gestione iniziale e la manutenzione, ma offre un livello di sicurezza inarrivabile con altri metodi.

I vantaggi del "Database-per-Tenant"

Oltre alla sicurezza granitica, questo approccio offre vantaggi operativi enormi:

- Portabilità e Manutenzione: Spostare un singolo Partner da un'architettura hardware a un'altra, o da un server a un altro per bilanciare il carico, diventa un'operazione banale e sicura.

- ROI e Costi Futuri: È un costo più alto inizialmente? Sì. Ma è un vantaggio competitivo enorme che abbassa drasticamente i costi futuri di gestione, migrazione e, soprattutto, i costi di un possibile data breach.

Questo problema si amplifica esponenzialmente quando si introduce il RAG (Retrieval-Augmented Generation). Se il tuo modello "vede" o indicizza i dati di tutti i clienti nello stesso spazio vettoriale prima di applicare un filtro logico, hai già perso. La sicurezza deve essere strutturale, non opzionale.

Tre livelli di isolamento

Quando si progettano architetture multi-tenant moderne, si applicano principi di privacy e security by design che vanno oltre il semplice codice applicativo. L'obiettivo è creare una "federazione" di dati dove ogni cliente è isolato su tre livelli:

1. Isolamento fisico dello Storage: Non ci limitiamo a filtrare le righe. Si utilizzano namespaces separati, schemi di database distinti o, nei casi più critici, istanze di database (relazionali e vettoriali) fisicamente separate. Se i dati non "vivono" nello stesso spazio logico, non possono mescolarsi per errore.

2. Orchestrazione Federata: L'applicazione (o l'Agente AI) non deve mai avere accesso diretto all'intero patrimonio informativo. Si utilizza un layer di orchestrazione che inietta il contesto specifico e le credenziali di accesso solo dopo una validazione rigorosa dell'identità del tenant.

3. Monitoraggio in tempo reale: È fondamentale monitorare non solo gli errori di sistema, ma le "anomalie di perimetro". Se una richiesta tenta di accedere a risorse (file, righe, vettori) fuori dal confine del tenant corrente, il sistema deve bloccare l'azione e generare un alert istantaneo.

Come isolare il contesto

Ecco un esempio concettuale di come implementare un wrapper sicuro che garantisca l'isolamento tra i tenant:

// Secure Multi-tenant Context Wrapper
async function executeAgentTask(tenantId: string, userPrompt: string) {
// 1. Strict validation of Tenant perimeter
const tenantContext = await securityService.getValidatedContext(tenantId);

// 2. Injection of client-specific Guardrails and Storage
const safeAgent = new AgentOrchestrator({
// Physical or logical isolation at the storage layer
storage: new TenantIsolatedStorage(tenantId),
systemPrompt: `You are an assistant for ${tenantContext.name}. Stay strictly within this context...`,
  });

// 3. Execution with active auditing and monitoring
return await safeAgent.run(userPrompt);
}

Perché il multi-tenancy robusto è un vantaggio competitivo

Creare un'architettura SaaS realmente sicura (che includa database relazionali, sistemi legacy e AI) richiede un investimento maggiore in fase di design. Ma nel mercato attuale, la sicurezza è il miglior asset commerciale.

Un SaaS che garantisce l'isolamento dei dati "by design" può attrarre i grandi player Enterprise che oggi guardano al cloud e all'AI con diffidenza. Come abbiamo visto nell'evoluzione degli [Agenti AI nel SDLC](/insights/ai-agents-software-lifecycle), il futuro appartiene a chi sa gestire la complessità senza sacrificare l'integrità.

In Volcanic Minds non ci limitiamo a "montare" moduli AI o a delegare lo sviluppo tramite vibe coding. Valutiamo ogni scelta architettonica e usiamo l'innovazione a vantaggio dei nostri Partner. Progettiamo architetture Cloud Native agnostiche dove la segregazione dei dati è un requisito non superfluo, così come lo è la scalabilità.

Le domande che restano

Come decidere l'architettura di un SaaS

Database dedicato, schema separato o riga condivisa: come si sceglie?

Come si garantisce che un tenant non veda i dati di un altro?

Cosa cambia quando si aggiunge l'AI a un SaaS multi-tenant?

Hai ancora dubbi?

Prenota un approfondimento sul multi tenant per dormire sonni tranquilli. Ne parliamo davanti a un caffè virtuale o meno.

Fissa incontro

Condividi l'articolo

Tag: Development, AI

Data pubblicazione: 23 aprile 2026

Ultima revisione: 23 aprile 2026

SaaS Multi-Tenant: Segregare i dati in modo corretto