Yuri Gubin, CTO la DataArt – Seria de interviuri

Yuri Gubin, CTO la DataArt este un executiv veterân în tehnologie și arhitect software care a petrecut peste 18 ani la DataArt, evoluând prin roluri ce acoperă arhitectura software, arhitectura de soluții, tehnologia cloud, inovație și conducere executivă înainte de a deveni Chief Technology Officer în martie 2026. Munca sa s-a concentrat pe rezolvarea provocărilor tehnologice complexe în industrii precum servicii financiare, sănătate, călătorii și IoT, având o expertiză deosebită în cloud computing, AI, platforme de date și arhitectura software enterprise. Înainte de a deveni CTO, Gubin a ocupat funcția de Chief Innovation Officer la DataArt timp de peste cinci ani și este membru al Board of Partners al companiei din 2021. De asemenea, este membru profesionist al Forbes Technology Council, participând în grupurile de experți în AI și Cloud Computing, și acționează ca consilier tehnologic pentru Girls Who Code, unde oferă consultanță în arhitectură, protecția datelor, guvernanța platformei și politica tehnologică. DataArt îl listează în prezent ca Chief Technology Officer, cu sediul în New York.

DataArt este o companie globală de inginerie software și transformare a datelor și AI, fondată în New York în 1997. Compania a crescut la peste 6.000 de profesioniști în tehnologie care operează în peste 20 de țări și colaborează cu peste 400 de clienți, oferind servicii în domenii precum inteligență artificială și învățare automată, date și analiză, transformare cloud, inginerie software personalizată, securitate cibernetică și modernizare a sistemelor vechi. DataArt activează în sectoare cum ar fi servicii financiare, sănătate și științe ale vieții, călătorii, media și divertisment, și retail, și menține parteneriate tehnologice cu platforme precum AWS, Google Cloud, Microsoft Azure, Snowflake și Databricks. În 2025, compania a anunțat o investiție de 100 de milioane de dolari, pe o perioadă de trei ani, în capacitățile sale de date și AI, urmată în 2026 de lansarea Artisyn, un model operațional alimentat de AI conceput să integreze agenți AI, acceleratori reutilizabili, guvernanță, securitate și conformitate în dezvoltarea de software enterprise.

„Ai petrecut aproape două decenii la DataArt, evoluând de la arhitect software și arhitect de soluții la Chief Innovation Officer și acum CTO. Cum a modelat această călătorie modul în care distingi tehnologiile cu adevărat transformatoare de ciclurile de hype și cum influențează „optimismul sceptic” față de AI în prezent?”

Am observat multe valuri diferite de-a lungul anilor, inclusiv ascensiunea cloud-ului și a mobilului, diferite generații de AI, automatizare, DevOps și SRE, și am programat, arhitectat și consiliat clienții noștri pe multe dintre aceste subiecte în tot acest timp. Am realizat că, da, poți face aproape orice cu tehnologia, iar tehnologia este destul de puternică, dar diavolul se ascunde în detalii și trebuie să știi ce faci pentru ca aceasta să aibă sens și să funcționeze.

Am văzut mediile cloud devenind tot mai scumpe, modele AI care nu performează așa cum te aștepți și încercări prost implementate de automatizare a ciclurilor de lansare. Am observat impactul atât al deciziilor bune, cât și al celor proaste, așa că ori de câte ori apare ceva nou și citești toate anunțurile, promisiunile și hype-ul, revin la aceeași premisă: aproape orice este posibil cu tehnologia, dar trebuie să știi ce faci.

Obții o înțelegere solidă a unei tehnologii prin cercetare și dezvoltare și, mai ales, prin proiecte din viața reală, deoarece așa înveți ce este posibil, ce nu este și unde pot apărea probleme. Preiei acele lecții din fiecare colaborare, discuți cu colegii, alți arhitecți și analiști și încerci să înțelegi dacă există tipare și dacă poți crea un fel de sistem în jurul lor. În cele din urmă, acestea devin ghidaj, iar apoi vezi dacă deciziile pe care le-ai considerat bune produc cu adevărat rezultate pozitive.

Asta este sursa optimismului sceptic. Orice promite tehnologia, tot trebuie să știi ce faci, iar această cunoaștere provine din experiență, colaborare și un efort continuu de a învăța, de a te perfecționa și de a crea un fel de sistem în spatele hype-ului.

„AI-ul enterprise pare să treacă de la o fază de încurajare a experimentării la decizia asupra experimentelor care merită cu adevărat să fie scalate. Ce semnale îți indică că un caz de utilizare AI este pregătit pentru o implementare mai largă și care sunt semnele de avertizare că o companie scalează prea devreme?”

Foloses două metode pentru a înțelege dacă putem scala ceva sau dacă trebuie să facem altceva: curba de adoptare și curba de învățare.

Pentru a înțelege dacă un caz de utilizare AI funcționează, trebuie să îi acorzi timp și să înțelegi ce valoare aduce și cum arată parcursul utilizatorului, pentru că astfel poți observa fluctuațiile în loc să te uiți doar la efectul imediat „wow” dintr-o echipă sau flux de lucru. Trebuie să vezi ce se întâmplă cu aceleași persoane la câteva săptămâni după aceea. Continuă să îl folosească? Sunt încă mulțumiți de acel caz de utilizare, de acea automatizare sau de acea abilitate AI pe care au creat-o, sau a fost doar o apariție trecătoare care nu ar trebui să fie scalată?

Unele dintre aceste lucruri pot fi validate doar în timp. Vor exista întotdeauna primii pionieri, de obicei cei mai pricepuţi din punct de vedere tehnic și cei foarte curioşi, iar apoi trebuie să le testezi cu alte segmente, cu cei care urmează adoptatorii timpurii și apoi majoritatea timpurie. Odată ce se dovedeşte acolo, da, poţi începe să o scalezi și să extinzi acel caz de utilizare către alte departamente.

Fiecare lansare majoră de model poate crea presiune în interiorul unei organizaţii pentru a oferi imediat angajaţilor acces la cele mai noi capabilităţi. Cum ar trebui liderii tehnologici să evalueze dacă un model nou reprezintă o îmbunătăţire semnificativă în loc să genereze pur şi simplu un alt val de experimentare şi costuri?

Iată din nou optimismul meu sceptic. Presupune că ai deja un model în funcţiune şi câteva mii de persoane care folosesc zilnic AI, cu diferite modele şi instrumente deja disponibile. Când apare un model nou, din cauza hype‑ului şi curiozităţii naturale, poţi să te aştepţi ca toată lumea să vrea să experimenteze cu el, ceea ce este bine, dar acea experimentare s‑ar putea să nu fie neapărat ghidată sau orientată spre rezultate specifice, şi uneori nici nu vei putea măsura diferenţa.

La scară, asta contează. Nu este vorba doar de una sau două persoane care se joacă să vadă cum se comportă modelul nou în comparaţie cu cel vechi. Pot fi mii de oameni care îşi petrec timpul experimentând, iar pentru un anumit caz de utilizare rezultatul poate să nu fie atât de semnificativ. În acelaşi timp, dacă ceva funcţionează foarte bine, învăţăturile despre ce funcţionează în cadrul organizaţiei tale s‑ar putea să nu fie explicate clar sau vizibile pentru toată lumea.

De aceea primul grup care evaluează un model nou nu ar trebui să fie toţi din organizaţie. Ar trebui să fie un grup de R&D care lucrează îndeaproape cu echipele relevante, precum şi cu departamentele juridic şi de securitate. Evaluăm modelul în mod cuprinzător, facem o evaluare rapidă şi apoi îl prezentăm unui public mai larg cu câteva comentarii şi îndrumări privind securitatea, conformitatea şi tehnologia. Odată cu apariţia constantă a modelelor noi şi a actualizărilor majore, trebuie să ai acest model şi această mentalitate în vigoare. Nu este cu adevărat un exerciţiu unic sau ocazional.

DataArt a creat un grup transversal „AI SWAT” care implică tehnologie, juridic, conformitate, InfoSec şi alte echipe. Cum funcţionează acest grup în practică şi ce tipuri de riscuri sau întrebări trebuie rezolvate înainte ca un nou instrument AI să fie aprobat pentru utilizare mai largă?

De la început, cred că am stabilit diferite obiective pentru acest grup la fiecare patru sau cinci luni aproximativ. Schimbăm prioritatea, scopul şi uneori misiunea, iar multe dintre aceste obiective se învârt în jurul AI. Poate fi dezvoltarea competenţelor forţei de muncă, lansarea pe piaţă şi noi capabilităţi, parteneriate sau facilitarea AI la scară mai largă în cadrul organizaţiei şi în întregul ADLC.

Subiectele exacte evoluează în timp, şi cred că este sănătos deoarece trebuie să revizuieşti constant propria strategie, să validezi ipotezele şi să înţelegi dacă trebuie să schimbi direcţia şi care ar trebui să fie următoarea temă pentru echipă.

Grupul implică reprezentanţi din diferite departamente, iar unul dintre scopurile sale este pur şi simplu să ţină pe toată lumea informată. Ori de câte ori există un anunţ nou, o întrebare sau o oportunitate, cineva poate aduce subiectul la una dintre întâlnirile noastre periodice. Chiar dacă pare o întrebare tehnologică relevantă doar pentru o echipă restrânsă, în prezent aceste subiecte pot avea implicaţii pentru multe părţi ale organizaţiei.

De aceea, atunci când evaluăm un nou parteneriat, instrument sau accelerator, îl discutăm deschis pentru ca toată lumea să înţeleagă încotro se îndreaptă lucrurile şi să aibă ocazia să pună întrebări sau să ofere supraveghere. Pentru un nou instrument AI, tehnologia nu îl poate evalua izolat. Securitatea, juridic şi conformitatea trebuie, de asemenea, să înţeleagă cum gestionează datele companiei sau ale clienţilor, ce constrângeri se aplică şi dacă poate fi utilizat în siguranţă la scară largă.

Uneori echipa AI SWAT lucrează şi la programe specifice, cum ar fi dezvoltarea competenţelor, unde stabilim obiective, conturăm foile de parcurs şi decidem cum vor fi integrate diferite grupuri. Aşa funcţionează cu adevărat: menţinerea oamenilor informaţi, colaborarea la programe specifice şi oferirea de vizibilitate consiliului privind ce se întâmplă cu AI în întreaga companie.

Observi atitudini foarte diferite faţă de dezvoltarea software asistată de AI, unele organizaţii scalând activ dezvoltarea agentică, în timp ce altele încă interzic codul generat de AI. Ce explică această divizare şi ce trebuie să se schimbe înainte ca întreprinderile mai conştiente de risc să devină confortabile cu AI având un rol mai mare în ingineria software?

Probabil că diferența dintre cei care spun nu și cei care spun da este apetitul lor pentru risc și atitudinea față de ambiguitate și incertitudine. Ce ajută ambele tipuri de organizații este educația continuă, experimentarea și evaluarea. Chiar și în rândul multor organizații cu care colaborăm și care adoptă AI peste tot, există în continuare provocări legate de măsurarea rezultatului și impactului. Pentru a fi sincer, întrebarea despre cum măsori impactul AI și cum evaluezi performanța unei echipe apare uneori din senin, ca și cum nimeni nu s-ar fi gândit la asta înainte.

Odată ce începi să evaluezi o inițiativă AI mai cuprinzător, începi să înțelegi impactul și valoarea pe care ți le oferă cu adevărat, ceea ce duce la decizii mai bune privind unde are sens tehnologia. Pentru companiile care spun nu AI-ului, trebuie să existe în continuare un proces constant de revizuire a ceea ce poate face tehnologia și a stadiului său actual. Nu vrei ca o decizie luată în urmă cu trei ani să rămână politică companială doar pentru că nimeni nu a revizuit ipotezele din spatele ei.

Agentic AI face din ce în ce mai ușor pentru echipele individuale să își creeze proprii agenți, ceea ce poate duce la multiple agenți care îndeplinesc sarcini aproape identice. La ce moment experimentarea devine o proliferare de agenți și ce tip de strat de guvernanță este necesar pentru a gestiona proprietatea, permisiunile, duplicarea și gestionarea ciclului de viață?

Când observăm un scenariu tipic în care fiecărui dezvoltator i se acordă o licență AI și experimentarea devine neorientată, toată lumea începe să își creeze propriile lucruri și să lucreze în felul său. În mod obișnuit, acest lucru duce la echipe subperformante, așteptări neîndeplinite, calitate în scădere și cheltuieli în creștere. Concluzia este că nu oferă ceea ce toată lumea așteaptă, calitatea este slabă și devine costisitor. Pentru a atenua această situație, trebuie să fie un efort de echipă care face parte dintr-un efort mai larg al departamentului sau al organizației, și aici intervine guvernanța.

La nivel de proiect, poți conveni asupra bazei de cunoștințe și a contextului, precum și asupra cazurilor de utilizare în care începi să folosești AI. Apoi creezi competențe și agenți care fac parte din fluxul de lucru de dezvoltare și pe care toată lumea îi poate reutiliza, astfel acumulând cunoștințe și bune practici în loc să le recreezi de fiecare dată. Acest efort la nivel de proiect ar trebui apoi orchestrat de ceva precum un board de arhitectură enterprise, un grup tehnologic, CTO-ul sau o echipă responsabilă de adoptarea AI. Vrei să reutilizezi agenți care funcționează bine, să te asiguri că procesul este solid și să le faci să funcționeze în întreaga organizație, în loc să se transforme în haos și zgomot.

Așadar, cred că trebuie să fie un efort sincronizat la nivel de proiect, poate la nivel de program, și apoi și la nivelul departamentului și al organizației.

Consumul de tokenuri și costurile de inferență pot părea relativ mici în timpul unui pilot, dar devin semnificative când sistemele AI sunt implementate la mii de angajați sau agenți autonomi. Cum ar trebui întreprinderile să abordeze gestionarea costurilor AI și așteptați-vă la apariția a ceva asemănător cu FinOps, specific sarcinilor AI?

Voi începe prin a spune că un scenariu aproape ideal este când costurile AI cresc, ating un platou și apoi încep să scadă ușor în timp. Acest lucru îți arată că poți prognoza, controla costurile, înțelege la ce cheltuiești efectiv pe AI și să vezi rezultatele deciziilor pe care le iei. Situațiile nefavorabile apar când costurile fluctuează în sus și în jos, deoarece de obicei înseamnă că ceva nu este sustenabil, sau când costurile cresc și apoi scad brusc pentru că adoptarea poate să nu aibă loc, ceva nu funcționează sau oamenii folosesc altceva și pur și simplu nu observi acest lucru.

Așadar, FinOps există, iar FinOps pentru AI există de asemenea. Unele tehnici sunt foarte tehnice, în timp ce altele sunt destul de simple. Poate fi la fel de simplu ca alegerea modelului preferat pentru a nu te baza mereu pe cel mai scump, iar pas cu pas acele decizii încep să economisească bani. În același timp, a ști cum să economisești și să controlezi costurile reprezintă doar jumătate din ecuație. FinOps, așa cum îl văd eu, este o disciplină și metodologie care implică și liderii de produs și de afaceri, deoarece trebuie să definiți ce măsurați când evaluați eforturile AI.

Așadar, da, cred că FinOps pentru AI este un subiect potrivit pentru echivalentul unei echipe AI SWAT de discutat: cât cheltui, cât recuperezi, cum îl controlezi și unde se află oportunitățile.

Multe companii sunt solicitate să demonstreze ROI din AI, deși nu au stabilit niciodată o bază de referință fiabilă pentru productivitatea echipelor lor înainte de introducerea AI. Ce ar trebui să măsoare organizațiile cu adevărat dacă doresc să determine dacă AI creează o valoare de afaceri semnificativă?

Indiferent de atitudinea ta față de AI sau de poziția în care te afli în prezent, poate că deja folosești agenți peste tot sau poate că te gândești că anul viitor vei începe să folosești AI; stabilirea unei baze de referință este absolut esențială în zilele noastre.

Există mai multe clase de metrici. Unele sunt subiective și pot fi pur și simplu feedback-ul de la dezvoltatorii sau angajații tăi, deoarece lucrezi cu oameni și este important să înțelegi cum percep ei valoarea AI. Măsurile mai obiective pot începe cu metrici mecanice sau sintetice, deși îi îndemn pe toți să nu se atașeze prea strâns de ele. Mă refer la lucruri precum commit-urile de cod sau story points. Aceste metrici arată că s-a lucrat, dar nu reflectă cu adevărat valoarea sau impactul.

Ce contează cu adevărat sunt metricile care explică cât de repede sau cât de bine a fost livrată munca. Gândiți-vă la metricile DORA, cum ar fi timpul de livrare sau MTTR, cât de repede puteți să vă recuperați dintr-o defecțiune, cât de repede puteți remedia un bug în producție, sau cum se modifică aceste măsurători în timp. Un număr la un moment dat nu vă spune traiectoria. Unul dintre arhitecții noștri a menționat recent că, în dezvoltarea software, o metrică bună ar putea fi și cât de fiabile sunt estimările pe măsură ce adoptarea AI crește, deoarece asta spune ceva despre sustenabilitatea acestor eforturi și cât de productive sunt cu adevărat echipele. De asemenea, trebuie să urmăriți costurile, deoarece dacă vorbiți doar despre beneficii fără să înțelegeți ce costă să le obțineți, nu aveți o imagine completă.

În afara dezvoltării software, mă gândesc la aceeași manieră. În fiecare flux de lucru sau proces există o anumită unitate de muncă și o definiție a finalizării. Indiferent dacă procesați cereri, revizuiți documente sau gestionați solicitări ale clienților, definiți ce livrați și apoi măsurați cât a durat înainte de AI, cât de repede și cât de bine puteți face asta acum și care sunt costurile. Acest lucru vă oferă un punct de plecare bun atât pentru linia de bază, cât și pentru cadrul metricilor.

DataArt a integrat AI pe tot parcursul ciclului de viață al livrării software prin inițiative precum Artisyn. Pe măsură ce AI preia tot mai multe sarcini de implementare, testare și flux de lucru, care părți ale ingineriei software devin mai valoroase pentru oameni și ce competențe riscă să devină mai puțin importante?

Nu puteți folosi AI eficient în dezvoltare dacă nu vă amintiți încă definiția de bun. Aveți nevoie de acea expertiză pentru a ghida agenții, a revizui rezultatul, a stabili constrângerile și a defini regulile. Trebuie să înțelegeți ce reprezintă cele mai bune practici și cum ar trebui să arate o arhitectură bună, deoarece, fără acestea, s-ar putea să nu știți ce se dezvoltă, iar valoarea acestui tip de expertiză crește foarte, foarte semnificativ.

Înțelegerea modelelor arhitecturale contează, la fel ca și înțelegerea a ceea ce este potrivit într-o anumită industrie, aplicație sau clasă de soluție. Trebuie să știți ce tip de arhitectură este bună în prezent și ce tip va rămâne bun când soluția se scalează, deoarece uneori aceeași arhitectură nu funcționează pe parcursul întregii durate a unei soluții sau platforme.

Echilibrul a ceea ce este potrivit pentru o anumită soluție reprezintă partea umană. Aceasta este gustul, măiestria din spatele serviciilor și dezvoltării software. Trebuie să știți ce faceți, iar acest lucru provine și din înțelegerea clientului și a industriei.

Ce competențe devin mai puțin importante? Este foarte greu să răspund, deși poate cât de repede puteți tasta cod. Glumesc, dar codul poate fi acum creat mult, mult mai rapid, iar cunoașterea specifică a unei anumite biblioteci sau limbaj poate fi învățată mult mai repede cu AI.

Am văzut dezvoltatori .NET recalificați ca dezvoltatori Java foarte repede, și acum cinci sau zece ani aș fi spus că a face asta la scară era aproape imposibil. În prezent, puteți. Un dezvoltator senior puternic poate trece din ce în ce mai des de la un limbaj la altul, deoarece ceea ce contează cu adevărat este înțelegerea tehnologiei, a arhitecturii, a celor mai bune practici de soluție, a SDLC și ADLC.

Pe măsură ce întreprinderile trec de la zeci de proiecte pilot AI la sisteme de producție care pot acționa independent, unde ar trebui să stea în final responsabilitatea când un agent AI comite o greșeală costisitoare: la dezvoltator, la proprietarul afacerii, la furnizorul modelului, la echipa de guvernanță sau la o combinație a acestora?

Îmi place ideea de colaborare fără vinovăție și responsabilitate partajată, deoarece toată organizația contribuie la cele mai bune practici, cadrele arhitecturale și soluții. Chiar dacă un dezvoltator creează cod cu AI sau fără AI, alt dezvoltator îl revizuiește, liderii de echipă oferă îndrumare, arhitecții furnizează arhitectura și constrângerile, iar echipa de guvernanță contribuie la deciziile privind bugetele, termenele și lansările. Toți sunt implicați într-un fel.

De multe ori, când ceva nu merge bine, este procesul care nu funcționează, așa că, în acest sens, responsabilitatea este împărțită între diferite roluri. Dar dacă spuneți pur și simplu că responsabilitatea este partajată și, prin urmare, fără vinovăție, nu este suficient. Trebuie în continuare să fie defalcată în responsabilități specifice.

Dezvoltatorii sunt responsabili pentru codul pe care îl trimit ca pull request și trebuie să înțeleagă ce se întâmplă acolo. Arhitecții sunt responsabili pentru deciziile pe care le iau și pentru deciziile arhitecturale furnizate agenților și dezvoltatorilor. Echipa de platformă este responsabilă pentru fiabilitatea soluției, indiferent cine sau ce a creat linia respectivă de cod.

Așadar responsabilitatea există, dar trebuie să o definiți granular, pe echipă, rol și departament. Ce nu puteți face este să opriți analiza la „AI a făcut asta”. Trebuie să întrebați ce controale, teste sau supraveghere au permis acelei defecțiuni să ajungă în producție.

Dacă lipsa testelor unitare a permis codului defect să fie împins în producție, sau lipsa supravegherii și revizuirii a permis acest lucru, nu puteți delega acea responsabilitate AI-ului. De asemenea, nu puteți pur și simplu să învinuiți furnizorul modelului sau furnizorul de cloud pentru fiecare bug sau întrerupere.

Vă mulțumim pentru interviul excelent, cititorii care doresc să afle mai multe ar trebui să viziteze DataArt.