L'AI non salva un processo sbagliato. Farà solo la cosa sbagliata più in fretta e a costo minore.

Nelle riunioni di direzione si sente una frase che sembra una strategia ma non lo è: dobbiamo adottare l'AI. Si cerca un processo a cui collegare un modello, si sceglie un fornitore, si avvia un pilota. Sei mesi dopo l'azienda possiede una licenza e gli stessi numeri di prima.

Il motivo non sta nella debolezza dei modelli, ma nell'ordine delle mosse. La tecnologia è una risposta, non una domanda. La domanda è quale ostacolo impedisca al lavoro di attraversare l'azienda senza fermarsi. Se nessuno se la pone, l'AI si limita ad accelerare la forma di lavoro esistente, deformazioni comprese.

Automatizzare un processo inefficiente senza ridisegnarlo non è un miglioramento, è la cristallizzazione di un'architettura del lavoro sbagliata. La cosa sbagliata inizia ad accadere a costo minore e più in fretta, il che è peggio di quando accadeva cara e lenta. Almeno allora faceva abbastanza male da farsi notare.

La tecnologia non è una strategia

Michael Hammer ha scritto sulla Harvard Business Review nel 1990 una frase che non è invecchiata: gli ingenti investimenti in tecnologie informatiche hanno deluso soprattutto perché le aziende usano la tecnologia per meccanizzare vecchi modi di lavorare. Lasciano intatti i processi esistenti e si limitano ad accelerarli con i computer. La sua conclusione suonava così: smettete di asfaltare i sentieri delle mucche.

Erik Brynjolfsson e Lorin Hitt, in uno studio del 2000, sostengono che gli investimenti in computer senza cambiamento organizzativo possono provocare perdite di produttività rilevanti, perché le interazioni negative con le pratiche esistenti superano i benefici. Non un effetto nullo, un effetto negativo. Gli investimenti organizzativi complementari, cioè nuovi processi e nuove competenze, possono secondo loro essere circa dieci volte superiori all'investimento in tecnologia.

I dati più recenti raccontano una storia simile, ma vanno letti con cautela. Il report The GenAI Divide, pubblicato nel luglio 2025 dal progetto MIT NANDA, afferma che, a fronte di 30 o 40 miliardi di dollari investiti nell'AI generativa, il 95 percento delle organizzazioni non vede alcun ritorno e solo il 5 percento dei piloti genera valore nell'ordine dei milioni di dollari. Il documento poggia su 52 interviste e 153 questionari del primo semestre 2025, gli autori definiscono i risultati preliminari, ammettono un bias di selezione e non hanno pubblicato i dati sottostanti. È quindi un indizio, non una misurazione del mercato. Conta di più la loro spiegazione: i progetti non falliscono per la qualità dei modelli né per la regolamentazione, ma per la fragilità dei workflow e per il disallineamento rispetto all'operatività quotidiana.

Prima disegnate il flusso, poi l'architettura

Il process redesign, cioè la riprogettazione del modo di lavorare prima della scelta dello strumento, inizia in modo noioso: scomponete un singolo processo in quattro tipi di passaggi. L'input è lo stimolo o il dato che entra nel processo. La decisione è il punto in cui si sceglie tra alternative. L'azione cambia lo stato. L'output è ciò che esce dal processo e che qualcun altro utilizza. L'obiettivo è separare i passaggi che creano valore da quelli che si limitano a spostare informazioni.

Si mappa la realtà, non la procedura scritta. Il manager vi descrive il flusso approvato. La persona che il lavoro lo fa davvero vi mostra anche il foglio di calcolo che il team si è creato, perché il sistema ufficiale non basta. Quelle scorciatoie sono la mappa migliore degli errori di progettazione.

Che cosa cercare nel flusso

• Duplicazione. La stessa informazione viene inserita in più punti e ogni punto è una nuova occasione di discrepanza.
• Attesa. Il lavoro resta fermo e nessuno lo tocca. Di solito è la voce più pesante del tempo complessivo.
• Approvazione senza rischio. Una firma che non ha mai respinto nulla non è un controllo, è un rituale con un costo.
• Trasferimento manuale. Ricopiare dalla posta al foglio di calcolo, esportare e importare, copiare tra sistemi.
• Passaggi senza motivo. Il report che nessuno legge. La copia per il revisore che non la chiede più.

I rilievi si ordinano con la formula del Cost of Friction: tempo di una singola ripetizione per frequenza per numero di persone coinvolte per costo orario. Un passaggio che dura poco, ma che tutto il team ripete ogni giorno, costa spesso più di un grande progetto affrontato una volta l'anno. Perché la maggior parte delle aziende non ha bisogno di un altro strumento, ma di meno caos, lo abbiamo analizzato nell'articolo La vostra azienda non ha bisogno di più software. Ha bisogno di meno caos.

Il metodo: eliminare, semplificare, automatizzare, potenziare

L'ordine è volutamente rigido. Il passaggio successivo si può affrontare solo dopo aver completato il precedente, perché ognuno costa di più ed è meno reversibile.

Eliminare

La prima domanda non è come farlo più in fretta, ma se vada fatto. Un passaggio eliminato ha costo operativo nullo, tasso di errore nullo e manutenzione nulla. Chi lo salta automatizza un lavoro che non doveva esistere.

Semplificare

Ciò che resta va accorciato. Meno campi, meno stati, meno eccezioni, meno livelli di approvazione. La semplificazione riduce insieme costi, errori e tempi di formazione, senza una sola riga di codice. Chi la salta automatizza le eccezioni. E ogni eccezione richiede una regola dedicata, un test e manutenzione.

Automatizzare

Solo ora entra in gioco lo strumento. Si automatizza ciò che è ripetibile, univoco e frequente, e la maggior parte di questo livello non ha bisogno di AI. Saltarlo per passare direttamente al modello è un errore che vediamo di continuo nei brief. L'azienda mette un modello su un compito che una regola risolverebbe e paga per un'incertezza di cui non aveva bisogno.

Potenziare

L'ultimo livello non sostituisce la persona, ne amplia la portata. Qui rientrano la sintesi dei materiali, la prima bozza di un testo o la classificazione di dati non strutturati, cioè compiti privi di un'unica risposta corretta. Chi parte direttamente da qui ottiene una demo di effetto e nessun cambiamento nei numeri, cioè esattamente quel disallineamento con l'operatività descritto dal report del MIT.

La differenza tra automazione e ridisegno si vede nell'esempio di Ford citato da Hammer. All'inizio degli anni Ottanta il reparto contabilità fornitori del Nord America impiegava oltre 500 persone e il management si aspettava che i nuovi sistemi informatici riducessero l'organico di circa il 20 percento. Dopo il ridisegno, quando si è passati a confrontare tre dati invece di quattordici e la fattura del fornitore è stata eliminata del tutto, Ford ha ottenuto, là dove ha introdotto il nuovo processo, una riduzione dell'organico del 75 percento. Sono quelle percentuali a separare l'accelerazione di un vecchio flusso dalla progettazione di uno nuovo.

Quando basta una regola e quando serve un modello

L'automazione deterministica restituisce sempre lo stesso output a parità di input. Qui rientra la workflow automation: integrazione dei sistemi, condizioni, validazioni, generazione di documenti, notifiche. È economica, testabile e quando si rompe si rompe rumorosamente e in un punto noto. Il large language model, cioè il modello linguistico di grandi dimensioni, è probabilistico. Lo stesso input può produrre output diversi e il modello non dispone di un modo affidabile per ammettere di non sapere. In compenso gestisce il linguaggio e gli input non strutturati, cosa che una regola non sa fare.

Se la procedura si può scrivere con una frase del tipo quando accade A, fai B, usate una regola. Se il compito si può esprimere solo per esempi, il modello è al posto giusto. E se la regola si potrebbe scrivere, ma nessuno ha voglia di farlo, non è un argomento a favore dell'AI, è una decisione rinviata.

Secondo il benchmark TheAgentCompany, sviluppato da ricercatori della Carnegie Mellon University e costruito come simulazione dell'ambiente di una piccola software house, il miglior agente testato ha portato a termine in piena autonomia il 30 percento dei compiti. Si tratta di una simulazione e di un completamento del tutto autonomo, quindi il numero non dice quanto un agente riesca a fare con una persona a fianco. Una conclusione resta comunque valida: un agente messo su un processo disordinato non porterà a termine la maggior parte del lavoro.

Dove deve restare la persona

Lo human in the loop, cioè il coinvolgimento della persona nel ciclo decisionale, è un'idea corretta che viene spesso usata come alibi. Ben Green, in uno studio sottoposto a revisione paritaria, ha esaminato 41 normative che impongono la supervisione umana sugli algoritmi della pubblica amministrazione. Secondo i suoi risultati le persone non sono in grado di svolgere le funzioni di supervisione che ci si aspetta da loro e le politiche di supervisione finiscono quindi per legittimare l'adozione di strumenti difettosi.

Lo riconosce anche la regolamentazione europea. L'articolo 14 del regolamento sull'intelligenza artificiale richiede che i sistemi ad alto rischio siano progettati in modo da poter essere efficacemente supervisionati dalle persone e nomina esplicitamente l'automation bias, cioè la tendenza ad affidarsi automaticamente all'output del sistema. La parola chiave è progettati. La supervisione è un requisito di progetto, non una toppa applicata dopo l'avvio.

La persona deve quindi restare dove la decisione è irreversibile, dove comporta conseguenze legali o finanziarie e dove si tratta di un'eccezione fuori dai casi ordinari. Dove il controllo sarebbe soltanto formale, meglio non automatizzare affatto quel passaggio.

I rischi da risolvere prima dell'avvio

Allucinazioni. Una misurazione indipendente del team Stanford RegLab ha mostrato che strumenti legali specializzati con ricerca sui documenti hanno prodotto allucinazioni in una quota di casi compresa tra il 17 e il 33 percento, mentre il migliore tra quelli testati ha risposto correttamente al 65 percento delle domande. Il suo fornitore, nel frattempo, prometteva zero allucinazioni. Il dominio è la ricerca giuridica statunitense, quindi non trasferite i numeri in modo meccanico. Trasferibile è la conclusione: anche uno strumento appoggiato a una banca dati verificata sbaglia abbastanza spesso da rendere necessario un controllo dell'output. Secondo il lavoro Why Language Models Hallucinate, i cui autori provengono in maggioranza da OpenAI, non si tratta di un difetto che la prossima versione correggerà. I modelli tirano a indovinare perché il modo in cui vengono valutati premia il tentativo e punisce l'ammissione di incertezza.

Privacy e dati. La data governance, cioè le regole su quali dati entrano nel sistema e su chi ne risponde, non è un sovrappiù amministrativo. L'articolo 10 del regolamento sull'intelligenza artificiale richiede che i set di dati di addestramento, convalida e prova siano pertinenti, sufficientemente rappresentativi e, nella misura del possibile, privi di errori. Un modello messo su dati disordinati cristallizza il disordine e gli conferisce l'autorevolezza dell'output di una macchina.

Diritti di accesso. Un assistente che vede tutto ciò che vede il disco aziendale è una nuova superficie di fuga. I permessi impostati in modo permissivo vengono ereditati dal modello, che rende poi più semplice cercare in ciò che doveva restare separato.

Auditabilità. L'articolo 12 richiede che i sistemi ad alto rischio consentano tecnicamente la registrazione automatica degli eventi lungo l'intero ciclo di vita. La capacità di ricostruire a posteriori che cosa ha fatto il sistema e su quale base va progettata in anticipo. Su un processo già avviato non si può incollare.

Il quadro statunitense NIST AI RMF aggiunge un passaggio che è facile saltare: l'esito della mappatura dei rischi deve essere una decisione iniziale sull'opportunità stessa di costruire una soluzione basata sull'AI.

Un esempio modello: dalla richiesta all'offerta

Un'azienda ipotetica vende componenti su misura. Stato attuale:

1. La richiesta arriva su una casella di posta condivisa.
2. L'assistente la ricopia in un foglio di calcolo e apre una cartella sul disco.
3. Il commerciale scrive al tecnico per verificare se la specifica sia realizzabile.
4. Il tecnico risponde quando ha tempo.
5. Il commerciale compone l'offerta a mano e copia i prezzi dal listino.
6. Il responsabile approva l'offerta, praticamente sempre.
7. L'offerta entra nel CRM quando qualcuno se ne ricorda.

La soluzione ingenua suona così: mettere un modello linguistico a scrivere le offerte a partire dai messaggi di posta. L'azienda ottiene una produzione di documenti più rapida, ma l'attesa del tecnico, la doppia registrazione e l'approvazione vuota restano dove sono. Nasce una versione più veloce dello stesso disordine e una nuova categoria di errori che nessuno controlla.

Il ridisegno secondo il metodo ha un altro aspetto. Eliminare: si cancellano la ricopiatura nel foglio di calcolo e l'approvazione che non ha mai respinto nulla, sostituita da una soglia. Semplificare: la richiesta arriva tramite un modulo che chiede i parametri necessari alla valutazione, così nella maggior parte dei casi la domanda al tecnico non serve più. Automatizzare: il modulo crea in modo deterministico l'opportunità nel CRM, assegna il commerciale, compone l'offerta a partire dal listino e presidia le scadenze. Qui non serve alcun modello. Potenziare: solo per le richieste non standard il modello prepara una sintesi e una proposta di soluzione, che il tecnico conferma o riscrive.

Notate l'ordine. L'effetto maggiore è arrivato dai primi due passaggi, che non sono costati quasi nulla e non hanno richiesto AI. Un'osservazione che nel nostro settore si sente di rado: una parte non trascurabile di questi progetti si risolve senza sviluppo su misura, cioè eliminando passaggi, con un modulo e con uno strumento standard il cui abbonamento costa un ordine di grandezza meno dello sviluppo e della sua manutenzione. La soluzione su misura ha senso dove il processo è davvero specifico e dove l'attrito supera il costo dello sviluppo e della manutenzione. Quando un investimento del genere si ripaga lo analizziamo nel testo Un buon sistema interno può ripagarsi prima di una nuova assunzione, e come sarebbe un'azienda costruita da zero nell'articolo Come costruirei oggi un'azienda che non ha bisogno di un esercito di amministrativi.

Cosa portarsi a casa

• Scomponete un singolo processo in input, decisione, azione e output. Mappate la realtà, non la procedura scritta.
• Individuate duplicazioni, attese, approvazioni senza rischio, trasferimenti manuali e passaggi senza motivo. Ordinateli secondo il Cost of Friction: tempo per frequenza per numero di persone per costo orario.
• Rispettate l'ordine eliminare, semplificare, automatizzare, potenziare. Il passaggio successivo si può iniziare solo dopo aver completato il precedente.
• Dove basta l'automazione deterministica, il modello linguistico aggiunge soltanto incertezza e costo.
• Prima dell'avvio datevi una risposta: chi controlla l'output, quali dati entrano, chi ha accesso a che cosa e come potete dimostrare a posteriori che cosa ha fatto il sistema.