Elaborare dati con i modelli IA: errori, tentativi, tracciamento e costi

Un'elaborazione dati con l'IA che funziona in una demo non dice molto. In una demo la rete è veloce, i dati sono puliti e nessuno chiama due volte. Nel lavoro vero, invece, succede tutto il resto. Un servizio risponde lento, un altro rifiuta le richieste, un modello IA restituisce un testo che non rispetta il formato. E la fattura del fornitore arriva a fine mese.

Qui descrivo come tengo affidabili le chiamate ai modelli IA negli strumenti con cui elaboro i dati. Parlo di cinque temi: contratto dei dati, errori, tentativi, tracciamento e costi.

Elaborazione dati con l'IA: prima viene il contratto dei dati

Il primo lavoro, in realtà, non è tecnico. Per ogni flusso scrivo da dove arriva il dato, dove deve finire e chi decide se qualcosa va storto. Poi fisso il formato: campi obbligatori, valori ammessi, cosa fare con un dato mancante.

Prendiamo un esempio ipotetico. Un'azienda riceve dal sito le richieste dei clienti e le vuole nel CRM già classificate: le classifico io con un modello IA e le carico nel CRM. I sistemi in gioco sono tre: il sito, il modello e il CRM. Senza un contratto scritto, però, ognuno fa ipotesi sugli altri. Di conseguenza il primo errore diventa una discussione su chi abbia ragione.

Errori temporanei ed errori definitivi

Non tutti gli errori, infatti, sono uguali. Alcuni passano da soli, altri no. Un'elaborazione dati con l'IA robusta li distingue subito.

Un errore di rete o un servizio momentaneamente non disponibile è temporaneo: ha senso riprovare. Al contrario, un dato non valido è definitivo. Infatti riprovare dieci volte produce dieci errori identici.

Poi c'è un caso a parte: il limite di richieste. Lo standard HTTP prevede il codice 429 "Too Many Requests". La risposta può includere l'intestazione Retry-After, definita nella RFC 9110, che dice quanto aspettare. Se il servizio lo indica, i miei strumenti lo rispettano. Altrimenti si rischia di essere bloccati più a lungo.

Tentativi senza doppioni

Nell'elaborazione dati con l'IA riprovare sembra banale. In realtà nasconde due trappole.

Aspettare nel modo giusto

La prima trappola è riprovare subito, tutti insieme. Se cento processi falliscono nello stesso istante e riprovano nello stesso istante, il servizio resta sommerso. La soluzione nota è attendere sempre di più fra un tentativo e l'altro, con una parte casuale. AWS la descrive bene in un articolo su backoff esponenziale e jitter. Inoltre fisso sempre un numero massimo di tentativi. Dopo l'ultimo, la richiesta va in una coda di errori che una persona può esaminare.

Non eseguire due volte la stessa azione

La seconda trappola è più grave. Per esempio, una richiesta parte, il servizio la esegue, ma la risposta si perde. Il mio strumento non lo sa e quindi riprova. Risultato: due richieste nel CRM, due e-mail, due registrazioni.

Per evitarlo, ogni operazione che scrive porta un identificativo unico. Chi riceve la richiesta lo ricorda e, se lo rivede, non ripete l'azione. Per HTTP esiste una bozza IETF per l'intestazione Idempotency-Key, che descrive proprio questo meccanismo. Anche quando il servizio esterno non lo supporta, lo si può applicare nella propria parte del flusso.

Elaborazione dati con l'IA: il formato non è garantito

Nell'elaborazione dati con l'IA, però, il modello non è un servizio come gli altri. La stessa richiesta può dare risposte diverse. Quindi la risposta va sempre validata prima di usarla: formato, campi, valori ammessi.

Se la classificazione non rispetta lo schema, il sistema non inventa. La richiesta va in una coda di revisione, con il testo originale e la risposta del modello. In questo modo un errore del modello resta un caso da guardare, non un dato sbagliato nel CRM.

Poi c'è il tema delle versioni. I fornitori aggiornano e ritirano i modelli con una certa frequenza. Per esempio, nelle note di rilascio delle API Gemini del 17 settembre 2026 Google annuncia una nuova versione del suo agente, con strumenti rinominati, e lo spegnimento della precedente il 5 ottobre. Per questo fisso la versione del modello nella configurazione dei miei strumenti. Poi la cambio solo dopo aver ripetuto i test sui casi reali.

Tracciamento: ogni chiamata deve lasciare una traccia

Quando un cliente chiede "che fine ha fatto la mia richiesta?", un'elaborazione dati con l'IA ben tracciata risponde in pochi minuti. Serve un identificativo che accompagni la richiesta in tutti i sistemi: sito, modello, CRM.

Per ogni chiamata registro almeno l'ora, la durata, l'esito, il numero di tentativi e l'identificativo. Per le chiamate ai modelli aggiungo la versione del modello e i token usati. Esiste anche uno standard aperto per questi dati: le convenzioni OpenTelemetry per l'IA generativa. In questo modo si evita di inventare un formato proprio. Inoltre permette di cambiare strumento di monitoraggio senza riscrivere tutto.

Costi: misurarli per chiamata, non a fine mese

Nell'elaborazione dati con l'IA i modelli si pagano a consumo, in token. Il costo quindi dipende da quanto testo entra e quanto ne esce. Due scelte tecniche pesano più di altre.

La prima è il riuso delle parti fisse della richiesta, come istruzioni ed esempi. Molti fornitori le fanno pagare meno quando vengono rilette dalla cache. Per esempio, nel listino del modello GPT-6 Sol l'input letto dalla cache costa il 10% di quello normale. Nel listino di Claude Opus 5.5, annunciato il 22 settembre 2026, la lettura dalla cache costa 0,20 dollari per milione di token, contro 4 dollari dell'input.

La seconda scelta è l'elaborazione differita. Se una classificazione può aspettare qualche ora, spesso costa meno. Sempre nel listino di GPT-6 Sol, l'elaborazione Batch costa la metà della tariffa standard.

Infine imposto un tetto di spesa e un avviso. Infatti un ciclo di tentativi sbagliato può moltiplicare le chiamate in poche ore. Meglio scoprirlo da un avviso che dalla fattura.

Una lista di controllo per l'elaborazione dati con l'IA

Prima di usare una procedura su dati veri controllo sei punti:

• il contratto dei dati è scritto e ha un responsabile per ogni flusso;
• gli errori temporanei e definitivi seguono percorsi diversi;
• i tentativi hanno attesa crescente, parte casuale e un limite;
• ogni scrittura ha un identificativo che impedisce i doppioni;
• ogni chiamata lascia una traccia ricostruibile;
• costi e consumi hanno un tetto e un avviso.

Nella pagina sulla conversione e il trasferimento dei dati descrivo come imposto questo lavoro, dalla mappa dei campi al registro degli scarti e delle correzioni.

Se hai dati che oggi passano a mano da un sistema all'altro, oppure un passaggio di dati che si interrompe senza avvisare, scrivimi. Guardiamo insieme dove si perde il dato e quale intervento ha più senso.