Yuri Gubin, CTO de DataArt – Serie de entrevistas

Yuri Gubin, CTO de DataArt es un ejecutivo veterano de tecnología y arquitecto de software que ha pasado más de 18 años en DataArt, avanzando a través de roles que abarcan arquitectura de software, arquitectura de soluciones, tecnología cloud, innovación y liderazgo ejecutivo antes de convertirse en Director de Tecnología en marzo de 2026. Su trabajo se ha centrado en resolver desafíos tecnológicos complejos en industrias como servicios financieros, salud, viajes e IoT, con especial expertise en computación en la nube, IA, plataformas de datos y arquitectura de software empresarial. Antes de ser CTO, Gubin desempeñó durante más de cinco años el cargo de Director de Innovación de DataArt y es miembro de la Junta de Socios de la compañía desde 2021. También es miembro profesional del Forbes Technology Council, participando en sus grupos de expertos en IA y Computación en la Nube, y actúa como Asesor Tecnológico de Girls Who Code, donde asesora en arquitectura, protección de datos, gobernanza de plataformas y política tecnológica. DataArt lo lista actualmente como su Director de Tecnología con sede en Nueva York.

DataArt es una empresa global de ingeniería de software y transformación de datos e IA fundada en Nueva York en 1997. La compañía ha crecido a más de 6.000 profesionales de tecnología que operan en más de 20 países y trabaja con más de 400 clientes, ofreciendo servicios en áreas que incluyen inteligencia artificial y aprendizaje automático, datos y analítica, transformación cloud, ingeniería de software a medida, ciberseguridad y modernización de sistemas heredados. DataArt actúa en sectores como servicios financieros, salud y ciencias de la vida, viajes, medios y entretenimiento, y retail, y mantiene alianzas tecnológicas con plataformas como AWS, Google Cloud, Microsoft Azure, Snowflake y Databricks. En 2025, la empresa anunció una inversión de $100 million durante tres años en sus capacidades de datos e IA, seguida en 2026 del lanzamiento de Artisyn, un modelo operativo habilitado por IA diseñado para incorporar agentes de IA, aceleradores reutilizables, gobernanza, seguridad y cumplimiento en el desarrollo de software empresarial.

Has pasado casi dos décadas en DataArt, progresando de arquitecto de software y arquitecto de soluciones a Director de Innovación y ahora a CTO. ¿Cómo ha moldeado ese recorrido la forma en que distingues las tecnologías verdaderamente transformadoras de los ciclos de hype, y cómo influye en tu “optimismo escéptico” hacia la IA hoy?

Hemos visto muchas olas diferentes a lo largo de los años, incluyendo el auge de la nube y el móvil, distintas generaciones de IA, automatización, DevOps y SRE, y he estado programando, diseñando arquitecturas y asesorando a nuestros clientes en muchos de estos temas durante ese tiempo. Lo que me di cuenta es que, sí, puedes hacer casi cualquier cosa con la tecnología, y la tecnología es bastante poderosa, pero el diablo está en los detalles y necesitas saber lo que haces para que tenga sentido y funcione.

He visto que los entornos cloud se vuelven cada vez más costosos, modelos de IA que no rinden como esperas, y intentos mal implementados de automatizar los ciclos de lanzamiento. He observado el impacto tanto de decisiones buenas como malas, así que cada vez que surge algo nuevo y lees todos los anuncios, promesas y hype, vuelvo a la misma premisa: casi cualquier cosa es posible con la tecnología, pero tú necesitas saber lo que haces.

Se adquiere una buena comprensión de una tecnología mediante R&D y, lo que es importante, a través de proyectos reales, porque así es como aprendes lo que es posible, lo que no lo es y dónde pueden surgir problemas. Extraes esas lecciones de cada compromiso, hablas con tus colegas, otros arquitectos y analistas, y tratas de entender si existen patrones y si puedes crear algún tipo de sistema alrededor de ellos. Finalmente, eso se convierte en una guía, y luego ves si las decisiones que considerabas buenas realmente generan buenos resultados.

De ahí proviene el optimismo escéptico. Sea lo que sea que la tecnología prometa, aún necesitas saber lo que haces, y ese conocimiento proviene de la experiencia, la colaboración y un esfuerzo continuo por aprender, mejorar y crear algún tipo de sistema detrás del hype.

La IA empresarial parece estar pasando de una fase de fomentar la experimentación a decidir qué experimentos realmente merecen escalar. ¿Qué señales te indican que un caso de uso de IA está listo para un despliegue más amplio, y cuáles son los signos de advertencia de que una empresa está escalando demasiado pronto?

Utilizo dos métodos para entender si podemos escalar algo o si necesitamos hacer otra cosa: la curva de adopción y la curva de aprendizaje.

Para entender si un caso de uso de IA está funcionando, necesitas darle tiempo y comprender el valor que aporta y cómo es el recorrido del usuario, porque así puedes observar los altibajos en lugar de solo el efecto inmediato de “wow” en un equipo o flujo de trabajo concreto. Necesitas ver qué ocurre con las mismas personas unas semanas después. ¿Siguen utilizándolo? ¿Siguen satisfechos con ese caso de uso, esa automatización o esa habilidad de IA que crearon, o fue solo un pico que realmente no debería escalarse?

Algunas de estas cosas solo pueden validarse con el tiempo. Siempre habrá los primeros pioneros, usualmente las personas más técnicamente hábiles y las que son muy curiosas, y luego debes probarlo con otros segmentos, con quienes siguen a los primeros adoptantes y después a la mayoría temprana. Una vez que se demuestre allí, sí, puedes comenzar a escalarlo y expandir ese caso de uso a otros departamentos.

Cada lanzamiento importante de un modelo puede crear presión dentro de una organización para dar a los empleados acceso inmediato a las capacidades más recientes. ¿Cómo deben los líderes tecnológicos evaluar si un nuevo modelo representa una mejora significativa en lugar de simplemente generar otra ola de experimentación y costo?

Aquí está mi optimismo escéptico de nuevo. Supón que ya tienes un modelo en funcionamiento y varios miles de personas usando IA a diario, con diferentes modelos y herramientas ya disponibles. Cuando sale un nuevo modelo, debido al bombo y a la curiosidad natural, puedes esperar que todos quieran experimentar con él, lo cual es bueno, pero esa experimentación puede no estar necesariamente guiada o orientada a resultados específicos, y a veces ni siquiera podrás medir la diferencia.

A gran escala, eso importa. No se trata solo de una o dos personas curioseando para ver cómo el nuevo modelo se desempeña frente al anterior. Pueden ser miles de personas dedicando tiempo a experimentar cuando, para un caso de uso particular, el resultado puede no ser tan significativo. Al mismo tiempo, si algo funciona muy bien, el aprendizaje sobre lo que funciona dentro de tu organización puede no estar claramente explicado o ser visible para todos.

Por eso, el primer grupo que evalúe un nuevo modelo no debe ser toda la organización. Debe ser un grupo de I+D que trabaje estrechamente con los equipos relevantes, así como con los departamentos legal y de seguridad. Evaluamos el modelo de forma integral, realizamos una evaluación rápida y luego lo presentamos a una audiencia más amplia con algunos comentarios y orientaciones sobre seguridad, cumplimiento y tecnología. Con la llegada constante de nuevos modelos y actualizaciones importantes, necesitas tener este modelo y mentalidad en marcha. Realmente no es un ejercicio único o puntual.

DataArt ha creado un “AI SWAT” multifuncional que involucra tecnología, legal, cumplimiento, InfoSec y otros equipos. ¿Cómo opera este grupo en la práctica y qué tipos de riesgos o preguntas deben resolverse antes de que una nueva herramienta de IA sea aprobada para un uso más amplio?

Desde su creación, creo que hemos establecido diferentes objetivos para este grupo aproximadamente cada cuatro o cinco meses. Cambiamos la prioridad, la meta y, a veces, la misión, y muchos de estos objetivos giran en torno a la IA. Puede tratarse de mejorar las habilidades de la fuerza laboral, ir al mercado y nuevas capacidades, asociaciones, o habilitar la IA de manera más amplia dentro de la organización y a lo largo del ADLC.

Los temas exactos evolucionan con el tiempo, y creo que eso es saludable porque necesitas revisar constantemente tu propia estrategia, validar tus suposiciones y entender si debes pivotar y cuál debería ser el próximo tema para el equipo.

El grupo incluye representantes de diferentes departamentos, y uno de sus propósitos es simplemente mantener a todos informados. Cada vez que hay un nuevo anuncio, pregunta u oportunidad, alguien puede llevar ese tema a una de nuestras reuniones regulares. Incluso si parece una cuestión tecnológica relevante solo para un equipo reducido, hoy en día estos temas pueden tener implicaciones para muchas partes de la organización.

Por eso, cuando evaluamos una nueva asociación, herramienta o acelerador, lo discutimos abiertamente para que todos comprendan hacia dónde se dirige y tengan la oportunidad de hacer preguntas o brindar supervisión. Para una nueva herramienta de IA, la tecnología no puede evaluarla de forma aislada. Seguridad, legal y cumplimiento también deben entender cómo maneja los datos de la empresa o de los clientes, qué restricciones se aplican y si puede usarse de manera segura a gran escala.

A veces, el equipo AI SWAT también trabaja en programas específicos, como la mejora de habilidades, donde establecemos metas, trazamos hojas de ruta y decidimos cómo se incorporarán los diferentes grupos. Así es realmente como funciona: mantener a la gente informada, trabajar juntos en programas específicos y proporcionar visibilidad a la junta sobre lo que está ocurriendo con la IA en toda la empresa.

Estás viendo actitudes muy diferentes hacia el desarrollo de software asistido por IA, con algunas organizaciones escalando activamente el desarrollo agente mientras que otras todavía prohíben el código generado por IA. ¿Qué explica esta división y qué necesita cambiar antes de que más empresas conscientes del riesgo se sientan cómodas con que la IA desempeñe un papel mayor en la ingeniería de software?

Probablemente lo que impulsa la diferencia entre quienes dicen no y quienes dicen sí es su apetito de riesgo y su actitud frente a la ambigüedad e incertidumbre. Lo que ayuda a ambos tipos de organizaciones es la educación continua, la experimentación y la evaluación. Incluso entre muchas organizaciones con las que trabajamos que adoptan la IA e la incorporan en todas partes, todavía existen desafíos para medir el resultado y el impacto. Para ser honesto, la pregunta de cómo medir el impacto de la IA y cómo evaluar el desempeño de un equipo a veces surge casi de la nada, como si nadie lo hubiera pensado realmente antes.

Una vez que empieces a evaluar una iniciativa de IA de forma más exhaustiva, comenzarás a comprender el impacto y el valor que realmente te está proporcionando, lo que conduce a decisiones mejores sobre dónde tiene sentido la tecnología. Para las empresas que dicen no a la IA, sigue siendo necesario un proceso continuo de revisión de lo que la tecnología puede hacer y de su situación actual. No quieres que una decisión tomada hace tres años siga siendo política de la empresa simplemente porque nadie revisó los supuestos que la sustentaban.

Agentic AI hace cada vez más fácil que equipos individuales creen sus propios agentes, lo que potencialmente resulta en múltiples agentes que realizan tareas casi idénticas. ¿En qué momento la experimentación se convierte en una proliferación de agentes, y qué tipo de capa de gobernanza se necesita para gestionar la propiedad, los permisos, la duplicación y la gestión del ciclo de vida?

Cuando observamos un escenario típico en el que se otorga una licencia de IA a cada desarrollador y la experimentación se vuelve desorientada, todos comienzan a crear sus propias cosas y a trabajar a su manera. Normalmente, eso conduce a equipos con bajo rendimiento, expectativas no cumplidas, calidad rezagada y gastos crecientes. En última instancia, no hace lo que todos esperan, la calidad es deficiente y se vuelve costoso. Para mitigar esto, debe ser un esfuerzo de equipo que forme parte de un esfuerzo más amplio del departamento u organización, y ahí es donde entra la gobernanza.

A nivel de proyecto, puedes acordar la base de conocimientos y el contexto, así como los casos de uso en los que comienzas a utilizar IA. Luego creas habilidades y agentes que forman parte del flujo de trabajo de desarrollo y que todos pueden reutilizar, de modo que acumules conocimientos y buenas prácticas en lugar de recrearlos cada vez. Ese esfuerzo a nivel de proyecto debería ser orquestado por algo como una junta de arquitectura empresarial, un grupo tecnológico, el CTO o un equipo responsable de la adopción de IA. Quieres reutilizar agentes que funcionen bien, asegurar que el proceso sea sólido y que funcione en toda la organización, en lugar de convertirse en caos y ruido.

Así que creo que debe ser un esfuerzo sincronizado a nivel de proyecto, quizá a nivel de programa, y también a nivel de departamento y organizacional.

El consumo de tokens y los costos de inferencia pueden parecer relativamente pequeños durante un piloto, pero se vuelven significativos cuando los sistemas de IA se despliegan entre miles de empleados o agentes autónomos. ¿Cómo deberían las empresas abordar la gestión de costos de IA, y esperas que surja algo similar a FinOps específicamente para cargas de trabajo de IA?

Comenzaré diciendo que un escenario casi ideal es cuando los costos de IA aumentan, alcanzan una meseta y luego comienzan a disminuir ligeramente con el tiempo. Eso indica que puedes pronosticar, controlar los costos, entender en qué estás gastando realmente en IA y ver los resultados de las decisiones que tomas. Las situaciones negativas son cuando los costos siguen subiendo y bajando, lo que suele significar que algo no es sostenible, o cuando los costos aumentan y luego caen por completo porque la adopción puede no estar ocurriendo, algo no funciona, o la gente está usando otra cosa y simplemente no lo ves.

Así que FinOps existe, y FinOps de IA también. Algunas técnicas son muy técnicas, mientras que otras son bastante simples. Puede ser tan básico como elegir el modelo preferido para no depender siempre del más caro, y poco a poco esas decisiones empiezan a ahorrar dinero. Al mismo tiempo, saber cómo ahorrar y controlar los costos es solo la mitad de la ecuación. FinOps, según yo, es una disciplina y metodología que también involucra a líderes de producto y de negocio, porque necesitas definir qué estás midiendo al evaluar los esfuerzos de IA.

Así que sí, creo que FinOps de IA es un buen tema para que el equivalente a un equipo SWAT de IA lo discuta: cuánto gastas, cuánto recuperas, cómo lo controlas y dónde están las oportunidades.

Muchas empresas están siendo solicitadas para demostrar el ROI de la IA aunque nunca establecieron una línea base fiable de cuán productivos eran sus equipos antes de introducir la IA. ¿Qué deberían medir realmente las organizaciones si quieren determinar si la IA está creando un valor comercial significativo?

Independientemente de tu actitud hacia la IA o de dónde te encuentres ahora, quizá ya estés usando agentes por todas partes o quizás estés pensando que el próximo año comenzarás a usar IA; establecer una línea base es absolutamente indispensable hoy en día.

Existen varias clases de métricas. Algunas son subjetivas, y pueden ser simplemente la retroalimentación de tus desarrolladores o empleados, ya que trabajas con personas y es importante comprender cómo perciben el valor de la IA. Medidas más objetivas pueden comenzar con métricas mecánicas o sintéticas, aunque instaría a todos a no atarse demasiado a ellas. Me refiero a cosas como commits de código o puntos de historia. Estas métricas demuestran que se estaba trabajando, pero no muestran realmente el valor o el impacto.

Lo que realmente marca la diferencia son las métricas que explican cuán rápido o cuán bien se entregó el trabajo. Piensa en métricas DORA como el tiempo de entrega o MTTR, cuán rápido puedes recuperarte de una falla, cuán rápido puedes arreglar un error en producción, o cómo esas medidas cambian con el tiempo. Un número en un momento dado no te dice la trayectoria. Uno de nuestros arquitectos mencionó recientemente que, en el desarrollo de software, una buena métrica podría también ser cuán fiables son las estimaciones a medida que la adopción de IA crece, porque eso indica algo sobre la sostenibilidad de estos esfuerzos y cuán productivos son realmente los equipos. También necesitas hacer un seguimiento de los costos porque si solo hablas de los beneficios sin entender lo que cuesta lograrlos, no tienes una visión completa.

Fuera del desarrollo de software, lo pienso de manera similar. En cada flujo de trabajo o proceso, hay alguna unidad de trabajo y alguna definición de finalización. Ya sea que estés procesando reclamaciones, revisando documentos o atendiendo solicitudes de clientes, define lo que entregas y luego mide cuánto tiempo tomó antes de la IA, cuán rápido y cuán bien puedes hacerlo ahora, y cuál es el costo. Eso te brinda un buen punto de partida tanto para la línea base como para el marco de métricas.

DataArt ha estado incorporando IA a lo largo del ciclo de vida de entrega de software mediante iniciativas como Artisyn. A medida que la IA asume más tareas de implementación, pruebas y flujos de trabajo, ¿qué partes de la ingeniería de software se vuelven más valiosas para los humanos y qué habilidades corren el riesgo de volverse menos importantes?

Solo puedes usar IA de manera eficaz en el desarrollo si aún recuerdas cuál es la definición de bueno. Necesitas esa experiencia para guiar a tus agentes, revisar los resultados, establecer restricciones y definir las reglas. Debes comprender qué es la mejor práctica y cómo debería ser una arquitectura buena, porque sin eso podrías no saber qué se está desarrollando, y el valor de este tipo de experiencia está aumentando de forma muy, muy significativa.

Entender los patrones arquitectónicos es importante, al igual que comprender qué es apropiado en una industria, aplicación o tipo de solución determinada. Necesitas saber qué tipo de arquitectura es buena en este momento y cuál seguirá siendo buena cuando la solución escale, porque a veces la misma arquitectura no funciona durante todo el ciclo de vida de una solución o plataforma.

Ese equilibrio de lo que es apropiado para una solución concreta es la parte humana. Es el gusto, la artesanía detrás de los servicios y el desarrollo de software. Debes saber lo que haces, y eso también proviene de comprender al cliente y la industria.

¿Qué habilidades son menos importantes? Me resulta muy difícil decirlo, aunque tal vez la rapidez con la que puedes escribir código. Es una broma, pero ahora el código puede generarse mucho, mucho más rápido, y el conocimiento específico de una biblioteca o lenguaje particular también puede aprenderse mucho más rápido con IA.

He visto desarrolladores de .NET reentrenarse como desarrolladores de Java muy rápidamente, y hace cinco o diez años habría dicho que hacerlo a gran escala era casi imposible. Hoy en día, puedes. Un desarrollador senior sólido puede moverse cada vez más entre lenguajes porque lo que realmente importa es su comprensión de la tecnología, la arquitectura, las mejores prácticas de solución, el SDLC y el ADLC.

A medida que las empresas pasan de docenas de pilotos de IA a sistemas de producción que pueden tomar acciones de forma independiente, ¿dónde debería ubicarse finalmente la responsabilidad cuando un agente de IA comete un error costoso: con el desarrollador, el propietario del negocio, el proveedor del modelo, el equipo de gobernanza o alguna combinación de ellos?

Me gusta la idea de una colaboración sin culpables y responsabilidad compartida porque todos en la organización contribuyen a las mejores prácticas, los marcos arquitectónicos y las soluciones. Incluso si un desarrollador crea código con IA o sin IA, otro desarrollador lo revisa, los líderes de equipo brindan orientación, los arquitectos proporcionan la arquitectura y las restricciones, y el equipo de gobernanza aporta decisiones sobre presupuestos, tiempos y lanzamientos. Todos están involucrados de alguna manera.

Muy a menudo, cuando algo sale mal, es el proceso el que falla, por lo que en ese sentido la responsabilidad se comparte entre diferentes roles. Pero si simplemente dices que la responsabilidad es compartida y, por lo tanto, sin culpables, eso no es suficiente. Aún necesita desglosarse en responsabilidades específicas.

Los desarrolladores son responsables del código que envían como pull request, y deben entender qué ocurre allí. Los arquitectos son responsables de las decisiones que toman y de las decisiones arquitectónicas proporcionadas a los agentes y desarrolladores. El equipo de plataforma es responsable de la fiabilidad de la solución, sin importar quién o qué creó una línea de código en particular.

Así que la responsabilidad está presente, pero necesitas definirla de forma granular por equipo, rol y departamento. Lo que no puedes hacer es detener el análisis en “la IA hizo esto”. Debes preguntar qué controles, pruebas o supervisiones permitieron que esa falla llegara a producción.

Si la falta de pruebas unitarias permitió que código defectuoso se enviara a producción, o la falta de supervisión y revisión lo permitió, no puedes delegar esa responsabilidad a la IA. Tampoco puedes simplemente culpar al proveedor del modelo o al proveedor de la nube por cada error o interrupción.

Gracias por la excelente entrevista, los lectores que deseen obtener más información deberían visitar DataArt.