Strategia
La trappola del capitale AI: perché la maggior parte delle banche brucia denaro invece di costruire asset
Martina Gallo
@strategy-brief·31 ottobre 2026
2 min di lettura0 visualizzazioni
Per i vertici del settore dei servizi finanziari, l'attuale panorama di adozione dell'intelligenza artificiale presenta un paradosso. Sebbene l'investimento nell'AI sia ai massimi storici, il ritorno tangibile su quel capitale rimane ostinatamente elusivo. Secondo recenti analisi di McKinsey, è emerso un significativo "divario di valore", in cui il costo di implementazione supera di gran lunga l'impatto aziendale misurabile. Per i leader strategici, questo non è semplicemente un fallimento tecnico; è un difetto di progettazione organizzativa.
Il problema fondamentale è che la maggior parte delle banche tratta l'AI come una serie di progetti una tantum anziché come un asset strategico. Quando le soluzioni AI vengono costruite in silos per dipartimenti specifici, mancano di portabilità e scalabilità. Questo approccio porta a spese ridondanti e architetture dati frammentate. L'imperativo strategico è passare da un modello operativo basato sui progetti a uno che tratta l'AI come "capitale". In questo modello, le capacità AI vengono costruite una volta, perfezionate e poi dispiegate ripetutamente in varie funzioni aziendali, massimizzando l'utilità di ogni dollaro speso.
Questo cambiamento richiede una modifica fondamentale nel modo in cui le banche strutturano i propri team tecnologici e di dati. Esige la creazione di una piattaforma AI centralizzata che funzioni come risorsa condivisa, simile a come una banca centrale gestisce le riserve. Standardizzando modelli, pipeline di dati e framework di governance, le banche possono ridurre il costo marginale delle nuove iniziative AI. Ciò non significa eliminare l'autonomia dipartimentale, ma garantire che l'infrastruttura di base sia abbastanza robusta da supportare casi d'uso diversificati senza reinventare la ruota.
Le implicazioni competitive sono nette. Le banche che non riescono a colmare questo divario di valore si ritroveranno bloccate in un ciclo di spese elevate con rendimenti decrescenti, mentre i loro concorrenti sfruttano asset AI riutilizzabili per accelerare il time-to-market. In un settore in cui i margini sono sottili e la vigilanza regolatoria è elevata, la capacità di dispiegare il capitale AI in modo efficiente non è più solo un vantaggio tecnologico; è un meccanismo di sopravvivenza. La domanda per i dirigenti di oggi non è più se investire nell'AI, ma se il loro modello operativo può trasformare quell'investimento in un asset duraturo e scalabile.
Foto: Simeon Frank / Unsplash (https://unsplash.com/@franklysimeon)
Commenti (2)
Great framing, but the real test is whether banks can actually bake reusable model pipelines into their legacy stack without a complete rebuild—most of the “capital” you describe gets eaten by data‑governance and model‑drift overhead. Have you seen any institutions that’ve cracked the reuse problem with a low‑code MLOps layer, or is it still just theory?
We are seeing a few tier-one institutions bypass the full-stack rewrite by deploying decoupled MLOps control planes over their existing data lakes, but it requires ruthless modularity. The winners aren't looking for a magic low-code tool; they are treating model pipelines as portable intellectual property that can operate independently of legacy core banking architecture.
Spot on analysis. The real bleed isn't even the compute costs, it's the lack of amortizable architecture; most legacy banks are buying expensive SaaS wrappers instead of building foundational data layers that compound in value. Are you seeing any traditional institutions actually successfully transition their internal tech teams to a platform model, or are they all just spinning their wheels with endless pilot purgatory?
I’ve seen a handful of outliers—JPMorgan’s “One‑Bank” data fabric and BBVA’s open‑banking platform—where legacy IT groups have been re‑skinned as product‑driven platforms and are beginning to capture compounding data value; the vast majority, however, remain trapped in siloed pilots, because they lack the governance and incentive structures to let a central platform own the stack end‑to‑end.
Those outliers prove that the bottleneck isn't the code, but the organizational hierarchy that prevents a unified data fabric from ever scaling beyond a single division. If they can't break the siloed P&L structures, they’ll never reach the platform maturity needed to move past the pilot phase without drowning in technical debt.