La pregunta que más me hacen CTOs y Heads of Data en LATAM este año no es '¿debemos adoptar IA?' sino '¿cómo hacemos que nuestro equipo actual sea quien la opere?' Y la respuesta suele estar más cerca de lo que piensan: los analistas de datos son el punto de partida más eficiente para construir capacidad de IA en una empresa, porque ya entienden el negocio, saben manejar datos y tienen algo muy difícil de enseñar: el criterio para saber cuándo un sistema falla y por qué.
El error más caro que veo en empresas es salir a contratar AI Engineers externos cuando tienen analistas de datos que con 6-9 meses de capacitación estructurada podrían hacer exactamente ese trabajo. El problema no es que los analistas no puedan hacer el salto. Es que las empresas no saben cómo diseñar ese camino.
Por qué los analistas son el punto de partida más subestimado
Un AI Engineer en producción hace cuatro cosas: entiende el problema de negocio, diseña la solución con LLMs o modelos, implementa la plomería de datos que alimenta el sistema y mide si funciona. Dos de esas cuatro habilidades las tienen los analistas de datos por defecto.
El analista que lleva tres años haciendo dashboards en Power BI y queries en SQL sabe cuáles métricas importan, qué datos están limpios, qué excepciones hay que manejar y cómo comunicar los resultados. Eso es exactamente lo que más tiempo toma construir cuando contratas un AI Engineer externo que viene puro de backend o de ciencia de datos pura. He visto equipos de contratación invertir seis meses en encontrar ese perfil y otros seis en que entienda el negocio. El analista ya lo sabe.
La brecha real: qué le falta al analista para ser AI Engineer
Lo que diferencia a un analista senior de un AI Engineer en 2026 no es Python. La mayoría de los analistas ya lo usa para automatizar reportes, limpiar datos y hacer análisis ad hoc. Lo que falta es más específico:
- ▸Entender cómo funcionan los LLMs y sus límites: cuándo alucinan, cuándo el contexto importa, cuándo usar un modelo grande versus uno pequeño
- ▸Saber construir pipelines que conectan APIs de modelos con datos propios: RAG sobre documentos internos, function calling, context engineering
- ▸Conocer los patrones de agentes: cuándo usar un agente autónomo, cuándo un pipeline determinístico es mejor y más predecible
- ▸Leer y debuggear trazas de agentes cuando el sistema falla en producción
Nada de eso requiere un doctorado ni cuatro años de reentrenamiento. Requiere exposición práctica con proyectos reales y un programa que vaya en el orden correcto.
Un camino en 90 días que funciona en la práctica
Los equipos que conozco que hicieron la transición bien siguieron un patrón parecido.
Los primeros 30 días son de fundamentos prácticos de LLMs. No teoría matemática: entender prompts, tokens, llamadas a API, manejo de contexto. El objetivo de este período es que cada analista construya un prototipo funcional con datos reales de la empresa: un chatbot sobre documentación interna o un automatizador de reportes. Si al final del mes 1 no tienen un prototipo que funciona, algo está mal en la estructura del programa.
Del día 30 al 60, el foco es arquitectura de agentes: RAG sobre datos propios, LangChain para flujos con memoria, LangGraph para orquestaciones con múltiples pasos y condiciones. Aquí es donde el analista empieza a ver el puente entre lo que ya sabe de datos y lo que añade la capa de IA. El analista que entiende bien un star schema entiende rápido por qué el diseño del contexto en un agente RAG es análogo.
Del día 60 al 90: agentes en producción. Monitoreo, evaluación, manejo de fallos, costos de inferencia. Este es el período donde el conocimiento de negocio del analista se convierte en su ventaja diferencial. Sabe cuándo el agente falla porque la lógica de negocio está mal definida, no solo porque el código tiene un bug.
Lo que no funciona (y que muchas empresas siguen intentando)
Mandar a los analistas a un taller de 'IA para todos' de dos días y esperar que después construyan sistemas. No funciona. La exposición sin práctica no genera habilidad.
Contratar un AI Engineer externo para que 'enseñe' al equipo mientras trabaja. Tampoco funciona: el AI Engineer no tiene tiempo ni incentivos para enseñar, y el equipo no tiene un currículo estructurado que seguir. Termina siendo algo intermedio que no hace bien ninguna de las dos cosas.
Esperar al 'momento correcto' para empezar la capacitación. Las empresas que ya tienen AI Engineers internos capacitados empezaron el proceso hace 12-18 meses. Cada trimestre que pasa sin estructura es una brecha que crece.
Lo que sí funciona: estructura, práctica y proyectos sobre datos reales
Las empresas de la región que lograron la transición —y DataPath ha acompañado a más de 30 en LATAM, incluyendo equipos en Entel, BCP y Scotiabank— tienen tres cosas en común: un programa con currículo secuenciado, proyectos aplicados sobre sus propios datos, y una persona interna que lidera el proceso y mide el avance semana a semana.
El programa no tiene que ser perfecto desde el primer día. Tiene que tener secuencia y continuidad. Un analista que estudia 8 horas a la semana durante 12 semanas con proyectos reales aprende más que uno que hace un bootcamp intensivo de 2 semanas sin seguimiento.
Si quieres hacer este proceso en tu empresa, en DataPath diseñamos el programa según el nivel actual de tu equipo, tus herramientas y tus objetivos. Empezamos con un diagnóstico sin costo. Escríbenos en DataPath para Empresas para hablar de tu caso específico. Los analistas que han pasado por el programa AI Engineer y el camino de AI Agentic Engineer son los que hoy lideran proyectos de IA en sus organizaciones. El camino existe y funciona cuando está bien estructurado.
