Qué es AI Engineering: diferencias con ML, competencias y ciclo

Publicado: 2026-03-09 · Actualizado: 2026-10-28

Por Goiko, Founder & AI Solutions CTO de GUGŌ Creative

Qué es AI Engineering, en qué se diferencia del machine learning y la ciencia de datos, qué competencias exige y cómo se evalúa, opera y controla en coste.

AI Engineering es la disciplina que construye productos y procesos sobre modelos de IA ya entrenados, sobre todo modelos de lenguaje, y se ocupa de que funcionen en producción: qué contexto recibe el modelo, cómo se mide si acierta, qué puede hacer y qué no, cuánto cuesta cada tarea y qué ocurre cuando el proveedor cambia o retira un modelo. Su punto de partida no es entrenar un modelo, sino adaptarlo y rodearlo de software fiable.

Se diferencia del machine learning clásico y de la ciencia de datos en dónde está el trabajo. En ellos, el peso está en preparar datos, entrenar y validar modelos propios; aquí, en el contexto, la evaluación continua, la seguridad, la observabilidad y el coste. Importa porque es lo que separa una demo de un sistema en el que la empresa puede confiar: la propia Anthropic reconoce que la distancia entre prototipo y producción suele ser mayor de lo previsto.

Qué es AI Engineering

Chip Huyen dedica su libro «AI Engineering» (O’Reilly, 2025) a adaptar modelos fundacionales —grandes modelos ya entrenados, como los de lenguaje— a problemas reales. En el repositorio del libro distingue ese trabajo del de las aplicaciones de machine learning tradicional: allí pesan más el etiquetado de datos, la ingeniería de características y el entrenamiento; aquí, la ingeniería de prompts, la construcción del contexto y el ajuste fino eficiente en parámetros.

El cambio de fondo es dónde está la dificultad. Con modelos generales disponibles por API, tener algo que funcione en una demo es rápido; conseguir que acierte de forma consistente, con los datos y los permisos de la empresa y a un coste controlado, es un trabajo de ingeniería. A ese trabajo se le llama AI Engineering.

Tampoco consiste solo en escribir prompts. Anthropic habla ya de ingeniería de contexto: las estrategias para seleccionar y mantener la información que ve el modelo en cada paso —instrucciones, herramientas, datos externos, historial—, tratada como un recurso finito. Diseñar ese contexto es una parte del oficio; medir, asegurar y operar el sistema, el resto.

AI Engineering, machine learning y ciencia de datos: diferencias

Las fronteras no son rígidas y muchos equipos combinan perfiles, pero cada disciplina responde a una pregunta distinta:

Criterio	Ciencia de datos	Ingeniería de machine learning	AI Engineering
Pregunta que responde	Qué dicen los datos y qué decisión apoyan	Cómo entrenar, desplegar y reentrenar un modelo propio	Cómo construir un producto fiable sobre un modelo ya entrenado
Punto de partida	Datos históricos de la empresa	Datos etiquetados y un modelo por entrenar	Un modelo general por API o de pesos abiertos
Trabajo principal	Análisis, estadística y modelos explicativos o predictivos	Características, entrenamiento y pipelines de datos y modelos	Contexto y RAG, herramientas, evaluación, guardrails y coste
Cómo se mide la calidad	Validez del análisis y métricas del modelo	Métricas sobre un conjunto de prueba y vigilancia de la deriva de datos	Evaluación de la tarea con casos reales, revisión humana y modelo como juez
Qué cambia sin que toques nada	Los datos y el negocio	La distribución de los datos	El modelo, que el proveedor actualiza o retira, y el contenido de las fuentes
Riesgo típico	Conclusiones erróneas	Un modelo que se degrada sin que nadie lo note	Respuestas inventadas, instrucciones inyectadas y coste descontrolado

AI Engineering no sustituye a las otras dos. Para prever la demanda, detectar fraude o inspeccionar piezas con visión artificial sigues necesitando modelos propios y lo que Google llama MLOps: unir desarrollo y operación de sistemas de machine learning con automatización y monitorización. Las dos ingenierías comparten una lección que recoge esa documentación: en un sistema real, el código del modelo es solo una pequeña parte. La diferencia práctica está en lo que cambia solo: en AI Engineering el modelo es de otro, y tu sistema tiene que seguir funcionando cuando el proveedor lo actualiza o lo retira.

Competencias de un equipo de AI Engineering

No hace falta una persona para cada una, pero el equipo tiene que cubrirlas todas:

Ingeniería de software: APIs, colas, bases de datos, pruebas, despliegue y seguridad. Es la mayor parte del sistema; el artículo Hidden Technical Debt in Machine Learning Systems ya advertía en 2015 de que las victorias rápidas con modelos no salen gratis.
Contexto y recuperación de información: qué documentos, datos y herramientas ve el modelo en cada paso, con los permisos de cada usuario. Ver cómo diseñar un sistema RAG.
Evaluación: convertir «que responda bien» en criterios medibles y en un conjunto de casos que se ejecuta en cada cambio.
Seguridad de aplicaciones con modelos de lenguaje: inyección de instrucciones, salidas sin validar y herramientas con permisos de más; el OWASP Top 10 para LLM es la lista de partida.
Operación y coste: trazas, métricas, límites de consumo y elección del modelo adecuado para cada tarea.
Producto y proceso: saber quién usa el sistema, qué error es tolerable y cuándo la respuesta correcta es no usar IA.

El Reglamento europeo de IA, en su artículo 4 modificado por el Ómnibus Digital, pide a proveedores y responsables del despliegue que adopten medidas para apoyar la alfabetización en IA de su personal, sin exigir un nivel concreto a cada persona: fomenta la formación, pero no sustituye a estas competencias. Si dudas entre crear el equipo o contratarlo fuera, lo comparamos en consultora, freelance o equipo interno.

El ciclo de AI Engineering: de la tarea a la operación

El ciclo se parece al de cualquier software en producción, con una diferencia: la calidad no se demuestra con pruebas que pasan o fallan, sino con mediciones sobre muchos casos.

Definir la tarea y el criterio de éxito: qué entra, qué sale y qué cuenta como acierto.
Construir el conjunto de evaluación con casos reales, incluidos los raros, los ambiguos y los malintencionados.
Hacer la versión más simple: instrucciones y contexto; herramientas o varios pasos, solo si hacen falta.
Medir y corregir cada cambio contra la evaluación; ajustar el modelo solo si la evaluación lo justifica.
Desplegar de forma gradual, con trazas, límites de consumo y vuelta atrás.
Operar: evaluación continua, vigilancia del coste y migración cuando el proveedor retira un modelo.

Evaluación

La guía de evaluación de OpenAI parte de que los modelos generativos son variables y la evaluación es la forma de probar el sistema pese a ello; recomienda evaluar pronto y a menudo, y en cada cambio. La de Anthropic pide casos que reflejen la tarea real, incluidos los extremos, corrección automática siempre que se pueda y, si un modelo hace de juez, que sea distinto del que generó la respuesta. Más detalle en testing de sistemas de IA y, si dudas entre RAG y ajustar el modelo, en fine-tuning o RAG.

LLMOps: versiones de prompts, modelos y datos

LLMOps es la parte operativa: versionar prompt, modelo, configuración y fuentes como se versiona el código, desplegar con vuelta atrás y gestionar un ciclo de vida que no controlas. Anthropic avisa con al menos 60 días de antelación antes de retirar un modelo público; el 30 de septiembre de 2026 anunció que retirará Claude Sonnet 4.5 de su API el 30 de noviembre (calendario de retiradas). OpenAI dejará de aceptar trabajos nuevos de fine-tuning en autoservicio el 6 de enero de 2027 (página de retiradas). Sin evaluación, cada migración es un salto a ciegas; con ella, es una prueba más.

Observabilidad

Por cada petición conviene registrar la entrada, el contexto recuperado, el modelo y su versión, las herramientas llamadas, la respuesta, la latencia, los tokens y el coste; sin eso no se puede explicar una respuesta errónea. OpenTelemetry mantiene convenciones semánticas para IA generativa que cubren llamadas a modelos, agentes, herramientas, evaluación y MCP, lo que permite no atarse a una sola herramienta de observabilidad. Si los registros contienen datos personales, fija su retención y quién puede consultarlos.

Coste

El coste crece con el uso, y OWASP recoge el riesgo de que se dispare como Unbounded Consumption (LLM10:2025). Las palancas son de ingeniería:

Medir el coste por tarea completada y fijar límites por usuario y por ejecución.
Reutilizar el prefijo común de las peticiones: en Anthropic, leer de la caché de prompts cuesta, en la mayoría de modelos, el 10 % del precio normal de entrada.
Mandar a lotes lo que no es urgente: la Batch API de OpenAI cuesta un 50 % menos y entrega en un plazo máximo de 24 horas.
Usar, para cada tarea, el modelo más pequeño que supere la evaluación.

Cómo se aplican estas piezas al salir del piloto lo contamos en IA generativa en producción.

Por qué AI Engineering importa para llevar IA a producción

Anthropic lo resume al contar cómo construyó su sistema de investigación: en agentes, la última milla suele convertirse en la mayor parte del camino. Sin esa ingeniería, los fallos son previsibles:

El proveedor retira el modelo y nadie sabe si el sustituto responde igual, porque no hay evaluación.
Un cambio de prompt arregla el caso del que se quejó un cliente y estropea otros diez que nadie vuelve a mirar.
Una integración entra en bucle y la factura del mes se multiplica sin que salte ninguna alarma.
Un documento con instrucciones ocultas hace que el asistente muestre información que el usuario no debería ver.

Para ordenar estos riesgos a lo largo del ciclo de vida existe el marco de gestión de riesgos de IA del NIST, de uso voluntario y con un perfil para IA generativa (NIST AI 600-1, de julio de 2024). Sirve como lista de comprobación para decidir qué medir y quién responde de cada riesgo.

Ejemplo hipotético: un asistente técnico que pasa de demo a producción

Este escenario es ilustrativo, no un caso de cliente. Una empresa de maquinaria industrial prueba un asistente que responde a su servicio técnico con los manuales de producto, y la demo convence. Para llevarlo a producción, el equipo:

convierte un centenar de preguntas reales del servicio técnico, con su respuesta correcta, en la evaluación;
filtra los manuales por permisos, porque algunos solo pueden verlos los técnicos internos;
exige que cada respuesta cite la página del manual y que diga cuándo no encuentra la respuesta;
registra cada consulta con su contexto, su coste y la valoración del técnico, y revisa los fallos cada semana;
fija un límite de gasto mensual y una alerta si el coste por consulta se desvía.

Ninguna de esas tareas cambia el modelo, y todas deciden si el asistente se sigue usando a los tres meses.

Equipo propio, partner o ambos

Un equipo propio de AI Engineering tiene sentido cuando la IA es central en el producto o hay un flujo continuo de casos de uso. Para los primeros sistemas suele bastar un partner que construya y opere junto a la empresa, con una persona interna dueña de la evaluación y del conocimiento del proceso. Qué hacemos nosotros en este terreno, con qué arquitecturas y en qué fases, está en nuestra página de AI Engineering y LLMOps.

Cuánto cuesta

No publicamos un precio para «AI Engineering» como servicio aislado ni para montar una plataforma de LLMOps: la evaluación, la observabilidad y el control de costes van dentro de cada sistema. Como referencia, estos son algunos rangos de nuestro informe de precios de software e IA en España 2026:

Chatbot o asistente con RAG: 10.000-25.000 €, en 4-8 semanas.
Copiloto interno con RAG y permisos por rol: 20.000-50.000 €, en 6-12 semanas.
Agente de IA: 20.000-35.000 € acotado a una tarea, en 6-8 semanas, y 35.000-60.000 € si es multiherramienta, en 10-16 semanas.

Se suman el uso de los modelos por API, desde unos 100 € al mes con poco volumen y 2.000-5.000 € al mes con volumen alto; la infraestructura cloud, de 50 a 500 € al mes, y el mantenimiento, del 15 al 25 % del coste de desarrollo al año. El desglose está en cuánto cuesta automatizar procesos con IA y en cuánto cuesta desarrollar un agente de IA.

Errores frecuentes

Elegir el modelo antes de definir cómo se medirá. Sin evaluación, la elección se hace por reputación y no por resultados en tu tarea.
Evaluar a ojo. Probar cinco preguntas en una reunión no dice nada de las quinientas que llegarán el primer mes.
Tratar el prompt como texto y no como código. Si no está versionado y probado, nadie sabe qué cambió cuando algo empeora.
No presupuestar la operación. El sistema necesita revisión de fallos, migraciones de modelo y control del coste mientras se use.

Preguntas frecuentes

¿Qué es AI Engineering?

La disciplina que construye productos y procesos sobre modelos de IA ya entrenados, sobre todo de lenguaje, y se ocupa de que funcionen en producción: contexto, evaluación, seguridad, observabilidad, coste y ciclo de vida de los modelos.

¿En qué se diferencia AI Engineering del machine learning y la ciencia de datos?

La ciencia de datos analiza datos para apoyar decisiones, y la ingeniería de machine learning entrena, despliega y reentrena modelos propios. AI Engineering parte de un modelo ya entrenado y se centra en adaptarlo con contexto, evaluarlo y operarlo como parte de un sistema de software.

¿Qué es LLMOps?

La parte operativa de AI Engineering: versionar prompts, modelos, configuración y fuentes, desplegar con vuelta atrás, evaluar en cada cambio, registrar cada petición y migrar cuando el proveedor retira un modelo.

¿Qué competencias necesita un equipo de AI Engineering?

Ingeniería de software, diseño de contexto y RAG, evaluación, seguridad de aplicaciones con modelos de lenguaje, operación y control de costes, y conocimiento del producto y del proceso. Ver consultora, freelance o equipo interno.

¿Necesita mi empresa un equipo propio de AI Engineering?

Solo si la IA es central en su producto o hay un flujo continuo de casos de uso. Para los primeros sistemas suele bastar un partner, con una persona interna responsable de la evaluación y del conocimiento del proceso.