L'Intelligenza Artificiale sta rendendo possibili automazioni che fino a pochi anni fa sarebbero state estremamente complesse, costose o semplicemente impraticabili. Un Large Language Model (LLM) può leggere un documento, comprenderne il significato, estrarre informazioni, classificare contenuti, interpretare una richiesta scritta in linguaggio naturale e, sempre più spesso, decidere quale azione intraprendere.
La tentazione, quindi, è comprensibile: se l'AI sa fare tutto questo, perché non affidarle direttamente l'intero processo?
Nel Sydea Lab stiamo sperimentando una strada diversa. La prima domanda che ci facciamo non è “dove possiamo inserire l'AI?”, ma “come progetteremmo questo processo se dovessimo costruirlo oggi?”. La differenza sembra sottile. In realtà cambia completamente l'architettura della soluzione.
Un esempio: dall'ordine cliente all'ERP
Immaginiamo un processo apparentemente semplice: acquisire un ordine cliente e registrarlo nell'ERP. L'ordine potrebbe arrivare come PDF e contenere codici prodotto, descrizioni scritte liberamente, quantità, riferimenti del cliente, indirizzi di consegna e condizioni particolari.
Potremmo affidare l'intero processo a un agente AI: chiedergli di leggere il documento, identificare il cliente, verificare l'anagrafica, cercare i prodotti nell'ERP, controllare prezzi e disponibilità e infine creare l'ordine. Tecnicamente è possibile.
Ma è davvero una buona architettura?
Probabilmente no.
Sono tutte operazioni deterministiche:
- verificare se un codice cliente esiste nell'ERP
- controllare la disponibilità di un articolo
- recuperare un listino
- verificare una condizione di pagamento
- creare un ordine attraverso una API
Perché dovremmo utilizzare un Large Language Model per fare qualcosa che una query, una API o poche righe di codice possono fare in maniera più veloce, prevedibile ed economica?
L'AI diventa invece estremamente interessante quando dobbiamo comprendere ciò che non è strutturato. Ad esempio: “consegnare il materiale insieme all'ordine precedente, se possibile entro la prima settimana del mese.” Oppure quando il cliente utilizza una descrizione commerciale che non corrisponde esattamente a quella presente nell'anagrafica prodotti.
Qui non basta più una semplice regola.
Serve interpretazione. Ed è esattamente qui che vogliamo utilizzare l'AI.
Software, automazione e AI non sono concorrenti
Uno degli aspetti che stiamo approfondendo è proprio la separazione delle responsabilità. In un processo moderno possono convivere almeno quattro componenti.
Software deterministico
Gestisce dati, API, autenticazione, database, file, controlli e regole certe. Quando conosciamo esattamente il risultato che vogliamo ottenere, il software tradizionale rimane spesso lo strumento migliore.
Automazione
Orchestra il processo: sposta informazioni, attiva workflow, richiama servizi, controlla stati ed esegue sequenze operative.
Intelligenza Artificiale
Interviene quando il sistema deve comprendere, interpretare, classificare, ragionare o lavorare con informazioni non strutturate.
Persone
Mantengono controllo e responsabilità nei punti in cui una decisione richiede esperienza, autorizzazione, valutazione del rischio o gestione di un'eccezione.
Il valore non sta quindi nel sostituire tutto con un agente AI.
Sta nel decidere come combinare queste componenti.
Le domande che ci facciamo prima di inserire l'AI
Quando analizziamo un processo nei nostri esperimenti, cerchiamo innanzitutto di identificare i punti in cui l'AI è realmente necessaria. Per ogni attività ci facciamo alcune domande.
Serve davvero l'AI?
- Il risultato è deterministico? Se dato lo stesso input ci aspettiamo sempre lo stesso output, probabilmente non abbiamo bisogno di un LLM.
- Esiste già una regola con cui possiamo risolvere il problema? Se possiamo esprimerla chiaramente attraverso codice, una query, una API o un workflow, spesso è preferibile farlo.
- Serve realmente comprendere qualcosa? Testo libero, documenti non strutturati, immagini, intenzioni, contesto e ambiguità sono territori nei quali l'AI può avere un vantaggio enorme.
Quanto costa e cosa rischia?
- Possiamo ridurre il problema prima di chiamare l'AI? Se il nostro ERP contiene 100.000 articoli, non serve dare al modello l'intera anagrafica per capire a quale articolo si riferisce una descrizione. Un'applicazione può restringere deterministicamente il campo a dieci possibili prodotti: l'AI ragiona su dieci alternative, non su centomila, in modo più veloce, controllabile ed economico.
- Quanto contesto dobbiamo fornire al modello? Ogni informazione inviata ha un costo computazionale. Passare interi documenti, conversazioni o grandi quantità di contesto ad ogni richiesta può funzionare tecnicamente, ma non significa che sia una buona soluzione.
- Serve davvero il modello più potente? Non tutte le attività richiedono lo stesso livello di intelligenza: estrarre cinque campi da un documento, classificare una richiesta e ragionare su un'eccezione commerciale complessa sono tre problemi diversi, che potrebbero richiedere tre approcci diversi.
- Quante volte verrà eseguita questa operazione? Una chiamata AI che costa pochissimo può sembrare irrilevante, ma cosa succede quando viene eseguita 100, 10.000, un milione di volte? Quando progettiamo processi aziendali dobbiamo ragionare sulla scala, non sulla singola interazione.
- Cosa succede quando l'AI sbaglia? Forse la domanda più importante di tutte. Possiamo verificare automaticamente il risultato? Possiamo annullare l'azione? Serve l'approvazione di una persona? Quanto costa un errore? L'autonomia di un sistema dovrebbe dipendere anche dalle risposte a queste domande.
Un processo aziendale non viene eseguito una volta: viene eseguito continuamente.
L'AI ha un costo, anche quando non lo vediamo
C'è un fenomeno che troviamo particolarmente interessante. Come utenti siamo ormai abituati a utilizzare strumenti come ChatGPT o Claude tramite un abbonamento mensile: paghiamo una cifra fissa e utilizziamo il servizio. Questo tende inevitabilmente a modificare la nostra percezione del costo dell'AI. Facciamo una domanda, riceviamo una risposta, facciamo analizzare un documento, chiediamo una seconda elaborazione: non vediamo un contatore economico aumentare a ogni token.
Il costo esiste, ma è nascosto dentro l'esperienza del prodotto.
Quando passiamo dall'utilizzo individuale alla costruzione di un processo aziendale, la prospettiva cambia completamente.
Ogni chiamata a un modello utilizza capacità computazionale. Ogni token elaborato ha un costo. Fornire grandi quantità di contesto ha un costo. Chiedere a un agente di ragionare, usare strumenti, verificare il proprio risultato e magari riprovare ha un costo.
E soprattutto, è qualcosa che si ripete nel tempo, chiamata dopo chiamata.
Dal costo per token al costo per processo
Per questo nel Sydea Lab stiamo cercando di spostare l'attenzione da una metrica puramente tecnologica a una metrica di business: non solo “quanto costa una chiamata al modello?”, ma “quanto costa eseguire questo processo?”.
Se un ordine viene elaborato utilizzando quindici chiamate AI, forse possiamo ridurle a tre. Se ogni volta inviamo cinquanta pagine di contesto, forse possiamo costruire un'applicazione che selezioni prima le cinque informazioni realmente rilevanti. Se utilizziamo un modello estremamente potente per classificare un documento in una delle quattro categorie conosciute, forse possiamo utilizzare qualcosa di molto più semplice.
L'ottimizzazione dell'AI diventa così parte dell'architettura applicativa.
I costi nascosti oltre ai token
C'è un secondo livello da considerare. Il costo reale di una soluzione AI non è semplicemente numero di token moltiplicato per il prezzo del modello: dobbiamo considerare anche latenza, infrastruttura, osservabilità, gestione degli errori, sicurezza, valutazione della qualità, evoluzione dei modelli e supervisione umana.
C'è poi un costo ancora più difficile da misurare: quello dell'imprevedibilità. Un programma tradizionale che verifica che “customer_id = 12345” esista nel database è relativamente semplice da testare; un sistema probabilistico richiede un approccio differente.
Per questo, utilizzare un LLM per eseguire qualcosa che avremmo potuto risolvere con una query non è soltanto uno spreco economico: può essere anche uno spreco di complessità.
Non vogliamo costruire agenti, vogliamo costruire processi migliori
Questo è forse il punto principale della sperimentazione che stiamo portando avanti nel Sydea Lab. Il mercato parla sempre più spesso di AI Agent: gli agenti sono una tecnologia estremamente interessante, ma restano uno degli strumenti disponibili. In alcuni processi saranno centrali, in altri una piccola componente di un'architettura più grande, e in altri ancora probabilmente non serviranno.
Per questo proviamo a non partire dalla domanda “quale agente possiamo costruire?”, ma da una pagina bianca: osserviamo il lavoro che oggi viene svolto e ci chiediamo “se dovessimo progettare questo processo da zero, con le tecnologie che abbiamo oggi, come dovrebbe funzionare?”. Solo dopo decidiamo cosa deve essere software, cosa automazione, cosa AI e cosa deve rimanere umano.
Verso una Digital Workforce
Questa sperimentazione ci sta portando progressivamente verso un concetto più ampio: quello di Digital Workforce.
Non immaginiamo un Digital Worker semplicemente come un chatbot con un nome e un avatar, ma come un sistema capace di assumersi una responsabilità operativa ben definita all'interno dell'organizzazione. Dietro quel lavoratore digitale possono esserci API, database, applicazioni tradizionali, workflow, modelli linguistici, modelli specializzati e diversi livelli di supervisione umana.
L'intelligenza artificiale è una componente fondamentale, ma non necessariamente deve fare tutto. All'utente finale interessa soprattutto una cosa: che quel lavoro venga svolto bene.
Ed è probabilmente questa la sfida più interessante che abbiamo davanti: non capire quanta AI possiamo inserire nelle aziende, ma capire quanta intelligenza serve davvero per costruire un modo migliore di lavorare.
Sydea Lab è lo spazio, un po' come i laboratori informatici all'università, dove testiamo il metodo descritto in questo articolo prima di applicarlo ai processi reali dei nostri clienti. Non nasce da un progetto specifico, ma da un'esigenza trasversale: prima di proporre AI, automazione o software tradizionale, capire quale delle tre serve davvero, e perché.
È un lavoro che continua, processo dopo processo, insieme alle aziende con cui lavoriamo.
