Yuri Gubin, CTO da DataArt – Série de Entrevistas

Yuri Gubin, CTO da DataArt é um executivo veterano de tecnologia e arquiteto de software que passou mais de 18 anos na DataArt, avançando por cargos que abrangem arquitetura de software, arquitetura de soluções, tecnologia de nuvem, inovação e liderança executiva antes de se tornar Diretor de Tecnologia em março de 2026. Seu trabalho tem se concentrado em resolver desafios tecnológicos complexos em setores como serviços financeiros, saúde, viagens e IoT, com expertise particular em computação em nuvem, IA, plataformas de dados e arquitetura de software corporativa. Antes de assumir o cargo de Diretor de Tecnologia, Gubin atuou por mais de cinco anos como Diretor de Inovação da DataArt e é membro do Conselho de Parceiros da empresa desde 2021. Ele também é membro profissional do Forbes Technology Council, participando de seus grupos de especialistas em IA e Computação em Nuvem, e atua como Consultor de Tecnologia para Girls Who Code, onde orienta sobre arquitetura, proteção de dados, governança de plataformas e política tecnológica. Atualmente, a DataArt o lista como seu Diretor de Tecnologia, com sede em Nova Iorque.

DataArt é uma empresa global de engenharia de software e transformação de dados e IA fundada em Nova Iorque em 1997. A empresa cresceu para mais de 6.000 profissionais de tecnologia operando em mais de 20 países e trabalha com mais de 400 clientes, oferecendo serviços em áreas como inteligência artificial e aprendizado de máquina, dados e análise, transformação de nuvem, engenharia de software sob medida, cibersegurança e modernização de legados. A DataArt atua em setores como serviços financeiros, saúde e ciências da vida, viagens, mídia e entretenimento, e varejo, e mantém parcerias tecnológicas com plataformas como AWS, Google Cloud, Microsoft Azure, Snowflake e Databricks. Em 2025, a empresa anunciou um investimento de $100 million, por três anos, em suas capacidades de dados e IA, seguido em 2026 pelo lançamento da Artisyn, um modelo operacional habilitado por IA projetado para incorporar agentes de IA, aceleradores reutilizáveis, governança, segurança e conformidade no desenvolvimento de software empresarial.

Você passou quase duas décadas na DataArt, evoluindo de arquiteto de software e arquiteto de soluções para Diretor de Inovação e agora CTO. Como essa trajetória moldou a forma como você distingue tecnologias verdadeiramente transformadoras dos ciclos de hype, e como isso informa seu “otimismo cético” em relação à IA hoje?

Vimos muitas ondas diferentes ao longo dos anos, incluindo a ascensão da nuvem e dos dispositivos móveis, diferentes gerações de IA, automação, DevOps e SRE, e eu estive programando, arquitetando e aconselhando nossos clientes sobre muitos desses tópicos durante esse período. O que percebi é que, sim, você pode fazer quase tudo com a tecnologia, e a tecnologia é bastante poderosa, mas o diabo está nos detalhes e você precisa saber o que está fazendo para que tudo faça sentido e funcione.

Vi ambientes de nuvem se tornarem cada vez mais caros, modelos de IA que não desempenham como se espera, e tentativas mal implementadas de automatizar ciclos de lançamento. Observei o impacto tanto de decisões boas quanto ruins, portanto, sempre que surge algo novo e você lê todos os anúncios, promessas e hype, volto ao mesmo princípio: quase tudo é possível com tecnologia, mas você precisa saber o que está fazendo.

Você obtém uma boa compreensão de uma tecnologia por meio de P&D e, principalmente, por projetos reais, pois é assim que você aprende o que é possível, o que não é, e onde as coisas podem dar errado. Você extrai essas lições de cada engajamento, conversa com seus pares, outros arquitetos e analistas, e tenta entender se existem padrões e se pode criar algum tipo de sistema em torno deles. Eventualmente, isso se torna orientação, e então você vê se as decisões que considerava boas realmente produzem bons resultados.

É daí que vem o otimismo cético. Independentemente das promessas da tecnologia, ainda é necessário saber o que está fazendo, e esse conhecimento vem da experiência, colaboração e de um esforço contínuo para aprender, melhorar e criar algum tipo de sistema por trás do hype.

A IA empresarial parece estar passando de uma fase de incentivo à experimentação para a decisão de quais experimentos realmente merecem ser escalados. Quais sinais indicam que um caso de uso de IA está pronto para uma implantação mais ampla, e quais são os sinais de alerta de que uma empresa está escalando prematuramente?

Eu utilizo dois métodos para entender se podemos escalar algo ou se precisamos fazer outra coisa: a curva de adoção e a curva de aprendizado.

Para entender se um caso de uso de IA está funcionando, é preciso dar-lhe algum tempo e compreender o valor que ele traz e como é a jornada do usuário, pois assim você pode observar os altos e baixos em vez de apenas o efeito imediato de “uau” em uma equipe ou fluxo de trabalho específico. É necessário ver o que acontece com as mesmas pessoas algumas semanas depois. Elas ainda o utilizam? Ainda estão satisfeitas com esse caso de uso, essa automação ou essa habilidade de IA que criaram, ou foi apenas um pico que realmente não deveria ser escalado?

Algumas dessas coisas só podem ser validadas ao longo do tempo. Sempre haverá os primeiros pioneiros, geralmente as pessoas mais tecnicamente experientes e as mais curiosas, e então você precisa testá‑las com outros segmentos, com aqueles que seguem os primeiros adotantes e depois a maioria precoce. Uma vez que isso se comprova, sim, você pode começar a escalar e expandir esse caso de uso para outros departamentos.

Todo lançamento importante de modelo pode gerar pressão dentro de uma organização para que os funcionários tenham acesso imediato às capacidades mais recentes. Como os líderes de tecnologia devem avaliar se um novo modelo representa uma melhoria significativa, em vez de simplesmente gerar outra onda de experimentação e custo?

Aqui está meu otimismo cético novamente. Suponha que você já tenha um modelo em funcionamento e vários milhares de pessoas usando IA diariamente, com diferentes modelos e ferramentas já disponíveis. Quando um novo modelo surge, por causa do hype e da curiosidade natural, você pode esperar que todos queiram experimentá‑lo, o que é bom, mas essa experimentação pode não ser guiada ou orientada a resultados específicos, e às vezes você nem conseguirá medir a diferença.

Em escala, isso importa. Não se trata apenas de uma ou duas pessoas testando como o novo modelo se comporta em relação ao antigo. Pode ser milhares de pessoas gastando tempo em experimentos quando, para um caso de uso específico, o resultado pode não ser tão significativo. Ao mesmo tempo, se algo funcionar muito bem, o aprendizado sobre o que funciona dentro da sua organização pode não ser claramente explicado ou visível a todos.

É por isso que o primeiro grupo a avaliar um novo modelo não deve ser toda a organização. Deve ser um grupo de P&D trabalhando de perto com as equipes relevantes, além de jurídico e segurança. Avaliamos o modelo de forma abrangente, fazemos uma avaliação rápida e, em seguida, o apresentamos ao público mais amplo com alguns comentários e orientações sobre segurança, conformidade e tecnologia. Com novos modelos e grandes atualizações chegando constantemente, você precisa ter esse modelo e essa mentalidade em prática. Realmente não se trata de um exercício pontual ou único.

A DataArt criou um “AI SWAT” multifuncional envolvendo tecnologia, jurídico, conformidade, InfoSec e outras equipes. Como esse grupo opera na prática e que tipos de riscos ou questões precisam ser resolvidos antes que uma nova ferramenta de IA seja aprovada para uso mais amplo?

Desde a sua criação, acho que definimos diferentes objetivos para esse grupo aproximadamente a cada quatro ou cinco meses. Mudamos a prioridade, a meta e às vezes a missão, e muitas dessas metas giram em torno de IA. Pode ser capacitar a força de trabalho, estratégias de go‑to‑market e novas capacidades, parcerias ou ampliar o uso de IA na organização e ao longo do ADLC.

Os tópicos exatos evoluem ao longo do tempo, e acho que isso é saudável porque você precisa revisitar constantemente sua própria estratégia, validar suas suposições e entender se é preciso mudar de direção e qual deve ser o próximo tema para a equipe.

O grupo inclui representantes de diferentes departamentos, e um de seus propósitos é simplesmente manter todos informados. Sempre que há um novo anúncio, dúvida ou oportunidade, alguém pode levar o assunto a uma de nossas reuniões regulares. Mesmo que pareça uma questão tecnológica relevante apenas para uma equipe restrita, hoje esses temas podem ter implicações para muitas partes da organização.

Por isso, ao avaliarmos uma nova parceria, ferramenta ou acelerador, discutimos abertamente para que todos compreendam a direção das coisas e tenham a chance de fazer perguntas ou oferecer supervisão. Para uma nova ferramenta de IA, a tecnologia não pode avaliá‑la isoladamente. Segurança, jurídico e conformidade também precisam entender como ela lida com dados da empresa ou de clientes, quais restrições se aplicam e se pode ser usada com segurança em escala.

Às vezes a equipe AI SWAT também trabalha em programas específicos, como capacitação, onde definimos metas, traçamos roteiros e decidimos como diferentes grupos serão integrados. Esse é realmente o modo de funcionamento: manter as pessoas informadas, trabalhar juntas em programas específicos e proporcionar visibilidade ao conselho sobre o que está acontecendo com IA em toda a empresa.

Você tem observado atitudes muito diferentes em relação ao desenvolvimento de software assistido por IA, com algumas organizações escalando ativamente o desenvolvimento agente enquanto outras ainda proíbem código gerado por IA. O que explica essa divisão e o que precisa mudar antes que mais empresas conscientes de risco se sintam confortáveis com a IA desempenhando um papel maior na engenharia de software?

Provavelmente o que impulsiona a diferença entre quem diz não e quem diz sim é a sua tolerância ao risco e a atitude em relação à ambiguidade e à incerteza. O que ajuda ambos os tipos de organizações é a educação contínua, a experimentação e a avaliação. Mesmo entre muitas organizações com as quais trabalhamos que adotam IA e a incorporam em todos os lugares, ainda há desafios na medição dos resultados e do impacto. Para ser sincero, a questão de como medir o impacto da IA e como avaliar o desempenho de uma equipe às vezes surge quase do nada, como se ninguém realmente tivesse pensado nisso antes.

Assim que você começa a avaliar uma iniciativa de IA de forma mais abrangente, passa a entender o impacto e o valor que ela realmente está proporcionando, o que leva a decisões melhores sobre onde a tecnologia faz sentido. Para empresas que dizem não à IA, ainda é necessário um processo contínuo de revisão do que a tecnologia pode fazer e de onde ela está atualmente. Você não quer que uma decisão tomada há três anos continue sendo política da empresa apenas porque ninguém revisitou as premissas por trás dela.

A IA agente torna cada vez mais fácil para equipes individuais criarem seus próprios agentes, potencialmente resultando em múltiplos agentes executando tarefas quase idênticas. Em que ponto a experimentação se torna proliferação de agentes, e que tipo de camada de governança é necessária para gerenciar propriedade, permissões, duplicação e gerenciamento do ciclo de vida?

Quando vemos um cenário típico em que uma licença de IA é concedida a cada desenvolvedor e a experimentação se torna desorientada, todos começam a criar suas próprias coisas e a trabalhar à sua maneira. Normalmente, isso leva a equipes com desempenho abaixo do esperado, expectativas não atendidas, qualidade atrasada e despesas crescentes. O resultado final é que não cumpre o que todos esperam, a qualidade é ruim e se torna caro. Para mitigar isso, é preciso que seja um esforço de equipe que faça parte de um esforço mais amplo de departamento ou organizacional, e é aí que a governança entra.

No nível de projeto, você pode concordar sobre a base de conhecimento e o contexto, bem como os casos de uso onde começa a usar IA. Em seguida, cria habilidades e agentes que fazem parte do fluxo de trabalho de desenvolvimento e que todos podem reutilizar, acumulando conhecimento e boas práticas em vez de recriá‑los a cada vez. Esse esforço ao nível de projeto deve então ser orquestrado por algo como um conselho de arquitetura corporativa, um grupo de tecnologia, o CTO ou uma equipe responsável pela adoção de IA. Você quer reutilizar agentes que funcionam bem, garantir que o processo seja sólido e que esse trabalho se espalhe por toda a organização, em vez de se transformar em caos e ruído.

Portanto, acredito que deve ser um esforço sincronizado ao nível de projeto, talvez ao nível de programa, e então também nos níveis de departamento e organizacional.

O consumo de tokens e os custos de inferência podem parecer relativamente pequenos durante um piloto, mas tornam‑se significativos quando sistemas de IA são implantados em milhares de funcionários ou agentes autônomos. Como as empresas devem pensar sobre a gestão de custos de IA, e você espera que algo semelhante ao FinOps surja especificamente para cargas de trabalho de IA?

Começarei dizendo que um cenário quase ideal é quando os custos de IA sobem, atingem um platô e depois começam a diminuir ligeiramente ao longo do tempo. Isso indica que você pode prever, controlar os custos, entender o que realmente está gastando em IA e ver os resultados das decisões que toma. As situações ruins são quando os custos continuam subindo e descendo, pois isso geralmente indica que algo não é sustentável, ou quando os custos aumentam e depois caem completamente porque a adoção pode não estar acontecendo, algo não funciona, ou as pessoas estão usando outra coisa e você simplesmente não vê isso.

Portanto, FinOps existe, e FinOps de IA também. Algumas técnicas são muito técnicas, enquanto outras são bastante simples. Pode ser tão básico quanto escolher o modelo preferido para não depender sempre do mais caro, e, passo a passo, essas decisões começam a economizar dinheiro. Ao mesmo tempo, saber como economizar e controlar custos é apenas metade da equação. FinOps, como eu vejo, é uma disciplina e metodologia que também envolve líderes de produto e de negócios, pois é necessário definir o que está sendo medido ao avaliar os esforços de IA.

Então, sim, acho que FinOps de IA é um tema adequado para o equivalente a uma equipe SWAT de IA discutir: quanto você gasta, quanto recebe de volta, como controla isso e onde estão as oportunidades.

Muitas empresas estão sendo solicitadas a demonstrar ROI da IA, mesmo que nunca tenham estabelecido uma linha de base confiável de quão produtivas suas equipes eram antes da introdução da IA. O que as organizações realmente devem medir se quiserem determinar se a IA está criando valor comercial significativo?

Independentemente da sua atitude em relação à IA ou de onde você está agora, talvez já esteja usando agentes de um lado ao outro ou talvez esteja pensando que no próximo ano começará a usar IA; estabelecer uma linha de base é absolutamente indispensável nos dias de hoje.

Existem várias classes de métricas. Algumas são subjetivas, e isso pode ser simplesmente o feedback dos seus desenvolvedores ou funcionários, porque você está trabalhando com pessoas e é importante entender como elas percebem o valor da IA. Medidas mais objetivas podem começar com métricas mecânicas ou sintéticas, embora eu aconselhe a todos a não se prenderem excessivamente a elas. Quero dizer coisas como commits de código ou story points. Essas métricas mostram que o trabalho está acontecendo, mas não demonstram realmente o valor ou o impacto.

O que faz mais diferença são as métricas que explicam quão rapidamente ou quão bem o trabalho foi entregue. Pense nas métricas DORA, como lead time ou MTTR, quão rápido você pode se recuperar de uma falha, quão rápido pode corrigir um bug em produção, ou como essas medidas mudam ao longo do tempo. Um número em um ponto não indica a trajetória. Um de nossos arquitetos mencionou recentemente que, no desenvolvimento de software, uma boa métrica pode também ser a confiabilidade das estimativas à medida que a adoção de IA cresce, porque isso revela algo sobre a sustentabilidade desses esforços e quão produtivas as equipes realmente são. Você também precisa acompanhar os custos, pois se você falar apenas dos benefícios sem entender o que custa alcançá‑los, não terá a visão completa.

Fora do desenvolvimento de software, penso sobre isso de forma semelhante. Em cada fluxo de trabalho ou processo, há uma certa unidade de trabalho e uma definição de concluído. Seja processando reivindicações, revisando documentos ou atendendo solicitações de clientes, defina o que está entregando e então meça quanto tempo levava antes da IA, quão rápido e quão bem você pode fazer isso agora, e qual é o custo. Isso lhe fornece um bom ponto de partida tanto para a linha de base quanto para a estrutura de métricas.

DataArt tem incorporado IA ao longo de todo o ciclo de entrega de software por meio de iniciativas como Artisyn. À medida que a IA assume mais tarefas de implementação, teste e fluxo de trabalho, quais partes da engenharia de software se tornam mais valiosas para os humanos, e quais habilidades correm o risco de se tornar menos importantes?

Você só pode usar IA de forma eficaz no desenvolvimento se ainda se lembrar qual é a definição de bom. Você precisa dessa expertise para orientar seus agentes, revisar o resultado, estabelecer restrições e definir as regras. É necessário compreender o que constitui as melhores práticas e como deve ser uma boa arquitetura, porque, sem isso, você pode não saber o que está sendo desenvolvido, e o valor desse tipo de expertise está aumentando muito, muito significativamente.

Compreender padrões arquiteturais é importante, assim como entender o que é adequado em determinada indústria, aplicação ou classe de solução. Você precisa saber que tipo de arquitetura é boa agora e que tipo ainda será boa quando a solução escalar, pois às vezes a mesma arquitetura não funciona ao longo de toda a vida útil de uma solução ou plataforma.

Esse equilíbrio do que é adequado para uma solução específica é a parte humana. É o gosto, a arte por trás dos serviços e do desenvolvimento de software. Você precisa saber o que está fazendo, e isso também vem da compreensão do cliente e do setor.

Quais habilidades são menos importantes? É realmente difícil para mim dizer isso, embora talvez a rapidez com que você digita código. Estou brincando, mas o código agora pode ser criado muito, muito mais rapidamente, e o conhecimento específico de uma determinada biblioteca ou linguagem também pode ser aprendido muito mais rápido com IA.

Eu vi desenvolvedores .NET requalificados como desenvolvedores Java muito rapidamente, e cinco ou dez anos atrás eu teria dito que fazer isso em escala era quase impossível. Hoje em dia, você pode. Um desenvolvedor sênior experiente pode cada vez mais transitar entre linguagens porque o que realmente importa é sua compreensão de tecnologia, arquitetura, melhores práticas de solução, SDLC e ADLC.

À medida que as empresas passam de dezenas de pilotos de IA para sistemas de produção que podem agir de forma independente, onde a responsabilidade deve ficar, em última análise, quando um agente de IA comete um erro custoso: com o desenvolvedor, o proprietário do negócio, o fornecedor do modelo, a equipe de governança ou alguma combinação deles?

Gosto da ideia de colaboração sem culpa e responsabilidade compartilhada, pois todos na organização contribuem para as melhores práticas, estruturas arquiteturais e soluções. Mesmo que um desenvolvedor crie código com IA ou sem IA, outro desenvolvedor o revisa, líderes de equipe fornecem orientação, arquitetos fornecem a arquitetura e as restrições, e a equipe de governança contribui para decisões sobre orçamentos, cronogramas e lançamentos. Todos estão envolvidos de alguma forma.

Muito frequentemente, quando algo dá errado, é o processo que falha, portanto, nesse sentido, a responsabilidade é compartilhada entre diferentes papéis. Mas se você simplesmente disser que a responsabilidade é compartilhada e, portanto, sem culpa, isso não é suficiente. Ainda precisa ser dividida em responsabilidades específicas.

Os desenvolvedores são responsáveis pelo código que enviam como pull request, e precisam entender o que está acontecendo ali. Os arquitetos são responsáveis pelas decisões que tomam e pelas decisões arquiteturais fornecidas a agentes e desenvolvedores. A equipe de plataforma é responsável pela confiabilidade da solução, independentemente de quem ou o que criou uma linha de código específica.

Portanto, a responsabilidade está presente, mas você precisa defini‑la de forma granular por equipe, função e departamento. O que você não pode fazer é interromper a análise em “IA fez isso”. É necessário perguntar quais controles, testes ou supervisões permitiram que essa falha chegasse à produção.

Se a falta de testes unitários permitiu que código defeituoso fosse enviado para produção, ou a falta de supervisão e revisão permitiu que isso acontecesse, você não pode transferir essa responsabilidade para a IA. Também não se pode simplesmente culpar o fornecedor do modelo ou o provedor de nuvem por cada bug ou interrupção.

Obrigado pela ótima entrevista, leitores que desejam saber mais devem visitar DataArt.