Capítulo 01
Por qué el red-teaming de IA es diferente
Las pruebas de seguridad de software tradicionales operan sobre una premisa relativamente clara. Hay una base de código, hay comportamientos definidos, y el trabajo del tester es encontrar entradas que hagan que el software se desvíe de esos comportamientos definidos de maneras que creen riesgo.
El red-teaming de un sistema de IA es diferente de una manera que lleva tiempo interiorizar completamente. El comportamiento del sistema no está completamente definido. Los resultados de un modelo de lenguaje grande no están determinados por un conjunto fijo de rutas de código, sino por la interacción entre su entrenamiento, su contexto y la entrada que recibe. Esto significa que la superficie de ataque no es un conjunto de funciones o puntos de acceso de API. Es efectivamente todo el espacio de posibles entradas en lenguaje natural, que es vasto.
Esta diferencia tiene consecuencias prácticas. No puedes enumerar todas las formas en que un modelo de lenguaje podría fallar de la misma manera que puedes enumerar las rutas de código en una aplicación tradicional. Lo que puedes hacer es desarrollar una metodología sistemática para explorar las partes más peligrosas de ese espacio y construir confianza en que las áreas que más te importan son razonablemente seguras.
El red-teaming de IA también implica una relación diferente entre el tester y el objetivo. En las pruebas de penetración tradicionales, el tester intenta encontrar errores en la implementación. En el red-teaming de LLM, el modelo en sí mismo se comporta como fue diseñado. Los fallos que encuentras a menudo no son errores en el sentido de ingeniería. Son casos donde el diseño, el entrenamiento o la configuración de despliegue del modelo produce resultados dañinos, engañosos o contrarios a la política.