Posso collegare un'AI al gestionale senza rischi per i dati?

Sì, se l'accesso passa da una replica in sola lettura con viste che espongono solo i campi necessari, e se ogni esecuzione viene registrata. Il modello non deve avere credenziali sulla produzione né poter scrivere.

Che differenza c'è tra RAG e text-to-SQL?

Il RAG cerca dentro documenti non strutturati (contratti, manuali, procedure) e risponde citando i passaggi trovati. Il text-to-SQL traduce una domanda in un'interrogazione al database per ottenere numeri. Servono a cose diverse e nei progetti seri convivono.

Quanto costa collegare il database aziendale all'AI?

Per una PMI, 1.800–4.500 euro per la parte di reportistica automatica, 2–4 settimane di lavoro. Se serve un semantic layer articolato e più fonti, si sale verso 6.000. La voce che pesa di più non è la tecnologia, è definire le metriche.

I dati escono dall'azienda?

Solo i campi necessari a produrre la risposta, e solo verso il fornitore del modello, con contratto che esclude l'addestramento e con elaborazione in UE se richiesta. I dati restano nel tuo database: quello che viaggia è una porzione minima e tracciata.

Serve un data warehouse?

Per una PMI quasi mai al primo progetto. Una replica in sola lettura ben strutturata basta fino a volumi importanti. Il data warehouse ha senso quando le fonti diventano molte e i calcoli pesanti.

Quanto è affidabile la risposta di un sistema del genere?

Su domande coperte dal semantic layer, con le metriche definite, l'accuratezza attesa è sopra il 95% e va verificata con un golden set prima del rilascio. Su domande fuori perimetro il sistema deve dire che non sa: è una scelta di progettazione, non un limite.

Database aziendale e AI: come far interrogare i tuoi dati senza esporli

Risposta diretta Per far interrogare i dati aziendali da un'AI in sicurezza si usa una replica in sola lettura del database, sopra la quale si definisce un semantic layer (le metriche aziendali scritte una volta, in modo univoco) e si concede al modello solo un insieme controllato di query o di strumenti, con log di ogni esecuzione. Il modello non riceve mai accesso diretto alla produzione né l'intero contenuto delle tabelle. Costo tipico per una PMI: 1.800–4.500 euro, 2–4 settimane.

Il metodo che quasi tutti provano per primo, e perché non regge

Esporti in CSV, carichi su un assistente pubblico, chiedi. Funziona, la prima volta. Poi cominciano i problemi.

I dati sono usciti dal perimetro aziendale, spesso senza che nessuno abbia valutato se potevano uscire. La foto è ferma a quel momento: domani serve un altro export. Nessuno può risalire a come è stato calcolato quel numero. E se nel file c'erano anagrafiche clienti, hai fatto un trattamento di dati personali senza base giuridica documentata.

Il punto non è che sia vietato. È che non scala e non è verificabile. Un sistema aziendale ha bisogno di tre cose che il CSV non dà: aggiornamento automatico, ripetibilità del calcolo, tracciabilità.

Le quattro architetture di accesso ai dati

Architettura	Cosa fa	Precisione	Rischio	Costo
1. Query parametriche predefinite	Un insieme chiuso di interrogazioni scritte da noi, il modello sceglie quale usare e con quali parametri	Molto alta	Molto basso	1.500 – 3.000 €
2. Semantic layer + text-to-SQL vincolato	Il modello genera SQL, ma solo su viste certificate e metriche definite	Alta	Basso	3.000 – 6.000 €
3. RAG su documenti	Il modello cerca dentro contratti, manuali, procedure e risponde citando la fonte	Media-alta	Basso	2.500 – 6.000 €
4. Agente con strumenti (MCP)	Il modello può chiamare più funzioni, incrociare fonti, decidere i passaggi	Variabile	Medio	6.000 – 15.000 €

Per la stragrande maggioranza delle PMI la risposta giusta è la 1 o la 2. La 4 è affascinante e ha il costo di verifica più alto: prima di darla in mano a chi decide sui margini, deve essere misurata.

Perché il text-to-SQL "libero" fallisce nei database aziendali italiani

L'idea è seducente: il modello legge lo schema, traduce la domanda in SQL, risponde. Sui database di esempio funziona benissimo. Sul gestionale di un'azienda vera, meno.

I motivi sono sempre gli stessi, e nessuno riguarda l'intelligenza del modello.

I nomi non dicono niente. Tabelle chiamate TB_ANAG01, colonne FL_ATT, IMP_TOT_2, DTA_RIF. Il modello indovina. A volte indovina male e non te lo dice.

Le regole non sono nello schema. L'insieme dei clienti attivi esclude sei codici di test e due sedi dismesse, cosa che sa solo l'amministrazione. In nessun punto del database c'è scritto.

Le metriche sono ambigue. "Fatturato" al netto degli storni? Con o senza trasporto? Per data documento o per data competenza? Tre risposte diverse, tutte formalmente corrette, e chi legge non sa quale ha ricevuto.

Gli storici sporcano. Import vecchi, duplicati di anagrafica, unità di misura miste. Un JOIN innocente produce righe moltiplicate e un fatturato gonfiato del 30%.

Il rimedio non è un modello più grande. È scrivere le definizioni una volta sola, in un posto solo.

Il semantic layer, spiegato senza gergo

È il glossario eseguibile dell'azienda. Ogni metrica che conta viene definita una volta, concordata con chi la usa, e da lì in poi tutti (persone e modelli) usano quella.

Esempio di come si scrive una definizione:

metrica: margine_lordo_riga
formula: (prezzo_netto - costo_ultimo_acquisto) * quantita
esclude: righe con causale OMAGGIO, RESO, TEST
periodo: data_documento
note: il costo è quello dell'ultimo acquisto, non il medio ponderato.
      Deciso con l'amministrazione il 12/03/2026.

Cinque righe. Ma da quel momento "margine" significa una cosa sola in tutta l'azienda, e la risposta del sistema è verificabile da chiunque. Nella nostra esperienza questa è la parte del progetto che genera più valore e che nessuno mette a preventivo: costringe l'azienda a mettersi d'accordo su cosa misura.

Il livello minimo per partire sono 8–15 metriche. Non servono cento.

L'architettura di riferimento che usiamo

Gestionale/ERP (produzione)
        │  sincronizzazione pianificata, sola lettura
        ▼
Replica read-only (PostgreSQL gestito, UE)
        │
        ▼
Viste certificate + semantic layer
        │  solo colonne necessarie, dati sensibili esclusi o pseudonimizzati
        ▼
Strato di accesso controllato (whitelist di query / tool MCP)
        │  timeout, limite righe, nessuna scrittura
        ▼
Modello AI  →  output (report, alert, risposta)
        │
        ▼
Log completo: chi, quando, quale query, quali righe, quale risposta

Cinque proprietà che questa struttura garantisce:

La produzione non viene mai toccata. Nessuna query pesante può rallentare la fatturazione.
Il modello non può scrivere. Fisicamente, non per gentilezza.
Esce solo il dato che serve alla risposta. Se una colonna non è necessaria, non è nella vista.
Ogni risposta è ricostruibile: dal log risali alla query e ai dati usati.
Se domani cambi modello o fornitore, cambia solo l'ultimo pezzo.

Sicurezza e conformità: cosa pretendere per iscritto

Utenza database dedicata in sola lettura, con accesso limitato alle viste certificate.
Minimizzazione: al modello va il dato aggregato quando basta l'aggregato. Un report sui margini non ha bisogno del nome del cliente, tanto meno della sua partita IVA.
Pseudonimizzazione dove serve la granularità ma non l'identità.
Residenza dei dati e opzione di elaborazione in UE dichiarata nel contratto.
Nessun uso dei tuoi dati per addestrare modelli, scritto, non promesso a voce.
Retention zero o minima lato fornitore del modello, con la policy allegata al contratto.
DPA e catena delle nomine completa: tu titolare, noi responsabili, i sub-responsabili elencati.
Audit trail conservato per un periodo definito, e definito da voi.

Sul fronte AI Act: dal 2 agosto 2026 si applicano gli obblighi di trasparenza (art. 50 del Regolamento UE 2024/1689) e il regime sanzionatorio; gli obblighi sui sistemi ad alto rischio sono stati rinviati dal Digital Omnibus al 2 dicembre 2027 e al 2 agosto 2028. L'obbligo di alfabetizzazione del personale è in vigore dal 2 febbraio 2025. Un sistema di reportistica interno normalmente non è ad alto rischio, ma va comunque mappato, documentato e le persone che lo usano vanno formate. Approfondimento nella nostra guida all'AI Act.

Il tuo database è pronto? Nell'audit verifichiamo qualità del dato, accessi disponibili e quali metriche sono definibili subito. Ne esce una lista di cosa si può automatizzare oggi e cosa va sistemato prima. Trenta minuti, gratuiti.

Come si misura se il sistema risponde bene

Senza misura non c'è fiducia, e senza fiducia il sistema non viene usato. Il metodo è semplice e va concordato prima del rilascio.

Golden set. 30–50 domande reali, quelle che l'azienda fa davvero, con la risposta corretta calcolata a mano una volta.
Accuratezza. Si esegue il set e si conta quante risposte coincidono. Sotto il 95% su domande standard, non si va in produzione.
Test di regressione. Lo stesso set si riesegue a ogni modifica: nuovo modello, nuova vista, nuova metrica.
Comportamento sull'incerto. Alla domanda ambigua il sistema deve chiedere chiarimenti o dire che non sa. Un sistema che inventa un numero plausibile è peggio di uno che tace.
Uso reale. Dopo un mese: quante volte è stato interrogato, da chi, quali domande hanno fallito.

Tre casi che si ripagano quasi sempre

Report settimanale con commento. Vendite, margini, scaduto, invenduto. Numeri più il testo che li spiega, in casella lunedì alle 7. Nel caso del distributore food service siamo passati da 2–3 giorni di lavoro a 15 minuti di controllo.

Alert su soglia. Margine sotto la soglia su un prodotto, cliente che scende del 40% rispetto alla media, scorta sotto il minimo con lead time lungo. Il valore non è il calcolo, è che arriva senza che nessuno debba ricordarsene.

Domanda in linguaggio naturale per chi sta fuori. Un agente in auto che chiede dal telefono lo storico del cliente prima di entrare, e ottiene tre righe utili invece di un PDF da 40 pagine.

Errori che vediamo ripetersi

Partire dagli strumenti. La scelta tra database vettoriale A e B è irrilevante finché non sai quali domande devi soddisfare.
Vettorializzare tutto. Il RAG serve sui documenti. Per i numeri serve SQL. Chiedere a un indice semantico "quanto ho fatturato a marzo" produce risposte fantasiose.
Saltare la pulizia dei dati. Se le anagrafiche sono doppie, la risposta sarà doppia. Nessun modello risolve questo.
Nessun proprietario delle metriche. Serve una persona che decida cosa significa "margine". Se decidono in tre, avrai tre verità.
Dare accesso a tutti dal primo giorno. Si parte da 2–3 utenti che sanno riconoscere una risposta sbagliata, poi si allarga.

Database e AI: come interrogarli senza esporli