AI in produzione: cosa si rompe davvero (e come evitarlo)

Quando dico “mettere l’AI in produzione” non intendo “aprire una chat aziendale”. Intendo questo: un workflow reale (ticket, preventivo, onboarding, compliance, NOC) che gira ogni giorno, con persone che ci contano sopra e KPI che si muovono.

Il salto demo → produzione è un cambio di sport: passiamo da “sembra intelligente” a “regge carico, rischi e budget”. E lì, quasi sempre, si rompono le stesse cose.

1) Pilot vs produzione: cosa cambia davvero

In produzione cambiano quattro variabili che in demo sono invisibili: volume reale, integrazioni, rischio e responsabilità. Se non progetti per queste quattro, non stai “andando in produzione”: stai solo allargando una demo.

• Volume: picchi, concorrenza, code, timeouts.
• Integrazioni: CRM, ticketing, email, documenti, sistemi legacy (e relativi failure mode).
• Rischio: dati sensibili, policy, prompt injection, audit trail, AI Act.
• Responsabilità: chi è owner quando sbaglia? chi è on‑call? qual è il kill‑switch?

La regola che uso è semplice: se non puoi scrivere SLO, runbook e un modello di costo “difendibile”, non è produzione. È un prototipo con marketing.

2) SLO e latenza: la media mente, il p95 ti presenta il conto

La maggior parte dei pilot misura “tempo medio di risposta”. In produzione, quello che conta è la coda: p95, p99, TTFT, error rate. Perché è lì che l’utente smette di fidarsi e torna al processo vecchio.

• TTFT (tempo al primo token): la latenza percepita decide l’adozione.
• p95 end‑to‑end: UI → API → modello → tool (non solo “il modello”).
• Timeout e retry: il moltiplicatore nascosto di costo e instabilità.
• Degrado controllato: cosa succede quando un componente fallisce?

Se vuoi un risultato pulito: definisci SLO aggressivi ma realistici, fai capacity planning, e rendi visibile il percorso completo. Il collo di bottiglia quasi mai è “il modello”: è il resto.

3) Qualità: drift e regressioni arrivano prima del valore

In demo scegli gli esempi migliori. In produzione arrivano edge case, input sporchi, richieste ambigue e utenti creativi. Senza un harness di valutazione, la qualità degrada senza che nessuno se ne accorga: lo vedi quando esplode il rework.

• Golden set: casi “da firma” che non devono mai peggiorare.
• Metriche: groundedness, tasso di allucinazioni, success rate per task.
• Regressioni: ogni change su prompt, retrieval, routing va testato.
• Gating: se non supera soglia, non agisce (escalation o fallback).

La scorciatoia classica è “mettiamo un modello più grande”. In produzione spesso peggiora costi e latenza senza risolvere la causa: mancano test e confini.

4) RAG e dati: la knowledge base può diventare un incidente

Quando colleghi l’AI a documenti, email e ticket, la domanda non è più “sa rispondere?”. È: “sta pescando la cosa giusta, per la persona giusta, nel momento giusto?”. Se la retrieval non è governata, la tua knowledge base diventa un amplificatore di rischio.

• ACL: retrieval filtrata per ruoli/cliente/progetto (non “tutto a tutti”).
• Fonti approvate: versioning, owner, e “single source of truth”.
• Prompt injection: input esterni che cercano di forzare policy o tool‑call.
• Logging con criterio: abbastanza per audit, non un nuovo data lake di PII.

5) Costi: in produzione paghi per affidabilità (non per token)

Il costo che brucia budget non è “il prezzo del modello”. È il costo di reggere la realtà: retry, prompt lunghi, tool‑call inutili, modelli sovradimensionati, logging eccessivo, assenza di caching. Se non misuri cost-to-serve, stai guidando al buio.

Le leve pulite sono quasi sempre operative: routing, caching, batching, quantizzazione, guardrail sui token, e una metrica per output (non per “sessione”). È così che rendi il TCO prevedibile.

• Budget: soglie per team/feature e alert automatici.
• Routing: modello piccolo di default, grande solo quando serve.
• Caching: retrieval e risposte per casi ripetuti.
• Guardrail: limiti su contesto, tool‑call, escalation.

6) Operazioni: runbook, kill‑switch, ownership (senza teatro)

In produzione l’AI è software che decide o influenza decisioni. Quindi deve avere ciò che ha ogni servizio serio: monitoraggio, incident response, runbook, e responsabilità chiare. Se manca, il primo incidente diventa una crisi.

La domanda “da firma” è questa: quando sbaglia, chi se ne accorge, in quanto tempo, e cosa fa? Se non sai rispondere, stai delegando rischio al caso.

7) Un piano 30 giorni per portare un workflow in produzione

Se vuoi andare in produzione senza bruciarti, serve un percorso breve e misurabile. Non “trasformazione”: disciplina.

Giorni 1–7 — Perimetro, SLO, dati

• Scegli 1 workflow con owner e KPI (non 5).
• Definisci SLO (TTFT, p95 end‑to‑end, error rate) e baseline.
• Mappa dati e accessi: cosa entra, cosa esce, chi può vedere cosa.
• Setup osservabilità minima: tracing, metriche, log “sufficienti”.

Giorni 8–14 — Qualità, guardrail, integrazioni

• Crea golden set + harness di valutazione (regressioni incluse).
• RAG con ACL e fonti approvate (versioning e owner).
• Guardrail: policy, blocchi, escalation e fallback.
• Runbook: kill‑switch, degradazione controllata, responsabilità.

Giorni 15–30 — Rollout controllato + costo prevedibile

• Canary / rollout progressivo con decision log.
• Misura cost-to-serve per output (non per token) e ottimizza (routing/caching/batching).
• Simula incidenti: timeouts, tool failure, retrieval failure, leak attempt.
• Pacchetto evidenze: log, accessi, eval, policy, runbook.

Se vuoi collegare subito architettura, osservabilità e governance: guarda la Reference Architecture, leggi la guida su LLM observability, usa il Compliance Mapper per mappare controlli/evidenze e fai un check economico con il TCO Calculator.

8) Checklist “production‑ready” (zero attrito, zero sorprese)

• SLO scritti e misurati (TTFT, p95, error rate).
• Harness di valutazione con golden set e regressioni.
• RAG governato (ACL, fonti approvate, versioning).
• Cost model per output + budget + alert.
• Runbook e kill‑switch (fallback, escalation, owner).
• Evidenze per audit/procurement (log, policy, decision record).

Conclusione: in produzione vince chi governa, non chi “prova”

Portare l’AI in produzione non è un atto tecnico: è una scelta di governance. È decidere che qualità, rischio e costi sono misure, non opinioni. È così che trasformi un pilot in vantaggio competitivo.

Se vuoi portare un workflow in produzione con KPI chiari e senza incidenti evitabili, scrivimi: partiamo da un assessment rapido, definiamo perimetro, SLO e controlli, e portiamo a terra una release misurabile.