Resumen Técnico: SARC – Un Marco de Gobernanza por Arquitectura para Sistemas de IA Agéntica

1. Declaración del Problema

Los sistemas de IA agéntica, que perciben, planifican y actúan mediante herramientas y sub-agentes, están ingresando a entornos regulados más rápido de lo que ha madurado la infraestructura de gobernanza. Existe una desajuste estructural crítico: las obligaciones regulatorias (por ejemplo, supervisión humana, gestión de riesgos) suelen evaluarse mediante documentación post-hoc o se adjuntan a prompts y paneles de control. Esto crea un "desajuste estructural" donde las restricciones destinadas a limitar la ejecución a menudo se evalúan solo después de que la acción ha ocurrido.

Los enfoques actuales sufren modos de fallo específicos:

• Guardarraíles de Prompt: Los modelos pueden ignorar, reinterpretar o desviar instrucciones mediante herramientas.
• Filtrado de Salida: No puede detectar violaciones realizadas a través de efectos secundarios en el mundo en lugar de texto visible.
• Auditoría Post-hoc: Documenta violaciones pero no puede prevenirlas.
• Reglas de Flujo de Trabajo: A menudo son insuficientes en espacios de acción que se expanden dinámicamente, a menos que estén vinculados a un registro completo y se apliquen en el despacho.

El artículo argumenta que los controles de gobernanza deben pasar de estar adjuntos a artefactos (prompts, registros) a estar adjuntos a la ejecución dentro de la arquitectura del sistema.

2. Metodología: El Marco SARC

Los autores presentan SARC (Estado, Espacio de Acción, Recompensa, Restricciones), un marco de gobernanza por arquitectura. Si bien $S$, $A$ y $R$ son primitivas estándar de Aprendizaje por Refuerzo (RL), $C$ (Restricciones) es la contribución novedosa. Trata las restricciones como objetos de especificación de primera clase, iguales al estado y la recompensa, y las hace cumplir en puntos declarados dentro del tiempo de ejecución del agente.

2.1 La Tupla de Especificación

Una especificación SARC se define como $\Sigma = \langle S, A, R, C \rangle$.

• Restricciones ($C$): Divididas en tres clases:
  • $C_h$ (Duras): Las violaciones no están permitidas bajo ninguna política.
  • $C_s$ (Suaves): Las violaciones son admisibles a un costo marginal declarado.
  • $C_e$ (Escalación): Condiciones que requieren la transferencia de control a un operador humano.
• Estructura de la Restricción: Cada restricción $c \in C$ es una quintupla $\langle src, class, pred, verif, resp \rangle$, donde:
  • $src$: Origen (regulatorio, contractual, etc.).
  • $class$:$h$, $s$, o $e$.
  • $pred$: Predicado sobre estado, acción y tiempo.
  • $verif$: Mecanismo de verificación (precondición, monitor en tiempo de ejecución, post-hoc).
  • $resp$: Protocolo de respuesta (bloquear, registrar, escalar, abortar).

2.2 Arquitectura de Aplicación en Tiempo de Ejecución

Las restricciones se compilan en cuatro sitios de aplicación nombrados dentro del bucle del agente:

1. Puerta Pre-Acción (PAG): Evalúa antes del despacho. Se utiliza para restricciones duras y escalaciones predictivas decidibles solo a partir del estado y la acción.
2. Monitor en Tiempo de Acción (ATM): Evalúa durante la ejecución (por ejemplo, envolviendo llamadas a herramientas). Se utiliza para restricciones que dependen de salidas parciales (acumulación de costos, contenido en transmisión).
3. Auditor Post-Acción (PAA): Evalúa después de la finalización. Se utiliza para comparar el estado post-acción con el estado pre-acción (desviación, verificación de efectos secundarios).
4. Enrutador de Escalación (ER): Enruta acciones marcadas a operadores humanos con latencia de colas acotada en relación con la ventana de reversibilidad de la acción.

2.3 Extensión Multi-Agente

Para flujos de trabajo multi-agente, SARC introduce:

• Propagación de Restricciones: Las restricciones se heredan hacia abajo en la cadena de llamadas. Si una restricción no es decidible en la capa de un sub-agente, se evalúa en la capa más profunda decidible ("rescate de decidibilidad").
• Intersección de Autoridad: La autoridad es la intersección de todos los principales y agentes en la cadena de llamadas; es monótonamente no creciente.
• Árboles de Trazado que Preservan la Atribución: El rastro de auditoría es un árbol jerárquico, no una secuencia plana, preservando la cadena completa de relaciones principal-agente para evitar la dilución de la atribución.

2.4 Propiedades Formales

• Limitación del Moldeado de Recompensas: El artículo proporciona un contraejemplo formal (Proposición 1) que muestra que las penalizaciones de recompensa finitas no pueden garantizar generalmente el cumplimiento de restricciones duras para violaciones de baja probabilidad y alto pago. Por lo tanto, las restricciones duras deben ser predicados arquitectónicos, no términos de recompensa.
• Correspondencia Especificación-Trazado: Un sistema es "conforme a SARC" si satisface ocho invariantes (por ejemplo, admisibilidad pre-acción, derivación de trazado, completitud de aplicación). Esto asegura que para cada acción en un trazado, un auditor pueda verificar mecánicamente qué restricciones se aplicaron y qué respuesta se tomó, sin acceder al modelo o a los prompts.

3. Contribuciones Clave

1. Modelo de Especificación de Restricciones: Un modelo tipificado por clases ($\langle src, class, pred, verif, resp \rangle$) que es agnóstico a la implementación pero requiere metadatos específicos para la ejecutabilidad y auditabilidad.
2. Arquitectura de Aplicación en el Bucle del Agente: Una disciplina que mapea clases de restricciones a puntos de aplicación específicos (PAG, ATM, PAA, ER), convirtiendo la gobernanza de documentación a control de ejecución.
3. Auditabilidad Verificable: Una definición formal de "auditable por construcción" y un verificador prototipo que verifica trazas de tiempo de ejecución contra especificaciones en tiempo $O(|T| \cdot |C|)$.
4. Extensión Multi-Agente: Mecanismos para propagación de restricciones, intersección de autoridad y árboles de trazado para manejar topologías empresariales complejas.
5. Ruta de Compilación Regulatoria: Un método para mapear cláusulas regulatorias (por ejemplo, Artículo 14 de la Ley de IA de la UE) en predicados ejecutables y verificaciones en tiempo de ejecución.

4. Evaluación Empírica

Los autores realizaron una evaluación sintética reproducible en una tarea de adquisición ($H=1,000$ pedidos, 50 semillas) comparando SARC contra cuatro líneas base: Auditoría Post-hoc, Filtrado de Salida, Reglas de Flujo de Trabajo y solo Política como Código (PaC).

Resultados:

• Violaciones Duras: SARC ejecutó cero violaciones de restricciones duras bajo predicados exactos, igualando la línea base de Política como Código pero superando al Filtrado de Salida y a la Auditoría Post-hoc.
• Restricciones Suaves: SARC redujo los excesos de ventana suave en un 89.5% en comparación con la línea base de solo Política como Código. Esto se atribuyó a la colocación explícita de una respuesta de estrangulamiento en el Auditor Post-Acción (PAA) en lugar de depender del rendimiento intrínseco.
• Violaciones Residuales: Bajo aplicación imperfecta (ruido en el predicado o fallo de aplicación), las violaciones residuales se escalaban con el error de la pila de aplicación ($\epsilon_{pred} + \epsilon_{exec}$) en lugar de la tasa de oportunidad de violación ambiental.
• Compensación de Latencia: SARC incurrió en una latencia por paso de ~21 ms (vs. 0 ms para post-hoc), demostrando el costo explícito de la gobernanza en tiempo de ejecución.

5. Significado y Afirmaciones

El artículo posiciona a SARC no como una garantía de seguridad ni como una certificación de cumplimiento legal, sino como un sustrato arquitectónico que hace que las obligaciones sean ejecutables, inspeccionables y auditables en tiempo de ejecución.

• Cambio de Artefacto a Ejecución: La contribución principal es el cambio de adjuntar restricciones a artefactos (prompts, registros) a adjuntarlas a rutas de ejecución.
• Auditable por Construcción: SARC habilita la "auditable por construcción", donde el rastro de auditoría es generado por la adhesión del sistema a su especificación, en lugar de reconstruirse a partir de registros después de los hechos.
• Régimen B: El marco está diseñado para despliegues de "Régimen B" (entornos regulados, irreversibles o de pérdida asimétrica) donde omitir el componente de restricción $C$ hace que una especificación esté incompleta.
• Claridad Económica: Al forzar la declaración explícita de puntos de operación y ventanas de reversibilidad, SARC hace visibles las compensaciones entre falsos positivos, falsos negativos y capacidad del operador como decisiones de asignación de capital.

Los autores concluyen que SARC no hace que los sistemas sean seguros por sí solo; más bien, proporciona la disciplina estructural necesaria para ingeniar la seguridad y el cumplimiento, separando la optimización ($R$), la capacidad ($A$) y la admisibilidad ($C$) para evitar que los sistemas fallen como anomalías no observables.