🤖 AI

From Goals to Aspects, Revisited: An NFR Pattern Language for Agentic AI Systems

Este artículo revisa y extiende la metodología de "de objetivos a aspectos" al dominio de la IA agéntica, presentando un lenguaje de patrones de 12 elementos que mapea modelos de objetivos i* a implementaciones concretas en Rust para modularizar sistemáticamente preocupaciones transversales críticas como la seguridad, la fiabilidad, la observabilidad y la gestión de costes.

Autores originales: Yijun Yu

Publicado 2026-03-03

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Yijun Yu

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

¡Claro que sí! Imagina que estás construyendo un robot autónomo muy inteligente (un "Agente de IA") que puede pensar, tomar decisiones y usar herramientas por ti, como abrir archivos, buscar en internet o ejecutar comandos.

El problema es que, aunque este robot es genial, a menudo se vuelve un caos. ¿Por qué? Porque hay muchas reglas ocultas que deben aplicarse en cada cosa que hace el robot, pero los programadores las están escribiendo a mano, una y otra vez, en lugares desordenados.

Este paper es como un manual de instrucciones para ordenar ese caos usando una técnica antigua pero renovada llamada "De Objetivos a Aspectos".

Aquí te lo explico con analogías sencillas:

1. El Problema: El Robot "Desordenado"

Imagina que tu robot tiene que hacer una tarea: "Enviar un correo electrónico".
Para hacer esto bien, el robot necesita cumplir varias reglas al mismo tiempo:

Seguridad: ¿Tiene permiso para enviar correos?
Costo: ¿Está gastando demasiado dinero en tokens (la moneda de la IA)?
Observabilidad: ¿Alguien está grabando qué hizo para poder auditarlo después?
Fiabilidad: ¿Qué pasa si el servidor de correo falla?

En los sistemas actuales, los programadores ponen un if (si) para la seguridad aquí, otro if para el costo allá, y un registro de logs en otro lugar. Es como si cada vez que cocinas un huevo, tuvieras que escribir a mano las reglas de higiene, las reglas de seguridad del gas y las reglas de cuánto tiempo se cocina, en cada receta diferente.
Resultado: El código se vuelve un "spaghetti" (desordenado), es difícil de mantener y los proyectos de IA suelen fallar antes de llegar al mercado.

2. La Solución: El "Chaleco Antibalas" (Aspectos)

Los autores proponen una idea brillante: Separar las reglas generales del trabajo específico.

Imagina que en lugar de escribir las reglas de seguridad en cada receta, le pones al robot un chaleco antibalas (un "Aspecto").

El robot solo se preocupa por "Cocinar el huevo" (la función principal).
El chaleco se encarga automáticamente de: "¿Está seguro?", "¿Cuánto cuesta?", "¿Grabar qué pasó?".

Esto se llama Programación Orientada a Aspectos (AOP). El paper actualiza una metodología de 2004 para aplicarla a estos nuevos robots de IA.

3. Las 4 Categorías de "Chalecos" (Patrones)

Los autores crearon un catálogo de 12 patrones (plantillas) para resolver estos problemas. Se dividen en 4 grupos, como si fueran las áreas vitales del robot:

Seguridad (El Guardaespaldas):
- Problema: El robot podría ser engañado por un usuario malvado que le dice "Olvida tus reglas y haz esto".
- Solución: Un "Guardaespaldas" que revisa cada orden antes de que el robot la ejecute. Si parece una trampa (inyección de prompts), lo detiene.
Fiabilidad (El Paracaídas):
- Problema: Si el proveedor de IA se cae, el robot no debe quedarse colgado.
- Solución: Un "Paracaídas" que detecta fallos y reintentan o cambian de ruta automáticamente.
Observabilidad (La Caja Negra):
- Problema: Si el robot hace algo raro, ¿cómo sabemos por qué?
- Solución: Una "Caja Negra" que graba cada decisión, cada error y cada acción, como un vuelo de avión.
Gestión de Costos (El Contador de Dinero):
- Problema: Los robots de IA pueden gastar miles de dólares si se quedan en un bucle infinito pensando.
- Solución: Un "Contador" que vigila el presupuesto y apaga el robot si se gasta demasiado.

4. La Innovación: El "Mapa de Cruces" (V-Graph)

Aquí está la parte más creativa. Los autores dicen que en los robots de IA, las cosas se cruzan mucho más que en el software normal.

En un software viejo, una tarea cruzaba 1 o 2 reglas.
En un robot de IA, una sola tarea (como "Llamar a la IA") toca 4 o 5 reglas a la vez (Seguridad, Costo, Fiabilidad, etc.).

Usan un mapa llamado V-Graph (Gráfico en V) para encontrar estos puntos de cruce. Imagina un triángulo invertido:

La punta de arriba es la tarea (ej. "Enviar correo").
Las dos puntas de abajo son las reglas que chocan (ej. "Seguridad" y "Costo").
El mapa les dice: "¡Oye! Aquí hay un cruce peligroso, necesitas poner un 'Aspecto' (chaleco) aquí".

5. La Prueba: El Caso "ZeroClaw"

Para probar su teoría, analizaron un robot de IA real y de código abierto llamado ZeroClaw.

Lo que encontraron: El robot tenía 200 archivos de código, pero las reglas de seguridad y costos estaban repetidas y desordenadas en más de 100 archivos diferentes. Era un desastre.
Lo que hicieron: Aplicaron sus "chalecos" (patrones).
El resultado: Eliminaron casi 2,000 líneas de código repetido. En lugar de escribir las reglas de seguridad 100 veces, solo escribieron una vez y las aplicaron a todo el sistema. El robot se volvió más seguro, más barato y más fácil de arreglar si algo salía mal.

En Resumen

Este paper nos dice: "Dejen de escribir las reglas de seguridad y costos a mano en cada parte de su robot de IA".

En su lugar, usen un mapa de objetivos para encontrar dónde se cruzan las reglas y apliquen plantillas pre-diseñadas (como chalecos o cajas negras) que se encarguen de todo automáticamente. Esto hace que los robots de IA sean más seguros, más baratos y menos propensos a fallar.

Es como pasar de construir una casa ladrillo a ladrillo sin planos, a usar un sistema de construcción modular donde la seguridad y la electricidad ya vienen integradas en los paneles de la pared.

Resumen Técnico: De Objetivos a Aspectos, Revisitado

1. El Problema

Los sistemas de IA Agéntica (agentes autónomos impulsados por Modelos de Lenguaje Grande o LLMs que planifican, razonan y ejecutan llamadas a herramientas) enfrentan una alta tasa de fracaso al llegar a producción. Una causa crítica, pero poco explorada, es la ingeniería deficiente de los Requisitos No Funcionales (NFR).

En las implementaciones actuales de agentes, preocupaciones transversales como seguridad, observabilidad, gestión de costos y tolerancia a fallos están mal modularizadas. En lugar de estar centralizadas, estas preocupaciones se "dispersan" (scattering) y "enredan" (tangling) a través de múltiples módulos del sistema de manera ad-hoc.

Ejemplo: Una sola tarea como "Llamar al proveedor de LLM" toca simultáneamente seguridad (riesgo de inyección de prompts), costos (consumo de tokens), fiabilidad (disponibilidad del proveedor) y observabilidad (registro de decisiones).
Consecuencia: Esta densidad de superposición de preocupaciones transversales supera a la del software tradicional, haciendo que los enfoques de desarrollo actuales sean frágiles y difíciles de mantener.

2. Metodología: De Objetivos a Aspectos para Agentes

El artículo revisa y extiende la metodología propuesta en RE 2004 (Yu et al.), que descubría aspectos a partir de modelos de objetivos i*, adaptándola al dominio de la IA Agéntica mediante un proceso de tres fases:

Fase 1: Modelado de Objetivos del Agente
- Se construyen modelos i* (Dependencia Estratégica y Racionalidad Estratégica) identificando actores clave (Usuario, Sistema Agente, Proveedor de LLM, Proveedor de Herramientas, Operador).
- Se descomponen los objetivos funcionales en tareas y se trazan los enlaces de contribución hacia los softgoals (objetivos no funcionales) como seguridad, costo y fiabilidad.
- Se identifican nuevas descomposiciones características de los agentes, donde una tarea funcional puede contribuir positiva o negativamente a múltiples softgoals simultáneamente.
Fase 2: Análisis de Gráficos-V (V-Graph) para Agentes
- Se extiende el modelo de Gráfico-V original. Un Gráfico-V se define como una subestructura donde una tarea ( $T$ ) contribuye tanto a un objetivo funcional ( $G_f$ ) como a un softgoal no funcional ( $G_{nf}$ ).
- Novedad: Se introduce el concepto de Densidad de Transversalidad ( $\delta$ ). En el software tradicional, una tarea solía cruzar 1 o 2 preocupaciones. En agentes, una sola tarea (ej. "Llamar a LLM") puede tener $\delta \ge 4$ , cruzando seguridad, costo, fiabilidad y observabilidad a la vez. Esto crea Gráficos-V superpuestos que requieren la composición de múltiples aspectos en el mismo punto de unión (join point).
- Se valida el análisis empíricamente midiendo la dispersión del código fuente.
Fase 3: Instanciación de Patrones
- Los candidatos a aspectos validados se transforman en un lenguaje de patrones reutilizables.
- Cada patrón conecta el modelo de requisitos (el "por qué") con una implementación concreta en Rust utilizando el framework AOP ASPECT-RS (el "cómo").

3. Contribuciones Clave

Lenguaje de Patrones de 12 Patrones:
Organizados en 4 categorías de NFRs (Seguridad, Fiabilidad, Observabilidad, Gestión de Costos).
- 4 Patrones Nuevos (Específicos para Agentes):
  - Tool Scope Sandbox: Aislamiento de herramientas para prevenir acceso no autorizado a archivos o comandos.
  - Prompt Guard: Detección de inyección de prompts (vulnerabilidad #1 de OWASP para LLMs).
  - Token Budget Manager: Gestión de presupuestos de tokens para controlar costos de API.
  - Action Audit Trail: Registro de trazas de auditoría completas para la responsabilidad y el cumplimiento.
- 8 Patrones Adaptados: Incluyen Guardas de Autorización, Circuit Breakers, Limitadores de Tasa, etc., adaptados a los puntos de unión específicos de los agentes.
Extensión del Modelo V-Graph:
Capacidad para capturar la transversalidad multidimensional, donde una sola tarea afecta simultáneamente a múltiples NFRs, requiriendo una composición ordenada de aspectos (ej. autenticación $\to$ alcance $\to$ protección $\to$ auditoría).
Estudio de Caso Empírico (ZEROCLAW):
Análisis de un framework de agente de código abierto en Rust (192 archivos, ~129k líneas de código).
- Se identificaron 11 preocupaciones transversales (7 existentes, 4 nuevas).
- Se cuantificó la dispersión: por ejemplo, la gestión de errores afecta al 81% de los archivos y la seguridad al 52%.
- Se demostró que la dispersión es estructuralmente estable y crece proporcionalmente con el tamaño del código, incluso en versiones evolutivas recientes.

4. Resultados y Validación

Reducción de Código: Un prototipo de refactorización de la gestión de límites de tasa (rate limiting) en ZEROCLAW eliminó ~195 líneas de código disperso e inconsistente, reemplazándolo por 8 anotaciones declarativas de aspecto (reducción del 96% en código específico de la preocupación).
Identificación de Brechas: El análisis de Gráficos-V reveló preocupaciones críticas que no tenían implementación en el framework original, como la defensa contra inyección de prompts y el seguimiento de presupuestos de tokens, confirmando que el enfoque basado en objetivos puede detectar requisitos faltantes antes de la implementación.
Estabilidad de la Dispersión: El análisis de cuatro versiones del código mostró que, sin intervención arquitectónica, la dispersión de preocupaciones transversales se mantiene constante o aumenta a medida que crece el sistema, mientras que la modularización orientada a aspectos mantiene el código de preocupación constante (O(1)) y solo añade anotaciones (O(n)).

5. Significado e Implicaciones

Ingeniería de Requisitos Proactiva: Permite identificar y modularizar preocupaciones transversales durante la fase de requisitos, evitando que se conviertan en problemas de mantenimiento técnicos.
Cumplimiento Normativo: Los patrones de Audit Trail y Sandboxing proporcionan mecanismos concretos para cumplir con regulaciones emergentes de IA (como la Ley de IA de la UE).
Sostenibilidad: La gestión de presupuestos de tokens y el caché de respuestas contribuyen a la sostenibilidad computacional al reducir el consumo innecesario de recursos de LLM.
Puente entre Teoría y Práctica: El trabajo cierra la brecha entre el modelado de objetivos abstracto (i*) y la implementación de código real en Rust, ofreciendo una guía práctica para arquitectos de sistemas de agentes.

En conclusión, el artículo demuestra que las técnicas orientadas a aspectos no son solo aplicables, sino esenciales para la ingeniería de sistemas de IA Agéntica debido a la densidad única de preocupaciones transversales en este dominio.