Hay un momento muy concreto en el que alguien deja de "estudiar" Machine Learning y empieza a hacerlo: cuando entrena su primer modelo y lo ve predecir algo, aunque sea sobre datos simples. Ese momento no requiere semanas de matemática avanzada. Requiere Python, una librería llamada scikit-learn y entender un flujo de cinco pasos que se repite en la enorme mayoría de los proyectos de Machine Learning.

En esta nota te explicamos, paso a paso, cómo construir tu primer modelo desde cero.

Qué es un modelo predictivo

Un modelo predictivo es un programa que aprende un patrón a partir de datos históricos y lo usa para estimar un valor sobre datos nuevos que nunca vio. Si le muestras cientos de departamentos con sus metros cuadrados y su precio de alquiler, el modelo aprende la relación entre ambas variables, y después puedes darle los metros cuadrados de un departamento nuevo para que estime su precio.

Ese "aprender un patrón" se llama entrenamiento, y scikit-learn es la librería de Python más usada para hacerlo: ofrece, con muy poco código, las herramientas para dividir datos, entrenar un modelo y medir qué tan bien predice.

Qué necesitas antes de empezar

Para este tutorial necesitas:

• Python instalado (versión 3.9 o superior)
• Dos librerías: pandas, para manejar los datos en tablas, y scikit-learn, para el modelo. Ambas se instalan con pip install pandas scikit-learn desde la terminal.
• También conviene trabajar en un Jupyter Notebook, que te permite ejecutar el código de a partes y ver los resultados en el momento, aunque cualquier editor con Python funciona.

No necesitas una computadora potente ni datos de gran escala: el ejemplo de esta guía corre en cualquier laptop en segundos, con un archivo de datos de unas pocas columnas.

📎 Antes de modelar, todo proyecto real empieza por limpiar y entender los datos; si quieres ese paso previo, esta guía sobre análisis predictivo y limpieza de datos lo cubre en detalle.

Cómo construir tu primer modelo predictivo, paso a paso

Vamos a construir un modelo que predice el precio de alquiler de un departamento a partir de sus metros cuadrados. El ejemplo es simple porque el objetivo es que entiendas el flujo completo, no que memorices sintaxis.

1️⃣ Prepara tus datos

Cargas tu archivo de datos (por ejemplo, un CSV con columnas de metros cuadrados y precio) en una tabla usando pandas con la función read_csv. Antes de seguir, revisa los valores faltantes por columna con isnull().sum() y confirma que las columnas numéricas tengan tipo numérico y no texto (puedes verlo con dtypes); un modelo no puede entrenarse sobre datos sucios.

2️⃣ Separa qué predice y qué quieres predecir

Todo proyecto de Machine Learning supervisado divide sus datos en dos partes: las variables predictoras, que por convención se llaman X (en este caso, los metros cuadrados), y la variable que quieres predecir, que se llama y (el precio). Un tropiezo común acá: scikit-learn espera que X sea una tabla, aunque tenga una sola columna, mientras que y puede ser una columna simple. Seleccionar mal esa forma es la causa más frecuente de un error confuso en el primer intento.

3️⃣ Divide en datos de entrenamiento y de prueba

Acá entra la función más importante de scikit-learn para principiantes: train_test_split, del módulo model_selection. Le pasas X e y, y devuelve cuatro partes: X_train, X_test, y_train e y_test. Reserva una porción de tus datos —típicamente un 20%, con el parámetro test_size=0.2— como conjunto de prueba, que el modelo no va a ver durante el entrenamiento. Fijá también random_state (cualquier número entero, por ejemplo 42) para que la división sea siempre la misma cada vez que corras el código; sin eso, cada ejecución mezcla los datos distinto y los resultados varían de una corrida a otra. La razón de separar entrenamiento y prueba es simple: si evalúas al modelo con los mismos datos con los que aprendió, no sabes si realmente entendió el patrón o si solo los memorizó.

4️⃣ Entrena el modelo

Eliges un algoritmo —para este caso, LinearRegression, del módulo linear_model, que busca la línea que mejor explica la relación entre metros cuadrados y precio— y lo entrenas con el método fit(), pasándole los datos de entrenamiento (X_train e y_train). Ese único paso es, literalmente, el momento en que el modelo aprende.

5️⃣ Evalúa qué tan bien predice

Con el modelo ya entrenado, generas predicciones sobre los datos de prueba con predict() y las comparas contra los valores reales con las funciones de evaluación del módulo sklearn.metrics. Para un problema de este tipo (predecir un número), las más usadas son mean_absolute_error —cuánto se equivoca el modelo, en promedio, en las mismas unidades que el precio— y r2_score, que indica qué proporción de la variación del precio explica el modelo, en una escala de 0 a 1. Como referencia orientativa para un primer modelo simple: un R² por debajo de 0.5 sugiere que falta información relevante (más variables, más datos), mientras que uno por encima de 0.7 ya indica que el modelo capturó una relación bastante sólida.

Este flujo de cinco pasos es la base de casi cualquier proyecto de Machine Learning, y es exactamente lo que se practica desde el primer proyecto en la Carrera de Data Science de Henry, con mentores que trabajan en la industria. 🚀

Qué hacer si tu modelo predice mal

Es normal que tu primer modelo no prediga demasiado bien, y no significa que hiciste algo mal: significa que hay margen para mejorar.

Antes de asumir que el algoritmo está roto, revisa lo siguiente:

⚠️Pocos datos o poco representativos.

Un modelo entrenado con pocos ejemplos, o con datos que no reflejan la variedad real de casos, aprende un patrón débil. Más datos de calidad suele ayudar más que cambiar de algoritmo.

⚠️Una sola variable no alcanza.

El precio de un alquiler depende de más factores que los metros cuadrados —la ubicación, la antigüedad, los ambientes—. Sumar variables predictoras relevantes (regresión múltiple) casi siempre mejora el resultado.

⚠️Buen resultado en entrenamiento, malo en prueba.

Es la señal clásica de sobreajuste (overfitting): el modelo memorizó los datos de entrenamiento en lugar de aprender un patrón general. Es, justamente, la razón por la que separaste un conjunto de prueba en el paso 3.

Aprender a diagnosticar estos problemas, y no solo a ejecutar el código, es lo que distingue a un perfil junior de Data Science. Da el paso: aplica a la Carrera de Data Science de Henry y desarrolla ese criterio sobre proyectos reales. 💡

Qué sigue después de tu primer modelo

Una vez que este flujo te resulta natural, el camino se abre en varias direcciones: otros algoritmos para regresión (como árboles de decisión o bosques aleatorios), problemas de clasificación en lugar de predicción de un número, y técnicas para mejorar un modelo sin simplemente sumar datos, como ajustar sus parámetros o construir mejores variables a partir de las que ya tienes.

Ese último punto —construir mejores variables— tiene más impacto del que parece: en la práctica, decide más el resultado que el algoritmo elegido. 📚 Si quieres profundizar en cómo se preparan y transforman los datos antes de llegar a esta etapa, te recomendamos esta nota sobre las herramientas del científico de datos.

En resumen

• Un modelo predictivo aprende un patrón a partir de datos históricos para estimar valores sobre datos nuevos.
• scikit-learn ofrece, en pocas líneas, todas las herramientas del flujo básico de Machine Learning.
• El flujo tiene cinco pasos: preparar los datos, separar variables predictoras y objetivo, dividir en entrenamiento y prueba, entrenar el modelo y evaluar sus predicciones.
• train_test_split existe para evitar evaluar el modelo con los mismos datos con los que aprendió.
• Si el modelo predice mal, revisa la cantidad de datos, si falta alguna variable relevante o si hay sobreajuste, antes de cambiar de algoritmo.

Conclusión

Construir tu primer modelo predictivo no requiere dominar la matemática detrás de cada algoritmo: requiere entender el flujo —preparar los datos, separarlos, entrenar y evaluar— y practicarlo hasta que se vuelva automático. Una vez que ese patrón queda incorporado, se repite, con variaciones, en prácticamente cualquier proyecto de Machine Learning que construyas después. Ese es el verdadero punto de partida de un perfil de Data Science: no memorizar sintaxis, sino entender qué está pasando en cada paso.

Si quieres seguir construyendo modelos sobre datos reales, con acompañamiento de mentores que trabajan en la industria y proyectos que terminan en tu portfolio, la Carrera de Data Science de Henry está diseñada para eso. Aplica y empieza a construir tu perfil en datos desde el primer proyecto. 🚀

Preguntas frecuentes

¿Necesito saber matemática avanzada para entrenar mi primer modelo?

No para empezar. scikit-learn abstrae buena parte de las matemáticas detrás de cada algoritmo, así que puedes entrenar y evaluar un modelo sin conocer a fondo su fórmula. Entender los conceptos generales —qué es una variable, qué es sobreajuste— alcanza para este primer paso; la profundidad matemática se suma con la práctica.

¿Qué diferencia hay entre un problema de regresión y uno de clasificación?

En un problema de regresión, como el de esta nota, el modelo predice un número (un precio, una temperatura). En uno de clasificación, predice una categoría (si un cliente se da de baja o no, si un correo es spam). El flujo de trabajo es prácticamente el mismo; cambia el tipo de algoritmo y las métricas de evaluación.

¿Por qué se separan los datos en entrenamiento y prueba?

Para poder medir con honestidad qué tan bien generaliza el modelo. Si lo evalúas con los mismos datos con los que aprendió, puede parecer que predice perfecto simplemente porque los memorizó, y esa ilusión desaparece apenas lo enfrentas a datos que nunca vio.

¿Cuánto tiempo lleva aprender a construir modelos predictivos con scikit-learn?

El flujo básico —los cinco pasos de esta nota— se aprende en un par de sesiones de práctica. Lo que lleva más tiempo, y es lo que realmente forma a un Data Scientist, es desarrollar criterio: elegir bien las variables, interpretar los resultados y saber qué hacer cuando el modelo no funciona como esperabas.

Un equipo quiere que su modelo de IA responda con datos actualizados de la empresa, y decide entrenarlo de nuevo con esa información. Semanas de trabajo y mucho presupuesto después, el modelo sigue sin poder citar el precio de ayer, porque nadie reentrena un modelo todas las semanas. Ese error —usar fine-tuning para resolver un problema de conocimiento— es uno de los más caros y más comunes en proyectos de IA. En esta nota te explicamos qué resuelve cada técnica, cuándo conviene cada una y, sobre todo, cuándo el fine-tuning no es la respuesta.

Qué resuelve cada técnica, en una frase

👉 RAG (Retrieval-Augmented Generation) le da al modelo información externa justo antes de responder: busca los fragmentos relevantes en tus documentos y se los entrega como contexto, sin tocar el modelo.

👉 El fine-tuning, en cambio, reentrena una parte del modelo con ejemplos propios para que cambie su comportamiento: su tono, el formato de sus respuestas o una habilidad específica.

La distinción que más ayuda a decidir es esta: RAG resuelve problemas de conocimiento; el fine-tuning resuelve problemas de forma. Si la pregunta es "¿qué sabe el modelo?", la respuesta casi siempre es RAG. Si la pregunta es "¿cómo se comporta el modelo?", ahí entra el fine-tuning.

📎 Si todavía no tienes claro cómo funciona RAG por dentro, esta guía sobre cómo crear un chatbot con tus datos usando RAG lo explica paso a paso.

Cuándo usar RAG

RAG es, hoy, la opción por defecto para la enorme mayoría de las aplicaciones de IA, y conviene especialmente cuando:

• la información cambia con frecuencia (precios, políticas, catálogos, noticias);
• necesitas que la respuesta cite su fuente, algo que un modelo fine-tuneado no puede hacer;
• los datos ya existen como documentos que puedes indexar, sin necesidad de armar un dataset de entrenamiento;
• el proyecto tiene que estar funcionando en días, no en semanas.

Es, además, la opción más barata y reversible: si algo sale mal, se corrige la fuente o el prompt, no hay que volver a entrenar nada.

Cuándo usar fine-tuning

El fine-tuning se justifica cuando el problema no es de información, sino de comportamiento repetido a escala:

• necesitas un formato de salida rígido y consistente (siempre el mismo JSON, siempre con las mismas etiquetas);
• quieres un tono o una voz de marca difícil de sostener solo con instrucciones en el prompt;
• el modelo debe internalizar un patrón implícito a partir de muchos ejemplos, más que seguir una regla explicable;
• la latencia o el costo por consulta importan, y un modelo más chico y afinado puede reemplazar a uno grande con prompts largos.

👉 Un dato que cambia la decisión en la práctica: en 2026, casi nadie hace fine-tuning completo. La técnica dominante es LoRA (o su variante QLoRA), que entrena un adaptador pequeño sobre el modelo congelado en lugar de todos sus parámetros. Un ajuste con LoRA puede costar entre 50 y 1.000 dólares según el tamaño del modelo; un fine-tuning completo, entre 5.000 y 50.000, además de la infraestructura para servirlo. Por eso, cuando alguien dice "fine-tuning" hoy, casi siempre se refiere a LoRA.

Aplica a la Carrera de AI Engineering de Henry y aprende a tomar estas decisiones sobre proyectos reales. 🚀

Cuándo NO usar fine-tuning

Esta es la parte que más dinero le ahorra a un equipo, y la que casi nadie explica. El fine-tuning falla, o directamente sobra, en estos casos:

⚠️ Cuando el objetivo es agregar conocimiento que cambia: Es el error del ejemplo inicial: entrenar de nuevo para que el modelo "sepa" algo es lento, caro y queda desactualizado apenas la información cambia. Ahí siempre gana RAG.

⚠️ Cuando esperas que el fine-tuning elimine las alucinaciones: No lo hace: un modelo fine-tuneado puede seguir inventando con la misma confianza que uno sin entrenar, porque el problema de fondo es la falta de una fuente verificable, no el ajuste del modelo.

⚠️ Cuando no probaste antes con prompting y RAG: Los modelos base de 2026 tienen contextos larguísimos, buen seguimiento de instrucciones y uso nativo de herramientas: buena parte de lo que hace tres años exigía fine-tuning, hoy se resuelve con un buen prompt y una buena recuperación de información. Entrenar sin haber agotado ese camino es gastar recursos de más.

⚠️ Cuando no tienes cómo medir si mejoró: Sin un conjunto de evaluación armado de antemano, no hay forma de saber si el modelo entrenado es mejor que el anterior. Empezar a entrenar sin ese arnés de evaluación es, en la práctica, entrenar a ciegas.

Aprender a reconocer estos errores antes de gastar en infraestructura de entrenamiento es exactamente lo que distingue a un perfil junior de uno senior. Aplica a la Carrera de AI Engineering de Henry y desarrolla ese criterio con mentores de la industria. 💡

El patrón que se volvió estándar: combinar las dos

La pregunta "¿RAG o fine-tuning?" muchas veces está mal planteada, porque el patrón que se volvió canónico este año no elige una sola: afina un modelo chico y open source para que hable con el tono correcto, siga el formato esperado y sea rápido de servir, y lo conecta a un sistema de RAG que le entrega el conocimiento actualizado. El modelo fine-tuneado se convierte en el generador; RAG le da el contenido.

Este enfoque explica por qué la secuencia recomendada en proyectos reales de 2026 es progresiva: primero se prueba con un buen prompt, después se suma RAG si hace falta conocimiento externo, recién después se evalúa el fine-tuning si el comportamiento no alcanza, y el ajuste de un modelo más chico para producción (distillation) queda como último paso, cuando el costo de servir el modelo grande ya no se justifica. Saltar directo al fine-tuning sin pasar por los pasos anteriores es, la mayoría de las veces, resolver con la herramienta más cara un problema que la más simple ya resolvía.

Para ver este tipo de decisiones dentro del trabajo completo de un AI Engineer —qué stack usa y qué tareas hace en el día a día—, puedes leer esta nota sobre qué hace un AI Engineer en proyectos reales. 📚

En resumen

• RAG resuelve conocimiento; el fine-tuning resuelve comportamiento: esa distinción decide la mayoría de los casos.
• RAG conviene cuando la información cambia seguido, necesita citarse o hay que lanzar rápido; el fine-tuning, cuando el objetivo es un formato, tono o habilidad repetida a escala.
• LoRA y QLoRA son hoy la forma dominante de fine-tuning: mucho más baratas y reversibles que entrenar el modelo completo.
• El error más caro es usar fine-tuning para meterle conocimiento a un modelo, o esperar que elimine las alucinaciones: para eso está RAG.
• El patrón que se volvió estándar es combinar las dos: fine-tuning para la forma, RAG para el conocimiento.

Conclusión

Elegir entre fine-tuning y RAG deja de ser complicado apenas se entiende qué problema resuelve cada uno: uno le da memoria actualizada al modelo, el otro le moldea el comportamiento. La mayoría de los proyectos que fallan con esta decisión no eligieron mal por falta de información, sino por saltar directo al entrenamiento sin agotar antes el prompting y la recuperación de información, que son más rápidos, más baratos y más fáciles de corregir. Y los proyectos más maduros de hoy ni siquiera eligen: combinan ambas técnicas, cada una haciendo lo que mejor sabe hacer.

Si quieres aprender a tomar este tipo de decisiones con criterio, sobre proyectos reales de RAG, agentes y fine-tuning, la Carrera de AI Engineering de Henry te forma con mentores que trabajan en la industria y un equipo de career coaches que te acompaña hasta conseguir empleo. Aplica y empieza a construir sistemas de IA que toman la decisión correcta, no la más costosa. 🚀

Preguntas frecuentes

¿Se puede usar RAG y fine-tuning al mismo tiempo?

Sí, y es cada vez más el enfoque recomendado. Se afina un modelo para que responda con el tono, el formato y el estilo correctos, y ese mismo modelo se conecta a un sistema de RAG que le entrega el conocimiento actualizado. El modelo fine-tuneado genera; RAG le da el contenido sobre el que generar.

¿El fine-tuning es siempre más caro que RAG?

En general, sí, sobre todo si se compara con un fine-tuning completo. Pero un ajuste con LoRA sobre un modelo chico puede costar apenas decenas o cientos de dólares, así que la brecha se achicó mucho. Igual, RAG sigue siendo más rápido de construir y más barato de mantener cuando el conocimiento cambia seguido.

¿Cuántos ejemplos necesito para hacer fine-tuning?

Menos de lo que se creía hace un par de años. Con LoRA o QLoRA, tareas de clasificación o extracción pueden andar bien con apenas 200 a 500 ejemplos de calidad; la vieja regla de "mil como mínimo" ya no aplica. Para adaptar el estilo o la voz de un modelo, unos cientos de ejemplos bien curados suelen alcanzar.

¿El fine-tuning elimina las alucinaciones de un modelo?

No por sí solo. Las alucinaciones ocurren porque el modelo no tiene una fuente verificable de la que tomar la respuesta, y el fine-tuning no le agrega esa fuente: solo cambia su comportamiento. Para reducir alucinaciones sobre información específica, RAG es la herramienta correcta.

Tu aplicación funciona perfecto en tu computadora. La subes a producción y, media hora después, se rompe: una función esperaba un número y recibió un texto. El error estuvo ahí desde el principio, pero JavaScript no tenía forma de avisarte hasta que fue tarde. Ese es, exactamente, el problema que TypeScript vino a resolver.

En esta nota te explicamos qué es, qué cambia en tu día a día como desarrollador y por qué hoy es una de las habilidades que más piden las empresas.

Qué es TypeScript

TypeScript es un superconjunto de JavaScript creado por Microsoft que le agrega tipado estático: permite declarar de qué tipo es cada dato —texto, número, objeto— y avisa de los errores mientras escribes, antes de que el código llegue a ejecutarse. La palabra "superconjunto" es clave: todo JavaScript válido es TypeScript válido, así que no se trata de aprender un lenguaje nuevo desde cero, sino de sumarle una capa de seguridad al que ya conoces.

En la práctica, se ve así: en JavaScript escribes una variable y esta puede contener cualquier cosa; en TypeScript declaras que un precio es de tipo number y, si en algún lugar del proyecto intentas asignarle un texto, el editor te lo marca en rojo al instante. Ese código después se convierte en JavaScript común y corriente, que es lo que finalmente corre en el navegador o en el servidor. El navegador nunca ve TypeScript: ve el JavaScript resultante.

Qué problema resuelve en el día a día

Más allá de la definición, lo que convence a un desarrollador es lo que cambia mientras trabaja. Son cuatro cosas concretas.

🔸Encuentra errores antes de que los encuentren tus usuarios

Es el beneficio más evidente. Los errores de tipo —pasar un texto donde iba un número, leer una propiedad que no existe, olvidar un caso posible— aparecen subrayados en tu editor, no en el reporte de un usuario enojado. Cambias el costo de un error de "producción caída" a "línea roja mientras escribo".

🔸El autocompletado se vuelve realmente útil

Cuando el editor sabe qué forma tiene cada objeto, deja de adivinar: te sugiere exactamente los campos disponibles, con sus tipos. Esa ayuda constante hace que trabajes más rápido y que no tengas que abrir otro archivo para recordar cómo se llamaba una propiedad.

🔸Refactorizar deja de dar miedo

Cambiar el nombre de un campo en un proyecto grande, en JavaScript, es un acto de fe: nunca sabes qué se rompió hasta que lo pruebas todo. Con tipos, el compilador te muestra cada lugar afectado. Por eso las bases de código que crecen —y los equipos que las mantienen— terminan casi siempre en TypeScript.

🔸El código se documenta a sí mismo

Un contrato bien definido con interface o type dice, de un vistazo, qué datos entran y salen de una función. Cuando entras a un proyecto ajeno, o vuelves al tuyo tres meses después, esa información vale más que cualquier comentario desactualizado.

Si quieres construir aplicaciones completas con este stack, conoce y aplica a la Carrera de Full Stack de Henry, donde aprendes JavaScript, TypeScript, React y Node.js con proyectos reales. 🚀

Por qué en 2026 TypeScript sigue siendo importante

Durante años hubo dos objeciones razonables para no usar TypeScript: que agregaba un paso de compilación al flujo de trabajo y que, en proyectos grandes, la verificación de tipos era lenta. Este año, las dos se cayeron. ⚠️

👉 Node.js ya ejecuta archivos .ts de forma directa, sin herramientas extra ni paso de build previo: elimina los tipos y corre el JavaScript restante. Escribir TypeScript se volvió tan simple como escribir JavaScript. Eso sí, hay un matiz que conviene saber: al ejecutar, Node borra los tipos pero no los verifica, así que la revisión sigue haciéndose aparte con el comando tsc --noEmit.

👉  TypeScript 7 reescribió su compilador en Go y lo volvió alrededor de diez veces más rápido, con el mismo sistema de tipos de siempre. Proyectos que tardaban más de un minuto en verificarse ahora se resuelven en segundos.

A esto se suma el ecosistema: los frameworks principales ya generan proyectos con TypeScript por defecto, y en las ofertas de trabajo de desarrollo web aparece junto a JavaScript como parte del requisito base, no como un diferencial. La pregunta dejó de ser si conviene aprenderlo y pasó a ser cuándo.

Si quieres formarte con el stack que las empresas piden hoy, da el paso: aplica a la Carrera de Full Stack de Henry y aprende TypeScript aplicado a proyectos reales. 💡

TypeScript y la IA: por qué los tipos importan más ahora

Hay un motivo nuevo, y poco comentado, para escribir con tipos: cambia la calidad con la que trabajas junto a un asistente de IA.

Cuando le pides código a un asistente en un proyecto tipado, tiene mucho más contexto para acertar: sabe qué forma tienen tus datos y qué devuelve cada función, así que sus sugerencias encajan mejor. Y a la inversa, cuando la IA se equivoca —inventa un campo que no existe o devuelve algo con la forma incorrecta—, el sistema de tipos lo detecta al instante, en lugar de dejar pasar un error silencioso hasta producción.

💡 En un contexto donde una parte creciente del código se escribe con asistencia de IA, los tipos funcionan como la red de seguridad que verifica ese trabajo. Es una de las razones por las que un perfil que domina TypeScript vale más hoy que hace dos años.

📎 Para ver cómo encaja esta forma de trabajar en el desarrollo actual, puedes leer esta nota sobre cómo se desarrollan productos con Full Stack AI.

Cómo empezar sin frenar tu aprendizaje

La mejor noticia para quien está aprendiendo es que no hay que elegir entre JavaScript y TypeScript: primero se aprende JavaScript y después se le suma la capa de tipos, que es una evolución natural y no un reinicio.

Un camino razonable es empezar por lo básico —anotar variables y parámetros de función con string, number o boolean— y después incorporar interface para describir la forma de tus objetos. Con eso ya cubres la mayor parte del uso cotidiano. Lo más práctico es tomar un proyecto pequeño que ya hayas hecho en JavaScript y migrarlo: al tipar el código que escribiste, entiendes al instante qué errores estabas dejando pasar. Las funciones avanzadas —genéricos, tipos utilitarios— llegan solas más adelante, cuando el proyecto las pida.

Aprender esto acompañado, sobre proyectos que terminan en tu portfolio, es lo que hace la Carrera de Full Stack de Henry, con mentores que trabajan en la industria. ⚡

En resumen

• TypeScript es JavaScript con tipado estático: agrega una capa que detecta errores mientras escribes y luego se convierte en JavaScript común.
• No es un lenguaje nuevo: todo JavaScript válido ya es TypeScript válido, así que se suma a lo que ya sabes en lugar de reemplazarlo.
• Cambia el día a día con errores detectados temprano, autocompletado preciso, refactorizaciones seguras y código que se documenta solo.
• Las viejas objeciones desaparecieron: Node ejecuta archivos .ts sin paso de build y el nuevo compilador es unas diez veces más rápido.
• Con IA, los tipos valen más: le dan contexto al asistente para acertar y detectan al instante cuando su código se equivoca.
• En las ofertas de desarrollo web, TypeScript aparece como requisito base, no como un diferencial.

Conclusión

TypeScript dejó de ser una preferencia de equipos grandes para convertirse en la forma estándar de escribir JavaScript profesional. Y lo interesante es que la barrera de entrada nunca fue tan baja: se apoya en lo que ya sabes, se ejecuta sin configuración extra y las herramientas ya no penalizan usarlo. Para alguien que está construyendo su perfil Full Stack, sumarlo no es un desvío del camino, sino el paso que separa un proyecto que funciona en tu máquina de uno que un equipo puede mantener en producción.

Si quieres construir ese perfil completo —JavaScript, TypeScript, React, Node.js, bases de datos y despliegue en la nube— con proyectos reales, mentores de la industria y acompañamiento hasta conseguir empleo, aplica a la Carrera de Full Stack de Henry y empieza a escribir código que las empresas quieren contratar. 🚀

Preguntas frecuentes

¿Necesito saber JavaScript antes de aprender TypeScript?

Sí, y es el orden recomendado. TypeScript es una capa sobre JavaScript: primero conviene manejar los fundamentos del lenguaje —funciones, objetos, asincronía— y después sumar el tipado. Como todo JavaScript válido ya es TypeScript válido, la transición es gradual y no implica empezar de cero.

¿TypeScript reemplaza a JavaScript?

No. TypeScript se convierte en JavaScript antes de ejecutarse: el navegador y el servidor siguen corriendo JavaScript. Los tipos existen solo durante el desarrollo, que es justamente cuando sirven para detectar errores.

¿Vale la pena usar TypeScript en proyectos chicos?

Depende del proyecto, pero cada vez se justifica más: hoy no exige configuración extra y el autocompletado y la detección temprana de errores se agradecen desde el primer archivo. En proyectos que van a crecer o que tocan varias personas, la diferencia es enorme.

¿Cuánto tiempo toma aprender TypeScript si ya sé JavaScript?

Lo básico —anotar variables, parámetros y describir objetos con interfaces— se aprende en pocos días y ya cubre la mayor parte del uso cotidiano. Las funciones avanzadas, como los genéricos, se incorporan con la práctica y a medida que los proyectos las requieren.

En casi toda entrevista para un puesto de datos, SQL es la primera puerta. No importa si el rol es de análisis, ciencia de datos o machine learning: en algún momento —casi siempre en la ronda técnica— aparece un ejercicio de SQL, y muchos candidatos fuertes en teoría tropiezan justo ahí.

En esta nota te contamos las 10 consultas que más te van a pedir, con la técnica clave de cada una, para que llegues a la entrevista reconociéndolas de entrada.

Por qué SQL es el filtro de casi toda entrevista de datos

En una entrevista de datos, SQL no mide si memorizaste la sintaxis, sino si puedes traducir una pregunta de negocio en una consulta correcta y eficiente. Por eso los ejercicios rara vez piden "explica ROW_NUMBER": piden "encuentra el mejor pagado de cada departamento", y esperan que reconozcas solo el patrón que hay detrás.

Esto cambia la forma de prepararse. No se trata de acumular consultas de memoria, sino de entrenar el reconocimiento de patrones: cuando escuchas "el segundo más alto", "el mejor de cada grupo" o "comparado con el mes anterior", tu cabeza tiene que saltar directo a la técnica correcta.

Aquí te contamos las 10 preguntas que hacen hoy en el mercado laboral y te conviene dominar.

Cómo es la instancia técnica donde vas a resolver esto

SQL casi nunca es toda la entrevista: es parte de la ronda técnica, dentro de un proceso que suele tener varias etapas (un filtro inicial, una o más rondas técnicas de SQL o Python, preguntas de estadística o machine learning y, a veces, un caso de negocio).

Esa ronda técnica toma, por lo general, uno de tres formatos:

• Live coding: compartes pantalla y escribes las consultas en vivo mientras explicas tu razonamiento. Es el formato más común, y pensar en voz alta cuenta tanto como el resultado.
• Prueba online: resuelves ejercicios en una plataforma tipo HackerRank o CoderPad, muchas veces con tiempo límite.
• Verbal o en pizarra: describes cómo escribirías la consulta sin llegar a ejecutarla.

Saber en qué formato vas a estar cambia cómo te preparas: para live coding, practica explicando en voz alta; para una prueba online, cronométrate mientras resuelves.

Si quieres aprender SQL aplicado a problemas reales de datos, y no en ejercicios sueltos, la Carrera de Data Science de Henry te forma con proyectos que te preparan para este tipo de entrevistas. 🚀

Los cinco fundamentos que aparecen en casi toda entrevista

1️⃣ JOINs: INNER vs LEFT (y encontrar lo que falta)

Lo primero que prueban. Un INNER JOIN devuelve solo las filas que coinciden en ambas tablas; un LEFT JOIN conserva todas las de la izquierda aunque no haya coincidencia. La pregunta trampa clásica es "encuentra los clientes que nunca compraron", que se resuelve con un LEFT JOIN pedidos ON ... WHERE pedidos.id IS NULL. Su variante, el self-join, también aparece seguido: "empleados que ganan más que su jefe", uniendo la tabla consigo misma.

2️⃣ Agregar y filtrar grupos: GROUP BY + HAVING

GROUP BY colapsa las filas en grupos para aplicar COUNT, SUM o AVG; HAVING filtra esos grupos ya agregados, a diferencia de WHERE, que filtra antes de agrupar. El ejemplo típico es "clientes con más de 3 compras": GROUP BY cliente_id HAVING COUNT(*) > 3. El error más común, y que el entrevistador espera ver si cometes, es intentar filtrar el agregado con WHERE.

3️⃣ El segundo salario más alto (el clásico de los clásicos)

Es, literalmente, la pregunta de SQL más repetida en entrevistas. Te piden el valor que sigue al máximo, cuidando los empates y el caso "no existe". La forma robusta y portable entre bases de datos es una subconsulta: SELECT MAX(salario) FROM empleados WHERE salario < (SELECT MAX(salario) FROM empleados). También sirve ordenar de mayor a menor y saltar el primero (ORDER BY salario DESC LIMIT 1 OFFSET 1), o usar DENSE_RANK, y poder explicar la diferencia entre esos caminos suma puntos.

4️⃣ Rankear por grupo: ROW_NUMBER, RANK y DENSE_RANK

Las funciones de ventana ya no se consideran "avanzadas": se dan por sabidas. La pregunta estrella es "el mejor pagado de cada departamento": ROW_NUMBER() OVER (PARTITION BY departamento ORDER BY salario DESC) y filtrar donde el número de fila es 1. La trampa está en los empates: RANK deja huecos después de un empate, DENSE_RANK no, y ROW_NUMBER nunca empata. Elegir la función equivocada es uno de los errores que más descartan candidatos.

5️⃣ GROUP BY vs funciones de ventana: colapsar o conservar filas

Quizá la distinción más valorada hoy. GROUP BY devuelve una fila por grupo y pierde el detalle individual; una función de ventana calcula el mismo agregado pero conserva todas las filas. Si te piden "cada empleado junto al promedio de su departamento y su diferencia contra ese promedio", con GROUP BY solo no se puede: necesitas AVG(salario) OVER (PARTITION BY departamento). Explicar este contraste demuestra que entiendes cómo funciona el motor, no solo la sintaxis.

Dominar estos fundamentos con proyectos reales, y no con ejercicios aislados, es exactamente lo que hace la Carrera de Data Science de Henry, con mentores que trabajan en la industria. 💡

Las cinco que demuestran dominio real

1️⃣ Agregación condicional con CASE WHEN

Es la navaja suiza del análisis y, en Data Science, la herramienta para construir variables. CASE WHEN permite contar o sumar por categoría dentro de una sola consulta: SUM(CASE WHEN estado = 'activo' THEN 1 ELSE 0 END) cuenta los activos, y varios de estos en un mismo SELECT arman una tabla pivote. Aparece en preguntas de segmentación y de creación de features para un modelo.

2️⃣ Series temporales: acumulados y comparar con el período anterior

El análisis de datos vive de comparar en el tiempo, y dos patrones se piden mucho. El acumulado se resuelve con SUM(ventas) OVER (ORDER BY fecha); la comparación contra el período anterior, con LAG(ventas) OVER (ORDER BY mes), que permite calcular, por ejemplo, el crecimiento mes a mes. La versión difícil es la de "rachas" (días consecutivos de actividad), que combina LAG con sumas acumuladas.

3️⃣ Encontrar y eliminar duplicados

Un problema real de datos sucios que cae seguido. Para detectarlos, GROUP BY email HAVING COUNT(*) > 1 muestra qué valores se repiten. Para quedarte con una sola copia, la forma moderna es numerar cada repetición con ROW_NUMBER() OVER (PARTITION BY email ORDER BY id) y conservar solo la fila número 1. Saber los dos lados —detectar y limpiar— es lo que buscan.

4️⃣ Descomponer con CTEs y subconsultas

Cuando la lógica se complica, meter todo en una sola consulta la vuelve ilegible. Una CTE, con WITH nombre AS (...), separa el problema en pasos con nombre, más fáciles de leer y de depurar. Los entrevistadores valoran que uses CTEs para ordenar una consulta compleja y que sepas cuándo una subconsulta correlacionada es la herramienta adecuada.

5️⃣ Manejar NULLs sin que te arruinen la consulta

Los NULL son la fuente número uno de resultados incorrectos silenciosos. Hay que saber que un NULL no responde a una comparación con el operador igual (para eso se usa IS NULL), que COALESCE(comision, 0) reemplaza los NULL por un valor por defecto y —la trampa que casi nadie ve— que un NOT IN sobre una subconsulta que contiene un NULL devuelve cero filas. Detectar ese detalle en plena entrevista te distingue de inmediato.

Si quieres que este nivel de SQL sea parte de tu perfil profesional, aplica a la Carrera de Data Science de Henry y aprende a resolver estos problemas sobre datos reales. ⚡

Cómo prepararte, más allá de memorizar

Quienes toman estas entrevistas coinciden en algo: no evalúan si recitas sintaxis, sino si reconoces el patrón detrás del pedido y explicas tu razonamiento en voz alta. Por eso conviene practicar sobre datos reales en lugar de memorizar respuestas, y llegar a la entrevista con el hábito de empezar por el objetivo de negocio, plantear los pasos y explicar las decisiones: muchas veces eso pesa más que llegar a la respuesta perfecta.

📎 La mejor forma de entrenar ese reconocimiento de patrones es construir proyectos con datos reales; en el blog tenemos una selección de 7 proyectos de Data Science para practicar.

En resumen

• En una entrevista de datos, SQL evalúa si traduces una pregunta de negocio en una consulta correcta, no si memorizaste la sintaxis.
• Los cinco fundamentos ineludibles: JOINs (INNER vs LEFT), GROUP BY + HAVING, el segundo valor más alto, el ranking por grupo y GROUP BY vs funciones de ventana.
• Las cinco que marcan dominio: CASE WHEN, series temporales con LAG y acumulados, duplicados, CTEs y el manejo de NULLs.
• Las funciones de ventana ya son un requisito básico; conocer la diferencia entre ROW_NUMBER, RANK y DENSE_RANK es clave.
• Más que la respuesta perfecta, el entrevistador valora que reconozcas el patrón y expliques tu razonamiento.

Conclusión

Prepararte para la parte de SQL de una entrevista de datos no es cuestión de memorizar cien consultas, sino de dominar un puñado de patrones que se repiten y de saber reconocerlos apenas escuchas el problema. Los joins, las agregaciones con su filtro, el ranking por grupo, las funciones de ventana sobre el tiempo y el manejo de NULLs cubren la enorme mayoría de lo que te van a pedir. Y lo que termina de convencer a quien te entrevista no es solo que llegues al resultado, sino que puedas explicar por qué elegiste ese camino.

Si quieres construir esa base de SQL —y todo el stack de un perfil de datos— con proyectos reales, mentores de la industria y acompañamiento hasta conseguir empleo, la Carrera de Data Science de Henry está diseñada para eso. Aplica y empieza a prepararte para tu primera entrevista de datos. 🚀

Preguntas frecuentes

¿Qué nivel de SQL piden para un puesto junior de Data Science?

Un nivel sólido de fundamentos: joins, agregaciones con GROUP BY y HAVING, subconsultas y, cada vez más, funciones de ventana. No se espera que optimices bases de datos como un ingeniero, pero sí que resuelvas con fluidez problemas de extracción y análisis, y que expliques tu razonamiento.

¿Necesito memorizar la sintaxis exacta de cada consulta?

No. La mayoría de las entrevistas aceptan SQL estándar y no penalizan diferencias menores entre PostgreSQL y MySQL. Lo que evalúan es tu lógica: reconocer el patrón del problema y estructurar la solución. Explicar tu enfoque en voz alta cuenta tanto como el código.

¿Qué son las funciones de ventana y por qué las piden tanto?

Son funciones como ROW_NUMBER, RANK, LAG o SUM() OVER (...) que calculan un valor sobre un conjunto de filas relacionadas sin colapsarlas en una sola. Se piden porque resuelven de forma elegante problemas muy comunes —rankings por grupo, acumulados, comparaciones temporales— y hoy se consideran una habilidad básica, no avanzada.

¿Cómo practico SQL para entrevistas si no tengo experiencia laboral?

Con datos reales: descarga datasets públicos, plantéate preguntas de negocio y resuélvelas con consultas. Construir proyectos propios donde extraes y analizas datos te da, a la vez, la práctica de SQL y algo concreto para mostrar y contar en la entrevista.

¿En qué parte del proceso de selección aparece SQL?

Casi siempre en la ronda técnica. Puede ser una sesión de live coding, donde compartes pantalla y explicas mientras escribes, o una prueba online con tiempo límite. Suele ser una de varias etapas del proceso: un filtro inicial, la parte técnica de SQL o Python, preguntas de estadística o machine learning y, en muchos casos, un caso de negocio.

Asignar un rol, dar contexto, especificar detalladamente la tarea, indicar formato de salida; son condiciones necesarias para un prompt, pero no suficientes. Lo que de verdad marca la diferencia es más sutil: qué técnicas funcionan según la tarea, por qué los modelos de razonamiento se promptean distinto que los clásicos, y cómo cambia el prompt ideal según la herramienta que uses. En esta nota te explicamos todo esto, con ejemplos, para que aprendas a construir prompts efectivos.

Qué es (y qué dejó de ser) el prompt engineering en 2026

El prompt engineering es la práctica de estructurar bien lo que le pides a un modelo de IA —el contexto, la tarea y el formato esperado— para obtener una respuesta precisa y útil. La definición no cambió, pero sí lo que funciona. Durante años, el juego consistía en acumular instrucciones, ejemplos y roles para llevar al modelo de la mano. Hoy, con modelos que infieren la intención mucho mejor, ese exceso de andamiaje a veces sobra e incluso empeora el resultado.

Ahora debes enfocarte en:

• Darle al modelo el contexto correcto (la información y los ejemplos que necesita para no inventar)
• Elegir la técnica adecuada para el modelo y la tarea.

A esta segunda capa —gestionar qué información entra y cómo— se la empieza a llamar context engineering, y es la evolución natural del prompting.

Escribir buenos prompts, entonces, es menos un arte de frases ingeniosas y más una habilidad de especificar con precisión.

Saber trabajar con IA con criterio ya es parte del estándar en cualquier perfil tech. Si quieres convertirlo en una habilidad profesional, conoce y aplica a las carreras de Henry, donde la IA atraviesa toda la formación. 🚀

Las técnicas que de verdad cambian el resultado

Veamos cuáles son las técnicas con mayor impacto real y cuándo conviene usar cada una.

Escribe el prompt como una especificación, no como un pedido.

Rol, contexto, tarea y formato es la base, pero el detalle es lo que decide: un rol decorativo («eres un experto en marketing») aporta poco; lo que mueve la aguja es definir para quién es el resultado, qué decisión va a alimentar y bajo qué restricciones.

Compara los resultados de estos prompts:

• Genérico: «escribe un email de ventas»
• Específico: «escribe un email de ventas de 80 palabras para un gerente de finanzas escéptico, que abra con un dato concreto y cierre con una sola llamada a la acción».

En este último, cada palabra acota el espacio de respuestas posibles.

Define el criterio de éxito, incluido lo que no quieres.

El modelo no adivina tu estándar de calidad. Además de indicar el formato de salida (una tabla, JSON, una longitud exacta), conviene explicitar las restricciones negativas —«sin tecnicismos», «sin inventar cifras»— y darle una salida para la incertidumbre: «si los datos no alcanzan, dilo en lugar de completar». Ese permiso para decir "no sé" es una de las formas más simples de reducir respuestas inventadas.

Ancla la respuesta en material de referencia y limita al modelo a usarlo.

Pegar el documento o los datos dentro del prompt no alcanza; el salto de calidad viene de instruir «responde únicamente con la información de arriba y cita la parte que uses». Un detalle técnico que casi nadie aprovecha: en contextos largos, los modelos prestan más atención al principio y al final que al medio, así que la instrucción clave y lo más importante conviene ubicarlos en los extremos, no en medio.

Usa ejemplos (few-shot), pero elígelos por cobertura, no por perfección.

Dos o tres ejemplos de lo que esperas mejoran mucho la consistencia en los modelos clásicos. El hallazgo contraintuitivo de la investigación es que importa más que los ejemplos cubran la variedad de casos —incluidos los difíciles y las excepciones— que el hecho de que cada etiqueta sea impecable. Un aviso: demasiados ejemplos hacen que el modelo copie patrones superficiales, y en los modelos de razonamiento suelen estorbar más que ayudar.

Encadena y hazlo iterar sobre su propia respuesta.

Para tareas complejas, dividir en prompts encadenados —donde la salida de uno alimenta al siguiente— supera a un único prompt gigante.

Y una técnica de alto retorno: pedirle al modelo que revise su propia respuesta contra los criterios que le diste y la corrija («revisa el borrador anterior, verifica que cumpla cada condición y reescríbelo si falla alguna»). Ese paso de autocrítica levanta la calidad sin que tengas que rehacer el prompt desde cero.

El cambio más importante: modelos de razonamiento vs modelos clásicos

Este es el punto que más resultados arruina hoy, y el que casi nadie ajusta bien. Conviven dos tipos de modelos, y cada uno pide un estilo de prompt casi opuesto.

Los modelos de razonamiento (la familia "o" de OpenAI, Claude con pensamiento extendido, Gemini en modo Deep Think, DeepSeek R1) ya razonan internamente antes de responder. Pedirles de forma explícita que "razonen paso a paso" no desbloquea nada: en el mejor caso desperdicia el presupuesto de razonamiento que ya tenían asignado. Con ellos conviene dar un objetivo claro y bien delimitado, ser conciso, evitar el few-shot que los encorseta y, cuando la herramienta lo permite, indicar cuánto esfuerzo de razonamiento aplicar. La regla práctica: empieza simple y agrega detalle solo si la respuesta se queda corta.

Los modelos clásicos o de chat (los de respuesta rápida) son lo contrario: se benefician del andamiaje. Ahí sí ayudan pedir el razonamiento explícito, los ejemplos few-shot y una estructura detallada. La regla acá es la inversa: empieza con estructura y ejemplos, y recorta si sobra.

Elegir mal el modelo también es un error: usar uno de razonamiento para redactar un mail rápido es lento y excesivo, y usar uno de chat para un problema lógico difícil baja la calidad.

📎 Para ver cómo esta habilidad se traduce en empleabilidad real y por qué el mercado ya la da por sentada, puedes leer esta nota sobre cómo trabajar con inteligencia artificial y cómo te prepara Henry para el mercado laboral.

Cómo cambia el prompt según la herramienta

El mismo prompt no rinde igual en todos los modelos. Cada uno tiene su "dialecto", y conocerlo hará que puedas escribir prompts efectivos.

Claude (Anthropic)

Responde especialmente bien a instrucciones explícitas y a la estructura con etiquetas tipo XML (por ejemplo, envolver los ejemplos o el contexto en etiquetas propias), que le ayudan a separar cada parte del prompt. Para tareas difíciles, su modo de pensamiento adaptativo decide cuánto razonar; conviene dejarlo trabajar en lugar de sobre-instruirlo.

ChatGPT (OpenAI)

Los modelos más nuevos funcionan como un sistema que enruta la petición al modelo adecuado según la dificultad. Por eso conviene un tono conversacional y directo, probar primero sin ejemplos (infiere muy bien la intención desde poco contexto) y no recargar de indicaciones de razonamiento las tareas complejas, porque puede perjudicar el resultado. En apps de producción, fijar una versión concreta del modelo evita sorpresas cuando cambia el comportamiento.

Gemini (Google)

Prefiere prompts más cortos y directos que Claude o ChatGPT. Su gran fortaleza es el contexto enorme que admite: puedes darle documentos largos completos, pero justamente por eso importa dónde ubicas la instrucción clave dentro de todo ese material. Además, brilla cuando el prompt combina texto con imágenes u otros formatos.

GitHub Copilot

Acá el "prompt" es, en buena parte, tu propio código. Copilot se guía por los archivos abiertos, los nombres de tus funciones y los comentarios: un comentario claro que describe la intención («función que valida un email y devuelve verdadero o falso») produce mejores sugerencias que un nombre vago. Para preguntas sobre todo el proyecto, su chat permite referirse al repositorio completo, y las instrucciones personalizadas fijan tu estilo de código.

DeepSeek

Su modelo de razonamiento (R1) es open source y muy fuerte en lógica y matemática a bajo costo. Se prompt-ea como cualquier modelo de razonamiento: prompts simples y directos, sin ejemplos ni indicaciones de razonamiento de más. Al plantear el problema con claridad y dejarlo razonar, entrega lo mejor de sí.

Dominar estas diferencias es lo que convierte la IA en una herramienta de trabajo real. Da el paso: aplica a las carreras de Henry y aprende a usarla en proyectos concretos. 💡

Errores que cometen incluso los usuarios avanzados

• Usar el mismo prompt en todas las herramientas: una instrucción que funciona en ChatGPT puede rendir distinto en Claude o Gemini; conviene probar antes de estandarizar.
• Sobre-instruir a un modelo que ya razona: recargarlo de indicaciones de razonamiento suele restar, no sumar.
• No dar material de referencia: sin contexto real, el modelo llena los huecos inventando, con confianza.
• Copiar prompts sin entenderlos: un prompt "viral" rara vez encaja con tu caso; el valor está en saber por qué funciona y adaptarlo.
• Elegir el modelo equivocado para la tarea: potencia de razonamiento para algo trivial, o un modelo rápido para un problema complejo, desperdician tiempo o calidad.

Aplica a Henry y conviértete en el experto en IA que las empresas necesitan. ⚡

En resumen

• Un buen prompt es una especificación: define la tarea, el contexto, el formato de salida y también lo que hay que evitar, no solo un "rol".
• Anclar la respuesta en material de referencia e indicarle al modelo que use solo eso es la forma más efectiva de frenar las respuestas inventadas.
• Los modelos de razonamiento piden lo opuesto que los clásicos: con los primeros, menos instrucciones y más objetivo; con los segundos, ejemplos y estructura.
• Cada herramienta tiene su dialecto: etiquetas en Claude, tono directo en ChatGPT, prompts cortos con mucho contexto en Gemini, código y comentarios en Copilot, prompts mínimos en DeepSeek.
• El mayor salto de nivel no es saber más técnicas, sino elegir la técnica y el modelo correctos para cada tarea.

Conclusión

Escribir buenos prompts dejó de ser un truco y se convirtió en una habilidad con capas: entender qué técnica pide cada tarea, saber que los modelos de razonamiento juegan con reglas distintas y conocer el dialecto de cada herramienta. Esa capacidad de trabajar con IA con criterio, y no de repetir fórmulas, es hoy una de las habilidades más valoradas en cualquier perfil tecnológico.

Si quieres desarrollar esta habilidad, aplica a Henry. Nuestras carreras integran el trabajo con IA, con mentores de la industria y acompañamiento hasta que consigas empleo. 🚀

Preguntas frecuentes

¿El prompt engineering sigue sirviendo si los modelos son cada vez mejores?

Sí, aunque cambió. Los modelos infieren mejor la intención, así que el andamiaje elaborado importa menos, pero las instrucciones claras y el buen contexto importan más que nunca. La habilidad ya no es memorizar trucos, sino elegir la técnica correcta para cada modelo y tarea.

¿Conviene pedirle a los modelos nuevos que "razonen paso a paso"?

En los modelos de razonamiento, no: ya razonan internamente antes de responder, así que pedírselo no agrega nada y puede desperdiciar el esfuerzo que ya tenían reservado. Esa técnica sigue siendo útil, en cambio, en los modelos clásicos de respuesta rápida.

¿Un mismo prompt funciona igual en Claude, ChatGPT y Gemini?

No necesariamente. Comparten principios, pero cada uno tiene preferencias: Claude responde bien a etiquetas y a instrucciones explícitas, Gemini prefiere prompts más cortos, y ChatGPT infiere bien desde poco contexto. Conviene probar el mismo pedido en la herramienta que uses antes de darlo por definitivo.

¿Necesito saber programar para aprender prompt engineering?

No. Es una habilidad transversal que sirve tanto para escribir y analizar como para programar o automatizar procesos. Escribir buenos prompts se apoya en pensar con claridad y estructurar bien lo que pides, más que en escribir código.

Cada vez que alguien compara Make y n8n termina en la misma pregunta: ¿cuál es mejor? Y esa es, justamente, la pregunta equivocada. Las dos son excelentes, las dos conectan tus aplicaciones y las dos te ahorran horas de trabajo repetitivo. La diferencia real no está en cuál gana una tabla de features, sino en cuál encaja mejor con lo que tú quieres hacer. En esta nota te explicamos cómo tomar esa decisión según tu objetivo, tu presupuesto y hasta dónde quieras llegar con la IA.

Make y n8n son plataformas de automatización visual que conectan tus aplicaciones para que ejecuten tareas solas, sin programar: la diferencia no está en lo que hacen, sino en para quién y para qué escala está pensada cada una.

Make nació como una herramienta pulida y lista para usar, orientada a perfiles de negocio que quieren resolver rápido y sin código. n8n nació como una plataforma open source y auto-hospedable, orientada a quien quiere control total sobre su automatización. Todo lo demás se desprende de ahí.

📎 Si todavía no armaste tu primer flujo y quieres ver por dentro cómo funciona una automatización, empieza por esta guía sobre cómo crear tu primer workflow con IA.

Por eso, en vez de buscar un ganador absoluto, conviene mirar las dos dimensiones que de verdad deciden: cómo te cobra cada una y qué tan lejos te deja llegar con la inteligencia artificial. Con esas dos claras, la elección se vuelve obvia para tu caso.

Si quieres que elegir y dominar estas herramientas se convierta en tu profesión, la Carrera de AI Automation de Henry te enseña a orquestar Make, n8n y APIs de IA con proyectos reales. 🚀

La diferencia que de verdad decide: cómo te cobran

Acá está el punto que cambia la ecuación y que casi ninguna comparación explica bien, porque el modelo de precios de cada plataforma es distinto en su lógica, no solo en el número.

• Make cobra por operación: cada paso de tu flujo que procesa datos consume un crédito. Un flujo de 5 pasos que corre 1.000 veces al mes consume unas 5.000 operaciones; si sumas pasos o corridas, el costo escala rápido. La ventaja es que no tienes que pensar en servidores y, para volúmenes bajos, suele ser más barato de arrancar.
• n8n cobra por ejecución: cuenta cada vez que corre el flujo completo, sin importar cuántos pasos tenga. El mismo flujo cuenta como 1.000 ejecuciones, tenga los pasos que tenga; y si lo auto-hospedas, no pagas por volumen, solo el costo de tu servidor (unos pocos dólares al mes). La contra del auto-hospedaje es que alguien tiene que mantener la instalación, las actualizaciones y las copias de seguridad.

En resumen de costos: para volúmenes bajos y flujos simples, Make arranca más fácil; para alto volumen —y sobre todo para flujos con muchos pasos de IA— el modelo por ejecución de n8n se vuelve mucho más previsible y económico.

La IA y los agentes: dónde está cada una

La segunda dimensión es la que más cambió en el último tiempo, y donde las dos plataformas están en puntos distintos. Conviene separar dos niveles: sumar un paso de IA a un flujo y construir un agente autónomo.

Para un paso de IA simple —mandar un texto al modelo y recibir una respuesta para resumir, clasificar o redactar—, las dos sirven perfectamente. La diferencia aparece con los agentes autónomos: sistemas que razonan, eligen qué herramienta usar, recuerdan el contexto y repiten el ciclo hasta cumplir un objetivo.

• Make facilita la IA sin código con conectores listos y un asistente que arma escenarios a partir de lenguaje natural; es lo más accesible para empezar. Para un agente autónomo completo, en cambio, hoy te exige armar buena parte de esa lógica a mano.
• n8n resuelve los agentes de forma nativa: su nodo de agente y su integración con LangChain traen memoria, RAG y elección de herramientas, y permite sumar código para la lógica que falte. A mediados de 2026, es la opción más sólida para construir agentes.

Aprender a construir estos agentes es de lo que más valora hoy el mercado de automatización. Da el paso: aplica a la Carrera de AI Automation de Henry y constrúyelos sobre proyectos reales. 💡

Cuál elegir según tu perfil

Con esas dos dimensiones claras, la decisión se ordena sola según quién eres y qué buscas.

Make te conviene si…

• vienes de negocio, marketing u operaciones y quieres lanzar hoy sin tocar nada técnico;
• automatizas tu propio trabajo o el de un equipo pequeño, con un volumen moderado;
• valoras una plataforma administrada, con soporte y sin servidores que mantener;
• tu uso de IA son pasos puntuales (resumir, clasificar, redactar), no agentes complejos.

n8n te conviene si…

• tienes perfil técnico (o quieres construirlo) y buscas control total sobre la lógica y los datos;
• manejas un volumen alto en el que el costo por pasos se dispara;
• quieres auto-hospedar por costo, privacidad o cumplimiento normativo;
• tu objetivo es construir agentes de IA de verdad, o hacer de la automatización tu profesión.

También puedes usar ambas y elegir según el proyecto; empezar por una no te cierra la puerta de la otra.

Qué esperan las empresas y los clientes

Si tu objetivo no es solo automatizar tus propias tareas, sino trabajar de esto, conviene mirar la decisión desde el mercado.

• Make es enorme en equipos de negocio, marketing y operaciones que necesitan resolver rápido y sin código; es una herramienta muy presente en roles internos de eficiencia operativa.
• n8n aparece más en contextos profesionales y corporativos que piden control, auto-hospedaje y agentes: no es casualidad que grandes empresas migren flujos críticos a n8n por su modelo de costo y por poder correrlo en sus propios servidores.

Un especialista en automatización no se casa con una herramienta, sino que elige la correcta para cada problema. Saber cuándo conviene la simpleza de Make y cuándo la potencia de n8n es, en sí mismo, una habilidad que el mercado paga.

Un AI Automation Specialist domina las dos y sabe cuál usar en cada caso. Aplica a la Carrera de AI Automation de Henry y aprende a orquestar Make, n8n y APIs de IA sobre proyectos reales. ⚡

En resumen

• La pregunta útil no es cuál es mejor, sino cuál te conviene según tu objetivo, tu volumen y tu perfil.
• El modelo de costo es la diferencia clave: Make cobra por paso (operación) y n8n por ejecución, además de poder auto-hospedarse a costo fijo; a mayor volumen, n8n suele salir más barato.
• Para IA, depende de la ambición: pasos simples de IA los hacen las dos; para agentes autónomos, n8n hoy es más nativo.Make brilla en simpleza y rapidez para perfiles de negocio; n8n brilla en control, escala y agentes para perfiles técnicos.
• No es una decisión definitiva: muchos profesionales usan las dos y eligen según el proyecto.

Conclusión

Elegir entre Make y n8n no se trata de coronar una plataforma, sino de entender qué quieres lograr y desde dónde partes. Si buscas automatizar tu trabajo rápido, sin infraestructura y con una curva suave, Make te lleva ahí en un día. Si buscas control total, escalar sin que el costo se dispare y construir agentes de IA de verdad, n8n te da ese techo más alto. Y si tu meta es dedicarte a esto, la respuesta deja de ser "una u otra": es aprender a leer cada problema y elegir la herramienta que mejor lo resuelve.

Si quieres convertir la automatización en tu profesión, la Carrera de AI Automation de Henry te enseña a dominar Make, n8n, Airtable y las APIs de IA para construir automatizaciones y agentes que las empresas necesitan, con mentores de la industria y acompañamiento hasta conseguir empleo. Aplica y empieza a diseñar sistemas que trabajen por ti. 🚀

Preguntas frecuentes

¿Make o n8n es más barato?

Depende del volumen. Para pocos flujos y bajo volumen, Make suele ser más económico de arrancar y no requiere mantener servidores. A medida que crecen los pasos y las corridas —sobre todo con IA—, el modelo por ejecución de n8n, y en especial su versión auto-hospedada, tiende a salir bastante más barato.

¿Cuál es mejor para construir agentes de IA?

Para pasos de IA simples, las dos funcionan bien. Para agentes autónomos que razonan, usan herramientas y recuerdan contexto, n8n hoy es más nativo gracias a su nodo de agente y su integración con LangChain. Make es más accesible para automatizaciones con IA sin código, pero para agentes complejos exige armar más lógica a mano.

¿Necesito saber programar para usar n8n?

No para empezar: n8n es low-code y se trabaja arrastrando nodos. La diferencia es que, cuando necesitas lógica avanzada, te permite escribir código, mientras que Make apunta a un enfoque más puramente no-code. Por eso n8n se siente más cómodo para perfiles técnicos y Make para perfiles de negocio.

¿Puedo usar Make y n8n a la vez?

Sí, y es lo que hacen muchos profesionales. Se puede elegir una para los flujos simples y de negocio, y la otra para las automatizaciones complejas o con agentes; incluso pueden conectarse entre sí. Dominar ambas es, de hecho, parte del perfil de un especialista en automatización.

Las dos carreras suenan parecidas, las dos prometen trabajar con inteligencia artificial y las dos apuntan a un mercado que contrata. Pero eligen caminos distintos: una construye el producto completo que usa la IA, la otra construye los sistemas de IA que van dentro del producto.

En esta nota te explicamos qué hace realmente cada perfil, en qué se diferencian su día a día y cuál te conviene elegir según tu punto de partida.

Qué hace cada perfil

Un desarrollador Full Stack AI construye aplicaciones web completas —interfaz, backend, base de datos— e integra en ellas capacidades de inteligencia artificial, además de usar IA para programar más rápido. Su producto final es la aplicación: lo que el usuario ve y usa.

Un AI Engineer construye los sistemas de inteligencia artificial que viven dentro de esos productos: conecta modelos ya existentes con datos y flujos de trabajo, diseña agentes y sistemas de recuperación de información, y se asegura de que funcionen de forma confiable en producción. Su producto final es el sistema inteligente, no la interfaz.

La diferencia se ve mejor con un ejemplo: Imagina una empresa que quiere un asistente que responda preguntas sobre sus manuales internos. El AI Engineer diseña el sistema que busca en esos documentos y genera la respuesta correcta; el Full Stack construye la aplicación donde el usuario escribe la pregunta, ve la respuesta, guarda su historial y gestiona su cuenta. En un equipo real, ambos trabajan sobre el mismo producto desde ángulos distintos.

Si todavía estás explorando, conocer las carreras de Henry y sus planes de estudio te va a dar el detalle concreto de qué se aprende en cada una. 🚀

Las diferencias que de verdad importan

Más allá de la definición, hay cuatro dimensiones donde los caminos se separan y que conviene mirar antes de decidir.

El día a día

Un Full Stack pasa el día construyendo interfaces, endpoints, modelos de datos y despliegues: el trabajo es visible y el resultado se toca. Un AI Engineer pasa el día preparando datos, diseñando y ajustando prompts, evaluando si un sistema responde bien o inventa información, y resolviendo por qué algo que funcionaba en desarrollo falla en producción. Hay más incertidumbre y menos resultado visual.

El stack

El Full Stack vive en JavaScript y TypeScript, con React, Node.js, bases de datos y servicios en la nube. El AI Engineer vive en Python, con frameworks de orquestación como LangChain y LangGraph, bases de datos vectoriales, APIs de modelos comerciales y Docker para llevar todo a producción.

El punto de entrada al mercado

Aquí está la diferencia más práctica y la que menos se dice. Los roles junior de desarrollo web son más numerosos y su camino de entrada está más recorrido. En AI Engineering, en cambio, buena parte de las ofertas de Argentina y LATAM piden experiencia previa en Python y algún proyecto de IA ya funcionando: los roles verdaderamente junior existen, pero son más escasos y sus procesos de selección son más exigentes.

El inglés

Pesa en los dos casos, pero de forma distinta: en Full Stack hay un mercado local que a veces no lo exige, mientras que en AI Engineering las mejores oportunidades son remotas e internacionales, con inglés técnico como requisito real.

Si quieres conocer en detalle cómo es el trabajo real de este segundo perfil, te recomendamos leer esta nota sobre las skills que piden las empresas para AI Engineering.📎

Cuál elegir según tu punto de partida

La pregunta correcta no es cuál carrera es mejor, sino cuál se ajusta mejor a ti. Estas señales suelen ser buenas guías:

🔸 Full Stack AI te conviene si te motiva ver el producto terminado, disfrutas del trabajo visual y de la lógica de una aplicación, empiezas desde cero sin base técnica previa, o quieres el camino con más puertas de entrada junior y un mercado local que también contrata.

🔸 AI Engineering te conviene si ya tienes base de programación (sobre todo en Python), te atrae el problema abstracto más que la interfaz, toleras bien la incertidumbre de un sistema que no siempre responde igual, y tu objetivo es el mercado remoto internacional con inglés técnico sólido.

🔸 Si dudas y empiezas desde cero, el orden natural suele ser Full Stack primero: da la base de programación, APIs, bases de datos y despliegue sobre la que después se construye cualquier perfil de IA. Es un camino, no una regla.

Una aclaración honesta, porque conviene decirla: ninguna de las dos es "la carrera de IA" y la otra no. En 2026, la inteligencia artificial atraviesa los dos perfiles. Lo que cambia es el rol que cumple: en Full Stack, la IA es una capacidad que se integra al producto y una herramienta que acelera el desarrollo; en AI Engineering, el sistema de IA es el producto.

Lo que comparten (y por qué la decisión no es para siempre)

Antes de agonizar sobre la elección, vale saber que los dos caminos comparten más de lo que separa. Ambos exigen dominar un lenguaje de programación de verdad, trabajar con Git, entender cómo funcionan las APIs, saber consultar datos con SQL y —sobre todo— construir un portfolio con proyectos reales desplegados, que es lo que hoy define un proceso de selección en la región.

Esa base común es la razón por la que la decisión no es irreversible. Un Full Stack con experiencia que aprende Python y frameworks de orquestación tiene un camino natural hacia AI Engineering, y de hecho es una de las transiciones más frecuentes del mercado. Elegir el primer paso importa; encadenarse a él, no.

Si tu objetivo es construir los sistemas de IA que van dentro de los productos, la Carrera de AI Engineering de Henry te forma con proyectos reales de agentes, RAG y aplicaciones de IA, junto a mentores que trabajan en la industria. ⚡

En resumen

• El Full Stack AI construye el producto completo e integra IA en él; el AI Engineer construye el sistema de IA que vive dentro de ese producto.
• El stack difiere: JavaScript/TypeScript, React y Node.js para Full Stack; Python, LangChain/LangGraph y bases de datos vectoriales para AI Engineering.
• El punto de entrada no es igual: los roles junior de desarrollo web son más numerosos, mientras que AI Engineering suele pedir base previa en Python y proyectos de IA funcionando.
• Elige según tu perfil: producto terminado y trabajo visual apunta a Full Stack; problema abstracto, datos y sistemas apunta a AI Engineering.
• La base es común —programación, Git, APIs, SQL y portfolio—, así que la decisión no es para siempre: migrar de Full Stack a AI Engineering es una transición frecuente.

Conclusión

Full Stack AI y AI Engineering no compiten entre sí: resuelven partes distintas del mismo producto y, en muchos equipos, trabajan codo a codo. La elección real no pasa por cuál está más de moda ni cuál paga mejor en un ranking, sino por qué tipo de problema tienes ganas de resolver y desde dónde estás partiendo hoy.

Si quieres tomar esa decisión con información concreta, puedes revisar los planes de estudio, los proyectos y las salidas laborales de las carreras de Henry.

Aplica y empieza por el camino que mejor se ajuste a tu perfil. 🚀

Preguntas frecuentes

¿Cuál es la diferencia principal entre Full Stack AI y AI Engineering?

El Full Stack construye la aplicación completa —interfaz, backend y base de datos— e integra capacidades de IA en ella. El AI Engineer construye el sistema de inteligencia artificial que funciona dentro de esa aplicación: conecta modelos con datos, diseña agentes y se ocupa de que el sistema sea confiable en producción. Uno se enfoca en el producto; el otro, en el sistema inteligente que lo potencia.

¿Cuál conviene si empiezo desde cero, sin saber programar?

Full Stack suele ser el camino de entrada más transitado: parte de cero, tiene más roles junior disponibles y construye la base de programación, APIs, bases de datos y despliegue sobre la que se apoya cualquier perfil de IA. No es una regla fija, pero sí el orden natural para quien no tiene experiencia previa.

¿Se puede pasar de Full Stack a AI Engineering más adelante?

Sí, y es una de las transiciones más frecuentes del mercado. Comparten la base —programación, Git, APIs, SQL y portfolio—, así que un desarrollador con experiencia que suma Python, frameworks de orquestación y proyectos de IA tiene un camino natural hacia ese rol.

¿Cuál de los dos perfiles tiene más demanda en Argentina y LATAM?

En volumen, el desarrollo web tiene más ofertas y más puertas de entrada junior. AI Engineering es un mercado en crecimiento con menos posiciones junior y procesos más exigentes, pero con mucha demanda remota internacional. Más que el volumen, lo que conviene mirar es cuál se ajusta a tu perfil: en ambos casos, el portfolio y el inglés técnico definen el acceso a las mejores oportunidades.

Un chatbot responde una pregunta y se detiene. Un agente de IA, en cambio, puede razonar, decidir usar una herramienta, ver el resultado y seguir hasta resolver una tarea completa. Ese salto —de responder a actuar— es una de las habilidades más buscadas hoy en AI Engineering, y LangGraph es uno de los frameworks que lo hace posible. En esta nota te explicamos, paso a paso, cómo crear tu primer agente de IA con LangGraph en Python, desde qué es un agente hasta cómo ejecutarlo.

Qué es un agente de IA y en qué se diferencia de un chatbot

Un agente de IA es un sistema que usa un modelo de lenguaje como "cerebro" para razonar, decidir qué herramienta usar y ejecutar acciones en varios pasos, hasta cumplir un objetivo, en lugar de limitarse a responder una sola vez. La diferencia con un chatbot común está justamente ahí: el chatbot genera una respuesta y termina; el agente entra en un ciclo de "pensar, actuar y volver a pensar" hasta que la tarea está lista.

Ese patrón tiene nombre: se lo conoce como ReAct (Reasoning and Acting). El modelo razona sobre qué hacer, llama a una herramienta —buscar en la web, consultar una base de datos, hacer un cálculo—, lee el resultado y decide el siguiente paso. Repite ese bucle las veces que haga falta, y recién cuando no necesita más herramientas entrega la respuesta final.

📎 Si quieres una base más general sobre qué es un agente, sus componentes (modelo, memoria y herramientas) y cómo se piensa desde cero, esta guía sobre cómo crear un agente de IA desde cero lo desarrolla en detalle.

Construir estos sistemas es el corazón del trabajo de un AI Engineer. La Carrera de AI Engineering de Henry te enseña a diseñar agentes, sistemas RAG y aplicaciones de IA con proyectos reales y mentores de la industria. 🚀

Qué es LangGraph y por qué se usa para construir agentes

LangGraph es un framework open source, creado por el equipo de LangChain, para construir agentes modelándolos como un grafo. En lugar de escribir una secuencia lineal, defines un estado compartido (la información que viaja entre pasos, normalmente el historial de mensajes), unos nodos que hacen el trabajo y unas aristas que deciden el flujo, incluidos los ciclos en los que el agente piensa, actúa y vuelve a pensar. Esa capacidad de manejar bucles y ramificaciones es lo que lo hace ideal para agentes, algo que las cadenas lineales no resuelven bien.

LangGraph ofrece dos niveles de trabajo, y conviene conocerlos desde el principio. El camino rápido es usar una función prebuilt que arma el agente por ti; el camino manual es construir el grafo nodo por nodo, cuando necesitas control fino sobre la lógica. La recomendación práctica para tu primer agente es empezar por el camino rápido y bajar al manual solo cuando el proyecto lo pida. Más adelante, al armar el agente, veremos en la práctica cómo se ve cada camino.

Si quieres dominar este tipo de herramientas con acompañamiento profesional, la Carrera de AI Engineering de Henry está diseñada para que aprendas el stack real del rol —Python, LangChain, LangGraph y APIs de modelos— construyendo proyectos. 💡

Cómo crear tu primer agente de IA con LangGraph, paso a paso

1️⃣ Prepara el entorno y tu clave de modelo

Instala las librerías necesarias en tu entorno de Python: el paquete langgraph y el conector del modelo que vayas a usar, por ejemplo langchain-openai (con pip install langgraph langchain-openai). Necesitas también una clave de API del proveedor del modelo —OpenAI, Anthropic o el que prefieras—, que se carga como variable de entorno (por ejemplo, OPENAI_API_KEY) para no escribirla en el código.

Sobre el costo: recorrer un tutorial como este suele costar menos de dos dólares en llamadas a la API, y cada consulta con un par de herramientas ronda unos centavos. Si prefieres evitar el gasto en la nube, LangGraph también funciona con modelos locales a través de Ollama, aunque para eso conviene tener una máquina con buena memoria.

2️⃣ Define las herramientas que podrá usar el agente

Las herramientas (tools) son, simplemente, funciones de Python que el agente puede invocar. Se marcan con el decorador @tool de langchain_core.tools, y el detalle clave es el docstring: esa descripción es lo que lee el modelo para decidir cuándo usar cada herramienta, así que tiene que ser clara. Una función que busca el clima, que consulta una base de datos o que hace un cálculo son ejemplos típicos de tu primer agente.

3️⃣ Arma el agente

El camino rápido es la función create_react_agent del módulo langgraph.prebuilt: le pasas el modelo, la lista de herramientas y un prompt de sistema, y ella construye por dentro todo el ciclo de razonamiento y acción. Con esas tres líneas conceptuales ya tienes un agente funcional.

Por debajo, ese atajo arma un StateGraph: un estado con la lista de mensajes, un nodo que llama al modelo, un nodo que ejecuta las herramientas (ToolNode) y una arista condicional que, según si el modelo pidió o no una herramienta, vuelve al modelo o termina. Compilar ese grafo (compile()) te da el agente. Empezar por create_react_agent te evita ese detalle hasta que necesites personalizarlo. Un apunte de actualidad: el ecosistema de LangChain está unificando este atajo en un helper más nuevo llamado create_agent; si te cruzas ese nombre, es la evolución de la misma idea.

4️⃣ Ejecútalo y observa su razonamiento

Para correr el agente, le pasas un mensaje del usuario con .invoke({"messages": [...]}). Vas a ver el bucle en acción: el modelo razona, decide llamar a una herramienta, recibe el resultado y decide el siguiente paso hasta responder. Para entender qué "piensa" en cada paso y depurar cuando algo falla, conviene conectar LangSmith, la herramienta de observabilidad del mismo ecosistema.

Armar agentes como este, cada vez más complejos, es parte del día a día de un AI Engineer. En la Carrera de AI Engineering de Henry los construyes sobre proyectos reales, con feedback de mentores que trabajan en la industria. ⚡

Qué hace realmente potente a un agente (y qué cuidar)

Un primer agente funciona con lo anterior, pero pasar de la demo a algo confiable exige atender algunos puntos:

• Docstrings claros en las herramientas: el agente decide qué herramienta usar leyendo su descripción, así que una descripción vaga produce decisiones malas.
• Memoria entre pasos: para conversaciones de varios turnos, se agrega checkpointing, que guarda el estado del grafo y le permite recordar el contexto.
• Supervisión humana en acciones sensibles: LangGraph permite pausar el flujo para que una persona apruebe antes de ejecutar algo delicado (human-in-the-loop).
• Costo y latencia: cada paso del ciclo es una llamada al modelo; un agente que itera varias veces cuesta y tarda más, así que conviene elegir bien el modelo y acotar la cantidad de pasos.

Dominar estas decisiones es lo que separa a quien probó un agente una vez de quien construye sistemas que funcionan en producción. La Carrera de AI Engineering de Henry está pensada para llegar a ese nivel. 🚀

En resumen

• Un agente de IA usa un modelo como cerebro para razonar, usar herramientas y actuar en varios pasos, a diferencia de un chatbot que responde una sola vez.
• LangGraph modela el agente como un grafo con estado, nodos y aristas, lo que le permite manejar los ciclos de "pensar y actuar" propios de un agente.
• El camino rápido es create_react_agent; por debajo arma un StateGraph con un nodo de razonamiento, un nodo de herramientas y una arista condicional.
• Los cuatro pasos son: preparar el entorno, definir las herramientas, armar el agente y ejecutarlo observando su razonamiento.
• En un agente real importan la memoria, la supervisión humana, el costo por iteración y la calidad de las descripciones de cada herramienta.

Conclusión

Crear tu primer agente de IA con LangGraph no exige inventar nada desde cero: exige entender el ciclo de razonar y actuar, definir buenas herramientas y dejar que el framework orqueste el flujo. Una vez que ese primer agente funciona, el mismo patrón escala hacia sistemas mucho más ambiciosos: agentes con memoria, con varias herramientas, con supervisión humana y desplegados en producción. Esa capacidad de pasar de la idea a un sistema que decide y actúa es, hoy, uno de los diferenciales más valorados en un perfil de AI Engineering.

Si quieres pasar de tu primer agente a construir sistemas de IA completos, la Carrera de AI Engineering de Henry te forma con proyectos reales de agentes, RAG y aplicaciones de IA, con mentores de la industria y un equipo de career coaches que te acompaña hasta conseguir empleo. Aplica y empieza a construir agentes que resuelven tareas de verdad. 🚀

Preguntas frecuentes

¿Necesito saber mucho de machine learning para crear un agente con LangGraph?

No. Crear un agente es, sobre todo, programación en Python y lógica de orquestación: defines herramientas, conectas un modelo y armas el flujo. No entrenas modelos; usas uno que ya existe a través de su API. Con bases sólidas de Python es suficiente para empezar.

¿Cuál es la diferencia entre LangChain y LangGraph?

LangChain aporta los bloques de construcción (conexión a modelos, herramientas, prompts), mientras que LangGraph se ocupa de la orquestación: cómo esos bloques se conectan, forman ciclos y mantienen un estado. Para un agente que necesita razonar en varios pasos, LangGraph es la pieza que maneja ese flujo.

¿Conviene usar create_react_agent o construir el grafo a mano?

Para tu primer agente y para la mayoría de los casos estándar, create_react_agent (o el nuevo create_agent de LangChain) es el camino recomendado, porque arma el ciclo por ti. Construir el StateGraph a mano tiene sentido cuando necesitas control fino: ejecución en paralelo, ramificaciones complejas o lógica de reintento personalizada.

¿Cuánto cuesta ejecutar un agente de IA?

Depende del modelo y de cuántos pasos dé el agente, ya que cada paso es una llamada a la API. Un agente simple de práctica cuesta apenas centavos por consulta. Para reducir el gasto conviene elegir un modelo acorde a la tarea, limitar la cantidad de iteraciones o usar un modelo local con herramientas como Ollama.

Sumarle a una aplicación web una función inteligente —un asistente, un resumidor, un clasificador— dejó de ser terreno exclusivo de especialistas en IA. Con la API de OpenAI, cualquier desarrollador Full Stack puede hacerlo. El desafío real no es "llamar al modelo": es hacerlo con la arquitectura correcta, sin exponer tu clave y sin romper la experiencia de usuario. En esta nota te explicamos cómo integrar la API de OpenAI en una app con React y Node.js, paso a paso y con código listo para usar.

Qué significa integrar la API de OpenAI en una app web

Integrar la API de OpenAI en una app significa sumarle a tu producto una capa de inteligencia: tu frontend captura lo que el usuario pide, tu backend lo envía al modelo a través de la API y devuelve la respuesta ya procesada a la interfaz. No entrenas ningún modelo ni corres nada pesado en tu servidor; solo orquestas una conversación entre tu aplicación y un modelo que ya existe.

Esto encaja de forma natural en el stack de un Full Stack moderno. React se ocupa de la interfaz, Node.js del backend y la API de OpenAI aporta el "cerebro". Saber conectar esas tres piezas es hoy una de las habilidades que más distingue a un desarrollador Full Stack en 2026, porque convierte una app común en un producto que entiende lenguaje natural.

Si quieres construir este tipo de aplicaciones de punta a punta, la Carrera de Full Stack de Henry enseña React, Node.js, TypeScript y la integración de APIs de IA con proyectos reales desde las primeras semanas. 🚀

La regla de oro: la clave de API nunca va en el frontend

Antes del primer paso, una decisión de arquitectura que separa una integración amateur de una profesional: tu clave de API de OpenAI nunca debe estar en el código de React. Todo lo que vive en el frontend es visible para cualquiera que abra las herramientas del navegador, así que una clave ahí equivale a regalarla, con el costo (y el riesgo) que eso implica.

La solución es simple y es el patrón estándar: el frontend en React no habla directamente con OpenAI, sino con tu propio backend en Node.js, que guarda la clave de forma segura y actúa como intermediario. El navegador llama a tu servidor, tu servidor llama a OpenAI, y la respuesta vuelve por el mismo camino. Con ese esquema en mente, vamos al paso a paso.

Cómo integrar la API de OpenAI con React y Node.js, paso a paso

1️⃣ Prepara el proyecto y tu clave de OpenAI

En la carpeta de tu backend, inicia el proyecto con npm init -y e instala en una sola línea las dependencias que vas a usar —Express como servidor, cors para permitir que React lo llame, dotenv para leer variables de entorno y la librería oficial de OpenAI— con npm install express cors dotenv openai.

Para obtener la clave, entra a tu cuenta en platform.openai.com, sección de API keys, crea una clave nueva y cópiala en ese momento, porque por seguridad se muestra una sola vez. Ten en cuenta que el uso de la API se cobra por consumo y es independiente de una suscripción a ChatGPT, así que la cuenta necesita saldo o un método de pago cargado.

Guarda esa clave en un archivo .env con el formato OPENAI_API_KEY=tu_clave, y agrega .env y node_modules a tu .gitignore para no subirlos nunca a GitHub.

2️⃣ Crea el backend con Node y Express

El backend es un servidor de Express con un solo endpoint —por ejemplo POST /api/chat— que hace de intermediario. Al arrancar, importas Express, cors, dotenv y la librería de OpenAI, creas la app con express() y habilitas cors() y express.json() para poder recibir desde React peticiones en formato JSON.

Después instancias el cliente con new OpenAI(), que toma la clave desde OPENAI_API_KEY de forma automática. Dentro del endpoint tomas el prompt que llega en el cuerpo de la petición, se lo pasas al modelo con client.responses.create({ model, input }) —usando la Responses API, la interfaz recomendada hoy— y devuelves el texto del resultado, que viene en response.output_text. Envuelve esa llamada en un try/catch para responder con un error claro si algo falla, y por último pones el servidor a escuchar en un puerto (por ejemplo, el 3001).

Un detalle: elige el modelo según tu caso. Para tareas simples o de alto volumen conviene una variante más liviana y económica (como GPT-5.4 mini); la lista actualizada está en la página de modelos de OpenAI.

3️⃣ Conecta el frontend en React

En el componente de React manejas tres estados con useState: el texto que escribe el usuario, la respuesta del modelo y un booleano de "cargando". Cuando la persona envía el formulario, una función asíncrona hace un fetch a tu backend (no a OpenAI) con método POST, la cabecera Content-Type: application/json y el prompt en el cuerpo de la petición. Mientras espera, activa el estado de "cargando" para que la interfaz no parezca congelada; cuando llega la respuesta, la guarda en el estado y la muestra en pantalla; y si algo falla, muestra un mensaje de error. La clave del frontend es esa: siempre habla con tu servidor, nunca directamente con la API de OpenAI.

4️⃣ Prueba el flujo completo

Levanta el backend (node server.js) y la app de React, escribe algo en el campo de texto y envíalo. Si todo está conectado, verás la respuesta del modelo en pantalla en unos segundos. Si algo falla, revisa la consola del navegador y la del servidor: casi siempre el problema es la clave mal cargada o el backend apagado.

Construir integraciones como esta, cada vez más completas, es exactamente lo que se practica en la Carrera de Full Stack de Henry, con mentores que trabajan en la industria y proyectos que terminan en tu portfolio. 💡

Buenas prácticas al llevar la integración a producción

El flujo anterior funciona, pero un producto real necesita algunos cuidados extra:

• Maneja la latencia de forma asíncrona: una respuesta del modelo puede tardar varios segundos; el estado de "cargando" evita que la interfaz parezca congelada.
• Controla el costo y el modelo: cada llamada consume tokens; elegir un modelo más liviano para tareas simples reduce mucho el gasto.
• Valida la entrada del usuario: nunca confíes en el texto que llega del frontend; límpialo y ponle un límite de longitud antes de enviarlo al modelo.
• Aprovecha los reintentos del SDK: la librería de OpenAI reintenta sola los errores de red y de límite de uso, pero conviene registrar los fallos para detectarlos a tiempo.

📎Si quieres profundizar en estas decisiones —asincronía, reintentos y manejo de latencia—, esta guía sobre cómo conectar una API de OpenAI en tu código lo desarrolla en detalle.

Dominar estos detalles es lo que distingue a quien "usó la API una vez" de quien construye productos con IA de forma profesional. La Carrera de Full Stack de Henry está diseñada para que llegues a ese nivel. ⚡

En resumen

• Integrar la API de OpenAI suma una capa de inteligencia a tu app: el frontend pide, el backend orquesta y el modelo responde.
• La clave de API nunca va en el frontend: React llama a tu backend en Node.js, que guarda la clave y actúa como intermediario seguro.
• El flujo tiene cuatro pasos: preparar el proyecto y la clave, crear el backend con Express, conectar el frontend en React y probar todo junto.
• La Responses API (client.responses.create) es la interfaz recomendada hoy, y conviene elegir el modelo según el costo y la tarea.
• En producción importan la latencia asíncrona, la validación de la entrada, el control de costos y el registro de errores.

Conclusión

Integrar la API de OpenAI en una app con React y Node.js no requiere saber de machine learning: requiere entender cómo se comunican el frontend, el backend y el modelo, y respetar una regla de seguridad básica que muchos pasan por alto. Una vez que armas este flujo, el patrón se repite para casi cualquier funcionalidad inteligente que quieras sumar a un producto: un asistente, un buscador semántico, un generador de contenido. Esa capacidad de conectar las piezas es, hoy, uno de los mayores diferenciales de un perfil Full Stack.

Si quieres pasar de integrar una API a construir productos completos con IA, la Carrera de Full Stack de Henry te enseña el stack entero —React, Node.js, TypeScript, bases de datos y despliegue en la nube— con proyectos reales y un equipo de career coaches que te acompaña hasta conseguir empleo. Aplica y empieza a construir aplicaciones inteligentes de punta a punta. 🚀

Preguntas frecuentes

¿Necesito saber de machine learning para integrar la API de OpenAI?

No. Integrar la API es una tarea de desarrollo de software: enviar una petición, esperar la respuesta y procesarla. No entrenas ni ajustas modelos; usas uno que ya existe a través de la API. Con bases de JavaScript, React y Node.js es suficiente para empezar.

¿Por qué no puedo llamar a la API de OpenAI directamente desde React?

Porque tendrías que poner tu clave en el frontend, y todo lo que vive en el navegador es visible para el usuario. Cualquiera podría copiarla y usar tu cuenta. Por eso la llamada se hace desde el backend en Node.js, que guarda la clave de forma segura y actúa como intermediario.

¿Qué modelo de OpenAI conviene usar?

Depende del caso. Los modelos más potentes (como GPT-5.5) dan mejores respuestas en tareas complejas; las variantes más livianas (como GPT-5.4 mini) son más rápidas y económicas para tareas simples o de alto volumen. La lista vigente está en la página de modelos de OpenAI.

¿Cuánto cuesta usar la API de OpenAI en mi app?

La API se cobra por consumo, según la cantidad de texto que entra y sale del modelo, y es un costo aparte de cualquier suscripción a ChatGPT. Para controlar el gasto conviene elegir un modelo acorde a la tarea y limitar la longitud de las peticiones.

Armar el mismo reporte todas las semanas —copiar datos de una planilla, resumirlos, darles formato y enviarlos por correo— es de esas tareas que consumen horas y no dejan nada nuevo aprendido. La buena noticia es que se puede delegar por completo a un flujo automático que corre solo. En esta nota te contamos cómo construir, paso a paso, una automatización que toma tus datos, redacta el reporte con ChatGPT y lo entrega sin que toques nada, usando n8n como orquestador.

Qué es n8n y por qué combinarlo con ChatGPT para tus reportes

n8n es una plataforma de automatización visual que conecta aplicaciones y servicios mediante nodos, sin necesidad de escribir código, para que las tareas repetitivas se ejecuten solas. En lugar de programar, arrastras bloques en un lienzo y los enlazas para definir qué pasa, en qué orden y con qué datos. Cada flujo empieza con un disparador —un horario, un formulario, un webhook— y encadena acciones hasta un resultado final.

¿Dónde entra ChatGPT? n8n mueve y conecta datos muy bien, pero no "entiende" texto por sí solo. Ahí es donde el modelo de lenguaje de OpenAI aporta el criterio: resume una tabla de ventas en un párrafo claro, detecta lo relevante de decenas de respuestas o redacta el informe con el tono que necesitas. La combinación es potente justamente porque separa dos trabajos: n8n orquesta el flujo y ChatGPT razona sobre el contenido.

Esa división es el corazón de la AI Automation: un profesional de este campo no programa modelos, sino que los orquesta dentro de flujos que resuelven problemas concretos de negocio. Si este es tu primer contacto con el tema, conviene entender antes la lógica general en esta guía sobre cómo crear tu primer workflow con IA.

Si te interesa convertir este tipo de automatizaciones en una habilidad profesional, la Carrera de AI Automation de Henry enseña exactamente este stack —Make, n8n y APIs de IA— con proyectos reales desde la primera semana. 🚀

Qué vas a construir: un flujo de reportes de punta a punta

Antes de tocar la herramienta, conviene tener el mapa completo. El flujo que vas a construir tiene cuatro bloques, siempre en el mismo orden:

🔸 Disparador programado: define cuándo se genera el reporte (por ejemplo, todos los lunes a las 8 a. m.).

🔸 Origen de datos: de dónde salen los números (una planilla de Google Sheets, una base de datos, la respuesta de una API).

🔸 Generación con ChatGPT: el nodo de OpenAI recibe esos datos y redacta el reporte.

🔸 Entrega: el informe llega solo a un correo, un canal de Slack o un documento.

Entender este esquema hace que el resto sea, básicamente, armar cada pieza y conectarla. Vamos con el paso a paso.

Cómo automatizar tus reportes con n8n y ChatGPT, paso a paso

1️⃣ Prepara tu cuenta de n8n y tu clave de OpenAI

Tienes dos formas de usar n8n: la versión en la nube (n8n Cloud), lista para usar sin instalar nada, o la versión open source auto-hospedada, gratuita y con más control. Para un primer proyecto, la nube es lo más rápido; si quieres el detalle de la instalación gratuita, esta guía sobre cómo usar n8n de forma gratuita e ilimitada lo cubre.

Además necesitas una clave de API de OpenAI. La generas desde tu cuenta en platform.openai.com, en la sección de API keys: creas una clave nueva y la copias en ese momento, porque por seguridad se muestra una sola vez. Ten en cuenta que el uso de la API se cobra por consumo y es independiente de una suscripción a Chat GPT, así que la cuenta necesita saldo o un método de pago cargado. Esa clave es la que le permite a n8n hablar con Chat GPT, así que guárdala en un lugar seguro: funciona como una contraseña.

2️⃣ Configura el disparador programado (Schedule Trigger)

En un lienzo nuevo, agrega el nodo Schedule Trigger. Es el que hace que el flujo corra solo, sin que nadie apriete "ejecutar". Configúralo con la frecuencia que necesites —diaria, semanal o mensual— y a la hora en la que quieras recibir el reporte. Este disparador es lo que convierte una tarea manual en un proceso desatendido.

3️⃣ Trae los datos que alimentan el reporte

Conecta un segundo nodo según dónde vivan tus datos. Si están en una planilla, el nodo de Google Sheets los lee; si vienen de un sistema externo, el nodo HTTP Request consulta su API; si están en una base de datos, hay nodos para Postgres o MySQL. El objetivo de este paso es simple: dejar los datos ordenados para que ChatGPT los reciba limpios.

4️⃣ Genera el reporte con el nodo de OpenAI (ChatGPT)

Agrega el nodo de OpenAI y pega tu clave de API. Elige un modelo (por ejemplo, uno de la familia GPT-4o) y escribe el prompt: la instrucción que define qué reporte quieres. Aquí está el verdadero arte del flujo. Un buen prompt no dice "resume esto", sino algo como: "Con estos datos de ventas semanales, redacta un reporte de máximo 200 palabras que destaque el total, la variación respecto de la semana anterior y los tres productos más vendidos, en tono profesional". Cuanto más preciso el prompt, más útil el resultado, sin necesidad de retoques manuales.

5️⃣ Entrega el reporte automáticamente

El último nodo envía el resultado a donde lo necesites: el nodo de Gmail o de correo lo manda por email, el de Slack lo publica en un canal, el de Google Docs lo guarda como documento. Conecta este nodo a la salida de ChatGPT, prueba el flujo completo una vez a mano para verificar que todo encaje y, cuando funcione, activa el flujo. A partir de ahí, el reporte se genera y se entrega solo.

Armar flujos como este, cada vez más complejos, es el día a día de un especialista en automatización. La Carrera de AI Automation de Henry está pensada para perfiles de negocio, operaciones o marketing que quieren dominar estas herramientas sin saber programar. 💡

Buenas prácticas para que tu automatización no falle

Un flujo que funciona en la prueba puede fallar en producción si no cuidas algunos detalles. Estos son los que más importan:

• Prueba con datos reales, no de ejemplo: los datos del mundo real llegan con huecos y formatos raros; ejecuta el flujo con casos verdaderos antes de confiar en él.
• Controla el costo de la API: cada llamada a ChatGPT tiene un costo. Para reportes frecuentes, un modelo más liviano suele alcanzar y sale mucho más barato.
• Define qué pasa cuando algo falla: si el origen de datos no responde, el flujo debería avisarte, no enviar un reporte vacío.
• Revisa los reportes críticos antes de que salgan: para informes sensibles, conviene sumar un paso de revisión humana (human-in-the-loop) antes de la entrega.

Dominar estas decisiones —qué modelo usar, cómo manejar errores, cuándo sumar supervisión— es lo que separa a un aficionado de un profesional de la automatización. En la Carrera de AI Automation de Henry las pones en práctica sobre proyectos reales, acompañado por mentores que trabajan en la industria. ⚡

En resumen

• n8n orquesta el flujo y ChatGPT razona sobre el contenido: esa división de tareas es lo que hace potente la combinación para automatizar reportes.
• El flujo tiene cuatro bloques: disparador programado, origen de datos, generación con el nodo de OpenAI y entrega automática.
• El prompt es el corazón del reporte: cuanto más preciso, menos retoques manuales necesita el resultado.
• No necesitas programar: n8n funciona con nodos visuales, ideal para perfiles de negocio, operaciones o marketing.
• Las buenas prácticas —probar con datos reales, controlar costos de API y manejar errores— son lo que separa una demo de una automatización confiable.

Conclusión

Automatizar un reporte con n8n y ChatGPT no requiere ser programador: requiere entender el flujo —cuándo se dispara, de dónde salen los datos, cómo se genera el texto y a dónde se entrega— y armar cada pieza en un lienzo visual. Una vez que construyes el primero, el patrón se repite para casi cualquier tarea repetitiva que hoy te consume horas: informes, resúmenes, respuestas, clasificaciones. Ese cambio de mentalidad, de ejecutar tareas a diseñar sistemas que se ejecutan solos, es exactamente lo que el mercado valora en un perfil de automatización.

Si quieres pasar de automatizar un reporte a convertir la AI Automation en tu profesión, la Carrera de AI Automation de Henry te enseña a orquestar Make, n8n y APIs de IA con proyectos reales desde la primera semana, y un equipo de career coaches que te acompaña hasta conseguir empleo. Aplica y empieza a construir automatizaciones que trabajen por ti. 🚀

Preguntas frecuentes

¿Necesito saber programar para automatizar reportes con n8n y ChatGPT?

No. n8n es una herramienta no-code/low-code: se trabaja arrastrando y conectando nodos visuales. Basta con entender la lógica del flujo y saber escribir un buen prompt para el modelo de IA. Es un enfoque ideal para perfiles de negocio, marketing u operaciones sin experiencia en código.

¿Cuánto cuesta usar n8n y ChatGPT para esto?

n8n tiene una versión open source gratuita que puedes auto-hospedar y una versión en la nube de pago. El costo variable suele venir de la API de OpenAI, que cobra por uso: para reportes frecuentes, elegir un modelo más liviano reduce bastante el gasto.

¿Puedo automatizar otros procesos además de reportes con este mismo flujo?

Sí. El mismo patrón —disparador, datos, IA y entrega— sirve para clasificar correos, generar respuestas, resumir documentos o crear contenido. Cambian los nodos, pero la lógica es la misma.

¿Qué diferencia hay entre este flujo y un agente de IA?

Este flujo es una automatización lineal: sigue pasos fijos en un orden definido. Un agente de IA usa el modelo para decidir dinámicamente qué hacer en cada situación, con más autonomía. Para generar reportes con una estructura estable, un flujo lineal como este es más simple y confiable.

La forma en que se consigue un primer empleo en datos cambió, y muchos aspirantes todavía no lo notaron. Cada vez menos reclutadores leen un CV con cursos completados; cada vez más abren directamente el GitHub del candidato para ver qué construyó. En ese contexto, el portfolio dejó de ser un complemento y se convirtió en el filtro que decide quién pasa a la entrevista.

En esta nota te explicamos por qué ocurrió ese cambio, qué espera hoy el mercado de un portfolio de Data Science junior y cómo se ve, con ejemplos reales, uno que consigue destacar.

Por qué el portfolio se volvió el filtro real para entrar a Data Science

Lo que hoy separa a un postulante de otro no es el certificado —casi todos los tienen—, sino la evidencia concreta de trabajo, y esa evidencia vive en el portfolio. Un portfolio de Data Science es el conjunto de proyectos accesibles y documentados que demuestra, con hechos, lo que un candidato puede hacer con datos: obtenerlos, limpiarlos, analizarlos, modelarlos y comunicar un resultado útil para una decisión de negocio. Un certificado dice que alguien completó un temario; un proyecto desplegado dice que puede hacer el trabajo, y para un rol junior —sin experiencia previa que mirar— esa es la única prueba directa de su capacidad.

Si estás evaluando entrar al mercado de datos y quieres formarte para llegar con ese tipo de evidencia, la Carrera de Data Science de Henry está pensada para que termines con un portfolio real, no solo con contenidos vistos. 🚀

Qué espera hoy el mercado de un portfolio de Data Science junior

El estándar subió en los últimos dos años, y conviene entender hacia dónde. El mercado ya no se conforma con un notebook que entrena un modelo sobre un dataset de práctica: espera ver el proceso completo y, sobre todo, señales de que el candidato trabaja como se trabaja en una empresa real.

Tres expectativas nuevas marcan la diferencia en 2026.

• Integración de inteligencia artificial: un portfolio de datos que incorpora modelos de lenguaje —para clasificar texto, extraer información o acelerar el análisis— refleja hacia dónde se movió el rol y pesa más que uno puramente estadístico.
• Trabajo con datos reales y desordenados, en lugar de datasets de tutorial que cualquier reclutador vio mil veces.
• Proyecto desplegado y accesible, no solo disponible como código: se valora mucho más algo que se puede tocar que algo que hay que ejecutar por cuenta propia.

Este cambio no es exclusivo de Data Science: recorre todos los perfiles tech de la región, donde el portfolio con proyectos reales se volvió más decisivo que el CV. 🖇️ Vale la pena verlo en contexto en esta nota sobre las skills más demandadas en tecnología en Argentina y LATAM, que ubica al portfolio dentro de todo lo que el mercado da por sentado hoy.

Formarse con esa vara en mente es parte del enfoque de la Carrera de Data Science de Henry, que integra IA a lo largo de toda la cursada en lugar de dejarla como un módulo suelto al final. 💡

Cómo se ve un portfolio de Data Science que destaca hoy

Más allá de la teoría, vale la pena ver qué tipo de proyectos hacen que un reclutador se detenga. Un portfolio junior competitivo no necesita muchos: tres o cuatro proyectos sólidos que, juntos, muestren el flujo completo de datos alcanzan y sobran. Estos son los que mejor funcionan:

Un análisis exploratorio que cuenta una historia con datos.

No una colección de gráficos, sino una pregunta clara respondida con evidencia. Ejemplo real: analizar datos abiertos de alquileres de una ciudad para identificar qué variables explican mejor el precio, o cruzar datos de transporte público con datos de clima para detectar patrones de uso. Herramientas típicas: Python con pandas y seaborn.

Un modelo predictivo de punta a punta.

El proyecto que el mercado más quiere ver en un perfil de datos, porque demuestra que el candidato pasa de los datos a una predicción útil y evalúa con honestidad qué tan bien funciona. Ejemplo real: un modelo que anticipa la rotación de clientes (churn) de una empresa de servicios, construido con scikit-learn y con sus métricas y sus límites explicados.

Un proyecto con datos que el candidato consiguió y limpió por su cuenta.

Aquí se separa un portfolio del montón. Hacer scraping de una web pública o consumir una API abierta, y después lidiar con valores faltantes y formatos inconsistentes, demuestra exactamente el trabajo que ocupa la mayor parte del tiempo de un data scientist.

Un proyecto que combina datos e IA.

La señal más actual. Usar la API de un modelo de lenguaje para clasificar miles de reseñas por sentimiento, o para extraer datos estructurados a partir de texto libre y después analizarlos, muestra dos habilidades a la vez y conecta con la forma en que las empresas usan datos hoy.

Si buscas ideas concretas para empezar, en el blog tenemos una selección de 7 proyectos de Data Science para construir tu portfolio que puedes tomar como punto de partida. ⚡

Qué diferencia a un candidato que consigue entrevistas de uno que no

Dos personas pueden tener proyectos parecidos y resultados muy distintos en una búsqueda. La diferencia rara vez está en el modelo: está en cómo presentan y defienden su trabajo.

Un portfolio que consigue entrevistas presenta cada proyecto con un README que se entiende en treinta segundos —qué problema resuelve, qué datos usa, qué resultado obtuvo— y con una historia de negocio detrás: por qué se hizo y qué decisión ayuda a tomar. Esa capa es la que permite sostener una conversación en la entrevista y demostrar criterio, no solo técnica. Un modelo preciso que no explica qué decisión de negocio habilita queda siempre a mitad de camino.

A eso se suma un factor que define el techo de las oportunidades: el inglés técnico. Las mejores posiciones de datos para la región son remotas y para empresas del exterior, y en esos procesos la documentación, las herramientas y las propias entrevistas están en inglés. Un portfolio fuerte abre la puerta; el inglés define hasta dónde llega.

En resumen

• El portfolio se convirtió en el filtro real para conseguir un primer empleo en Data Science: los reclutadores revisan el GitHub antes que el CV.
• En 2026 el mercado espera más que un modelo entrenado: integración de IA, datos reales y desordenados, y proyectos desplegados y accesibles.
• Un portfolio competitivo incluye análisis exploratorio, un modelo predictivo de punta a punta, un proyecto con datos propios y uno que combine datos con IA.
• Lo que diferencia a quien consigue entrevistas es la presentación (README claro, historia de negocio) y la capacidad de defender las decisiones tomadas.
• El inglés técnico define el acceso a las mejores oportunidades, que son remotas e internacionales.

Conclusión

El cambio de fondo es claro: en Data Science, el mercado dejó de preguntar qué estudiaste y empezó a preguntar qué construiste. Un portfolio con proyectos reales, un modelo que funciona, datos que trabajaste por tu cuenta y una capa de IA no solo demuestra habilidades técnicas: demuestra que puedes hacer el trabajo desde el primer día. Para quien está entrando al mercado, esa es la mejor noticia, porque ese portfolio se puede construir sin experiencia laboral previa: hace falta un problema, datos y el criterio para resolverlo y explicarlo.

Si quieres formarte para llegar al mercado con ese tipo de portfolio —proyectos reales desde el primer día, IA integrada a lo largo de toda la cursada, mentores que trabajan en la industria y un equipo de career coaches que te acompaña hasta conseguir empleo—, la Carrera de Data Science de Henry está diseñada exactamente para eso. Aplica y empieza a construir el perfil que hoy consigue las entrevistas. 🚀

Preguntas frecuentes

¿Por qué el portfolio pesa más que un certificado para un primer empleo en Data Science?

Porque los certificados dejaron de ser un diferencial: casi todos los candidatos junior los tienen. El portfolio, en cambio, muestra evidencia concreta de lo que la persona puede hacer con datos. Para un rol sin experiencia previa, es la única prueba directa de esa capacidad, y por eso los reclutadores revisan el GitHub antes que el CV.

¿Cuántos proyectos necesito en mi portfolio de Data Science para un primer empleo?

No hay un número mágico, pero tres o cuatro proyectos sólidos y bien presentados suelen alcanzar para un perfil junior. Es preferible tener pocos proyectos terminados, documentados y accesibles que muchos a medio hacer. La variedad de habilidades que demuestran pesa más que la cantidad.

¿Puedo armar un portfolio sin experiencia laboral previa en datos?

Sí. La mayoría de los portfolios junior se construyen con proyectos personales usando datos abiertos, APIs públicas o datos que obtienes por tu cuenta. Lo que un reclutador evalúa no es si te pagaron por el proyecto, sino si resuelve un problema real y si puedes explicar las decisiones que tomaste.

¿Qué proyectos hacen que un portfolio de Data Science destaque en 2026?

Los que muestran el flujo completo de datos y reflejan cómo trabaja hoy el mercado: un análisis exploratorio con una conclusión clara, un modelo predictivo de punta a punta, un proyecto con datos reales que tú mismo conseguiste y limpiaste, y uno que integra IA de forma concreta, como usar la API de un modelo de lenguaje para clasificar o extraer información. Sumar al menos un proyecto accesible online termina de diferenciarlo.

Cuando alguien revisa ofertas de trabajo tech en Argentina y LATAM, algo llama la atención: hay habilidades que aparecen una y otra vez, independientemente de si la búsqueda es de un AI Engineer, un Data Scientist, un desarrollador Full Stack o un especialista en automatización. No son habilidades de nicho ni exclusivas de una especialidad: son la base que el mercado da por sentada antes de evaluar cualquier otra cosa. Esta nota las recorre una por una, con foco en lo que efectivamente se pide en el mercado de la región.

La base técnica que cruza todas las especialidades

Un lenguaje de programación dominado, no conocido

El mercado no pide "nociones de programación". Pide alguien que resuelva problemas reales con código, sin necesitar que le expliquen la sintaxis básica. En la práctica, esto se traduce en dos lenguajes según el camino elegido: Python para perfiles de datos, IA y automatización, y JavaScript/TypeScript para desarrollo web. Ambos aparecen en la mayoría de las búsquedas activas de Argentina como requisito no negociable.

Lo que distingue a un candidato que "conoce Python" de uno que "domina Python" en una entrevista técnica es simple: el primero explica conceptos, el segundo resuelve el problema que le ponen adelante.

SQL para trabajar con datos

Aunque no sea el centro de todas las especialidades, SQL aparece en una proporción enorme de las ofertas tech de la región, incluyendo roles que no son de datos en sentido estricto.

• Quien construye sistemas de IA lo necesita para acceder a los datos que alimentan sus pipelines.
• Quien desarrolla aplicaciones web lo usa para diseñar el backend.
• Quien automatiza procesos lo usa para consultar bases de datos desde sus flujos.

El nivel que pide el mercado no es avanzado, pero sí sólido: escribir consultas, hacer joins, filtrar y transformar datos con fluidez.

Git y control de versiones

Presente en absolutamente todas las ofertas de trabajo tech activas en Argentina y LATAM. No como diferencial, sino como mínimo esperado. Quien no trabaja con Git no puede trabajar en equipo en un entorno profesional tech, y eso los reclutadores lo saben. El nivel que se espera incluye commits, branches, pull requests y resolución de conflictos básicos.

Si estás evaluando qué carrera estudiar y quieres entender cómo se construye esta base en la práctica, puedes explorar las carreras de Henry disponibles hoy. 🚀

Las skills de IA que ya no son opcionales

Saber trabajar con IA, no solo usarla

En 2026, la capacidad de integrar herramientas de inteligencia artificial en el trabajo cotidiano ya no distingue a un perfil avanzado: es parte del estándar base. Esto no significa saber entrenar modelos desde cero. Significa saber cuándo delegar una tarea a un modelo de lenguaje, cómo formular bien una instrucción y cómo validar que el resultado sea correcto antes de usarlo.

• Para un desarrollador, esto se traduce en usar GitHub Copilot o Cursor con criterio, no con dependencia ciega.
• Para un analista de datos, en usar IA para acelerar la limpieza y el análisis sin perder el control sobre los resultados.
• Para un especialista en automatización, en conectar APIs de LLMs a flujos de trabajo reales.

Conocimiento básico de APIs

El ecosistema tech de 2026 está construido sobre APIs. Casi todas las herramientas se conectan entre sí a través de ellas, y casi todos los proyectos reales —desde una app Full Stack hasta un flujo de automatización o un sistema RAG— involucran consumir o construir una API. El mercado de la región pide, con distintos niveles de profundidad según el perfil, que el candidato entienda cómo funcionan las APIs REST, cómo autenticarse y cómo manejar los errores que ocurren cuando algo falla.

Si quieres profundizar en cómo estas habilidades transversales se construyen dentro de cada especialidad, puedes leer esta nota sobre las skills específicas que piden las empresas por perfil en Argentina y LATAM. 📚

Las skills que más diferencian candidatos en las entrevistas

🔸Inglés técnico

La brecha más clara entre las oportunidades laborales disponibles en Argentina y LATAM es el idioma. Las empresas locales que contratan para el mercado interno muchas veces no lo exigen. Pero el trabajo remoto para empresas del exterior —donde están las oportunidades con más proyección, mejores proyectos y mejores condiciones— lo pide en nivel B2 mínimo en la mayoría de los casos. La documentación de LangChain, React, scikit-learn, Docker y prácticamente todas las herramientas del stack tech está en inglés. Las entrevistas técnicas para roles internacionales se hacen en inglés. No es una habilidad que pueda dejarse para después si el objetivo son esas posiciones.

🔸Capacidad de comunicar decisiones técnicas

Aparece en las descripciones de puesto bajo distintos nombres: "comunicación con stakeholders", "capacidad de trabajar con equipos multidisciplinarios", "habilidad para explicar resultados a perfiles no técnicos". En la práctica, es la misma cosa: el mercado pide profesionales que sepan traducir su trabajo técnico al lenguaje de quien lo va a usar o pagar.

Quien construye un modelo predictivo preciso pero no puede explicar qué decisión de negocio habilita tiene un límite claro en su crecimiento. Quien diseña una arquitectura elegante pero no puede justificarla frente al equipo de producto enfrenta el mismo límite. Esta habilidad no se aprende de un curso; se construye practicando en contextos donde hay que rendir cuentas de lo que se hizo.

🔸Portfolio con proyectos reales desplegados

Más que una skill en sí misma, el portfolio es la evidencia de todas las anteriores.

Los reclutadores de empresas tech cada vez más reemplazan la revisión del CV por la revisión del GitHub. Lo que buscan no son ejercicios académicos: son proyectos que corren, que resuelven un problema real, que tienen documentación y que el candidato puede explicar en una entrevista.

✅Un proyecto de IA funcional accesible online vale más que veinte certificados.

✅Una aplicación completa con integración de herramientas modernas pesa más que cualquier curso en el CV.

✅Un flujo automatizado documentado diferencia al candidato que sabe usar las herramientas del que solo las conoce de nombre.

La formación que produce ese tipo de portfolio —con proyectos reales desde el primer día— es exactamente lo que diferencia una carrera en Henry de estudiar por tutoriales sueltos. Puedes conocer las carreras disponibles y elegir la que mejor se ajusta a tu perfil. 💡

La skill que no figura en ninguna oferta pero define todo

Ninguna descripción de puesto dice "buscamos alguien que aprenda rápido". Pero es, implícitamente, lo que el mercado tech más valora en 2026. Las herramientas cambian: lo que era estándar hace 18 meses puede haber sido reemplazado. Los frameworks que el sector usa hoy no existían hace dos años. Las plataformas añaden funciones cada mes y los modelos de IA se actualizan con una frecuencia que ningún curso puede seguir en tiempo real.

Lo que permanece es la capacidad de entender por qué algo funciona, no solo cómo usarlo. Esa comprensión es la que permite adaptarse cuando las herramientas cambian, resolver los errores que no están en la documentación y tomar decisiones técnicas con criterio en lugar de copiar soluciones sin entenderlas.

Si quieres construir esa base con acompañamiento real, las carreras de Henry combinan formación técnica aplicada, proyectos reales y mentores que trabajan activamente en la industria. ⚡

En resumen

• Python o JavaScript/TypeScript dominados (no solo conocidos) son la base técnica no negociable según el camino elegido.
• SQL aparece en la gran mayoría de las búsquedas tech en Argentina, independientemente de la especialidad.
• Git es el mínimo esperado en cualquier rol tech profesional de la región.
• Trabajar con IA con criterio —saber cuándo usarla y cómo validar sus resultados— ya es parte del estándar base, no un diferencial.
• El inglés técnico es la brecha más clara entre las oportunidades del mercado local y las oportunidades remotas internacionales con mayor proyección.
• Un portfolio con proyectos reales desplegados pesa más que cualquier certificado en los procesos de selección tech de Argentina y LATAM.

Conclusión

Las skills más demandadas en tecnología en Argentina y LATAM no son las que se nombran más en artículos de tendencias: son las que aparecen en las búsquedas reales de las empresas que contratan. Y lo que esas búsquedas muestran, una y otra vez, es que el mercado busca personas que puedan hacer cosas concretas con herramientas reales, explicar lo que hicieron y seguir aprendiendo cuando las herramientas cambien.

Construir esa base con proyectos reales, mentoría especializada y acompañamiento hasta el empleo es exactamente para lo que están diseñadas las carreras de Henry. Explorá las opciones disponibles y empezá a construir el perfil que el mercado pide. 🚀

Preguntas frecuentes

¿Cuáles son las habilidades tech más demandadas en Argentina en 2026?

Las que aparecen de forma transversal en las búsquedas activas son: un lenguaje de programación dominado (Python o JavaScript/TypeScript), SQL, Git, capacidad de trabajar con herramientas de IA, conocimiento básico de APIs, inglés técnico y un portfolio con proyectos reales desplegados. A estas se suma la comunicación técnica efectiva, que los reclutadores valoran cada vez más en todos los perfiles.

¿Qué nivel de conocimiento en inteligencia artificial se espera en un perfil tech junior en 2026?

En la mayoría de los roles tech actuales —desarrollo, datos, automatización— se espera que el profesional sepa cuándo usar IA para acelerar su trabajo y cómo validar que los resultados sean correctos. Quien no desarrolla esa capacidad pierde competitividad respecto a quienes sí lo hacen.

¿El inglés es obligatorio para trabajar en tecnología desde Argentina

Para empresas locales que operan en el mercado interno, no siempre. Para trabajo remoto con empresas del exterior —donde están las mejores oportunidades en términos de proyectos y condiciones—, el inglés B2 es un requisito real en la mayoría de los casos. La documentación técnica de prácticamente todas las herramientas del stack está en inglés.

¿Cuánto importa tener un portfolio en un proceso de selección tech?

Los reclutadores tech valoran más ver proyectos reales y funcionales que leer un CV con cursos completados. Un portfolio sólido —con proyectos desplegados, código documentado en GitHub y capacidad de explicar las decisiones tomadas— puede abrir puertas que años de experiencia no técnica no abren.

El título "AI Engineer" aparece cada vez más en LinkedIn, en ofertas de trabajo y en conversaciones sobre tecnología. Pero entre la descripción del rol y lo que pasa realmente dentro de un proyecto hay una brecha que vale la pena cerrar. Este artículo no describe el rol en abstracto: describe lo que un AI Engineer hace concretamente, proyecto a proyecto, decisión a decisión, en el tipo de contexto laboral al que puede acceder desde Argentina y Latinoamérica.

Qué es un AI Engineer (y qué no es)

Un AI Engineer es el profesional que construye sistemas de inteligencia artificial funcionales dentro de productos y procesos reales. No entrena modelos desde cero —eso es más propio de un ML Engineer o un investigador— sino que conecta modelos ya existentes con aplicaciones, datos y flujos de trabajo concretos, y se asegura de que esos sistemas funcionen de manera confiable en producción.

La distinción importa porque define qué hace en el día a día. Un AI Engineer no pasa su jornada ajustando hiperparámetros ni derivando funciones de pérdida: pasa su jornada integrando APIs de modelos de lenguaje, diseñando pipelines de datos, construyendo agentes, evaluando si el sistema responde bien o alucina, y resolviendo los problemas que aparecen cuando algo que funcionaba en desarrollo deja de funcionar en producción.

🌍 En Argentina y LATAM, el mercado para este perfil existe principalmente en dos modalidades: empresas locales (startups tech, consultoras, compañías que están integrando IA en sus procesos) y empresas del exterior que contratan talento latinoamericano de forma remota. Las mejores oportunidades —en términos de proyectos, aprendizaje y condiciones laborales— están en la segunda modalidad, y eso tiene una implicancia directa: el inglés técnico no es un plus, es un requisito real.

Si estás evaluando si la carrera de AI Engineering es tu camino, puedes conocer el programa de Carrera de AI Engineering de Henry y cómo está diseñado para prepararte para este mercado. 🚀

Qué tipos de proyectos construye un AI Engineer

Los proyectos de un AI Engineer no son todos iguales, pero hay un conjunto de tipos que se repiten con frecuencia en el mercado real:

🔸Sistemas RAG (Retrieval-Augmented Generation)

Es el proyecto de entrada más común para perfiles junior. Una empresa tiene documentos internos —manuales, contratos, bases de conocimiento, reportes— que sus empleados o clientes necesitan consultar. En lugar de buscar manualmente, se construye un sistema que permite hacer preguntas en lenguaje natural y recibir respuestas basadas en esos documentos. El AI Engineer diseña el pipeline: divide los documentos en fragmentos, genera sus embeddings, los guarda en una base de datos vectorial (Chroma, Pinecone), y conecta esa búsqueda con un modelo de lenguaje que genera la respuesta final.

🔸Agentes autónomos

Un agente es un sistema que no solo responde preguntas sino que ejecuta acciones en pasos: busca información, llama a APIs externas, toma decisiones intermedias y entrega un resultado. Un AI Engineer construye estos flujos usando frameworks como LangGraph, definiendo qué herramientas tiene disponibles el agente, cómo gestiona el estado entre pasos y cómo maneja los errores cuando algo falla en el camino.

🔸Integraciones de LLMs en productos existentes

Muchas empresas tienen productos ya funcionando y quieren añadirles capacidades de IA: un resumen automático, una clasificación de tickets, un asistente de escritura. El AI Engineer diseña la integración técnica: cómo se llama a la API del modelo, qué prompt recibe, cómo se valida la respuesta antes de mostrarla al usuario, y cómo se controlan los costos de uso.

🔸APIs de IA como servicios

Cuando el sistema de IA necesita integrarse a una aplicación más grande, el AI Engineer lo expone como un servicio usando FastAPI: un endpoint que recibe una pregunta y devuelve una respuesta, que se puede consumir desde cualquier frontend o sistema externo.

Si te interesa aprender a construir este tipo de proyectos con mentoría de profesionales activos en la industria, puedes explorar la Carrera de AI Engineering de Henry. 💡

Las tareas reales de un AI Engineer en el día a día

Dentro de un proyecto concreto, el trabajo de un AI Engineer incluye tareas muy distintas entre sí.

No todas son visibles en las descripciones de puesto, pero forman parte del trabajo real:

• Preparar y limpiar datos: los documentos o bases de datos que van a alimentar el sistema rara vez llegan en el formato correcto. Antes de generar embeddings, hay que decidir cómo dividir el contenido (qué tamaño de fragmento, con qué superposición), cómo manejar tablas, imágenes o formatos irregulares.
• Diseñar y ajustar prompts: la calidad de la respuesta de un LLM depende en gran medida de cómo se le formula la pregunta y qué contexto se le entrega. El AI Engineer prueba distintas formulaciones, mide el impacto y documenta lo que funciona.
• Evaluar las respuestas del modelo: un sistema que alucina —que inventa información con confianza— es un sistema que no puede ir a producción. Parte del trabajo es definir métricas de evaluación y revisar sistemáticamente que las respuestas sean correctas, coherentes y seguras.
• Desplegar y monitorear: con Docker para empaquetar el entorno y servicios de cloud (AWS, GCP o Azure) para el despliegue, el AI Engineer lleva el sistema de desarrollo a producción. Después del lanzamiento, monitorea que el comportamiento se mantenga estable y que los costos de API no se disparen.
• Comunicar decisiones técnicas: en un equipo real, el AI Engineer trabaja con product managers, diseñadores y otras áreas que no tienen contexto técnico. Explicar por qué se eligió una arquitectura, qué limitaciones tiene el sistema y qué se puede y no se puede hacer con él es parte esencial del rol.

Si quieres profundizar en cómo se entrena este tipo de pensamiento desde la formación, puedes leer esta nota sobre cómo Henry prepara a sus estudiantes para trabajar con inteligencia artificial. 📚

El stack real que usan los AI Engineers

Basado en las ofertas de trabajo activas en Argentina y LATAM en 2026, el stack más frecuente para este perfil incluye:

• Python: el lenguaje central. Sin Python sólido, el resto del stack no tiene base.
• LangChain y LangGraph: los frameworks de orquestación más presentes en las ofertas. LangChain aparece en más de un tercio de las búsquedas de AI Engineers a nivel global; LangGraph crece como la capa de producción para agentes con estado.
• Hugging Face: para acceder a modelos open source y, en algunos casos, hacer fine-tuning con datos propios.
• Bases de datos vectoriales: Chroma para desarrollo local, Pinecone para producción cuando el proyecto escala.
• APIs de modelos comerciales: OpenAI (GPT-4o), Anthropic (Claude) y Google (Gemini) son las más usadas. Saber cuándo usar cada una, y cómo controlar los costos, es parte del trabajo.
• FastAPI: para exponer modelos como servicios consumibles desde otras aplicaciones.
• Docker: para empaquetar entornos reproducibles. Aparece en más de una cuarta parte de las ofertas de AI Engineering en inglés.
• SQL: para acceder y transformar los datos estructurados que alimentan los pipelines.
• Cloud (AWS, GCP o Azure): la mayoría de los sistemas de IA en producción viven en la nube. Conocer los servicios de IA de al menos una plataforma es un requisito frecuente.

Qué se necesita para conseguir el primer trabajo como AI Engineer

El mercado argentino para AI Engineers está creciendo, y el contexto real es este:

La mayoría de las ofertas de AI Engineering en Argentina y LATAM —especialmente las que ofrecen trabajo remoto para empresas del exterior— piden entre 2 y 4 años de experiencia en Python y al menos algún proyecto de IA en producción. Los roles verdaderamente junior existen, pero son más escasos que en otras disciplinas como Full Stack o Data Science, y el proceso de selección es más exigente.

Esto no significa que el camino sea imposible, sino que requiere preparación específica:

• Un portfolio con proyectos reales desplegados. Una aplicación RAG funcional con código en GitHub y accesible online comunica más que veinte certificados. Los reclutadores de este perfil piden ver sistemas que corran, no solo ejercicios.
• Inglés técnico desde el principio. La documentación de LangChain, Hugging Face, FastAPI y todas las herramientas del stack está en inglés. Las entrevistas para roles remotos internacionales son en inglés. No es algo que pueda dejarse para más adelante.
• Una base sólida en Python y, al menos, comprensión de ML. No es necesario ser un experto en machine learning, pero sí entender cómo funcionan los modelos que se usan: qué son los embeddings, cómo funciona la atención en un transformer, qué es el fine-tuning y cuándo tiene sentido usarlo.
• Expectativas ajustadas al punto de partida. El primer trabajo puede no llamarse "AI Engineer". Puede ser un rol de Python Developer en una empresa que está empezando a integrar IA, o un puesto en una consultora que le da IA a sus clientes. Esa experiencia, sumada a los proyectos personales, es lo que construye el perfil que en 12 o 18 meses puede postularse con más fuerza a los roles que sí llevan ese título.

Si quieres formarte con proyectos reales, mentores que trabajan en la industria y un equipo de career coaches que te acompaña hasta el empleo, conoce la Carrera de AI Engineering de Henry. ⚡

En resumen

• Un AI Engineer no entrena modelos desde cero: conecta modelos existentes con productos, datos y flujos de trabajo reales.
• Los proyectos más frecuentes son sistemas RAG, agentes autónomos, integraciones de LLMs en productos existentes y APIs de IA.
• El trabajo diario incluye preparar datos, diseñar prompts, evaluar respuestas, desplegar con Docker y comunicar decisiones técnicas a equipos no técnicos.
• El stack real en Argentina y LATAM incluye Python, LangChain/LangGraph, FastAPI, Docker, bases de datos vectoriales y APIs de modelos comerciales.
• Las mejores oportunidades son remotas e internacionales, y requieren inglés técnico sólido (B2 mínimo).
• El primer empleo puede no llamarse "AI Engineer": lo que construye el perfil es la combinación de portfolio con proyectos desplegados y experiencia práctica en Python con IA.

Conclusión

Un AI Engineer en un proyecto real no trabaja en un laboratorio de investigación ni diseña arquitecturas teóricas: resuelve problemas concretos con las herramientas disponibles, itera cuando algo no funciona y aprende a comunicar sus decisiones técnicas en términos que el equipo pueda entender.

Lo que marca la diferencia entre alguien que estudia IA y alguien que consigue trabajo en IA es haber construido sistemas que funcionan y poder explicar las decisiones que tomó para hacerlos funcionar. La Carrera de AI Engineering de Henry está diseñada para que ese sea exactamente el resultado. 🚀

Preguntas frecuentes

¿Un AI Engineer necesita saber matemáticas avanzadas?

No es necesario tener el nivel de un matemático o un investigador. Sí conviene entender los conceptos básicos detrás de los modelos que se usan: qué son los embeddings, cómo funciona la similitud vectorial, qué implica el fine-tuning. Esa comprensión permite tomar mejores decisiones técnicas y no depender ciegamente de las herramientas.

¿Es obligatorio el inglés para trabajar como AI Engineer en Argentina?

Para las mejores oportunidades —especialmente roles remotos para empresas del exterior—, el inglés técnico es un requisito real, no opcional. La documentación de todas las herramientas del stack está en inglés, y las entrevistas técnicas para esos roles suelen hacerse en inglés.

¿Cuál es la diferencia entre un AI Engineer y un Data Scientist?

El Data Scientist se enfoca en analizar datos, construir modelos estadísticos y extraer insights. El AI Engineer se enfoca en llevar sistemas de IA a producción: integrar modelos con aplicaciones, construir APIs, diseñar agentes y garantizar que el sistema funcione de manera confiable. En muchos equipos colaboran, pero su trabajo cotidiano es distinto.

¿Qué tipo de portfolio necesita un AI Engineer junior para conseguir su primer empleo?

Un portfolio con al menos un sistema RAG funcional y accesible online, con el código en GitHub documentado, comunica más que cualquier certificado. Idealmente, el proyecto resuelve un problema real (aunque sea propio o de un proyecto personal) y el candidato puede explicar las decisiones técnicas que tomó para construirlo.

Tenemos un nuevo motivo para celebrar y compartir con toda la comunidad: Course Report acaba de publicar su ranking "The 24 Best Online Bootcamps of 2026" y Henry quedó en el puesto número 3 del mundo. Sí, leíste bien. No de Latinoamérica. Del mundo🌎

Este reconocimiento se basa en una calificación promedio de 4.7 estrellas sobre 5. Y en un ranking que evalúa 24 bootcamps de todo el mundo y que se actualiza de forma continua, llegar al podio implica mantener ese estándar de forma sostenida, no solo en un año puntual.

Qué es Course Report y por qué nos importa este reconocimiento

Course Report es la plataforma de referencia global para comparar y evaluar bootcamps tecnológicos. Evalúa programas de todo el mundo basándose en la calidad educativa, el éxito de los graduados en el mercado laboral y, principalmente, las experiencias reales de los estudiantes. Sus rankings no se compran ni se negocian: se construyen a partir de reseñas verificadas de personas que completaron los programas.

Nuestra comunidad nos elige año tras año por los resultados concretos: más de 20.000 graduados que aprendieron tecnología en Henry y que, en su mayoría, encontraron empleo en el sector. Sus experiencias son las que construyeron este lugar en el ranking.

Si quieres conocer de primera mano qué estudian y cómo se forman quienes logran esto, puedes explorar las carreras de Henry disponibles hoy. 🚀

Un camino de reconocimientos que se construye año a año

Este no es el primer reconocimiento que Course Report le otorga a Henry, y eso no lo hace menos emocionante, sino todo lo contrario: confirma que no fue casualidad. En 2025, Henry fue elegido el mejor bootcamp online de Latinoamérica en esa misma plataforma, y en septiembre del año pasado fue incluido entre los 25 mejores bootcamps de Data Science a nivel global.

Lo que cambia en 2026 es la escala: ya no se trata de una categoría regional ni de una especialidad. Es el ranking general de los mejores bootcamps online del mundo.

Que el reconocimiento llegue tres años seguidos no es una coincidencia: es la confirmación de que lo que funciona en Henry es la metodología, una comunidad que crece y un modelo de empleabilidad seguro.

Si quieres saber más sobre cómo Henry construyó ese historial de reconocimientos, puedes leer esta nota sobre cómo Henry fue elegido el mejor bootcamp online de LATAM en 2025. 📚

Qué dicen quienes construyeron este reconocimiento

Este reconocimiento lo construyeron los estudiantes que dejaron sus reseñas y los graduados que comparten sus experiencias. Sus palabras hablan de habilidades técnicas adquiridas desde cero, de una comunidad que sostiene el proceso de aprendizaje y de un equipo de career coaches que acompaña la búsqueda de empleo hasta que aparece la oferta.

En las reseñas publicadas en Course Report aparecen perfiles muy distintos entre sí: personas que venían de la enfermería, de la gastronomía, de las finanzas, de la música. Lo que comparten es haber encontrado en Henry no solo un stack técnico actualizado, sino también una forma de aprender que se adapta, un entorno que no abandona al estudiante cuando la dificultad aumenta y una red que sigue activa mucho después de la graduación.

Lo que Henry ofrece a cada uno de ellos:

• Proyectos reales desde el primer día, con el mismo nivel de exigencia que en una empresa tech.
• Henry Experts: mentores que trabajan activamente en la industria y acompañan el proceso con feedback real.
• Career coaches dedicados a preparar entrevistas, perfiles de LinkedIn y conexión con más de 3.000 empresas que contratan talento Henry.
• Garantía de devolución si no consigues empleo dentro del año posterior a graduarte, en carreras seleccionadas.

Si te reconoces en ese perfil y estás evaluando dar el salto a la tecnología, este puede ser el momento de aplicar a Henry. ⚡

La IA en el centro de cada carrera

Estar entre los tres mejores bootcamps online del mundo en 2026 también implica haber tomado una decisión curricular clara: la inteligencia artificial no es un módulo optativo al final de la carrera, sino el eje que atraviesa todo el proceso de formación.

Cada estudiante de Henry aprende con el apoyo de un AI Agent que personaliza su experiencia según su ritmo y sus necesidades, y cada carrera está diseñada para que el graduado llegue al mercado con herramientas de IA que ya se usan en la industria, no con las que se usaban hace dos años.

Estas son nuestras carreras:

• AI Engineering: Construye aplicaciones de IA de punta a punta: desde conectar modelos con datos propios mediante RAG hasta diseñar agentes autónomos y sistemas multimodales listos para producción.
• AI Automation: Aprende a automatizar procesos de negocio con herramientas no-code y low-code, sin necesidad de experiencia previa en programación, y conviértete en el perfil más demandado por empresas que quieren operar con IA hoy.
• Data Science AI: Aprende a trabajar con datos reales, construir modelos predictivos y comunicar hallazgos que impacten en decisiones de negocio concretas, con Python y las librerías más usadas en la industria.
• Full Stack AI: Desarrolla aplicaciones web completas —front-end y back-end— integrando desde el primer día las prácticas de codificación asistida por IA que ya son estándar en los equipos de desarrollo.

Cada reseña en Course Report es la firma de alguien que lo vivió.

Si estás evaluando tu próximo paso profesional y quieres que ese paso tenga el respaldo de una formación reconocida globalmente, aplica a las carreras de Henry. 🚀

Llegar al top 3 de los mejores bootcamps online del mundo es el resultado de miles de personas que apostaron por una decisión difícil, atravesaron una formación intensa y encontraron empleo en tecnología del otro lado. Cada reseña en Course Report es la firma de alguien que lo vivió.

Si estás pensando en dar ese paso, aplica a las carreras de Henry. El lugar 3 del mundo lo construyeron personas como tú. 🚀

Imagina poder preguntarle a un chatbot por las políticas internas de tu empresa, el contenido de un manual extenso o los datos de un catálogo de productos, y recibir una respuesta basada en información real, no inventada por el modelo. Esa combinación es posible gracias al RAG (Retrieval-Augmented Generation), una técnica que conecta un modelo de lenguaje con tus propios documentos. En esta guía vas a ver, paso a paso, cómo construir un chatbot de este tipo desde cero.

Qué es RAG y por qué lo necesita tu chatbot

Un modelo de lenguaje como GPT o Claude conoce el mundo hasta la fecha en la que terminó su entrenamiento, y no tiene acceso espontáneo a los documentos internos de tu empresa, a tus manuales de producto ni a las conversaciones de tus clientes. Cuando le pides que responda sobre algo que no vio durante el entrenamiento, pueden pasar dos cosas: que diga que no sabe, o que invente una respuesta que suena convincente pero es incorrecta.

💡 RAG, sigla de Retrieval-Augmented Generation, resuelve este problema de forma directa: antes de generar la respuesta, el sistema busca los fragmentos más relevantes dentro de tus propios documentos y se los entrega al modelo como contexto, para que la respuesta final esté anclada en información real y verificable.

Esta arquitectura no reemplaza al modelo de lenguaje ni requiere reentrenarlo: simplemente le da acceso a una fuente de información actualizada y específica justo antes de responder.

Cómo funciona un chatbot con RAG, paso a paso

Construir un chatbot con RAG implica armar una cadena de pasos que convierten tus documentos en algo que un modelo de lenguaje pueda consultar en tiempo real.

Estos son los bloques principales:

1. Preparar y dividir tus documentos

El primer paso es reunir el material que quieres que tu chatbot conozca: manuales en PDF, artículos de tu base de conocimiento, políticas internas o cualquier documento de texto. Como los modelos de lenguaje no pueden procesar documentos completos de una sola vez, ese contenido se divide en fragmentos más pequeños, generalmente de algunos cientos de palabras cada uno, cuidando que cada fragmento conserve sentido por sí mismo y que la información crítica no quede cortada a la mitad.

2. Convertir el texto en embeddings

Cada fragmento se transforma luego en un embedding: una representación numérica que captura el significado del texto, no solo las palabras que contiene. Gracias a esto, un modelo puede entender que una pregunta sobre "cancelar una suscripción" está relacionada con un fragmento que habla de "dar de baja un plan", aunque no comparta ninguna palabra exacta. Para esta tarea se usan modelos de embeddings como los de OpenAI o los de la librería sentence-transformers de Hugging Face.

3. Guardar y buscar en una base de datos vectorial

Los embeddings se almacenan en una base de datos vectorial —como Pinecone, Chroma o Weaviate— diseñada para buscar por similitud de significado en lugar de coincidencia exacta de texto. Cuando alguien le hace una pregunta al chatbot, esa pregunta también se convierte en un embedding, y la base de datos devuelve los fragmentos de tus documentos más cercanos en significado.

4. Conectar la búsqueda con el modelo de lenguaje

Con esos fragmentos relevantes ya identificados, el último paso es enviarlos junto con la pregunta original a un modelo de lenguaje —como GPT, Claude o un modelo open source corriendo en Ollama— pidiéndole que responda basándose en ese contexto. Frameworks como LangChain simplifican esta orquestación, conectando cada pieza (documentos, embeddings, base vectorial y modelo) en un solo flujo.

Si te interesa aprender a armar este tipo de arquitecturas con el acompañamiento de mentores que ya trabajan en la industria, conocer la Carrera de AI Engineering de Henry puede ser un buen punto de partida. 🚀

Qué herramientas necesitas para construir tu propio chatbot con RAG

Las piezas más usadas en proyectos reales de RAG son:

• Python — el lenguaje base para armar el flujo completo.
• LangChain — el framework que orquesta la cadena: documentos, embeddings, búsqueda y modelo.
• Pinecone o Chroma — bases de datos vectoriales para guardar y consultar los embeddings.
• API de un modelo de lenguaje — OpenAI, Anthropic o un modelo local con Ollama para generar la respuesta final.
• FastAPI — para exponer el chatbot como un servicio cuando necesita integrarse a una aplicación o sitio web.

Entender cómo se conectan entre sí es justamente lo que distingue a alguien que sabe usar un modelo de lenguaje de alguien que sabe construir un sistema completo alrededor de él.

Si ya tienes algo de experiencia en programación y quieres profundizar en este stack con proyectos reales y mentoría especializada, puedes conocer más sobre la Carrera de AI Engineering de Henry. 💡

Por qué dominar RAG es clave para un perfil de AI Engineering

Construir un chatbot con RAG deja de ser un experimento curioso en el momento en que una empresa necesita que su soporte al cliente, su equipo de ventas o sus propios empleados encuentren respuestas precisas dentro de información que cambia todo el tiempo. Las compañías ya no buscan solo personas que sepan usar modelos de lenguaje: buscan perfiles capaces de conectar esos modelos con datos reales, de forma segura y escalable, y esa es exactamente la habilidad que distingue a un AI Engineer.

Si te interesa dar el salto hacia este tipo de perfil técnico, la Carrera de AI Engineering de Henry está pensada para eso: proyectos reales de RAG, agentes y aplicaciones multimodales, con mentores que trabajan en la industria. ⚡

Una vez que tu chatbot puede responder con tus propios datos, el siguiente paso natural es darle capacidad de actuar, no solo de informar. Si quieres profundizar en eso, te recomendamos leer: Aprende a crear un agente de IA desde cero. 📚

En resumen

• RAG conecta un modelo de lenguaje con tus propios documentos para que sus respuestas estén basadas en información real, no inventada.
• El proceso completo incluye dividir tus documentos en fragmentos, convertirlos en embeddings y guardarlos en una base de datos vectorial.
• Herramientas como LangChain, Pinecone o Chroma, y modelos como OpenAI, Claude u Ollama, son las piezas más usadas en proyectos reales de RAG.
• Esta arquitectura no requiere reentrenar el modelo: actualiza su conocimiento agregando contexto justo antes de responder.
• Es una de las habilidades centrales que las empresas buscan hoy en un perfil de AI Engineering.

Conclusión

Construir un chatbot con RAG no requiere ser un experto en machine learning desde el primer día: requiere entender el flujo completo —preparar documentos, generar embeddings, buscarlos por similitud y conectar esa búsqueda con un modelo de lenguaje— y empezar a practicarlo con un caso concreto. Es una de esas habilidades que, una vez entendidas, cambian la forma en que piensas cualquier producto que necesite responder preguntas con información específica, ya sea un asistente interno, un buscador de documentación o un bot de atención al cliente.

Si este tipo de arquitecturas te genera curiosidad y quieres aprender a construirlas con acompañamiento profesional, en lugar de armar todo por tu cuenta a fuerza de tutoriales sueltos, la Carrera de AI Engineering de Henry te prepara con proyectos reales de RAG, agentes autónomos y aplicaciones de IA, guiado por mentores que ya trabajan en la industria. Aplica a la Carrera de AI Engineering y empieza a construir tu primer chatbot inteligente. 🚀

Preguntas frecuentes

¿Necesito saber programar para crear un chatbot con RAG? Sí, conviene tener una base de programación (Python es el lenguaje más usado) y conocimientos de APIs, ya que vas a conectar varias herramientas entre sí: una base de datos vectorial, un modelo de embeddings y la API de un modelo de lenguaje.

¿Qué diferencia hay entre RAG y el fine-tuning de un modelo?

El fine-tuning reentrena un modelo con nuevos datos, lo cual es costoso y requiere actualizarlo cada vez que la información cambia. RAG, en cambio, no modifica el modelo: le agrega contexto actualizado al momento de responder, lo que lo hace más rápido de implementar y más fácil de mantener.

¿Qué base de datos vectorial conviene usar para empezar?

Para un primer proyecto, Chroma es una opción simple porque puede correr de forma local sin configuración compleja. Pinecone es una alternativa popular en producción, especialmente cuando el proyecto necesita escalar.

¿Esta habilidad solo sirve para chatbots de atención al cliente?

No. La misma arquitectura se usa para asistentes internos de búsqueda de documentación, herramientas de análisis de contratos, buscadores semánticos y como la "memoria a largo plazo" de agentes de IA más complejos.