Tre cose diverse. Una sola parola nel catalogo.

Serie «Capire l’IA», nota 3 di 12. Le prime due spiegavano che cos’è l’intelligenza artificiale e come lavora all’interno un modello linguistico. Questa esce dalla macchina ed entra nella sala riunioni.

Martedì, 9.30, la sala grande di un’azienda di logistica a Chiasso. Tre fornitori, tre presentazioni, una stessa parola sulle tre copertine. Il primo mostra un sistema che legge gli ordini dalla posta e li inserisce nel gestionale. Il secondo, un «robot» che copia dati da uno schermo all’altro senza che nessuno tocchi il mouse. Il terzo, un «agente» che risponde ai clienti da solo. Tutti e tre dicono intelligenza artificiale. Tutti e tre costano più del camion nuovo. E la titolare, che da trent’anni distingue in cinque minuti un buon trasportatore da uno cattivo, si rende conto di non sapere da dove cominciare a confrontare.

La scena è immaginaria. La confusione no. Nasce perché tre tecnologie con sessant’anni di distanza fra loro sono finite nella stessa parola, e perché a chi vende conviene che sia così. In questa nota le do le tre definizioni, un’immagine per non dimenticarle, un criterio per sapere quale le serve in ogni caso e le sette domande che uso per smontare una presentazione in mezz’ora. Alla fine, la prossima volta che qualcuno le dirà «questa è IA», saprà che cosa le sta dicendo esattamente. E che cosa no.

Il software segue regole. Il robot di processo imita le mani. Il modello prevede. Tutti e tre automatizzano, ma solo uno di loro può sbagliare con eleganza.

Primo: il software, ovvero le regole scritte.

Un programma classico è una ricetta. Qualcuno ha scritto, passo per passo, che cosa fare con ogni dato: se la fattura supera i 10’000 franchi, chiedi una seconda firma; se il cliente è in Italia, applica questa imposta; se il campo è vuoto, mostra un errore. Ogni regola l’ha pensata una persona e l’ha scritta un’altra, o la stessa. Il programma non capisce nulla. Esegue.

Questo ha una virtù enorme che di solito diamo per scontata: è deterministico. Con gli stessi dati in ingresso produce sempre la stessa uscita. Se fallisce, fallisce sempre allo stesso modo, e qualcuno può leggere la regola e correggerla. Il suo programma di contabilità, il suo sistema di prenotazioni e il foglio di calcolo con cui calcola i margini sono software in questo senso. Automatizzano da decenni, e bene. La maggior parte di ciò che un’azienda deve automatizzare resta, nel 2026, software di sempre. Conviene ricordarlo prima della seconda presentazione.

Il suo limite è altrettanto chiaro. Fa solo ciò che qualcuno ha saputo scrivere come regola. E ci sono cose che nessuno sa scrivere come regola: riconoscere che un’e-mail è un reclamo anche se non contiene la parola reclamo, riassumere un contratto, decidere quale ordine è urgente leggendo il tono del cliente. Lì il software classico si ferma.

Secondo: l’automazione robotica dei processi, ovvero le mani che imitano.

Alla fine degli anni 2000 comparve un’idea semplice e molto redditizia. Molte aziende hanno programmi che non si parlano fra loro: quello degli ordini non è collegato alla fatturazione, la banca non è collegata alla contabilità. Qualcuno, ogni mattina, copia dati da uno schermo all’altro. E se un programma imitasse quella persona? Apre l’applicazione, clicca dove clicca lei, copia quello che copia lei, incolla dove incolla lei. Lo si chiamò automazione robotica dei processi, RPA secondo la sigla inglese. Il «robot» non è una macchina: è un programma che muove il mouse e digita.

IBM la definisce con una distinzione che in riunione vale oro. La RPA è guidata dal processo: segue flussi definiti, passo per passo, e lavora con dati strutturati, quelli che stanno già in campi e colonne. L’intelligenza artificiale è guidata dai dati: impara schemi e può lavorare con dati non strutturati, come testo libero, immagini o voce. Sono complementari, dice IBM, ed è vero. Ma non sono la stessa cosa, e un robot di processo è, in fondo, software classico con un’interfaccia diversa: tanto deterministico e tanto cieco quanto qualsiasi ricetta.

L’immagine che uso è quella di una cucina. Il software è la ricetta. Il robot di processo è un aiutante che segue la ricetta alla lettera, apre i cassetti e preme i pulsanti del forno, ma non assaggia il sugo. È molto utile finché la cucina non cambia: se qualcuno sposta il cassetto dei coltelli, l’aiutante apre l’aria. Per questo i progetti di RPA si rompono ogni volta che un fornitore cambia il disegno di uno schermo. Se le hanno venduto un robot che «si adatta» ai cambiamenti degli schermi, chieda come. Quasi sempre la risposta è: con una persona che lo aggiusta.

Terzo: l’intelligenza artificiale, ovvero il cuoco che assaggia il sugo.

La terza tecnologia è quella che abbiamo spiegato nelle due note precedenti. Un modello addestrato con quantità enormi di esempi che, invece di seguire regole scritte, prevede: la parola successiva, la categoria di un’e-mail, il contenuto di un campo a partire da un PDF scansionato. Nessuno gli ha scritto la regola «questo è un reclamo». Ha visto milioni di reclami e ne riconosce uno nuovo anche se è scritto con cortesia svizzera.

In cucina, è il cuoco. Assaggia il sugo, nota che manca il sale e lo corregge. Può improvvisare con ciò che c’è in frigorifero. E può sbagliare: confondere lo zucchero con il sale con la stessa sicurezza con cui ci azzecca le altre volte. Questa è la differenza decisiva rispetto alle altre due tecnologie e la ragione di tutta questa serie. Il software e il robot falliscono in modo prevedibile. Il modello fallisce in modo plausibile. Una regola scritta male produce un errore visibile; un modello configurato male produce una risposta che sembra corretta.

Da qui nasce la domanda che più valore mi ha dato in riunione, e che le regalo: «Se lo eseguo due volte con gli stessi dati, esce esattamente la stessa cosa?» Se la risposta è sì, le stanno vendendo software o un robot di processo, per quanto la copertina dica IA. Se la risposta è «quasi», le stanno vendendo un modello, e da quel momento tutte le altre domande devono riguardare come si misura e come si controlla quel «quasi».

Quale le serve, e quando.

Non è una gara. Quasi tutti i buoni progetti che ho visto combinano i tre, e l’errore abituale è mettere un modello dove bastava una regola, o una regola dove serviva un modello. Il mio criterio sta in una tabella mentale con due domande: le regole sono chiare? e i dati sono ordinati?

• Regole chiare, dati ordinati. Software. Una formula, una validazione, un flusso di approvazione. È il più economico, il più affidabile e quello che richiede meno sorveglianza. Esempio: avvisare quando una fattura è scaduta da 30 giorni.
• Regole chiare, dati ordinati, programmi che non si parlano. Robot di processo, mentre si costruisce il collegamento vero. Esempio: passare ogni mattina i movimenti bancari nel programma di contabilità. Sappia che è una stampella, non una soluzione, e che si romperà al prossimo cambio di schermo.
• Regole sfumate o dati non strutturati. Modello di IA. Esempio: leggere le e-mail che arrivano a info@, decidere di che cosa trattano, estrarre l’ordine e proporre una risposta. Qui sì che c’è qualcosa che nessuna regola sapeva fare.
• Giudizio con conseguenze. Un modello che propone e una persona che decide. Esempio: classificare i reclami per gravità. La macchina ordina la casella; la decisione di risarcire la firma qualcuno.

Osservi che negli ultimi due casi il modello lavora raramente da solo. Di norma legge qualcosa di disordinato, lo trasforma in dati ordinati e li consegna al software di sempre, che da lì applica le regole. L’IA ordina; il software esegue; il robot, se serve, muove il mouse. Quando un fornitore le mostra un sistema, gli chieda di indicarle nello schema dove sta ciascuno dei tre pezzi. Se non lo sa, non l’ha costruito lui.

La parola più consumata del catalogo: agente.

Resta la quarta parola, quella della terza presentazione. Nel 2026 quasi tutto si chiama agente. Conviene sapere da dove viene e quanto c’è dietro.

Anthropic ha pubblicato nel dicembre 2024 una guida tecnica per chi costruisce questi sistemi, e vi traccia una linea che le servirà: un flusso di lavoro è un sistema in cui il modello e gli strumenti sono orchestrati lungo percorsi definiti in anticipo nel codice; un agente è un sistema in cui il modello decide da solo quali passi compiere e quali strumenti usare per svolgere un compito. La stessa guida aggiunge due consigli che un venditore ripete di rado: cercare sempre la soluzione più semplice possibile, e usare agenti solo per problemi aperti in cui non si può prevedere il numero di passi. Per quasi tutto il resto, dice, basta una sola chiamata al modello fatta bene. A questa distinzione dedico la nota 5.

Il mercato è andato da un’altra parte. Il 25 giugno 2025 Gartner ha pubblicato una previsione che dovrebbe essere appesa in tutti gli uffici acquisti: oltre il 40 % dei progetti di agenti di IA sarà cancellato entro la fine del 2027, per costi crescenti, valore poco chiaro o controlli del rischio insufficienti. Nella stessa nota ha coniato un termine, «agent washing», per descrivere la pratica di ribattezzare come agenti prodotti che non lo sono: assistenti, robot di processo, automazioni classiche con una mano di vernice nuova. Gartner stimava che, fra le migliaia di fornitori che dicevano di vendere agenti, solo circa 130 fossero reali. E in un sondaggio fra 3412 dirigenti, il 19 % aveva fatto investimenti importanti in agenti, il 42 % investimenti prudenti, l’8 % nessuno e il 31 % stava aspettando di vedere.

Non glielo racconto perché non compri agenti. Glieli spiegherò, e bene, fra due note. Glielo racconto perché, quando sentirà la parola, faccia la domanda di prima: i passi li decide il modello, o li ha decisi un programmatore? La maggior parte delle volte li ha decisi un programmatore, e questa è una buona notizia, perché è più economico, più prevedibile e più facile da controllare. È una cattiva notizia solo se l’ha pagato al prezzo di un’altra cosa.

Sette domande per mezz’ora.

Le faccio in quest’ordine, e la qualità delle risposte mi dice più della dimostrazione.

• Se lo eseguo due volte con gli stessi dati, esce la stessa cosa? Separa il software dal modello. È la prima perché cambia tutte le altre.
• Quale parte è modello, quale è regola e quale è robot? Chieda che glielo indichino in uno schema. Chi l’ha costruito lo sa a memoria.
• Quale modello, di chi e di quale versione? Se la risposta è «il nostro motore di IA», insista. Nel 2026 quasi nessuno addestra un proprio modello; quasi tutti usano quello di un grande fornitore. È legittimo, ma cambia chi controlla il prezzo e i cambiamenti.
• Con quali cinquanta casi miei lo misuriamo? Non con i suoi. Con cinquanta e-mail, fatture o chiamate reali della sua azienda, con la risposta corretta nota. Se non si può, non si può valutare.
• Che cosa succede quando non sa? La risposta buona è: lo dice e passa a una persona. Quella cattiva è: risponde sempre.
• Che cosa si rompe quando cambia qualcosa? Uno schermo, un formato di fattura, la versione del modello. Chi lo aggiusta, in quanto tempo e a che prezzo.
• Dove vanno i miei dati? A quale fornitore, in quale paese, se si usano per addestrare e come si cancellano. Lo tratteremo con calma nella nota su dati e legge, ma la domanda si fa nella prima riunione.

1. Questa settimana, 30 minuti

   Faccia l’inventario dei tre pezzi

   Elenchi i programmi che ha già e segni ciascuno: ricetta, aiutante o cuoco. Scoprirà che quasi tutto è ricetta, e che funziona.

2. Alla prossima presentazione

   Faccia la domanda delle due esecuzioni

   Prima di vedere la dimostrazione. Osservi se il venditore la capisce al primo colpo.

3. Prima di chiedere il prezzo

   Chieda lo schema con i tre pezzi indicati

   E che le dicano di chi è il modello e quale versione. Conservi la risposta per iscritto.

4. Prima di firmare

   Prepari i suoi cinquanta casi

   Reali, con la risposta corretta accanto. È il suo insieme d’oro, e serve a confrontare i tre fornitori con lo stesso metro.

Come la imposto io.

Nei miei progetti, la prima settimana non si scrive codice: si disegna lo schema con i tre pezzi. Quasi sempre c’è più ricetta di quanta il cliente si aspettasse e meno modello di quanto gli avessero venduto. Il modello si riserva a ciò che nessuna regola sa fare, si misura con i cinquanta casi prima di accenderlo e gli si dà il permesso di dire «non lo so». Il resto è software, e il software, quando è fatto bene, non ha bisogno di cognome.

Prima della prossima nota, pensi all’ultima proposta di «IA» arrivata sulla Sua scrivania. Cancelli mentalmente quella parola e si chieda che cosa resta: una regola che si potrebbe scrivere, un robot che imita i clic o un modello che deve davvero capire qualcosa?

Se non sa in quale delle tre caselle cadrebbe, non è un Suo difetto. È esattamente la domanda a cui la proposta avrebbe dovuto rispondere per Lei. E forse vale la pena chiedersi perché non l’ha fatto.

Prossima nota: la mappa. Che cosa sa fare oggi un modello linguistico dentro un’azienda, reparto per reparto, con ciò che gli studi hanno misurato davvero e ciò che è ancora promessa.