Traducción autorizada del paper canónico en inglés de A.M.O. CORE. La versión en inglés es la única versión normativa.
# A.M.O. CORE — Versión en español
## Resumen
Los sistemas basados en modelos de lenguaje de gran tamaño (LLM) se despliegan cada vez más como arquitecturas multi-agente en entornos operativos. A medida que estos sistemas escalan, la capacidad del modelo, la toma de decisiones y la ejecución de acciones se acoplan, con riesgos estructurales asociados a la autoridad implícita en los diseños actuales basados en agentes y con una falta de capas de gobernanza explícitas capaces de validar y restringir acciones.
Este trabajo introduce **A.M.O. CORE** como una aplicación de IA orientada a la gobernanza, en lugar de a la ejecución. A.M.O. CORE define y hace cumplir condiciones normativas para la acción, la invocación y la responsabilidad, con una separación explícita entre gobernanza y ejecución como principio arquitectónico central. El trabajo describe principios arquitectónicos e implicaciones operativas de sistemas orientados a gobernanza y posiciona la gobernanza como una preocupación de primera clase en el diseño de sistemas multi-agente basados en LLM.
## 1. Introducción
### Contexto y motivación
Los sistemas recientes basados en LLM han adoptado cada vez más arquitecturas multi-agente y se están desplegando en entornos operativos. A medida que estos sistemas evolucionan, la autonomía y la complejidad del sistema tienden a aumentar, mientras que los mecanismos estructurales de control siguen siendo limitados o están insuficientemente especificados.
### El problema estructural de control
Un modo de fallo arquitectónico recurrente surge cuando la capacidad del modelo, la toma de decisiones y la ejecución de acciones se acoplan dentro de los mismos componentes o rutas. En tales entornos, la autoridad implícita puede surgir como una suposición no validada de que un componente puede actuar, decidir o autorizar sobre la base de la capacidad o de la posición.
Este acoplamiento tiene consecuencias a nivel de sistema, incluida una auditabilidad reducida, la dificultad de asignar responsabilidad y la fragilidad operativa a escala.
### Gobernanza antes que ejecución
Este trabajo distingue entre (i) determinar qué puede ocurrir dentro de un sistema y bajo qué autoridad, y (ii) ejecutar lo que ocurre. La gobernanza funciona como una condición previa de legitimidad: las acciones se permiten únicamente una vez que las condiciones normativas bajo las cuales pueden ocurrir han sido definidas y validadas explícitamente.
En consecuencia, el artículo sostiene la necesidad de una capa normativa explícita que preceda a la ejecución.
### Contribución de este trabajo
Este trabajo introduce A.M.O. CORE como una aplicación de IA orientada a la gobernanza. Propone una separación explícita entre gobernanza y ejecución, formaliza la autoridad como un elemento explícito y trazable, y replantea el diseño de sistemas de IA en torno al control estructural.
### Alcance y no-objetivos
**Dentro del alcance.** Principios arquitectónicos, un modelo de gobernanza e implicaciones operativas.
**Fuera del alcance.** Diseño interno de los LLM, optimización del rendimiento y modelado cognitivo de agentes.
### Estructura del artículo
La Sección 2 describe el espacio del problema. La Sección 3 expone los principios arquitectónicos. La Sección 4 presenta el modelo A.M.O. CORE. La Sección 5 formaliza la separación entre gobernanza y ejecución. La Sección 6 discute implicaciones operativas. Las Secciones 7–8 proporcionan discusión y conclusiones.
## 2. Espacio del problema: Autoridad y control en sistemas LLM
### Capacidad vs. autoridad
Existe una distinción fundamental entre lo que un sistema **puede** hacer y lo que está **autorizado** a hacer. La capacidad técnica no implica la legitimidad de la acción. Comúnmente, el rendimiento del modelo se confunde con la autoridad de decisión, y la autoridad necesita tratarse como una propiedad normativa en lugar de una funcional.
### Autoridad implícita como fallo estructural
La autoridad implícita está presente cuando la capacidad se interpreta como permiso. También surge en sistemas donde los agentes asumen legitimidad por diseño o por posición, y donde no existe una validación explícita previa a la ejecución de acciones. La autoridad implícita se convierte en una fuente de decisiones no auditables, y se trata como un fallo arquitectónico en lugar de un bug de implementación.
### Limitaciones de los enfoques actuales
Los enfoques actuales basados en agentes a menudo permiten que los agentes planifiquen, decidan y ejecuten sin una separación formal de responsabilidades. Las herramientas, los *planners* y las *chains* se emplean con frecuencia como sustitutos de la gobernanza, y los mecanismos de control son predominantemente reactivos y *post hoc*. Estos enfoques carecen de una capa normativa explícita independiente del comportamiento del agente.
### Ausencia de control normativo explícito
Los sistemas actuales a menudo carecen de mecanismos formales para definir qué acciones son legítimas, validar invocaciones antes de la ejecución y restringir el comportamiento fuera de contratos explícitos. En estos entornos, a menudo se confía en el alineamiento del modelo como mecanismo de control, y mantener un control coherente se vuelve difícil a medida que los sistemas escalan.
### Necesidad de una capa de gobernanza
Existe un requisito de una capa de gobernanza dedicada para definir autoridad, establecer límites y validar legitimidad. Este requisito incluye una separación explícita entre decidir qué puede ocurrir y ejecutar lo que ocurre. La gobernanza se trata como infraestructura estructural en lugar de corrección *post hoc*, y se formula como una condición necesaria para sistemas multi-agente operables.
## 3. Principios arquitectónicos
### Separación de gobernanza y ejecución
La gobernanza y la ejecución son funciones del sistema distintas y sin solapamiento de responsabilidades. La gobernanza define legitimidad y restricciones, y la ejecución realiza acciones autorizadas. Ningún componente puede gobernar y ejecutar simultáneamente.
### Prohibición de la autoridad implícita
La autoridad debe definirse y concederse explícitamente antes de cualquier acción. La capacidad, el rendimiento o la posición no otorgan permiso. Cualquier forma de autoridad inferida o asumida es inválida por diseño.
### Separación de responsabilidades
La toma de decisiones, la ejecución y la supervisión son preocupaciones independientes. Cada responsabilidad debe asignarse a una capa dedicada. Colapsar responsabilidades introduce riesgo sistémico y pérdida de control.
### La gobernanza precede a toda acción
Las condiciones de legitimidad deben existir y validarse antes de la ejecución. Las comprobaciones o correcciones *post hoc* no constituyen gobernanza. La autorización es un prerrequisito, no un efecto colateral.
### Trazabilidad y auditabilidad
Toda acción debe ser trazable a una cadena explícita de autorización. Las decisiones de gobernanza deben ser inspeccionables y auditables a lo largo del tiempo. La auditabilidad es un requisito estructural, no un añadido operativo.
### Agnosticismo respecto al modelo
La lógica de gobernanza es independiente de implementaciones concretas de LLM. Los modelos pueden sustituirse o actualizarse sin alterar las reglas de gobernanza. La autoridad se vincula a contratos y reglas, no a modelos.
## 4. El modelo A.M.O. CORE
### Definición y rol
**A.M.O. CORE** se define como una aplicación de IA orientada a la gobernanza. Su función es actuar como la capa central de control en sistemas multi-agente basados en LLM. A.M.O. CORE establece condiciones normativas para la acción, la invocación y la responsabilidad. El sistema gobierna el comportamiento sin realizar tareas.
### Límites y fronteras del sistema
A.M.O. CORE no ejecuta acciones ni genera resultados operativos. No planifica tareas, no optimiza resultados ni persigue objetivos. Su autoridad se limita a validación, autorización y aplicación de restricciones. Cualquier intento de extender A.M.O. CORE a la ejecución se considera una violación de límites.
### Qué hace A.M.O. CORE
A.M.O. CORE define qué acciones pueden invocarse bajo determinadas condiciones. Valida solicitudes de acción frente a reglas explícitas de gobernanza. Autoriza o rechaza invocaciones según criterios formales. Registra cadenas de autorización para garantizar trazabilidad y auditabilidad. Hace cumplir la separación entre autoridad de decisión y capacidad de ejecución.
### Qué no hace A.M.O. CORE
A.M.O. CORE no ejecuta las acciones que autoriza. No genera planes, estrategias ni soluciones. No interpreta intención más allá de solicitudes explícitas. No asume autoridad basándose en el contexto del sistema o en la capacidad del modelo.
### A.M.O. CORE como capa central de control
A.M.O. CORE sirve como un punto único de verdad de gobernanza para el sistema. Media entre agentes y capas de ejecución. Impide que los agentes se auto-autoricen acciones. Garantiza la aplicación coherente de reglas de gobernanza entre agentes.
### Relación con agentes LLM y capas de ejecución
Los agentes LLM operan exclusivamente dentro de las capas de ejecución. Los agentes pueden solicitar autorización, pero no pueden concederla. Las capas de ejecución actúan únicamente con autorización explícita de A.M.O. CORE. La supervisión humana (HITL) puede participar en la gobernanza sin ejecutar acciones.
## 5. Gobernanza vs. ejecución
### Delimitación formal de capas
La gobernanza y la ejecución son capas del sistema formalmente delimitadas. La gobernanza posee la autoridad para decidir legitimidad y restricciones. La ejecución realiza acciones estrictamente dentro de la autorización concedida. No se permite flujo bidireccional de autoridad entre capas.
### Flujo de autorización e invocación
Las acciones se originan como solicitudes de autorización, no como decisiones. La gobernanza valida las solicitudes frente a reglas y contratos explícitos. La autorización precede a la invocación, y la invocación precede a la ejecución. Las solicitudes rechazadas no deben producir efectos colaterales.
### Imposibilidad de la auto-autorización
Ningún agente ni componente de ejecución puede autorizar sus propias acciones. La autoridad no puede inferirse del contexto, la intención ni la capacidad. La auto-autorización se trata como una violación estructural.
### Rol de la supervisión humana (HITL)
La supervisión humana participa en la capa de gobernanza. Los humanos pueden validar, anular o restringir autorizaciones. HITL no ejecuta acciones dentro del sistema. La intervención humana permanece explícita y trazable.
### Roles y capacidades comparadas
**Gobernanza.** Decide legitimidad, autoriza acciones y aplica restricciones.
**Ejecución.** Realiza acciones autorizadas, informa resultados y no tiene autoridad de decisión.
### Prevención del colapso de capas
Las interfaces explícitas separan gobernanza y ejecución. Las reglas de gobernanza se aplican de forma independiente de la lógica de ejecución. Cualquier colapso de capas introduce pérdida de control y auditabilidad. La separación de capas se hace cumplir de forma continua, no se asume.
## 6. Implicaciones operativas
### Control en entornos multi-agente complejos
Un diseño orientado a gobernanza permite control centralizado sobre agentes heterogéneos. La autorización explícita impide interacciones no controladas entre agentes, y el comportamiento del sistema permanece predecible a medida que crece el número de agentes. El control no depende del alineamiento interno ni de heurísticas de los agentes.
### Escalabilidad sin pérdida de gobernanza
Las reglas de gobernanza permanecen estables a medida que las capas de ejecución escalan horizontalmente. Se pueden introducir nuevos agentes sin redefinir la semántica de la autoridad, y el aumento de complejidad del sistema no implica un aumento de la complejidad de la gobernanza. El control escala de forma independiente a la capacidad de ejecución.
### Sustitución de modelos sin impacto normativo
Los LLM pueden sustituirse, actualizarse o diversificarse sin cambiar la lógica de gobernanza. La autoridad no está vinculada a capacidades específicas del modelo, y la evolución de modelos no requiere revalidar principios de gobernanza. La continuidad de la gobernanza se preserva a lo largo de los ciclos de vida del modelo.
### Auditabilidad y responsabilidad operativa
Toda acción ejecutada es trazable a una autorización explícita. La responsabilidad puede atribuirse a decisiones de gobernanza, no a comportamiento emergente. El análisis post-incidente se centra en cadenas de autorización, no en la intención del modelo. La auditabilidad es inherente a la arquitectura, no se añade retroactivamente.
### Alineación con entornos regulados y críticos
Los sistemas orientados a gobernanza se alinean con requisitos regulatorios de control y responsabilidad. La autoridad explícita respalda cumplimiento, certificación y auditoría externa, y la separación de roles se corresponde de forma natural con estructuras operativas reguladas. Los sistemas orientados a gobernanza son adecuados para despliegues en dominios críticos o de alto impacto.
### Reducción del riesgo sistémico
Eliminar la autoridad implícita reduce comportamientos impredecibles. La separación estructural limita fallos en cascada entre capas, y las restricciones de gobernanza actúan como salvaguardas sistémicas. El riesgo se gestiona arquitectónicamente, no de forma probabilística.
## 7. Discusión
### De sistemas inteligentes a sistemas gobernables
El diseño común de sistemas de IA enfatiza capacidad y rendimiento. El aumento de autonomía expone límites del control basado en capacidad. Se requiere un cambio desde lo que los sistemas pueden hacer hacia lo que se les permite hacer. La gobernabilidad emerge como una restricción principal de diseño.
### La gobernanza como infraestructura, no como *feature*
La gobernanza a menudo se trata como un añadido o capa de seguridad. En A.M.O. CORE, la gobernanza es una capa arquitectónica fundamental. El control se integra estructuralmente, no se aplica de forma reactiva. La infraestructura de gobernanza persiste independientemente del comportamiento del sistema.
### Implicaciones arquitectónicas del cambio
El cambio implica una redistribución clara de responsabilidades entre capas del sistema. La autoridad pasa a ser explícita, inspeccionable y exigible. Se reduce la dependencia del alineamiento del modelo como mecanismo principal de control. La arquitectura, y no el comportamiento, se convierte en el locus del control.
### Límites del enfoque
Los sistemas orientados a gobernanza pueden introducir complejidad adicional de diseño inicial. El control explícito puede reducir la flexibilidad a corto plazo. El enfoque requiere disciplina organizativa para mantener la separación de capas. No todos los dominios pueden requerir el mismo grado de rigor en la gobernanza.
### Consideraciones organizativas y de adopción
La adopción requiere replantear los sistemas de IA como infraestructuras gobernadas. Los equipos deben distinguir claramente entre roles de gobernanza y ejecución. La supervisión humana debe integrarse como una función de gobernanza, no como un recurso operativo. Los beneficios de operabilidad a largo plazo pueden superar los costes iniciales de adopción.
## 8. Conclusión
### Síntesis de la propuesta
Este trabajo abordó deficiencias estructurales de control en sistemas multi-agente basados en LLM. La autoridad implícita se identificó como un fallo arquitectónico central, y un diseño orientado a gobernanza se presentó como una corrección necesaria.
### A.M.O. CORE como cambio de capa
**A.M.O. CORE** replantea el diseño de sistemas de IA en torno a la gobernanza, no al comportamiento. La autoridad se trata como un constructo normativo explícito, y la separación entre gobernanza y ejecución se hace cumplir estructuralmente. El control se logra arquitectónicamente, no mediante el comportamiento del modelo.
### Implicaciones para el diseño de sistemas de IA
Los sistemas futuros deben distinguir capacidad de permiso. La gobernabilidad se convierte en un requisito de diseño de primer orden. La arquitectura, y no solo el alineamiento, es el mecanismo principal de control. Los sistemas pueden escalar sin perder auditabilidad ni responsabilidad.
### Trabajo futuro
El trabajo futuro incluye la formalización de contratos de gobernanza y esquemas de autorización, la exploración de interoperabilidad de gobernanza entre sistemas, la evaluación empírica de arquitecturas orientadas a gobernanza en entornos de producción y la integración con marcos regulatorios y de cumplimiento.
## Referencias
Las siguientes referencias se incluyen como contexto técnico.
No se utilizan como autoridad semántica ni se citan explícitamente en el texto.
- Wooldridge, M. (2009).
*An Introduction to Multi-Agent Systems*.
John Wiley & Sons.
- Russell, S., & Norvig, P. (2010).
*Artificial Intelligence: A Modern Approach*.
Prentice Hall.
- Panait, L., & Luke, S. (2005).
*Cooperative Multi-Agent Learning: The State of the Art*.
Autonomous Agents and Multi-Agent Systems.
- Amodei, D., et al. (2016).
*Concrete Problems in AI Safety*.
arXiv:1606.06565.
- LeCun, Y., Bengio, Y., & Hinton, G. (2015).
*Deep Learning*.
Nature.
- Nilsson, N. J. (1998).
*Artificial Intelligence: A New Synthesis*.
Morgan Kaufmann.
- National Institute of Standards and Technology (2023).
*AI Risk Management Framework*.
<https://www.nist.gov/itl/ai-risk-management-framework>
Note
This document is the
canonical and normative version
of the A.M.O. CORE paper.
Any versions in other languages are
authorized translations for reference only
and have no normative authority.
Propiedad de A.M.O. Lab -. Ingeniería de Sistemas Automatizados por IA. | R. Rubio