S

i hay una constante en el mundo de la tecnología, es que cuanto más se adopta una tecnología determinada, más fallos presenta.

Dado que la respuesta ante incidentes de IA es diferente de la respuesta tradicional a incidentes en varios aspectos, los esfuerzos de respuesta ante incidentes de IA requieren sus propias políticas y procedimientos para guiar a las empresas y al personal involucrado en la gestión del incidente. Las políticas sobre incidentes de IA deben abordar los siguientes puntos.

— Crear una definición de IA.

— Identificar los daños más relevantes.

— Designar a los responsables de responder ante incidentes.

— Desarrollar un plan de contención a corto plazo.

¿Qué hacer después de identificar un incidente de IA: contención, erradicación y recuperación?

Una vez que se han identificado los incidentes, el siguiente paso es llevar a cabo una estrategia de contención a más largo plazo para evitar que el daño se extienda aún más. Estas son las preguntas críticas que dicha evaluación debe responder:

— ¿Quién está siendo perjudicado?

— ¿Cuáles son las opciones para modificar el comportamiento del sistema de IA?

— ¿Qué está causando el daño?

— ¿Pueden abordarse o rectificarse de alguna manera los daños existentes?

Una vez que el incidente ha ocurrido, es importante no solo entender quién ha sido perjudicado, sino también qué pueden hacer las empresas al respecto. Un tipo común de incidente se produce cuando se ofrecen servicios preferenciales (como descuentos en productos) solo a grupos demográficos específicos.

Cuando se han puesto en marcha y ejecutado los planes de contención, el siguiente paso consiste en intentar eliminar por completo la causa del incidente. Algunos sistemas de IA pueden ser susceptibles de ser erradicados, pero otros solo permiten una erradicación parcial, o es posible que la fuente del incidente no pueda eliminarse por completo. A grandes rasgos, existen tres formas principales de abordar o corregir el comportamiento problemático de los modelos, cada una de las cuales ha sido utilizada desde hace mucho tiempo para depurar modelos de aprendizaje automático:

1. Preprocesamiento: Se refiere a las acciones que se pueden realizar antes de que el modelo ingiera datos de entrada o sea entrenado con ellos. En algunos casos, los datos de entrenamiento no representativos pueden ser la fuente del comportamiento problemático del modelo. En ese caso, la solución consiste en volver a entrenar el modelo con datos más representativos.

2. Procesamiento interno: Este tipo de correcciones implica cambiar los pesos reales o la arquitectura del propio modelo. En ocasiones, este tipo de actualizaciones son relativamente simples, pero en la mayoría de los casos requieren un desarrollo significativo y prolongado. Rara vez he visto que este enfoque funcione en la práctica, sobre todo porque a menudo implica crear un modelo completamente nuevo.

3. Postprocesamiento: Esta es la opción más sencilla de todas y se ha utilizado ampliamente durante décadas para solucionar problemas de IA. Consiste en cambiar el comportamiento del modelo después de que el sistema ha realizado sus predicciones. Los filtros de salida, por ejemplo, pueden simplemente impedir ciertos comportamientos o evitar que se generen predicciones específicas. Por lo general, estos se presentan en forma de reglas que pueden añadirse al modelo.

Lecciones aprendidas

Una vez concluidas las actividades de respuesta, es fundamental que las empresas realicen una revisión posterior para aprender y mejorar a partir de cada incidente. Esto implica dar un paso atrás y evaluar los aciertos y las deficiencias en la forma en que se abordó el incidente.

Prevenir y responder a los riesgos debe ser un ejercicio continuo.

H

ay una razón por la que a veces fracasamos en tareas que normalmente podemos ejecutar de pie sobre una pierna. Es una lección que aprendí por las malas.

Solía haber una presentación de comedia llamada Big Night Out en el Comedy Pub de Londres. Bueno, en realidad dos actuaciones. Una en el sótano debajo del pub y otra en una sala en el piso arriba. La primera vez que actué en el Big Night Out, al principio de mi carrera, hice una gran rutina en el sótano, y luego subí a la planta superior y tuve el peor espectáculo de mi vida.

¿Qué fue lo que salió mal?

En el sótano me gané la confianza poco a poco, me fui atreviendo y terminé la presentación como alguien que tenía al público en la palma de su mano. En la segunda presentación, entré pensando que era tan bueno que el público debía caer rendido a mis pies. No me molesté en tantear el terreno ni en generar confianza.

Como instructor ejecutivo, siempre respeto los conocimientos y la experiencia de mis clientes. Primero me esfuerzo por comprenderlos y entender el contexto en el que operan. Incluso después de conseguir esa comprensión, no presumo ni proclamo saber más que ellos.

También he hecho un esfuerzo consciente por desarrollar mi marca personal y profesional. Esto no me impide fracasar por arrogancia. Todavía debo acercarme con humildad a las partes interesadas y probar mi valor.

¿Es consciente de las ocasiones en las que podría estar pensando que es demasiado bueno como para fallar? Cuando se une a una nueva empresa, proyecto o equipo, ¿entra con el chip de sus éxitos pasados? ¿O es emocionalmente inteligente para observar y entender primero las dinámicas del grupo? Usted pudo ser grandioso en su organización previa, o pudo ser el mejor de su clase. El nuevo equipo podría estar familiarizado con su currículum, pero necesitarán tiempo para conocerlo antes de que puedan confiar en usted.

Mi consejo: Cuando entre a una nueva situación (en el trabajo o en la vida) tome el tiempo para entender a las partes interesadas que están involucradas, y también bríndeles la oportunidad de entenderlo y confiar en usted.

Cuando le propone una idea a un cliente, por ejemplo, ¿está enforzándose por comprender sus necesidades antes de presumirle las credenciales de las que usted dispone? Si no es así, ¿cómo puede saber cuál de esas credenciales es relevante para resolver el problema por el que lo contrataron? Del mismo modo, cuando trata de aprender algo nuevo, ¿la arrogancia de sus éxitos pasados le impide plantear una pregunta aparentemente “tonta” (pero esencial)? Cuando está dando un discurso, ¿está personalizando su contenido, adaptándose a la retroalimentación en tiempo real y gestionando sus niveles de energía con base en los de su audiencia?

Si puede tomar algunas de las lecciones que yo aprendí, tendrá más éxito en sus esfuerzos. Y además de la alegría que le brindará el estar en el momento, ¡quizá, a diferencia de mí, usted consiga algunas risas encima del pub en una Big Night Out!

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.