Cómo formar un equipo rojo con un modelo de IA generativa

En los últimos meses, los gobiernos de todo el mundo han empezado a converger en torno a una solución para gestionar los riesgos de la IA generativa: el red teaming. A finales de octubre, la administración Biden hizo pública su arrolladora orden ejecutiva sobre la IA. Entre sus requisitos más importantes está que ciertos modelos de IA generativa de alto riesgo se sometan a un "red teaming", que define vagamente como "un esfuerzo de prueba estructurado para encontrar fallos y vulnerabilidades en un sistema de IA". Esto se produjo unos meses después de que la administración organizara un evento formal de "red teaming" de IA que atrajo a miles de hackers. El enfoque en el red teaming es un desarrollo positivo. El red teaming es una de las formas más eficaces de descubrir y gestionar los riesgos de la IA generativa. Sin embargo, hay una serie de obstáculos importantes para aplicar el red teaming en la práctica, como aclarar qué constituye realmente un equipo rojo, estandarizar lo que hace ese equipo mientras prueba el modelo y especificar cómo se codifican y difunden los hallazgos una vez finalizadas las pruebas. Cada modelo tiene una superficie de ataque, vulnerabilidades y entornos de despliegue diferentes, lo que significa que no habrá dos esfuerzos de red teaming exactamente iguales. Por esa razón, la creación de equipos rojos coherentes y transparentes se ha convertido en un reto central en el despliegue de la IA generativa, tanto para los proveedores que desarrollan modelos fundacionales como para las empresas que afinan y ponen en uso esos modelos. Este artículo pretende abordar estos obstáculos y resumir mi experiencia en el red teaming de varios sistemas diferentes de IA generativa. Mi bufete, Luminos.Law, formado conjuntamente por abogados y científicos de datos, se centra exclusivamente en la gestión de los riesgos de la IA. Tras haber sido contratados para red teamizar algunos de los modelos de IA generativa de más alto perfil y ampliamente adoptados, hemos descubierto lo que funciona y lo que no a la hora de red teamizar la IA generativa. Esto es lo que hemos aprendido. ¿Qué es la IA generativa "red teaming"? A pesar del creciente entusiasmo que suscita esta actividad, no existe un consenso claro sobre lo que significa en la práctica la IA generativa "red teaming". Esto es así a pesar de que algunas de las mayores empresas tecnológicas han empezado a adoptar públicamente el método como componente central para crear una IA generativa digna de confianza. El término en sí se popularizó durante la Guerra Fría y empezó a integrarse formalmente en los esfuerzos de planificación bélica del Departamento de Defensa estadounidense. En los ejercicios de simulación, a los llamados equipos rojos se les encargaba actuar como el adversario soviético (de ahí el término "rojo"), mientras que a los equipos azules se les encargaba actuar como Estados Unidos o sus aliados. A medida que los esfuerzos de seguridad de la información fueron madurando con los años, la comunidad de ciberseguridad adoptó el mismo lenguaje, aplicando el concepto de red teaming a las pruebas de seguridad de los sistemas de software tradicionales. El red teaming de la IA generativa es muy diferente del red teaming de otros sistemas de software, incluidos otros tipos de IA. A diferencia de otros sistemas de IA, que suelen utilizarse para tomar una decisión -como a quién contratar o qué calificación crediticia debe tener alguien-, los sistemas de IA generativa producen contenido para sus usuarios. La interacción de cualquier usuario con un sistema de IA generativa puede crear un enorme volumen de texto, imágenes o audio. Los daños que crean los sistemas de IA generativa son, en muchos casos, diferentes a los de otras formas de IA tanto en alcance como en escala. La IA generativa de los equipos rojos está diseñada específicamente para generar contenidos dañinos que no tienen un análogo claro en los sistemas de software tradicionales: desde generar estereotipos degradantes e imágenes gráficas hasta mentir descaradamente. De hecho, los daños que los equipos rojos tratan de generar se asocian más comúnmente con los humanos que con el software. En la práctica, esto significa que las formas en que los equipos rojos interactúan con los propios sistemas de IA generativa son únicas: Deben centrarse en generar prompt maliciosos, o entradas en el modelo, además de pruebas con código más tradicional para comprobar la capacidad del sistema de producir comportamientos dañinos o inapropiados. Hay todo tipo de formas de generar este tipo de prompts maliciosos, desde cambiar sutilmente los prompt hasta simplemente presionar al modelo para que genere salidas problemáticas. La lista de formas de atacar eficazmente a la IA generativa es larga y crece día a día. ¿Quién debe formar parte del equipo rojo de la IA? Al igual que la propia definición de equipo rojo, no existe un consenso claro sobre cómo debe construirse cada equipo rojo. Por eso, una de las primeras cuestiones que deben abordar las empresas es si el equipo rojo debe ser interno a la empresa o externo. Las empresas, como Google, que han creado sus propios equipos rojos de IA abogan ahora por equipos rojos internos, en los que empleados con diversos tipos de conocimientos simulan ataques al modelo de IA. Otras, como OpenAI, han adoptado el concepto de equipos rojos externos, llegando incluso a crear una red externa para animar a los miembros externos a unirse. Determinar cómo deben constituirse los equipos rojos de IA es una de las tareas que la administración Biden ha encomendado a los jefes de las agencias federales, que están en la obligación de responder a la pregunta el año que viene en un próximo informe. Entonces, ¿qué les decimos a nuestros clientes? Para empezar, no existe un enfoque único para crear equipos rojos de IA generativa. He aquí algunas directrices generales. Debido a la enorme escala de los sistemas de IA que muchas empresas están adoptando, crear equipos rojos completos para cada uno de ellos sería imposible. Por esa razón, la clave para un red teaming eficaz reside en clasificar cada sistema en función del riesgo. Decimos a nuestros clientes que asignen diferentes niveles de riesgo a los distintos modelos, basándose, por ejemplo, en la probabilidad de que se produzca el daño, la gravedad del daño si se produce o la capacidad de rectificar el daño una vez detectado. (Éstas son métricas comúnmente aceptadas para definir el riesgo.) Los diferentes niveles de riesgo pueden utilizarse entonces para guiar la intensidad de cada esfuerzo de los equipos rojos: el tamaño del equipo rojo, por ejemplo, o el grado en que se prueba el sistema, o incluso si se prueba en absoluto. Siguiendo este enfoque, los modelos de menor riesgo deberían someterse a pruebas menos exhaustivas. Otros modelos podrían requerir pruebas internas pero ninguna revisión por parte de expertos externos, mientras que los sistemas de mayor riesgo suelen requerir equipos rojos externos. Es probable que las partes externas centradas en el red teaming de IA generativa tengan mayores niveles de experiencia en red teaming y, por lo tanto, podrán desenterrar más vulnerabilidades. Las revisiones externas pueden demostrar un nivel de cuidado razonable y reducir también la responsabilidad al documentar que partes externas han dado su visto bueno al sistema de IA generativa. Objetivos de degradación Comprender qué daños deben perseguir los equipos rojos es extremadamente importante. Seleccionamos lo que llamamos "objetivos de degradación" para guiar nuestros esfuerzos, y comenzamos nuestros equipos rojos evaluando qué tipos de comportamiento dañino del modelo generarán la mayor responsabilidad. Los objetivos de degradación son tan críticos porque, a menos que estén claramente definidos y asignados a los pasivos más significativos que plantea cada sistema, el red teaming es casi siempre infructuoso o, en el mejor de los casos, incompleto. De hecho, sin una organización adecuada, el red teaming se lleva a cabo con demasiada frecuencia sin un plan coordinado para generar daños específicos, lo que conduce a ataques al sistema y a la ausencia de conclusiones estratégicas claras y procesables. Aunque este tipo de red teaming puede crear la apariencia de pruebas exhaustivas, un sondeo desorganizado de este tipo puede ser contraproducente, ya que crea la impresión de que el sistema se ha probado por completo cuando siguen existiendo importantes lagunas. Junto con una evaluación clara de los riesgos y las responsabilidades, también es una buena práctica alinear los objetivos de degradación con los incidentes conocidos de sistemas similares de IA generativa. Aunque existen diversas formas de rastrear y comparar incidentes pasados, la base de datos de incidentes de IA es un gran recurso (y uno en el que confiamos mucho). He aquí algunos objetivos de degradación comunes de nuestros anteriores esfuerzos de red teaming: Ayudar a los usuarios a realizar actividades ilícitas Los usuarios pueden aprovecharse de los sistemas de IA generativa para ayudar a llevar a cabo una serie de actividades perjudiciales y, en muchos casos, generar una responsabilidad significativa para las empresas que despliegan el sistema de IA en el proceso. Si no existen suficientes salvaguardas contra este tipo de comportamiento del modelo, las empresas pueden acabar compartiendo la responsabilidad del daño final. En el pasado, hemos comprobado daños que van desde instrucciones para la fabricación de armas y fármacos hasta la realización de una contabilidad fraudulenta o que el modelo lleve a cabo campañas automatizadas de piratería informática. Sesgo en el modelo La IA en general puede generar o perpetuar todo tipo de sesgos, como ya he escrito aquí antes, lo que, a su vez, puede dar lugar a muchos tipos diferentes de responsabilidades en virtud de la legislación contra la discriminación. La Comisión Federal de Comercio de EE.UU. ha dedicado mucha atención a la cuestión de la injusticia en la IA en los últimos años, al igual que los legisladores, lo que indica que se avecinan más responsabilidades en este ámbito. Los sesgos pueden surgir en los resultados del modelo, como la representación injusta de diferentes grupos demográficos en los contenidos generados por la IA, así como en el propio rendimiento del modelo, como un rendimiento diferente para los miembros de diferentes grupos (hablantes nativos de inglés frente a hablantes no nativos, por ejemplo). Toxicidad La toxicidad en la IA generativa surge con la creación de contenidos ofensivos o inapropiados. Este problema tiene una larga historia en la IA generativa, como cuando el chatbot Tay comenzó de forma infame a generar públicamente resultados racistas y sexistas. Dado que los modelos de IA generativa se conforman a partir de grandes cantidades de datos extraídos de Internet -un lugar no conocido por su decoro-, el contenido tóxico plaga muchos sistemas de IA generativa. De hecho, la toxicidad es un problema tan grave que ha dado lugar a todo un nuevo campo de estudio en la investigación de la IA conocido como "desintoxicación". Daños a la privacidad Hay un sinfín de formas en las que los modelos de IA generativa pueden crear daños a la privacidad. A veces, la información de identificación personal está contenida en los propios datos de entrenamiento, que pueden ser pirateados por usuarios adversarios. Otras veces, el modelo puede filtrar involuntariamente información sensible de otros usuarios, como ocurrió con el chatbot surcoreano Lee Luda. Los modelos de IA generativa podrían incluso violar directamente las políticas de privacidad de las empresas, como decir falsamente a los usuarios que tienen un acceso limitado a sus datos y cometer así un fraude. La lista de objetivos de degradación suele ser larga, y va desde los objetivos señalados hasta daños como la infracción de la propiedad intelectual, las violaciones contractuales y mucho más. A medida que los sistemas de IA generativa se desplieguen en un número creciente de entornos, desde el sanitario hasta el jurídico y el financiero, es probable que esa lista se amplíe. Ataques a la IA generativa Una vez que hemos determinado la composición del equipo rojo, las responsabilidades y los objetivos de degradación asociados para guiar las pruebas, empieza la parte divertida: atacar el modelo. Hay una gran variedad de métodos que los equipos rojos pueden utilizar. En Luminos.Law, dividimos nuestros planes de ataque en dos categorías: manuales y automatizados. Aquí nos centraremos principalmente en los ataques manuales, pero vale la pena señalar que un gran cuerpo de investigación y herramientas emergentes hacen que los ataques automatizados sean una parte cada vez más importante de los equipos rojos. También existen muchos conjuntos de datos de código abierto que pueden utilizarse para probar estos sistemas.(Aquí hay un documento que ofrece una visión general de muchos de estos conjuntos de datos). Una estrategia de ataque eficaz implica asignar a cada objetivo los ataques que pensamos que tienen más probabilidades de éxito, así como los vectores de ataque a través de los cuales planeamos probar el sistema. Los vectores de ataque pueden ser "directos", consistentes en interacciones directas y relativamente breves con el modelo, mientras que otros implican ataques más complejos denominados inyección prompt indirecta, en los que el código o las instrucciones maliciosas pueden estar contenidos en sitios web u otros archivos a los que el sistema pueda tener acceso. Aunque la siguiente lista no incluye todas las técnicas que utilizamos, sí ofrece una muestra de cómo nos gusta enfocar los ataques durante el red teaming: Inyección de código. Utilizamos código informático, o prompt de entrada que se asemejan a código informático, para conseguir que el modelo genere salidas dañinas. Este método es uno de nuestros favoritos precisamente porque tiene una tasa de éxito sorprendentemente alta, como demostró recientemente un grupo de investigadores. Agotamiento del contenido. Utilizamos grandes volúmenes de información para abrumar al modelo. Hipótesis. Instruimos al modelo para que cree una salida basada en instrucciones hipotéticas que, de otro modo, activarían los controles de contenido. Pros y contras. Preguntamos sobre los pros y los contras de temas controvertidos para generar respuestas perjudiciales. Juegos de rol. Dirigimos al modelo para que asuma el papel de una entidad típicamente asociada con declaraciones negativas o controvertidas y luego incitamos al modelo a crear contenidos dañinos. Existen, por supuesto, docenas de estrategias de ataque para los sistemas de IA generativa, muchas de las cuales, de hecho, existen desde hace años. La metodología de ataque crowdsourcing, siempre que sea posible, es también una de las mejores prácticas a la hora de formar equipos rojos, y hay una serie de recursos en línea diferentes que los formadores de equipos rojos pueden utilizar para inspirarse, como repositorios específicos de Github donde los probadores perfeccionan y comparten ataques exitosos. La clave de una prueba eficaz reside en asignar cada estrategia al objetivo de degradación, al vector de ataque y, por supuesto, en tomar copiosas notas para poder capturar y estudiar posteriormente los ataques exitosos. Ponerlo todo junto La creación de equipos rojos para la IA generativa es complicada, ya que suele implicar a diferentes equipos, plazos que compiten entre sí y muchos tipos de conocimientos diferentes. Pero las dificultades a las que se enfrentan las empresas no sólo están relacionadas con la formación del equipo rojo, la alineación en las responsabilidades clave, la formulación de objetivos de degradación claros y la aplicación de las estrategias de ataque adecuadas. Vemos un puñado de otras cuestiones que a menudo hacen tropezar a las empresas. Documentación El éxito del equipo rojo implica a menudo probar cientos de estrategias de ataque. Si se utilizan ataques automatizados, ese número puede ascender a miles. Con tantas variables, estrategias de prueba, miembros del equipo rojo y demás, puede resultar difícil hacer un seguimiento de la información que se genera y garantizar que los resultados de las pruebas sean digeribles. Disponer de una orientación clara no sólo sobre cómo realizar las pruebas, sino también sobre cómo documentar cada una de ellas, es una parte fundamental, aunque a menudo pasada por alto, del proceso de formación de equipos rojos. Aunque cada organización y equipo rojo es diferente, resolvimos este problema para nuestro bufete de abogados creando nuestras propias plantillas personalizadas para guiar nuestras pruebas y presentar nuestro análisis final a nuestros clientes. Saber que la documentación final se alinea con la información capturada durante las pruebas en tiempo real hace que el proceso de red teaming sea significativamente más eficiente. Privilegio legal Con tanta información sensible que se genera entre los probadores y los equipos, entender dónde y cuándo hacer valer el privilegio legal es otra consideración a menudo pasada por alto pero de gran importancia. A menudo vemos cómo se discuten abiertamente posibles responsabilidades en lugares como Slack, lo que hace que esa información sea descubrible para las partes adversarias si se produce una supervisión externa, como una investigación reguladora o una demanda. Lo último que quieren las empresas es aumentar sus riesgos porque estaban red teaming sus modelos. Involucrar a los abogados y determinar cuidadosamente dónde y cómo se puede comunicar la información sobre los resultados de las pruebas es una consideración clave. Qué hacer con las vulnerabilidades Disponer de planes claros para abordar las vulnerabilidades que los esfuerzos de red teaming descubren es otra parte central, pero a menudo pasada por alto, del proceso de red teaming. ¿Quién de los equipos de producto o de ciencia de datos es responsable de tomar medidas? ¿Se reúnen con el equipo rojo directamente o a través de un intermediario? ¿Intentan parchear las vulnerabilidades mientras se produce el red teaming o deben esperar hasta el final del proceso? Estas preguntas, y muchas más, deben abordarse antes de que se produzca el red teaming; de lo contrario, es probable que la detección de vulnerabilidades en el modelo genere mucha confusión. Este artículo ofrece sólo una visión general de alto nivel de todas las consideraciones que intervienen para que la IA generativa red teaming tenga éxito. Es una de las formas más eficaces de gestionar los complejos riesgos de la tecnología y, por ese motivo, los gobiernos apenas están empezando a darse cuenta de los beneficios del red teaming. Las empresas que apuestan fuerte por la IA generativa deberían comprometerse igualmente con el red teaming.

Cómo formar un equipo rojo con un modelo de IA generativa

Resumen.

Partner Center