Non mescolare tutti i dati nelle stesse tabelle
Un’applicazione di IA gestisce categorie di dati molto diverse: dati transazionali di business, documenti, embedding, conversazioni, prompt, risposte del modello, tracce tecniche e dati di audit.
Mescolarli senza una separazione chiara crea rapidamente problemi di prestazioni, governance e sicurezza. Una buona architettura inizia identificando la responsabilità di ogni spazio di archiviazione.
PostgreSQL può restare senza problemi il cuore del sistema, ma schemi e tabelle vanno organizzati in base alla loro finalità e non alla comodità di sviluppo.
Il nucleo transazionale resta relazionale
Le entità di business critiche devono continuare a essere modellate con relazioni, vincoli, chiavi esterne, indici e transazioni. L’IA non sostituisce la coerenza relazionale.
Clienti, utenti, contratti, interventi, ordini e diritti di accesso devono mantenere identificativi stabili e regole di integrità rigorose.
Questo livello è la fonte di verità. I processi di IA lo arricchiscono, ma non devono diventare l’unica rappresentazione dello stato del business.
Separare documenti, chunk ed embedding
In un’architettura RAG è utile separare il documento sorgente, le sue versioni, i chunk generati e gli embedding associati.
Ogni chunk deve conservare un riferimento al proprio documento, il numero di versione, la posizione, i metadati di business e, facoltativamente, un hash. Così si preserva la provenienza delle risposte.
Con pgvector gli embedding possono risiedere in PostgreSQL, ma occorre pianificare gli indici vettoriali, la strategia di filtraggio e la cancellazione coerente quando un documento viene aggiornato.
Tracciare le chiamate all’IA senza memorizzare tutto
Per diagnosticare un sistema di IA, i team devono poter risalire al modello utilizzato, alla latenza, allo stato, al costo approssimativo, alla versione del prompt e agli errori.
Tuttavia, memorizzare sistematicamente i prompt completi e tutti i valori trasmessi può creare una copia permanente di informazioni sensibili.
È preferibile separare i metadati tecnici dal contenuto, mascherare i campi sensibili e definire un periodo di conservazione adeguato.
Integrare multi-tenancy e sicurezza nel modello dati
In un SaaS di IA multi-azienda, ogni record di business, documento, chunk, conversazione e traccia deve essere esplicitamente legato a un’organizzazione o a un tenant.
I filtri per tenant non devono esistere solo nell’interfaccia. Vanno applicati nel backend e, quando opportuno, rafforzati con la Row Level Security di PostgreSQL.
Questa disciplina diventa ancora più importante con agenti di IA in grado di concatenare più strumenti e fonti di dati.
Una struttura di riferimento
Una struttura semplice può separare gli schemi logical_business, ai_knowledge, ai_runtime e audit. I nomi contano meno della separazione delle responsabilità.
Lo schema di business contiene le entità transazionali. Lo schema della conoscenza contiene documenti, chunk ed embedding. Runtime contiene conversazioni, esecuzioni degli agenti e risultati. Audit conserva gli eventi di tracciabilità.
Questa organizzazione rende molto più semplice controllare migrazioni, politiche di conservazione, permessi e analisi man mano che l’applicazione cresce.
