AI System Engineering: diseñar el sistema completo, no solo el modelo

Un tutor de IA funciona bien en una asignatura. Responde dudas del temario, orienta sobre las entregas y el profesor que lo solicitó puede revisar los casos dudosos. La pregunta siguiente llega sola: ¿se puede llevar a todo el grado?

Lo que se rompe al ampliar el alcance no tiene por qué ser el modelo. Cambia el usuario de servicio, que estaba limitado a un curso y ahora necesita acceso a muchos. Aparecen grupos y excepciones que no existían en el piloto. El consumo puede concentrarse durante las entregas y los exámenes. Si aumentan las respuestas enviadas a revisión y no crece la capacidad para revisarlas, aparece una cola. Y la retirada deja de ser trivial cuando el alumnado considera el tutor un canal normal de consulta.

La demostración probaba que el modelo podía responder en unas condiciones concretas. El producto debe funcionar también cuando cambian la escala, los permisos, el coste y la capacidad de corregirlo.

El modelo genera una salida. El sistema decide qué información recibe, quién

puede utilizar el resultado, qué efecto produce y cómo se responde si estaba equivocado.

En este artículo llamo AI System Engineering al trabajo que integra todas esas decisiones. Reúne ingeniería de software, arquitectura, seguridad, datos y diseño de producto alrededor de un componente cuyo comportamiento no puede predecirse por completo.

Empezar por la capacidad, no por el modelo

«Construir un asistente con IA» no define un producto. Antes de escoger el modelo hace falta saber qué tarea resolverá, para quién y con qué consecuencias.

Un sistema que resume notas privadas y otro que recomienda una actuación sobre una persona pueden utilizar el mismo modelo. No necesitan las mismas fuentes, explicaciones, revisiones ni formas de reparar un error. La precisión media del modelo no permite saber si cualquiera de los dos está preparado.

La definición de ingeniería de IA del Software Engineering Institute combina ingeniería de sistemas, ingeniería de software, informática y diseño centrado en las personas. El punto de partida son las necesidades y el entorno, no el componente técnico.

Una descripción mínima debería responder:

Comparar con la alternativa sin IA evita automatizar por costumbre. Si una regla conocida resuelve la tarea con menos errores y se explica mejor, introducir una decisión generativa empeora el sistema.

En el caso del tutor, estas decisiones cambian con el alcance. En una asignatura, el impacto puede quedar limitado a ese curso y el profesor que lo solicitó puede corregir antes los casos detectados. En un grado, una respuesta equivocada puede llegar a muchas personas antes de que alguien la detecte, y el foro de dudas sigue existiendo como alternativa. Es la misma capacidad, pero ya no es el mismo sistema.

Cuando el uso educativo entra en alto riesgo

El Reglamento (UE) 2024/1689 no clasifica como alto riesgo cualquier función de IA utilizada en educación. El punto 3 del Anexo III incluye cuatro finalidades concretas: decidir el acceso, la admisión o la asignación a centros; evaluar resultados del aprendizaje, también cuando esa evaluación orienta el proceso; determinar el nivel educativo que una persona recibirá o al que podrá acceder; y vigilar conductas prohibidas durante exámenes. El artículo 6.3 permite que determinados sistemas incluidos en esas finalidades no se consideren de alto riesgo cuando no planteen un riesgo importante ni influyan sustancialmente en una decisión. La finalidad prevista y el efecto real importan más que llamar al producto «tutor» o «copiloto».

Un tutor limitado a explicar materiales no entra automáticamente en esa lista. Si el mismo sistema evalúa a un estudiante o utiliza el resultado para orientar su itinerario, la clasificación puede cambiar. Esa frontera debe fijarse antes de diseñar los datos, los permisos, la evaluación y el despliegue, no en una revisión jurídica al final.

Cuando el sistema es de alto riesgo, el artículo 26 exige al responsable del despliegue medidas técnicas y organizativas, supervisión humana competente, vigilancia del funcionamiento y conservación de los registros que estén bajo su control. También obliga a suspender el uso e informar cuando aparezcan determinados riesgos o incidentes. Los organismos de Derecho público y las entidades privadas que prestan servicios públicos deben evaluar además el impacto sobre los derechos fundamentales cuando resulte aplicable el artículo 27. Para una dirección general, esto significa que el presupuesto del producto debe incluir responsables, registros, supervisión, respuesta ante incidentes y capacidad de detenerlo o retirarlo. Es ingeniería del sistema, no documentación añadida al final.

El comportamiento no vive solo en el modelo

Una respuesta puede cambiar aunque el modelo sea el mismo. Puede cambiar la interfaz que recoge la petición, la identidad del usuario, las instrucciones, la información recuperada, un recuerdo, la descripción de una herramienta o la regla que decide cuándo parar.

El modelo ocupa una caja. El comportamiento final depende de la información que recibe, los efectos que puede producir y los controles del conjunto.

Ver a tamaño originalCerrar

Los capítulos anteriores separan esas responsabilidades. Prompt Engineering se ocupa de las instrucciones persistentes. La ingeniería de contexto selecciona la información para cada ejecución. La memoria decide qué persiste. RAG recupera fuentes y los grafos permiten recorrer relaciones explícitas.

Un flujo fija los pasos. Un bucle utiliza el resultado de una vuelta para decidir la siguiente. Un agente elige acciones y herramientas. La coordinación reparte el trabajo cuando varios agentes aportan una mejora.

La ingeniería del sistema vuelve a unirlo todo. Una mejora local puede empeorar el producto: recuperar más documentos puede aumentar el ruido; recordar más datos puede invadir la privacidad; añadir agentes puede disparar el coste.

Mantener separadas la información y la autoridad

Una instrucción del producto, un dato escrito por el usuario, un documento recuperado, una página externa y una respuesta anterior pueden acabar juntos en la entrada del modelo. Todos aparecen como texto, pero no tienen la misma autoridad.

Un documento puede aportar un dato. No puede conceder acceso a una herramienta. Un recuerdo puede personalizar una respuesta. No puede cambiar una regla de seguridad. Una página externa puede contener una instrucción maliciosa y no por ello adquiere control sobre el agente.

Estas diferencias necesitan controles fuera del prompt:

• identidades separadas para la persona, la aplicación y los servicios;
• autorización cada vez que se consulta una fuente o se ejecuta una acción;
• herramientas con entradas delimitadas y resultados estructurados;
• separación entre datos, instrucciones y contenido externo;
• aprobación antes de los efectos sensibles;
• límites de tiempo, coste, pasos y recursos;
• ejecución aislada cuando el agente puede usar código o modificar archivos;
• registros que no copien credenciales ni datos innecesarios.

La publicación de Anthropic sobre agentes confiables distingue el modelo, el entorno de instrucciones y control, las herramientas y el entorno de ejecución. Cada parte aporta capacidad y también puede introducir fallos. Un buen modelo no compensa una herramienta con permisos excesivos.

Diseñar también la forma de fallar

Los prototipos suelen describir el caso en que todo sale bien. En producción también hay que decidir qué ocurre cuando falta información, dos fuentes se contradicen, una herramienta no responde o el proceso queda a medias.

Para cada capacidad conviene fijar cuándo debe preguntar, abstenerse o pedir una revisión. También hay que limitar los intentos, decidir qué resultado parcial puede mostrarse y cómo reparar un efecto ya producido.

Loop Engineering desarrolla las condiciones de parada y la necesidad de comprobar el objeto real. Agent Engineering añade los traspasos y permisos entre participantes. Aquí esas decisiones deben encajar con la seguridad y con la experiencia de uso del producto.

La versión incluye mucho más que el modelo

Registrar solo el nombre del modelo explica una parte pequeña del comportamiento. Para investigar una respuesta hace falta relacionarla con la configuración que la produjo:

• instrucciones y plantillas;
• modelo, proveedor y parámetros relevantes;
• reglas de contexto y memoria;
• documentos, índices y versiones de las fuentes;
• datos estructurados y esquema del grafo;
• herramientas, permisos y servicios externos;
• límites, condiciones de parada y aprobaciones;
• código, configuración y entorno de despliegue.

No hace falta asignar a mano un número a cada pieza. Sí hace falta poder reconstruir qué conjunto estaba activo. Si se actualiza una política fuera del código o se reconstruye un índice sin dejar rastro, el producto puede cambiar sin que parezca haber una nueva versión.

Volver a la configuración anterior tampoco revierte el mundo. Puede corregir las ejecuciones futuras, pero una notificación enviada o un acceso concedido exigen una reparación adicional.

Probar las piezas y el recorrido completo

Una sola puntuación del modelo no valida el producto. Puede responder bien con la fuente correcta y fallar porque el buscador no la encuentra. Puede elegir la herramienta adecuada con un permiso que no corresponde. Puede ofrecer una gran respuesta después de superar el tiempo y el coste que la hacían útil.

Las pruebas necesitan varios niveles:

Los casos deben incluir entradas normales, ambiguas, incompletas, contradictorias y hostiles. Como la salida puede variar, algunas comparaciones exigirán varias ejecuciones. La cantidad depende del riesgo y de la diferencia que intentamos detectar.

El núcleo del AI Risk Management Framework de NIST pide probar los sistemas antes del despliegue y durante su funcionamiento, documentar las métricas y utilizar revisiones independientes cuando resulte pertinente.

Una media puede ocultar un fallo grave. Antes de comparar versiones hay que decidir qué mejora se busca, qué no puede empeorar y qué error detiene la publicación. Una mejora media no compensa una filtración entre usuarios o una acción sin permiso.

Publicar poco a poco y observar

Las pruebas de laboratorio contienen los casos que alguien imaginó. Al llegar a producción aparecen idiomas, combinaciones y dependencias nuevas. Por eso una versión puede empezar con tráfico interno, ejecutarse sin producir efectos, llegar a un grupo pequeño y ampliarse de forma gradual.

Los criterios para avanzar y volver atrás deben decidirse antes de ver los resultados. Si el umbral cambia después de descubrir una regresión, ya no actúa como límite.

La observación combina señales tradicionales —disponibilidad, errores, demora y coste— con señales del comportamiento: calidad, abstenciones, fuentes, herramientas utilizadas, pasos, reintentos, aprobaciones, quejas e incidentes.

La guía de Google Cloud incluye las interacciones con el modelo, el uso de herramientas, la secuencia de decisiones, el rendimiento, la seguridad y la evaluación. La amplitud importa: un problema puede aparecer primero como más pasos o más coste y tardar en reflejarse en la calidad final.

Los registros también necesitan límites. Para depurar una decisión quizá baste con referencias y versiones; copiar todo el contenido aumenta el riesgo sin mejorar necesariamente la explicación.

El coste y la capacidad también son diseño

Una versión puede ser más precisa y empeorar el producto si tarda demasiado o duplica el coste. Cuando hay búsqueda, varios modelos y herramientas, el gasto se acumula y los promedios esconden los casos más caros.

El presupuesto debería medirse por tarea terminada. Las consultas sencillas pueden seguir un camino determinista o utilizar un modelo pequeño. La arquitectura completa se reserva para los casos que realmente la necesitan.

También importa la capacidad de revisión. Si el sistema genera el doble de propuestas y esa capacidad no crece, el cuello de botella solo cambia de sitio. Hay que observar la cola, el tiempo de espera y la capacidad de reparar, no solo la duración de cada llamada.

En un tutor educativo, esa restricción se hace visible al ampliar el piloto. Si las respuestas dudosas se derivan a revisión humana, incorporar más asignaturas aumenta la cola aunque la tasa de abstención no cambie. La arquitectura debe limitar el ritmo de ampliación a la capacidad real de revisión.

Poder cambiar, limitar y retirar

Gobernar no consiste en añadir una revisión al final. Cada sistema necesita un inventario que relacione su finalidad, responsables, usuarios, modelos, datos, proveedores, pruebas, riesgos y estado de operación.

Los incidentes reales deben convertirse en nuevos casos de prueba. Las personas afectadas necesitan una forma de comunicar errores y, cuando corresponda, impugnar el resultado.

Hay que preparar también la retirada: cómo desactivar la capacidad, revocar credenciales, detener la memoria, conservar o eliminar datos, ofrecer una alternativa y comunicar el cambio. Un sistema que no puede apagarse sin llevarse por delante el proceso que sostenía no está bajo control.

Apagar el tutor de una asignatura durante un piloto puede limitarse a retirar el acceso y devolver las consultas al foro. Retirar un canal que ya utiliza todo un grado exige un sustituto, un aviso y una fecha. Esa diferencia debe resolverse antes de ampliar el servicio, no cuando aparezca el primer incidente.

Qué significa estar preparado

El rigor depende del riesgo, pero antes de publicar una capacidad hay que poder explicar su finalidad, sus usuarios, las personas afectadas y los límites. La mejora debe compararse con una alternativa más sencilla, no solo con otra versión del modelo.

También debe poder reconstruirse la configuración completa. Fuentes, memorias y datos conservan procedencia, vigencia y permisos; las herramientas vuelven a comprobar la identidad antes de un efecto sensible; y las pruebas recorren casos normales, fronterizos y adversos.

La preparación termina en la operación. El despliegue puede ampliarse y detenerse de forma gradual, la observación detecta problemas de calidad, seguridad, coste y conducta, alguien responde por los incidentes y existe un plan practicable para limitar, sustituir y retirar la capacidad.

Una función reversible y de bajo impacto puede aprobarse mediante un proceso ligero. Una decisión cuyos efectos sean difíciles de detectar o reparar necesita controles más fuertes.

La nueva ingeniería de la IA separa las disciplinas para entender sus responsabilidades. Este capítulo vuelve a unirlas. El prompt, el contexto, la memoria, RAG, los grafos, los bucles y los agentes son piezas que modifican el comportamiento de un mismo producto.

Diseñar el sistema completo significa poder explicar qué decide cada parte, qué prueba sostiene esa decisión, quién puede cambiarla y cómo se recupera el control si falla. Solo entonces una capacidad demostrada por el modelo empieza a ser una función de la que una organización puede responder.