Ser científico de datos en 2026 ya no se parece a lo que entendíamos hace una década. El rol mutó hacia perfiles híbridos donde la frontera entre AI engineer, data engineer y machine learning researcher se borra, y donde el verdadero diferencial está en mezclar técnica con negocio. Esta es una lectura útil para quienes están entrando al campo o lideran equipos de datos.
Alejandro Correa, líder del equipo de AI en GBM y profesor en el TEC, comparte una mirada construida tras entrevistar a más de 3.000 data scientists y haber sido VP AI en Rappi y AB InBev. Su tesis es directa: la mayoría de los proyectos de AI fracasan, y la razón principal es la brecha de talento.
¿Por qué hay tantos nombres para el mismo rol en ciencia de datos?
En los últimos quince años, una misma persona puede haber pasado por etiquetas como desarrollador de modelos, machine learning researcher, data scientist, lead data scientist y hoy AI engineer. Esa rotación de títulos refleja una industria que aún no se pone de acuerdo sobre qué hace exactamente un perfil de datos.
¿Qué es un AI engineer? Es el nombre más común en 2026 para quien diseña, implementa y evalúa sistemas basados en modelos de lenguaje y agentes, conectándolos con producto y negocio.
Entre tantos títulos, también aparecieron los autodenominados AI influencers. Correa distingue dos tipos de expertos: el que tiene base académica sólida en estadística, cálculo, deep learning y programación, y el que domina TikTok pero no necesariamente la disciplina [4:00].
¿Qué habilidades necesita un científico de datos hoy?
El famoso diagrama de Wes McKinney, creador de Pandas, dibujado en una servilleta en 2016, sigue vigente: la ciencia de datos es la intersección de tres áreas, conocimiento de negocio, matemáticas y estadística, y programación e infraestructura [6:30]. El problema es que casi nadie cubre las tres a la vez.
En la práctica, los equipos se ubican en alguna de las intersecciones laterales, no en el centro. Por eso la estrategia realista es construir equipos cuya suma esté en el medio, no buscar un unicornio individual.
¿Por qué el 95% de los proyectos de AI fracasan?
Cuando un CEO ve algo en redes el fin de semana, llega el lunes pidiendo un chatbot, un modelo predictivo de demanda, un estimador de churn y un LLM corporativo, todo al mismo equipo. La brecha de talento entre lo que se pide y lo que el equipo realmente domina dispara la tasa de fracaso.
¿Cuál es la principal causa de fracaso en proyectos de AI? La brecha de talento técnico y de negocio dentro de la organización, sumada a equipos que aceptan cualquier requerimiento sin filtrar viabilidad.
¿Cómo deben evolucionar los equipos técnicos en 2026?
La recomendación es dejar de pelear por los detalles que no mueven la aguja y enfocarse en los extremos del diagrama, que es donde aparecen los proyectos reales: LLMs que respondan preguntas de negocio, chatbots que hagan onboarding, soluciones embebidas en aplicaciones productivas.
¿Qué LLM elegir y cómo evaluarlo?
En el 99% de las aplicaciones industriales no importa qué LLM se elija. Gastar meses comparándolos es desperdicio. Lo que sí importa, y casi nadie hace bien, son los evals, es decir, cómo se evalúa la calidad de las respuestas del modelo en producción.
- Los evals son la palabra más importante al implementar un LLM.
- Ninguna herramienta del mercado los resuelve por completo.
- Conviene construir el sistema de evaluación internamente.
La evaluación de modelos de lenguaje no se parece a la de los modelos clásicos de machine learning, donde bastaban métricas como precisión o recall. Aquí hay que diseñar criterios propios, contextualizados al caso de uso.
¿Por qué programar en TypeScript en lugar de Python?
Los equipos de Correa migraron sus desarrollos de LLM de Python a TypeScript porque los sistemas productivos que usan modelos de lenguaje viven en ese entorno. Acortar la distancia entre prototipo y producción aumenta la productividad, aunque cueste a quienes vienen de banca o de stacks tradicionales [13:00].
Viniendo de alguien que fue contribuidor de Scikit-learn, la recomendación pesa: no arranques proyectos de LLM en Python, hazlos en TypeScript desde el inicio.
¿Cómo deben construirse los agentes de IA?
Los agentes deben vivir en código, versionados en Git, no en herramientas de drag and drop. Si un proveedor no permite exportar el agente como código, hay que descartarlo. Esta regla protege la mantenibilidad, la trazabilidad y la capacidad de evaluar cada cambio.
- Cero agentes en interfaces visuales sin código.
- Todo agente versionado en Git.
- Evaluación rigurosa antes de pasar a producción.
Evaluar un agente es aún más complejo que evaluar un LLM aislado, porque hay múltiples pasos, herramientas y decisiones encadenadas.
¿Por qué el conocimiento de negocio define al mejor data scientist?
La parte más importante del diagrama es negocio. Los mejores data scientists que Correa ha visto son los que se acercan a las áreas comerciales hasta volverse responsables de ellas. En GBM, las áreas de growth y customer experience le reportan directamente, siendo él un perfil técnico [16:30].
Mientras los técnicos se mantengan separados del negocio, será fácil quejarse de requerimientos mal definidos. La transformación real ocurre cuando los técnicos se vuelven owners de KPIs comerciales.
¿Qué casos muestran el impacto de líderes técnicos en negocio?
Dos referencias concretas: el lanzamiento de RappiCard, cuyo CEO tiene doctorado en machine learning, y las pocas compañías tradicionales del mundo que se transformaron de verdad, casi siempre con CEOs técnicos al frente. En México son contadas, y ese es justamente el espacio de oportunidad.
¿Te animarías a tomar responsabilidad sobre un área de negocio en tu organización? Cuéntame en los comentarios qué te frena o qué ya estás intentando.
