Le chat generiche non conoscono i ruoli aziendali, le viste SQL approvate né i requisiti di audit. Per interrogare il database in linguaggio naturale in sicurezza serve un copilot dati con template SQL governati, permessi per ruolo e tracciabilità — il tema che guidiamo nel laboratorio NL2SQL di Purple AI. Questo articolo riassume il perché tecnico e organizzativo, senza sostituire una valutazione legale o una revisione DBA sul vostro schema.
Obiettivo: dare al business risposte rapide su KPI senza aprire il database a query arbitrarie generate dal modello e senza creare shadow IT parallelo.
Contesto operativo e stakeholder
In un’organizzazione media o grande, la richiesta di “mettere ChatGPT sul database” arriva spesso dal business dopo una demo generica. Il rischio è sottovalutare ruoli SQL, viste materializzate, permessi granulari e tracciamento delle query eseguite. Purple AI propone un percorso in cui il linguaggio naturale è solo lo strato finale: sotto restano template approvati, validatori e audit log consultabili dal vostro security officer.
Perché il modello generico non basta
Un LLM pubblico non conosce la vostra nomenclatura interna, le abbreviazioni di reparto né le tabelle che non devono mai essere joinate. Anche con prompt lunghi, la probabilità di SQL invalido o pericoloso resta troppo alta per ambienti regolati. Un copilot aziendale deve quindi combinare retrieval su dizionario dati, mapping intent → template e, solo dove sicuro, completamento controllato.
Template SQL e governance
I template non sono “optional”: definiscono lo spazio delle query ammissibili. Il sistema può riempire parametri tipizzati (date, codici articolo, filiali) ma non inventare nuove join. L’IT mantiene versionamento dei template come codice applicativo, con pull request e ambienti di test.
Ruoli, JWT e principio del minimo privilegio
Ogni richiesta porta un contesto identità. Il motore risolve quali template e quali parametri sono consentiti per quel ruolo. Se il CFO chiede margini su una divisione non autorizzata, la risposta è un rifiuto esplicito, non una query silenziosa fallita.
Audit e retention
Registriamo chi ha chiesto cosa, quale template è stato usato, tempi di risposta ed esito. La retention segue policy aziendale e GDPR. Dove necessario, mascheriamo valori sensibili nei log pur mantenendo tracciabilità per contestazioni interne.
Integrazione con Excel e BI
Il valore percepito sale se il copilot alimenta export Excel o dataset già usati dal reparto controllo. Non sostituiamo la BI: conviviamo, interrogando le stesse fonti controllate e rispettando refresh schedulati.
Anti-pattern da evitare
Permettere SQL arbitrario generato dal modello. Esporre credenziali di database al browser. Saltare ambienti di staging. Non avere rollback del prompt o della configurazione quando un aggiornamento modello peggiora la qualità.
Checklist pre go-live
Test con utenti reali su dataset anonimizzato. Soglie di allarme su costo per query e su latenza p95. Piano di comunicazione interna per aspettative. Procedure di escalation quando il sistema risponde “non so” o propone conferma umana.
Semantic layer e metadati
Un dizionario dati leggibile dalla macchina riduce ambiguità: sinonimi di colonna, unità di misura, grain delle tabelle fatti. Il copilot interroga prima questo layer per capire se la domanda utente è mappabile a template esistenti. Senza metadati curati, anche il miglior modello produrrà risposte incoerenti con la semantica del warehouse.
Performance e query plan
I template possono essere rivisti dal DBA per indici e partizionamento. Monitoriamo piani di esecuzione ricorrenti e tempi: un linguaggio naturale che genera full scan ripetuti va corretto a monte, non mascherato con cache aggressiva che nasconde debito dati.
Test di regressione dopo cambio modello
Quando il provider aggiorna il modello, rieseguite una batteria di domande golden con esito atteso. Registrate differenze di tono o di parametri estratti. Questo disciplina l’incertezza intrinseca degli LLM in un perimetro ristretto.
Costi variabili
Ogni richiesta può comportare chiamate multiple (classificazione intent, estrazione slot, eventuale riscrittura risposta). Contabilizzate token in ingresso e uscita, non solo “una domanda = un prezzo fisso”. Il product owner deve vedere una dashboard sintetica mensile.
Formazione utenti finali
Gli utenti devono sapere cosa il sistema può e non può fare, come formulare domande chiare e quando passare al report tradizionale. Una demo di venti minuti non basta: servono esempi sul loro dominio e messaggi su limiti di accuratezza.
Disaster recovery e continuità
Se il servizio LLM esterno ha outage, definite comportamento degradato: messaggio chiaro, coda delle richieste o fallback su report pre-calcolati. L’azienda non deve bloccarsi perché un vendor terzo ha un incidente temporaneo.
Confronto con BI self-service classica
Strumenti drag-and-drop richiedono training su schema; il copilot abbassa la barriera iniziale ma non elimina la necessità di capire metriche ufficiali. Il punto di equilibrio dipende dalla maturità dati del reparto e dalla varietà delle domande ad hoc.
Sicurezza delle credenziali
Le connessioni al database restano lato server con segreti in vault. Mai incollare stringhe di connessione in prompt pubblici o in log client-side. Ruotate le chiavi quando un dipendente lascia il progetto o in caso di sospetto incidente.
Multi-lingua e sinonimia
In aziende internazionali, la stessa metrica può essere chiesta in più lingue. Il layer semantico e i template devono essere progettati per sinonimi e varianti linguistiche coerenti con il glossario aziendale, non solo italiano.
Metriche di qualità per il business
Oltre all’accuratezza tecnica, misurate soddisfazione utente, tempo risparmiato rispetto al ticket IT e tasso di abbandono del tool. Se il copilot è tecnicamente corretto ma inutilizzato, il problema è UX o fiducia, non solo SQL.
Human in the loop
Per operazioni sensibili (reimport massivo, modifiche a soglie di allerta) richiedete conferma esplicita da un umano con ruolo adeguato. Il modello può proporre, ma non eseguire transazioni distruttive senza workflow approvato.
Documentazione per auditor
Preparate un dossier che spieghi flusso dati, fornitori LLM, retention log e misure di mascheramento. Gli auditor interni ed esterni chiederanno tracciabilità, non solo screenshot della chat.
Roadmap evolutiva
Dopo il go-live, pianificate revisioni trimestrali di template, aggiornamento glossario e riesame fornitori. Il sistema deve crescere con il warehouse, non restare congelato alla versione del primo giorno.
Conclusione
Il linguaggio naturale sui dati aziendali richiede governance, non solo un modello più grande. Se volete approfondire l’implementazione tecnica, leggete i casi studio e la pagina Servizi; per una conversazione sul vostro stack, contattateci. Portate in call uno schema semplificato e tre domande reali che vorreste automatizzare oggi.