Yuri Gubin, CTO hos DataArt – Interviewserie

Yuri Gubin, CTO hos DataArt er en erfaren teknologiledere og softwarearkitekt, der har tilbragt mere end 18 år i DataArt og har avanceret gennem roller inden for softwarearkitektur, løsningsarkitektur, cloud‑teknologi, innovation og ledelse, inden han blev Chief Technology Officer i marts 2026. Hans arbejde har fokuseret på at løse komplekse teknologiske udfordringer på tværs af brancher såsom finansielle tjenester, sundhedssektoren, rejsebranchen og IoT, med særlig ekspertise inden for cloud computing, AI, dataplatforme og enterprise‑softwarearkitektur. Før han blev CTO, tjente Gubin i mere end fem år som DataArts Chief Innovation Officer og har været medlem af virksomhedens Board of Partners siden 2021. Han er også professionelt medlem af Forbes Technology Council, hvor han deltager i AI‑ og Cloud Computing‑ekspertgrupperne, og fungerer som teknologirådgiver for Girls Who Code, hvor han rådgiver om arkitektur, databeskyttelse, platformstyring og teknologipolitik. DataArt angiver i øjeblikket ham som sin Chief Technology Officer med base i New York.

DataArt er en global software‑engineering‑ og data‑ og AI‑transformationsvirksomhed, der blev grundlagt i New York i 1997. Virksomheden er vokset til mere end 6.000 teknologiprofessionelle, der opererer i over 20 lande, og arbejder med mere end 400 kunder og leverer tjenester inden for områder som kunstig intelligens og maskinlæring, data og analyse, cloud‑transformation, skræddersyet software‑engineering, cybersikkerhed og modernisering af ældre systemer. DataArt arbejder på tværs af sektorer såsom finansielle tjenester, sundheds‑ og livsvidenskab, rejse, medier og underholdning samt detailhandel, og opretholder teknologipartnerskaber med platforme som AWS, Google Cloud, Microsoft Azure, Snowflake og Databricks. I 2025 annoncerede virksomheden en investering på 100 millioner USD over tre år i sine data‑ og AI‑kapaciteter, efterfulgt i 2026 af lanceringen af Artisyn, en AI‑drevet driftsmodel designet til at integrere AI‑agenter, genanvendelige accelerators, governance, sikkerhed og overholdelse i enterprise‑softwareudvikling.

Du har tilbragt næsten to årtier hos DataArt, hvor du er avanceret fra softwarearkitekt og løsningsarkitekt til Chief Innovation Officer og nu CTO. Hvordan har den rejse påvirket din evne til at skelne ægte transformative teknologier fra hype‑cyklusser, og hvordan informerer den din “skeptiske optimisme” over for AI i dag?

Vi har gennem årene set mange forskellige bølger, herunder fremkomsten af cloud og mobil, forskellige generationer af AI, automatisering, DevOps og SRE, og jeg har kodet, arkitektet og rådgivet vores kunder om mange af disse emner i hele perioden. Det, jeg indså, er, at ja, du kan gøre næsten alt med teknologi, og teknologi er ret kraftfuld, men djævlen gemmer sig i detaljerne, og du skal vide, hvad du laver, for at det giver mening og fungerer.

Jeg har set cloud‑miljøer blive mere og mere dyre, AI‑modeller, der ikke præsterer, som du tror, de vil, og dårligt implementerede forsøg på at automatisere udgivelsescyklusser. Jeg har set virkningen af både gode og dårlige beslutninger, så når noget nyt dukker op, og du læser alle meddelelser, løfter og hype, vender jeg tilbage til den samme forudsætning: næsten alt er muligt med teknologi, men du skal vide, hvad du laver.

Du får en god forståelse af en teknologi gennem R&D og, vigtigst af alt, gennem virkelige projekter, fordi det er sådan, du lærer, hvad der er muligt, hvad der ikke er, og hvor ting kan gå galt. Du tager de erfaringer fra hver enkelt engagement, taler med dine kolleger, andre arkitekter og analytikere, og forsøger at forstå, om der er mønstre, og om du kan skabe en form for system omkring dem. Til sidst bliver det til vejledning, og så ser du, om de beslutninger, du troede var gode beslutninger, virkelig giver gode resultater.

Det er her den skeptiske optimisme kommer fra. Uanset hvad teknologien lover, skal du stadig vide, hvad du laver, og den viden kommer fra erfaring, samarbejde og en kontinuerlig indsats for at lære, blive bedre og skabe en form for system bag hype.

Enterprise AI ser ud til at bevæge sig fra en fase med at opmuntre til eksperimentering til at beslutte, hvilke eksperimenter der faktisk fortjener at blive skaleret. Hvilke signaler fortæller dig, at et AI‑brugstilfælde er klar til bredere implementering, og hvad er advarselstegnene på, at en virksomhed skalerer for tidligt?

Jeg bruger to metoder til at forstå, om vi kan skalere noget, eller om vi skal gøre noget andet: adoptionskurven og læringskurven.

For at forstå, om et AI‑brugstilfælde fungerer, skal du give det tid og forstå, hvilken værdi det bringer, og hvordan brugerrejsen ser ud, for så kan du se op- og nedture i stedet for kun den umiddelbare ‘wow’-effekt i et bestemt team eller workflow. Du skal se, hvad der sker med de samme personer et par uger senere. Bruger de det stadig? Er de stadig tilfredse med det pågældende brugstilfælde, den automatisering eller den AI‑færdighed, de har skabt, eller var det blot et kortvarigt fænomen, der egentlig ikke bør skaleres?

Nogle af disse ting kan kun valideres over tid. Der vil altid være de første pionerer, typisk de mest teknisk kyndige personer og dem, der er meget nysgerrige, og så skal du prøve det med andre segmenter, med dem der følger de tidlige adoptanter og derefter den tidlige majoritet. Når det har bevist sig der, ja, kan du begynde at skalere det og udvide den brugssag til andre afdelinger.

Hver større modeludgivelse kan skabe pres i en organisation til straks at give medarbejderne adgang til de nyeste funktioner. Hvordan skal teknologiledere vurdere, om en ny model udgør en meningsfuld forbedring frem for blot at generere en ny bølge af eksperimentering og omkostninger?

Her er min skeptiske optimisme igen. Antag, at du allerede har en model på plads, og flere tusinde mennesker bruger AI dagligt, med forskellige modeller og værktøjer allerede tilgængelige. Når en ny model kommer ud, på grund af hype og naturlig nysgerrighed, kan du forvente, at alle vil eksperimentere med den, hvilket er positivt, men den eksperimentering er måske ikke nødvendigvis styret eller rettet mod specifikke resultater, og nogle gange vil du endda ikke kunne måle forskellen.

I stor skala betyder det noget. Det er ikke kun én eller to personer, der roder rundt for at se, hvordan den nye model klarer sig i forhold til den gamle. Det kan være tusinder af mennesker, der bruger tid på at eksperimentere, når udfaldet for en bestemt brugssag måske ikke er så betydningsfuldt. Samtidig, hvis noget fungerer rigtig godt, kan læringen om, hvad der virker i din organisation, måske ikke blive tydeligt forklaret eller synlig for alle.

Derfor bør den første gruppe, der evaluerer en ny model, ikke være hele organisationen. Det bør være en R&D-gruppe, der arbejder tæt sammen med de relevante teams samt juridisk og sikkerhed. Vi evaluerer modellen grundigt, laver en hurtig vurdering og bringer den derefter ud til et bredere publikum med kommentarer og vejledning omkring sikkerhed, compliance og teknologi. Med nye modeller og store opdateringer, der konstant ankommer, skal du have denne model og tankegang på plads. Det er virkelig ikke en engangs‑ eller engangsøvelse.

DataArt har oprettet en tværfunktionel “AI SWAT” bestående af teknologi, juridisk, compliance, InfoSec og andre teams. Hvordan fungerer denne gruppe i praksis, og hvilke typer risici eller spørgsmål skal løses, før et nyt AI‑værktøj godkendes til bredere brug?

Siden starten tror jeg, at vi har sat forskellige mål for denne gruppe cirka hver fjerde eller femte måned. Vi ændrer prioriteten, målet og nogle gange missionen, og mange af disse mål drejer sig om AI. Det kan være opkvalificering af arbejdsstyrken, go‑to‑market og nye funktioner, partnerskaber eller at muliggøre AI bredere i organisationen og på tværs af ADLC.

De præcise emner udvikler sig over tid, og jeg synes, det er sundt, fordi du konstant skal genoverveje din egen strategi, validere dine antagelser og forstå, om du skal dreje om, og hvad næste tema for teamet skal være.

Gruppen involverer repræsentanter fra forskellige afdelinger, og et af formålene er simpelthen at holde alle informeret. Når der er en ny meddelelse, et spørgsmål eller en mulighed, kan nogen bringe emnet op på et af vores regelmæssige møder. Selvom det kan se ud som et teknologispørgsmål, der kun er relevant for et snævert team, kan sådanne emner i dag have konsekvenser for mange dele af organisationen.

Derfor diskuterer vi åbent, når vi evaluerer et nyt partnerskab, værktøj eller accelerator, så alle forstår, hvor tingene er på vej, og får mulighed for at stille spørgsmål eller give tilsyn. For et nyt AI‑værktøj kan teknologien ikke evaluere det isoleret. Sikkerhed, juridisk og compliance skal også forstå, hvordan det håndterer virksomhedens eller kundens data, hvilke begrænsninger der gælder, og om det kan bruges sikkert i stor skala.

Nogle gange arbejder AI SWAT‑teamet også på specifikke programmer, såsom opkvalificering, hvor vi fastsætter mål, udarbejder roadmaps og beslutter, hvordan forskellige grupper skal onboardes. Sådan fungerer det i virkeligheden: holde folk informeret, samarbejde om specifikke programmer og give bestyrelsen indsigt i, hvad der sker med AI på tværs af virksomheden.

Du ser meget forskellige holdninger til AI‑assisteret softwareudvikling, hvor nogle organisationer aktivt skalerer agentbaseret udvikling, mens andre stadig forbyder AI‑genereret kode. Hvad forklarer denne splittelse, og hvad skal ændres, før mere risikobewuste virksomheder bliver trygge ved, at AI spiller en større rolle i softwareengineering?

Sandsynligvis er forskellen mellem dem, der siger nej, og dem, der siger ja, deres risikotolerance og holdning til tvetydighed og usikkerhed. Hvad der hjælper begge typer organisationer, er kontinuerlig uddannelse, eksperimentering og evaluering. Selv blandt mange af de organisationer, vi arbejder med, som omfavner AI og integrerer den overalt, er der stadig udfordringer med at måle resultatet og påvirkningen. For at være ærlig kommer spørgsmålet om, hvordan du måler AI’s påvirkning, og hvordan du evaluerer et teams præstation, nogle gange næsten ud af det blå, som om ingen egentlig har tænkt over det før.

Når du begynder at evaluere en AI‑initiativer mere omfattende, får du forståelse for den påvirkning og den værdi, den faktisk giver dig, hvilket fører til bedre beslutninger om, hvor teknologien giver mening. For virksomheder, der siger nej til AI, skal der stadig være en kontinuerlig proces for at gennemgå, hvad teknologien kan gøre, og hvor den står i dag. Du ønsker ikke, at en beslutning truffet for tre år siden forbliver virksomhedens politik, blot fordi ingen har revurderet de bagvedliggende antagelser.

Agentisk AI gør det i stigende grad nemt for enkelte teams at skabe deres egne agenter, hvilket potentielt kan resultere i flere agenter, der udfører næsten identiske opgaver. Hvor på et tidspunkt bliver eksperimenteringen til en spredning af agenter, og hvilken form for styringslag er nødvendig for at håndtere ejerskab, tilladelser, duplikering og livscyklusadministration?

Når vi ser et typisk scenarie, hvor en AI‑licens gives til hver udvikler, og eksperimenteringen bliver ustyret, begynder alle at skabe deres eget indhold og arbejde på deres egen måde. Typisk fører det til underpresterende teams, uopfyldte forventninger, faldende kvalitet og stigende omkostninger. Bundlinjen er, at det ikke lever op til, hvad alle forventer, kvaliteten er dårlig, og det bliver dyrt. For at afbøde dette skal det være en teamindsats, der er en del af en bredere afdeling eller organisatorisk indsats, og det er her, governance kommer ind.

På projektniveau kan I blive enige om vidensbasen og konteksten samt de brugssager, hvor I begynder at anvende AI. Derefter opretter I færdigheder og agenter, der er en del af udviklingsarbejdsflowet, og som alle kan genbruge, så I akkumulerer viden og bedste praksis i stedet for at genskabe dem hver gang. Denne projekt‑niveau indsats bør så koordineres af f.eks. et enterprise‑arkitektur board, en teknologigruppe, CTO’en eller et team, der er ansvarligt for AI‑adoption. I vil genbruge agenter, der fungerer godt, sikre at processen er solid, og få den til at fungere på tværs af organisationen i stedet for at ende i kaos og støj.

Så jeg tror, det skal være en synkroniseret indsats på projektniveau, måske på programniveau, og derefter også på afdelings‑ og organisationsniveau.

Token‑forbrug og inferenskost kan fremstå relativt små under en pilot, men bliver betydelige, når AI‑systemer implementeres på tværs af tusindvis af medarbejdere eller autonome agenter. Hvordan bør virksomheder tænke på AI‑omkostningsstyring, og forventer du, at noget lignende FinOps vil opstå specifikt for AI‑arbejdsbelastninger?

Jeg vil starte med at sige, at et næsten ideelt scenarie er, når AI‑omkostningerne stiger, når et plateau og derefter begynder at falde let over tid. Det viser, at du kan forudsige, kontrollere omkostningerne, forstå hvad du faktisk bruger på AI, og se resultaterne af de beslutninger, du træffer. De dårlige situationer er, når omkostningerne fortsat svinger op og ned, fordi det typisk betyder, at noget ikke er bæredygtigt, eller når omkostningerne stiger og derefter falder helt, fordi adoptionen måske ikke sker, noget ikke fungerer, eller folk bruger noget andet, som du simpelthen ikke ser.

FinOps er altså en ting, og AI‑FinOps er også en ting. Nogle teknikker er meget tekniske, mens andre er ret simple. Det kan være så grundlæggende som at vælge den foretrukne model, så du ikke altid er afhængig af den dyreste, og trin for trin begynder disse beslutninger at spare penge. Samtidig er det kun halvdelen af ligningen at vide, hvordan man sparer og kontrollerer omkostninger. FinOps er, som jeg ser det, en disciplin og metode, der også involverer produkt‑ og forretningsledere, fordi du skal definere, hvad du måler, når du evaluerer AI‑indsatser.

Ja, jeg mener, at AI‑FinOps er et godt emne for den tilsvarende AI‑SWAT‑team at diskutere: hvor meget du bruger, hvor meget du får tilbage, hvordan du kontrollerer det, og hvor mulighederne ligger.

Mange virksomheder bliver bedt om at demonstrere ROI fra AI, selvom de aldrig har etableret et pålideligt grundlag for, hvor produktive deres teams var, før AI blev introduceret. Hvad bør organisationer faktisk måle, hvis de vil afgøre, om AI skaber meningsfuld forretningsværdi?

Uanset din holdning til AI eller hvor du befinder dig lige nu, måske bruger du allerede agenter overalt, eller måske overvejer du at begynde at bruge AI næste år – at etablere et grundlag er i dag helt uundværligt.

Der findes flere klasser af målinger. Nogle er subjektive, og det kan simpelthen være feedback fra dine udviklere eller medarbejdere, fordi du arbejder med mennesker, og det er vigtigt at forstå, hvordan de opfatter AI‑værdien. Mere objektive målinger kan starte med mekaniske eller syntetiske metrics, selvom jeg vil opfordre alle til ikke at binde sig for tæt til dem. Jeg mener ting som kode‑commits eller story points. Disse målinger viser, at der blev arbejdet, men de viser ikke virkelig værdien eller påvirkningen.

Det, der gør mest forskel, er målinger, der forklarer, hvor hurtigt eller hvor godt arbejdet blev leveret. Tænk på DORA-målinger såsom lead time eller MTTR, hvor hurtigt du kan komme dig efter en fejl, hvor hurtigt du kan rette en bug i produktion, eller hvordan disse målinger ændrer sig over tid. Et tal på et tidspunkt fortæller dig ikke udviklingskurven. En af vores arkitekter nævnte for nylig, at i softwareudvikling kan en god måling også være, hvor pålidelige estimater er, efterhånden som AI‑adoptionen vokser, fordi det siger noget om bæredygtigheden i disse indsatser og hvor produktive teams virkelig er. Du skal også holde styr på omkostningerne, for hvis du kun taler om fordele uden at forstå, hvad det koster at opnå dem, har du ikke det fulde billede.

Uden for softwareudvikling tænker jeg på det på en lignende måde. I hver arbejdsgang eller proces er der en enhed af arbejde og en definition af færdig. Uanset om du behandler krav, gennemgår papirarbejde eller håndterer kundebegæringer, skal du definere, hvad du leverer, og så måle, hvor lang tid det tog før AI, hvor hurtigt og hvor godt du kan gøre det nu, og hvad det koster. Det giver dig et godt udgangspunkt både for baseline og for rammerne for målinger.

DataArt har indlejret AI i hele softwareleveringslivscyklussen gennem initiativer som Artisyn. Efterhånden som AI overtager flere implementerings-, test- og arbejdsopgave‑processer, hvilke dele af softwareingeniørarbejdet bliver mere værdifulde for mennesker, og hvilke færdigheder risikerer at blive mindre vigtige?

Du kan kun bruge AI effektivt i udvikling, hvis du stadig husker, hvad definitionen af god er. Du har brug for den ekspertise til at vejlede dine agenter, gennemgå resultatet, sætte begrænsninger og definere reglerne. Du skal forstå, hvad bedste praksis er, og hvordan god arkitektur bør se ud, for uden det kan du måske ikke vide, hvad der bliver udviklet, og værdien af denne form for ekspertise stiger meget, meget betydeligt.

At forstå arkitektoniske mønstre er vigtigt, ligesom det er vigtigt at forstå, hvad der er passende i en given branche, applikation eller løsningsklasse. Du skal vide, hvilken type arkitektur der er god lige nu, og hvilken type der stadig vil være god, når løsningen skalerer, fordi nogle gange fungerer den samme arkitektur ikke gennem hele levetiden af en løsning eller platform.

Den balance, hvad der er passende for en bestemt løsning, er den menneskelige del. Det er smagen, håndværket bag tjenester og softwareudvikling. Du skal vide, hvad du laver, og det kommer også fra at forstå kunden og branchen.

Hvilke færdigheder er mindre vigtige? Det er virkelig svært for mig at sige, selvom måske hvor hurtigt du kan skrive kode. Jeg er bare sjov, men kode kan nu skabes meget, meget hurtigere, og specifik viden om et bestemt bibliotek eller sprog kan også læres meget hurtigere med AI.

Jeg har set .NET‑udviklere omskole sig til Java‑udviklere meget hurtigt, og for fem eller ti år siden ville jeg have sagt, at det var næsten umuligt at gøre i stor skala. I dag kan du det. En stærk seniorudvikler kan i stigende grad bevæge sig mellem sprog, fordi det der virkelig betyder noget, er deres forståelse af teknologi, arkitektur, løsnings‑bedste praksis, SDLC og ADLC.

Efterhånden som virksomheder går fra dusinvis af AI‑piloter til produktionssystemer, der kan handle uafhængigt, hvor bør ansvaret i sidste ende ligge, når en AI‑agent begår en kostbar fejl: hos udvikleren, forretningsejeren, modeludbyderen, governance‑teamet eller en kombination af dem?

Jeg kan lide idéen om fejlfri samarbejde og delt ansvar, fordi alle i organisationen bidrager til bedste praksis, arkitektoniske rammer og løsninger. Selv hvis en udvikler laver kode med AI eller uden AI, så gennemgår en anden udvikler den, teamledere giver vejledning, arkitekter leverer arkitekturen og begrænsningerne, og governance‑teamet bidrager til beslutninger om budgetter, tidsplaner og udgivelser. Alle er involveret på en eller anden måde.

Meget ofte, når noget går galt, er det processen, der fejler, så i den forstand er ansvaret delt på tværs af forskellige roller. Men hvis du blot siger, at ansvaret er delt og dermed fejlfrit, er det ikke nok. Det skal stadig opdeles i specifikke ansvarsområder.

Udviklere er ansvarlige for den kode, de indsender som en pull‑request, og de skal forstå, hvad der foregår der. Arkitekter er ansvarlige for de beslutninger, de træffer, og for de arkitektoniske beslutninger, der gives til agenter og udviklere. Platformsteamet er ansvarligt for løsningens pålidelighed uanset hvem eller hvad der har skabt en bestemt kode‑linje.

Så ansvaret er der, men du skal definere det detaljeret efter team, rolle og afdeling. Det du ikke kan gøre, er at stoppe analysen ved “AI gjorde dette.” Du skal spørge, hvilke kontroller, tests eller tilsyn der tillod den fejl at nå produktion.

Hvis mangel på enhedstest tillod dårlig kode at blive skubbet i produktion, eller mangel på tilsyn og gennemgang tillod det, kan du ikke overlade det ansvar til AI. Du kan heller ikke blot skyde skylden på modeludbyderen eller cloud‑udbyderen for hver bug eller nedbrud.

Tak for det gode interview, læsere der ønsker at lære mere, bør besøge DataArt.