Le migrazioni legate all’intelligenza artificiale non sono tutte uguali. Per AWS, distinguere fin dall’inizio se un’organizzazione sta migrando con l’AI, verso l’AI oppure dall’AI è un passaggio necessario per impostare correttamente competenze, governance, risorse e tempi del progetto.
Il tema viene affrontato da Willem VanEssendelft, Senior Solutions Architect di AWS, che propone un modello di classificazione pensato per ridurre l’ambiguità che ancora caratterizza molti programmi di trasformazione basati sull’intelligenza artificiale.
Il problema non è secondario. Secondo Gartner, alla fine del 2025 almeno il 50% dei progetti di intelligenza artificiale generativa era stato abbandonato dopo la fase di proof of concept. Un’indagine S&P Global del 2025 ha inoltre rilevato che il 42% delle aziende aveva interrotto la maggior parte delle proprie iniziative AI, contro il 17% dell’anno precedente. Una ricerca della RAND Corporation ha individuato nella scarsa comprensione degli obiettivi e delle finalità dei progetti AI una delle principali cause di fallimento.
Migrare con l’AI, verso l’AI o dall’AI
Nel modello proposto da AWS, migrare con l’AI significa utilizzare l’intelligenza artificiale come strumento per accelerare una migrazione tecnologica. L’AI può intervenire nelle fasi di discovery, assessment, wave planning, mappatura delle dipendenze tra sistemi e allineamento degli stakeholder. La destinazione dell’infrastruttura rimane sostanzialmente invariata: ciò che cambia è il modo con cui viene eseguito il percorso.
Il secondo scenario è quello della migrazione verso l’AI. In questo caso l’intelligenza artificiale rappresenta la destinazione della trasformazione. L’organizzazione vuole introdurre funzionalità AI, distribuire modelli oppure sviluppare nuove applicazioni intelligenti. AWS indica il proprio percorso di modernizzazione Move to AI come uno degli approcci strutturati a questo tipo di progetto.
La terza categoria riguarda invece la migrazione dall’AI. Comprende i casi nei quali un’organizzazione decide di abbandonare una piattaforma AI esistente, cambiare fornitore di modelli oppure consolidare un’infrastruttura di machine learning diventata eccessivamente frammentata.
Nella pratica, i tre modelli possono sovrapporsi. Una stessa trasformazione può comprendere contemporaneamente una componente con l’AI, una verso l’AI e una dall’AI. Trattare queste attività come un unico flusso di lavoro rischia però di portare a una sottostima delle risorse e delle competenze necessarie.
Come l’AI cambia le migrazioni tradizionali
Le migrazioni cloud richiedono normalmente una fase preliminare significativa dedicata a discovery, assessment e pianificazione dei workload. L’intelligenza artificiale può modificare sensibilmente queste attività, automatizzando una parte delle analisi e riducendo il tempo necessario per preparare il progetto.
AWS cita come esempio AWS Transform, attraverso il quale attività quali la mappatura delle dipendenze, la pianificazione intelligente delle wave e la conversione delle reti possono essere completate in tempi molto inferiori rispetto agli approcci tradizionali.
In uno scenario di questo tipo, tuttavia, le competenze richieste rimangono prevalentemente quelle tipiche di una migrazione infrastrutturale. Secondo AWS servono quindi professionisti esperti di migrazione che sappiano utilizzare strumenti AI, piuttosto che specialisti di intelligenza artificiale ai quali venga affidato un progetto di migrazione.
Migrare verso l’AI cambia il profilo di rischio
Quando invece l’intelligenza artificiale diventa la destinazione del progetto, cambiano sia i requisiti tecnici sia il profilo di rischio.
I sistemi AI hanno infatti un comportamento probabilistico. A parità di input possono produrre risultati differenti, mentre le loro prestazioni possono variare al modificarsi della distribuzione dei dati. La qualità dell’output dipende inoltre dalla qualità dei dati utilizzati per addestrare o alimentare il modello.
In una tradizionale migrazione lift-and-shift, i dati vengono trasferiti sostanzialmente senza modificare il comportamento dell’applicazione. Nei sistemi AI, invece, dati incompleti, distorti o scarsamente rappresentativi possono produrre risultati che appaiono plausibili ma sono errati.
Gartner stima che entro il 2026 le organizzazioni potrebbero abbandonare il 60% dei progetti AI privi di dati adeguatamente preparati per l’intelligenza artificiale.
La governance deve controllare anche il comportamento dei modelli
La migrazione verso sistemi AI impone inoltre un ampliamento del concetto di governance.
I tradizionali meccanismi di controllo degli accessi non sono sufficienti a gestire rischi quali allucinazioni, prompt injection e divulgazione involontaria dei dati. Diventa necessario controllare anche il comportamento del sistema, considerando che la stessa richiesta può produrre risposte differenti e che le prestazioni possono cambiare nel tempo.
Anche il testing assume quindi caratteristiche diverse. Nelle migrazioni tradizionali è possibile verificare il corretto funzionamento attraverso logiche sostanzialmente deterministiche di tipo pass/fail. Nei sistemi AI occorre invece valutare parametri quali accuratezza, equità e robustezza rispetto a numerose categorie di input.
Questa attività non può essere limitata alla fase precedente al rilascio, ma deve entrare nel ciclo operativo dell’applicazione, perché le prestazioni del modello possono deteriorarsi nel tempo in seguito a cambiamenti nei dati.
AWS indica Amazon Bedrock Evaluations come uno degli strumenti utilizzabili per integrare processi di valutazione automatizzati, revisioni umane oppure valutazioni condotte attraverso modelli linguistici di grandi dimensioni direttamente nelle pipeline di sviluppo e distribuzione.
Le competenze richieste cambiano con il tipo di migrazione
La distinzione tra una migrazione con l’AI e una migrazione verso l’AI influenza direttamente anche la pianificazione delle risorse.
Nel primo caso servono soprattutto competenze relative alla trasformazione dell’infrastruttura, alla modernizzazione applicativa e alla gestione delle migrazioni, integrate dalla capacità di utilizzare strumenti AI.
Quando l’AI rappresenta invece la destinazione, diventano centrali competenze relative a modelli, dati, valutazione, sicurezza, governance e gestione del comportamento probabilistico dei sistemi.
Secondo AWS, confondere le due categorie può portare un’organizzazione ad assegnare al progetto professionisti con competenze non coerenti con gli obiettivi effettivi della trasformazione.
Migrare dall’AI e il problema della portabilità
Il terzo scenario riguarda le organizzazioni che vogliono cambiare piattaforma AI.
La possibilità di spostarsi da un modello all’altro dipende in larga misura dall’architettura adottata nello sviluppo dell’applicazione. Un sistema fortemente dipendente dalle API e dalle caratteristiche proprietarie di un singolo modello può richiedere modifiche consistenti nel momento in cui l’azienda decide di cambiare fornitore.
AWS collega questo tema alla propria piattaforma Amazon Bedrock, che consente di accedere attraverso un’unica API ai foundation model di diversi fornitori, tra cui Anthropic, Cohere, Meta e Mistral AI, oltre alle famiglie Amazon Nova e Titan.
Un’architettura di questo tipo permette di valutare, confrontare e sostituire modelli differenti riducendo la necessità di modificare il codice dell’applicazione.
La portabilità diventa quindi un requisito architetturale da considerare già durante lo sviluppo delle nuove applicazioni AI. Progettare fin dall’inizio sistemi basati sulla libertà di scelta del modello e su API unificate può trasformare una futura migrazione dall’AI in un intervento di refactoring, invece che in una riscrittura completa dell’applicazione.
Quando un progetto verso l’AI viene trattato come semplice automazione
AWS porta anche alcuni esempi delle conseguenze derivanti da una classificazione errata.
Nel settore assicurativo, una grande compagnia internazionale ha approvato un progetto pilota biennale per introdurre l’intelligenza artificiale nella gestione dei sinistri, affrontandolo però principalmente come un progetto di automazione.
Secondo i dati riportati nell’analisi, soltanto il 7% delle compagnie assicurative è riuscito a portare l’intelligenza artificiale oltre la fase pilota, mentre circa il 70% delle difficoltà nella scalabilità sarebbe riconducibile a problemi legati alle persone e ai processi.
Classificare un progetto di questo tipo come migrazione verso l’AI avrebbe richiesto fin dall’inizio una diversa pianificazione di competenze, governance e tempistiche.
Thomson Reuters e la modernizzazione .NET con AWS Transform
Un esempio differente arriva da Thomson Reuters, impegnata in un progetto di modernizzazione di applicazioni .NET.
In questo caso l’intelligenza artificiale è stata utilizzata come acceleratore della trasformazione. Gli agenti AI di AWS Transform sono stati impiegati per automatizzare attività di discovery, analisi del codice, pianificazione e refactoring.
La destinazione rimaneva una moderna architettura .NET, mentre l’AI interveniva sul processo utilizzato per raggiungerla. Secondo il modello AWS, si tratta quindi di un caso di migrazione con l’AI.
Nei servizi finanziari governance e dati rallentano l’adozione
Il settore finanziario offre un altro esempio delle differenze tra i due modelli.
Il Banking Outlook 2026 di Deloitte descrive iniziative AI rallentate da basi dati fragili, requisiti normativi crescenti e resistenze interne, con numerosi programmi ancora fermi alla fase di proof of concept.
Uno studio condotto su 125 responsabili della conformità del settore bancario ha inoltre rilevato che oltre la metà delle difficoltà tecniche era riconducibile alla governance dei modelli.
Una migrazione con l’AI può seguire le tempistiche tipiche di una trasformazione tecnologica, mentre una migrazione verso l’AI deve adeguarsi anche ai tempi richiesti dalla governance, dalla compliance e dalla valutazione dei modelli.
La classificazione proposta da AWS punta quindi a identificare fin dalle fasi iniziali quale ruolo svolga effettivamente l’intelligenza artificiale all’interno del progetto: strumento utilizzato per eseguire la migrazione, destinazione tecnologica della trasformazione oppure piattaforma dalla quale l’organizzazione intende migrare.
