Negli ultimi mesi si è diffusa un’idea: con l’AI le aziende potranno costruire internamente qualsiasi software e i SaaS perderanno valore.
Eppure, mentre si ripete che i SaaS siano destinati a sparire, Gartner ha stimato per il 2025 una spesa mondiale in software SaaS di 299 miliardi di dollari, il 21% in più rispetto all’anno precedente. Secondo i dati di Mordor Intelligence si stima una crescita fino a quasi 976 miliardi di dollari entro il 2031.
Il mercato, almeno per ora, sembra leggere il fenomeno in modo diverso: l’AI può cambiare il modo in cui usiamo i software, ma aumenta il valore di piattaforme solide su cui costruire automazioni e agenti.
Quando il software deve gestire dati sensibili, processi trasversali, ruoli di approvazione, integrazioni e audit, la domanda “possiamo costruirlo?” è solo l’inizio. Quella più utile è: qual è il costo e la responsabilità di possederlo per i prossimi anni?
Questo vale per molti ambiti aziendali. Nella gestione delle note spese, per esempio, un flusso apparentemente lineare deve spesso tenere insieme acquisizione dei documenti, dati fiscali, policy, approvazioni, centri di costo, rimborsi chilometrici, export, conservazione e connessioni con altri sistemi.
Vi è mai capitato di vedere un progetto AI partire con grande entusiasmo e poi rallentare, fermarsi o restare confinato a una demo?
L’AI rende più veloce il codice. Non sostituisce il lavoro di prodotto
L’AI può essere molto utile nello sviluppo. In una ricerca condotta su oltre 40 sviluppatori, McKinsey (McKinsey, Unleashing developer productivity with generative AI, 2023) ha rilevato che la documentazione del codice può richiedere circa la metà del tempo, la scrittura di nuovo codice quasi la metà e il refactoring circa due terzi del tempo rispetto al lavoro senza assistenza AI. Sui compiti complessi, però, il vantaggio registrato scendeva a meno del 10% quando gli sviluppatori avevano scarsa familiarità con il contesto tecnico richiesto.
Il punto è qui: un software aziendale è 90% contesto.
L’AI può generare una schermata per caricare uno scontrino. Non conosce da sola la policy della vostra azienda, le eccezioni approvate per una business unit, il sistema contabile da integrare, le regole di accesso tra società del gruppo e ciò che un revisore dovrà poter ricostruire tra sei mesi.
Per arrivare a un prodotto affidabile servono comunque attività che l’AI non rende automatiche:
raccolta e validazione dei requisiti con amministrazione, HR, IT, finance e utenti finali;
progettazione dei flussi e dei casi eccezionali;
architettura, sicurezza, gestione delle identità e autorizzazioni;
test, monitoraggio, gestione degli incidenti e continuità operativa;
integrazioni, aggiornamenti normativi e manutenzione evolutiva;
supporto agli utenti e ownership delle decisioni di prodotto.
L’AI riduce il tempo su alcune attività di sviluppo. Non elimina queste responsabilità. Anzi, quando rende più semplice produrre codice, rende ancora più importante avere regole chiare su qualità, controllo e sicurezza.
Per trasformare quel vantaggio in un prodotto completo servono competenze che vanno ben oltre la scrittura del codice. Servono persone in grado di:
raccogliere e validare i requisiti con amministrazione, HR, IT, finance e utenti finali;
progettare flussi che funzionino anche nei casi eccezionali;
definire architettura, sicurezza, identità e autorizzazioni;
testare, monitorare e gestire eventuali incidenti;
mantenere integrazioni, aggiornamenti normativi ed evolutive;
supportare gli utenti e prendere decisioni di prodotto nel tempo.
Quando il codice è più facile da produrre, qualità, controllo e sicurezza diventano ancora più rilevanti.
La differenza tra POC e prodotto in produzione
Un proof of concept serve a dimostrare che un’idea può funzionare. È utile e, grazie all’AI, oggi può essere costruito in tempi brevi.
Un prodotto in produzione deve invece reggere il lavoro quotidiano senza dipendere dalla persona che l’ha creato. Deve gestire picchi di utilizzo, errori, modifiche di processo, richieste di assistenza, accessi, backup, tracciabilità e aggiornamenti. Deve continuare a funzionare quando cambiano l’ERP, i ruoli interni, una policy o un requisito normativo.
Questa distanza ha un peso economico concreto. Il Consortium for Information & Software Quality ha stimato in almeno 2.410 miliardi di dollari il costo della scarsa qualità del software negli Stati Uniti nel 2022 e in circa 1.520 miliardi il debito tecnico accumulato. È un dato riferito al mercato statunitense, quindi non è trasferibile come stima diretta a una singola azienda italiana. È però un indicatore utile della dimensione di costi che emergono dopo il rilascio: vulnerabilità, fallimenti operativi, dipendenze software e debito tecnico. (CISQ, The Cost of Poor Software Quality in the U.S.: A 2022 Report)
La lezione è semplice: il costo di un’applicazione non termina quando la prima versione va online!
Build vs buy: il confronto va fatto sul TCO, non sul prezzo iniziale
Per decidere se sviluppare internamente o adottare un SaaS, il confronto corretto è il Total Cost of Ownership. Il TCO considera i costi diretti e indiretti lungo l’intero ciclo di vita, non solo il preventivo iniziale o il canone mensile. (IBM, What Is Total Cost of Ownership (TCO)?, 2025)
Voce di costo | Sviluppo interno | SaaS configurabile |
Analisi iniziale | Requisiti, priorità, progettazione e coordinamento interno | Analisi di configurazione e adozione |
Realizzazione | Team di sviluppo, UX, QA, project management | Canone, configurazione e eventuali integrazioni |
Sicurezza e continuità | Responsabilità interna su accessi, vulnerabilità, backup, monitoraggio e incidenti | Da verificare nel fornitore, con responsabilità contrattuali e operative definite |
Manutenzione | Bug, aggiornamenti, librerie, infrastruttura, evolutive | Evoluzione del prodotto inclusa o regolata dal contratto |
Supporto | Persone interne o servizio dedicato | Supporto del fornitore e formazione utenti |
Costo opportunità | Tempo IT sottratto a sistemi davvero distintivi per l’azienda | Minore sviluppo interno, con dipendenza da un prodotto esterno da valutare |
Nel TCO rientrano anche i costi meno visibili: tempo dei dipendenti per la formazione, rallentamenti durante il cambio di processo, correzione degli errori, fermo operativo e gestione di fornitori o infrastrutture. IBM li include esplicitamente nella valutazione del costo totale di un investimento IT. (IBM, What Is Total Cost of Ownership (TCO)?, 2025)
Non significa che il SaaS sia sempre la scelta migliore. Significa che il canone va confrontato con il costo di lungo periodo del software interno, non soltanto con il costo della sua prima versione.
Perché la scelta è più delicata nelle aziende finanziarie e regolamentate
Per banche, assicurazioni, intermediari e organizzazioni con requisiti di controllo elevati, un software che tratta dati e processi aziendali richiede una valutazione ancora più attenta.
Dal 17 gennaio 2025 il regolamento europeo DORA è applicabile alle entità finanziarie e riguarda, tra gli altri aspetti, gestione del rischio ICT, gestione del rischio relativo ai fornitori tecnologici, test di resilienza operativa digitale e segnalazione degli incidenti ICT maggiori. (EIOPA, Digital Operational Resilience Act (DORA))
DORA non impone di acquistare un SaaS e non vieta lo sviluppo interno. Impone però un livello di responsabilità che rende poco sensata una valutazione basata soltanto sulla rapidità con cui si può produrre codice.
Chi sceglie lo sviluppo interno deve poter governare nel tempo sicurezza, continuità, tracciabilità, accessi, test e aggiornamenti. Chi sceglie un fornitore deve valutarne con rigore affidabilità, misure di sicurezza, contratti, integrazioni, gestione dati e continuità del servizio.
In entrambi i casi, la governance resta in capo all’azienda.
Quando ha senso sviluppare internamente
Costruire internamente può essere una buona scelta se il processo è davvero distintivo, difficilmente replicabile da un prodotto configurabile e strategico per il vantaggio competitivo dell’azienda.
Ha più senso quando esistono già:
un team stabile che abbia competenze di prodotto, sviluppo, sicurezza e operations;
una roadmap finanziata anche oltre la prima release;
ownership chiara sulle priorità e sui risultati;
capacità di mantenere integrazioni e adeguamenti normativi nel tempo;
un caso d’uso che non può essere risolto con configurazione, API o integrazioni di un prodotto esistente.
Se l’esigenza è comune a molte aziende e il valore sta nel farla funzionare bene, in modo sicuro e aggiornato, acquistare un software specializzato tende a ridurre tempi di adozione e carico operativo sul team interno.
Quando ha senso acquistare un software specializzato
Acquistare ha senso quando il processo da gestire è comune a molte aziende e non costituisce un elemento distintivo del proprio business.
In questi casi, sviluppare da zero significa prendere in carico anche tutto ciò che resta dopo il rilascio: manutenzione, sicurezza, supporto, integrazioni, evoluzione normativa e continuità operativa.
Un SaaS è una scelta sensata se permette di:
adottare un processo già collaudato in tempi più brevi;
configurare ruoli, policy e flussi senza sviluppare ogni funzione da zero;
mantenere il team IT concentrato su sistemi e progetti davvero strategici;
avere un prodotto che evolve con aggiornamenti, sicurezza e supporto già inclusi nel perimetro del fornitore;
integrare ciò che serve senza trasformare ogni esigenza operativa in un progetto interno.
La scelta non è ideologica. Costruire internamente ha valore quando crea un vantaggio competitivo reale. Acquistare ha valore quando consente di risolvere bene un problema necessario senza trasformarlo in una responsabilità tecnologica permanente.
Cinque domande prima di decidere
Il processo che vogliamo costruire è davvero un elemento distintivo del nostro business?
Abbiamo una stima a tre anni che includa manutenzione, sicurezza, supporto e integrazioni?
Chi sarà responsabile del prodotto quando cambieranno policy, persone, sistemi o requisiti normativi?
Quali dati tratterà il software e quali controlli servono per accesso, tracciabilità e continuità?
Esiste già un prodotto configurabile che copre l’80–90% del bisogno e consente di gestire il resto con integrazioni o processi mirati?
L’ultima domanda è spesso la più concreta. Cercare il 100% di aderenza al primo giorno può portare a costruire un prodotto costoso da mantenere per coprire eccezioni che potrebbero essere gestite in altro modo.
L’AI come livello di accelerazione, non come fondazione improvvisata
L’AI cambierà il modo in cui le persone usano i software aziendali. Può ridurre l’inserimento manuale, aiutare a classificare documenti, proporre controlli, rendere più accessibili dati e procedure.
Perché queste funzioni producano un vantaggio reale, devono poggiare su dati affidabili, processi configurati e responsabilità chiare. L’AI può diventare il livello che rende più semplice lavorare sul sistema. Non sostituisce il sistema che deve conservare il dato, applicare le regole e rendere il processo verificabile.
Nella gestione delle note spese questo significa usare l’AI per togliere attività ripetitive alle persone, mantenendo una base solida per policy, approvazioni, documenti e controllo.
La scelta tra build e buy, quindi, non riguarda chi riesce a creare più velocemente una prima schermata. Riguarda quale organizzazione è pronta a sostenere, controllare e far evolvere quel processo nel tempo.
