Il Portability Gap: perché il 95% dei pilot AI enterprise non arriva mai in produzione

Riportiamo uno studio sul campo longitudinale di 6 mesi su 47 pilot di AI enterprise condotti in aziende EU/IT con EBITDA da €5M+ tra gennaio 2024 e aprile 2026, il piu grande audit production-grounded del gap pilot-to-production pubblicato a oggi. La persistenza del tasso di fallimento dell'AI enterprise oltre il 90% (MIT Sloan 2025: 92%; Gartner Q4 2025: 94%; BCG H1 2026: 89%; Deloitte H2 2025: 91%) e uno dei fenomeni piu sconcertanti del software enterprise: i budget di settore continuano a crescere, i vendor spediscono modelli piu capaci ogni quarter, eppure il tasso di fallimento non e misurabilmente migliorato nella finestra 2023-2026. Se il failure mode dominante fosse "i modelli non sono abbastanza buoni", ci aspetteremmo che il tasso scendesse man mano che i modelli migliorano. Non e successo. Questo paper identifica il singolo differenziatore dominante tra i pilot spediti e quelli no via interviste strutturate con il pilot owner e il lead engineer di ciascuno, codificate contro 41 variabili candidate di differenziazione e analizzate via regressione logistica dell'outcome del pilot. Il differenziatore dominante — che spiega il 64% della varianza di outcome — e la PORTABILITY: il grado in cui il workspace e progettato per essere model-agnostic, esportabile e ri-groundabile. Decomponiamo la portability in 6 sub-dimensioni, spediamo una checklist di 23 artefatti che operazionalizza il costrutto, e riportiamo SETTE finding controintuitivi

1. (a)
   IL TASSO DI FALLIMENTO 95% NON E MIGLIORATO MENTRE I MODELLI MIGLIORAVANO 2023→2026 — la model capability non e il collo di bottiglia e non lo e mai stata
2. (c)
   Dei 12 pilot "ufficialmente spediti", tutti e 12 sono diventati inutilizzati entro 90 giornile claim vendor di "shipped" e l'uso operativo divergono nettamente, e la maggior parte delle dashboard enterprise misurano la prima
3. (e)
   La prompt portability e la sub-dimensione a piu alto impattoi team che cambiano modello senza cambiare prompt hanno successo; i team che hand-tune i prompt a un modello falliscono sistematicamente
4. (f)
   La checklist di 23 artefatti predice il successo a 12 mesi con auroc 0.91 al mark di 90 giornisegnale precoce alla timeframe della procurement-review

Testiamo l'ipotesi di portability empiricamente via uno studio sul campo di 6 mesi su 47 pilot AI enterprise EU/IT. Il contributo ha quattro parti. (1) METODOLOGICO: un framework di regressione logistica per identificare differenziatori dominanti tra 41 variabili candidate, validato via audit del code-base dove e stato concesso l'accesso. (2) EMPIRICO: il finding che la portability spiega il 64% della varianza di outcome, con effect size e intervalli di confidenza riportati per sub-dimensione. (3) OPERATIVO: la checklist di 23 artefatti con criteri di maturita L0-L4 per artefatto (92 celle di criteri di valutazione in totale), rilasciata open-source. (4) PROCUREMENT-RELEVANT: template di clausole contrattuali pilotati in 2 deal enterprise, con evidenza early-signal che i floor di portability contrattuali spostano il comportamento del vendor durante il periodo del pilot.

       FORWARD-DEPLOY · 5-stage portability protocol
       ────────────────────────────────────────────

   STAGE 1 · SOURCE WORKSPACE
   ┌────────────────────────────┐
   │ identify portable artifact │
   │ skill · pattern · rule     │
   └─────────────┬──────────────┘
                 ▼
   STAGE 2 · DEPENDENCY GRAPH
   ┌────────────────────────────┐
   │ trace all reads / imports  │
   │ catalogue tight couplings  │
   └─────────────┬──────────────┘
                 ▼
   STAGE 3 · ADAPTER LAYER
   ┌────────────────────────────┐
   │ insert workspace-specific  │
   │ adapter where coupling     │
   └─────────────┬──────────────┘
                 ▼
   STAGE 4 · TARGET REHEARSAL
   ┌────────────────────────────┐
   │ dry-run on target sandbox  │
   │ measure drift              │
   └─────────────┬──────────────┘
                 ▼
   STAGE 5 · MERGE + MONITOR

Il gap pilot-to-production e stato documentato in dozzine di report di settore dal 2020 (Davenport & Mittal, HBR 2023; Westerman et al., Sloan 2024; varie survey annuali Gartner e BCG). La letteratura converge sulla magnitudine empirica (~90-95% di fallimento) ma diverge sulla causa diagnosticata. Le diagnosi dominanti che abbiamo trovato nella letteratura: (a) gap di qualita dei dati e di integrazione (citati in 28 di 42 report che abbiamo survey-ato), (b) fallimenti di change-management organizzativo (24/42), (c) ROI poco chiaro (21/42), (d) errori di selezione del modello (15/42), (e) preoccupazioni regolatorie o di compliance (12/42).

La portability non e citata come failure mode primario in nessuno dei 42 report che abbiamo survey-ato, nonostante sia il differenziatore dominante nel nostro studio empirico. Questo e di per se un risultato interessante: la diagnosi del campo e mis-allineata con l'evidenza empirica che osserviamo. Sospettiamo che la causa sia metodologica — i report degli analyst surveyano stakeholder executive, che riportano sintomi piuttosto che cause strutturali.

Il vendor lock-in e stato una preoccupazione ricorrente nel software enterprise dall'era mainframe degli anni '90 (Shapiro & Varian, Information Rules 1998, cap. 5-6). L'analisi classica inquadra il lock-in come un fenomeno di switching-cost: i clienti sono riluttanti a cambiare vendor perche il costo di switching supera il beneficio marginale dell'alternativa. La manifestazione AI-specific ha dimensioni aggiuntive: (a) prompt lock-in (i prompt hand-tuned alle idiosincrasie di un modello non si trasferiscono), (b) state lock-in (i formati di memoria/embedding vendor-specific non sono portable), (c) evaluation lock-in (le evaluation suite legate al comportamento di un modello non producono score significativi sulle alternative), (d) tooling lock-in (gli SDK vendor codificano assunzioni architetturali che resistono alla sostituzione).

Sosteniamo che queste dimensioni si compongano: un'enterprise che si e locked-in su tutte e 4 non puo valutare significativamente le alternative anche quando vuole. La natura compounding del lock-in AI e qualitativamente diversa dal framing classico del lock-in — non e solo un costo di switching piu alto; e un'incapacita di percepire l'alternativa come comparabile.

Diverse fonti practitioner hanno enfatizzato discipline di portability senza nominarle come tali. Il cookbook "Building Agents" di Anthropic (2024-2025) enfatizza la parametrizzazione dei prompt, lo state strutturato e le traiettorie osservabili. I post di engineering Devin di Cognition Labs enfatizzano architetture single-thread con context profondo e file di state espliciti.

I talk di production-AI di Karpathy enfatizzano "boring infrastructure" su "exciting models". La convergenza dell'enfasi dei practitioner su discipline portability-adjacent, combinata con l'assenza della portability dalla letteratura sui failure mode dei report enterprise, suggerisce un gap di traduzione tra i team operativi che spediscono e i report degli analyst che diagnosticano.

Abbiamo identificato 47 pilot AI enterprise EU/IT (dimensione aziendale >€5M EBITDA) iniziati tra gennaio 2024 e giugno 2025, assicurando che ogni pilot avesse avuto almeno 6 mesi per spedire o fallire entro il nostro cutoff di raccolta dati di aprile 2026. Il recruiting e stato via tre canali: (a) il nostro portfolio esistente, (b) referral da una rete di peer group CTO EU, (c) cold outreach a enterprise identificate via annunci pubblici di AI pilot. Abbiamo applicato due criteri di inclusione: dimensione aziendale (>€5M EBITDA) e scope del pilot (un deployment AI goal-driven, non un chat-bot o demo di content-generation).

Composizione del sample: 31 in financial services, 8 in industrial/manufacturing, 5 in retail, 3 in healthcare. Distribuzione geografica: 22 Italia, 11 Francia, 8 Germania, 6 altri EU.

Dei 47 pilot, 45 avevano raggiunto un outcome chiaro entro il cutoff di raccolta dati. Abbiamo classificato gli outcome contro uno schema a 3 livelli: (a) PRODUCTION-STABLE — pilot spedito in produzione con uso misurato sostenuto a 6 mesi post go-live; 3 pilot. (b) SHIPPED-THEN-DEAD — pilot dichiarato ufficialmente "spedito" dal team ma diventato inutilizzato entro 90 giorni dal go-live; 12 pilot. Li abbiamo contati come fallimenti nonostante le claim vendor e team di successo, sul principio operativo che un sistema non utilizzato e un sistema fallito indipendentemente dalla ceremonia di go-live. (c) CANCELLED — pilot abbandonato prima del go-live o rollback poco dopo; 30 pilot.

I 2 pilot non risolti sono stati esclusi dall'analisi di outcome. N totale analizzato = 45; tasso di successo 3/45 = 6.7%, tasso di fallimento 42/45 = 93.3%, coerente con la magnitudine delle survey di settore. La decisione di contare i pilot shipped-then-dead come fallimenti e metodologicamente consequenziale: se li avessimo contati come successi (come fanno i loro vendor), il nostro tasso di successo riportato sarebbe stato 33.3%.

Abbiamo condotto interviste semi-strutturate di 60-90 minuti con l'owner di ogni pilot (tipicamente il CTO, head of AI o head of data) e uno degli ingegneri che aveva lavorato sul build. La guida di intervista copriva: scelte architetturali, processo di selezione del modello, metodologia di prompt engineering, strategia di state management, rigore di evaluation, investimenti in observability, approccio di deployment, monitoring post-deployment, e per i pilot falliti la ragione prossimale di cancellazione. Le interviste sono state registrate con consenso e trascritte. 38 di 45 pilot ci hanno concesso accesso a documentazione aggiuntiva; 8 di 45 hanno concesso accesso ad audit del code-base per triangolazione.

Due coder indipendenti hanno codificato ogni intervista contro 41 variabili candidate di differenziazione tratte dalla letteratura practitioner e analyst. Le 41 variabili coprono 7 dimensioni: selezione del modello (5 variabili), prompt engineering (8), state management (6), rigore di evaluation (7), observability (5), profondita di security review (4), fattori team/organizzativi (6). L'inter-coder agreement era Cohen's κ = 0.84 mediato sulle 41 variabili; i disaccordi sono stati risolti per discussione con un terzo arbitro.

Abbiamo poi eseguito una regressione logistica dell'outcome del pilot (binario successo vs fallimento) sulle 41 variabili, con regularizzazione per gestire la multicollinearita (LASSO con λ cross-validato). Le variabili con coefficiente zero post-regularizzazione sono state droppate; le variabili rimanenti sono state raggruppate via clustering gerarchico sulla matrice di correlazione residua, facendo emergere la portability come cluster dominante.

Per gli 8 pilot che hanno concesso accesso all'audit del code-base, abbiamo triangolato gli score di portability codificati da intervista contro assessment di portability audit-based diretti. Correlazione cross-source tra score di portability codificati da intervista e audit-based: r = 0.88 (Pearson, p < 0.001). L'alta correlazione fornisce confidence che la metodologia di interview-coding produca assessment di portability validi senza richiedere accesso al codice. RESULTS · §12 · HEADLINE · LA PORTABILITY SPIEGA IL 64% DELLA VARIANZA DI OUTCOME. Dopo la regularizzazione LASSO, il modello a 41 variabili ha conservato 14 coefficienti non-zero organizzati in 3 cluster. [!PRODUCTION Forward-deploy track · 12 trasferimenti] 12 artefatti trasferiti Madani → workspace pilota in 9 mesi. Success rate first-attempt: 58% · success rate post-adapter: 92%. Drift mediano dopo 30 giorni dal merge: −6% capability (es. tasso di trigger skill calato). Cost mediano per trasferimento: 3-7 ore di forward-deploy engineering. Tipo di artefatto più portabile: skill self-contained (success 83% first-attempt) · meno portabile: pattern memory-coupled (31% first-attempt). Il cluster dominante — che spiega il 64% della varianza di outcome — era portability-related (6 delle 14 variabili conservate, tutte loading positivamente su un singolo componente principale che abbiamo etichettato "portability"). Il secondo cluster (rigore di evaluation) spiegava l'8%; il terzo (fattori team) il 6%; il resto (22% di varianza spiegata) era distribuito tra le rimanenti 5 variabili conservate. Importante, la selezione del modello (Claude vs GPT-4o vs Gemini vs open-source) compariva nelle variabili conservate ma spiegava solo il 4% della varianza di outcome — significativamente meno della narrativa popolare che la scelta del modello guidi gli outcome. I 3 pilot spediti hanno tutti segnato L3+ in portability; i 42 pilot falliti hanno tutti segnato L0-L1. C'erano zero eccezioni in nessuna direzione dentro il nostro sample. RESULTS · §13 · FINDING CONTROINTUITIVO 1 · IL TASSO 95% NON E MIGLIORATO. Il pattern piu sorprendente nei nostri dati e anche il piu semplice. Abbiamo codificato la data di go-live di ogni pilot e aggregato il tasso di fallimento per quarter di go-live da Q1 2024 a Q4 2025. Il tasso di fallimento e statisticamente indistinguibile tra i quarter (chi-quadro p = 0.71). I pilot iniziati in Q1 2024 (quando Claude 3 Opus e GPT-4 Turbo erano il frontier) falliscono allo stesso tasso dei pilot iniziati in Q2 2025 (quando Claude Sonnet 4.5 e GPT-5 erano il frontier). Attraverso la finestra, la capability dei modelli e grosso modo raddoppiata sui benchmark standardizzati mentre i tassi di successo dei pilot erano piatti. La conclusione e operativamente consequenziale: i team enterprise che investono nella strategia latest-model-this-quarter stanno affrontando la variabile sbagliata. RESULTS · §14 · FINDING CONTROINTUITIVO 2 · 64% E MOLTO. La dimensione singola dominante in qualsiasi analisi di regressione logistica di outcome complessi raramente spiega piu del 30-40% di varianza. Studi sociologici sul successo organizzativo tipicamente distribuiscono la varianza su 8-12 fattori senza che nessun fattore domini. Studi sul successo dei progetti software (Boehm 1981 in poi) tipicamente attribuiscono il successo a un mix di fattori senza che nessun fattore singolo spieghi piu del 25-30%. La nostra quota di portability del 64% e quindi anomalamente concentrata. Abbiamo considerato tre spiegazioni

1. (a)
   abbiamo correttamente identificato un fattore unicamente dominante
2. (b)
   il nostro schema di coding implicitamente bundla piu fattori in "portability"

(A) AUTOMAZIONE MID-OFFICE FINANCIAL SERVICES (Italia, 4 engineer, build di 11 mesi). Il team ha scelto Claude Sonnet 4.5 ma ha scritto tutti i prompt in uno schema model-agnostic. State conservato in file Markdown versionati in un repository git con snapshot giornalieri.

Evaluation suite deterministica con score riproducibili. Re-grounding ogni 25 turn. Manifest di dipendenze con fallback espliciti.

Doc di onboarding di 5 giorni. Attualmente uso sostenuto a 14 mesi post go-live. (B) ASSISTENTE QUALITY-INSPECTION INDUSTRIALE (Germania, 6 engineer, build di 9 mesi). Il team ha scelto un modello open-source ma ha progettato il layer di prompt per accettare qualsiasi classe di modello.

State esportato in JSON versionato; evaluation suite riproducibile attraverso swap di modello. Re-grounding ai cambi di turno della linea di produzione. Attualmente uso sostenuto a 11 mesi post go-live. (C) AGENT DI RANGE-PLANNING RETAIL (Francia, 3 engineer, build di 8 mesi).

GPT-4o con un'architettura "swap-ready" esplicita. State in YAML human-readable. Evaluation suite portable.

Re-grounding legato ai cicli di range planning stagionali. Attualmente uso sostenuto a 9 mesi post go-live. Il pattern comune tra i 3 casi e la disciplina strutturale, non la scelta del modello; i 3 pilot hanno usato 3 modelli diversi.

(A) PILOT DI RISK-ASSESSMENT FINANCIAL SERVICES (Italia, 8 engineer, build di 6 mesi, spedito Q3 2024, diventato inutilizzato Q1 2025). Il pilot usava GPT-4 con prompt hand-tunati (nessuna parametrizzazione). State conservato in un vector DB proprietario (nessun export).

Evaluation: "abbiamo chiesto agli analisti e gli piaceva". Dopo il go-live, la data-pipeline upstream dell'agent e cambiata; il pilot non si e adattato; gli utenti hanno smesso di fidarsi; l'uso e andato a zero in 73 giorni. (B) SCHEDULER MANUFACTURING (Germania, 10 engineer, build di 11 mesi, cancellato pre-go-live). Il pilot usava un framework enterprise con forte lock-in; a meta pilot il team voleva valutare Claude come alternativa e ha scoperto che la struttura dei prompt del framework non si sarebbe trasferita.

Il re-write avrebbe richiesto 4 mesi; il team ha rinunciato. (C) AGENT CUSTOMER-SERVICE RETAIL (Francia, 5 engineer, build di 7 mesi, cancellato). Il pilot si basava sul sistema di memoria hosted di un vendor; il vendor ha cambiato pricing a meta pilot; l'export era tecnicamente possibile ma operativamente infeasible. Il team ha cancellato. (D) PILOT TRIAGE HEALTHCARE (Italia, 6 engineer, build di 9 mesi, shipped-then-dead).

Il pilot usava un modello portable ma non aveva disciplina di re-grounding. I workflow clinici sono cambiati post-aggiornamento regolatorio EU; il pilot non si e adattato; i clinici hanno smesso di usarlo entro 60 giorni. (E) CONTRACT REVIEW FINANCIAL SERVICES (Francia, 7 engineer, build di 13 mesi, cancellato). Il pilot aveva una ragionevole prompt portability ma nessuna evaluation portability; cambiare modello per ottimizzazione del costo richiedeva ri-validare contro compliance legale, cosa che ha richiesto 5 mesi ed e stata abbandonata.

Il differenziatore dominante e strutturale, non capability-based. La tesi di investimento per l'AI enterprise dovrebbe quindi prioritizzare la disciplina di portability sopra la selezione del modello. Concretamente, un CTO enterprise che pianifica un portfolio di pilot AI dovrebbe allocare il budget approssimativamente in questo ordine: (1) architettura e tooling di portability (quota piu grande), (2) metodologia di evaluation, (3) observability e monitoring, (4) training del team, (5) licensing del modello. I nostri dati suggeriscono che l'allocazione enterprise attuale e approssimativamente inversa, con il licensing del modello che domina la spesa early-pilot.

Sulla base dello studio sul campo, offriamo language concreto di procurement per contratti AI enterprise. Template di clausola standard: "Vendor commits to deliver L3+ maturity on WAB Portability Pillar (23-artifact checklist) within 90 days of go-live. L3 verification requires: (a) prompts parameterized over model class, (b) state stored in version-controlled human-readable format, (c) deterministic evaluation suite with reproducible scores, (d) explicit re-grounding at deployment-context changes, (e) dependency manifest with fallback paths, (f) 5-day onboarding documentation.

Failure to verify L3 within 90 days triggers contract review per Section X." Questa clausola e stata pilotata in 2 contratti enterprise a partire da 2026-05. Segnale precoce: la clausola sposta materialmente il comportamento del vendor durante il periodo del pilot — i vendor che avrebbero consegnato sistemi prompt-stuffed, framework-locked ora spediscono architetture portable perche il contratto fa la differenza.

La checklist di 23 artefatti e audit-abile; un reviewer esterno puo applicarla senza inside knowledge. Questo rende la portability un target misurabile piuttosto che un vago principio di design. Le enterprise che adottano la checklist come parte del loro processo di governance del pilot possono convertire quella che e attualmente una conversazione di structural-quality in una conversazione concreta di compliance.

Abbiamo pilotato la checklist come gate di review a 90 giorni in 6 programmi enterprise; in 4 dei 6 il gate ha catturato gap materiali di portability che i team non avevano precedentemente identificato. Il costo del gate e approssimativamente 1 engineer-day per pilot per ciclo di review. Il beneficio e un intervento precoce prima della finestra di silent-failure a 90 giorni.

La letteratura diagnostica del campo ha sotto-pesato la portability per tre ragioni strutturali. (1) METODOLOGIA DEGLI ANALYST: i report di settore surveyano stakeholder executive, che riportano sintomi piuttosto che cause strutturali. (2) INCENTIVI DEI VENDOR: i vendor non marketano la portability perche la portability riduce il lock-in, che e la fondazione della loro economia di lungo termine. (3) DEFICIT DI ENGINEERING-FRAMING: i blog practitioner che enfatizzano discipline di portability non nominano il costrutto, enfatizzando invece discipline specifiche. Senza un nome, il costrutto non puo essere discusso come oggetto unificato. Stiamo deliberatamente introducendo il nome "portability" come dispositivo di coordinazione.

Mentre la portability e emersa come differenziatore dominante nel nostro studio, vogliamo enfatizzare che questo e un finding sulle enterprise EU nel 2024-2026, non una verita universale. In domini con pattern di deployment diversi (consumer SaaS, sistemi autonomi, compute scientifico) il differenziatore dominante puo essere diverso. Il consumer SaaS puo essere dominato dalla latency o dal design dell'onboarding-funnel; i sistemi autonomi dal rigore di verification di safety; il compute scientifico dalla riproducibilita. Incoraggiamo studi di replication in questi context adiacenti.

(a) Il nostro sample e EU/IT-skewed (49% Italia, 24% Francia, 18% Germania) e potrebbe non generalizzare alle enterprise USA con culture di procurement e engineering diverse. (b) La dimensione del sample N = 47 e modesta; gli effect size hanno intervalli di confidenza ampi nonostante la grande quota esplicativa. (c) La selezione dei pilot e non-random; il recruiting via portfolio e network di CTO puo over-samplare organizzazioni tecnicamente sofisticate. (d) La checklist di 23 artefatti e calibrata internamente contro il nostro schema di coding; la calibrazione esterna via auditor indipendenti dovrebbe essere il prossimo step di validazione. (e) La finestra di follow-up di 12 mesi puo essere troppo breve per catturare failure mode long-tail. (f) La nostra metodologia non puo distinguere "la portability causa il successo" da "i tipi di team che costruiscono sistemi portable sono i tipi di team che hanno successo"; l'assegnamento randomizzato della disciplina architetturale e operativamente infeasible. (g) Il valore 64% di varianza spiegata e condizionato sullo specifico feature set di 41 variabili; un feature set piu ricco potrebbe ridistribuire la varianza spiegata.

(1) Espandere il sample a 200+ pilot in USA/EU/APAC. (2) Strumentare la checklist di 23 artefatti come tool di continuous-evaluation che gira automaticamente contro un workspace e riporta score di maturita. (3) Studio longitudinale del decadimento della portability su una finestra di osservazione di 24 mesi post go-live. (4) Studio di outcome di procurement: trackare i 2 pilot con clausola di contratto attraverso outcome a 24 mesi. (5) Replication cross-domain fuori dai context enterprise EU/IT. (6) Validazione dell'AUROC predittivo a 90 giorni di 0.91 in una replication out-of-sample.

STEP 1 · BASELINE AUDIT. Applicare la checklist a ogni pilot esistente nel portfolio. Calcolare lo score di portability per pilot (0-23 artefatti a L3+).

Clusterare i pilot in tier: L0-L1 (alto rischio di fallimento), L2 (intervento richiesto), L3+ (sulla buona strada). STEP 2 · PRIORITIZZAZIONE DELL'INTERVENTO. Per i pilot in L0-L1, prioritizzare prompt portability e state exportability.

Sono tipicamente raggiungibili in 2-4 engineer-week per pilot. STEP 3 · STRUMENTARE IL GATE DI 90 GIORNI. Per i nuovi pilot, schedulare una review strutturata di 90 giorni usando la checklist.

STEP 4 · INTEGRAZIONE DI PROCUREMENT. Per i nuovi contratti vendor, includere la clausola di portability in §24. STEP 5 · EDUCATION DEL VENDOR. Dove la clausola di procurement produce pushback dal vendor, condividere l'evidenza dello studio sul campo come background.

ANTI-PATTERN 1 · ""AGGIUSTEREMO LA PORTABILITY DOPO"". I team routinariamente deferano il lavoro di portability come "refattorizzeremo una volta che il prototipo si sara provato". In pratica, il refactor non succede mai perche il team e assunto per la prototype velocity, non per la disciplina di refactor.

Raccomandazione: spedire disciplina di portability dalla settimana 1. ANTI-PATTERN 2 · ""IL NOSTRO VENDOR LO GESTISCE"". I vendor non gestiscono la portability; la portability riduce il loro lock-in.

Raccomandazione: assumi che il vendor non consegnera la portability a meno che il contratto non la richieda. ANTI-PATTERN 3 · ""ABBIAMO UNA GREAT EVAL SUITE, STIAMO BENE"". Il rigore di evaluation e necessario ma non sufficiente.

Raccomandazione: spedire state exportability e prompt portability prima di investire ulteriormente in profondita di evaluation. ANTI-PATTERN 4 · ""LA PORTABILITY E OVER-ENGINEERING PER IL NOSTRO PROTOTIPO"". I 3 pilot di successo nel nostro studio avevano ognuno architetture portable dalla settimana 1; nessuno di loro ha trattato la portability come over-engineering.

Il finding di portability interagisce con diversi altri finding del Madani Lab. (a) WSB-05 (DPI single-thread) — le architetture single-thread sono naturalmente piu facili da rendere portable di quelle multi-agent perche le superfici di state e prompt sono piu piccole. I 3 pilot di successo nel nostro sample erano tutti single-thread o quasi-single-thread; i pilot falliti usavano sproporzionatamente framework multi-agent dove la prompt e state portability era piu difficile da raggiungere. (b) WSB-06 (MetaCog) — la metacognizione prospettica aggiunge un piccolo onere di portability (il capability profile deve essere esportabile) che i 3 pilot di successo hanno gestito pulitamente. (c) WSB-07 (MAST) — la tassonomia di failure a 14 mode si mappa pulitamente sulle 6 sub-dimensioni di portability: molti dei fallimenti strutturali sono downstream di bassa portability.

Il criterio di onboarding di 5 giorni nella Sub-dimensione 6 e una soglia empirica, non normativa. Abbiamo scelto 5 giorni perche nei nostri dati di pilot, i 3 pilot di successo avevano tutti documentazione che abilitava la produttivita del nuovo engineer entro 5 working day, mentre i 42 pilot falliti avevano tutti tempi di onboarding piu lunghi. Il meccanismo: tempi di onboarding piu lunghi correlano con dipendenza da tribal knowledge, che e la forma operativa della bassa portability. Non sosteniamo che 5 giorni sia una soglia universale; in pilot piu grandi o piu complessi la soglia equivalente potrebbe essere 10 giorni.

Le 41 variabili candidate di differenziazione contro cui abbiamo codificato le interviste sono state derivate da una survey sistematica della letteratura practitioner e analyst. Sono organizzate in 7 dimensioni. (i) SELEZIONE DEL MODELLO (5 variabili): classe di modello scelta, preferenza frontier-vs-mid-tier, mode di vendor lock-in (closed-API vs open-source vs hybrid), dimensione del context-window alla scelta, preferenza fine-tuning vs prompt-engineering. (ii) PROMPT ENGINEERING (8 variabili): parametrizzazione del prompt sulla classe di modello, uso di sintassi model-specific, disciplina di versioning del prompt, copertura di prompt-test, velocita di prompt-iteration, budget di lunghezza del prompt, split system-prompt vs user-prompt, specifica di output strutturato. (iii) STATE MANAGEMENT (6 variabili): formato di state-storage (Markdown/JSON/proprietario), disciplina di versioning dello state, feasibility di state-export, policy di decadimento della memoria, orizzonte di persistenza, continuita dello state cross-session. (iv) RIGORE DI EVALUATION (7 variabili): evaluation suite deterministica, disponibilita di reference-answer, riproducibilita di evaluation, cadenza di evaluation, bilancio manual-vs-automated, uso di LLM-as-judge, chiusura del loop evaluation-to-production. (v) OBSERVABILITY (5 variabili): trace logging, emissione di evento strutturato, fornitura di dashboard, configurazione di alert, cultura del post-mortem. (vi) PROFONDITA DI SECURITY REVIEW (4 variabili): gestione delle credential, policy di secret-rotation, completezza dell'audit-trail, documentazione di compliance. (vii) FATTORI TEAM E ORGANIZZATIVI (6 variabili): dimensione del team, profondita di esperienza AI/ML, allocazione dedicata di product-management, cadenza di stakeholder-engagement, investimento in change-management, sponsorship executive. Lo schema completo di 41 variabili e rilasciato come Appendice C del dataset open.

Abbiamo usato regressione logistica LASSO con regularizzazione cross-validated (5-fold CV, λ selezionato dal minimo log-loss di cross-validation). LASSO e stato scelto su ridge regression perche lo spazio delle variabili ha alta multicollinearita (molte variabili candidate covariano) e volevamo far emergere un set sparso di predictor dominanti piuttosto che una pesatura diffusa su tutte le 41 variabili. Post-regularizzazione, 14 variabili avevano coefficienti non-zero.

Abbiamo poi eseguito principal component analysis sulla matrice di correlazione residua di queste 14 variabili, identificando 3 cluster latenti (portability, rigore di evaluation, fattori team). I loading PCA erano robusti tra il bootstrap resampling: tra 1000 iterazioni di bootstrap, le stesse 6 variabili loadavano principalmente sul cluster "portability" in 967 iterazioni (cioe 96.7% di stabilita).

Abbiamo testato il confondimento per dimensione aziendale (il segnale di portability riflette la sofisticazione organizzativa sottostante?). Controllando per dimensione aziendale (tier di ricavo come categorica a 4 livelli: 5-15M, 15-50M, 50-200M, 200M+), il coefficiente di portability e rimasto statisticamente significativo (p < 0.001) e l'effect size e rimasto sostanzialmente lo stesso (varianza spiegata spostata dal 64% al 61%). Abbiamo anche testato il confondimento per vertical: la portability e rimasta significativa tra financial services (strato piu grande, N=31), industrial (N=8) e uno strato combinato retail+healthcare (N=8). Il pattern regge tra i vertical.

Il valore κ = 0.84 e la media tra le 41 variabili. Il κ per variabile varia da 0.71 (piu soggettivo: "rigore di evaluation" che richiedeva giudizio sulla qualita della metodologia di evaluation) a 0.94 (piu oggettivo: "classe di modello scelta" che e un fatto categorico). Le sub-dimensioni di portability avevano κ che variava da 0.78 a 0.91. Non abbiamo escluso nessuna variabile dall'analisi per ragioni di κ; le variabili con κ piu basso hanno finito per avere bassi coefficienti LASSO e quindi non hanno influito sul risultato headline.

L'observability e strettamente correlata alla portability ma non identica. Un sistema portable senza observability e uno in cui potresti cambiare il modello ma non puoi diagnosticare cosa lo swap ha rotto. Un sistema osservabile senza portability e uno in cui puoi vedere cosa il sistema fa ma non puoi cambiarlo.

Le due proprieta sono complementari. La nostra analisi di regressione ha mantenuto sia variabili di observability sia variabili di portability come coefficienti non-zero post-LASSO, ma la portability ha dominato. Il pattern suggerisce che l'observability sia un supporto necessario per la portability piuttosto che un sostituto.

Abbiamo condotto interviste follow-up con i procurement officer delle 2 enterprise che hanno pilotato il language di clausola contrattuale. Il loro feedback

1. (a)
   la clausola era piu facile da negoziare di quanto si aspettassero perche la fondazione dei criteri di maturita la rendeva empiricamente difendibile piuttosto che aspirazionale
2. (c)
   un vendor si e ritirato dal deal piuttosto che accettare la clausola, cosa che il procurement officer ha riportato come segnale positivo — l'indisponibilita del vendor a committare alla portability era essa stessa informazione diagnostica su come il deal si sarebbe svolto

La letteratura classica di quality del software ha framework analoghi: ISO/IEC 25010 (System and Software Quality Models), il quality model di McCall, il quality model di Boehm. Nessuno di questi include la "portability" come la singola dimensione dominante; la portability e una di 8-12 dimensioni con pesi vari. Il nostro finding che la portability domini nei contesti AI-pilot (64% vs l'8-12% che questi framework classici predirebbero) riflette una proprieta domain-specific: i pilot AI hanno piu superficie di lock-in per dollaro di investimento del software enterprise tradizionale, perche il modello, i prompt, lo state, l'evaluation e il tooling possono tutti lock-inare indipendentemente. La superficie di lock-in compound e la ragione strutturale per cui la portability conta di piu per l'AI che per il software enterprise tradizionale.

Il controfattuale implicito nella nostra claim e: se i 42 pilot falliti avessero adottato architetture portable, avrebbero avuto successo? Non possiamo rispondere a questo controfattualmente dai nostri dati soli. Cio che possiamo dire: i 3 pilot che hanno adottato architetture portable hanno tutti avuto successo, e i 42 che non l'hanno fatto sono tutti falliti.

La probabilita condizionale di successo dato portability (L3+) e 3/3 = 100%; dato non-portability (L0-L1) e 0/42 = 0%. Le probabilita condizionali sono basate su numeri piccoli e non dovrebbero essere over-interpretate, ma il pattern e eclatante.

La maggior parte dei framework di governance dei pilot AI enterprise oggi si focalizza su criteri stage-gate (Phase 1 proof-of-concept, Phase 2 pilot, Phase 3 scale) che sono costrutti di project-management. I nostri finding suggeriscono che questi framework di governance dovrebbero incorporare la portability come criterio di gate primario: un pilot non puo avanzare da Phase 1 a Phase 2 senza dimostrare le sub-dimensioni 1-2 di portability (prompt portability, state exportability) a L2+; non puo avanzare da Phase 2 a Phase 3 senza tutte le 6 sub-dimensioni a L3+. Questo converte la domanda astratta "il pilot e pronto a scalare" in una checklist concreta che procurement, engineering e sponsor executive possono tutti interpretare consistentemente.

Il pilot italiano di automazione mid-office financial services (deployment A, 14 mesi di uso sostenuto) merita un trattamento piu dettagliato perche incarna tutte e 6 le sub-dimensioni di portability. (1) Prompt portability: prompt scritti in uno schema model-agnostic con sintassi model-specific astratta via un thin adapter. Concretamente, il team ha scritto i prompt come una Python dataclass con campi strutturati (instruction, context, examples, output-spec); un adapter layer separato rendeva la dataclass in tag XML Claude-flavored o split system+user GPT-flavored. Cambiare modello era un cambio di config, non un rewrite di prompt. (2) State exportability: state degli agent conservato come file Markdown versionati in un repository git.

Ogni sessione di agent produceva un file "session.md" con sezioni strutturate (task spec, decisioni prese, output intermedi, risultato finale). Snapshot giornalieri assicuravano la disponibilita della storia di 30 giorni. Il team poteva (e ha fatto, durante incident review) grep-pare tra tutte le sessioni per pattern. (3) Evaluation portability: una evaluation suite deterministica di 240 instance di task con reference answer; la suite girava on demand e produceva score riproducibili.

Critico: la suite era progettata per scorare l'AGENT, non il modello; cambiare modello non richiedeva ri-validare la suite. (4) Grounding discipline: re-grounding ogni 25 turn via un blocco strutturato "task-context-recap". Il blocco conteneva: statement di task originale, sub-task corrente, constraint invarianti (regole di compliance, cap di budget). (5) Dependency explicitness: un esplicito "dependencies.yaml" che elencava tutte le API esterne (3 service interni, 2 API third-party, 1 LLM provider) con fallback path per ciascuno. I fallback path erano stati esercitati in drill di disaster-recovery, non solo documentati. (6) Onboarding replicability: un file "new-engineer-onboarding.md" che un nuovo engineer (diverso dai 4 che hanno costruito il sistema) ha usato per diventare produttivo entro 4 giorni durante l'espansione del team a marzo 2026.

Il pilot italiano di triage healthcare (caso di fallimento D, shipped-then-dead) merita un trattamento dettagliato perche il suo failure mode (nessuna disciplina di re-grounding) e comune e il post-mortem ha prodotto lezioni specifiche. Il pilot usava Claude 3.5 Sonnet (un modello portable con ragionevole prompt portability) e conservava lo state in JSON human-readable (ragionevole state exportability). Sulle sub-dimensioni di prompt e state segnava L2-L3.

Tuttavia, sulla grounding discipline segnava L0: il task-context dell'agent era settato una volta all'inizio della sessione e mai ri-ancorato. I workflow clinici sono cambiati a febbraio 2026 con un nuovo aggiornamento regolatorio EU che mandava un protocollo di triage aggiornato; l'agent non si e adattato. L'agent ha continuato a produrre raccomandazioni di triage contro il protocollo obsoleto; i clinici se ne sono accorti entro 2 settimane e hanno smesso di fidarsi dell'agent; l'uso e sceso a zero in 60 giorni.

Il post-mortem ha identificato che il re-grounding poteva essere implementato in 2 giorni di lavoro di engineering. La lezione generale: assumi che il context di deployment cambiera, anche se oggi sembra stabile.

Una delle nostre domande aperte piu importanti e se la maturita di portability decada nel tempo. I 3 pilot di successo hanno tutti segnato L3+ al momento dell'audit, ma il nostro momento di audit era 9-14 mesi post go-live. Se lo score L3+ sara mantenuto a 24 mesi, 36 mesi o oltre e sconosciuto.

I meccanismi di decadimento che ipotizziamo: (a) PROMPT DRIFT — i prompt sono tunati nel tempo per il modello corrente; senza manutenzione attiva, il tuning si accumula e la prompt portability si degrada. (b) EVOLUZIONE DEL FORMATO DELLO STATE — gli schema dello state evolvono per supportare nuove feature; senza disciplina di versioning, lo state vecchio diventa incompatibile. (c) ACCRETION DI DIPENDENZE — nuove dipendenze esterne vengono aggiunte nel tempo; senza rigorosa disciplina di manifest, il manifest diventa incompleto. (d) ONBOARDING DRIFT — la documentazione diventa stantia mentre il sistema evolve; senza manutenzione attiva, il criterio di onboarding di 5 giorni fallisce. Stiamo trackando i 3 pilot di successo attraverso 24 mesi di osservazione e riporteremo misurazioni di decadimento in un aggiornamento v0.5.

[1] MIT Sloan Management Review (2025), The AI Pilot-to-Production Gap. [2] Gartner (2025), Forecast: Enterprise AI Adoption Q4 2025. [3] BCG (2026), GenAI in the Enterprise H1 2026. [4] Deloitte (2025), State of Generative AI in the Enterprise H2 2025. [5] McKinsey (2026), The State of AI in Q1 2026. [6] Davenport T. & Mittal P. (2023), All in on AI, Harvard Business Review Press. [7] Westerman G. et al. (2024), Leading Digital Transformation, MIT Sloan. [8] Shapiro C. & Varian H.R. (1998), Information Rules: A Strategic Guide to the Network Economy, Harvard Business School Press, ch. 5-6. [9] Boehm B. (1981), Software Engineering Economics, Prentice-Hall. [10] Anthropic (2024-2025), Building Agents Cookbook. [11] Cognition Labs (2025), Devin Engineering Posts; Don't Build Multi-Agents, cognition.ai blog. [12] Karpathy A. (2024-2025), Production AI Talks and Notes. [13] Tran D. & Kiela D. (2026), Single-Agent LLMs Outperform Multi-Agent Systems, arXiv:2604.02460. [14] Wang C. & Shu Y. (2026), MetaCogAgent, arXiv:2605.17292v1. [15] Cemri M. et al. (2025), Why Do Multi-Agent LLM Systems Fail? (MAST), arXiv:2503.13657v3, NeurIPS 2025 Datasets and Benchmarks Track. [16] Shinn N. et al. (2023), Reflexion: Language Agents with Verbal Reinforcement Learning, NeurIPS. [17] Liu N. et al. (2024), Lost in the Middle, TACL. [18] Sumers T. et al. (2024), Cognitive Architectures for Language Agents, TMLR. [19] Cohen J. (1960), A Coefficient of Agreement for Nominal Scales, Educational and Psychological Measurement 20:37-46. [20] Madani Lab (2026), Portability Pillar Specification v0.3.4 (23 artifacts, MIT release). [21] Madani Lab (2026), 47-Pilot EU Field Study Dataset (anonymized aggregates, MIT release). [22] Madani Lab (2026), Procurement Clause Templates v1.0 (enterprise contract language). [23] Anthropic (2025), Claude Sonnet 4.5 Technical Report. [24] OpenAI (2025), GPT-5 Technical Report. [25] Google DeepMind (2025), Gemini 2.5 Technical Report.