Yuri Gubin, CTO ve společnosti DataArt – série rozhovorů

Yuri Gubin, CTO ve společnosti DataArt je veteránský technologický výkonný ředitel a softwarový architekt, který strávil více než 18 let ve společnosti DataArt, postupně přes role zahrnující softwarovou architekturu, řešení architektury, cloudové technologie, inovace a výkonné vedení, než se v březnu 2026 stal hlavním technologickým ředitelem. Jeho práce se zaměřovala na řešení složitých technologických výzev napříč odvětvími, včetně finančních služeb, zdravotnictví, cestovního ruchu a IoT, s konkrétní odborností v cloud computingu, AI, datových platformách a podnikovém softwarovém architektuře. Před tím, než se stal CTO, Gubin více než pět let působil jako Chief Innovation Officer ve společnosti DataArt a od roku 2021 je členem představenstva partnerů společnosti. Je také profesionálním členem Forbes Technology Council, kde se účastní skupin odborníků na AI a cloud computing, a působí jako technologický poradce pro Girls Who Code, kde radí v oblasti architektury, ochrany dat, správy platform a technologické politiky. DataArt jej v současnosti uvádí jako svého hlavního technologického ředitele se sídlem v New Yorku.

DataArt je globální společnost zabývající se softwarovým inženýrstvím a transformací dat a AI, založená v New Yorku v roce 1997. Společnost vyrostla na více než 6 000 technologických profesionálů působících ve více než 20 zemích a spolupracuje s více než 400 klienty, poskytujíc služby v oblastech zahrnujících umělou inteligenci a strojové učení, data a analytiku, cloudovou transformaci, zakázkové softwarové inženýrství, kybernetickou bezpečnost a modernizaci legacy systémů. DataArt působí napříč sektory jako finanční služby, zdravotnictví a životní vědy, cestovní ruch, média a zábava a maloobchod a udržuje technologická partnerství s platformami včetně AWS, Google Cloud, Microsoft Azure, Snowflake a Databricks. V roce 2025 společnost oznámila investici ve výši $100 million, tříletou investici do svých datových a AI schopností, po čemž v roce 2026 spustila Artisyn, AI‑povolovaný provozní model navržený tak, aby začlenil AI agenty, opakovaně použitelné akcelerátory, správu, zabezpečení a soulad s předpisy do vývoje podnikového softwaru.

Strávili jste téměř dvě desetiletí ve společnosti DataArt, postupně od softwarového architekta a řešení architekta po Chief Innovation Officer a nyní CTO. Jak tato cesta formovala váš způsob rozlišování skutečně transformačních technologií od cyklů hype a jak ovlivňuje váš „skeptický optimismus“ vůči AI dnes?

Viděli jsme během let mnoho různých vln, včetně vzestupu cloudu a mobilních technologií, různých generací AI, automatizace, DevOps a SRE, a během té doby jsem programoval, architektoval a radil našim klientům v mnoha z těchto oblastí. Co jsem si uvědomil, je, že ano, s technologií můžete udělat téměř cokoli a technologie je poměrně mocná, ale peklo je v detailech a musíte vědět, co děláte, aby to mělo smysl a fungovalo.

Viděl jsem, jak se cloudová prostředí stávají stále dražšími, AI modely, které nefungují tak, jak jste očekávali, a špatně provedené pokusy o automatizaci vydávacích cyklů. Viděl jsem dopad jak dobrých, tak špatných rozhodnutí, takže kdykoli se objeví něco nového a přečtete si všechna oznámení, sliby a hype, vracím se k téže premise: téměř vše je s technologií možné, ale musíte vědět, co děláte.

Získáte dobré pochopení technologie prostřednictvím výzkumu a vývoje a, co je důležité, skrze reálné projekty, protože tak se učíte, co je možné, co není a kde mohou nastat chyby. Tyto lekce čerpáte z každého zapojení, mluvíte se svými kolegy, dalšími architekty a analytiky a snažíte se pochopit, zda existují vzory a zda můžete kolem nich vytvořit nějaký systém. Nakonec se to stane vodítkem a pak zjistíte, zda rozhodnutí, o nichž jste si mysleli, že jsou dobrá, skutečně přinášejí dobré výsledky.

Odtud pochází skeptický optimismus. Ať technologie slibuje cokoli, stále musíte vědět, co děláte, a toto znalosti pocházejí ze zkušeností, spolupráce a neustálého úsilí učit se, zlepšovat se a vytvářet nějaký systém za hype.

Enterprise AI se zdá přecházet z fáze podporování experimentování do fáze rozhodování, které experimenty si skutečně zaslouží škálování. Jaké signály vám říkají, že je AI případ použití připravený na širší nasazení, a jaké jsou varovné signály, že společnost škáluje příliš brzy?

Používám dvě metody, abych pochopil, zda můžeme něco škálovat nebo zda musíme udělat něco jiného: křivku adopce a křivku učení.

Abyste pochopili, zda AI případ použití funguje, musíte mu dát čas a pochopit, jakou hodnotu přináší a jak vypadá cesta uživatele, protože pak můžete vidět výkyvy místo pouhého okamžitého \”wow\” efektu v konkrétním týmu nebo pracovním postupu. Musíte sledovat, co se stejným lidem stane o několik týdnů později. Používají jej stále? Jsou stále spokojeni s tímto případem použití, touto automatizací nebo touto AI dovedností, kterou vytvořili, nebo šlo jen o krátkodobý záblesk, který by skutečně neměl být škálován?

Některé z těchto věcí lze ověřit jen v průběhu času. Vždy budou první průkopníci, obvykle nejtechničtěji zdatnější lidé a ti nejzvídavější, a poté to musíte vyzkoušet s dalšími segmenty, s těmi, kteří následují první osvojitele, a pak s ranou většinou. Jakmile se to tam osvědčí, ano, můžete začít škálovat a rozšiřovat tento případ použití do dalších oddělení.

Každé hlavní vydání modelu může vyvíjet tlak v organizaci, aby okamžitě poskytlo zaměstnancům přístup k nejnovějším schopnostem. Jak by technologičtí lídři měli hodnotit, zda nový model představuje smysluplné zlepšení, místo aby jen generoval další vlnu experimentování a nákladů?

Znovu zde představím svůj skeptický optimismus. Předpokládejte, že již máte model a několik tisíc lidí používá AI denně, s různými modely a nástroji, které jsou již k dispozici. Když vyjde nový model, kvůli hype a přirozené zvědavosti můžete očekávat, že všichni budou chtít s ním experimentovat, což je dobré, ale toto experimentování nemusí být nutně vedené nebo zaměřené na konkrétní výsledky a někdy nebudete ani schopni měřit rozdíl.

Ve velkém měřítku na tom záleží. Nejde jen o jednoho nebo dva lidi, kteří zkoumají, jak nový model funguje oproti starému. Může jít o tisíce lidí, kteří tráví čas experimentováním, ačkoliv pro konkrétní případ použití výsledek nemusí být tak významný. Současně, pokud něco funguje opravdu dobře, poznatky o tom, co ve vaší organizaci funguje, nemusí být jasně vysvětleny ani viditelné pro všechny.

Proto by první skupina hodnotící nový model neměla zahrnovat všechny v organizaci. Měla by to být skupina výzkumu a vývoje (R&D), která úzce spolupracuje s příslušnými týmy, stejně jako s právním a bezpečnostním oddělením. Model hodnotíme komplexně, provedeme rychlé posouzení a poté jej představíme širšímu publiku s komentáři a pokyny ohledně bezpečnosti, souladu a technologií. S neustálým přicházením nových modelů a velkých aktualizací potřebujete mít tento model a myšlení připravené. Není to skutečně jednorázové ani jednorázové cvičení.

DataArt vytvořila mezioborový „AI SWAT“ zahrnující technologie, právní, compliance, InfoSec a další týmy. Jak tato skupina funguje v praxi a jaké typy rizik nebo otázek je třeba vyřešit, než bude nový AI nástroj schválen pro širší použití?

Od svého založení si myslím, že pro tuto skupinu stanovujeme různé cíle přibližně každé čtyři až pět měsíců. Měníme priority, cíle a někdy i poslání a mnoho těchto cílů se točí kolem AI. Může se jednat o zvyšování kvalifikace pracovní síly, vstup na trh a nové schopnosti, partnerství nebo širší umožnění AI v celé organizaci a napříč ADLC.

Konkrétní témata se v průběhu času vyvíjejí a myslím, že je to zdravé, protože neustále musíte přehodnocovat svou strategii, ověřovat své předpoklady a pochopit, zda je potřeba změnit směr a jaké by mělo být další téma pro tým.

Skupina zahrnuje zástupce z různých oddělení a jedním z jejích účelů je jednoduše udržet všechny informované. Kdykoli je zde nové oznámení, otázka nebo příležitost, může někdo toto téma přinést na jedno z našich pravidelných setkání. I když to vypadá jako technologická otázka relevantní jen pro úzký tým, v dnešní době mohou tato témata mít dopady na mnoho částí organizace.

Proto, když hodnotíme nové partnerství, nástroj nebo akcelerátor, diskutujeme o tom otevřeně, aby každý pochopil, kam se věci ubírají, a měl možnost klást otázky nebo poskytovat dohled. U nového AI nástroje technologie nemůže hodnotit samostatně. Bezpečnost, právní a compliance také potřebují pochopit, jak s ním zachází s firemními nebo klientskými daty, jaká omezení platí a zda jej lze bezpečně použít ve velkém měřítku.

Někdy tým AI SWAT také pracuje na konkrétních programech, jako je zvyšování kvalifikace, kde stanovujeme cíle, vytváříme plány a rozhodujeme, jak budou různé skupiny zapojeny. To je opravdu způsob, jak to funguje: informovat lidi, spolupracovat na konkrétních programech a poskytovat vedení přehled o tom, co se s AI ve firmě děje.

Vidíte velmi odlišné postoje k vývoji softwaru asistovanému AI, některé organizace aktivně rozšiřují agentický vývoj, zatímco jiné stále zakazují kód generovaný AI. Co tuto propast vysvětluje a co je potřeba změnit, než se rizikově uvědomělé podniky budou cítit pohodlně s tím, že AI bude hrát větší roli v softwarovém inženýrství?

Pravděpodobně to, co pohání rozdíl mezi těmi, kteří říkají ne, a těmi, kteří říkají ano, je jejich chuť k riziku a postoj k nejasnostem a nejistotě. Co pomáhá oběma typům organizací, je kontinuální vzdělávání, experimentování a hodnocení. I mezi mnoha organizacemi, se kterými spolupracujeme a které AI přijímají a integrují všude, stále existují výzvy při měření výsledků a dopadu. Upřímně řečeno, otázka, jak měřit dopad AI a jak hodnotit výkonnost týmu, někdy přichází téměř z ničeho, jako by o tom nikdo předtím opravdu nepřemýšlel.

Jakmile začnete AI iniciativu hodnotit podrobněji, začnete chápat dopad a hodnotu, kterou vám skutečně přináší, což vede k lepším rozhodnutím o tom, kde má technologie smysl. U firem, které říkají ne AI, je stále potřeba kontinuální proces přezkoumávání toho, co technologie dokáže a kde se nyní nachází. Nechcete, aby rozhodnutí učiněné před třemi lety zůstalo firemní politikou jen proto, že nikdo neprověřil předpoklady, na nichž bylo založeno.

Agentická AI usnadňuje jednotlivým týmům stále více vytvářet vlastní agenty, což může vést k tomu, že několik agentů bude vykonávat téměř identické úkoly. V jakém okamžiku se experimentování promění v rozrůstání agentů a jaký typ řídící vrstvy je potřeba k řízení vlastnictví, oprávnění, duplikace a správy životního cyklu?

Když vidíme typický scénář, kdy je každému vývojáři poskytnuta licence na AI a experimentování se stane neřízeným, všichni začnou vytvářet vlastní věci a pracovat po svém. To obvykle vede k podvýkonným týmům, nesplněným očekáváním, klesající kvalitě a rostoucím nákladům. Výsledek je, že to nedělá to, co všichni očekávají, kvalita je špatná a stává se to drahým. K tomu, aby se situace zmírnila, je potřeba týmová spolupráce, která je součástí širšího úsilí oddělení nebo organizace, a právě zde vstupuje řízení.

Na úrovni projektu můžete souhlasit s znalostní bází a kontextem, stejně jako s případy užití, kde začnete AI využívat. Poté vytvoříte dovednosti a agenty, které jsou součástí vývojového pracovního postupu a které může každý znovu použít, takže akumulujete znalosti a osvědčené postupy místo toho, abyste je pokaždé znovu vytvářeli. Tento projektový úsilí by pak mělo být koordinováno například radou pro podnikovou architekturu, technologickou skupinou, CTO nebo týmem odpovědným za adopci AI. Chcete znovu využívat agenty, kteří fungují dobře, zajistit, aby proces byl pevný, a aby fungoval v celé organizaci, místo aby se proměnil v chaos a šum.

Myslím, že to musí být synchronizované úsilí na úrovni projektu, možná i programu, a také na úrovni oddělení a celé organizace.

Spotřeba tokenů a náklady na inferenci se mohou během pilotního provozu jevit jako relativně malé, ale stávají se významnými, když jsou AI systémy nasazeny u tisíců zaměstnanců nebo autonomních agentů. Jak by měly podniky uvažovat o řízení nákladů na AI a očekáváte, že se pro pracovní zátěže AI objeví něco podobného FinOps?

Začnu tím, že téměř ideální scénář nastává, když náklady na AI rostou, dosáhnou plateau a pak se časem mírně snižují. To vám ukazuje, že můžete předpovídat, kontrolovat náklady, pochopit, na co skutečně v AI investujete, a vidět výsledky svých rozhodnutí. Špatné situace nastávají, když náklady neustále kolísají, protože to obvykle znamená, že něco není udržitelné, nebo když náklady stoupnou a pak úplně klesnou, protože adopce nemusí probíhat, něco nefunguje, nebo lidé používají něco jiného a vy to jednoduše nevidíte.

FinOps tedy existuje a AI FinOps také. Některé techniky jsou velmi technické, zatímco jiné jsou poměrně jednoduché. Může to být tak základní jako výběr preferovaného modelu, abyste se neustále nespoléhali na ten nejdražší, a postupně tyto rozhodnutí začnou šetřit peníze. Zároveň je znalost úspor a řízení nákladů jen polovinou rovnice. FinOps, jak to vidím, je disciplína a metodologie, která zahrnuje i produktové a obchodní lídry, protože musíte definovat, co měříte při hodnocení AI úsilí.

Ano, myslím, že AI FinOps je dobré téma pro ekvivalent AI SWAT týmu k diskuzi: kolik utratíte, kolik získáte zpět, jak to kontrolujete a kde jsou příležitosti.

Mnoho společností je požádáno, aby prokázalo návratnost investic (ROI) z AI, i když nikdy nezaváděly spolehlivý výchozí stav produktivity svých týmů před zavedením AI. Co by organizace měly skutečně měřit, pokud chtějí zjistit, zda AI vytváří smysluplnou obchodní hodnotu?

Bez ohledu na váš postoj k AI nebo na to, kde se právě nacházíte, možná už používáte agenty všude kolem, nebo uvažujete, že příští rok začnete AI využívat – nastavení výchozího stavu je dnes naprosto nezbytné.

Existuje několik tříd metrik. Některé jsou subjektivní a mohou být jednoduše zpětnou vazbou od vašich vývojářů nebo zaměstnanců, protože pracujete s lidmi a je důležité pochopit, jak vnímají hodnotu AI. Objektivnější měření mohou začínat mechanickými nebo syntetickými metrikami, i když bych všechny varoval, aby se k nim nepřipoutali příliš úzce. Mám na mysli věci jako commitování kódu nebo story points. Tyto metriky ukazují, že práce probíhala, ale skutečně neukazují hodnotu ani dopad.

Větší rozdíl dělají metriky, které vysvětlují, jak rychle a jak dobře byla práce dodána. Přemýšlejte o metrikách DORA, jako je doba dodání nebo MTTR, jak rychle můžete zotavit se z selhání, jak rychle můžete opravit chybu v produkci, nebo jak se tyto ukazatele v čase mění. Jedna číslice v konkrétním okamžiku neukazuje trajektorii. Jeden z našich architektů nedávno zmínil, že v softwarovém vývoji může být dobrá metrika také to, jak spolehlivé jsou odhady s rostoucím nasazením AI, protože to něco říká o udržitelnosti těchto snah a o skutečné produktivitě týmů. Také musíte sledovat náklady, protože pokud hovoříte jen o výhodách, aniž byste rozuměli tomu, kolik to stojí, nemáte úplný obrázek.

Mimo vývoj softwaru o tom přemýšlím podobně. V každém pracovním postupu nebo procesu existuje určitá jednotka práce a definice dokončení. Ať už zpracováváte nároky, kontrolujete dokumentaci nebo řešíte požadavky zákazníků, definujte, co dodáváte, a poté změřte, jak dlouho to trvalo před AI, jak rychle a jak dobře to nyní můžete udělat, a jaké to stojí. To vám poskytne dobrý výchozí bod jak pro základní úroveň, tak pro rámec metrik.

DataArt vkládá AI do celého životního cyklu dodávky softwaru prostřednictvím iniciativ jako je Artisyn. Jak AI přebírá více implementačních, testovacích a pracovních úkolů, které části softwarového inženýrství se stávají pro lidi hodnotnějšími a které dovednosti hrozí, že budou méně důležité?

AI můžete v vývoji efektivně využívat jen tehdy, pokud si stále pamatujete, jaká je definice dobré. Potřebujete tuto odbornost k řízení svých agentů, revizi výsledků, nastavení omezení a definování pravidel. Musíte rozumět tomu, co je nejlepší praxe a jak by měla vypadat dobrá architektura, protože bez toho nemusíte vědět, co se vyvíjí, a hodnota tohoto druhu odbornosti roste velmi, velmi výrazně.

Pochopení architektonických vzorů je důležité, stejně jako pochopení toho, co je vhodné v konkrétním odvětví, aplikaci nebo typu řešení. Musíte vědět, jaký typ architektury je v současnosti dobrý a jaký bude i nadále dobrý, když se řešení rozroste, protože někdy stejná architektura nefunguje po celou dobu životnosti řešení či platformy.

Tato rovnováha toho, co je vhodné pro konkrétní řešení, je lidská část. Jedná se o vkus, řemeslnou zručnost za službami a vývojem softwaru. Musíte vědět, co děláte, a to také vychází z porozumění klientovi a odvětví.

Které dovednosti jsou méně důležité? Je pro mě těžké to říci, možná jen jak rychle dokážete psát kód. Žertuji, ale kód lze nyní vytvářet mnohem, mnohem rychleji a specifické znalosti konkrétní knihovny či jazyka se také s AI dají naučit mnohem rychleji.

Viděl jsem, jak se .NET vývojáři velmi rychle přeškolili na Java vývojáře, a před pěti či deseti lety bych řekl, že to v takovém měřítku bylo téměř nemožné. Dnes to jde. Silný senior vývojář může čím dál více přecházet mezi jazyky, protože podstatné je jeho pochopení technologií, architektury, nejlepších postupů řešení, SDLC a ADLC.

Jakmile podniky přecházejí od desítek AI pilotů k produkčním systémům, které mohou samostatně jednat, kde by měla být konečná odpovědnost, když AI agent udělá nákladnou chybu: u vývojáře, majitele podniku, poskytovatele modelu, týmu pro správu nebo u jejich kombinace?

Líbí se mi myšlenka bezviny spolupráce a sdílené odpovědnosti, protože každý v organizaci přispívá k nejlepším postupům, architektonickým rámcům a řešením. I když jeden vývojář vytvoří kód s AI nebo bez ní, jiný jej kontroluje, vedoucí týmů poskytují vedení, architekti dodávají architekturu a omezení a tým pro správu přispívá k rozhodnutím o rozpočtech, termínech a vydání. Každý je nějak zapojen.

Velmi často, když se něco pokazí, je to proces, který nefunguje, a tak je v tomto smyslu odpovědnost sdílena mezi různými rolemi. Ale pokud jen řeknete, že odpovědnost je sdílená a tedy bezviny, není to dostatečné. Stále je potřeba ji rozdělit na konkrétní povinnosti.

Vývojáři jsou odpovědní za kód, který odevzdají jako pull request, a musí rozumět tomu, co se tam děje. Architekti jsou odpovědní za svá rozhodnutí a za architektonická rozhodnutí poskytnutá agentům a vývojářům. Tým platformy je odpovědný za spolehlivost řešení bez ohledu na to, kdo nebo co vytvořilo konkrétní řádek kódu.

Takže odpovědnost existuje, ale je třeba ji podrobně definovat podle týmu, role a oddělení. Nemůžete zastavit analýzu na „AI to udělala.“ Musíte se zeptat, jaké kontroly, testy nebo dohled umožnily, že selhání se dostalo do produkce.

Pokud nedostatek unit testů umožnil, aby špatný kód byl nasazen do produkce, nebo nedostatek dohledu a revize to umožnil, nemůžete tuto odpovědnost přenést na AI. Nemůžete také jednoduše vinit poskytovatele modelu nebo poskytovatele cloudu za každou chybu či výpadek.

Děkujeme za skvělý rozhovor, čtenáři, kteří se chtějí dozvědět více, by měli navštívit DataArt.