Il demo funziona, la produzione no.
Nel 2026 costruire un primo prototipo AI costa poco. Lovable, Cursor, v0, Google AI Studio, Bolt hanno azzerato la barriera d'ingresso. Il problema non è più partire, è arrivare a un sistema che funzioni con dati veri, utenti reali e requisiti aziendali. È qui che si perde la maggior parte del budget: fonti secondarie (McKinsey e Gartner, 2022-2024) stimano che il 70-80% delle iniziative AI non superi la fase pilota. Il numero preciso varia, la direzione no.
La chiamiamo prototype cliff: il precipizio tra il demo perfetto e il primo utente che fa qualcosa di imprevisto.
Dove si rompono i prototipi AI
- 1. Sui dati. Il PoC gira su un dataset ripulito, spesso sintetico. Il primo contatto con dati aziendali reali, incompleti, con schemi che cambiano e record duplicati, degrada precisione e tempi di risposta.
- 2. Sull'architettura. Il prompt monolitico che fa tutto in una chiamata funziona per un utente e non scala per cento. Senza una separazione tra modello, orchestrazione e interfaccia, ogni cambiamento tocca ogni cosa.
- 3. Sulla sicurezza. Chiavi API in chiaro, dati sensibili passati al modello, nessuna traccia di chi ha chiesto cosa. Il team security dice no e il progetto si ferma.
- 4. Sulla misurazione. Il prototipo non ha metriche di qualità del modello (accuratezza, latenza, costo per chiamata). Senza numeri, ogni discussione sulla messa in produzione è opinione.
- 5. Sulla proprietà. Nessuno in azienda ha il mandato di mantenerlo dopo il rilascio. Un sistema senza owner interno muore alla prima manutenzione.
Il vibe coding ha spostato il problema, non lo ha risolto
Generare un prototipo in un pomeriggio è oggi normale. Questo ha compresso la fase creativa e ha ingrossato quella successiva: capire se quel prototipo può funzionare dentro un'azienda vera. Il vantaggio di velocità si trasforma in svantaggio quando il prototipo diventa, senza revisione, la base di un sistema di produzione.
Fonti di settore (blog IT 2026) hanno segnalato quote significative di codice generato da AI con vulnerabilità di sicurezza. Non è un motivo per non usare gli strumenti, è un motivo per non trattare l'output come pronto per la produzione.
Con gli agenti il salto è più alto
Un agente non produce una risposta, produce una sequenza di azioni. Ogni passaggio può fallire per conto suo e un errore intermedio può generare un esito finale che sembra corretto. Chi valuta solo l'output non lo vede.
Microsoft Research ha rilevato che il 61% dei fallimenti nei sistemi multi-agente nasce ai punti di passaggio tra agenti, non dentro il singolo agente. È il punto che quasi nessuno testa in fase di prototipo, ed è quello che cede per primo in esercizio.
A questo si aggiunge una voce di costo che nel prototipo non si vede. Un agente che gira su dieci richieste al giorno può diventare insostenibile su diecimila. Il costo per esecuzione va misurato durante lo sprint, non scoperto dopo il rilascio.
Come progettare un prototipo perché arrivi in produzione
Non serve costruirlo diverso. Serve iniziarlo diverso. Cinque scelte al momento zero cambiano la traiettoria.
- Architettura API-first. Separare modello, orchestrazione e interfaccia dal primo giorno. Ogni pezzo sostituibile.
- Dati veri, subito. Anche un campione limitato di dati reali dice più di un dataset sintetico completo.
- Metriche dal primo sprint. Accuratezza, latenza, costo per chiamata. Se non le misuri, non le stai gestendo.
- Governance in checklist. Sicurezza, privacy, audit trail come voci di sprint, non come progetto separato.
- Owner interno dichiarato. Chi lo prende in mano dopo il go-live deve essere nel team dal primo standup.