Cómo hacer pruebas de “Red Team” a un modelo de IA generativaRed teaming

Entorno e Innovación

El red teaming es “un esfuerzo de prueba estructurado para encontrar fallas y vulnerabilidades en un sistema de inteligencia artificial”.

E

n los últimos meses, los gobiernos de todo el mundo han comenzado a converger en torno a una solución para gestionar los riesgos de la IA generativa: el red teaming (equipo rojo). La Administración Biden define vagamente el red teaming como “un esfuerzo de prueba estructurado para encontrar fallas y vulnerabilidades en un sistema de inteligencia artificial”.

Centrarse en el red teaming es un avance positivo. Es una de las formas más efectivas de descubrir y gestionar los riesgos de la IA generativa.

Mi bufete de abogados, Luminos.Law, formado conjuntamente por abogados y científicos de datos, se enfoca exclusivamente en la gestión de riesgos de la IA. Tras haber sido contratados para realizar el red teaming de algunos de los modelos de IA generativa más conocidos y adoptados, hemos descubierto lo que funciona (y lo que no) cuando se combina (el red teaming) con IA generativa. Esto es lo que hemos aprendido.

¿Qué es el red teaming de la IA generativa?

El red teaming de la IA generativa es muy diferente al 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 una persona), los sistemas de IA generativa producen contenido para sus usuarios.

En la práctica, esto significa que las formas en que los equipos rojos interactúan con los sistemas de IA generativa son únicas: Deben centrarse en generar indicaciones maliciosas, o entradas en el modelo, además de realizar pruebas utilizando código más tradicional para evaluar la capacidad del sistema para producir comportamientos perjudiciales o inapropiados.

¿Quién debería formar el red teaming de la IA?

Debido a la gran escala de los sistemas de IA que muchas empresas están adoptando, sería imposible realizar un red teaming completo de cada uno de ellos. Por ello, les 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 ocurre, o la capacidad de rectificar el daño una vez detectado. Los diferentes niveles de riesgo pueden guiar la intensidad de cada esfuerzo de red teaming: el tamaño del equipo, por ejemplo, o el grado en que se prueba el sistema, o incluso si se prueba en absoluto.

Objetivos de degradación

Es muy importante comprender cuáles son los perjuicios que deben perseguir los equipos rojos. Seleccionamos lo que llamamos “objetivos de degradación” para guiar nuestros esfuerzos, y comenzamos nuestra labor de red teaming evaluando qué tipos de comportamiento perjudicial del modelo generarán la mayor responsabilidad.

He aquí algunos objetivos de degradación comunes de nuestros esfuerzos pasados de red teaming:

Ayudar a los usuarios a participar en actividades ilícitas

Los usuarios pueden aprovechar los sistemas de IA generativa para llevar a cabo una variedad de actividades perjudiciales. Si no existen salvaguardas suficientes contra este tipo de comportamiento, las empresas pueden terminar compartiendo la responsabilidad del daño final.

Sesgo en el modelo

En general, la IA puede generar o perpetuar todo tipo de sesgos. Los sesgos pueden surgir en los resultados del modelo, como la representación injusta de diferentes grupos demográficos en el contenido generado por la IA, así como en el rendimiento del modelo en sí, como la diferencia de rendimiento entre miembros de diferentes grupos.

Toxicidad

La toxicidad en la IA generativa surge con la creación de contenido ofensivo o inapropiado. Dado que los modelos de IA generativa están formados por grandes cantidades de datos extraídos de Internet, el contenido tóxico plaga muchos sistemas de IA generativa.

Daños a la privacidad

Hay muchas formas en que los modelos de IA generativa pueden causar daños a la privacidad. A veces, los propios datos de entrenamiento contienen información de identificación personal. En otras ocasiones, el modelo puede filtrar involuntariamente información confidencial de otros usuarios.

La lista de objetivos de degradación suele ser larga, y abarca desde los objetivos descritos anteriormente hasta perjuicios como la infracción de la propiedad intelectual, violaciones contractuales y mucho más.

Ataques a la IA generativa

Una vez que hemos determinado la composición del red teaming, las responsabilidades y los objetivos de degradación asociados para guiar las pruebas, comienza la parte divertida: atacar el modelo.

Una estrategia de ataque efectiva implica asignar cada objetivo a los ataques que creemos que tienen más probabilidades de tener éxito, así como a los vectores de ataque a través de los cuales planeamos probar el sistema.

Si bien la siguiente lista no incluye todas las técnicas que utilizamos, sí ofrece una muestra de cómo nos gusta abordar los ataques durante el red teaming:

Inyección de código. Utilizamos código informático, o indicaciones de entrada que se asemejan al código informático, para que el modelo genere resultados perjudiciales.

Agotamiento de contenido. Empleamos grandes volúmenes de información para abrumar al modelo.

Hipotéticos. Damos instrucciones al modelo para que cree resultados basados ​​en instrucciones hipotéticas que, de otro modo, activarían los controles de contenido.

Pros y contras. Preguntamos sobre los pros y contras de temas controvertidos para generar respuestas perjudiciales.

Juego de roles. Dirigimos al modelo para que asuma el papel de una entidad típicamente asociada con declaraciones negativas o controvertidas y, a continuación, lo incitamos a crear contenido perjudicial.

Por supuesto, existen docenas de estrategias de ataque para los sistemas de IA generativa. La clave para realizar pruebas efectivas radica en asignar cada estrategia al objetivo de degradación, al vector de ataque y, por supuesto, en tomar notas para que los ataques exitosos puedan ser capturados y estudiados posteriormente.

Unirlo todo

El red teaming de la IA generativa es complicado, pero las dificultades que enfrentan las empresas no solo están relacionadas con la creación de equipos, la alineación de las vulnerabilidades clave, la definición de objetivos de degradación claros y la implementación de las estrategias de ataque adecuadas. También observamos algunos otros problemas que a menudo hacen tropezar a las empresas:

Documentación

Un red teaming exitoso a menudo implica probar cientos de estrategias de ataque. Si se utilizan ataques automatizados, esa cifra puede ascender a miles. Con tantas variables, estrategias de prueba, miembros del equipo y más, puede resultar difícil realizar un seguimiento de la información que se genera, y garantizar que los resultados de las pruebas sean comprensibles. Disponer de una orientación clara, no solo sobre cómo realizar las pruebas, sino también sobre cómo documentar cada una de ellas, es una parte crítica, pero que a menudo se pasa por alto durante el proceso de red teaming.

Privilegio legal

Con tanta información sensible que se genera entre los evaluadores y los equipos, comprender dónde y cuándo hacer valer el privilegio legal es otra consideración importante que a menudo se pasa por alto. A menudo vemos que las posibles responsabilidades se discuten abiertamente en lugares como Slack, lo que hace que esa información sea accesible para las partes adversarias si se produce una supervisión externa, como una investigación regulatoria o una demanda.

Qué hacer ante las vulnerabilidades

Tener planes claros para abordar las vulnerabilidades descubiertas por los esfuerzos de red teaming es otra parte central, pero a menudo pasada por alto, del proceso. ¿Quién, en los equipos de productos o de ciencia de datos, es responsable de tomar acción? ¿Se reúnen directamente con el equipo o a través de un intermediario? ¿Intentan reparar las vulnerabilidades mientras se lleva a cabo el red teaming o deben esperar hasta el final del proceso?

Estas cuestiones, y muchas más, deben abordarse antes de que se produzca el red teaming; de lo contrario, la detección de vulnerabilidades en el modelo probablemente generará mucha confusión.

Este artículo solo proporciona una visión general de alto nivel de todas las consideraciones que intervienen para que el red teaming de la IA generativa sea exitoso. Es una de las formas más efectivas de gestionar los riesgos complejos de la tecnología. Las empresas que apuestan por la IA generativa deberían estar igualmente comprometidas con el red teaming.

© 2024 Harvard Business School Publishing Corp. | De: hbr.org  |  Distribuido por: The New York Times Syndicate.

Artículo en inglés

In recent months governments around the world have begun to converge around one solution to managing the risks of generative AI: red teaming. The Biden Administration loosely defines red teaming as “a structured testing effort to find flaws and vulnerabilities in an AI system.”

The focus on red teaming is a positive development. Red teaming is one of the most effective ways to discover and manage generative AI’s risks.

My law firm, Luminos.Law, which is jointly made up of lawyers and data scientists, is focused exclusively on managing AI risks. After being retained to red team some of the highest profile and widely adopted generative AI models, we’ve discovered what works and what doesn’t when red teaming generative AI. Here’s what we’ve learned.

WHAT IS RED TEAMING GENERATIVE AI?

Red teaming generative AI is much different from red teaming other software systems, including other kinds of AI. Unlike other AI systems, which are typically used to render a decision — such as whom to hire or what credit rating someone should have — generative AI systems produce content for their users.

In practice, this means that the ways that red teams interact with generative AI systems itself are unique: They must focus on generating malicious prompts, or inputs into the model, in addition to tests using more traditional code in order to test the system’s ability to produce harmful or inappropriate behavior.

WHO SHOULD RED TEAM THE AI?

Due to the sheer scale of the AI systems many companies are adopting, fully red teaming each one would be impossible. We tell our clients to assign different risk levels to different models — based, for example, on the likelihood of the harm occurring, the severity of the harm if it does occur, or the ability to rectify the harm once it is detected. Different risk levels can then be used to guide the intensity of each red teaming effort: the size of the red team, for example, or the degree to which the system is tested, or even if it’s tested at all.

DEGRADATION OBJECTIVES

Understanding what harms red teams should target is extremely important. We select what we call “degradation objectives” to guide our efforts, and we start our red teaming by assessing which types of harmful model behavior will generate the greatest liability.

Here are a few common degradation objectives from our past red teaming efforts:

HELPING USERS ENGAGE IN ILLICIT ACTIVITIES

Users can take advantage of generative AI systems to help conduct a range of harmful activities. If sufficient safeguards against this type of model behavior are not in place, companies may end up sharing responsibility for the ultimate harm.

BIAS IN THE MODEL

AI in general can generate or perpetuate all sorts of bias. Biases can arise in model output, such as unfairly representing different demographic groups in content generated by the AI, as well as in model performance itself, such as performing differently for members of different groups.

TOXICITY

Toxicity in generative AI arises with the creation of offensive or inappropriate content. Because generative AI models are shaped by vast amounts of data scraped from the internet, toxic content plagues many generative AI systems.

PRIVACY HARMS

There are a host of ways that generative AI models can create privacy harms. Sometimes personally identifying information is contained in the training data itself. Other times, sensitive information from other users might be leaked by the model unintentionally.

The list of degradation objectives is often long, ranging from the objectives outlined above to harms like intellectual property infringement, contractual violations and much more.

ATTACKS ON GENERATIVE AI

Once we’ve determined the composition of the red team, the liabilities and associated degradation objectives to guide testing, the fun part begins: attacking the model.

An effective attack strategy involves mapping each objective to the attacks we think are most likely to be successful, as well as the attack vectors through which we plan to test the system.

While the following list doesn’t include all the techniques we use, it does give a sample of how we like to approach attacks during red teaming:

CODE INJECTION. We use computer code, or input prompts that resemble computer code, to get the model to generate harmful outputs.

CONTENT EXHAUSTION. We use large volumes of information to overwhelm the model.

HYPOTHETICALS. We instruct the model to create output based on hypothetical instructions that would otherwise trigger content controls.

PROS AND CONS. We ask about the pros and cons of controversial topics to generate harmful responses.

ROLE PLAYING. We direct the model to assume the role of an entity typically associated with negative or controversial statements and then goad the model into creating harmful content.

There are, of course, dozens of attack strategies for generative AI systems. The key to effective testing lies in mapping each strategy to the degradation objective, attack vector, and, of course, taking copious notes so that successful attacks can be captured and studied later.

PUTTING IT ALL TOGETHER

Red teaming generative AI is complicated, but the difficulties companies encounter are not just related to putting together the red team, aligning on key liabilities, coming up with clear degradation objectives and implementing the right attack strategies. We see a handful of other issues that often trip companies up.

DOCUMENTATION

Successful red teaming oftentimes involves testing hundreds of attack strategies. If automated attacks are used, that number can be in the thousands. With so many variables, testing strategies, red team members and more, it can be difficult to keep track of the information that is generated and to ensure testing results are digestible. Having clear guidance not just on how to test but also on how to document each test is a critical if often-overlooked part of the red teaming process.

LEGAL PRIVILEGE

With so much sensitive information being generated across testers and teams, understanding where and when to assert legal privilege is another often overlooked but a major consideration. We often see potential liabilities being discussed openly in places like Slack, which makes that information discoverable to adversarial parties if external oversight occurs, such as a regulatory investigation or lawsuit.

WHAT TO DO ABOUT VULNERABILITIES

Having clear plans for addressing the vulnerabilities that red teaming efforts discover is another central but often-overlooked part of the red teaming process. Who from the product or data science teams is responsible for taking action? Do they meet with the red team directly or through an intermediary? Do they attempt to patch the vulnerabilities as red teaming is occurring or should they wait until the end of the process?

These questions, and many more, need to be addressed before red teaming occurs; otherwise the detection of vulnerabilities in the model is likely to create lots of confusion.

This article provides only a high-level overview of all of the considerations that go into making red teaming generative AI successful. It is one of the most effective ways to manage the technology’s complex risks. Companies betting big on generative AI should be equally committed to red teaming.

Autor

  • Es cofundador de Luminos.Law, un bufete de abogados especializado en IA y análisis, y miembro visitante del Information Society Project de la Facultad de Derecho de Yale.

    Ver todas las entradas

Sobre el Autor

Es cofundador de Luminos.Law, un bufete de abogados especializado en IA y análisis, y miembro visitante del Information Society Project de la Facultad de Derecho de Yale.