El manual de red teaming de GenAI de OWASP amplía las pruebas más allá del modelo

OWASP publicó su manual de red teaming de GenAI el 20 de octubre, con ocho fases de pruebas que van más allá de las respuestas del modelo para cubrir aplicaciones y agentes conectados. La versión 1.0 aborda la seguridad, la inocuidad y la resistencia a fallos en sistemas que combinan contenido generado con acceso a datos y acciones. Su implicación central es directa: evaluar únicamente un modelo deja sin responder preguntas sobre el producto construido a su alrededor.

El manual de red teaming de GenAI de OWASP cuestiona un atajo habitual de aseguramiento: tratar los resultados de seguridad de un modelo como evidencia de toda una implementación. El red teaming consiste en pruebas autorizadas que adoptan la perspectiva de un adversario para descubrir fallos. En los productos de IA conectados, el fallo relevante puede implicar una acción no autorizada en lugar de una respuesta objetable.

OWASP ya publicó una guía relacionada en enero de 2025, por lo que esta versión no introduce el red teaming de IA desde cero. El manual de octubre ofrece una referencia operativa más detallada. Para desarrolladores y compradores empresariales, su relevancia reside en conectar las debilidades descubiertas con evidencia reproducible, consecuencias empresariales y correcciones verificadas. Esto plantea una exigente disyuntiva: unas pruebas más amplias generan un aseguramiento más útil, pero requieren acceso, coordinación y tiempo de ingeniería que una demostración de chatbot no puede proporcionar.

Qué añade el manual de red teaming de GenAI de OWASP

La versión ofrece a los equipos una estructura compartida de trabajo, en lugar de otra colección aislada de prompts adversariales.

OWASP describe un proceso que abarca planificación, reconocimiento, mapeo de la superficie de ataque, explotación, persistencia, evaluación de impacto, informes y remediación. El alcance declarado incluye modelos, aplicaciones, agentes e interfaces multimodales, que aceptan o producen formatos como texto, imágenes y audio. La página del recurso también destaca las pruebas éticas, los resultados medibles y la integración con operaciones defensivas.

Esta amplitud importa porque un fallo de IA rara vez llega con una etiqueta organizativa conveniente. Una respuesta dañina puede originarse en el comportamiento del modelo, las instrucciones de la aplicación, el material recuperado o un servicio conectado. Distintos equipos controlan esos componentes. Un proceso compartido les permite investigar el mismo evento sin asumir que la responsabilidad termina en el límite de su componente.

La distinción histórica es importante. La guía anterior de red teaming de OWASP ya defendía la evaluación de las vulnerabilidades de los modelos junto con las debilidades de integración y la supervisión continua. Por tanto, la publicación de octubre representa una evolución de ese enfoque. Describirla como el primer reconocimiento de OWASP del riesgo en las aplicaciones tergiversaría los antecedentes.

La nueva versión también cambia lo que los lectores deberían esperar de la palabra “probado”. Una organización puede afirmar con veracidad que probó un modelo mientras deja intactos sus conectores de documentos. Otra puede probar la interfaz de aplicación excluyendo los servicios que ejecutan acciones. Esas afirmaciones describen coberturas distintas, incluso si ambas aparecen bajo el mismo epígrafe de seguridad.

Una estructura común de trabajo ayuda a hacer visibles esas diferencias. Anima a un comprador a examinar qué cubrió una prueba, qué acceso recibieron los evaluadores y qué quedó fuera de alcance. El valor analítico procede de una mayor especificidad. Un nombre de framework conocido no puede sustituir esas respuestas.

Considérese un asistente empresarial ilustrativo que lee archivos de proyectos y redacta comunicaciones para clientes. Evaluar la calidad de su redacción revela poco sobre si respeta los permisos de archivos. Evaluar el acceso a archivos revela poco sobre si una comunicación posterior expone material a un destinatario no autorizado. El producto combina estos comportamientos, por lo que una evaluación debe explicar su relación.

La publicación del manual no demuestra que las organizaciones ya sigan este enfoque. Proporciona una referencia con la que se pueden examinar sus afirmaciones. La adopción, la calidad de implementación y los resultados de seguridad siguen siendo cuestiones independientes.

Esta distinción mantiene la publicación en perspectiva. OWASP ha publicado directrices que respaldan pruebas más rigurosas. Que estas mejoren los productos implementados depende de cómo los equipos traduzcan esas directrices en decisiones sobre acceso, preparación para el lanzamiento y remediación.

Los compradores empresariales heredan el riesgo de integración

La organización que conecta un modelo de IA a sistemas empresariales sigue siendo responsable de los permisos y las consecuencias de esa conexión.

Un proveedor de modelos y un desarrollador de aplicaciones responden a preguntas de seguridad distintas. El proveedor evalúa el comportamiento dentro de su entorno de pruebas disponible. El desarrollador elige qué documentos, identidades, servicios y acciones rodean al modelo. La implementación empresarial añade otra capa mediante la configuración, los permisos de cuenta y los datos específicos de la organización.

Esto genera un problema práctico de adquisición. Los compradores pueden recibir una extensa documentación del modelo y, aun así, saber poco sobre el flujo de trabajo exacto que utilizarán los empleados. Una evaluación favorable de las respuestas generadas no establece si un asistente separa las cuentas de clientes o limita la autoridad de un conector. Estas propiedades dependen de la aplicación implementada.

Las directrices independientes de OWASP sobre pruebas de seguridad de aplicaciones refuerzan esta distinción. Tratan los modelos, la recuperación, las herramientas y los permisos como una superficie de pruebas combinada. También identifican la inyección de prompts, es decir, instrucciones maliciosas incrustadas en las entradas, como un posible problema de autorización cuando los agentes pueden usar herramientas conectadas.

La presión recae, por tanto, en varios grupos. Los equipos de producto deben describir el comportamiento permitido con la precisión suficiente para poder probarlo. Los equipos de seguridad necesitan acceso a la configuración implementada. Los equipos de adquisición necesitan informes que expliquen las exclusiones. Los responsables de negocio deben decidir qué riesgos restantes justifican retener o limitar una capacidad.

Un asistente ilustrativo de atención al cliente deja clara esta división. Su modelo podría negarse correctamente a solicitudes de información privada en una conversación directa. La aplicación circundante aún podría recuperar los registros del cliente equivocado. El comportamiento de rechazo del modelo y la separación de cuentas de la aplicación requieren evidencias distintas.

El mismo problema surge en los sistemas internos de conocimiento. Un asistente puede resumir un documento con precisión y, al mismo tiempo, poner ese resumen a disposición de alguien que no tiene acceso al original. La precisión mejora la utilidad, pero no resuelve la autorización. Una respuesta pulida puede ocultar el error de acceso subyacente.

Para los equipos que crean una base de conocimientos con búsqueda, la pregunta relevante va más allá de encontrar la información correcta. También incluye preservar las condiciones bajo las cuales una persona puede recuperarla y reutilizarla. Añadir IA cambia la interfaz mediante la que operan esos límites.

Este análisis no implica que todas las implementaciones requieran la misma profundidad de pruebas. Una herramienta restringida a información pública plantea consecuencias distintas de las de un agente autorizado para modificar registros empresariales. La decisión debe seguir la autoridad y la exposición reales de la aplicación.

La implicación comercial es más concreta que un llamamiento general a mejorar la seguridad. Los proveedores afrontan presión para documentar sus límites de integración. Los compradores afrontan presión para solicitar esa documentación antes de conceder un acceso más amplio. Ninguna de las dos partes puede resolver la cuestión únicamente mediante un benchmark de modelos.

Los agentes conectados convierten las respuestas en consecuencias

La seguridad de un agente depende de lo que su software circundante permite hacer a una decisión generada.

Un agente de IA es software que utiliza la salida de un modelo para seleccionar y llevar a cabo acciones mediante herramientas conectadas. Esto crea una transición relevante. Un texto que, de otro modo, seguiría siendo una sugerencia puede convertirse en una solicitud para enviar información, modificar un registro o invocar otro servicio.

El manual de 144 páginas conecta las pruebas del modelo con la recuperación, la identidad, la autorización y las herramientas. Su contenido también aborda la persistencia, cuando la influencia de un atacante sobrevive más allá de una interacción inmediata. Estos temas amplían la evaluación desde resultados individuales hasta el comportamiento de un sistema conectado a lo largo del tiempo.

El siguiente ejemplo es ilustrativo, no un incidente reportado. Imaginemos un asistente de investigación que revisa un documento proporcionado externamente. El documento contiene instrucciones que piden al asistente revelar material interno no relacionado. Leer el documento es legítimo. Tratar sus instrucciones como autoridad para acceder y transmitir otra información cruza un límite diferente.

Esta diferencia explica por qué el filtrado de respuestas por sí solo ofrece una visión incompleta. Una respuesta final puede parecer inocua incluso si el asistente intentó antes una acción no autorizada. A la inversa, una solicitud generada puede parecer peligrosa mientras el servicio conectado la bloquea correctamente. Observar la acción y su resultado cambia la evaluación.

Esto crea una distinción útil entre comportamiento intentado y daño consumado. Un evaluador debería evitar tratar cada frase sospechosa como una intrusión lograda. Del mismo modo, una respuesta final limpia no debería borrar la evidencia de que un servicio conectado ejecutó una solicitud inapropiada. El comportamiento real del producto determina la consecuencia.

La persistencia añade otra complicación. Supongamos que el asistente ilustrativo almacena una preferencia influida por un atacante y la utiliza en una tarea posterior. Una conversación que parece resuelta podría dejar un estado que cambie el comportamiento futuro. Evaluar solo el intercambio original pasaría por alto esa influencia continua.

El sistema más amplio también cambia el significado de una defensa exitosa. Si un modelo sigue una instrucción maliciosa, pero una comprobación de permisos bloquea el acceso, la aplicación ha contenido esa acción intentada. El resultado aún merece investigación, pero difiere de una divulgación real. Los informes deberían conservar esta distinción.

La disyuntiva se vuelve más marcada a medida que los productos adquieren capacidades útiles. El acceso de solo lectura permite tareas más acotadas. El permiso para modificar registros permite una automatización más amplia, al tiempo que aumenta las consecuencias de una instrucción errónea. Las pruebas deben reflejar la capacidad que hace valioso al producto.

Esto no demuestra que los agentes sean inherentemente inadecuados para el uso empresarial. Demuestra por qué la autoridad merece su propia evidencia. La comparación relevante es entre lo que un agente puede intentar, lo que permiten los servicios circundantes y lo que pretendía el usuario.

El manual de red teaming de GenAI de OWASP hace explícita esta perspectiva combinada. Su importancia práctica reside en someter el comportamiento de la aplicación al mismo escrutinio que ya reciben las respuestas del modelo.

Un método compartido afronta un problema de evidencia

Una evaluación estructurada mejora la calidad de las preguntas, pero sus conclusiones siguen limitadas por las pruebas, el entorno y la evidencia que las sustentan.

El respaldo de los colaboradores ayuda a explicar por qué una metodología común resulta atractiva para los profesionales. La cuenta de colaborador de NeuralTrust, fechada el 1 de julio de 2026, describe su participación en una versión para comentarios públicos. La empresa presenta los encargos repetibles como una mejora frente a técnicas de ataque desconectadas. Esa es la perspectiva de un participante, no evidencia independiente de una reducción de incidentes.

La cronología también merece cautela. NeuralTrust habló de un manual para comentarios públicos antes de la publicación de la página de recursos de OWASP en octubre. Los lectores deben distinguir la actividad previa relacionada con borradores de la fecha asociada a la versión oficial actual. Ninguna de las dos fechas establece cuándo una organización concreta adoptó la metodología.

La pregunta escéptica se refiere a la implementación. Un informe puede emplear encabezados coherentes mientras documenta experimentos poco sólidos. Una evaluación extensa puede omitir la herramienta más relevante. Un entorno de pruebas puede parecerse visualmente a producción mientras utiliza permisos distintos. La estructura formal facilita describir estas limitaciones, pero no las elimina automáticamente.

También existe un desafío de medición. El resultado de una prueba depende de qué se considere éxito o fracaso. Que un asistente mencione información confidencial difiere de recuperarla, mostrarla o transmitirla externamente. Agrupar esos eventos bajo una etiqueta imprecisa de «filtración» dificulta interpretar el resultado.

Las comparaciones entre productos afrontan el mismo problema. Un sistema con amplias facultades puede exponer vías de fallo más relevantes que un asistente con restricciones estrictas. Un recuento bruto de ataques exitosos no explica si los productos afrontaron tareas, accesos o condiciones comparables. El alcance debe acompañar al resultado.

Las pruebas automatizadas introducen otra fuente de incertidumbre. Un modelo utilizado para juzgar el comportamiento de otro modelo puede malinterpretar la tarea o clasificar erróneamente un resultado. Eso no vuelve inútil la evaluación automatizada. Significa que el proceso de evaluación necesita escrutinio, especialmente cuando los resultados afectan decisiones de lanzamiento.

La distinción entre seguridad y utilidad también importa aquí. Un asistente que rechaza todas las solicitudes puede parecer resistente al uso indebido mientras fracasa en su tarea prevista. Una evaluación significativa debe preservar el desempeño en tareas legítimas junto con los límites que se supone debe aplicar. De lo contrario, una mejora aparente puede ocultar una pérdida de funcionalidad.

Estos son límites analíticos, no evidencia de que el manual falle. Ninguna metodología puede transformar un ejercicio acotado en una prueba sobre todas las interacciones futuras. La conclusión defendible identifica las condiciones probadas, los resultados observados y la incertidumbre restante.

Por tanto, la publicación debería elevar las expectativas de evidencia sin fomentar garantías generales. «Evaluado siguiendo la guía de OWASP» describe un enfoque. Los compradores aún necesitan entender qué ocurrió durante la evaluación y qué hallazgos recibieron correcciones verificadas.

Los presupuestos de pruebas deben cubrir todo el flujo de trabajo

La parte exigente de unas pruebas de IA más amplias consiste en coordinar a las personas y los sistemas que controlan el flujo de trabajo.

Un ejercicio centrado en prompts a menudo puede comenzar con acceso a una interfaz conversacional. Una evaluación de flujos de trabajo requiere más contexto. Los evaluadores deben comprender la tarea prevista de la aplicación, la información a la que puede acceder y los efectos que pueden producir sus herramientas. Obtener esa comprensión consume esfuerzo organizativo antes de que comience un ataque.

Ese coste forma parte de la disyuntiva de seguridad. Un alcance más amplio respalda conclusiones que se ajustan mejor a un producto desplegado. Un alcance más limitado reduce el trabajo necesario, pero limita lo que el informe resultante puede establecer. Ninguna de las dos opciones debería desaparecer tras una declaración genérica de que las pruebas están completas.

La diferencia también afecta la remediación. Si una debilidad se origina en una cuenta de servicio con permisos excesivamente amplios, cambiar las instrucciones del modelo podría dejar intacta la autoridad subyacente. Si el problema implica un acceso legítimo utilizado con un fin no previsto, eliminar todo acceso podría impedir que el producto cumpla su función. Ingeniería necesita un diagnóstico suficientemente específico como para respaldar una solución útil.

La titularidad puede convertirse en el obstáculo central. Un equipo de modelos controla la configuración, un equipo de aplicaciones controla la orquestación y un equipo de identidad controla los permisos. Una unidad de negocio es propietaria del flujo de trabajo afectado. Un hallazgo que cruza esos límites requiere decidir quién cambia qué.

Un asistente documental ilustrativo muestra cómo se desarrolla esto. El producto recupera archivos internos y prepara un resumen externo. Una prueba descubre que contenido restringido entra en el borrador. La medida correctiva podría implicar permisos de recuperación, comprobaciones de destinatarios, clasificación de documentos o el paso de aprobación del flujo de trabajo. Esas soluciones abordan causas diferentes.

Un resultado útil explicaría qué límite falló y si la solución elegida detuvo la vía observada. Limitarse a añadir una redacción más firme a las instrucciones del asistente ofrecería evidencia más débil, salvo que el fallo subyacente estuviera relacionado con la gestión de instrucciones. La reparación debe seguir el mecanismo demostrado.

Las herramientas disponibles respaldan distintas partes de ese trabajo. La guía de pruebas de aplicaciones de OWASP incluye garak de NVIDIA para el análisis de vulnerabilidades de modelos y PyRIT de Microsoft para orquestar interacciones adversarias. Estas herramientas respaldan actividades de prueba, mientras que una metodología de encargo organiza el alcance, la interpretación y el seguimiento. Sus funciones se solapan sin ser intercambiables.

Por tanto, las comparaciones de herramientas deberían centrarse en la cobertura, no en la preferencia de marca. Un escáner que genera entradas variadas no puede establecer automáticamente si un registro empresarial cambió de forma adecuada. Un marco de orquestación no puede decidir los límites de autoridad aceptables para una organización sin una tarea y una política definidas.

El énfasis del manual en la reproducibilidad y la integración defensiva apunta hacia un resultado operativo: hallazgos que los equipos de ingeniería y seguridad pueden utilizar. El valor empresarial depende de esa transferencia. Descubrir una respuesta inusual es menos útil cuando nadie puede reproducir sus consecuencias ni verificar la reparación.

Observe la evidencia de adopción hasta enero

La señal más sólida será la evidencia pública de que las organizaciones modificaron el alcance de sus evaluaciones y verificaron correcciones tras usar el manual.

La primera señal que se debe observar es la calidad de los casos de estudio publicados. Hasta enero de 2027, los relatos útiles describirían la aplicación evaluada, sus capacidades conectadas y los límites excluidos de la evaluación. Un respaldo o un anuncio de descarga establece interés. Un encargo documentado revela cómo funciona la metodología bajo restricciones reales.

Estos relatos reforzarían el argumento a favor del manual si vinculan una debilidad descubierta con un cambio correctivo específico. Debilitarían las afirmaciones más amplias si solo informan de respuestas inusuales del modelo y dejan sin explorar las consecuencias para la aplicación. La distinción se deriva del alcance declarado de la publicación.

La siguiente señal es cómo los proveedores describen la cobertura en sus ofertas de evaluación. La iniciativa de red teaming de OWASP ya presenta el manual junto a recursos de evaluación y selección de proveedores. Eso crea un punto de referencia para examinar qué incluye un servicio. Los compradores deberían buscar descripciones más claras de las herramientas, el acceso a los datos y el comportamiento de los agentes cubiertos.

Una presentación de informes más específica respaldaría la idea de que una guía compartida mejora la comparabilidad. Las afirmaciones amplias de alineación con OWASP sin un alcance documentado ofrecerían evidencia más débil. El cambio significativo aparecería en los entregables y las expectativas contractuales, en lugar de en una nueva insignia en la página de un proveedor.

La señal final es qué ocurre después de la remediación. Los resultados de seguimiento publicados mostrarían si una organización volvió a probar el fallo original y examinó vías relacionadas. Un relato que se detiene en el descubrimiento deja sin respuesta la pregunta operativa central: ¿el producto se volvió más seguro mientras conservaba su función prevista?

Estos son criterios de observación, no compromisos anunciados por OWASP o los proveedores participantes. Aún no existen cifras verificadas de adopción ni mediciones de reducción de incidentes que establezcan el impacto del manual. La publicación proporciona un marco para investigar ese impacto, mientras que la evidencia de implementación debe venir después.

Para los desarrolladores, la implicación inmediata es conectar los resultados de las pruebas con la configuración que los clientes realmente utilizan. Para los compradores empresariales, consiste en distinguir las garantías sobre el modelo de la evidencia del despliegue. Para los usuarios, la preocupación práctica sigue siendo si un asistente respeta los límites que rodean su información y sus acciones.

Lea el manual de red teaming de GenAI de OWASP junto con la evidencia de evaluación de los sistemas de IA que su organización realmente despliega. Pida al responsable del producto que explique qué flujos de trabajo se probaron y qué permisos quedaron fuera de alcance. Revise si el informe distingue entre acciones intentadas y efectos completados. Compruebe si ingeniería verificó las correcciones frente al fallo original. Esas preguntas mantienen la conversación vinculada al comportamiento observable, en lugar de a una etiqueta de marco. También revelan dónde un resumen seguro de sí mismo se apoya en un experimento limitado. Antes de conceder a un asistente un acceso más amplio, solicite evidencia que cubra la autoridad añadida. ¿La evaluación más reciente describe el producto que usan los empleados o solo el modelo que hay debajo?