Interrogare i dati aziendali con l'IA: quando la risposta deve essere esatta.

Studio machine learning dal 2020 circa, poi deep learning, IA generativa e modelli linguistici, attraverso corsi, documentazione e sperimentazione: è la base su cui lavoro. L'esperienza diretta su progetti reali è molto più recente, e con grandi piattaforme di IA generativa in produzione è ancora limitata.

Queste osservazioni nascono dall'incontro tra quello studio e quasi trent'anni di sviluppo di software reale. Guardo soprattutto alla sostenibilità: un sistema deve offrire valore sufficiente a giustificare sviluppo, verifica e gestione nel tempo.

Il modello linguistico interviene al massimo in tre punti; tutto ciò che è numero resta codice.

1. Il codice riconosce nella domanda nomi, codici e quantità che esistono davvero nei dati.
2. Le domande più frequenti seguono percorsi fissi, senza passare da un modello.
3. Per le altre, il modello propone come cercare; il codice controlla la proposta prima di eseguirla.
4. Conteggi e somme li calcola il database; il modello scrive solo il testo delle risposte di ricerca, citando dati che il sistema ha verificato.

Quattro errori di questo progetto, ancora in sviluppo e test. Gli esempi sono costruiti per illustrare l'errore, non sono domande o dati reali.

1. La domanda letta male, in silenzio

L'errore. Il cliente Rossi, nella chat sul sito dell'azienda, chiede: "Quanto mi avete consegnato nel 2025?". Il programma compone la richiesta e la manda al motore. Se il modello perde il nome del cliente, il sistema risponde con il totale dell'azienda: Rossi vede dati che non sono suoi. Il numero è vero e nessun controllo scatta: non è un errore, è un risultato plausibile. Questo scenario è possibile, non è un uso attuale del progetto, ma il rischio non dipende dal tipo di dato né da chi chiede.

Vale anche dentro l'azienda: un collaboratore che chiede "il budget del mio reparto" e riceve quello di tutti, o che vede i risultati dei singoli agenti commerciali. Succede anche in altri modi: il modello ignora un periodo o un prodotto, oppure il programma applica un valore predefinito anche se la richiesta ne indicava uno. Basta anche una parola: "ordini a giugno 2025" e "ordini fino a giugno 2025" indicano un mese e un intervallo. Il modello lo legge bene il più delle volte, talvolta no, e un errore raro non si vede in una dimostrazione.

Come ci si accorge. Il perimetro di chi può vedere cosa lo applica il codice, a partire da chi sta chiedendo, e non dipende da come il modello legge la domanda: un'istruzione al modello può essere aggirata. Poi chiedo al modello non solo cosa ha capito, ma quali parole della domanda ha usato e dove. Il codice rilegge la domanda: se prima di "a giugno 2025" c'era "fino", il modello l'ha escluso e il codice corregge l'interpretazione. Le parole di chi chiede prevalgono su ciò che il modello propone.

Esiste anche l'errore opposto: il modello rifiuta la domanda perché la giudica non abbastanza univoca. Non espone dati, ma chi chiede resta senza risposta, e lo conto come errore.

Cosa chiedere a chi sviluppa. Cosa impedisce a un utente di vedere dati non suoi: il modo in cui il modello legge la domanda, o un controllo che non dipende da quello? Cosa fa il sistema quando una parte della domanda non risulta spiegata da ciò che ha interpretato?

Sicurezza: a quali dati può arrivare il sistema →

2. La precisione si misura, non si sente

L'errore. Giudicare il sistema da qualche domanda provata a mano. Funziona sulle domande che ci si ricorda e sbaglia quelle che nessuno ha provato.

Come ci si accorge. Una serie di domande di riferimento, ciascuna con la risposta attesa scritta e approvata da una persona: da qualche decina a circa 150, a seconda che si verifichi una singola modifica o si qualifichi l'intera procedura. A ogni esecuzione conto le interpretazioni sbagliate (periodo, cliente o prodotto ignorato, valore predefinito al posto di quello indicato), i rifiuti per ambiguità e le differenze tra due esecuzioni della stessa domanda: anche a parità di prompt, la stessa domanda può dare risposte diverse. La messa a punto la faccio su una parte delle domande, la verifica su un'altra, e non scrivo mai nel codice le parole di una domanda di prova.

Cosa chiedere a chi sviluppa. Chi ha scritto e chi ha approvato le risposte attese? Quante sono, e cosa succede alle domande a cui il sistema non risponde? Le risposte attese le devono scrivere e approvare persone dell'azienda: è tempo da mettere in conto.

3. Un modello alla volta

L'errore. Provare più modelli insieme. Oltre a Qwen3.8-27B ho provato Gemma 4 nelle versioni 26B e 31B: davano più interpretazioni sbagliate, dello stesso tipo di quelle viste sopra. Probabilmente richiederebbero un prompt messo a punto per ciascun modello. Con tre modelli non distinguevo il difetto del modello da quello del codice.

Come ci si accorge. Mi sono fermato su un modello, fino a una baseline che funziona e si misura. Provare gli altri per vedere le differenze è il passo successivo, non ancora fatto. Cambiare modello non è una sostituzione: è un nuovo lavoro di prova.

Cosa chiedere a chi sviluppa. Su quanti modelli è stato provato il sistema? Cosa cambia, e cosa resta uguale, se si cambia modello?

Non restare legati a un fornitore →

Cambiare modello: solo con prove →

4. Una regola per problema, non una toppa per caso

L'errore. Una revisione trova un problema e lo correggo. La revisione successiva ne trova un altro, diverso ma nella stessa area della procedura: spesso un altro aspetto dello stesso problema, talvolta una conseguenza della correzione precedente. Ogni correzione, presa da sola, è giusta; ma procedere un punto alla volta non chiude la serie, perché non si interviene sulla regola da cui dipende tutta l'area. Esempio costruito: aggiungo il filtro per cliente alla ricerca; la revisione successiva trova che, quando il filtro non si può applicare, la ricerca ricade su un valore predefinito; quella dopo trova lo stesso punto debole nell'esportazione.

Come ci si accorge. Quando due revisioni trovano problemi diversi nella stessa area, non correggo il terzo punto. Per ogni problema adotto una sola regola, scritta in modo che nel dubbio blocchi: se il sistema non può dimostrare che una risposta è consentita, non la dà. La regola la verifico con un test generato su molti casi, non con pochi esempi scritti a mano. Un caso nuovo si aggiunge ai casi generati, non diventa una correzione a parte.

Cosa chiedere a chi sviluppa. Quando una revisione trova un altro problema nella stessa area, cosa cambia: un'altra correzione o una regola? Il test copre i casi possibili o solo quelli già visti? Nel dubbio, il sistema risponde o si ferma?

Il modello linguistico interviene al massimo in tre punti; conteggi, somme, applicazione dei filtri e citazioni restano codice deterministico.

Codicepassaggio deterministicoModellochiamata a un modello linguistico

Questi riferimenti sostengono i criteri tecnici generali. Le misure sul mio hardware descrivono quella configurazione e non sono trasferibili automaticamente ad altre.

• Microsoft — valutazione dei sistemi RAG (si apre in una nuova scheda): distingue pertinenza dei documenti recuperati, aderenza alle fonti e qualità della risposta finale.
• Google Cloud — architetture agentiche (si apre in una nuova scheda): descrive i compromessi di latenza, costi e complessità dei flussi con più agenti e chiamate al modello.
• Evalita-LLM — benchmark per l'italiano (si apre in una nuova scheda): offre prove su compiti in italiano per confrontare i modelli; non sostituisce una verifica sul caso d'uso.
• Databricks — adozione dei modelli aperti (si apre in una nuova scheda): nei dati aggregati dei suoi clienti documenta l'uso di modelli aperti; il campione non rappresenta l'intero mercato.
• Databricks — tendenze dei sistemi agentici (si apre in una nuova scheda): rileva la crescita dei flussi con più agenti tra i propri clienti, senza dimostrare che siano adatti a ogni caso.
• OWASP — Sensitive Information Disclosure (si apre in una nuova scheda): minimo privilegio e limiti delle istruzioni date al modello; non descrive i filtri per utente nella ricerca.
• Thinking Machines — non determinismo dell'inferenza (si apre in una nuova scheda): a temperatura 0 la stessa richiesta può dare risposte diverse, misurato su un modello e un server; non descrive la mia configurazione.
• Sclar et al. — sensibilità al formato del prompt (si apre in una nuova scheda): modelli diversi reagiscono in modo diverso al formato; studio su modelli precedenti, non sul mio caso.