Come verificare il codice SQL generato dall’IA prima di usarlo

Perché una query eseguibile può essere sbagliata

Una query SQL generata dall’IA può essere sintatticamente valida, essere eseguita e restituire righe senza rispondere correttamente alla domanda aziendale. Il database esegue le operazioni richieste, ma non sa se una somma corrisponda alla metrica che il team chiama «ricavi», se il periodo selezionato sia quello giusto o se una JOIN abbia duplicato i record. La correttezza sintattica è una condizione per l’esecuzione, non una prova della correttezza logica.

Il rischio si annida spesso in decisioni plausibili, ma facili da non notare: collegare tabelle con una chiave errata, applicare un filtro mai richiesto, aggregare valori dopo aver moltiplicato le righe o interpretare i valori NULL in modo diverso dal previsto. Prima di eseguire la query, bisogna saper spiegare che cosa rappresenta ogni riga e perché ogni condizione è presente. Poi occorre confrontare il risultato con un riferimento indipendente, che non dipenda dalla stessa generazione dell’IA.

Questo protocollo riguarda le query analitiche su database relazionali. Non sostituisce la definizione delle regole aziendali né una revisione completa della sicurezza. Propone una sequenza pratica: chiarire la domanda, ispezionare staticamente il codice SQL, provarlo con un ambito limitato e convalidare l’output. L’accesso in sola lettura riduce i danni possibili, ma da solo non garantisce risultati corretti.

Passaggio 1: trasformare la domanda aziendale in criteri verificabili

Prima di leggere il codice SQL, chiarisci che cosa significa la richiesta. «Vendite del trimestre per cliente» lascia aperte diverse questioni: vendite lorde o nette? Ordini creati o completati? Quali date delimitano il trimestre? Si sottraggono i resi? Quale fuso orario si applica? Se queste decisioni non sono documentate, una query apparentemente ragionevole può rispondere a un’interpretazione diversa.

Scrivi una breve specifica che indichi la metrica, l’unità di analisi, il periodo, i filtri e il livello di raggruppamento. Identifica anche la fonte autorizzata per ciascun dato. Per esempio, se il totale si trova nell’intestazione dell’ordine e i prodotti in una tabella di dettaglio, specifica che, prima della somma, la metrica deve mantenere una riga logica per ordine. L’IA non dovrebbe completare in silenzio regole che il team non ha ancora concordato.

Chiarisci lo schema effettivo e il dialetto SQL. Controlla tabelle, colonne, tipi, chiavi e relazioni documentate nel database o nel dizionario dei dati; non fidarti di nomi che sembrano plausibili. In un’integrazione da linguaggio naturale a SQL, lo schema e le regole forniti al modello sono un contesto utile, ma l’output deve comunque essere verificato nel codice e sul motore di destinazione. Microsoft Learn, per esempio, mostra la generazione di SQL con valori parametrizzati e un controllo successivo delle query vietate; avverte inoltre che le istruzioni date al modello non sostituiscono la pianificazione delle misure di sicurezza.

Se manca una definizione necessaria, interrompi la revisione e chiedi chiarimenti alla persona responsabile dell’indicatore. Aggiungere una condizione inventata per «far funzionare» la query non risolve l’ambiguità: la trasforma soltanto in una decisione più difficile da individuare in seguito.

Passaggio 2: ispezione statica prima dell’esecuzione

Leggi la query dall’esterno verso l’interno e annota ogni tabella, JOIN, filtro, aggregazione, sottoquery e funzione finestra. Confronta gli oggetti con lo schema reale. Poi segui il percorso delle righe: quale relazione introduce ogni JOIN, quali condizioni escludono record e in quale punto cambia la granularità. Non considerare corretta una condizione solo perché il suo nome sembra familiare.

Le JOIN meritano particolare attenzione. Verifica che le chiavi utilizzate rappresentino la relazione giusta e chiariscine la cardinalità: uno a uno, uno a molti o molti a molti. Se una tabella contiene una riga per ordine e un’altra una riga per articolo, unirle può ripetere l’importo dell’intestazione per ogni articolo. Sommare quell’importo dopo la JOIN può gonfiare il totale senza produrre errori di sintassi. Aggiungere DISTINCT in un secondo momento non dimostra che la logica sia stata corretta.

Controlla ogni filtro rispetto alla specifica. Verifica stati, date, limiti inclusivi o esclusivi e condizioni sui NULL. Accertati che la query non elimini righe che dovrebbero essere conteggiate né ne includa altre fuori ambito. In una condizione come `colonna = valore`, i NULL non si comportano come valori ordinari: le regole di trattamento devono essere deliberate, non presunte.

Esamina aggregazioni e funzioni finestra ponendoti una domanda precisa: su quale insieme di righe viene calcolato ogni valore? Controlla che le colonne selezionate e raggruppate corrispondano al livello richiesto. Nelle sottoquery annidate, annota quali righe restituisce ogni livello e come si collega a quello successivo. Infine, verifica che funzioni e sintassi siano compatibili con il dialetto del motore di destinazione.

Passaggio 3: limitare l’ambito ed eseguire in un ambiente controllato

La prima esecuzione dovrebbe avvenire fuori dalla produzione, quando possibile: in un database di test isolato con dati sintetici oppure in una copia anonimizzata e aggiornata nel rispetto delle policy aziendali. I dati sintetici permettono di creare casi mirati — inclusi duplicati, valori nulli e date al limite — senza esporre record reali. Una copia anonimizzata può riprodurre meglio la distribuzione dei dati, ma occorre verificare che l’anonimizzazione sia adeguata e che la copia non disponga di permessi di scrittura sulla produzione.

Configura la connessione applicando il principio del privilegio minimo. Per testare una query, usa un’identità con accesso in sola lettura e limita l’accesso alle tabelle o viste necessarie. Controlla anche i vincoli sulle risorse: tempo massimo, numero di righe restituite e possibilità di annullare l’esecuzione. Una query in sola lettura può comunque consumare troppe risorse o restituire dati che l’utente non dovrebbe vedere: sicurezza e correttezza sono controlli correlati, ma distinti.

Non eseguire SQL generato dall’IA senza una convalida lato applicazione. Le istruzioni nel prompt possono orientare il modello, ma non sono un confine di sicurezza. Accetta solo le operazioni e gli oggetti consentiti, convalida i parametri e usa query parametrizzate per i valori. Microsoft Learn descrive un esempio in cui il server passa le stringhe come parametri e controlla la query prima di eseguirla; l’elenco di parole vietate presentato è dimostrativo, non una protezione completa da applicare senza adattamenti.

Inizia con il più piccolo ambito che consenta di verificare la logica: un’entità nota, un periodo breve o un campione ridotto. Se devi esaminare un piano di esecuzione, fallo nell’ambiente autorizzato e considera i costi. L’obiettivo non è dimostrare che la query può essere eseguita sull’intero database, ma verificare in sicurezza le ipotesi rilevanti prima di ampliarne l’ambito.

Passaggio 4: provare casi noti e confrontare i risultati

Un risultato plausibile non è un riferimento. La convalida deve basarsi su casi il cui esito sia prevedibile senza chiedere allo stesso modello di confermare la propria query. Prepara esempi ridotti con risultati calcolabili, record ai limiti del periodo, entità con e senza relazioni e righe con valori NULL, quando pertinente. Con i dati sintetici puoi controllare esattamente queste condizioni.

Confronta il risultato con una fonte di riferimento autorizzata: una query semplificata e revisionata da una persona, un report la cui definizione corrisponda alla specifica oppure un calcolo manuale su un insieme ridotto. Assicurati che entrambi i metodi usino lo stesso periodo, gli stessi filtri, le stesse regole di esclusione e la stessa granularità. Due query che differiscono su questi aspetti non sono confrontabili, anche se utilizzano lo stesso nome per la metrica.

Convalida sia la struttura sia i valori. Controlla il numero di righe, le chiavi duplicate, i totali per gruppo e i casi limite. Se il risultato deve contenere una riga per cliente, verifica l’univocità; se è raggruppato per mese, esamina anche i mesi senza attività e i limiti temporali. Se emerge una differenza, riduci il caso: esamina prima l’insieme precedente alla JOIN, poi quello successivo a ogni JOIN e infine il risultato dopo filtri e aggregazioni. In questo modo puoi individuare in quale fase cambia la cifra.

La convalida incrociata non trasforma un test limitato in una garanzia universale. Un caso noto può confermare che la query risponde correttamente in quella situazione, ma non necessariamente in tutti i periodi o tutte le combinazioni di dati. Trasforma in test di regressione i casi che hanno rilevato errori, così potrai controllare che le modifiche future non reintroducano lo stesso problema.

Errori, risultati vuoti e ambiguità

Un errore di sintassi indica che il motore non riesce a interpretare la query, ma correggerlo non ne convalida la logica. Verifica il dialetto, i nomi e i tipi prima di chiedere una nuova generazione. Se richiedi una correzione, descrivi l’errore specifico e mantieni le condizioni aziendali già verificate; limitarti a dire «sistemala» può portare l’IA a modificare altre parti della query.

Un risultato vuoto non ha una spiegazione univoca. Può dipendere da un filtro troppo restrittivo, da differenze di maiuscole o formattazione, da una data errata, da una relazione che esclude righe oppure dall’assenza effettiva di corrispondenze. Esamina ogni condizione separatamente nell’ambiente di test. Non eliminare automaticamente i filtri per ottenere risultati: potresti trasformare un problema di interpretazione in una query che include dati fuori ambito.

Se il modello non sa spiegare da dove provenga una tabella, una relazione o una regola, considera quell’elemento non verificato. Riformula la domanda specificando ciò che manca oppure chiedi chiarimenti alla persona responsabile della metrica. Le spiegazioni del modello possono aiutare a capire la proposta, ma non sono una prova indipendente della sua correttezza.

Se il codice SQL differisce dal riferimento, conserva la query, i parametri, la versione dello schema, il caso di test e il risultato osservato, nel rispetto delle misure di tutela della privacy. Correggi la causa, non solo il valore visibile. Poi ripeti i controlli interessati e aggiungi un test di regressione se il problema potrebbe ripresentarsi.

Checklist finale prima di integrare la query

Prima di utilizzare SQL generato dall’IA in un’analisi o in una pipeline, verifica che la domanda iniziale abbia una definizione controllabile, che ogni tabella, colonna e relazione esista nello schema e che le JOIN mantengano la granularità necessaria. Controlla filtri, aggregazioni, NULL, date, funzioni e dialetto. Accertati inoltre che la query sia stata provata in un ambiente autorizzato, con dati adeguati e permessi in sola lettura, quando il caso lo consente.

L’output deve superare un controllo indipendente basato su casi noti o dati di riferimento comparabili. Se il controllo non riesce, non presentare il risultato come confermato. Correggi o riformula la query, ripeti i test e registra la versione approvata insieme al relativo ambito. Questa lista non elimina la necessità di una revisione specialistica per indicatori ad alto impatto, dati sensibili o query complesse.

La regola pratica è semplice: una query è pronta solo quando la sua logica è comprensibile, l’accesso è limitato a quanto autorizzato e i test rappresentativi della domanda aziendale mostrano risultati coerenti. Se non puoi dimostrare una di queste condizioni, mantieni esplicita l’incertezza e chiedi una revisione prima di usarla.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.