La nueva ingeniería de la IA: de optimizar prompts a diseñar sistemas

En una conversación con una IA, cambiar una frase puede mejorar mucho la respuesta. En un producto, rara vez basta. El resultado también depende de quién hace la petición, qué datos puede consultar, qué ocurrió antes, qué fuentes siguen vigentes y qué herramientas tiene a su alcance.

Una alumna pregunta si puede entregar el trabajo el lunes. Parece una consulta de calendario. Para acertar hay que saber quién pregunta, en qué asignatura, a qué grupos pertenece, si tiene una prórroga, si su entrega está bloqueada y cuál de las fechas de la actividad manda sobre las demás. Ninguno de esos datos está necesariamente en la guía docente: el estado se reparte entre varias tablas y la regla que decide qué prevalece vive en el código.

Una instrucción excelente no resuelve nada de eso. Puede conseguir que el asistente responda con más tacto y, aun así, decir que sí a quien ya tiene la entrega cerrada. Ahí ya no hay un problema de redacción, sino el diseño de un sistema.

El futuro de la IA no se reduce a escribir mejores prompts. Consiste en

diseñar mejores sistemas.

Las instrucciones siguen siendo importantes. Lo que cambia es su lugar dentro del producto. Cuanto más se espera que haga la aplicación, más decisiones quedan fuera del prompt y más necesario resulta saber quién responde por ellas.

Esta colección separa esas responsabilidades en ocho disciplinas: Prompt Engineering, Context Engineering, Memory Engineering, RAG Engineering, Graph Engineering, Loop Engineering, Agent Engineering y AI System Engineering. No pretendo presentar una clasificación académica cerrada. Es un mapa de trabajo para no llamar «prompt» a todo lo que condiciona el comportamiento de una IA.

En este mapa, «prompt» nombra el contenido instructivo de la entrada, sea fijo o generado; «contexto» nombra la entrada efectiva que el sistema compone para una ejecución, incluida esa instrucción. La distinción evita convertir en sinónimos dos responsabilidades que se diseñan y cambian de manera diferente.

Lo que un prompt puede resolver

Una buena instrucción explica la tarea, reduce la ambigüedad, fija límites, ofrece ejemplos y define la forma de la respuesta. Cuando se reutiliza en un producto, además hay que probarla, versionarla, publicar sus cambios con cuidado y observar qué ocurre después. De eso trata el capítulo sobre Prompt Engineering en producto.

En el campus del ejemplo, intentar resolverlo todo dentro del prompt equivaldría a pegar políticas completas, calendarios de todos los grupos, el historial de la alumna y todas las herramientas disponibles. La entrada se volvería larga, cara y difícil de controlar, pero el modelo todavía tendría que deducir qué fecha manda y qué información puede utilizar para esa persona.

La ingeniería de contexto responde entonces a una pregunta distinta: de toda la información disponible, ¿cuál necesita el modelo para esta petición concreta? Decide qué entra, de dónde procede, con qué permisos y durante cuánto tiempo.

Si el tutor debe reanudar entre dos consultas una petición de prórroga que quedó pendiente, aparece la ingeniería de memoria. Su trabajo consiste en decidir qué estado de la tarea se guarda, para quién, con qué edición del curso, cuándo se actualiza y cuándo debe olvidarse. La prórroga oficial sigue consultándose en el sistema que la mantiene.

Ocho disciplinas, ocho preguntas distintas

La forma más sencilla de distinguirlas es mirar qué pregunta responde cada una:

El mapa separa ocho responsabilidades conectadas; su disposición no prescribe una secuencia de implantación.

Ver a tamaño originalCerrar

La tabla ordena la colección, pero no es una receta. Un producto puede necesitar recuperación sin memoria duradera, una secuencia fija sin agentes o un grafo sin ninguna autonomía. Pocas aplicaciones necesitarán las ocho capas. Añadirlas sin una mejora demostrable solo crea más lugares donde algo puede fallar.

La guía de Anthropic sobre construcción de agentes recomienda empezar por la solución más sencilla y añadir pasos o agentes cuando la mejora pueda medirse. Este mapa sirve para escoger responsabilidades, no para acumular componentes.

Encontrar un documento no garantiza una buena respuesta

RAG suele explicarse como una búsqueda que añade fragmentos al prompt. La idea es correcta, pero incompleta. Todavía hay que saber qué versión está vigente, quién puede verla, qué hacer cuando dos fuentes se contradicen y si lo recuperado basta para responder.

El capítulo sobre RAG Engineering parte de ese problema. Una respuesta puede sonar convincente y apoyarse en la fuente equivocada. También puede fallar porque el buscador nunca encontró el documento correcto. Son fallos distintos y conviene probarlos por separado.

Cuando la pregunta depende de varias relaciones —actividad, competencia, prerrequisito y norma—, buscar párrafos puede resultar torpe. La ingeniería de grafos representa esas entidades y sus vínculos para poder recorrerlos y comprobarlos.

Responder no es lo mismo que terminar

El tutor puede explicar cómo entregar una actividad. Otra cosa es consultar el intento de la alumna, ejecutar una acción autorizada, comprobar su resultado y decidir si hace falta otro paso. En el segundo caso hay un ciclo y puede haber efectos fuera de la conversación.

El sistema debe recordar lo que ha intentado, limitar los reintentos y comprobar el efecto real. Si acepta sin más que el agente declare «tarea completada», puede cerrar un trabajo que sigue fallando. El capítulo de Loop Engineering desarrolla esa diferencia.

Si el recorrido ya se conoce, normalmente basta con código o con un flujo fijo. La ingeniería de agentes cobra sentido cuando varias unidades toman decisiones propias y ese reparto mejora el resultado. Entonces hay que decidir quién delega, qué recibe cada especialista, qué permisos tiene y qué ocurre cuando dos conclusiones se contradicen.

El sistema es la unidad que llega a producción

La pregunta del lunes permite reunir el mapa. La instrucción define qué debe hacer el asistente y cuándo debe abstenerse. El contexto reúne la identidad de quien pregunta y la actividad concreta. RAG localiza la normativa de entregas vigente. Si hay que recorrer esas relaciones, un grafo puede enlazar la actividad con la asignatura y con quien puede autorizar una prórroga. La memoria conserva el estado necesario para reanudar la petición, mientras la prórroga oficial se consulta en el sistema que la mantiene. El bucle comprueba que la respuesta coincide con el estado real y no con el que había al empezar. Si la consulta deriva en una acción repartida entre varios agentes, uno puede consultar y otro ser el único autorizado para escribir.

Todavía falta el producto que identifica a la alumna, aplica sus permisos, registra qué se le respondió y permite corregirlo si la respuesta fue mala. Esa responsabilidad pertenece a la ingeniería del sistema completo.

Un error puede nacer en cualquiera de esos puntos. Corregir el prompt no actualiza una política, no limpia una memoria contaminada y no limita una herramienta demasiado potente. Cambiar de modelo tampoco arregla un sistema que le entrega la información equivocada.

Por eso hay que evaluar y mantener el sistema completo. El modelo es uno de sus componentes. El Software Engineering Institute de Carnegie Mellon define la ingeniería de IA como la combinación de ingeniería de sistemas, ingeniería de software, informática y diseño centrado en las personas. La propia definición sitúa el problema bastante más allá de escoger un modelo.

Es también el sentido en que utilizo IA aplicada: una capacidad integrada en procesos, controles y responsabilidades reales.

El AI Risk Management Framework de NIST pide probar los sistemas antes de publicarlos y durante su funcionamiento, documentar responsabilidades y vigilar también los componentes de terceros. La idea importante es la continuidad: la revisión no termina el día del estreno.

Cuándo merece llamarse ingeniería

El nombre solo tiene sentido si cambia la forma de trabajar. Para cada una de estas responsabilidades conviene poder responder:

• ¿Qué comportamiento se espera y en qué condiciones?
• ¿Qué entradas, versiones y dependencias pueden cambiarlo?
• ¿Qué pruebas debe superar antes de publicarse?
• ¿Quién puede modificarlo y quién revisa el cambio?
• ¿Cómo se identifica la versión que produjo una respuesta?
• ¿Qué señales revelarían un problema en producción?
• ¿Cómo se vuelve atrás y quién responde por los efectos ya causados?

Las respuestas cambian según se trate de un prompt, una memoria o un agente. El principio común es este:

Cada cambio que pueda alterar el comportamiento de una IA debe llegar a producción con pruebas, responsable, trazabilidad y posibilidad de reversión.

Eso no obliga a guardar cada conversación. Significa conservar lo necesario para explicar una decisión y depurar un fallo, con límites de acceso y retención. Y conviene recordar que volver a una versión anterior no borra lo que ya ocurrió: una acción ejecutada puede exigir una reparación adicional.

Una colección para separar antes de volver a integrar

Los siguientes capítulos aíslan una responsabilidad cada vez para poder entenderla. Después habrá que volver a unirlas. La memoria no puede convertirse en un almacén que el contexto carga entero. La búsqueda no puede saltarse los permisos porque haya encontrado un fragmento relevante. Un agente no puede ampliar su autoridad al delegar. Cada decisión local modifica el conjunto.

El capítulo final sobre AI System Engineering vuelve a reunir requisitos, arquitectura, seguridad, evaluación, versiones, costes, operación y retirada.

La pregunta deja de ser únicamente «¿qué prompt escribo?». Se amplía: «¿qué sistema estoy construyendo, qué pruebas permiten confiar en él y quién conserva el control cuando deja de comportarse como se esperaba?».