L'AI che prevede,
e quella che indovina

C'è un fenomeno che rende difficile ragionare su questo argomento e si chiama effetto AI: appena una tecnica funziona in modo affidabile, smettiamo di chiamarla intelligenza artificiale e le diamo il nome del suo mestiere. Il riconoscimento della scrittura sugli assegni era AI; oggi è «lettura degli assegni». L'antifrode della tua carta era AI; oggi è «l'antifrode». Il navigatore che calcola il percorso più breve è, tecnicamente, un algoritmo di ricerca su grafo nato in un laboratorio di intelligenza artificiale nel 1968; oggi è «il navigatore». Chiamiamo AI solo ciò che non funziona ancora bene: è una definizione mobile che si ritira ogni volta che facciamo un passo avanti. Il risultato è che l'AI sembra sempre imminente e mai arrivata, mentre in realtà è arrivata da decenni ed è dappertutto, sotto altri nomi.

Vale la pena ripercorrere la strada, perché ogni epoca ha lasciato in eredità qualcosa che usiamo ancora oggi, e perché quasi tutti gli errori che vedo fare nel 2026 con gli LLM sono errori già commessi, e già capiti, negli anni Ottanta.

La storia dell'AI non è una scala verso gli LLM. È un armadio di attrezzi in cui gli LLM sono l'ultimo cassetto, non l'unico.

Perché ti riguarda concretamente. Se il tuo problema è «dato questo cliente, comprerà?», il tuo strumento è la rivoluzione statistica del 1995: un gradient boosting su tabella, che gira in venti millisecondi su una macchina da quattro euro al mese, ti dice quali variabili contano e non inventa nulla. Se il tuo problema è «leggi queste ottocento mail di reclamo e dimmi di cosa si lamentano», allora sì, è l'ultimo cassetto. Il mestiere è sapere quale cassetto aprire, e per saperlo bisogna sapere che gli altri cassetti esistono.

Aggiungo la cosa che dico sempre ai clienti, che è la vera lezione dei sistemi esperti. Quelle regole non morirono perché erano stupide: morirono perché nessuno si era occupato del loro ciclo di vita. Chi le aggiorna, chi verifica che non si contraddicano, chi si accorge che il mondo è cambiato. Oggi si costruiscono modelli con lo stesso identico difetto: nascono benissimo, e nessuno ha deciso chi li guarderà tra otto mesi. Il modo di morire è lo stesso, è solo cambiata la matematica.

La tassonomia che segue è quella che uso sul campo. Ogni casella ha un modo diverso di fallire, un fabbisogno diverso di dati, un costo diverso e un modo diverso di essere verificata. Quando in una riunione qualcuno dice «mettiamoci l'AI», la prima domanda utile è sempre la stessa: in quale di queste caselle stiamo? Nove volte su dieci la discussione finisce lì, perché ci si accorge che due persone stavano parlando di due caselle diverse.

Due distinzioni ulteriori, perché è lì che nascono i malintesi più costosi.

Discriminativo contro generativo. Un modello discriminativo impara il confine tra le classi: dato il cliente, la probabilità che compri. Un modello generativo impara com'è fatta la distribuzione e sa produrre nuovi esemplari verosimili. Sembra un dettaglio filosofico, ed è invece la ragione tecnica per cui un LLM può scrivere una previsione bellissima e sbagliata senza il minimo disagio: sta facendo esattamente il suo mestiere, che è generare qualcosa di verosimile.

Ristretta contro generale. Tutto quello di cui parliamo qui è AI ristretta: un compito, un dominio, una metrica. L'AGI è un'altra conversazione, e non serve averne un'opinione per costruire un sistema che decide quanti pezzi ordinare a marzo. Anzi: nella mia esperienza, più una riunione parla di AGI, meno è probabile che finisca con qualcosa in produzione.

Dentro un LLM, quando gli fai una domanda, non c'è nessuna scintilla di casualità. C'è una sequenza di moltiplicazioni tra matrici, deterministica come una calcolatrice: stessi pesi, stesso input, stesso risultato. Alla fine di tutto questo calcolo il modello produce, per ogni singola parola che potrebbe venire dopo, un punteggio. Un vettore di decine di migliaia di numeri, uno per token. Questo vettore è sempre lo stesso, bit per bit, a parità di input e di condizioni di calcolo.

Poi succede la cosa importante: qualcuno deve scegliere una parola. E a scegliere ci pensa il codice che sta intorno al modello. È lì che entra il caso, per scelta di progetto, non per magia.

E allora perché con T=0 a volte cambia lo stesso? Perché la riproducibilità che ti immagini richiede che sia identico non solo il modello, ma tutto il resto. In pratica, sui servizi veri, non lo è quasi mai, per quattro motivi molto concreti:

Il capriccio non c'entra: stai guardando un sistema numerico sensibile alle condizioni iniziali. È lo stesso identico fenomeno del capitolo sul caos, otto sezioni più avanti.

Cosa farne, in pratica. Se stai generando testo per una persona, la variabilità è un pregio. Se stai estraendo un numero che finisce in un database, la variabilità è un difetto e va progettata via: temperature=0, seed fisso quando il fornitore lo espone, versione del modello bloccata esplicitamente (mai il nome generico), output vincolato a uno schema. E poi la regola che non tratto: logga il prompt esatto e la versione esatta insieme al risultato. Senza quei due campi, tra sei mesi non potrai nemmeno dimostrare cosa aveva risposto il modello quando avete deciso.

E qui c'è la trappola che voglio lasciarti come idea forte del capitolo. Molti, per «stabilizzare» le risposte numeriche, mettono T=0 e si tranquillizzano. Ma una risposta stabile non è una risposta giusta: T=0 ti dà lo stesso errore, tutte le volte, con la stessa faccia sicura. Hai eliminato il rumore, non il bias. Anzi, hai perso l'unico segnale gratuito che avevi: la variabilità tra risposte è un indicatore, grezzo ma reale, di quanto il modello è incerto. Nel capitolo 19 lo trasformiamo in uno strumento di misura al posto di buttarlo via.

«Vorremmo prevedere le vendite.» Sembra una frase chiara. Non lo è. Dentro ci sono almeno tre richieste incompatibili, con tre matematiche diverse e tre modi diversi di essere sbagliate. Distinguerle è il primo atto architetturale del progetto, e si fa prima di scegliere qualunque tecnologia.

Il cliente chiede sempre di prevedere. Quasi sempre vuole ottimizzare. Quasi mai gli serve la previsione che ha chiesto, e quasi sempre gli serve quella che non sa di volere: la distribuzione, non il numero.

Ti faccio l'esempio che uso in aula, perché rende l'idea in trenta secondi. Un'azienda mi chiede un modello per «prevedere la domanda» di un ricambio. Facciamo il lavoro, portiamo l'errore medio dal 30% al 18%: risultato tecnicamente ottimo. Non cambia niente in magazzino. Perché? Perché quel ricambio, se manca, ferma un impianto del cliente: costa migliaia di euro l'ora. Se avanza, costa due euro di scaffale l'anno. Il rapporto tra i due errori è mille a uno, e quindi la decisione giusta non ha mai avuto bisogno di una previsione precisa: aveva bisogno di sapere quanto in alto stare nella coda della distribuzione. Con una previsione mediocre e la domanda giusta si decideva meglio che con una previsione eccellente e la domanda sbagliata.

Ecco il criterio che porto in ogni prima riunione, ed è la cosa più utile di questa sezione: non chiedere mai «cosa vuoi prevedere», chiedi «quale decisione cambia in base al numero, e cosa succede se sbagliamo per eccesso invece che per difetto». Se la risposta è «nessuna decisione, è per un cruscotto», il progetto giusto non è AI: è un grafico. Se la risposta è «per eccesso perdiamo 2 euro, per difetto ne perdiamo 2.000», hai appena scoperto che non ti serve una previsione, ti serve un quantile, e nel capitolo 13 ti mostro l'equazione, di una riga, che ti dice esattamente quale.

Tolta la mitologia, l'apprendimento automatico è una procedura in tre atti che si ripete uguale dal 1805 a oggi. Sì, 1805: i minimi quadrati di Legendre e Gauss, usati per prevedere l'orbita di un asteroide, sono già machine learning con un altro nome. Gli atti sono questi: scegli una famiglia di funzioni, definisci quanto ti fa male sbagliare, cerca dentro la famiglia la funzione che ti fa male di meno. Fine. Un GPT da mille miliardi di parametri fa esattamente questo, con una famiglia più grande e una collina più accidentata.

Cosa cambia davvero tra un modello e l'altro, allora? Cambia l'atto primo: la famiglia di funzioni dentro cui cerchi. Una retta è una famiglia povera: qualsiasi cosa tu faccia, resta una retta. Un albero di decisione è una famiglia di scalini. Una rete profonda è una famiglia sterminata, capace di approssimare qualsiasi funzione continua (è un teorema, e come tutti i teoremi di esistenza non ti dice affatto che riuscirai a trovarla). Più la famiglia è ricca, più cose puoi rappresentare, e più facilmente rappresenterai anche le fesserie: è esattamente il tema del prossimo capitolo, ed è il compromesso centrale di tutto il mestiere.

Un'ultima cosa, sull'«imparare» come parola. Il modello non impara il fenomeno: impara la distribuzione congiunta dei dati che gli hai dato. Se nei tuoi dati storici i preventivi grandi li firmava sempre il commerciale più bravo, il modello imparerà che «commerciale bravo → preventivo firmato» e ti dirà di mandare lui dappertutto. Non ha capito niente della vendita: ha visto una correlazione e l'ha presa sul serio, perché è l'unica cosa che sa fare. Tutta la disciplina che segue (validazione, backtest, guardrail) esiste per compensare questo singolo fatto.

Torniamo alla demo che hai visto in cima alla pagina. Due modelli, stessi dati. Il primo passa esattamente per ogni punto: errore sullo storico quasi zero. Il secondo ne manca parecchi. Poi arriva il futuro, e il primo esce dal grafico. Questo non capita per caso. È una scomposizione algebrica esatta dell'errore che ti aspetti su un dato mai visto, e vale per qualunque modello, dalla retta a GPT.

Rileggi l'ultima frase, perché è la cosa più commercialmente utile di questa risorsa. Quando un fornitore ti promette il 95% di accuratezza su un fenomeno che ha un σ² alto, non sta essendo ottimista: sta descrivendo una violazione dell'algebra. O ha barato nella validazione (cap. 07), o sta misurando un'altra cosa, o non sa quello che dice. Non ci sono altre possibilità. Ed è una domanda che puoi fare in riunione senza essere un tecnico: «qual è secondo voi il rumore irriducibile di questo fenomeno, e come l'avete stimato?». La qualità della risposta ti dice tutto quello che ti serve sapere sull'interlocutore.

Il grafico qui sotto è la demo che rende visibile il compromesso. Muovi la complessità del modello e guarda le due curve muoversi in direzioni opposte: l'errore sullo storico scende sempre, quello sul futuro scende, tocca il fondo, e poi risale. Il punto giusto non è dove il modello è più bravo. È dove la somma è minima, e per trovarlo devi guardare dati che il modello non ha mai visto. Non c'è nessun altro modo. Nessuno.

Come si combatte, davvero. Quattro armi, in ordine di efficacia reale sul campo.

1. Più dati. Abbassano la varianza senza toccare il bias, ed è per questo che i modelli enormi funzionano: più esempi vedono, meno prendono una coincidenza per segnale.
2. Regolarizzazione. Aggiungi alla loss un termine che penalizza i parametri grandi (L + λ‖θ‖²). Stai dicendo al modello: puoi curvare, ma ti costa.
3. Validazione onesta. Tenere dati chiusi in un cassetto e non guardarli mai finché non hai finito.
4. Meno feature. Ogni colonna che aggiungi è un'occasione in più di trovare una coincidenza.

Il doppio discendente, per onestà: sui modelli giganteschi la U ha una seconda discesa dopo il picco. È vero, è studiato, ed è irrilevante per te: vale in regimi di sovraparametrizzazione estrema che non hai sui tuoi ventimila record.

Chiudo con il consiglio più pratico che ho. Quando un modello ti dà un risultato bellissimo al primo colpo, non festeggiare: cerca l'errore. In ventisei anni, un risultato splendido ottenuto subito è stato un errore nel novanta per cento dei casi, quasi sempre il leakage del capitolo 07. Il modello che funziona davvero, di solito, all'inizio funziona così così.

Sotto trovi la tabella che ho in testa quando entro in un progetto. Le colonne le ho scelte guardando cosa fa vivere un progetto, non cosa vince un benchmark. Dati necessari, perché il modello più bravo è inutile se ti servono cento volte i record che hai. Interpretabilità, perché in un mondo di crediti, sanità, assicurazioni e adesso AI Act, «non so perché ha detto no» è una risposta che può costarti l'attività. Costo, in addestramento e in inferenza, che è la voce di bolletta che nessuno mette nel preventivo. E soprattutto dove tradisce: perché ogni algoritmo ha un modo tipico di rovinarti la giornata, e conoscerlo in anticipo vale più di due punti di accuratezza.

Se dovessi tenere una riga sola: sui dati tabellari, gradient boosting. Sui segnali, deep learning. Sulle serie corte, ETS. E sempre, prima di tutto, il baseline stupido.

Il baseline stupido è il vero protagonista di questo capitolo, e nessuno gliene dà atto. È la previsione «domani come oggi» (naïve), o «come lo stesso mese dell'anno scorso» (naïve stagionale), o «la media degli ultimi tre». Non ha parametri, si scrive in una riga, gira in un microsecondo. Se il tuo modello da centomila euro non lo batte in modo netto e ripetuto, il tuo modello non esiste. Ho visto progetti da sei mesi chiudersi con questa singola frase, e in almeno due casi l'ho detta io, gratis, alla prima riunione. Chiedilo sempre, prima di firmare qualunque cosa: «qual è il baseline, e di quanto lo battiamo?». Se la risposta è imbarazzata, hai risparmiato un anno.

Sul No Free Lunch, visto che l'ho citato: Wolpert ha dimostrato che, mediando su tutti i problemi possibili, tutti gli algoritmi vanno uguale. In pratica serve a poco, perché i tuoi problemi hanno una struttura e non escono a caso dall'universo. Il corollario però è utilissimo: ogni algoritmo che funziona bene funziona perché ha un pregiudizio azzeccato sul tuo tipo di dati. Gli alberi presumono che il mondo sia a scalini. La regressione che sia liscio. Le reti convoluzionali che le cose vicine nello spazio siano correlate. Scegliere un algoritmo è scegliere un pregiudizio. Fallo consapevolmente e avrai già fatto metà del lavoro di un data scientist serio.

Un modello non vede il tuo business: vede una matrice di numeri. Tutto quello che sa del mondo è passato dalle colonne che gli hai preparato. Per questo il feature engineering, costruire quelle colonne, è il lavoro dove si vince, ed è un lavoro da gente che conosce il dominio molto più che da statistici. La colonna «giorni dall'ultimo ordine» vale, su un problema di churn, più di sei mesi di tuning. La colonna «è il mese di chiusura del bilancio del cliente» vale più di una rete neurale. Nessun algoritmo scoprirà mai queste cose da solo, perché nei dati non ci sono. Stanno nella testa di chi lavora lì da vent'anni. Il novanta per cento del valore di un data scientist bravo è saper fare le domande giuste a quella persona.

E poi c'è il leakage. Il data leakage è quando nelle feature entra, anche indirettamente, un'informazione che al momento della decisione non avrai. Il modello la usa, il punteggio in validazione diventa splendido, tutti sono felici, il progetto viene approvato. Poi va in produzione e crolla, e nessuno capisce perché. È l'errore più frequente, più costoso e più subdolo di tutto il campo, e l'unico sintomo è che va troppo bene.

La regola, e non ha eccezioni: il modello non deve mai vedere un dato che, nel momento in cui deciderà davvero, non esisterà ancora.

Come si evita, concretamente. Per ogni feature, poniti una domanda sola e in forma brutale: «questo valore, alle 9 di lunedì mattina, quando devo decidere, ce l'ho già in mano, con questo esatto valore?». Se la risposta è «beh, quasi», è no. Se è «sì ma viene caricato a fine mese», è no. Se è «sì ma viene corretto a posteriori», e questa è la più cattiva, perché nel database sembra esserci: è comunque no. Le anagrafiche corrette retroattivamente sono un leakage silenzioso che ho visto avvelenare interi progetti senza che nessuno se ne accorgesse per un anno.

La contromisura strutturale, per chi vuole farlo bene: un feature store con validità temporale, cioè registrare non solo il valore, ma da quale istante quel valore era conoscibile, e ricostruire il training «come si vedeva allora» (point-in-time correctness). È lavoro serio da fare una volta, e trasforma la domanda «stiamo barando?» da opinione a query. Se lavori su dati che valgono soldi, è la singola infrastruttura che consiglio prima di qualunque modello.

Il ciclo canonico è quello del CRISP-DM del 1999, e va bene, ma la versione onesta, quella con le proporzioni vere, è questa. Te la do con le percentuali di tempo che vedo nei progetti reali, non in quelli raccontati alle conferenze.

Il target è il vero progetto. Un esempio che mi porto dietro. «Prevedere i clienti che ci lasciano.» Benissimo: cos'è un cliente che ci ha lasciato? Chi disdice formalmente? Chi non ordina da 90 giorni? Da 180? Chi ha ridotto del 70% ma è ancora lì? A seconda della definizione ottieni dataset diversi, modelli diversi, azioni diverse e ROI diversi. Ho visto due team della stessa azienda costruire due modelli di churn che davano risposte opposte sugli stessi clienti: entrambi corretti, definizioni diverse. Quel giorno il problema non era statistico. Era che nessuno aveva scritto una frase in italiano.

C'è poi una cosa che ai clienti dico sempre, e che nessuna metodologia mette in diagramma: lo scopo di un progetto di data science è una decisione presa diversamente, e il modello è solo il mezzo per arrivarci. Se alla fine del progetto tutti decidono esattamente come prima, il progetto è fallito anche se il modello è splendido e il notebook è bellissimo. Per questo la mia prima domanda non è mai sui dati. È: «quando il modello dirà un numero che non vi piace, chi ha l'autorità di seguirlo lo stesso?». Se non c'è quella persona, non serve costruire niente: state comprando un oggetto decorativo.

E l'ultima parte, sorvegliare, non è manutenzione. È il progetto. Un modello è l'unica cosa che compri che si guasta stando ferma.

Perché si guasta stando ferma? Perché il mondo si muove sotto di lui. Si chiama drift e ha due sapori: cambia la distribuzione degli ingressi (data drift: ti sono arrivati clienti di un altro tipo), oppure cambia la relazione stessa tra ingressi ed esito (concept drift: gli stessi clienti si comportano diversamente perché è cambiato il mercato, un concorrente, una legge). Il modello continua a rispondere con la stessa sicurezza di sempre. Non ha nessun modo di dirti che il mondo che aveva imparato non c'è più: l'unica cosa che può accorgersene sei tu, se hai messo in piedi la misura. Un modello senza monitoraggio diventa un debito che matura in silenzio.

Il machine learning standard poggia su un'ipotesi che si scrive in una sigla, i.i.d.: gli esempi sono indipendenti e vengono tutti dalla stessa distribuzione. Su una serie storica sono false entrambe, e non per un dettaglio: per costruzione. Le vendite di marzo somigliano a quelle di febbraio (non indipendenti). Il mercato del 2019 non è quello del 2024 (non identicamente distribuite). Applicare gli strumenti standard senza accorgersene è il motivo per cui tanti progetti di forecasting hanno metriche splendide e risultati nulli.

Le quattro strutture con cui devi fare i conti, in ordine di quanto contano nei dati aziendali veri:

La regola d'oro del backtest. Valutare un modello temporale ha un solo modo corretto, e si chiama walk-forward (o origine mobile): ti metti in un istante t del passato, fingi di non sapere nulla dopo t, prevedi, avanzi, ripeti. Ti stai rigiocando la storia come si è vissuta, non come si legge oggi. Aggiungi, se sei serio, un intervallo di guardia tra fine training e inizio test (embargo), perché anche l'ultimo dato di training «tocca» il primo di test attraverso l'autocorrelazione.

C'è poi un pezzo di onestà intellettuale che pochissimi mettono in pratica, e che ti consiglio di pretendere: l'orizzonte di valutazione deve essere l'orizzonte della decisione. Se ordini con sei settimane di anticipo, non ti serve sapere l'errore a una settimana: quello è bellissimo e inutile. Ti serve l'errore a sei settimane, misurato prevedendo a sei settimane, ogni settimana, per due anni. È molto meno lusinghiero. Ed è l'unico numero che descrive quello che ti succederà davvero.

Un backtest è un esperimento di storia controfattuale. Se in quell'esperimento ti lasci sfuggire una sola informazione dal futuro, non stai misurando un modello: stai misurando la tua distrazione.

Nel 1961 Edward Lorenz stava rifacendo girare una simulazione meteorologica. Per risparmiare tempo la riprese da metà, digitando i numeri dal tabulato: 0,506 invece di 0,506127. Una differenza di una parte su diecimila, molto più piccola di qualunque errore di misura reale. La simulazione, dopo poco, produsse un meteo completamente diverso. Non un po' diverso: un altro. Lorenz aveva appena scoperto, per sbaglio, la proprietà che governa il confine di tutta questa disciplina.

I sistemi caotici sono perfettamente deterministici (le equazioni sono note, non c'è nessun caso dentro) eppure restano impredicibili oltre un certo orizzonte. Le due cose convivono benissimo, e il motivo è che gli errori non restano piccoli, crescono in modo esponenziale.

E allora perché il meteo funziona? Perché ha fatto una cosa intelligentissima: ha smesso di prevedere il futuro e ha iniziato a prevederne la distribuzione. L'ECMWF non gira un modello: ne gira cinquantuno, ognuno con perturbazioni diverse delle condizioni iniziali e della fisica. Se i cinquantuno restano vicini, la previsione è affidabile e te lo dicono. Se si sparpagliano, è incerta e te lo dicono lo stesso: quel «70%» è un'informazione misurata e verificabile, altro che scusa preventiva. Le previsioni meteo sono, e lo dico con invidia professionale, il sistema previsionale meglio calibrato e più onestamente valutato che l'umanità abbia costruito: la previsione a 5 giorni di oggi è accurata come quella a 1 giorno degli anni Ottanta, e ogni singola previsione emessa viene verificata contro l'osservato. Nessun reparto commerciale che conosco fa nulla di lontanamente simile.

Cosa c'entra con te. Tutto. Anche la tua domanda commerciale è un sistema con un λ, solo che non l'hai mai stimato. Il modo per stimarlo empiricamente è alla portata di chiunque abbia due anni di storico: fai walk-forward e traccia l'errore in funzione dell'orizzonte. Vedrai una curva che sale e poi si appiattisce su un plateau. Quel plateau è l'errore che avresti indovinando la media: è il punto in cui il tuo modello ha smesso di sapere qualcosa. Se sta a otto settimane, prevedere a sei mesi è un esercizio di scrittura creativa, e nessun fornitore, nessun budget, nessun LLM sposterà quel punto, perché non è una proprietà del modello. È una proprietà del tuo mercato.

Il pregio di conoscere il proprio orizzonte non è la rassegnazione. È che sotto quel numero puoi finalmente investire con criterio, e sopra puoi smettere di buttare soldi.

Questa distinzione è la più elegante del campo e quasi nessuno la fa. Il meteo è un sistema caotico ma indifferente: puoi prevederlo quanto ti pare, all'atmosfera non interessa e non cambia comportamento. Il mercato è un sistema riflessivo: se scopri un modo affidabile di prevederlo, lo usi; usandolo, compri; comprando, muovi il prezzo; muovendo il prezzo, distruggi il pattern che avevi trovato. La prevedibilità dei mercati si autodivora. Siamo davanti a un punto fisso economico, e la tecnica non c'entra.

Da qui l'ipotesi dei mercati efficienti nella sua forma utile (non quella da manuale): tutta l'informazione pubblicamente disponibile è già dentro il prezzo, perché migliaia di persone molto attrezzate sono pagate per metterla lì entro pochi millisecondi. Ne segue che la variazione futura del prezzo è, in prima approssimazione, imprevedibile: assomiglia a una passeggiata aleatoria. Non perché sia casuale in senso metafisico, ma perché tutto ciò che era prevedibile è già stato prevenuto.

E qui c'è la trappola cognitiva più costosa che esista, e voglio fartela sentire addosso invece che raccontartela. Sotto ci sono sei grafici. Tre sono andamenti reali di un titolo, tre sono rumore puro generato adesso dal tuo browser con un generatore di numeri casuali. Prova a distinguerli. Prenditi il tempo che vuoi: ci vedrai testa-e-spalle, supporti, breakout, trend. Il tuo cervello è una macchina straordinaria per trovare pattern, ed è tarata per trovarne anche dove non ce n'è nessuno, perché per centomila anni scambiare un cespuglio per una tigre è costato molto meno che il contrario.

Adesso la parte che ribalta il capitolo, e che rende questo tema molto meno nichilista di come lo si racconta. Dire «la borsa è imprevedibile» è impreciso in un modo importante. Non è prevedibile il livello. È prevedibilissima la volatilità. Se ieri il mercato ha sbandato, oggi sbanderà: i periodi turbolenti si raggruppano, i periodi calmi anche. Questo fatto, il volatility clustering, è stabile e misurabile, e si modella con i GARCH. È valso il Nobel a Engle nel 2003, e su di esso è costruita l'intera industria della gestione del rischio e delle opzioni. Quindi: non sai se il prezzo salirà, ma sai quanto sarà mosso il mare. E il secondo dato, per chi deve dimensionare un rischio, vale più del primo.

La lezione generale, quella che porto fuori dalla finanza e uso ovunque, è questa: quando la media è imprevedibile, spesso la dispersione non lo è. È esattamente ciò che serve per decidere. Un magazzino non ha bisogno di sapere la domanda esatta: ha bisogno di sapere quanto può sbagliare. Un piano di assunzioni non ha bisogno del fatturato preciso: ha bisogno dello scenario cattivo. Le domande sulla distribuzione hanno risposta molto più spesso delle domande sul numero, e sono anche quelle che servono davvero.

Chiudo con il criterio da mettere in tasca. Prima di iniziare qualunque progetto previsionale, chiediti dove sta il tuo fenomeno tra questi tre: indifferente (guasti di macchinari, consumi, meteo, dove nessuno reagisce alle tue previsioni, quindi prevedibile fino al suo λ); debolmente riflessivo (domanda commerciale: le tue previsioni muovono i tuoi ordini, i tuoi ordini muovono un po' il mercato, e la promozione che fai perché prevedi poco vende cambia quanto venderai); fortemente riflessivo (mercati finanziari, aste competitive: chiunque scopra qualcosa lo cancella usandolo). Sono tre mestieri con tre aspettative diverse. Prometterne uno mentre se ne fa un altro è, nella mia esperienza, il modo più comune di essere in perfetta buona fede e completamente fuori strada.

«A marzo venderemo 1.240 pezzi.» Falso, garantito: non ne venderai 1.240. La previsione utile è un'altra: «a marzo venderemo tra 980 e 1.520 con probabilità 80%, e la mediana è 1.240». La seconda contiene la prima e in più contiene tutto quello che serve per decidere: quanto scorta tenere, quanto rischio corri, quando alzare la mano. La prima è un numero da mettere in una slide.

E c'è un motivo tecnico, non estetico, per cui il numero singolo è pericoloso. Se il tuo modello minimizza l'errore quadratico, quello che ti restituisce è la media condizionata. La media, su una distribuzione asimmetrica come sono quasi tutte le domande commerciali (limitate a zero sotto, con una coda lunga sopra), è una quantità che non descrive nessuno scenario realmente probabile. È il valore atteso di una lotteria, non l'esito della lotteria. Nessuno ordina «il valore atteso» di pezzi.

Gli strumenti, in ordine di quanto li uso.

• Quantile regression (la pinball qui sopra): semplice, diretta, funziona con qualunque boosting.
• Conformal prediction, la cosa più elegante degli ultimi anni. Prendi il tuo modello, qualunque esso sia, guardi come ha sbagliato su un pezzo di dati che non ha mai visto, e ne ricavi un intervallo con una garanzia di copertura dimostrata, senza ipotesi sulla distribuzione. Funziona anche sopra un LLM, e nel capitolo 21 fa da spina dorsale al guardrail.
• Ensemble. Fai girare più modelli: il loro disaccordo è una misura d'incertezza gratuita. È il meteo del capitolo 10.
• Simulazione. Quando la decisione è complicata, campiona mille futuri e valuta la decisione su tutti.

Un cenno alla metrica giusta, perché è la domanda che ricevo sempre dopo. Per valutare una previsione a distribuzione non usi MAE o RMSE: sono metriche per numeri singoli. Usi CRPS (Continuous Ranked Probability Score) o la pinball media. Hanno una proprietà che si chiama propriety: sono costruite in modo che il modo migliore per prendere un buon punteggio sia dire onestamente cosa credi. Non esiste una strategia furba per barare. È una proprietà matematica di cui avrei voluto una versione anche per le riunioni.

La domanda che separa un fornitore serio da un venditore è una sola, e dura cinque secondi: «la vostra banda all'80%, negli ultimi due anni di backtest, ha coperto l'80% dei casi? Fatemi vedere il conteggio.» Non l'ho mai vista fare. Non ho mai visto neanche una risposta pronta.

Rispondo alla domanda del titolo con la massima onestà possibile, distinguendo, perché «funzionano» in blocco non vuol dire niente. Sì, funzionano, e in modo molto solido, dove il fenomeno è indifferente e ha inerzia: consumi, carichi, guasti, traffico, domanda aggregata, code, assenze. Qui il ML batte l'intuizione umana in modo sistematico e i benefici sono documentati da decenni. Funzionano a metà dove il fenomeno è debolmente riflessivo e l'orizzonte è lungo: la domanda del singolo articolo a sei mesi è un esercizio di modestia. Non funzionano, e chi dice il contrario ti sta vendendo qualcosa, dove il sistema è fortemente riflessivo o dove l'evento che conta è una rottura che per definizione non è nei dati.

Ma la vera risposta è che stiamo misurando la cosa sbagliata. L'accuratezza è una metrica di comodo dei tecnici. Il metro vero è: quanto è migliorata la decisione. E il modo per vederlo in un secondo è il problema più bello della ricerca operativa, che ha oltre sessant'anni e che continua a risolvere l'80% dei casi reali.

Il valore di un progetto previsionale non si misura in punti di MAPE. Si misura in euro di decisione, e le due cose, sorprendentemente spesso, non si muovono nella stessa direzione.

Questo apre una linea di ricerca che è anche il mio consiglio architetturale più forte di tutta la parte quarta. Il modo classico si chiama predict-then-optimize: prima il modello prevede il meglio che può, poi un secondo pezzo di software decide. Ma il modello sta ottimizzando la sua metrica, non il tuo conto economico, e non ha nessuna idea di quali errori ti fanno male. L'alternativa, il decision-focused learning, è addestrare il modello direttamente sul costo della decisione a valle. Non è sempre facile, ma la sua versione povera è alla portata di tutti ed è quella che implemento nel 90% dei casi: metti la pinball loss con il τ che esce dal newsvendor. Sono due righe. Il modello smette di inseguire la media e comincia a inseguire i tuoi soldi.

E c'è un effetto collaterale, sul quale ho visto sbloccarsi progetti fermi da mesi. Nel momento in cui chiedi a un'azienda «quanto costa averne troppo pochi rispetto a troppi?», scopri quasi sempre due cose. Primo: nessuno l'ha mai quantificato. Secondo: quando finalmente lo quantificano, si accorgono che la politica di scorte in vigore da dieci anni corrisponde a un rapporto di costi che nessuno sceglierebbe consapevolmente. La domanda è arrivata con l'AI, ma la risposta non aveva bisogno di AI. È il caso più frequente in cui porto valore prima ancora di scrivere una riga di codice, e no, non lo dico per modestia: lo dico perché è il motivo per cui poi il codice lo scrivono con me.

Se il capitolo 13 ti ha convinto che il punto è la decisione, questo è il capitolo su come si prende quando le opzioni sono miliardi. Trenta consegne da mettere in sequenza sono 30! percorsi possibili: un numero con 33 cifre. Provarli tutti è fuori discussione per l'universo, non per il tuo server. Eppure un solver ti dà l'ottimo, o qualcosa di dimostrabilmente vicino, in pochi secondi. Non con l'AI: con la ricerca operativa, che è tecnologia degli anni Cinquanta e continua ad essere la macchina che genera più margine e meno titoli sui giornali.

L'architettura che propongo, e il motivo per cui la propongo. Nei sistemi che costruisco l'anello è sempre lo stesso, e le responsabilità sono rigidamente separate: previsione → decisione → azione → misura → di nuovo previsione. Il modello previsionale non decide mai e non sa nulla dei vincoli. L'ottimizzatore non prevede mai e non sa nulla di statistica: prende in ingresso una distribuzione e dei vincoli e restituisce una scelta. Sembra pignoleria architetturale ed è invece l'unica cosa che rende il sistema manutenibile: quando qualcosa va storto, e andrà storto, devi poter dire in quale dei due pezzi è successo. Nei sistemi dove i due pezzi sono impastati (tipicamente: regole di business dentro il modello, o soglie apprese dentro il solver) non l'ho mai potuto dire, e la diagnosi è diventata archeologia.

Il pezzo più difficile, però, non è nessuno dei due. Sono i vincoli veri. Il solver ti darà sempre una risposta ottima rispetto ai vincoli che gli hai scritto, e quelli che ti hanno raccontato in riunione non sono mai tutti. Il giro di consegne perfetto che passa dal cliente Rossi alle 14 è ottimo finché non scopri che Rossi chiude dalle 13 alle 15, cosa che sanno tutti gli autisti e nessun sistema. L'ottimizzazione fallisce quasi sempre per antropologia, non per matematica: il vincolo mancante è quasi sempre una cosa che «si è sempre saputa». Il mio metodo, banale e infallibile: prima di scrivere il modello, fai girare il piano ottimo a chi fa il lavoro e chiedigli di dirti tutti i motivi per cui è una schifezza. Ogni obiezione è un vincolo che non avevi.

Un ottimizzatore senza i vincoli veri non produce piani sbagliati. Produce piani perfetti che nessuno eseguirà, ed è molto peggio, perché sembrano funzionare.

Questo è il capitolo che quasi nessuno scrive, ed è quello che spiega perché tanti sistemi che funzionavano al primo anno diventano lentamente insensati al terzo. Un modello messo in produzione non è un osservatore. È un attore. E gli attori inquinano il palco che osservano.

Il caso di scuola, che ho visto succedere per davvero. Prevedi che il prodotto X venderà poco. Di conseguenza ne ordini poco. Di conseguenza sullo scaffale ce n'è poco e a volte manca. Di conseguenza vende poco. Il tuo storico ora conferma la previsione, il modello si riaddestra e diventa ancora più convinto. Il ciclo si chiude e il prodotto muore. Non perché non piacesse: perché il modello ha smesso di misurare la domanda e ha iniziato a misurare le proprie decisioni. Il dato che ti serviva, quanto avresti venduto se ce ne fosse stato, non esiste in nessun database del mondo, ed è la censura più costosa e più ignorata di tutta la gestione scorte.

Come ci si difende. Quattro mosse, tutte poco costose e quasi mai fatte.

1. Registra cosa ha deciso il sistema e perché, non solo cosa è successo. Senza il log delle decisioni non potrai mai separare i tuoi effetti da quelli del mondo.
2. Modella la censura invece di ignorarla. I dati censurati hanno una loro statistica, con più di un secolo di letteratura, e in azienda non la usa nessuno.
3. Mantieni una quota di esplorazione: una piccola percentuale di scelte deliberatamente non ottime. È il prezzo, bassissimo, per continuare ad avere dati onesti.
4. Tieni un gruppo di controllo, se puoi: un pugno di negozi, clienti o articoli dove il sistema non decide. È l'unico modo di sapere se serve davvero, e l'unica difesa contro la domanda che prima o poi arriva dal consiglio: «ma questo affare, quanto ci ha fatto guadagnare?». Senza controllo, quella domanda ha solo risposte aneddotiche.

Un modello in produzione non descrive il mondo: negozia con lui. Chi progetta senza tenerne conto costruisce sistemi che, col tempo, misurano soltanto se stessi.

Il capitolo 01 ti ha dato la tassonomia teorica: come impara una macchina. Questo capitolo ti dà l'atlante operativo: cosa esiste sul mercato, cosa fa, quanto costa e, soprattutto, dove mente. Quella colonna non la scrive mai nessuno. È la tabella che apro davanti al cliente alla prima riunione, e serve a fare una cosa sola: smettere di discutere di «AI» e cominciare a discutere di quale casella.

Le prime due righe si prendono il 95% delle conversazioni. Le ultime sei si prendono, nella mia esperienza, più della metà del valore.

Guarda la colonna dei costi, perché racconta una storia che nessuno racconta. Le due famiglie più economiche, ML classico e statistica, sono anche le due che risolvono la maggior parte dei problemi aziendali. La famiglia di gran lunga più costosa per volume, gli LLM, è quella su cui si concentra il 95% dell'entusiasmo. Di per sé va benissimo. Diventa un problema quando si usa la famiglia costosa per fare il lavoro di quella gratis. Nel capitolo 30 ti faccio vedere quanto costa esattamente quell'errore, con il calcolatore.

Quando un'azienda mi dice «vorremmo usare l'AI sui nostri dati», quello che sta cercando è quasi sempre una di queste ventidue caselle. Il catalogo qui sotto è filtrabile in due modi che corrispondono alle due domande giuste: «con che tecnologia si fa?» e «che tipo di domanda sto facendo?», che è la scala descrittiva → diagnostica → predittiva → prescrittiva del capitolo che segue.

Ogni scheda dice cosa fa, con cosa si fa e qual è il suo limite onesto: la cosa che quell'analisi non fa, e che le viene attribuita lo stesso. È la riga che rende questo catalogo diverso da tutti gli altri.

Ogni consulenza al mondo ti fa vedere questa piramide: cosa è successo → perché → cosa succederà → cosa fare, con una freccia che sale verso il «valore». Il disegno è utile e la retorica che gli hanno costruito sopra è, nella mia esperienza, attivamente dannosa. Ti spiego perché, gradino per gradino, e poi ti do la versione che uso io.

La piramide suggerisce di salire. La realtà è che ogni gradino ha il suo pavimento, e che il gradino più alto poggia su un gradino diagnostico che quasi nessuno ha costruito davvero.

La versione che uso io. È un anello, e si percorre al contrario. Parti dalla decisione (gradino 4): cosa deve cambiare, chi decide, cosa costa sbagliare da ciascun lato. Da lì scendi a cosa serve prevedere (gradino 3): spesso scopri che serve un quantile, non un numero, e a volte che non serve prevedere affatto. Da lì scendi a cosa devi capire (gradino 2), e qui, se la decisione è «quale leva tiro», ti serve causalità, non correlazione. E solo alla fine scendi a cosa devi misurare (gradino 1), e scopri che metà dei dati che servono non li stai raccogliendo.

Percorrere l'anello al contrario ha un effetto collaterale che vale da solo la fatica: ti dice cosa non costruire. Il cruscotto con quarantadue indicatori che nessuno guarda è quello che si ottiene partendo dal gradino 1 e sperando che salendo si trovi il valore. Non si trova: si trova solo altro cruscotto.

Le domande che ogni direzione fa, e che sono tutte la stessa domanda: la campagna ha aumentato le vendite? Lo sconto ha portato ordini aggiuntivi o ha solo bruciato margine? Il nuovo processo ha ridotto i tempi? Il corso ha migliorato le prestazioni? Cambiare venditore ha ridotto l'abbandono?

Sembrano domande da dati. Non lo sono, e questo è il punto più difficile e più importante di tutta la risorsa: i dati osservativi non contengono l'informazione necessaria per rispondere. Non «non ne contengono abbastanza»: non ne contengono affatto. La ragione è che per sapere se la campagna ha funzionato bisognerebbe sapere cosa sarebbe successo senza la campagna, sugli stessi clienti, nello stesso periodo. Quel dato non esiste. Non è mai esistito. È un universo parallelo, e nessun modello lo ricostruisce dal nulla.

Ecco perché ogni analisi causale seria consiste in un solo gesto: fabbricare un pezzo di quell'universo parallelo. Un gruppo di controllo, un esperimento A/B, un confronto tra chi è stato appena sopra e appena sotto una soglia arbitraria, due regioni gemelle di cui una sola riceve la campagna. Qui serve disegno, più che statistica avanzata. E si decide prima, non dopo.

Il paradosso di Simpson non è una curiosità da manuale. È il motivo per cui due persone oneste, guardando lo stesso cruscotto, arrivano a due conclusioni opposte, e hanno ragione entrambe.

Gli strumenti, in ordine di forza.

1. Test A/B randomizzato. Il re. Assegni a caso, e il caso rende i due gruppi identici in media su tutto: comprese le cose che non hai misurato e quelle che non ti sono venute in mente. È l'unica tecnica che regge davanti a un fattore confondente che non conosci. Costa poco e quasi nessuno lo fa, perché richiede di rinunciare deliberatamente a trattare un gruppo.
2. Difference-in-differences. Due gruppi, prima e dopo. Guardi se il trattato devia dalla traiettoria del non trattato.
3. Regression discontinuity. Se una soglia arbitraria decide chi riceve cosa (sconto sopra 10.000 €), chi sta a 9.990 e chi a 10.010 sono quasi gemelli, e lì l'effetto si misura.
4. Controlli sintetici. Costruisci il gemello mancante combinando altri.

E poi la cosa che dico sempre e che nessuno vuole sentire: se non hai un gruppo di controllo, non stai misurando l'effetto. Stai raccontando una storia coerente con i dati, e i dati sono compatibili con moltissime storie, comprese quelle in cui il tuo lavoro non è servito a niente. Non lo dico per pessimismo. È la ragione per cui insisto perché in ogni sistema che costruisco resti fuori una quota di clienti, negozi o articoli che il sistema non tocca. Costa una percentuale di efficienza. Compra l'unica risposta possibile alla domanda «ma questo affare, quanto ci ha fatto guadagnare?»: la domanda che, prima o poi, arriva sempre.

L'anomaly detection è ovunque: vendite improvvisamente strane, consumi insoliti, ordini sospetti, errori di produzione, accessi potenzialmente fraudolenti, picchi di reclami, agenti con comportamenti inconsueti, sensori che iniziano a dare valori bizzarri. Ha un pregio enorme rispetto a tutto il resto di questa risorsa: funziona anche senza sapere in anticipo cosa stai cercando. Non ti serve uno storico di frodi etichettate: ti serve sapere com'è fatto il normale, e segnalare ciò che non gli somiglia.

E ha un difetto che non è tecnico ma matematico, che nessun fornitore ti spiega, e che uccide più progetti di qualunque bug. Si chiama base rate fallacy, e si vede meglio con i numeri che con le parole.

Come si progetta un sistema di anomalie che sopravvive.

1. Non chiedere «è un'anomalia?», chiedi «vale la pena guardarla?». La domanda giusta è economica prima che statistica: un'anomalia da 12 euro è vera e inutile. Ordina per impatto atteso (probabilità × valore), non per stranezza.
2. Dai all'operatore un budget, non una lista. Se può controllare venti casi al giorno, il sistema deve produrre i migliori venti, non trecento ordinati per punteggio. È un problema di ottimizzazione (cap. 14) travestito da rilevamento.
3. Chiudi l'anello. Ogni allarme controllato è un'etichetta gratis: dopo sei mesi hai un dataset supervisionato e puoi passare dal «cosa è strano» al «cosa è frode», che è un mestiere diverso e molto migliore. Chi non registra l'esito dei controlli butta via l'unico dato che il sistema stava producendo.

Una regola che non tratto: un sistema di anomalie non si dimensiona sulla statistica. Si dimensiona su quante persone hai per guardare gli allarmi.

Le domande che arrivano sempre in consiglio: e se aumentiamo i prezzi del 5%? E se perdiamo un fornitore? E se apriamo un nuovo magazzino? Se assumiamo altri agenti? Se cambiamo le scorte minime? Se la domanda cresce o crolla? Se dimezziamo i tempi di consegna? Nessuna di queste ha dati storici: sono mondi che non sono mai accaduti. Il machine learning qui non ha niente da masticare: impara dal passato, e il passato non contiene questi scenari.

La risposta è più vecchia dell'AI e la usano da ottant'anni: costruisci un modellino del mondo, buttaci dentro il caso, e falla girare diecimila volte. Monte Carlo: nasce a Los Alamos nel 1946 con Ulam e von Neumann, e prende il nome dal casinò. L'idea è di una semplicità imbarazzante: se non sai calcolare la distribuzione del risultato, campionala. Simula un futuro con valori estratti a caso dalle distribuzioni che conosci, segna il risultato, e ripeti diecimila volte. Alla fine non hai una previsione: hai l'intera distribuzione degli esiti, cioè esattamente ciò che serve per decidere (cap. 12).

Il pregio decisivo rispetto a tutto il resto della risorsa: non serve storico, serve capire come funziona il tuo sistema. Le ipotesi le metti tu, e sono discutibili, che è un enorme vantaggio: si può litigare su un'ipotesi, non si può litigare con una rete neurale.

La famiglia completa.

• Monte Carlo. Quando conosci le distribuzioni delle grandezze in gioco.
• Modelli ad agenti. Quando il risultato emerge dall'interazione di tanti attori con regole semplici: code, contagi, mercati, folle. Non calcoli l'esito, lo fai succedere.
• Digital twin. La copia software di un impianto fisico, alimentata dai sensori reali, su cui provi le modifiche prima di farle sul ferro.
• Analisi di sensibilità. La variante più economica e più sottovalutata: muovi un'ipotesi alla volta e guarda quanto trema il risultato. Ti dice dove concentrare gli sforzi. Se il margine è sensibilissimo all'elasticità e insensibile al costo del trasporto, sai su quale delle due vale la pena litigare.

Una simulazione non predice il futuro. Ti restituisce, in forma leggibile, le conseguenze delle cose che credi già: comprese quelle che non sapevi di credere.

Ed è anche il limite, che va detto forte perché la bellezza dei grafici è ipnotica: garbage in, gospel out. Il modello ti dà le tue ipotesi, ma vestite da risultato, con tanto di percentili e istogramma. Le difese sono due, entrambe banali e quasi mai applicate. Primo: scrivi le ipotesi accanto al risultato, sempre e in chiaro. Quel «−0,8 / −2,0 di elasticità» sembra un dettaglio tecnico, e invece è la conclusione. Secondo: fai l'analisi di sensibilità prima di presentare. Se il risultato ribalta il segno quando muovi un'ipotesi che nessuno sa stimare, non hai una risposta: hai scoperto quale numero l'azienda deve andare a misurare. Che è comunque un ottimo risultato, solo diverso da quello che cercavi.

Questo capitolo esiste perché ho una regola personale, e la applico anche ai clienti: non bruciare soldi. È sorprendentemente facile violarla proprio mentre si cerca di ottimizzare: mettere un modello linguistico dove bastava una query, e scoprirlo a fine trimestre. Quindi facciamo i conti, con i numeri veri e la struttura vera dei costi, che è profondamente diversa tra le due famiglie.

Il ML classico ha costi a scalino. Sviluppo: settimane di persona, il grosso della spesa, una volta sola. Addestramento: da secondi a ore su una macchina normale. Un gradient boosting su centomila righe e cinquanta colonne si allena in un minuto sul tuo portatile. Inferenza: microsecondi, praticamente gratis. Fare una previsione o farne dieci milioni cambia la bolletta di pochi centesimi. Il costo ricorrente è l'infrastruttura (pochi euro al mese) e il presidio: qualcuno che guardi il drift, che è la voce vera e quella che nessuno mette a budget.

L'LLM ha costi lineari. Sviluppo: giorni invece di settimane, perché scrivi un prompt e non addestri nulla. È il suo vantaggio reale. Addestramento: zero. Inferenza: paghi ogni singola volta, per sempre, a token. È un costo variabile puro, e sui volumi aziendali il variabile puro è quello che ti sorprende. Il calcolatore qui sotto usa i listini reali di luglio 2026 (Anthropic, dollari per milione di token): Opus 4.8 $5 in ingresso / $25 in uscita; Sonnet 5 $3/$15; Haiku 4.5 $1/$5. Le due leve serie: la cache del prompt (le parti che si ripetono identiche costano circa un decimo in lettura) e le chiamate a lotti (metà prezzo se accetti di aspettare ore invece di secondi).

La domanda non è «quanto costa un'analisi». È: quante ne farò al mese, per quanti mesi, e cosa succede quando il volume decuplica?

Le cinque regole che applico, e che valgono più di qualunque negoziazione sul listino.

1. Usa l'LLM una volta sola per record, mai dentro un ciclo. Il pattern «per ogni riga chiedo al modello» è quello che porta i conti a quattro zeri. Quasi sempre puoi chiedere al modello di scrivere il codice che elabora tutte le righe (cap. 22), e pagare una chiamata invece di cinquantamila.
2. Metti in cache tutto ciò che si ripete: il prompt di sistema, gli esempi, lo schema. Il calcolatore te lo fa vedere: con l'80% del prompt in cache il conto crolla, e la qualità non peggiora di una virgola.
3. Usa il modello più piccolo che regge il compito. Classificare un ticket in cinque categorie non richiede il modello di punta. Misura, non tifare.
4. A lotti tutto ciò che non è interattivo. Metà prezzo per una cosa che nessuno stava aspettando.
5. Distilla. È la più importante. Fai etichettare all'LLM diecimila esempi una volta sola (costo: una tantum), allena su quelle etichette un classificatore da quattro soldi, e mandalo in produzione. Paghi l'intelligenza una volta e la usi per sempre. È il trucco che ho visto abbattere di più i costi ricorrenti, e quasi nessuno lo usa perché è meno divertente che chiamare l'API.

E il costo che non è in nessun listino: la latenza. Un boosting risponde in venti millisecondi, un LLM in due o tre secondi. Se l'analisi sta dentro una schermata che un operatore usa duecento volte al giorno, quei tre secondi sono dieci minuti al giorno per persona, che nel conto economico pesano più della bolletta dell'API. Il costo di un sistema è il suo prezzo più il tempo che ruba a chi lo usa.

Se hai letto fin qui hai visto otto famiglie e venti analisi, ognuna con il suo limite. La conclusione operativa è una sola, e la vedo confermata in ogni progetto: un sistema reale ne usa quattro o cinque insieme, ciascuna nel punto in cui è imbattibile, e nessuna fuori dal suo mestiere.

Ecco un sistema che ho in testa quando parlo con una rete vendita. L'ho vista prendere questa forma in ogni progetto che è sopravvissuto.

Le tre regole del montaggio, le stesse in ogni sistema che ho costruito.

1. Ogni pezzo fa un mestiere solo. Quando qualcosa va storto, e andrà storto, devi poter dire quale pezzo ha sbagliato. Nei sistemi impastati la diagnosi diventa archeologia.
2. I numeri non passano mai per la bocca del modello linguistico (cap. 21). L'LLM può chiedere, spiegare, contestualizzare. Calcolare no.
3. L'anello si chiude. Cosa ha deciso il sistema, cosa è successo, e la quota che il sistema non tocca per poterlo sapere (cap. 15 e 26). Un sistema che non misura sé stesso è un'opinione che gira in produzione.

Non esiste il progetto AI. Esiste un problema, tagliato nei pezzi giusti, e per ogni pezzo lo strumento più economico che lo risolve. Spesso il più economico è anche il più vecchio.

Faccio la traduzione, riga per riga, perché è l'esercizio più utile che conosco per capire se un progetto ha senso prima di iniziarlo.

Un sistema previsionale non vale per quanto azzecca. Vale per quante decisioni migliori ha reso possibili, e per quante volte ha avuto il coraggio di dire «non lo so».

Ogni domanda ha la trappola (la risposta che sembra giusta e che sento nel 90% dei casi) e la risposta da senior. Se ne reggi tredici su venti senza aprire, questa risorsa ti ha fatto il suo lavoro.

Se ti stai chiedendo chi ti ha scritto tutto questo: sono Matteo Migliore, ho fondato Sviluppatore Migliore e sono ventisei anni che costruisco sistemi in cui il software deve decidere qualcosa e poi risponderne. Le cose che hai letto qui non vengono solo dai paper. Vengono dalle volte in cui ho creduto a un 97% che era leakage, dalle previsioni che ho difeso troppo a lungo, e dalle riunioni in cui la domanda giusta («quanto costa sbagliare da quale lato?») ha risolto in venti minuti un problema su cui si lavorava da mesi.

Se leggendo hai avuto il sospetto che qualcosa di simile stia succedendo anche da te: un modello che nessuno guarda più, un piano a sei mesi su un fenomeno che non ha sei mesi di orizzonte, una previsione bellissima che non ha cambiato una sola decisione, o un entusiasmo per l'AI generativa senza che nessuno abbia chiesto quale dei tre progetti si sta comprando: è esattamente quello che vado a cercare quando entro in un'azienda. E di solito lo si vede in mezza giornata, guardando i dati veri: non serve un progetto per capire se un progetto ha senso.

Scrivimi su WhatsApp, risponde Silvia e fissiamo mezz'ora. Se non c'è niente da fare, te lo dico: è la cosa che mi fa risparmiare più tempo e a te più soldi.