Auditando OpenAI Swarm: lo que descubrimos cuando el framework «no hace casi nada»
Cuando OpenAI lanzó Swarm, la comunidad de desarrolladores lo celebró por lo que es: un marco de orquestación de agentes maravillosamente simple, ligero y fácil de entender. Sin embargo, desde la perspectiva de la gobernanza corporativa, esa misma simplicidad es su mayor vulnerabilidad.
Auditamos Swarm bajo el marco de la Vertical AI Governance Stack v1.0 y lo que encontramos es una lección fundamental para cualquier empresa que esté pensando en pasar de experimentos con IA a sistemas de producción.
El problema real: La «Gobernanza Implícita»
El gran problema de los marcos minimalistas como Swarm no es que funcionen mal, sino que asumen que la seguridad y el control ocurren en otro lugar. En Swarm, si el modelo decide que quiere ejecutar una función, el framework simplemente la ejecuta. No hay una aduana, no hay un notario y no hay un registro inmutable.
Eso es lo que llamamos Gobernanza Implícita: confiar en que el código que rodea a la IA será suficiente para contenerla. En una organización de alto riesgo, lo implícito es, por definición, inauditable.
Lo que Swarm garantiza (y lo que no)
1. Disponibilidad vs. Autorización (L3)
Swarm permite crear agentes que se pasan el control entre sí (handoffs). El framework garantiza que el agente A puede pasarle la pelota al agente B. Pero no garantiza que el usuario que inició la conversación tenga permiso para hablar con el agente B.
Si expones una función que conecta con un agente con privilegios administrativos, Swarm ejecutará el traspaso sin hacer preguntas. La autorización está acoplada a la visibilidad de la herramienta, no a una política de acceso explícita.
2. Decisión vs. Ejecución (L4)
Este es el hallazgo más crítico de la auditoría. En Swarm, la brecha entre que la IA «decide» hacer algo y que el sistema lo «hace» es cero. No hay un interceptor determinista que valide los parámetros antes de que lleguen al mundo real.
Si el modelo alucina un parámetro prohibido, Swarm lo envía directamente a la función de ejecución. La responsabilidad de validar recae enteramente en el desarrollador, dentro de cada función, lo que crea una superficie de ataque fragmentada y difícil de supervisar.
3. Memoria vs. Evidencia (L5)
Swarm es, por diseño, stateless (sin estado). Te devuelve la historia del chat al final de la ejecución y se olvida de todo. Para una auditoría formal, esto es insuficiente. Un rastro de chat volátil no es un registro de evidencias. No permite reconstruir quién autorizó qué, bajo qué política y con qué hechos verificados.
El hallazgo: Swarm como «Gobernanza Baseline»
La conclusión de nuestra investigación es que Swarm no es una herramienta de producción por sí misma, sino un excelente punto de partida para entender qué falta.
Revela con precisión quirúrgica dónde termina la ergonomía del desarrollador y dónde debe empezar la ingeniería de gobernanza. Si tu empresa está construyendo sobre Swarm, lo que en realidad está construyendo es la necesidad de rodearlo con una arquitectura de control externa (un «Sidecar de Gobernanza»).
Si quieres ir a la versión formal
La auditoría completa, con los tests arquitectónicos y el dashboard de conformidad capa por capa (L1-L6), está publicada en nuestro portal de investigación:
→ Applied Audit 01: OpenAI Swarm — Conformance Observatory
En el paper encontrarás el detalle técnico de por qué Swarm se clasifica como «No Conformante por defecto» en las capas críticas de ejecución y control, y qué responsabilidades específicas debe asumir el equipo de despliegue para cerrar ese gap.
¿Estás usando Swarm o frameworks similares para automatizar procesos de negocio? No esperes a que un agente «alucine» una orden de compra para preguntarte quién supervisa la ejecución. La transición hacia la v1.1 de nuestro stack se centra precisamente en cómo convertir estos marcos ligeros en infraestructuras seguras.
— Manuel Enrique Morales Santiago
