di Antonio Solinas

Negli ultimi due anni si sono sentite ripetere sempre più spesso frasi come: “Dobbiamo introdurre l’AI in azienda”, “Dobbiamo automatizzare con l’intelligenza artificiale”, “Dobbiamo avere una strategia AI”. La domanda da porre, in questi casi, è molto semplice: per fare cosa? Ed è sorprendente quanto spesso, dopo questa domanda, la conversazione diventi improvvisamente meno chiara.

Utilizzare l’intelligenza artificiale non è un obiettivo aziendale. Esattamente come vent’anni fa non era una strategia “avere Internet”, dieci anni fa non era una strategia “andare sul cloud” e qualche anno dopo non era una strategia “fare IoT”. Sono tecnologie. Potenti, trasformative, in alcuni casi rivoluzionarie. Ma rimangono tecnologie. La strategia viene prima.

Una strategia dovrebbe dire quali problemi si vogliono risolvere, quali processi migliorare, quali capacità acquisire, quali costi ridurre, quali tempi comprimere o quale nuovo valore creare. Solo dopo arriva una seconda domanda: quale tecnologia permette di farlo meglio? E la risposta potrebbe essere AI. Ma potrebbe anche non esserlo.

Quando emerge una tecnologia particolarmente potente succede spesso qualcosa di prevedibile: si iniziano a cercare problemi ai quali applicarla. È comprensibile. Si vede un Large Language Model scrivere un documento, analizzare centinaia di pagine, produrre software, interpretare un’immagine o dialogare con un database e si pensa immediatamente a quante attività potrebbero essere automatizzate.

Il problema nasce quando il ragionamento diventa: “Abbiamo l’AI. Dove possiamo metterla?”, invece di: “Abbiamo questo problema. Come possiamo risolverlo?”. La differenza sembra sottile, ma dal punto di vista progettuale è enorme. Nel primo caso la tecnologia diventa un vincolo della soluzione prima ancora di avere definito il problema. Nel secondo caso è semplicemente uno degli strumenti disponibili.

Quando si ragiona sull’integrazione dell’AI nei processi complessi è quindi utile partire da cinque considerazioni: 1) un processo confuso non diventa ordinato grazie all’AI; 2) un buon modello AI è soltanto un componente di un sistema; 3) la soluzione migliore potrebbe non contenere affatto intelligenza artificiale; 4) il livello di autonomia deve dipendere dalle conseguenze delle azioni; 5) non tutto ciò che si può automatizzare conviene automatizzarlo. La possibilità tecnica è soltanto l’inizio della decisione.

Esiste una convinzione piuttosto diffusa secondo cui introdurre AI significhi automaticamente rendere più efficiente un processo. Non necessariamente. Se un processo è ben definito, l’AI può renderlo enormemente più veloce. Se è confuso, può semplicemente rendere il caos più veloce. E come dice Matthew McConaughey in the Gentlemen :«Per essere il re della giungla non basta comportarsi da re. Devi essere il re. E non devono esserci dubbi, perché i dubbi creano Caos e il Caos porta alla rovina.»

Si immagini un processo aziendale nel quale tre persone svolgono la stessa attività in tre modi differenti. Le regole sono in parte scritte, in parte tramandate verbalmente e in parte dipendono dall’esperienza individuale. Ci sono eccezioni che tutti conoscono ma che nessuno ha mai formalizzato. Alcuni dati arrivano attraverso il gestionale, altri via Excel, altri ancora dentro una mail. In questo scenario introdurre un agente AI non significa necessariamente avere risolto il problema. Si potrebbe semplicemente avere costruito un sistema molto sofisticato che automatizza un processo che non è stato ancora compreso completamente.

Esiste un principio dell’ingegneria del software che l’AI non ha cancellato: automatizzare una regola ambigua significa rendere l’errore replicabile. Prima di chiedere a una macchina di eseguire un processo bisogna quindi essere capaci di descriverlo.

Una sequenza progettuale apparentemente meno affascinante, ma molto più solida, è: Processo -> Requisiti -> Architettura → Sistema → AI. Prima bisogna capire cosa deve funzionare. Poi cosa deve accadere e con quali vincoli. Successivamente quali regole, automazioni, dati e integrazioni sono necessarie. Soltanto a quel punto ci si può domandare dove l’intelligenza artificiale produca realmente un vantaggio.

Si prenda una regola aziendale apparentemente banale: “Le richieste di importo basso provenienti da clienti affidabili e con documentazione completa possono essere approvate automaticamente”. Per una persona questa frase può sembrare sufficientemente chiara. Per un sistema software non lo è. Cosa significa “importo basso”? Mille euro? Diecimila? Dipende dal cliente? Cosa significa “cliente affidabile”? Che ha già acquistato? Che non ha insoluti? Che ha superato un processo di verifica? Quando si può considerare la documentazione “completa”? Quali documenti sono obbligatori? E soprattutto: cosa succede quando una di queste condizioni è formalmente soddisfatta ma compare un’anomalia?

Per costruire un sistema bisogna trasformare concetti linguistici in condizioni verificabili. “Importo basso” diventa “importo inferiore a una soglia definita”. “Cliente affidabile” diventa “cliente già verificato secondo determinati criteri”. “Documentazione completa” significa che tutti i documenti obbligatori risultano presenti e validi. “Caso standard” significa appartenere a determinate tipologie e non presentare anomalie. Ed è qui che spesso emerge qualcosa di interessante: il problema più difficile non è introdurre l’AI , è capire come funziona realmente l’azienda.

Molte organizzazioni possiedono una quantità enorme di conoscenza che non esiste formalmente nei loro sistemi informativi. Esiste nelle persone. “Normalmente facciamo così”. “Con quel tipo di cliente però è diverso”. “Se succede questo bisogna chiedere a Marco”. “Questa pratica sembra regolare, ma in quel caso bisogna controllare anche quest’altro documento”.

Questa conoscenza implicita è estremamente preziosa, ma è anche difficile da automatizzare. Per trasformare un processo in un sistema bisogna esplicitare almeno cinque elementi: 1) la regola; 2) i criteri con cui si applica; 3) le eccezioni; 4) le priorità tra regole differenti; 5) gli esiti possibili. Non basta sapere quando procedere. Bisogna sapere anche quando fermarsi. E questo diventa ancora più importante quando si introducono sistemi AI capaci di operare autonomamente.

Quando si progetta una demo si tende naturalmente a rappresentare il caso ideale. Arriva un input corretto, il servizio è disponibile, i dati hanno il formato previsto, il modello risponde, l’API funziona e il sistema produce il risultato. Perfetto. Poi il software incontra il mondo reale: manca un dato, un documento arriva in un formato diverso, un servizio esterno non risponde. Una API restituisce un errore. Un modello produce una risposta incompleta. Arriva un caso limite che nessuno aveva previsto. Si verifica un timeout. Un dato è formalmente corretto ma incoerente con altri dati.

È qui che finisce la demo e comincia l’ingegneria.

Un sistema affidabile non è quello che funziona quando tutto va bene. È quello per il quale è stato progettato cosa deve succedere quando qualcosa va male. Questo principio vale per qualsiasi sistema software, ma diventa ancora più importante con l’intelligenza artificiale, perché viene aggiunta al sistema una componente probabilistica.

Uno degli errori più frequenti consiste nel confondere il modello con la soluzione. Un Large Language Model può classificare un documento, estrarre informazioni, generare un testo, interpretare una richiesta, riassumere informazioni o suggerire un’azione. Sono capacità straordinarie. Ma intorno al modello continuano a servire dati, regole, integrazioni, controlli, gestione degli errori, autorizzazioni, logging e monitoraggio.

Il modello è un componente. Non è il sistema.

È una distinzione già nota in molti altri settori dell’ingegneria. Un ottimo algoritmo di controllo non è un’automobile. Un sensore molto preciso non è un sistema IoT. Un ottimo modello di machine learning non è un prodotto. Allo stesso modo, un LLM estremamente potente non è un processo aziendale. Il valore emerge quando quella capacità viene inserita correttamente dentro un sistema.

Una delle regole progettuali più importanti dovrebbe essere questa: per ogni fase di un processo utilizzare lo strumento meno complesso capace di risolvere bene il problema.

Se una condizione è nota, deterministica e verificabile, probabilmente basta una regola software. Se bisogna eseguire una sequenza ripetibile tra sistemi, probabilmente serve automazione. Se bisogna interpretare linguaggio naturale, immagini, documenti o situazioni caratterizzate da forte variabilità, allora l’AI può diventare lo strumento corretto.

Non c’è alcun premio per avere inserito più AI possibile dentro un’architettura. Anzi. Ogni componente AI aggiunge costi, dipendenze, latenza, necessità di controllo e nuovi possibili comportamenti inattesi. L’AI dovrebbe quindi essere utilizzata esattamente dove la sua natura probabilistica rappresenta un vantaggio. Non dove una semplice istruzione “if” avrebbe risolto meglio il problema.

Da questa considerazione deriva un pattern architetturale particolarmente efficace che tendo ad applicare: l’AI interpreta, il software decide.

Si immagini un processo che riceva documenti, email e dati non strutturati. L’AI può leggere questi contenuti, estrarre un importo, individuare una data, classificare una richiesta, comprendere l’intenzione contenuta in una mail, associare un documento a una determinata pratica o produrre informazioni strutturate partendo da informazioni non strutturate.

A quel punto il risultato può essere passato a software tradizionale. Il software valida i dati, controlla le soglie, verifica le autorizzazioni, applica le regole aziendali, controlla eventuali anomalie e infine decide se procedere, richiedere una verifica o bloccare il processo.

Questa separazione è importante perché distingue due problemi profondamente differenti. L’interpretazione del mondo reale è spesso probabilistica. Una regola aziendale, invece, può essere deterministica. Se una decisione può essere espressa con precisione attraverso regole verificabili, non esiste necessariamente un vantaggio nell’affidarla interamente a un modello probabilistico.

L’arrivo degli AI Agent sta spostando ulteriormente la discussione. Non si chiede più soltanto all’AI di produrre informazioni. Si inizia a permetterle di agire. Può inviare una mail, modificare un database, aprire un ticket, generare un ordine, aggiornare un CRM, prenotare qualcosa, avviare una procedura o effettuare operazioni attraverso API.

A questo punto la domanda non è più soltanto: “Quanto è bravo il modello?”. Diventa: “Cosa si è disposti a permettergli di fare senza chiedere il permesso?”.

L’autonomia non dovrebbe essere considerata come un interruttore acceso/spento. È una scala. 1) L’AI suggerisce: propone un’opzione e una persona decide. 2) L’AI prepara: crea una bozza, raccoglie informazioni o predispone un’azione che una persona verifica. 3) L’AI esegue autonomamente entro limiti precisi e regole definite. 4) L’AI prepara o avvia determinate operazioni, ma l’esecuzione richiede una conferma umana.

Il livello corretto non dipende soltanto dalla qualità dell’AI. Dipende soprattutto dalle conseguenze dell’azione.

Per decidere quanta autonomia concedere si possono utilizzare tre concetti molto semplici: rischio, reversibilità e impatto. Quanto è probabile un errore e quanto sarebbe grave? Quanto è facile annullare l’azione? Quali persone, dati, sistemi o risorse economiche sono coinvolti?

Si considerino due operazioni. Nel primo caso l’AI prepara una bozza di email. Nel secondo effettua un pagamento. La tecnologia utilizzata potrebbe essere esattamente la stessa, ma il livello di autonomia ragionevole è completamente diverso.

Una bozza può essere modificata, cancellata e rigenerata. Un pagamento può essere molto più difficile da annullare e produce conseguenze economiche immediate. Si può quindi consentire all’AI di preparare autonomamente cento email senza permetterle di effettuare autonomamente un singolo bonifico.

La differenza non sta nell’intelligenza del modello. Sta nella reversibilità dell’azione.

Questo principio diventerà fondamentale man mano che si passerà dall’AI generativa agli agenti autonomi. La questione centrale non sarà soltanto quanto un agente sia capace di ragionare, ma quali azioni possa compiere, con quali permessi, entro quali soglie e in quali condizioni debba obbligatoriamente fermarsi.

Esiste infine una domanda che spesso viene dimenticata: vale la pena?

È tecnicamente possibile costruire un sistema AI capace di automatizzare quasi qualsiasi piccola attività amministrativa. Ma questo non significa che sia opportuno farlo. Bisogna considerare almeno il tempo risparmiato, il volume dell’attività, il costo dell’errore e il costo di manutenzione della soluzione.

Automatizzare un’attività che richiede cinque minuti una volta al mese con un sistema che dovrà essere mantenuto per anni probabilmente non rappresenta una grande innovazione. Automatizzare un’attività da trenta secondi eseguita centomila volte al giorno potrebbe invece avere un valore enorme.

Il ROI (Ritorno dell’investimento) dell’automazione non dipende da quanto sia impressionante la demo. Dipende dall’economia del processo.

Una strategia AI interessante non dovrebbe quindi iniziare con un elenco di modelli, piattaforme e chatbot. Dovrebbe iniziare dalla mappa dei processi.

Dove si perde tempo? Dove le decisioni vengono prese lentamente? Dove esistono grandi quantità di informazioni non strutturate? Dove esiste un’attività ripetitiva? Dove l’esperienza delle persone è difficile da trasferire? Dove sono presenti colli di bottiglia? Dove si commettono errori? Dove una migliore interpretazione dei dati potrebbe cambiare una decisione? Dove si potrebbe creare un servizio che prima non era economicamente possibile?

Una volta identificati questi punti, si può decidere cosa risolvere con software tradizionale, cosa con automazione, cosa con AI e cosa invece sia meglio lasciare alle persone.

Forse sarebbe quindi più utile ridurre l’enfasi sulla “AI strategy” e parlare di strategia di trasformazione dei processi in un mondo in cui esiste l’AI.

La differenza non è soltanto linguistica. Nel primo caso si rischia di misurare il successo contando quanti strumenti AI sono stati introdotti: quanti chatbot, quanti agenti, quante licenze, quanti POC (proof of concept). Nel secondo caso si misura qualcosa di completamente diverso: quanto tempo è stato risparmiato, quanto è migliorata la qualità, quanto velocemente viene presa una decisione, quanti errori sono stati eliminati, quanto è diventato scalabile un processo e quali nuove capacità sono state costruite.

Si potrebbe così scoprire che un processo eccellente utilizza tre modelli AI, un altro ne utilizza uno e un altro ancora nessuno. Va benissimo così.

Se tutti possono accedere agli stessi modelli, il semplice accesso all’intelligenza artificiale difficilmente rappresenterà un vantaggio competitivo duraturo. Il vantaggio sarà altrove: nei dati, nella conoscenza del dominio, nella qualità dei processi, nella capacità di trasformare regole implicite in sistemi, nell’integrazione con il mondo reale, nella capacità di progettare correttamente autonomia e controlli e, soprattutto, nella velocità con cui un’organizzazione riesce a imparare e modificare i propri processi.

Due aziende possono utilizzare esattamente lo stesso modello AI e ottenere risultati completamente differenti. Perché il modello è soltanto una parte dell’equazione. La parte difficile rimane costruire il sistema intorno.

L’approccio dovrebbe quindi essere sintetizzato in sette regole: 1) chiarire il processo prima di scegliere la tecnologia; 2) trasformare le regole implicite in criteri verificabili; 3) progettare eccezioni, errori e casi limite fin dall’inizio; 4) utilizzare l’AI soltanto dove esiste una variabilità reale che sarebbe difficile gestire con regole tradizionali; 5) separare, quando possibile, l’interpretazione probabilistica dalla decisione deterministica; 6) calibrare l’autonomia sulla base di rischio, reversibilità e impatto; 7) automatizzare soltanto quando il beneficio supera realmente costi e complessità.

Sono regole poco spettacolari. Ma probabilmente è proprio questo il punto. La fase delle demo spettacolari dell’intelligenza artificiale è stata necessaria per mostrare cosa fosse possibile. Adesso viene la parte più interessante: trasformare quelle possibilità in sistemi che funzionano tutti i giorni.

Con dati incompleti, utenti reali, API che ogni tanto non rispondono, eccezioni, responsabilità e conseguenze economiche. E con la necessità, qualche volta, di saper dire semplicemente: “qui l’AI non serve”.

L’intelligenza artificiale non è una strategia. È uno straordinario nuovo componente a disposizione di chi progetta prodotti, servizi e organizzazioni.

La strategia consiste nel sapere dove usarlo, perché usarlo e, soprattutto, dove fermarsi.