Planeamiento de la formación de red teaming de IA

El proceso de red teaming es una práctica recomendada en el desarrollo responsable de aplicaciones y sistemas que utilizan modelos de lenguaje de grandes dimensiones (LLM). Los equipos rojos complementan el trabajo sistemático de medición y mitigación realizado por los desarrolladores y ayudan a descubrir e identificar los daños. Los equipos rojos también ayudan a habilitar las estrategias de medición para validar la eficacia de las mitigaciones.

Al planear su enfoque para el uso de equipos rojos con LLMs y aplicaciones habilitadas para IA, tenga en cuenta los siguientes objetivos.

• Asegúrese de que se siguen los protocolos de seguridad de software adecuados para la aplicación: la inteligencia artificial no le exime de las prácticas de seguridad tradicionales.
• Pruebe el modelo base de LLM y determine si hay lagunas en los sistemas de seguridad existentes, dado el contexto de la aplicación.
• Proporcionar comentarios sobre errores que las pruebas descubren para impulsar mejoras

El proceso de red teaming de IA tiene cuatro fases: contratar al equipo, diseñar pruebas adversariales, realizar pruebas e informar de los resultados.

Contratación del equipo rojo

El éxito de la formación de red teaming de IA depende de las personas que contrata. Al seleccionar miembros del equipo rojo, siga estos principios:

• Seleccione para obtener experiencia y experiencia diversas: busque miembros del equipo rojo con diferentes antecedentes, áreas de experiencia y casos de uso para el sistema de destino. Por ejemplo, si sondea un bot de chat de atención sanitaria, una enfermera tiene un enfoque diferente al de un administrador de sistemas que administra la infraestructura del bot de chat.
• Incluya tanto mentalidades adversas como benignas: a diferencia de los equipos rojos tradicionales solo con profesionales de seguridad, los equipos rojos de IA también deben incluir usuarios normales. Los usuarios normales pueden detectar comportamientos dañinos a través de patrones de interacción naturales que es posible que los profesionales de seguridad no piensen en probar. Por ejemplo, una enfermera podría convencer a un bot de chat para liberar datos confidenciales de los pacientes de una manera que no se produciría en un profesional de seguridad.
• Asignar miembros del equipo a perjuicios y características específicos: asigne a los miembros con pericia específica para investigar tipos específicos de perjuicios; por ejemplo, los expertos en seguridad investigan los jailbreaks y la extracción de metaprompt. En el caso de varias rondas, considere rotar tareas para aportar nuevas perspectivas, permitiendo tiempo para ajustarse.
• Proporcionar objetivos claros: proporcione a cada miembro del equipo instrucciones claras sobre el objetivo, las características del producto que se van a probar, los tipos de problemas para investigar, las expectativas de tiempo y cómo registrar los resultados.

Proporcione una manera coherente de registrar los resultados, incluida la fecha, un identificador único para la reproducibilidad, el aviso de entrada y una descripción o captura de pantalla de la salida.

Diseño de pruebas adversariales

Dado que una aplicación se compila con un modelo base, pruebe en ambas capas:

• El modelo base de LLM con su sistema de seguridad implementado, normalmente a través de un punto de conexión de API, para identificar brechas que necesitan abordarse en el contexto de la aplicación
• La aplicación habilitada para IA mediante su interfaz de usuario para probar el sistema completo incluidos los mecanismos de seguridad de nivel de la aplicación.

Los red teamers deben probar ambas capas antes y después de que se produzcan mitigaciones.

Realización de pruebas

Comience por probar el modelo base para comprender la superficie de riesgo y guiar el desarrollo de mitigación. Pruebe iterativamente con y sin mitigaciones para evaluar su eficacia. Utilice tanto el red teaming manual como las evaluaciones sistemáticas, y pruebe en la interfaz de usuario de producción tanto como sea posible para replicar el uso real.

Estructure las pruebas en torno a estas actividades:

Determinar el ámbito de daño

Comience con las directivas organizativas sobre confianza y seguridad o inteligencia artificial responsable, junto con las regulaciones de cumplimiento. Trabaje con sus equipos legales y de directivas para identificar los daños más importantes para esta aplicación. El resultado es una lista prioritaria de daños con ejemplos.

Los equipos de ataque creativos a menudo descubren vulnerabilidades que no fueron previstas por las políticas organizativas. Varias organizaciones han sufrido daños de reputación cuando el público detectó resultados problemáticos de inteligencia artificial que no se probaron. Es más probable que un equipo rojo creativo detecte estos problemas antes del lanzamiento.

Ampliar la lista a través de pruebas abiertas

Complementar la lista impulsada por políticas con problemas encontrados a través de la exploración creativa. Priorice los daños para las pruebas iterativas en función de la gravedad y el contexto en el que es probable que aparezcan. Agregue cada daño recién detectado a la lista maestra para futuras rondas de pruebas.

Volver a probar después de aplicar mitigaciones

Pruebe la lista completa de daños conocidos con mitigaciones implementadas. Puede detectar nuevos daños o encontrar que las mitigaciones existentes no son suficientes. Actualice la lista de daños y esté abierta a las prioridades cambiantes en función de los resultados.

Automatización a escala

El red teaming manual es esencial pero difícil de escalar. Complétalo con herramientas de red teaming automatizadas, marcos que automatizan el escaneo adversarial de modelos y aplicaciones de inteligencia artificial. Por ejemplo, el Python Risk Identification Tool (PyRIT) de código abierto proporciona:

1. Exámenes automatizados: simula prospecciones adversarias mediante mensajes iniciales seleccionados por categoría de riesgo, con estrategias de ataque que eluden los protocolos de seguridad.
2. Puntuación: genera una tasa de éxito de ataque (ASR)—el porcentaje de ataques exitosos—lo que te da una postura de riesgo cuantificable.
3. Informes: genera tarjetas de puntuación de técnicas de ataque y categorías de riesgo, que se siguen a lo largo del tiempo para el cumplimiento y la supervisión continua.

En el caso de los agentes de inteligencia artificial específicamente, las herramientas automatizadas pueden probar categorías de riesgo difíciles de alcanzar a través de pruebas manuales de avisos solos, incluidas las acciones prohibidas, la pérdida de datos confidenciales a través de llamadas a herramientas y el cumplimiento de tareas.

Ejecute herramientas automatizadas en un entorno que no sea de producción configurado con recursos similares a la producción. Úselos como complemento para las pruebas manuales: la automatización expone riesgos a escala, mientras que los expertos humanos proporcionan un análisis más profundo.

Resultados del informe

Sea estratégico con la recopilación de datos para evitar sobrecargar a los red teamers al capturar información crítica. Para ejercicios más pequeños, una hoja de cálculo compartida funciona bien. Para realizar pruebas sistemáticas a escala, las herramientas automatizadas proporcionan métricas y recopilación de resultados estructurados.

Comparta informes regulares con las partes interesadas clave que incluyen:

• Los principales problemas identificados
• Vínculo a los datos sin procesar
• El plan de pruebas de las próximas rondas
• Reconocimiento de los miembros de los equipos rojos

Aclara que los red teaming exponen e incrementan la comprensión de la superficie de riesgo; no es un reemplazo para la evaluación sistemática y el trabajo riguroso de mitigación. Los lectores no deben interpretar ejemplos específicos como una métrica para la penetración de ese daño.