La Previsione Cambiante delle Nuvole

Un Modello che Ho Già Visto

Ero professionista quando il cloud è diventato una cosa. Da quella prospettiva ho visto l’adozione iniziale: l’eccitazione, la flessibilità, la sensazione che tutto sarebbe andato più veloce. Ciò ha portato a un’adozione massiccia, dove ogni workload era un candidato e ogni fornitore aveva una storia sul cloud.

L’adozione, tuttavia, era solo la prima metà di ciò che ho visto. Poi ho visto l’altra parte: la repatriazione. Le aziende spostavano specifici workload indietro, chiedendosi se ogni applicazione realmente necessitava della flessibilità del cloud. Quel secondo spostamento è avvenuto per una ragione. Con gli spostamenti economici e la maturità del workload, le ipotesi che avevano reso il cloud la scelta ovvia per letteralmente tutto hanno smesso di essere valide una volta che le organizzazioni hanno iniziato a esaminarle su larga scala.

Avendo vissuto l’intero arco una volta, riconosco la sua forma quando inizia a formarsi di nuovo. Ora, mentre aiuto le aziende a capire cosa l’AI dovrebbe effettivamente fare nei loro ambienti, il modello di adozione/repatriazione massiccia inizia a sembrare familiare.

La Correzione del Cloud

Per capire perché la somiglianza sia importante, aiuta a iniziare con ciò che è effettivamente accaduto al cloud, nei suoi propri termini. Il passaggio al cloud era razionale. Ha rimosso l’attrito, ha dato alle organizzazioni flessibilità e velocità, e ha avuto senso per i workload che erano incerti o in rapida evoluzione. Era razionale a causa del tipo specifico di lavoro per cui era stato costruito. I team DevOps sono andati cloud-first perché il cloud era stato costruito per il lavoro che è iterativo, variabile o difficile da prevedere.

Ma la cosa per cui stavano costruendo non è rimasta ferma. Il cloud non è cambiato, ma i workload sì. Man mano che i processi maturavano e diventavano prevedibili, le organizzazioni si sono rese conto dei costi intorno al recupero dei propri dati. Tasse di uscita, costi di archiviazione, addebiti per il trasferimento: spese che erano facili da ignorare quando la flessibilità ne valeva la pena, e difficili da ignorare una volta che i workload si sono stabilizzati. Nel 2024, dopo anni di addebito per l’uscita dei dati, AWS, Azure e Google Cloud hanno rinunciato a quelle tasse per i clienti che migravano dalle loro piattaforme, come riportato da DataCenterDynamics.

Una volta che quei costi sono stati resi visibili, la matematica ha smesso di funzionare per una quota crescente del portfolio. L’economia che aveva reso il cloud una buona strategia con alcuni svantaggi è diventata economicamente non sostenibile per un insieme crescente di workload orientati all’AI. Le aziende hanno affilato le matite e hanno chiesto se ogni applicazione realmente necessitava di ciò che il cloud stava fornendo. Quando hanno effettivamente eseguito i calcoli, la risposta, per molti workload, è stata no.

Quei risposte accumulate sono diventate una correzione che l’industria ha etichettato in modo errato. Quella correzione è stata chiamata “repatriazione del cloud”, e viene descritta in modo errato la maggior parte delle volte. In realtà si tratta di maturità del workload: aziende mature che imparano a far corrispondere ogni workload al modello di infrastruttura che gli si adatta. I dati supportano la lettura selettiva piuttosto che quella globale. L’IDC ha scoperto che circa l’80% delle organizzazioni si aspetta una certa repatriazione nei prossimi 12 mesi, anche se meno del 10% ha ripatriato interi workload, secondo quanto riportato su CIO.com.

Leggendo correttamente, la conclusione non è che il cloud sia stato un errore. Il cloud rimane prezioso, ma ha smesso di essere universale. Lo stato maturo è ibrido: cloud dove ha guadagnato il suo posto, infrastruttura privata o dedicata ovunque altro.

Stessa Curva di Correzione, Tecnologia Diversa

Quell’arco è finito e etichettato ora. La stessa forma sta iniziando a formarsi di nuovo con l’AI. Ogni singolo fornitore, ogni singola conferenza, ogni singola telefonata di vendita è ora su l’AI. La saturazione è identica a quella che ho visto accadere con il cloud. La spesa sotto il rumore è reale: Gartner prevede una spesa mondiale di 644 miliardi di dollari per l’AI generativa nel 2025, in aumento del 76,4% rispetto all’anno precedente.

La stessa saturazione implica la stessa correzione imminente. Credo che una correzione simile stia arrivando, non perché l’AI sia cattiva, ma perché la stessa dinamica che ha prodotto la repatriazione del cloud si applica qui anche. Sta arrivando perché le organizzazioni stanno spingendo duramente nei flussi di lavoro guidati dall’AI senza sempre sapere, all’interno dei propri ambienti, come si conclude la storia. Il divario tra adozione e maturità è misurabile: McKinsey scopre che l’88% delle organizzazioni ora segnala l’uso regolare dell’AI in almeno una funzione, eppure la maggior parte sta ancora sperimentando e solo circa il 39% segnala un impatto EBIT a livello aziendale.

Spingere troppo senza una strategia e il rendiconto non è un forse. Quella correzione arriva. Arriva sempre. Si spinge troppo senza una strategia, e alla fine l’economia e la realtà operativa costringono a un rendiconto.

C’è già un nome per il modello correttivo, e non è mio. La repatriazione dell’AI, l’atto di spostare specifiche attività fuori dai sistemi di AI probabilistici e tornare ai flussi di lavoro deterministici una volta che quelle attività diventano stabili e ripetibili, non è un concetto che ho inventato. È un modello che sto guardando svilupparsi. Non sono solo a guardarlo: Gartner prevede che più del 40% dei progetti di AI agente saranno cancellati entro la fine del 2027, citando costi in aumento, valore aziendale non chiaro e controlli di rischio inadeguati.

Cosa Sembra la Correzione dell’AI

Per anticipare la correzione, aiuta avere definizioni chiare per i due tipi di flussi di lavoro coinvolti.

Un flusso di lavoro deterministico è basato su regole, prevedibile e ripetibile. Lo stesso input e le stesse regole producono lo stesso output, ogni volta. È veloce, è fisso. Fa esattamente ciò per cui è stato progettato, nulla più, nulla meno. Un flusso di lavoro probabilistico utilizza l’AI o il ragionamento basato su modelli per interpretare il contesto e produrre una risposta probabile. È utile quando i processi coinvolgono ambiguità, informazioni non strutturate o decisioni che richiedono giudizio dove le regole fisse si rompono e le inferenze portano il carico.

Con le definizioni impostate, la domanda del tempo si risponde da sola. I flussi di lavoro probabilistici sono spesso lo strumento giusto all’inizio quando i processi non sono ancora completamente compresi. Diventano problematici quando le aziende continuano a utilizzarli quando i processi sono chiariti.

Un flusso di lavoro concreto rende quella distinzione tra inizio e fine tangibile. Parte di quel flusso di lavoro richiede effettivamente l’AI. Identificare il conto giusto da una trascrizione di una chiamata, ad esempio, richiede inferenze che un sistema deterministico non può fare. Altre parti, come allegare un file a un record o pubblicare una notifica, sono attività deterministiche. Una regola fissa, una chiamata API diretta, è lo stesso output ogni volta. Sono colpevole di questo stesso errore: sto attualmente costruendo un’automazione interna che collega trascrizioni di chiamate, indirizza informazioni nel nostro CRM, assegna elementi di azione e spinge aggiornamenti a Slack.

La tentazione è quella di eseguire tutto attraverso l’AI, e quella tentazione porta un onere reale e ricorrente. Mentre c’è la tentazione di eseguire l’intera cosa attraverso chiamate mediate dall’AI, ogni chiamata AI introduce latenza e porta costi di utilizzo e infrastruttura. I sistemi AI richiedono monitoraggio, gestione dei prompt e paratie, perché il modello sottostante è costantemente (e imprevedibilmente) sviluppato dal suo proprietario. Non si sa mai quando inizierà a funzionare diversamente; gli output possono variare in modi che creano problemi di governance su larga scala, in fretta.

Giocato abbastanza lontano, quell’onere si trasforma in pura spesa. Pensate a un’azienda che utilizza l’AI per analizzare 50.000 biglietti di supporto. L’AI identifica i cinque percorsi di risoluzione più comuni. All’inizio, l’AI gestisce la routazione in modo probabilistico: legge ogni biglietto e prende una decisione. Nel tempo, l’azienda convalida quei modelli. I percorsi di risoluzione sono ora noti. Trasformarli in rami di flusso di lavoro deterministici non rimuove l’AI dal processo, ma rimuove la pratica ridondante di pagare l’AI per riscoprire risposte che sono ora note.

Quella è la tassa probabilistica: il costo aggiuntivo, la latenza e l’onere di governance di eseguire l’AI come runtime per il lavoro che non richiede più ragionamento probabilistico.

Cosa Sembra un Modello Operativo Maturo

Se eseguire il lavoro risolto sull’AI è una tassa, il passo maturo è dividere il lavoro per tipo. La maturità del cloud ha prodotto un’infrastruttura ibrida, cloud dove ha guadagnato il suo posto, infrastruttura dedicata ovunque altro. Prevedo che la maturità dell’AI produrrà operazioni ibride con la stessa logica.

Quella divisione produce una regola operativa chiara. I sistemi probabilistici sono preziosi dove esiste un’ambiguità genuina. Gli esseri umani sono ambigui. I dati non strutturati sono ambigui. I processi che non sono ancora completamente compresi sono ambigui. L’inferenza è lo strumento giusto per tutto ciò. L’altra metà della regola è altrettanto importante: i sistemi deterministici sono dove contano scala, costo, velocità e governance. Il livello probabilistico scopre e interpreta. Il livello deterministico esegue.

Sul campo, due segnali ti dicono a quale carico di lavoro assegnare un determinato workload:

1. Se trovi il tuo team che si affida all’AI per qualcosa che è diventato stabile, ripetibile e ben compreso, è un candidato per la repatriazione, poiché stai pagando una tassa probabilistica per il lavoro deterministico.
2. Se trovi il tuo codice deterministico pieno di gestori di eccezioni e considerazioni di variabilità, è un segno che potresti effettivamente aver bisogno dell’AI. L’insieme di regole sta cercando di approssimare l’inferenza.

Nella pratica, quel confine viene disegnato come una soglia di confidenza. Una soglia di confidenza specifica, impegnandosi a una decisione quando il modello è al di sopra del 90% di certezza, o fallendo in modo elegante al di sotto di essa, è spesso dove quel confine viene disegnato nella pratica.

Quale riformula ciò che vincere con l’AI richiede effettivamente. Le aziende più di successo che adottano l’AI non saranno quelle che la utilizzano di più, ma quelle che sanno quando utilizzarla e quando integrarla.