Hay cientos de cursos de IA y casi nadie sabe en qué orden tomarlos. El problema no es la falta de material, sino saber qué necesitas primero y qué puede esperar. Por eso aquí te dejo una ruta que puedes seguir tanto si empiezas desde cero como si ya eres desarrollador.

Para que no se quede en teoría, vamos a usar un mismo ejemplo de principio a fin: un SaaS que recibe cientos de tickets de soporte al día y cuyo dueño dice un día: «queremos IA en el soporte».

Qué hace un AI Engineer

En ese SaaS pueden entrar varios perfiles. Un data scientist analizaría los tickets para encontrar patrones. Un ingeniero de machine learning podría entrenar un modelo propio con esos datos. Y un AI Engineer hace otra cosa: toma un modelo que ya existe y lo convierte en una función del producto.

Es quien decide qué modelo usar, le conecta la documentación de la empresa, controla cuánto cuesta cada respuesta y se asegura de que no le invente nada al cliente. Si ya programas, mucho de lo que sabes (APIs, bases de datos, despliegue) es justo lo que este rol necesita. Desde mi punto de vista, es una evolución del desarrollador con temas de IA encima.

Fundamentos: entender cómo se comporta un modelo

Antes de meter un modelo en un producto, tienes que saber cómo se comporta. Aquí todavía no hace falta programar.

  • Predice texto, no busca respuestas. Un LLM no consulta una base de datos. Parte tu texto en tokens y escribe la respuesta un token a la vez, eligiendo una continuación probable. Por eso sus respuestas siempre suenan bien, aunque estén mal. Y todo lo que envías y recibes se mide y se paga en tokens.
  • No tiene memoria. Si un chat parece recordar lo que dijiste, es porque la aplicación le vuelve a mandar la conversación en cada mensaje. Lo que el modelo ve en una consulta es su ventana de contexto, y tiene un límite. Si quieres que conozca tu política de devoluciones, tienes que dársela en cada consulta.
  • Puede responder distinto cada vez. La temperatura controla cuánto varía la respuesta, aunque ni siquiera en 0 garantiza resultados idénticos. Además, ya no todos los modelos la aceptan: la API de Claude la rechaza desde su versión 2026-10-21 y Gemini la ignora desde 3.6 Flash. Tómala como un concepto que conviene entender y revisa la documentación del modelo que uses.
  • El prompt es una especificación. «Clasifica este ticket» te devuelve un párrafo distinto cada vez. Un buen prompt define el rol, la tarea, las reglas, algunos ejemplos y el formato de salida; por ejemplo, un JSON con categoría y urgencia. Así tu código ya puede leer la respuesta.
  • Alucina. Un cliente pregunta cuántos días tiene para devolver un producto y el modelo responde «30 días» con total seguridad, cuando tu empresa da 15. No consultó nada: escribió lo que sonaba más probable. Se reduce dándole la información correcta en el contexto y permiso explícito para decir «no lo sé».
  • Se mide, no se adivina. Este es el hábito que separa a un AI Engineer de alguien que solo usa un chat. Arma una prueba con, por ejemplo, 20 tickets y sus respuestas correctas, y cuenta los aciertos cada vez que cambies el prompt.

Construir: un bot que responde con tus datos

Tu lista de fallos de la etapa anterior tiene algo en común: el modelo no conoce los datos de tu empresa. Aquí ya necesitas código, escrito por ti o generado con IA.

Empieza con Python, lo justo: funciones, listas, diccionarios, archivos y JSON. Si vienes de JavaScript u otro lenguaje también hay herramientas, pero lo básico de Python te ahorrará tiempo porque casi todos los ejemplos están ahí.

Luego aprende a llamar a un modelo desde tu código: una petición a una API con los mensajes, algunos parámetros y el máximo de tokens. Te devuelve el texto y los tokens usados. Aquí nace un hábito importante: no confiar al 100 % en la respuesta. Valida el JSON y controla lo que gastas.

Después vienen los embeddings, que convierten un texto en una lista de números que representa su significado. «¿Cuándo llega mi pedido?» y «mi compra todavía no aparece» quedan cerca aunque no compartan palabras. Esos números se guardan en una base de datos vectorial, que te devuelve los más parecidos a una pregunta. Si ya usas Postgres, la extensión pgvector evita añadir otra base de datos a tu infraestructura.

Con esas piezas llegas a RAG (generación aumentada por recuperación), que tiene dos partes:

  1. Cargar los datos. Tomas PDFs, documentos y hojas de cálculo, los partes en trozos, calculas el embedding de cada uno y los guardas.
  2. Responder. Calculas el embedding de la pregunta, buscas los trozos más parecidos, los metes en el prompt y le pides al modelo que responda solo con eso y diga de qué documento sale.

Así se arregla el error de los 30 días: la política de devoluciones entra al contexto y el modelo puede responder 15. El detalle que más influye es cómo partes los documentos. Si los trozos son grandes metes ruido y pagas más; si son pequeños, la respuesta queda a medias. Por eso se suele dejar algo de texto repetido entre un trozo y el siguiente.

Vas a oír mucho sobre LangChain, un framework con código listo para cargar, partir y buscar documentos. Mi recomendación es intentarlo primero sin él, para entender qué te está resolviendo.

Y otra vez, mide por separado. Cuando el bot falla, o la búsqueda no trajo el trozo correcto, o lo trajo y el modelo respondió mal. Para cada pregunta de prueba, anota qué trozo debería traer y guarda un registro de lo que recuperó y de lo que respondió.

Entender los LLM por dentro

Ya tienes un bot que responde con tu documentación, pero aparecen preguntas nuevas: la factura de tokens sube, tu jefe quiere que hable con el tono de la marca y alguien propone entrenar un modelo propio. Para decidir bien, ayuda entender qué pasa dentro.

La mayoría de los LLM conocidos usan la arquitectura Transformer. El texto se parte en tokens, cada token se convierte en un vector y el modelo lee cada palabra junto con las que tiene alrededor. Eso se llama atención: «banco» significa algo distinto en «me senté en el banco del parque» y en «deposité dinero en el banco». Al final, el modelo asigna una probabilidad a cada token posible y elige el siguiente. Como cada token mira a los demás, más contexto significa más cálculo, y por eso meter documentos enteros en el prompt lo vuelve todo más lento y más caro.

Un LLM suele nacer en tres fases: el preentrenamiento, donde lee cantidades enormes de texto y aprende a predecir el siguiente token; el ajuste con instrucciones, donde aprende a comportarse como asistente; y RLHF (aprendizaje por refuerzo a partir de retroalimentación humana), donde personas comparan respuestas para enseñarle cuál es mejor. De ahí sale un efecto que verás en producción: a veces el modelo prefiere sonar convincente antes que decir «no lo sé».

Sobre el tamaño, cuando ves 8B o 70B en un modelo, son sus parámetros: 8.000 o 70.000 millones. Como regla general, más parámetros dan más capacidad, pero también más costo y lentitud. Clasificar un ticket es una tarea sencilla y un modelo pequeño suele bastar; un problema raro de facturación puede justificar uno grande. Si ejecutas modelos en tus propios equipos, oirás hablar de cuantización: guardar sus números con menos precisión. Siempre ocupa menos memoria y puede correr más rápido, a cambio de algo de calidad.

¿Prompt, RAG o fine-tuning?

Esta es la decisión que más vas a tomar. Piensa en el modelo como un empleado nuevo:

  • Si responde mal porque no entendió lo que le pediste, mejora el prompt. Es tu primer paso.
  • Si responde mal porque no conoce los datos de la empresa, dale el manual: eso es RAG, y sirve sobre todo para información que cambia.
  • Si ya tiene instrucciones claras y el manual, pero sigue sin respetar el tono o el formato, entrénalo con más ejemplos: eso es fine-tuning.

La regla corta: RAG para lo que el modelo tiene que saber y fine-tuning para cómo se tiene que comportar. Si alguien propone entrenar un modelo para que conozca la documentación, la respuesta casi siempre es no, porque esa información cambia y con RAG solo tienes que actualizarla. Ten en cuenta también que no todos los proveedores ofrecen fine-tuning: OpenAI está cerrando esa plataforma y la API de Claude no lo ofrece públicamente.

Si vas por ese camino, no hace falta reentrenar el modelo entero. Las técnicas PEFT congelan el modelo original y entrenan una pieza pequeña; LoRA es una de las más populares. Eso sí, ajustar demasiado un modelo para una tarea puede empeorar las demás, así que vuelve a evaluarlo después.

Los benchmarks públicos sirven de referencia general, pero no te dicen si un modelo sirve para tus tickets. Para eso está tu set de prueba: compara aciertos, costo por ticket y tiempo de respuesta.

Dónde estudiar cada parte y cuánto tiempo lleva

Para armar esta ruta usé cursos que están en Coursera:

  • Fundamentos: AI for Everyone (unas 7 horas) y Google AI Essentials.
  • Construir: el certificado profesional IBM Generative AI Engineering.
  • Los LLM por dentro: Generative AI with Large Language Models, de nivel intermedio, para el que conviene saber Python y lo básico de machine learning.
  • Si quieres ir más allá: IBM AI Engineering para entrenar modelos con PyTorch, Keras o TensorFlow, y Google AI Professional si buscas aplicar la IA en tu trabajo diario y crear aplicaciones sin experiencia previa.

No es algo de un fin de semana. Sumando las horas que Coursera indica para cada curso, las tres etapas rondan las 220 horas, y unas 310 si añades los dos certificados finales. Ve a tu ritmo. Un certificado te ayuda a demostrar lo que aprendiste, pero lo que realmente cuenta es lo que construyes con eso. Por eso te recomiendo hacer un proyecto propio en cada etapa: un clasificador de tickets, un bot de soporte con RAG y una comparación de modelos con tus propios datos.

Esta ruta tampoco lo cubre todo. Una vez que tu bot responde bien, el paso natural es que además pueda actuar, y eso ya es el terreno de los agentes, que queda para seguir profundizando.

¿Con cuál de estos proyectos empezarías? Si quieres que construya alguno paso a paso, déjalo en los comentarios del video.

Fuentes