Yuri Gubin, CTO bij DataArt – Interviewreeks

Yuri Gubin, CTO bij DataArt is een doorgewinterde technologie‑executive en software‑architect die meer dan 18 jaar bij DataArt heeft gewerkt, waarbij hij zich heeft ontwikkeld door functies die variëren van software‑architectuur, solutions‑architectuur, cloud‑technologie, innovatie tot leidinggevende rollen, voordat hij in maart 2026 Chief Technology Officer werd. Zijn werk richt zich op het oplossen van complexe technologische uitdagingen in sectoren zoals financiële dienstverlening, gezondheidszorg, reizen en IoT, met bijzondere expertise in cloud‑computing, AI, dataplatformen en enterprise‑software‑architectuur. Voordat hij CTO werd, was Gubin meer dan vijf jaar Chief Innovation Officer bij DataArt en sinds 2021 lid van de Board of Partners van het bedrijf. Hij is tevens professioneel lid van de Forbes Technology Council, waar hij deelneemt aan de AI‑ en Cloud Computing‑expertgroepen, en dient als Technology Advisor voor Girls Who Code, waar hij adviseert over architectuur, gegevensbescherming, platform‑governance en technologisch beleid. DataArt vermeldt hem momenteel als Chief Technology Officer, gevestigd in New York.

DataArt is een wereldwijd software‑engineerings- en data‑ en AI‑transformatiebedrijf dat in 1997 in New York is opgericht. Het bedrijf is gegroeid tot meer dan 6.000 technologische professionals die actief zijn in meer dan 20 landen en werkt met meer dan 400 klanten, waarbij het diensten levert op gebieden zoals kunstmatige intelligentie en machine learning, data en analytics, cloudtransformatie, maatwerksoftware‑engineering, cybersecurity en modernisering van legacy‑systemen. DataArt opereert in sectoren als financiële dienstverlening, gezondheidszorg en life sciences, reizen, media en entertainment, en detailhandel, en onderhoudt technologische partnerschappen met platforms zoals AWS, Google Cloud, Microsoft Azure, Snowflake en Databricks. In 2025 kondigde het bedrijf een investering van $100 miljoen voor drie jaar aan in zijn data‑ en AI‑capaciteiten, gevolgd in 2026 door de lancering van Artisyn, een AI‑enabled operationeel model dat is ontworpen om AI‑agents, herbruikbare accelerators, governance, beveiliging en compliance te integreren in de ontwikkeling van enterprise‑software.

Je hebt bijna twee decennia bij DataArt doorgebracht, van software‑architect en solutions‑architect tot Chief Innovation Officer en nu CTO. Hoe heeft die reis jouw manier gevormd om echt transformerende technologieën te onderscheiden van hype‑cycli, en hoe beïnvloedt dit jouw “skeptisch optimisme” ten opzichte van AI vandaag?

We hebben door de jaren heen vele verschillende golven gezien, waaronder de opkomst van cloud en mobiel, verschillende generaties AI, automatisering, DevOps en SRE, en ik heb gedurende die tijd geprogrammeerd, ontworpen en onze klanten geadviseerd over veel van deze onderwerpen. Wat ik me realiseerde is dat je, ja, bijna alles kunt doen met technologie, en technologie is behoorlijk krachtig, maar de duivel zit in de details en je moet weten wat je doet om het zinvol en werkbaar te maken.

Ik heb gezien dat cloudomgevingen steeds duurder worden, AI‑modellen die niet presteren zoals je verwacht, en slecht uitgevoerde pogingen om release‑cycli te automatiseren. Ik heb de impact van zowel goede als slechte beslissingen gezien, dus telkens wanneer er iets nieuws opduikt en je alle aankondigingen, beloftes en hype leest, keer ik terug naar dezelfde premisse: bijna alles is mogelijk met technologie, maar je moet weten wat je doet.

Je krijgt een goed begrip van een technologie door R&D en, belangrijker nog, door real‑life projecten, want zo leer je wat mogelijk is, wat niet, en waar dingen mis kunnen gaan. Je haalt die lessen uit elke opdracht, spreekt met je collega‑architecten en analisten, en probeert te begrijpen of er patronen zijn en of je er een soort systeem omheen kunt bouwen. Uiteindelijk wordt dat richtlijn, en zie je of de beslissingen die je als goed beschouwde daadwerkelijk goede resultaten opleveren.

Dat is waar het sceptisch optimisme vandaan komt. Hoeveel technologie ook belooft, je moet nog steeds weten wat je doet, en die kennis komt voort uit ervaring, samenwerking en een voortdurende inspanning om te leren, beter te worden en een soort systeem achter de hype te creëren.

Enterprise AI lijkt van een fase waarin experimenten worden aangemoedigd, over te gaan naar een fase waarin wordt beslist welke experimenten daadwerkelijk opgeschaald moeten worden. Welke signalen geven aan dat een AI‑use‑case klaar is voor bredere uitrol, en wat zijn de waarschuwingssignalen dat een bedrijf te vroeg opschaalt?

Ik gebruik twee methoden om te bepalen of we iets kunnen opschalen of dat we iets anders moeten doen: de adoptiecurve en de leercurve.

Om te begrijpen of een AI‑use‑case werkt, moet je het wat tijd geven en inzicht krijgen in welke waarde het levert en hoe de gebruikersreis eruitziet, want dan kun je de pieken en dalen zien in plaats van alleen het onmiddellijke ‘wow’-effect in een specifiek team of workflow. Je moet zien wat er een paar weken later met dezelfde mensen gebeurt. Gebruiken ze het nog? Zijn ze nog tevreden met die use‑case, die automatisering of die AI‑vaardigheid die ze hebben gecreëerd, of was het slechts een korte piek die eigenlijk niet opgeschaald mag worden?

Een deel van deze zaken kan alleen in de loop van de tijd worden gevalideerd. Er zullen altijd de eerste pioniers zijn, meestal de technisch meest onderlegde mensen en de zeer nieuwsgierige, en daarna moet je het uitproberen met andere segmenten, met degenen die de vroege adoptanten volgen en vervolgens de vroege meerderheid. Zodra het zich daar heeft bewezen, kun je het inderdaad opschalen en die use case uitbreiden naar andere afdelingen.

Elke grote modelrelease kan binnen een organisatie druk uitoefenen om medewerkers onmiddellijk toegang te geven tot de nieuwste mogelijkheden. Hoe moeten technologische leiders beoordelen of een nieuw model een betekenisvolle verbetering vertegenwoordigt in plaats van simpelweg een nieuwe golf van experimentatie en kosten te genereren?

Hier is mijn sceptische optimisme opnieuw. Stel dat je al een model hebt en enkele duizenden mensen die dagelijks AI gebruiken, met verschillende modellen en tools die al beschikbaar zijn. Wanneer er een nieuw model verschijnt, kun je door de hype en natuurlijke nieuwsgierigheid verwachten dat iedereen ermee wil experimenteren, wat goed is, maar die experimenten zijn misschien niet noodzakelijk geleid of gericht op specifieke resultaten, en soms kun je het verschil zelfs niet meten.

Op schaal maakt dat uit. Het gaat niet alleen om één of twee personen die rondneuzen om te zien hoe het nieuwe model presteert ten opzichte van het oude. Het kunnen duizenden mensen zijn die tijd besteden aan experimenteren, terwijl voor een specifieke use case de uitkomst misschien niet zo significant is. Tegelijkertijd, als iets echt goed werkt, kan de kennis over wat werkt binnen je organisatie niet duidelijk worden uitgelegd of zichtbaar zijn voor iedereen.

Daarom mag de eerste groep die een nieuw model evalueert niet iedereen in de organisatie zijn. Het moet een R&D‑groep zijn die nauw samenwerkt met de relevante teams, evenals juridisch en beveiliging. We evalueren het model grondig, doen een snelle beoordeling, en brengen het vervolgens naar een breder publiek met enkele opmerkingen en richtlijnen over beveiliging, compliance en technologie. Omdat er voortdurend nieuwe modellen en grote updates verschijnen, moet je dit model en deze mentaliteit hebben. Het is echt geen eenmalige of incidentele oefening.

DataArt heeft een cross‑functioneel “AI SWAT” opgezet dat technologie, juridisch, compliance, InfoSec en andere teams omvat. Hoe werkt deze groep in de praktijk, en welke soorten risico’s of vragen moeten worden opgelost voordat een nieuw AI‑instrument wordt goedgekeurd voor breder gebruik?

Sinds de oprichting denk ik dat we ongeveer elke vier of vijf maanden verschillende doelstellingen voor deze groep hebben vastgesteld. We wijzigen de prioriteit, het doel en soms de missie, en veel van deze doelstellingen draaien om AI. Het kan gaan om het bijscholen van het personeel, go‑to‑market en nieuwe mogelijkheden, partnerschappen, of het breder mogelijk maken van AI binnen de organisatie en over de ADLC heen.

De exacte onderwerpen evolueren in de loop van de tijd, en ik denk dat dit gezond is omdat je voortdurend je eigen strategie moet herzien, je aannames moet valideren en moet begrijpen of je moet bijsturen en wat het volgende thema voor het team moet zijn.

De groep omvat vertegenwoordigers van verschillende afdelingen, en een van de doeleinden is simpelweg iedereen geïnformeerd te houden. Wanneer er een nieuwe aankondiging, vraag of kans is, kan iemand dat onderwerp naar een van onze reguliere vergaderingen brengen. Zelfs als het lijkt op een technologische vraag die alleen voor een klein team relevant is, kunnen deze onderwerpen tegenwoordig implicaties hebben voor veel delen van de organisatie.

Daarom bespreken we, wanneer we een nieuw partnerschap, instrument of accelerator evalueren, dit openlijk zodat iedereen begrijpt waar de zaken naartoe gaan en de kans krijgt om vragen te stellen of toezicht te bieden. Voor een nieuw AI‑instrument kan technologie het niet in isolatie beoordelen. Beveiliging, juridisch en compliance moeten ook begrijpen hoe het omgaat met bedrijfs‑ of klantgegevens, welke beperkingen gelden en of het veilig op schaal kan worden gebruikt.

Soms werkt het AI SWAT‑team ook aan specifieke programma’s, zoals bijscholing, waarbij we doelen stellen, roadmaps uitwerken en bepalen hoe verschillende groepen worden geïntroduceerd. Dat is echt hoe het werkt: mensen geïnformeerd houden, samenwerken aan specifieke programma’s, en het bestuur inzicht geven in wat er met AI binnen het bedrijf gebeurt.

Je ziet zeer verschillende houdingen ten opzichte van AI‑ondersteunde softwareontwikkeling, waarbij sommige organisaties actief agent‑gedreven ontwikkeling opschalen terwijl anderen nog steeds AI‑gegenereerde code verbieden. Wat verklaart deze kloof, en wat moet er veranderen voordat meer risico‑bewuste bedrijven zich comfortabel voelen met AI die een grotere rol speelt in software‑engineering?

Waarschijnlijk wordt het verschil tussen degenen die nee zeggen en degenen die ja zeggen gedreven door hun risicobereidheid en hun houding ten opzichte van ambiguïteit en onzekerheid. Wat beide soorten organisaties helpt, is continue educatie, experimentatie en evaluatie. Zelfs bij veel organisaties waarmee we samenwerken die AI omarmen en overal integreren, blijven er uitdagingen bestaan rond het meten van de uitkomst en impact. Om eerlijk te zijn, de vraag hoe je de impact van AI meet en hoe je de prestaties van een team evalueert, komt soms bijna uit het niets, alsof er niemand er eerder echt over heeft nagedacht.

Zodra je een AI-initiatieven grondiger begint te evalueren, begin je de impact en de waarde die het je daadwerkelijk biedt te begrijpen, wat leidt tot betere beslissingen over waar de technologie zinvol is. Voor bedrijven die AI afwijzen, moet er nog steeds een continu proces zijn om te beoordelen wat de technologie kan doen en waar deze nu staat. Je wilt niet dat een beslissing die drie jaar geleden is genomen, beleid van het bedrijf blijft, simpelweg omdat niemand de aannames erachter heeft herzien.

Agentic AI maakt het voor individuele teams steeds gemakkelijker om hun eigen agents te creëren, wat mogelijk leidt tot meerdere agents die bijna identieke taken uitvoeren. Op welk moment wordt experimenteren een agent‑sprawl, en welk type governance‑laag is nodig om eigendom, permissies, duplicatie en levenscyclusbeheer te beheren?

Wanneer we een typisch scenario zien waarin elke ontwikkelaar een AI-licentie krijgt en experimenteren ongecontroleerd wordt, begint iedereen zijn eigen dingen te creëren en op zijn eigen manier te werken. Dit leidt doorgaans tot onderpresterende teams, gemiste verwachtingen, achterblijvende kwaliteit en stijgende kosten. Het komt erop neer dat het niet doet wat men verwacht, de kwaliteit slecht is en het duur wordt. Om dat te mitigeren moet het een teamprestatie zijn die deel uitmaakt van een bredere afdeling‑ of organisatie‑inspanning, en daar komt governance om de hoek kijken.

Op projectniveau kun je overeenstemming bereiken over de kennisbasis en context, evenals de use‑cases waarin je AI gaat inzetten. Vervolgens creëer je vaardigheden en agents die deel uitmaken van de ontwikkelworkflow en die iedereen kan hergebruiken, zodat je kennis en best practices ophoopt in plaats van ze telkens opnieuw te moeten maken. Die project‑gerichte inspanning moet vervolgens worden gecoördineerd door bijvoorbeeld een enterprise‑architectuurboard, een technologie‑groep, de CTO of een team dat verantwoordelijk is voor AI‑adoptie. Je wilt agents die goed werken hergebruiken, zorgen dat het proces solide is, en dat dit binnen de organisatie werkt in plaats van te verzanden in chaos en ruis.

Dus ik denk dat het een gesynchroniseerde inspanning moet zijn op projectniveau, mogelijk op programmaniveau, en vervolgens ook op afdelings‑ en organisatieniveau.

Tokenverbruik en inferentiekosten kunnen tijdens een pilot relatief klein lijken, maar worden aanzienlijk wanneer AI‑systemen worden uitgerold naar duizenden medewerkers of autonome agents. Hoe moeten ondernemingen nadenken over AI‑kostenbeheer, en verwacht je dat er iets dat op FinOps lijkt specifiek voor AI‑workloads zal ontstaan?

Ik begin met te zeggen dat een bijna ideaal scenario is wanneer AI‑kosten stijgen, een plateau bereiken en daarna geleidelijk afnemen. Dat geeft aan dat je de kosten kunt voorspellen, beheersen, begrijpt waar je daadwerkelijk aan uitgeeft aan AI, en de resultaten van je beslissingen kunt zien. De slechte situaties zijn wanneer de kosten blijven schommelen, omdat dat meestal betekent dat iets niet duurzaam is, of wanneer de kosten stijgen en vervolgens volledig dalen omdat adoptie mogelijk niet plaatsvindt, iets niet werkt, of mensen iets anders gebruiken en je dat simpelweg niet ziet.

FinOps bestaat, en AI‑FinOps bestaat ook. Sommige technieken zijn zeer technisch, terwijl andere vrij eenvoudig zijn. Het kan zo simpel zijn als het kiezen van het voorkeursmodel zodat je niet steeds op het duurste model hoeft te vertrouwen, en stap voor stap beginnen die keuzes geld te besparen. Tegelijkertijd is weten hoe je kosten bespaart en beheerst slechts de helft van de vergelijking. FinOps, zoals ik het zie, is een discipline en methodologie die ook product‑ en businessleiders omvat, omdat je moet definiëren wat je meet bij het evalueren van AI‑inspanningen.

Ja, ik denk dat AI‑FinOps een goed onderwerp is voor het equivalent van een AI‑SWAT‑team om te bespreken: hoeveel je uitgeeft, hoeveel je terugkrijgt, hoe je het beheert en waar de kansen liggen.

Veel bedrijven wordt gevraagd om ROI van AI aan te tonen, hoewel ze nooit een betrouwbare basislijn hebben vastgesteld voor hoe productief hun teams waren voordat AI werd geïntroduceerd. Wat zouden organisaties daadwerkelijk moeten meten als ze willen bepalen of AI betekenisvolle bedrijfswaarde creëert?

Ongeacht je houding ten opzichte van AI of waar je nu staat, misschien gebruik je al agents overal of overweeg je dat je volgend jaar AI gaat inzetten; het vaststellen van een basislijn is tegenwoordig absoluut onmisbaar.

Er zijn verschillende klassen van metrics. Sommige zijn subjectief, en dat kan simpelweg feedback van je ontwikkelaars of medewerkers zijn, omdat je met mensen werkt en het belangrijk is te begrijpen hoe zij de waarde van AI ervaren. Meer objectieve metingen kunnen beginnen met mechanische of synthetische metrics, hoewel ik iedereen zou aanraden zich er niet te strikt aan te binden. Ik bedoel zaken als code‑commits of story points. Deze metrics laten zien dat er gewerkt werd, maar ze tonen niet echt de waarde of impact.

Wat echt het verschil maakt, zijn metrics die aangeven hoe snel of hoe goed het werk is geleverd. Denk aan DORA‑metrics zoals doorlooptijd of MTTR, hoe snel je van een storing kunt herstellen, hoe snel je een bug in productie kunt oplossen, of hoe die metingen in de loop van de tijd veranderen. Een enkel getal op een bepaald moment vertelt je niet de trend. Een van onze architecten merkte onlangs op dat, in software‑ontwikkeling, een goede metric ook kan zijn hoe betrouwbaar schattingen zijn naarmate AI‑adoptie groeit, omdat dat iets zegt over de duurzaamheid van deze inspanningen en hoe productief teams werkelijk zijn. Je moet ook de kosten bijhouden, want als je alleen over voordelen praat zonder te begrijpen wat het kost om ze te realiseren, heb je geen volledig beeld.

Buiten software‑ontwikkeling denk ik er op een vergelijkbare manier over. In elke workflow of elk proces is er een bepaalde eenheid van werk en een definitie van ‘klaar’. Of je nu claims verwerkt, documenten beoordeelt of klantverzoeken afhandelt, definieer wat je levert en meet vervolgens hoe lang het duurde vóór AI, hoe snel en hoe goed je het nu kunt doen, en wat het kost. Dat geeft je een goed uitgangspunt zowel voor de basislijn als voor het raamwerk van metrics.

DataArt heeft AI geïntegreerd in de volledige software‑leveringslevenscyclus via initiatieven zoals Artisyn. Nu AI meer implementatie-, test‑ en workflow‑taken overneemt, welke delen van software‑engineering worden waardevoller voor mensen, en welke vaardigheden riskeren minder belangrijk te worden?

Je kunt AI alleen effectief inzetten in ontwikkeling als je nog weet wat de definitie van goed is. Je hebt die expertise nodig om je agents te begeleiden, de uitkomst te beoordelen, beperkingen te stellen en de regels te definiëren. Je moet begrijpen wat best practice is en hoe een goede architectuur eruitziet, want zonder dat kun je niet weten wat er wordt ontwikkeld, en de waarde van dit soort expertise stijgt zeer, zeer aanzienlijk.

Het begrijpen van architecturale patronen is belangrijk, net als het begrijpen van wat passend is in een bepaalde industrie, toepassing of oplossingsklasse. Je moet weten welk type architectuur nu goed is en welk type ook goed zal blijven wanneer de oplossing schaalt, want soms werkt dezelfde architectuur niet gedurende de hele levensduur van een oplossing of platform.

Die balans tussen wat passend is voor een specifieke oplossing is het menselijke aspect. Het is het gevoel, het vakmanschap achter diensten en software‑ontwikkeling. Je moet weten wat je doet, en dat komt ook voort uit het begrijpen van de klant en de branche.

Welke vaardigheden worden minder belangrijk? Het is echt moeilijk voor mij om dat te zeggen, hoewel misschien hoe snel je code kunt typen. Ik maak een grapje, maar code kan nu veel, veel sneller worden gemaakt, en specifieke kennis van een bepaalde bibliotheek of programmeertaal kan ook veel sneller worden geleerd met AI.

Ik heb .NET‑ontwikkelaars zeer snel omscholen tot Java‑ontwikkelaars gezien, en vijf of tien jaar geleden zou ik hebben gezegd dat dat op schaal bijna onmogelijk was. Tegenwoordig kan dat. Een sterke senior ontwikkelaar kan steeds vaker tussen talen schakelen, omdat wat echt telt hun begrip van technologie, architectuur, best practices voor oplossingen, SDLC en ADLC is.

Nu bedrijven van tientallen AI‑pilots overstappen naar productiesystemen die zelfstandig acties kunnen uitvoeren, waar moet de verantwoordelijkheid uiteindelijk liggen wanneer een AI‑agent een kostbare fout maakt: bij de ontwikkelaar, de bedrijfsleider, de modelprovider, het governance‑team, of een combinatie daarvan?

Ik vind het idee van schuldvrije samenwerking en gedeelde verantwoordelijkheid prettig, omdat iedereen in de organisatie bijdraagt aan best practices, architecturale kaders en oplossingen. Zelfs als één ontwikkelaar code maakt met of zonder AI, beoordeelt een andere ontwikkelaar deze, teamleiders geven begeleiding, architecten leveren de architectuur en beperkingen, en het governance‑team draagt bij aan beslissingen over budgetten, planning en releases. Iedereen is op een bepaalde manier betrokken.

Heel vaak, wanneer er iets misgaat, is het het proces dat niet werkt, dus in die zin is verantwoordelijkheid gedeeld over verschillende rollen. Maar als je simpelweg zegt dat verantwoordelijkheid gedeeld en daardoor schuldvrij is, is dat niet voldoende. Het moet nog steeds worden opgesplitst in specifieke taken.

Ontwikkelaars zijn verantwoordelijk voor de code die ze indienen als pull‑request, en ze moeten begrijpen wat daar gebeurt. Architecten zijn verantwoordelijk voor de beslissingen die ze nemen en voor de architecturale keuzes die aan agents en ontwikkelaars worden gegeven. Het platformteam is verantwoordelijk voor de betrouwbaarheid van de oplossing, ongeacht wie of wat een specifieke regel code heeft gecreëerd.

De verantwoordelijkheid is er dus, maar je moet deze gedetailleerd definiëren per team, rol en afdeling. Wat je niet kunt doen, is de analyse stoppen bij ‘AI heeft dit gedaan.’ Je moet vragen welke controles, tests of toezicht die fout hebben toegestaan om in productie te komen.

Als een gebrek aan unit‑tests slechte code in productie heeft laten komen, of een gebrek aan toezicht en review dit mogelijk maakte, kun je die verantwoordelijkheid niet afschuiven op AI. Je kunt ook niet simpelweg de modelprovider of cloudprovider de schuld geven voor elke bug of storing.

Bedankt voor het geweldige interview, lezers die meer willen weten, kunnen terecht op DataArt.