Siamo nell’era dell’”AI che fa cose”, ma quando si tratta di finanza, sanità o pubblica amministrazione, la differenza tra un agente che genera valore e uno che genera una causa legale è questione di tooling, temperatura, e fallimenti. Cohere — azienda nota più per i suoi modelli LLM made in Canada che per le frasi ad effetto — ha appena pubblicato una guida su come costruire agenti AI “enterprise-ready” nei settori dove la compliance non è un’opinione ma un dio vendicativo.
E la guida ha un tono quasi insolitamente pragmatico, per essere un whitepaper AI. Niente arcobaleni quantici. Solo sei regole che dovrebbero già essere scolpite in pietra in ogni SOC 2 room con tanto di badge RFID.
No, non è un altro manuale di prompt engineering. Anzi: dimentica i prompt, e prepara i ferri da lavoro.
Cominciamo da dove fa più male.
Ogni tool è un rischio
Il primo assioma è brutale nella sua semplicità: ogni tool che l’agente utilizza è una superficie d’attacco. Tradotto per i CTO: l’LLM non è il rischio, è la porta d’accesso. Il rischio vero è quello che succede dopo il completamento. Quell’API bancaria che non ha una validazione seria. Quella funzione di scraping con un parser fragile. Quel database legacy che restituisce mezza colonna NULL ogni mercoledì.
La soluzione? Trattare ogni tool come un prodotto API completo. Specifiche chiare, output rigorosi, validazione interna, fallback multilivello. In altre parole, ingegneria del tool prima ancora di pensare alla conversazione. Il prompt è solo il palcoscenico. È il dietro le quinte che farà cadere il sipario.
La temperatura è tutto, tranne che un dettaglio
Ah, la temperatura. Quel parametro che molti trattano come lo zucchero nel caffè: “mah, mettiamo 0.7, così sembra più creativo”. Errore. In ambienti regolamentati, la temperatura dell’LLM è una leva sulla probabilità di fallimento sistemico.
Cohere suggerisce un range chirurgico: tra 0 e 0.3. Questo non perché sia elegante, ma perché si riduce la deriva probabilistica. L’agente diventa prevedibile, ma ancora capace di adattarsi. Se usi un LLM come un decision maker ausiliario, non puoi permetterti estro poetico. Vuoi deduzione fredda. Vuoi ragionamento razionale, non poesia surrealista.
Le allucinazioni non sono errori, sono allarmi
Ecco il fraintendimento più pericoloso del momento: “l’agente ha sbagliato perché ha allucinato un fatto”. No. L’agente ha fallito perché ha restituito un output a bassa confidenza senza avvisarti.
Il problema non è la risposta sbagliata. Il problema è l’assenza di un meccanismo per dire: “non ne sono sicuro, mandalo a un umano”. Questa è l’implementazione reale del concetto di “human in the loop”, che troppo spesso viene evocato come un mantra, ma ignorato nel codice.
Confidence threshold, output strutturato, JSON con tag affidabilità, routing differenziale. L’AI non deve solo generare. Deve sapere quando tacere.
Prompt engineering è morto, viva il tool engineering
Questo è il passaggio più sovversivo del report. Scordatevi il culto del prompt perfetto. “Write a detailed but concise answer using professional tone and no hedging…” — chi se ne frega. Il prompt non salva un agente mal attrezzato.
Il fulcro oggi è costruire strumenti robusti, modulari, e ben definiti. Se il tool è fragile, l’agente fallirà a prescindere da quanto sia ben ingegnerizzato il suo prompt iniziale. Non stai parlando con ChatGPT. Stai orchestrando microservizi intelligenti. E la precisione ingegneristica è la nuova UX.
I workflow devono cadere in piedi
Una catena di task è forte quanto il suo nodo più stupido. E quando l’agente lavora in passaggi — tipo raccogli dati → analizza → genera PDF → invia report — il fallimento di un solo step può azzerare tutto. Ma non deve.
Il trucco è la resilienza strutturata: fallback multipli, log accessibili, backup query, ritentativi intelligenti. L’agente deve degradare con grazia, come un router Cisco che va in modalità failover. Se c’è un errore, non muore, escalationa. La differenza tra MVP e sistema pronto per la produzione sta qui: nella coreografia delle eccezioni.
I veri colli di bottiglia sono nell’orchestrazione
Ultimo punto, il più crudo. Se il tuo agente è lento, goffo o fallace, non è colpa del modello. Nella maggior parte dei casi, il problema sta a monte: orchestrazione inefficiente, caching assente, timeout non gestiti, queue management improvvisato.
L’agente non fallisce perché GPT-4 non è abbastanza “intelligente”. Fallisce perché il circuito tra prompt, tool, e risposta è un castello di sabbia. E questo, per chi gestisce infrastrutture, è musica sinistra. Vuoi affidabilità? Allora serve DevOps per agenti AI, con tanto di osservabilità, logs strutturati e circuit breaker. Altrimenti stai solo giocando con l’AI, non la stai producendo.
Curiosità: nel 2024 una startup healthcare americana ha dovuto sospendere un sistema AI per la triage ospedaliero perché un fallback mancato ha causato l’invio errato di raccomandazioni mediche critiche. Il sistema funzionava al 95%, ma era bastato un tool mal gestito a mandarlo tutto in tilt. Costo: 3 milioni in class action. Un CTO in meno. Un CEO molto silenzioso.
In conclusione? No, non c’è una conclusione, solo una verità brutale: nell’AI moderna, la differenza tra magia e disastro sta nei dettagli che i team sottovalutano. E la guida di Cohere, se letta tra le righe, è un manuale di guerra: come costruire agenti che sopravvivono a qualcosa di più difficile di una demo su Hugging Face — la realtà.