Respuesta a la orden ejecutiva del NIST sobre la IA

OpenAI se creó en 2015 como entidad sin ánimo de lucro para asegurar que la inteligencia artificial general (es decir, un tipo de IA que es tan inteligente como una persona o más) beneficie a toda la humanidad. Investigamos, desarrollamos y lanzamos tecnología de IA puntera, así como herramientas y buenas prácticas para su seguridad, alineación y gobernanza. Agradecemos esta oportunidad de aportar información al NIST para su trabajo actual y fundamental en materia de la IA.

En este artículo, nos centraremos en tres temas recogidos en la solicitud de información: (1) evaluación y auditoría de las capacidades de la IA; (2) realización de pruebas del equipo rojo para permitir el despliegue de sistemas seguros y fiables; y (3) contenido sintético y procedencia.

Nos complace que el NIST se centre en «crear directrices y pruebas comparativas para evaluar las capacidades… mediante las que la IA podría ser perjudicial». En OpenAI, nos hemos adherido a un marco de preparación⁠(se abre en una ventana nueva) que ofrece un enfoque integral para evaluar, rastrear y mitigar los riesgos catastróficos y peligrosos de los modelos de IA de la actualidad y del futuro. A día de hoy, el marco de preparación rastrea cuatro áreas de riesgo iniciales: ciberseguridad, amenazas químicas, biológicas, radiológicas y nucleares (QBRN), persuasión y autonomía del modelo. Con este marco, también nos comprometemos a mantener una vigilancia continua sobre los riesgos «desconocidos» que todavía no se han identificado. Así pues, como parte de este trabajo, OpenAI ha compartido⁠ recientemente una evaluación a gran escala en materia de QBRN. En ella, se evalúa la capacidad de GPT‑4 para aumentar de forma significativa el acceso de los actores maliciosos a información peligrosa sobre la creación de amenazas biológicas en comparación con la base de referencia de recursos que ya existen (por ejemplo, internet). En esta evaluación, la mayor de su clase y en la que han participado tanto expertos en biología como estudiantes, comprobamos que GPT‑4 proporciona, como mucho, un ligero aumento de la información sobre la creación de amenazas biológicas. Aunque no se trata de un aumento lo suficientemente significativo como para ser concluyente, esperamos que este hallazgo sirva como punto de partida para continuar con esta investigación y con la deliberación de la comunidad. También tenemos la esperanza de que el NIST y el nuevo Instituto de Seguridad de la IA fomenten esta tarea. Por otro lado, este trabajo aumentó nuestra confianza en varios principios clave para evaluar los riesgos de los sistemas de IA:

• La contribución que los sistemas de IA hacen a los riesgos se debe medir en términos de cambio con respecto a una base de referencia adecuada.Muchos de los riesgos que pueden aumentar con el uso de los sistemas de IA, tanto actuales como futuros, existen igualmente a cierto nivel incluso sin la IA (como en ciberseguridad o en bioseguridad). Por ejemplo, una simple búsqueda en internet ya permite un grado significativo de acceso a información relevante para la bioseguridad. Por ese motivo, al evaluar la contribución de los sistemas de IA a los riesgos, una importante práctica recomendada es comprobar si la IA aumenta los riesgos en comparación con los recursos existentes. En nuestro estudio reciente sobre riesgos biológicos, pusimos esto en práctica de la siguiente manera. Asignamos aleatoriamente la mitad de los participantes a un grupo de control que solo tenía acceso a fuentes de conocimiento ajenas a la IA (como bases de datos online, buscadores de internet o cualquiera de sus conocimientos previos). La otra mitad de los participantes formó un grupo experimental con pleno acceso tanto a estos recursos como al modelo GPT‑4.
• Trabajar con expertos en la materia es fundamental para comprender los riesgos.Para cualquier entidad, contratar a expertos de talla mundial en todos los amplios y variados temas que atañen a la seguridad de la IA es todo un desafío. Por ello, para acceder a expertos de prestigio, es útil asociarse con terceros que cuenten con expertos en materias relevantes para la evaluación de las capacidades peligrosas de la IA. Además, que haya expertos que participen en la calificación de los estudios es de gran ayuda para asegurar que estas evaluaciones se lleven a cabo de forma objetiva. Un ejemplo de esto es nuestro trabajo en el desarrollo y la administración de la evaluación de los riesgos biológicos. Colaboramos estrechamente con expertos en bioseguridad externos, tanto en el diseño de las tareas de investigación como en la administración de la formación en seguridad para los participantes y la calificación de las tareas que se completan. La expansión y la diversificación de este ecosistema serían de gran utilidad para la seguridad de la IA.
• Una evaluación exhaustiva también requiere colaborar con expertos en IA para descubrir de forma eficaz todas las capacidades del modelo.Si queremos comprender toda la variedad de riesgos que pueden suponer los modelos de IA, es necesario descubrir todas las capacidades del modelo en la evaluación, siempre que sea posible. Esto requiere un exhaustivo conocimiento de los sistemas de IA subyacentes y de cómo pueden aprovecharse de forma eficaz. Por lo tanto, recomendamos que las evaluaciones se diseñen en colaboración directa con expertos del sector. En nuestro estudio de riesgos biológicos, esta colaboración incluyó la formación de sujetos humanos sobre cómo obtener un mejor rendimiento de las mejores prácticas de educación de capacidades de modelos del lenguaje, así como enfoques técnicos personalizados para descubrir y sondear mejor las capacidades de los modelos.
• Necesitamos más investigación sobre cómo interpretar los resultados de las evaluaciones de riesgos.Por ejemplo, en el caso de la evaluación del creciente acceso de los modelos de IA a la información sobre riesgos biológicos, todavía no queda claro qué nivel de incremento en el acceso a la información implicaría un aumento significativo de ese tipo de riesgo. El efecto de los sistemas de IA sobre el riesgo biológico puede cambiar a medida que surjan nuevas tecnologías que puedan convertir la información disponible online en amenazas biológicas físicas. Nosotros continuamos aplicando nuestro marco de preparación y tenemos muchas ganas de trabajar con el NIST y el Instituto de Seguridad de la IA para entender de forma más profunda los riesgos y sus métricas.
• Las evaluaciones de expertos humanos tienen un alto coste.Llevar a cabo evaluaciones de los modelos del lenguaje con humanos requiere un presupuesto considerable (compensación para los participantes, el desarrollo del software, la seguridad, etc.). En nuestro estudio de riesgos biológicos, exploramos varias maneras de reducir esos costes. No obstante, la mayoría de esos gastos fueron necesarios. Primero, por las consideraciones de seguridad no negociables. Y, segundo, por el número de participantes necesarios y la cantidad de tiempo que cada participante emplea para un examen exhaustivo. Hay que tener en cuenta estas consideraciones a la hora de diseñar las normas.

Puedes encontrar más información en nuestro artículo de blog sobre el reciente estudio de riesgos biológicos: Desarrollo de un sistema de alerta temprana para las amenazas biológicas creadas con ayuda de LLM⁠.

En OpenAI, definimos la labor del equipo rojo como «un proceso estructurado para sondear sistemas y productos de IA con el objetivo de identificar capacidades y resultados perjudiciales, o amenazas de la infraestructura».^A
Bajo el término «equipo rojo», hay varios métodos posibles. Entre ellos, se incluyen el equipo rojo interno (formado por equipos internos especializados en un laboratorio o empresa), el equipo rojo externo (formado por partes externas interesadas en colaboración con un laboratorio o una empresa) o el equipo rojo automatizado (usa modelos de IA para generar ataques automatizados y clasificar los resultados). En el contexto de este documento, hablaremos principalmente de los esfuerzos del equipo rojo externo que conllevan que OpenAI trabaje con expertos del sector externos para evaluar las capacidades y riesgos de un modelo o sistema de IA.

En el enfoque de OpenAI para el equipo rojo, no se consideran de forma aislada los ataques adversos o los resultados que ofrezca el modelo. Por el contrario, se trata de un método para determinar los riesgos dentro del contexto y de manera multidisciplinar en colaboración con expertos en la materia.^B De hecho, además de los usos malintencionados y los métodos para eludir las medidas de seguridad, el equipo rojo también tiene en cuenta otros riesgos. Entre ellos, se encuentran las entradas de datos benignas o esperadas que conducen a salidas de datos perjudiciales o de riesgo, las mejoras de las capacidades nuevas que puedan alterar la variedad de riesgos o cómo los factores externos al propio sistema pueden interactuar con las salidas de datos del modelo para causar daños o riesgos. La participación humana es, a menudo, beneficiosa para las evaluaciones de estas áreas, ya que genera ejemplos potenciales y valida los resultados dentro del contexto de la experiencia de un determinado miembro del equipo rojo.

El equipo rojo de la IA nos ayuda a comprender los riesgos potenciales asociados a los nuevos modelos y sistemas siguientes:

• Aquellos que requieren formas de interactuar que pueden ser diferentes a los sistemas o tecnologías de IA anteriores y que no están del todo contemplados en las evaluaciones de los programas (por ejemplo, pintar en DALL·E o los GPT).
• Los que tienen capacidades significativamente mejoradas que pueden introducir riesgos que todavía no se han evaluado (por ejemplo, el sector científico, la persuasión o el razonamiento).
• Aquellos que requieren un conocimiento específico del contexto o del sector para poder comprobarlos y verificarlos (por ejemplo, contenido político específico de una región, sesgos culturales, el sector científico o materias de expertos como el derecho o la medicina).
• Los que requieren comprender a un flujo de usuarios o casos de uso específicos entre los que se incluyen factores que pueden ser externos al propio sistema (por ejemplo, probar GPT‑4V para personas con problemas de vista).

En OpenAI, consideramos que el equipo rojo es una herramienta para evaluar los riesgos tanto a nivel de modelo como de sistema. Las características del sistema pueden incluir clasificadores, filtros de prompts o listas de bloqueo, intervenciones a nivel de interfaz de usuario, prácticas de evaluación y otros mecanismos para aplicar las políticas. En ocasiones, usamos el equipo rojo para probar un nuevo producto incluso aunque no se trate de un nuevo modelo. Un claro ejemplo son los GPT⁠, que aunque no introdujeron un nuevo modelo subyacente, sí introdujeron nuevos sistemas para que los usuarios interactuasen con el modelo.

En OpenAI, consideramos que nuestros esfuerzos con el equipo rojo son complementarios a otros esfuerzos de equipos rojos específicos de cada sector que deberían llevar a cabo los desarrolladores que se basan en nuestra tecnología. Así pues, si nosotros sometemos nuestros modelos y sistemas a pruebas de equipo rojo en momentos específicos y condiciones concretas, aquellos desarrolladores que se basen en nuestra API deben tener en cuenta estos conocimientos y llevar a cabo pruebas de equipo rojo adicionales basadas en el sistema y el contexto en los que desean operar. Esta es una de las razones por las que publicamos los hallazgos clave de los equipos rojos en las tarjetas del sistema y otras formas de documentación disponibles para el público. Así, otros pueden aprender y basarse en ellos.

Hemos documentado varios de nuestros esfuerzos con el equipo rojo para el lanzamiento de modelos de frontera en las tarjetas del sistema:

• Tarjeta del sistema DALL·E 2
  ⁠(se abre en una ventana nueva)
• Tarjeta del sistema GPT‑4⁠(se abre en una ventana nueva)
• Tarjeta del sistema GPT‑4V⁠
• Tarjeta del sistema DALL·E 3⁠

Hemos proporcionado a los expertos del equipo rojo total acceso a modelos preentrenados con diversos grados de optimización y posentrenamiento, así como varios niveles de desarrollo de las mitigaciones de seguridad.

Nuestros objetivos al hacer esto son los siguientes:

• Los conocimientos que obtiene el equipo rojo pueden servir de base para las medidas de mitigación del posentrenamiento, las mitigaciones del sistema, las políticas y las evaluaciones.
• Los conocimientos que obtiene el equipo rojo pueden ayudar a la directiva a tomar decisiones sobre la publicación de determinadas funciones, cómo desplegarlas de forma iterativa y la eficacia de las medidas de seguridad.
• Podemos compartir los resultados de los equipos rojos junto con los materiales que publicamos (como las tarjetas del sistema u otros formatos) para informar a los usuarios potenciales y otras partes interesadas sobre los riesgos que se han mitigado, los riesgos residuales y los posibles riegos que pueda haber en el futuro.

En cuanto es razonable dentro del proceso de desarrollo, involucramos a los miembros del equipo rojo para que sus conocimientos puedan contribuir directamente a los esfuerzos de seguridad y a la toma de decisiones. De igual manera, es importante conocer las capacidades básicas del modelo antes de incorporar mitigaciones de seguridad para que los desarrolladores puedan tomar decisiones informadas sobre los riesgos base de su modelo y para que la sociedad comprenda la variedad de riesgos asociada a los sistemas cada vez más potentes.

Una vez se han implementado las mitigaciones de seguridad, los esfuerzos del equipo rojo se pueden centrar en rondas adicionales de comprobación para identificar las lagunas y los riesgos residuales que no se han contemplado en las mitigaciones de seguridad. Así mismo, también sirven para evaluar la eficacia de las mitigaciones.

En definitiva, aunque hay propiedades de seguridad importantes que se deben tener en cuenta durante el desarrollo de los modelos, el equipo rojo tiene como objetivo simular una experiencia lo más parecida posible a la que los desarrolladores ponen a disposición del público.

Por sí misma, la tarea del equipo rojo no es un ejercicio de medición de riesgos lo suficientemente completo. Esto se debe a que, por sí solo, el equipo rojo no puede cuantificar la probabilidad o la propensión de un modelo para producir contenidos nocivos o riesgos asociados al uso de un sistema de IA. De hecho, tampoco proporciona la suficiente información como para cuantificar la gravedad de un riesgo o perjuicio que se identifique.

Aunque la mayoría de los esfuerzos de los expertos del equipo rojo de OpenAI se llevan a cabo antes del despliegue de un modelo o producto importante, los modelos y sistemas evolucionan con bastante frecuencia durante la producción. Por lo tanto, es importante tener esto en cuenta a la hora de dar contexto a los hallazgos del equipo rojo. De la misma forma, los desarrolladores que crean modelos para casos de uso concretos pueden tomar decisiones de diseño que alteren el perfil de seguridad de un modelo o sistema si no es propio del modelo o sistema en sí (o no puede modificarse a partir de él).

Así pues, el equipo rojo sienta las bases para otros tipos de pruebas y evaluaciones, y proporciona algunas pautas sobre los vectores de ataque o los problemas a los que las mitigaciones de seguridad deben hacer frente.

Y es que examinar diferentes ejemplos y permutaciones de un problema es de gran ayuda a la hora de ganar confianza en cómo medir un área de riesgo concreta. Tal y como está diseñado, el equipo rojo de expertos tiene como objetivo abarcar la amplitud en vez de la profundidad de las áreas de riesgo. Este es el motivo por el cual, por sí solo, no crearía necesariamente una evaluación lo suficientemente exhaustiva para medir riesgos específicos. En cambio, el equipo rojo puede generar un conjunto de datos que podrían considerarse las «semillas» para una evaluación más exhaustiva. A partir de ahí, los resultados se pueden usar para generar más ejemplos de un área problemática en concreto que se haya descubierto. Además, se puede usar un conjunto de ejemplos de calidad ya etiquetados (normalmente, por expertos del sector) para evaluar futuros modelos con respecto a un área problemática identificada.

Los sistemas de IA de propósito general, que en muchos casos, se utilizarán tanto de la forma prevista como de manera imprevista y en diversos contextos de todo el mundo, necesitan cubrir una amplia variedad de áreas temáticas, con personas que representen múltiples perspectivas y tengan diferentes visiones del mundo.

Por ello, en OpenAI creemos que es necesario reclutar a una gran variedad de expertos para llevar a cabo las pruebas de equipo rojo en nuestros modelos. El año pasado, publicamos una convocatoria de candidaturas para la red de equipos rojos. Los criterios de selección incluían:

• Conocimientos o experiencia demostrable en un sector concreto y relevante para el equipo rojo
• Pasión por mejorar la seguridad de la IA
• No tener conflictos de intereses
• Procedencia diversa y grupos poco representados habitualmente
• Representación geográfica diversa
• Hablar con fluidez más de un idioma
• Habilidades técnicas (útil, pero no obligatorio)

La priorización de los sectores puede basarse en varios factores. Entre estos, se incluyen los usos previstos de los sistemas o modelos de IA, sobre todo, en contextos con mayor ambigüedad o posibles riesgos; la evaluación temprana de modelos en los que los desarrolladores podrían esperar mayores capacidades; las áreas problemáticas previas ya conocidas en materia de política de contenidos; y los contextos sociopolíticos relevantes (por ejemplo, el año 2024 ha sido un año electoral importante en varios lugares del mundo). Cabe destacar que cada modelo o sistema puede requerir distintos conjuntos de conocimientos especializados. Además, también pueden entrar en consideración nuevos sectores en función del avance de las capacidades y los nuevos casos de uso del modelo o sistema. Por ello, la composición óptima de los equipos rojos irá evolucionando con el tiempo.

• Marcas de agua: según este enfoque, los propios contenidos audiovisuales generados contienen una marca de su origen, un patrón sutil que no es demasiado evidente para el espectador u oyente, pero que un software sí puede detectar. Puede tratarse de una señal que solo se pueda detectar con la ayuda de una clave secreta o, si no, el software para detectar la marca de agua puede estar a disposición del público. Por este motivo, si OpenAI añadiera una marca de agua a sus datos de salida, la colaboración de toda la cadena de valor sería necesaria para que otros participantes, como las plataformas de redes sociales que distribuyen los contenidos, pudieran hacer que la marca de agua fuera visible y útil para los usuarios. Si el proceso de detección no es público, entonces, el acceso a ese proceso es una cuestión de políticas compleja. De hecho, también existen algunos desafíos técnicos. Aunque las marcas de agua son más difíciles de eliminar que otros métodos para detectar la procedencia, los contenidos marcados pueden perder la marca de agua si los recortan, redimensionan o modifican de alguna manera. Hay que considerar que, las marcas de agua pueden esquivarse, especialmente por actores motivados con malas intenciones. Además, el impacto de las marcas de agua puede ser limitado, ya que los actores malintencionados pueden acceder a aquellos modelos que no marquen sus datos de salida con marcas de agua.
  
• Clasificadores (modelos entrenados que distinguen los resultados generados por IA de los generados por otros medios y pueden detectar qué modelo o servicio ha generado un resultado determinado): cuando son eficaces, estos enfoques son muy interesantes, ya que no dependen de la cooperación de la persona que distribuye la imagen ni de nadie más. No obstante, los clasificadores pueden cometer errores, tanto falsos positivos como falsos negativos. Por ello, su despliegue a gran escala puede requerir un gran esfuerzo informático. Por ejemplo, los falsos positivos pueden etiquetar la obra de un artista humano como contenido generado por IA. Por su parte, los falsos negativos pueden etiquetar de forma errónea una imagen como no generada por IA cuando, en realidad, sí lo está.
  
  
• Enfoques basados en los metadatos (como el estándar C2PA⁠(se abre en una ventana nueva) actual): en estos enfoques, los metadatos que acompañan determinados contenidos están firmados criptográficamente para dar fe de su origen.
  
  Esto es de gran ayuda para las personas que quieran demostrar el origen de los contenidos, ya estén generados por la IA o no. Por ejemplo, el C2PA puede permitir que un periodista demuestre que ha publicado realmente una determinada imagen o vídeo con el respaldo de los metadatos, y los lectores o espectadores pueden confirmar que es cierto. De igual forma, si se aplica a un sistema de IA generativa, esta técnica puede ayudar a un artista a demostrar que ha generado una determinada imagen o vídeo sintético. En teoría, estos enfoques tienen el beneficio de proporcionar visibilidad sobre la procedencia del contenido tanto al consumidor como al público general. Además, también cuentan con la ventaja de no requerir grandes recursos para implementarlos.
  
  No obstante, los metadatos pueden eliminarse fácilmente de una imagen o vídeo, por lo que esta técnica no crea una barrera significativa para los actores malintencionados que quieran hacer pasar por reales los contenidos generados por la IA (por ejemplo, en campañas de desinformación).
  
  Para que los enfoques basados en los metadatos puedan beneficiar ampliamente al público, los navegadores y las plataformas de distribución, como las redes sociales, tendrían que detectar y mostrar esos metadatos. Por lo tanto, para aplicar con éxito estos enfoques, es necesaria la colaboración de toda la cadena de valor: que los materiales lleven los metadatos firmados criptográficamente no es suficiente; las plataformas de distribución también tienen que ser capaces de detectar esos metadatos en cuestión y mostrarlos para que el usuario final pueda verificar la procedencia de los contenidos.

Puesto que cada método de procedencia tiene sus ventajas y limitaciones, en OpenAI hemos estado explorando diferentes enfoques para la procedencia de los contenidos audiovisuales generados por IA.

El 15 de enero de 2024, desde OpenAI anunciamos que íbamos a implementar un enfoque de metadatos C2PA para las imágenes generadas mediante nuestro modelo de conversión de texto a imagen DALL·E 3. Las especificaciones C2PA son un estándar técnico abierto que ofrece a los editores, consumidores y creadores la posibilidad de rastrear el origen de diferentes tipos de contenidos.

Estas especificaciones permiten adjuntar metadatos a un archivo, que incluyen información sobre el origen de una imagen (en nuestro caso, que la imagen procede de DALL·E) y la fecha de su creación. El público puede buscar estos metadatos y, si están presentes, confirmar que la imagen se ha generado con DALL·E 3.

Esto nos facilitará ofrecer a los usuarios la posibilidad de indicar la procedencia de las imágenes que generen con DALL·E 3. No obstante, estos metadatos se pueden eliminar de una forma relativamente fácil: un actor malintencionado puede eliminar los metadatos C2PA que acompañan cualquier imagen con tan solo un poco de motivación. Además, a día de hoy, las plataformas habituales para compartir imágenes, como las redes sociales, eliminan los metadatos por defecto en vez de detectarlos y presentárselos a los usuarios. Así pues, dada la facilidad con la que pueden eliminarse los metadatos C2PA, el público no puede dar por hecho que todas las imágenes que se generen con DALL·E incluyan necesariamente esos metadatos.

Sin embargo, los metadatos C2PA no son solo para las imágenes generadas por la IA, y podrían tener importantes beneficios si se adoptaran de forma más amplia. Por ejemplo, los fabricantes de cámaras, las organizaciones de noticias y otras entidades están haciendo uso de estos metadatos para garantizar la procedencia de las imágenes. Creemos que una adopción más amplia de los métodos de divulgación y animar a los usuarios a que busquen estas señales son pasos fundamentales para aumentar la fiabilidad de la información digital.

El 19 de octubre de 2023, anunciamos nuestro trabajo en curso sobre un clasificador de procedencia, una nueva herramienta interna para detectar imágenes generadas por nuestro sistema DALL·E 3. Nos encargamos de medir la precisión del clasificador mediante pruebas de referencia internas que han mostrado resultados prometedores, incluso aunque las imágenes estén modificadas, como con recortes, cambios de tamaño, compresión JPEG o aunque se hayan superpuesto textos o recortes de imágenes reales en pequeñas porciones de la imagen generada. A pesar de estos buenos resultados en nuestras pruebas internas, el clasificador solo puede decirnos que es probable que la imagen se haya generado con DALL·E, pero no nos permite sacar conclusiones definitivas.

Por ello, continuamos probando nuestro clasificador y, en el primer trimestre de 2024, lo pusimos a disposición de socios externos para que nos enviasen su opinión. Así mismo, esperamos empezar a ampliar nuestras pruebas con el clasificador de imágenes con la ayuda de partes externas seleccionadas para unirse a nosotros y evaluar su rendimiento y utilidad.

No obstante, el clasificador está adaptado al modelo y solo es capaz de clasificar si una imagen se ha generado probablemente con DALL·E. Por lo tanto, aunque fuera completamente preciso con sus clasificaciones, no sería posible usarlo para determinar si una imagen se ha generado por otra herramienta generativa.

Nos complace tener la oportunidad de colaborar contigo mientras continúe nuestro trabajo en esta área.

Un saludo,

Anna Adeola Makanju
Vicepresidenta de Asuntos Internacionales
OpenAI