Negli ultimi diciotto mesi ci siamo trovati a dire a clienti potenziali una frase che non è popolare: per il problema che ci stai descrivendo, un agente AI non serve. Anzi, sarebbe peggio. Non è una frase che fa bene al fatturato di un'azienda di consulenza AI, ma è la frase corretta. Spendere venti settimane a costruire un agente per un problema che si risolve con una regola scritta o con un buon script Python è uno spreco. Non di soldi soltanto: di reputazione interna del progetto AI nella tua azienda.
L'AI generativa è uno strumento potente. Come ogni strumento potente, è inadatto a un sacco di contesti. In questo articolo elenchiamo sei scenari concreti in cui un agente AI è inutile o addirittura controproducente in una PMI. Sono sei pattern che abbiamo visto ricorrere, e che ogni volta che abbiamo provato a forzare l'AI in quel contesto hanno prodotto un risultato peggiore di quello che si otteneva con un software tradizionale ben fatto.
Scenario 1: il task è interamente deterministico
Se il processo è descrivibile come 'se X allora Y, sempre, senza eccezioni', non hai bisogno di un LLM. Hai bisogno di un if statement. L'AI generativa eccelle quando c'è ambiguità nell'input o nel ragionamento: per task perfettamente strutturati, introduce variabilità non desiderata.
Esempio concreto: una PMI ci chiedeva un agente AI per calcolare lo sconto applicabile a un cliente B2B in base a fatturato annuo, anzianità del rapporto, tipo di prodotto. La regola era una tabella di 24 righe con tre dimensioni. Non c'è nulla di ambiguo, nulla di linguistico, nulla che richieda ragionamento. Una regola di business in qualunque sistema gestionale risolve il problema in cinque minuti. Un agente AI lo risolverebbe nel 99% dei casi ma con 1% di errore inaccettabile su una decisione commerciale.
Scenario 2: ci sono regole rigide non negoziabili
Quando il dominio impone regole inderogabili — normative sanitarie, vincoli legali, soglie di sicurezza — la natura probabilistica dell'LLM è un rischio strutturale. Il modello, anche con istruzioni esplicite, può produrre output che violano la regola in una percentuale minima ma diversa da zero. In contesti regolati, zero è l'unica soglia accettabile.
- Calcolo dose farmaceutica in base a peso paziente: software validato, mai un LLM.
- Verifica conformità etichetta alimentare a regolamento UE 1169/2011: rule engine, non LLM.
- Determinazione importo IVA su una fattura intracomunitaria: software fiscale, non LLM.
- Calcolo punteggio in gara d'appalto pubblico: matematica certa, non LLM.
Scenario 3: la decisione è safety-critical
Se l'errore può causare danno fisico a persone, danno ambientale, o danno economico irreversibile, l'agente AI non è lo strumento. Sistemi safety-critical hanno bisogno di garanzie deterministiche, ridondanza, certificazioni che un LLM oggi non può offrire. Questo è anche il motivo per cui l'AI Act classifica come ad alto rischio molti contesti safety-related.
Esempi: controllo macchinari industriali, gestione sistemi di sicurezza fisica, sistemi che gestiscono flussi energetici critici, dispositivi medici a contatto col paziente. In questi contesti l'AI può essere un copilota informativo che propone analisi a un operatore qualificato, ma la decisione finale non passa mai sotto controllo autonomo dell'agente.
“La domanda da farsi non è 'questo agente può sbagliare?'. È 'se sbaglia, chi paga il prezzo dell'errore?'. Se la risposta è una persona, un cliente, una multa: ridisegna il processo. Se è un fastidio interno superabile, puoi pilotare con human-in-the-loop.”
Scenario 4: i volumi sono troppo bassi
Un agente AI ben fatto richiede da quattro a dodici settimane di build, più costi ricorrenti di monitoraggio, fine-tuning prompt, manutenzione integrazioni. Questo costo si ammortizza se il task viene eseguito centinaia o migliaia di volte. Se il task viene eseguito tre volte al mese, l'ammortamento è incompatibile con qualunque ROI ragionevole.
Caso concreto: una PMI ci chiedeva un agente per processare una specifica tipologia di reclamo cliente. Numero di reclami di quel tipo: in media 4 al mese. Tempo medio di trattamento manuale: 20 minuti per reclamo. Saving teorico massimo: 80 minuti al mese, circa 16 ore l'anno. Costo dell'agente per essere costruito e mantenuto: superiore a un anno di lavoro saving. Il caso giusto qui era una checklist scritta bene per l'addetto reclami, non un agente.
Scenario 5: i dati di input sono troppo incerti o sporchi
Un agente AI lavora bene su input strutturati, anche se in formato libero. Lavora male su input contraddittori, incompleti, o estremamente eterogenei. Se il tuo problema è 'abbiamo centinaia di tabelle con strutture diverse e regole non scritte', il primo intervento non è costruire un agente: è normalizzare i dati. Costruire un agente sopra dati sporchi produce un agente che amplifica il disordine.
Una regola empirica: se la qualità dei dati di input è inferiore al 70% (cioè più del 30% dei record richiede pulizia o validazione manuale), prima dell'agente serve un progetto di data cleansing. Saltarlo significa avere un agente che propone risultati confidenti su input inaffidabili — il combinato peggiore.
Scenario 6: il ROI è strutturalmente sotto soglia
Indipendentemente da quanto sembri 'figo' il caso d'uso, se il ritorno economico atteso non supera una soglia minima ragionevole, il progetto non va fatto. Per una PMI italiana, una soglia minima sensata è: il progetto deve generare almeno 3x il proprio costo entro 18 mesi, con un payback period inferiore a 12 mesi. Sotto questi numeri, esistono quasi sempre interventi di automazione tradizionale più economici e più rapidi.
- Costo del progetto: build + 12 mesi di operating cost (licenze modello, infrastruttura, manutenzione).
- Beneficio atteso: tempo risparmiato * costo del tempo + ricavi incrementali generati - rischio residuo monetizzato.
- Soglia: beneficio / costo >= 3, payback <= 12 mesi.
- Se sei sotto questi numeri e non hai un motivo strategico chiaro (es. positioning competitivo), rinvia.
Cosa fare invece, in pratica
In molti dei sei scenari sopra, esistono soluzioni più semplici e più efficaci dell'agente AI. Riconoscerle non è un ripiego: è una scelta operativa migliore.
- Per task deterministici: rule engine integrato nel gestionale, o macro Excel ben scritta.
- Per task con regole rigide: software dominio-specifico già esistente (HACCP, fatturazione, compliance fiscale).
- Per task safety-critical: sistema certificato del settore, eventualmente con LLM come supporto informativo non decisionale.
- Per task a basso volume: checklist o procedura scritta, formazione dell'addetto, automazione minima (es. RPA).
- Per task con dati sporchi: progetto di data normalization prima, agente AI poi.
- Per task sotto soglia ROI: rivedere il processo manuale prima di automatizzarlo, eliminare attività a basso valore.
Sapere quando non usare un agente AI è una competenza tanto rara quanto quella di costruirne uno buono. Per una PMI, distinguere significa proteggere il budget e proteggere la fiducia interna nel progetto AI. Se hai una lista di idee e vuoi un parere esterno onesto su quali meritano un agente e quali si risolvono con strumenti più semplici, una chiamata gratuita di 30 minuti basta per fare una prima sgrossatura. Ti diremo dove farlo e dove non farlo, senza pretendere che ogni problema sia un nostro caso da vendere.