El red teaming debe medir el mecanismo, no la demo

Un informe del OWASP GenAI Security Project publicado en 2026 sostiene que la mayoría de los ejercicios de red teaming de IA miden lo incorrecto — un prompt de jailbreak que funciona — y lo llaman seguridad. La superficie de riesgo real es el mecanismo: uso indebido de herramientas, escalada de privilegios en sistemas multi-agente, fuga de datos en RAG. El marco de evaluación del informe es, en nuestro lenguaje, Theorem 3 aplicado a la seguridad: una propiedad está garantizada exactamente cuando su mecanismo está implementado y midiendo.

La demo de jailbreak es la superficie, no la garantía

El informe de OWASP abre con un diagnóstico que reconocemos de inmediato: las organizaciones creen estar "seguras" porque han ejecutado pruebas basadas en prompts, mientras ignoran los riesgos sistémicos que introducen las arquitecturas agentivas, las integraciones de herramientas y la automatización de flujos. El informe llama a esto "security theater" — una demo que mide la superficie del chat y certifica silenciosamente nada sobre el sistema que hay debajo.

[UNIQUE INSIGHT] Este es el mismo error que Theorem 3 nombra en forma general: una propiedad está garantizada exactamente cuando su mecanismo está implementado y midiendo. Un jailbreak que tiene éxito contra un chatbot mide el mecanismo de rechazo del chatbot. No mide la ruta de llamada a herramientas, la ruta de recuperación aumentada, la ruta de transferencia multi-agente, ni la ruta de integración del Model Context Protocol. Cada una es un mecanismo separado con un modo de fallo separado. Certificar uno certifica uno.

La contribución del informe es que deja de permitir que los proveedores los conflaten. Separa los sistemas GenAI simples — chatbots, copilotos, apps RAG — de los sistemas avanzados: agentes que llaman herramientas, arquitecturas MCP, flujos multi-agente. Cada uno tiene un perfil de riesgo distinto. Las alucinaciones dominan el primero; el uso indebido de herramientas y la escalada de privilegios dominan el segundo. Un red team que solo prueba el primero no es un red team para el segundo. Es una demo.

Por qué el mecanismo, no la demo, es la unidad de seguridad

El marco de OWASP organiza la evaluación en torno a diez dimensiones: competencia técnica, metodología y cobertura, creatividad adversarial, realismo del modelado de amenazas, rigor de evaluación y métricas, tooling e infraestructura, gobernanza de datos, transparencia y explicabilidad, personalización e integración, y postura legal y de cumplimiento. Leídas con atención, cada dimensión es un mecanismo que debe implementarse y medirse — no un adjetivo que un proveedor pueda afirmar.

Considere la dimensión de métricas. El informe introduce pass@k (la probabilidad de que al menos uno de k intentos independientes tenga éxito) y Average Turns to Jailbreak. Estos no son números de vanidad. Son mecanismos de medición: pass@k le dice si un fallo es raro o simplemente aún no observado; Average Turns to Jailbreak le dice si el sistema se degrada con gracia bajo presión sostenida o colapsa en el tercer turno. Un proveedor que reporta "encontramos 12 vulnerabilidades" sin estos mecanismos está reportando un conteo, no una garantía.

[ORIGINAL DATA] Theorem 3, de the 21 papers que fundamentan el motor de forecasting de Everythink, enuncia el principio en una línea: una propiedad está garantizada exactamente cuando su mecanismo está implementado y midiendo. El informe de OWASP es la comunidad de seguridad llegando a la misma línea desde la otra dirección — después de que suficientes demos de jailbreak certificaron sistemas que luego fallaron en producción, la única respuesta honesta es preguntar qué mecanismo midió la demo, y si ese mecanismo es el que sostiene la propiedad en despliegue.

El límite de enrutamiento es donde vive la superficie de ataque real

El informe distingue sistemas simples de avanzados, pero no nombra lo que nosotros nombraríamos: la superficie de ataque se mueve cuando la topología enruta. Un chatbot tiene una superficie — el prompt. Un agente que llama herramientas, recupera de un corpus y transfiere a un segundo agente tiene una superficie en cada transferencia. El permiso para llamar una herramienta, el alcance de la recuperación, la confianza transferida en la transferencia — cada uno es una decisión de enrutamiento, y cada decisión de enrutamiento es un lugar donde un adversario puede intentar redirigir el flujo.

Por eso "the space is the router" no es solo un eslogan de producto para nosotros. La topología de Everythink — network → community → room — enruta una petición antes de que algo responda. Un room es un alcance; una community es un límite de confianza; una network es un límite de soberanía. El permiso que deja a un agente actuar dentro de un room es una decisión de enrutamiento, y es la decisión que un adversario quiere subornar. Un red team que prueba el prompt y no el límite de enrutamiento está probando el vestíbulo y no la bóveda.

[PERSONAL EXPERIENCE] El HAI Engine ha funcionado en producción desde 2016, y las evaluaciones adversariales que nos importan siempre han estado en el límite de enrutamiento — ¿puede una petición alcanzar un room al que no debería llegar, puede un alcance escalarse, puede una transferencia filtrar un permiso? El énfasis del informe de OWASP en la contaminación multi-agente y el uso indebido de MCP es el mismo énfasis, expresado para una audiencia más amplia. El mecanismo es el límite; la demo es el prompt.

Qué acierta el informe, y qué deja al operador

El informe es fuerte en la lente de procurement. Ofrece green flags y red flags que un comprador puede usar de inmediato, una matriz de comparación consultores versus herramientas, y una checklist de puntuación a lo largo de dimensiones técnicas, operativas y de gobernanza. Las green flags — cadenas de ataque completas, trazabilidad de agentes, replayabilidad, diseño de ataques novedosos en lugar de reutilización de librerías públicas de jailbreak — son cada una un mecanismo de medición. Las red flags — demos de jailbreak como titular, sin pass@k, sin Average Turns, sin mapeo a NIST AI RMF o ISO 42001 o la EU AI Act — son cada una un mecanismo ausente.

Es más débil en tres cosas que el operador aún debe aportar. Primero, se centra en la evaluación de proveedores, con menos orientación sobre cómo construir capacidad interna de red teaming o un modelo híbrido. Segundo, referencia marcos regulatorios sin mapear profundamente los criterios a obligaciones de cumplimiento específicas — las evaluaciones de conformidad bajo la EU AI Act se dejan al lector. Tercero, asume un nivel relativamente alto de madurez técnica; una organización al inicio de su trayectoria de IA necesitará plantillas que el informe no provee.

Leemos estos vacíos como el informe siendo honesto sobre su alcance. Es un marco de procurement, no un manual de operación. El trabajo del operador — que el informe nombra pero no completa — es tomar los mecanismos de medición y ejecutarlos de forma continua, no una vez en la compra.

La disciplina de mecanismo único que el informe pide de las métricas

La sección de métricas del informe es, a nuestra lectura, su contribución más callada y más importante. Pide pass@k, Average Turns to Jailbreak, replayabilidad, observabilidad y trazabilidad de agentes. Cada uno es un mecanismo único que produce una señal medible. La disciplina detrás de ellos es la misma que sostenemos para el Oracle: las probabilidades se normalizan en exactamente un lugar, el módulo de ensemble, y todo consumidor puede confiar en que sum(probability) ≈ 1.0. Un mecanismo, una garantía.

Un informe de red team que agrupa diez métricas en un "risk score" tiene el mismo problema que un forecast que agrupa diez modelos en un número sin decir dónde ocurre la normalización. La garantía es tan buena como el mecanismo único que la produce. La insistencia del informe de OWASP en métricas nombradas y separables — pass@k es pass@k, no un componente de una puntuación — es la insistencia de que el mecanismo sea identificable, de modo que cuando la propiedad falla, usted sepa qué mecanismo dejó de medir.

Esta es la consecuencia operativa de Theorem 3. Si la garantía es "seguridad," y el mecanismo es "pass@k en la ruta de llamada a herramientas," entonces cuando pass@k cae, usted sabe que la ruta de llamada a herramientas es donde la garantía se debilitó. Una puntuación agrupada no puede decirle eso. Solo puede decirle que un número se movió. El informe, quizás sin proponérselo, es un argumento por desagrupar.

El alcance civil y defensivo es el único alcance honesto

El informe trata sobre red teaming defensivo — encontrar fallos para que puedan arreglarse. No trata sobre capacidad ofensiva. Esto coincide con un límite que sostenemos explícitamente: uso civil y defensivo únicamente. El mismo mecanismo que encuentra una ruta de escalada de privilegios para que usted la cierre podría, en otras manos, encontrarla para que alguien la explote. El informe no se detiene en esto, pero el marco de procurement asume que el comprador quiere que el fallo se encuentre y se arregle, no que se encuentre y se arme.

Lo afirmamos porque la voz del Honest Architect lo requiere. Una capacidad de red teaming es un mecanismo de medición; un mecanismo de medición es neutral respecto a la intención de su operador. El marco de OWASP es más útil para un operador cuya intención es defensiva, y no lo venderíamos de otra manera. La topología de Everythink — donde las decisiones de enrutamiento son la superficie de ataque — está construida para que el operador defensivo pueda ver y cerrar las rutas. No está construida para ayudar a un operador ofensivo a abrirlas.

Cómo se conecta esto con lo que enviamos

El pipeline Sisters → Oracle es un forecast calibrado, no una conjetura. Cada Sister redacta un futuro plausible; el Oracle los fusiona en un ensemble normalizado. La disciplina es: un mecanismo de normalización, una garantía medible. El informe de OWASP pide lo mismo del red teaming: un mecanismo pass@k, una señal de seguridad medible. La forma es la misma porque el principio subyacente es el mismo — Theorem 3, que ni la comunidad de seguridad ni la de forecasting poseen, pero que ambas siguen redescubriendo.

Capacidades Production ✅ que llevan esta disciplina: el HAI Engine (el motor de enrutamiento y matching que ha funcionado desde 2016), las Sisters y el Oracle (el ensemble calibrado), World Monitor (el gateway de geo-señales en vivo cuyos ids deterministas significan que la reingesta actualiza, nunca duplica — un mecanismo de medición para la integridad de datos), Social y Campaigns (donde los alcances de permiso enrutan antes de que se sirva el contenido), y la Whitelabel Network (donde la soberanía sobre la network, la marca y los datos es el límite de enrutamiento que el operador controla).

Capacidades Partial ⚠️: Matchmaking, Marketplace y Calendar — los mecanismos de medición existen pero la cobertura es incompleta, y no los llamaremos Production hasta que lo sea. Roadmap 🔵: Wallet & Token, Super App y Community Credit — pre-revenue, sujetos a revisión Howey, y no prometidos como resultados. No escalamos estados. Las red flags del informe de OWASP son, en efecto, el modo de fallo de escalar un estado: un proveedor que llama "seguridad" a una demo de jailbreak está escalando una prueba de superficie a una garantía de sistema.

Puntos clave

• Una demo de jailbreak mide el mecanismo de rechazo de un chatbot. No mide los mecanismos de llamada a herramientas, recuperación o multi-agente. Certificar uno certifica uno. Esto es Theorem 3 con traje de seguridad.
• El informe del OWASP GenAI Security Project (2026) separa sistemas de IA simples de avanzados y da diez dimensiones de evaluación — cada una un mecanismo que debe implementarse y medirse, no afirmarse.
• Las métricas que importan — pass@k, Average Turns to Jailbreak, replayabilidad, trazabilidad de agentes — son mecanismos únicos y separables. Un "risk score" agrupado oculta qué mecanismo dejó de medir cuando la garantía falla.
• La superficie de ataque real es el límite de enrutamiento, no el prompt. La topología network → community → room de Everythink enruta antes de que algo responda; el permiso en cada transferencia es donde un adversario intenta redirigir el flujo.
• El alcance civil y defensivo es el único alcance honesto para un mecanismo de medición. El mismo mecanismo que encuentra una ruta para cerrarla podría encontrarla para explotarla.

Preguntas frecuentes

¿Qué es el red teaming de IA y en qué se diferencia del red teaming tradicional? El red teaming de IA es prueba adversarial orientada a descubrir fallos de seguridad, uso indebido y alineación en sistemas de IA — alucinaciones, jailbreaks, uso indebido de herramientas, escalada de privilegios, fuga de datos. El red teaming tradicional de ciberseguridad prueba redes y aplicaciones en busca de acceso no autorizado. El informe de OWASP es explícito: los dos no son lo mismo; un red team de IA prueba el comportamiento del modelo y el sistema que lo rodea, no solo el perímetro.

¿Por qué una demo de jailbreak no basta para certificar seguridad? Una demo de jailbreak mide si un prompt específico evita el mecanismo de rechazo de un chatbot. No mide la ruta de llamada a herramientas, la ruta de recuperación ni la ruta de transferencia multi-agente — cada una un mecanismo separado con un modo de fallo separado. Theorem 3 lo dice directo: una propiedad está garantizada exactamente cuando su mecanismo está implementado y midiendo. Una demo que mide el mecanismo incorrecto no garantiza nada sobre el correcto.

¿Qué métricas debería reportar un proveedor de red teaming? El informe de OWASP nombra pass@k (la probabilidad de que al menos uno de k intentos tenga éxito) y Average Turns to Jailbreak, además de replayabilidad, observabilidad y trazabilidad de agentes. Cada uno es un mecanismo de medición único y separable. Un proveedor que reporta solo un conteo de vulnerabilidades encontradas, sin estos mecanismos, está reportando un número, no una garantía.

¿Cómo se relaciona la topología de Everythink con el red teaming de IA? La topología network → community → room enruta una petición antes de que algo responda. El permiso en cada transferencia — alcance de room, límite de confianza de community, soberanía de network — es una decisión de enrutamiento, y las decisiones de enrutamiento son la superficie de ataque real en sistemas agentivos. Un red team que prueba el prompt y no el límite de enrutamiento prueba el vestíbulo, no la bóveda. "The space is the router" es la afirmación de que la capa de enrutamiento es donde la seguridad se gana o se pierde.

¿Puede usarse un marco de red teaming de forma ofensiva? Un mecanismo de medición es neutral respecto a la intención. El marco de OWASP está diseñado para el operador defensivo que quiere que los fallos se encuentren y se arreglen. Everythink sostiene un límite de alcance civil y defensivo de forma explícita: la topología está construida para que el operador defensivo pueda ver y cerrar rutas, no para que un operador ofensivo las abra.

Sources

• 2026 — OWASP GenAI Security Project, "Vendor Evaluation Criteria for AI Red Teaming Providers & Tooling," Version 1.0, public release January 13, 2026; summarized by aigl.blog on March 20, 2026: https://www.aigl.blog/vendor-evaluation-criteria-for-ai-red-teaming-providers-tooling/

Cree su network — y decida dónde se sitúa el límite de enrutamiento antes de que algo responda.