Yuri Gubin, CTO di DataArt – Serie di Interviste

Yuri Gubin, CTO di DataArt è un dirigente veterano nel settore tecnologico e architetto software che ha trascorso più di 18 anni in DataArt, progredendo attraverso ruoli che spaziano dall’architettura software, architettura delle soluzioni, tecnologia cloud, innovazione e leadership esecutiva, prima di diventare Chief Technology Officer nel marzo 2026. Il suo lavoro si è concentrato sulla risoluzione di complesse sfide tecnologiche in settori tra cui servizi finanziari, sanità, viaggi e IoT, con particolare competenza nel cloud computing, IA, piattaforme dati e architettura software aziendale. Prima di diventare CTO, Gubin ha ricoperto per più di cinque anni il ruolo di Chief Innovation Officer di DataArt ed è membro del Board of Partners dell’azienda dal 2021. È anche membro professionale del Forbes Technology Council, partecipando ai gruppi di esperti in IA e Cloud Computing, e svolge il ruolo di Technology Advisor per Girls Who Code, dove consiglia su architettura, protezione dei dati, governance della piattaforma e politica tecnologica. DataArt lo elenca attualmente come Chief Technology Officer con sede a New York.

DataArt è una società globale di ingegneria del software e trasformazione dati e IA fondata a New York nel 1997. L’azienda è cresciuta fino a più di 6.000 professionisti tecnologici operanti in oltre 20 paesi e collabora con più di 400 clienti, fornendo servizi in ambiti tra cui intelligenza artificiale e apprendimento automatico, dati e analisi, trasformazione cloud, ingegneria software su misura, cybersecurity e modernizzazione di sistemi legacy. DataArt opera in settori quali servizi finanziari, sanità e scienze della vita, viaggi, media e intrattenimento, e retail, e mantiene partnership tecnologiche con piattaforme tra cui AWS, Google Cloud, Microsoft Azure, Snowflake e Databricks. Nel 2025, la società ha annunciato un investimento di $100 million per tre anni nelle proprie capacità di dati e IA, seguito nel 2026 dal lancio di Artisyn, un modello operativo abilitato all’IA progettato per incorporare agenti IA, acceleratori riutilizzabili, governance, sicurezza e conformità nello sviluppo di software aziendale.

Hai trascorso quasi due decenni in DataArt, passando da architetto software e architetto di soluzioni a Chief Innovation Officer e ora CTO. In che modo questo percorso ha influenzato il modo in cui distingui le tecnologie realmente trasformative dai cicli di hype, e come informa il tuo “ottimismo scettico” verso l’IA oggi?

Abbiamo osservato molte diverse ondate nel corso degli anni, tra cui l’ascesa del cloud e del mobile, le varie generazioni di IA, l’automazione, DevOps e SRE, e ho scritto codice, progettato architetture e consigliato i nostri clienti su molti di questi temi durante tutto questo periodo. Quello che ho capito è che, sì, con la tecnologia si può fare quasi tutto, ed è davvero potente, ma il diavolo sta nei dettagli e devi sapere cosa stai facendo affinché abbia senso e funzioni.

Ho visto gli ambienti cloud diventare sempre più costosi, modelli di IA che non si comportano come ci si aspetta, e tentativi mal implementati di automatizzare i cicli di rilascio. Ho osservato l’impatto sia delle decisioni corrette sia di quelle sbagliate, quindi ogni volta che arriva qualcosa di nuovo e leggi tutti gli annunci, le promesse e l’hype, torno al medesimo principio: quasi tutto è possibile con la tecnologia, ma tu devi sapere cosa stai facendo.

Ottieni una buona padronanza di una tecnologia attraverso la R&D e, soprattutto, tramite progetti reali, perché è così che impari ciò che è possibile, ciò che non lo è e dove le cose possono andare storte. Tratti queste lezioni da ogni incarico, parli con i colleghi, altri architetti e analisti, e cerchi di capire se esistono schemi ricorrenti e se è possibile creare una sorta di sistema attorno a essi. Alla fine, ciò diventa una guida, e poi verifichi se le decisioni che ritenevi buone producono davvero risultati positivi.

Da qui nasce l’ottimismo scettico. Qualunque cosa prometta la tecnologia, è comunque necessario sapere cosa stai facendo, e questa conoscenza proviene dall’esperienza, dalla collaborazione e da uno sforzo continuo di apprendere, migliorare e creare una sorta di sistema dietro l’hype.

L’IA aziendale sembra passare da una fase di incoraggiamento alla sperimentazione a quella di decidere quali esperimenti meritano davvero di essere scalati. Quali segnali ti indicano che un caso d’uso di IA è pronto per una diffusione più ampia, e quali sono gli avvertimenti che un’azienda sta scalando troppo presto?

Utilizzo due metodi per capire se possiamo scalare qualcosa o se dobbiamo fare altro: la curva di adozione e la curva di apprendimento.

Per capire se un caso d’uso di IA funziona, è necessario concedergli del tempo e comprendere il valore che apporta e come appare il percorso dell’utente, perché così si possono osservare gli alti e bassi invece del semplice effetto immediato di ‘wow’ in un team o flusso di lavoro specifico. È importante vedere cosa succede alle stesse persone qualche settimana dopo. Le stanno ancora usando? Sono ancora soddisfatte di quel caso d’uso, di quell’automazione o di quella capacità IA che hanno creato, o è stato solo un picco che in realtà non dovrebbe essere scalato?

Alcune di queste cose possono essere convalidate solo nel tempo. Ci saranno sempre i primi pionieri, solitamente le persone più esperte dal punto di vista tecnico e quelle molto curiose, e poi dovrai provarlo con altri segmenti, con coloro che seguono i primi adottanti e poi la maggioranza precoce. Una volta che si dimostra efficace, sì, puoi iniziare a scalarlo e a espandere quel caso d’uso ad altri dipartimenti.

Ogni importante rilascio di modello può creare pressione all’interno di un’organizzazione per fornire immediatamente ai dipendenti le ultime funzionalità. Come dovrebbero i leader tecnologici valutare se un nuovo modello rappresenta un miglioramento significativo piuttosto che generare semplicemente un’ulteriore ondata di sperimentazione e costi?

Ecco di nuovo il mio scettico ottimismo. Supponi di avere già un modello in uso e diverse migliaia di persone che utilizzano l’IA quotidianamente, con diversi modelli e strumenti già disponibili. Quando esce un nuovo modello, a causa del clamore e della naturale curiosità, puoi aspettarti che tutti vogliano sperimentarlo, il che è positivo, ma tale sperimentazione potrebbe non essere necessariamente guidata o orientata verso risultati specifici, e a volte potresti anche non riuscire a misurare la differenza.

Su larga scala, questo è importante. Non si tratta solo di una o due persone che curiosano per vedere come il nuovo modello si comporta rispetto a quello vecchio. Possono essere migliaia di persone che dedicano tempo alla sperimentazione quando, per un caso d’uso specifico, il risultato potrebbe non essere così significativo. Allo stesso tempo, se qualcosa funziona davvero bene, l’apprendimento su ciò che funziona all’interno della tua organizzazione potrebbe non essere spiegato chiaramente o visibile a tutti.

Ecco perché il primo gruppo che valuta un nuovo modello non dovrebbe essere l’intera organizzazione. Dovrebbe essere un gruppo di R&D che lavora a stretto contatto con i team pertinenti, nonché con i reparti legale e di sicurezza. Valutiamo il modello in modo completo, facciamo una rapida valutazione e poi lo presentiamo a un pubblico più ampio con alcuni commenti e linee guida su sicurezza, conformità e tecnologia. Con l’arrivo costante di nuovi modelli e aggiornamenti importanti, è necessario avere questo modello e mentalità in atto. Non è davvero un esercizio una tantum o occasionale.

DataArt ha creato un “AI SWAT” cross-funzionale che coinvolge tecnologia, legale, conformità, InfoSec e altri team. Come opera questo gruppo nella pratica e quali tipi di rischi o domande devono essere risolti prima che un nuovo strumento di IA sia approvato per un uso più ampio?

Fin dalla sua nascita, credo che abbiamo fissato obiettivi diversi per questo gruppo circa ogni quattro o cinque mesi. Cambiamo la priorità, l’obiettivo e talvolta la missione, e molti di questi obiettivi riguardano l’IA. Possono includere l’aggiornamento delle competenze del personale, il go-to-market e nuove capacità, partnership, o l’abilitazione dell’IA in modo più ampio all’interno dell’organizzazione e attraverso l’ADLC.

Gli argomenti specifici evolvono nel tempo, e penso che ciò sia salutare perché è necessario rivedere costantemente la propria strategia, convalidare le proprie ipotesi e capire se è necessario cambiare rotta e quale dovrebbe essere il prossimo tema per il team.

Il gruppo comprende rappresentanti di diversi dipartimenti, e uno dei suoi scopi è semplicemente tenere tutti informati. Ogni volta che c’è un nuovo annuncio, una domanda o un’opportunità, qualcuno può portare l’argomento a una delle nostre riunioni regolari. Anche se sembra una questione tecnologica rilevante solo per un team ristretto, oggigiorno questi temi possono avere implicazioni per molte parti dell’organizzazione.

Ecco perché, quando valutiamo una nuova partnership, uno strumento o un acceleratore, ne discutiamo apertamente affinché tutti comprendano dove stanno andando le cose e abbiano la possibilità di fare domande o fornire supervisione. Per un nuovo strumento di IA, la tecnologia non può valutarlo in isolamento. Anche sicurezza, legale e conformità devono capire come gestisce i dati aziendali o dei clienti, quali vincoli si applicano e se può essere utilizzato in modo sicuro su larga scala.

A volte il team AI SWAT lavora anche su programmi specifici, come l’aggiornamento delle competenze, dove definiamo obiettivi, tracciamo roadmap e decidiamo come verranno integrati i diversi gruppi. Questo è davvero il modo in cui funziona: tenere le persone informate, collaborare su programmi specifici e fornire al consiglio una visibilità su ciò che sta accadendo con l’IA in tutta l’azienda.

Stai osservando atteggiamenti molto diversi verso lo sviluppo software assistito dall’IA, con alcune organizzazioni che stanno attivamente scalando lo sviluppo agente mentre altre vietano ancora il codice generato dall’IA. Cosa spiega questa divisione e cosa deve cambiare prima che le imprese più attente al rischio si sentano a proprio agio con un ruolo più ampio dell’IA nell’ingegneria del software?

Probabilmente ciò che guida la differenza tra chi dice no e chi dice sì è la loro propensione al rischio e il loro atteggiamento verso l’ambiguità e l’incertezza. Ciò che aiuta entrambi i tipi di organizzazioni è l’educazione continua, la sperimentazione e la valutazione. Anche tra le numerose organizzazioni con cui lavoriamo che abbracciano l’IA e la integrano ovunque, rimangono delle sfide nella misurazione dei risultati e dell’impatto. Ad essere onesti, la domanda su come misurare l’impatto dell’IA e su come valutare le prestazioni di un team a volte appare quasi dal nulla, come se nessuno ne avesse mai davvero pensato prima.

Una volta che inizi a valutare un’iniziativa di IA in modo più approfondito, cominci a comprendere l’impatto e il valore che ti sta realmente offrendo, il che porta a decisioni migliori su dove la tecnologia abbia senso. Per le aziende che dicono no all’IA, è comunque necessario un processo continuo di revisione di ciò che la tecnologia può fare e di dove si trovi attualmente. Non vuoi che una decisione presa tre anni fa rimanga una politica aziendale semplicemente perché nessuno ha rivisto le ipotesi alla base.

L’IA agentica rende sempre più facile per i singoli team creare i propri agenti, potenzialmente generando più agenti che svolgono compiti quasi identici. A che punto la sperimentazione diventa un proliferare di agenti, e che tipo di livello di governance è necessario per gestire la proprietà, le autorizzazioni, la duplicazione e la gestione del ciclo di vita?

Quando osserviamo uno scenario tipico in cui una licenza IA viene concessa a ogni sviluppatore e la sperimentazione diventa non guidata, tutti iniziano a creare le proprie soluzioni e a lavorare a modo loro. Tipicamente, ciò porta a team con prestazioni inferiori, aspettative non soddisfatte, qualità in calo e costi in aumento. In sostanza, non fa quello che tutti si aspettano, la qualità è scarsa e diventa costosa. Per mitigare la situazione, è necessario che sia uno sforzo di squadra inserito in un più ampio impegno dipartimentale o organizzativo, ed è qui che entra in gioco la governance.

A livello di progetto, è possibile concordare la base di conoscenza e il contesto, così come i casi d’uso in cui si inizia a utilizzare l’IA. Successivamente si creano competenze e agenti che fanno parte del flusso di lavoro di sviluppo e che tutti possono riutilizzare, così da accumulare conoscenza e migliori pratiche invece di ricrearli ogni volta. Tale sforzo a livello di progetto dovrebbe poi essere orchestrato da un organo come un board di architettura aziendale, un gruppo tecnologico, il CTO o un team responsabile dell’adozione dell’IA. Si desidera riutilizzare agenti che funzionano bene, garantire che il processo sia solido e far sì che funzioni in tutta l’organizzazione, evitando il caos e il rumore.

Quindi penso che debba essere uno sforzo sincronizzato a livello di progetto, forse a livello di programma, e poi anche a livello di dipartimento e organizzativo.

Il consumo di token e i costi di inferenza possono apparire relativamente ridotti durante un pilota, ma diventano significativi quando i sistemi di IA vengono distribuiti a migliaia di dipendenti o agenti autonomi. Come dovrebbero le imprese affrontare la gestione dei costi dell’IA, e vi aspettate che emerga qualcosa di simile al FinOps specificamente per i carichi di lavoro IA?

Inizio dicendo che uno scenario quasi ideale è quando i costi dell’IA aumentano, raggiungono un plateau e poi cominciano a diminuire leggermente nel tempo. Questo indica che è possibile prevedere, controllare i costi, capire su cosa si sta realmente spendendo per l’IA e vedere i risultati delle decisioni prese. Le situazioni negative si verificano quando i costi continuano a oscillare perché ciò indica solitamente una mancanza di sostenibilità, oppure quando i costi salgono e poi crollano completamente perché l’adozione potrebbe non avvenire, qualcosa non funziona, o le persone usano altro e semplicemente non lo si vede.

Quindi il FinOps esiste, e anche il FinOps per l’IA esiste. Alcune tecniche sono molto tecniche, mentre altre sono piuttosto semplici. Può essere qualcosa di basilare, come scegliere il modello preferito in modo da non dipendere sempre dal più costoso, e decisione dopo decisione queste scelte iniziano a far risparmiare denaro. Allo stesso tempo, sapere come risparmiare e controllare i costi è solo metà dell’equazione. Il FinOps, così come lo vedo, è una disciplina e una metodologia che coinvolge anche i leader di prodotto e di business, poiché è necessario definire cosa si sta misurando quando si valutano gli sforzi di IA.

Sì, penso che il FinOps per l’IA sia un buon argomento per l’equivalente di un team SWAT IA da discutere: quanto si spende, quanto si recupera, come lo si controlla e dove si trovano le opportunità.

Molte aziende sono invitate a dimostrare il ROI dell’IA anche se non hanno mai stabilito una baseline affidabile sulla produttività dei loro team prima dell’introduzione dell’IA. Cosa dovrebbero realmente misurare le organizzazioni se vogliono determinare se l’IA sta creando un valore commerciale significativo?

Indipendentemente dal tuo atteggiamento verso l’IA o dalla tua situazione attuale, forse stai già usando agenti dappertutto o forse pensi che l’anno prossimo inizierai a usare l’IA; stabilire una baseline è assolutamente indispensabile al giorno d’oggi.

Esistono diverse classi di metriche. Alcune sono soggettive e possono semplicemente derivare dal feedback dei tuoi sviluppatori o dipendenti, poiché lavori con le persone ed è importante capire come percepiscono il valore dell’IA. Misure più oggettive possono partire da metriche meccaniche o sintetiche, sebbene esorterei tutti a non legarsi troppo strettamente a esse. Intendo cose come i commit di codice o i story point. Queste metriche dimostrano che il lavoro è avvenuto, ma non mostrano realmente il valore o l’impatto.

Ciò che conta di più sono le metriche che spiegano quanto rapidamente o quanto bene il lavoro è stato consegnato. Pensate alle metriche DORA, come il lead time o il MTTR, a quanto velocemente potete riprendervi da un guasto, a quanto rapidamente potete correggere un bug in produzione, o a come queste misure cambiano nel tempo. Un valore in un dato momento non indica la traiettoria. Uno dei nostri architetti ha riferito recentemente che, nello sviluppo software, una buona metrica potrebbe anche essere l’affidabilità delle stime man mano che l’adozione dell’IA cresce, perché ciò fornisce indicazioni sulla sostenibilità di questi sforzi e su quanto siano realmente produttivi i team. È inoltre necessario tenere traccia dei costi, perché se si parla solo dei benefici senza comprendere quanto costi realizzarli, non si ha il quadro completo.

Al di fuori dello sviluppo software, lo penso in modo simile. In ogni flusso di lavoro o processo esiste un’unità di lavoro e una definizione di completamento. Che si tratti di elaborare richieste, revisionare documenti o gestire richieste dei clienti, definite cosa state consegnando e poi misurate quanto tempo ci è voluto prima dell’IA, quanto rapidamente e quanto bene potete farlo ora, e a che costo. Questo vi fornisce un buon punto di partenza sia per la baseline sia per il quadro delle metriche.

DataArt ha integrato l’IA lungo l’intero ciclo di vita della consegna del software attraverso iniziative come Artisyn. Man mano che l’IA assume più compiti di implementazione, test e flusso di lavoro, quali parti dell’ingegneria del software diventano più preziose per gli esseri umani e quali competenze rischiano di diventare meno importanti?

Puoi utilizzare l’IA in modo efficace nello sviluppo solo se ricordi ancora qual è la definizione di buono. Hai bisogno di quella competenza per guidare i tuoi agenti, rivedere i risultati, impostare vincoli e definire le regole. Devi comprendere quali siano le best practice e come dovrebbe apparire una buona architettura, perché senza ciò potresti non sapere cosa si sta sviluppando, e il valore di questo tipo di competenza sta aumentando in modo molto, molto significativo.

Comprendere i pattern architetturali è importante, così come capire cosa sia appropriato in una determinata industria, applicazione o classe di soluzione. È necessario sapere quale tipo di architettura è adeguata al momento e quale continuerà a esserlo quando la soluzione scala, perché a volte la stessa architettura non funziona per l’intera durata di una soluzione o piattaforma.

Quel bilanciamento di ciò che è appropriato per una soluzione specifica è la parte umana. È il gusto, l’artigianato che sta dietro ai servizi e allo sviluppo software. Devi sapere cosa stai facendo, e ciò deriva anche dalla comprensione del cliente e del settore.

Quali competenze sono meno importanti? È davvero difficile per me dirlo, anche se forse la velocità con cui si può digitare codice. Sto scherzando, ma il codice può ora essere creato molto, molto più rapidamente, e la conoscenza specifica di una determinata libreria o linguaggio può essere appresa molto più velocemente con l’IA.

Ho visto sviluppatori .NET riqualificati come sviluppatori Java molto rapidamente, e cinque o dieci anni fa avrei detto che farlo su larga scala era quasi impossibile. Oggi, è possibile. Uno sviluppatore senior competente può spostarsi sempre più tra i linguaggi perché ciò che conta davvero è la sua comprensione della tecnologia, dell’architettura, delle best practice di soluzione, del SDLC e dell’ADLC.

Man mano che le imprese passano da decine di progetti pilota di IA a sistemi di produzione in grado di agire autonomamente, dove dovrebbe risiedere in ultima analisi la responsabilità quando un agente IA commette un errore costoso: con lo sviluppatore, il proprietario dell’azienda, il fornitore del modello, il team di governance o una combinazione di essi?

Mi piace l’idea di una collaborazione senza colpe e di responsabilità condivisa, perché tutti nell’organizzazione contribuiscono alle best practice, ai framework architetturali e alle soluzioni. Anche se un sviluppatore crea codice con l’IA o senza IA, un altro sviluppatore lo revisiona, i team lead forniscono indicazioni, gli architetti definiscono l’architettura e i vincoli, e il team di governance partecipa alle decisioni su budget, tempistiche e rilascio. Tutti sono coinvolti in qualche modo.

Molto spesso, quando qualcosa va storto, è il processo a non funzionare, quindi in questo senso la responsabilità è condivisa tra diversi ruoli. Ma se ci si limita a dire che la responsabilità è condivisa e quindi senza colpe, non è sufficiente. Deve comunque essere suddivisa in responsabilità specifiche.

Gli sviluppatori sono responsabili del codice che inviano come pull request e devono comprendere cosa vi accade. Gli architetti sono responsabili delle decisioni che prendono e delle scelte architetturali fornite ad agenti e sviluppatori. Il team di piattaforma è responsabile dell’affidabilità della soluzione, indipendentemente da chi o cosa abbia creato una determinata riga di codice.

Quindi la responsabilità esiste, ma è necessario definirla in modo granulare per team, ruolo e dipartimento. Ciò che non si può fare è fermare l’analisi al “l’IA ha fatto questo”. Bisogna chiedersi quali controlli, test o supervisioni hanno permesso a quel fallimento di arrivare in produzione.

Se la mancanza di test unitari ha consentito che codice difettoso fosse spinto in produzione, o la mancanza di supervisione e revisione ha permesso che ciò accadesse, non si può delegare quella responsabilità all’IA. Non si può nemmeno incolpare semplicemente il fornitore del modello o il provider cloud per ogni bug o interruzione.

Grazie per la fantastica intervista, i lettori che desiderano saperne di più dovrebbero visitare DataArt.