Agenti AI in azienda: dove funzionano davvero (e dove bruciano budget)

Quando sento “mettiamo agenti AI in azienda”, la domanda che faccio è sempre la stessa: agenti per fare cosa, su quale processo, con quale responsabilità? Perché un agente non è un assistente. Un assistente ti aiuta a scrivere. Un agente tocca sistemi, prende decisioni operative e, se non lo governi, crea incidenti a velocità macchina.

La promessa è reale: ridurre lavoro ripetitivo, accelerare triage, aumentare throughput e time‑to‑decision. Ma il rischio è simmetrico: costi fuori controllo, tool sprawl, azioni irreversibili, compliance che salta. Qui ti spiego dove funzionano davvero e come portarli in produzione senza “sorprese”.

1) Assistente vs agente: la differenza è l’autonomia (e quindi il rischio)

Un agente è un sistema che pianifica passi, chiama strumenti e produce un risultato “chiuso”: ticket risolto, email inviata, runbook eseguito, evidenza esportata. Questo richiede due cose che spesso mancano: confini e verifica.

Quando un’azienda mette un agente senza confini, succede sempre la stessa cosa: l’agente diventa un “browser costoso” che prova a indovinare. L’autonomia va guadagnata: prima in sandbox, poi in canary, poi in produzione.

• Input: cosa può leggere (e cosa no).
• Tools: cosa può chiamare (e con quali permessi).
• Actions: cosa può fare da solo vs cosa richiede approvazione.
• Logs: audit trail completo: chi ha chiesto cosa, cosa è stato chiamato, e cosa è stato cambiato.

2) Tre pattern che funzionano (ROI alto, rischio controllabile)

Gli agenti funzionano quando il problema è procedurale e quando esiste un “modo giusto” di fare le cose. Tre pattern che vedo funzionare bene:

• Triage operativo (NOC / support / incident): raccogli contesto, classifica, propone azioni e prepara handoff umano.
• Ricerca→memo decisionale: raccoglie fonti interne, sintetizza, evidenzia rischi e produce una pagina decision‑ready.
• Procurement‑ready evidence pack: trasforma obblighi→controlli→evidenze in un output firmabile (con ownership chiara).

Se vuoi un riferimento pratico sui “tool contract” e su come orchestrare chiamate, la guida MCP Protocol è un buon punto di partenza.

3) Dove bruciano budget (e perché succede quasi sempre)

Gli agenti diventano costosi quando li usi come scorciatoia per processi non definiti. Se non esiste un runbook, l’agente lo “inventa” e paga in token, tool call e tentativi.

• Obiettivo vago: “fammi un’analisi completa” → loop e context bloat.
• Nessun budget guardrail: niente limiti su tool call, tempo o token.
• Assenza di eval: non sai se migliora o peggiora, quindi continui a spendere.
• Connettori fragili: API instabili, permessi incoerenti, dati sporchi → retry e fallimenti.

4) Guardrail: come renderli “firmabili” (e non un rischio)

Un agente in produzione deve essere governabile come un servizio: SLO, runbook, rollback, logging. E deve avere regole “non negoziabili” che bloccano comportamenti pericolosi.

• Tool allowlist + permessi minimi (principle of least privilege).
• Approvazioni per azioni irreversibili (invii, scritture, cancellazioni).
• Sandbox per esecuzione e test: prima simuli, poi applichi.
• Audit log con redaction: tracciabilità senza PII in chiaro.
• Eval gate: nessun deploy senza test set e soglie minime.

Qui la Reference Architecture aiuta a trasformare discussioni infinite in una checklist operativa (confini, logging, ownership).

5) Economics: il KPI non è “token”, è costo per outcome

Il modo più veloce per far fallire un progetto agentic è misurare solo “token spesi”. In boardroom conta il KPI economico: costo per outcome affidabile (ticket risolto, pratica completata, decision memo consegnato).

Per una prima stima, puoi usare il TCO Calculator e poi aggiungere i costi “invisibili”: review umana, eccezioni, incident response, e drift di policy.

6) Piano 30 giorni: 1 agente, 1 processo, 1 KPI

Se vuoi evitare l’effetto “demo infinita”, la regola è semplice: un agente, un workflow, una metrica. Poi scala.

Giorni 1–7 — Focus: perimetro e runbook

• Scegli 1 workflow ad alto volume e alta frizione.
• Definisci outcome, owner e KPI (prima della tecnologia).
• Scrivi il runbook: passi, eccezioni, “red lines”.
• Definisci dati accessibili e tool allowlist.

Giorni 8–14 — Build: tool contract + logging + eval

• Implementa strumenti con input/output deterministici.
• Attiva logging, redaction e tracing dei tool call.
• Crea test set e soglie go/no‑go.
• Simula in sandbox e misura costo per outcome.

Giorni 15–30 — Scale: canary, approvazioni, rollout

• Rilascia canary su subset di casi e misura KPI settimanalmente.
• Aggiungi approvazioni sulle azioni irreversibili.
• Scrivi runbook + rollback e allena il team sul flusso “assistito”.
• Scala solo dopo evidenze e stabilità.

7) KPI che uso per capire se un agente è “production‑ready”

Un agente è pronto quando è prevedibile: qualità, costi e rischio devono stare dentro un range. Questi KPI bastano per il 90% dei casi:

• Success rate: % outcome completati senza escalation.
• Human override rate: quante volte l’umano deve correggere.
• Cost per outcome: costo per ticket/pratica/memo (non per token).
• Time‑to‑resolution: tempo medio per chiudere un caso.
• Tool reliability: errori, retry, timeout per tool call.
• Safety incidents: violazioni policy, leakage, azioni bloccate.

Punti chiave (da portare in CDA)

• Un agente è automazione: va governato come un servizio.
• Funziona su processi procedurali con runbook: non su obiettivi vaghi.
• Il KPI reale è costo per outcome affidabile, non token.
• Autonomia si guadagna: sandbox → canary → produzione.

Conclusione: agenti sì, ma con confini e prove

Gli agenti possono diventare un vantaggio competitivo, ma solo se li tratti come un prodotto operativo: confini, logging, eval, ownership. Senza, diventano una tassa: budget bruciato e rischio accumulato.

Se vuoi portare un agente in produzione con guardrail e KPI chiari, scrivimi: partiamo da una valutazione strategica e disegniamo la soluzione più semplice che regge audit, sicurezza e costi. Contattami qui.