Ogni demo a una conferenza mostra la stessa cosa: un agente AI che prenota voli, scrive codice e gestisce il calendario — tutto in un'unica ripresa fluida. Il pubblico applaude. Il founder raccoglie una Serie B.

Poi qualcuno prova a deployarlo in un'azienda reale, e tutto crolla.

Abbiamo deployato agenti AI all'interno di operazioni Fortune 500. Non demo. Non prototipi. Sistemi che girano 24/7, prendono decisioni reali e toccano soldi veri. Ecco cosa abbiamo imparato sul divario tra ciò che fa bella figura sul palco e ciò che sopravvive in produzione.

Il Divario Demo-Produzione

In una demo, controlli gli input. L'agente riceve una richiesta ben formattata, accede a un'API pulita e restituisce una risposta curata. Il percorso felice è l'unico percorso.

In produzione, gli input sono disordinati. Le API vanno in timeout. I dati sono stantii. Gli utenti chiedono cose per cui l'agente non è stato progettato. I casi limite non sono casi limite — sono il martedì.

Il problema fondamentale è che la maggior parte delle architetture ad agenti è ottimizzata per la capacità, non per l'affidabilità. Possono fare cose impressionanti occasionalmente. Le aziende enterprise hanno bisogno di sistemi che facciano cose prevedibili in modo consistente.

Di Cosa Hanno Bisogno gli Agenti in Produzione

Dopo aver deployato gli agenti autonomi di Sentara in call center e team operativi, abbiamo converguto su cinque requisiti non negoziabili:

1. Autonomia Delimitata

L'agente più pericoloso è quello che non conosce i propri limiti. Ogni agente in produzione ha bisogno di confini espliciti:

  • Ambito d'azione — Cosa può fare? Cosa richiede approvazione umana?
  • Soglie di confidenza — Sotto quale livello di confidenza escala?
  • Limiti del raggio d'impatto — Qual è l'impatto massimo di una singola decisione?

Lo implementiamo come un sistema di permessi, non diverso dai permessi file Unix. Ogni agente ha una matrice di capacità che definisce esattamente cosa può leggere, scrivere ed eseguire. Nessun permesso implicito. Nessun "sembrava ragionevole."

2. Fallback Deterministici

Quando un agente basato su LLM incontra ambiguità, ha bisogno di un fallback che non sia "riprova con un prompt diverso." I nostri agenti usano un'architettura decisionale a livelli:

  • Livello 1: Basato su regole — Se la situazione corrisponde a pattern noti, usa logica deterministica. Nessun LLM necessario. Veloce, prevedibile, auditabile.
  • Livello 2: Assistito dal modello — Se le regole non coprono il caso, usa il modello con output vincolato. Risposte strutturate, validate contro schemi.
  • Livello 3: Escalation umana — Se la confidenza è sotto soglia o l'azione supera l'ambito, instrada verso un umano con contesto completo.

L'insight chiave: la maggior parte delle interazioni degli agenti non ha bisogno di AI affatto. Nei nostri deployment, il 60-70% delle decisioni è gestito dalle regole di Livello 1. L'LLM gestisce il restante 30-40% dove il giudizio è effettivamente necessario.

3. Stato Osservabile

Non puoi debuggare ciò che non puoi osservare. Ogni decisione dell'agente deve produrre una traccia che risponde a tre domande:

  • Cosa ha percepito l'agente? (input, contesto, informazioni recuperate)
  • Cosa ha considerato l'agente? (azioni candidate, punteggi di confidenza, ragionamento)
  • Cosa ha fatto l'agente? (azione intrapresa, esito, effetti collaterali)

Logghiamo ogni decisione a ogni livello. Quando qualcosa va storto — e qualcosa va sempre storto — l'indagine richiede minuti, non giorni.

4. Degradazione Graduale

Gli agenti in produzione devono gestire modalità di fallimento che gli agenti demo non incontrano mai:

  • Fallimenti API — L'agente non riesce a raggiungere un servizio esterno. Ritenta? Mette in coda? Ricade su dati in cache?
  • Picchi di latenza del modello — L'LLM impiega 30 secondi invece di 2. L'utente aspetta? L'agente usa un modello più piccolo?
  • Corruzione del contesto — Lo storico della conversazione è inconsistente. L'agente allucina in avanti o resetta?

Ogni modalità di fallimento necessita di una strategia esplicita. "Riprova tre volte poi errore" non è una strategia. È arrendersi lentamente.

5. Valutazione Continua

Gli agenti demo vengono testati una volta. Gli agenti in produzione vengono testati continuamente. Eseguiamo suite di valutazione sui nostri agenti deployati ogni ora:

  • Scenari sintetici che testano casi limite noti
  • Test di regressione per fallimenti precedentemente riscontrati
  • Rilevamento della deriva sulla distribuzione delle decisioni (se l'agente improvvisamente inizia a escalare 3 volte più del solito, qualcosa è cambiato)

L'Architettura Che Funziona

Dopo multiple iterazioni, abbiamo converguto su un'architettura che chiamiamo Autonomia Supervisionata. L'agente opera indipendentemente entro confini definiti, ma ogni sessione è valutata da una pipeline di valutazione asincrona.

Richiesta Utente → Router → [Motore Regole | Agente | Coda Umana]
                                    ↓
                          Azione + Log Traccia
                                    ↓
                          Pipeline Valutazione Asincrona
                                    ↓
                          Punteggio + Allarme (se anomalo)

La pipeline di valutazione non blocca l'agente. Si esegue dopo il fatto, valutando le decisioni contro criteri di qualità. Se una decisione sembra sbagliata, allerta il team operativo. Se emerge un pattern di decisioni scadenti, può automaticamente restringere le soglie di confidenza dell'agente — rendendolo effettivamente più conservativo finché un umano non verifica cosa sta succedendo.

Cosa Sbagliano le Aziende Enterprise

Tre pattern che vediamo ripetutamente:

"Iniziamo con un agente general-purpose." No. Iniziate con l'ambito più stretto possibile. Un agente che gestisce brillantemente un singolo workflow specifico ha infinitamente più valore di un agente che gestisce tutto in modo scadente. Espandete l'ambito dopo aver guadagnato fiducia.

"Il modello capirà da solo." Il modello è un componente. Il sistema intorno — routing, fallback, valutazione, permessi — è ciò che lo rende pronto per la produzione. Dedicare l'80% dello sforzo al prompt engineering e il 20% all'infrastruttura è esattamente al contrario.

"Aggiungeremo i guardrail dopo." I guardrail non sono una feature che si aggiunge. Sono una decisione architetturale che plasma tutto il resto. Aggiungere sicurezza a un sistema non sicuro significa ricostruire il sistema.

La Verità Onesta

Gli agenti AI in produzione sono meno autonomi di quanto pensereste e più utili di quanto vi aspettereste. Il valore non sta nel sostituire il giudizio umano. Sta nel gestire il 70% delle interazioni che non richiedono giudizio affatto, e nel fornire supporto strutturato per il 30% che lo richiede.

Non è eccitante come una demo a una conferenza. Ma è ciò che funziona davvero.