Guía de seguridad

Los modelos de inteligencia artificial generativa son herramientas poderosas, pero tienen sus limitaciones. Su versatilidad y aplicabilidad a veces pueden generar resultados inesperados, como resultados imprecisos, sesgados u ofensivos. El procesamiento posterior y la evaluación manual rigurosa son fundamentales para limitar el riesgo de daño que pueden causar estos resultados.

Los modelos que proporciona la API de Gemini se pueden usar para una amplia variedad de aplicaciones de IA generativa y procesamiento de lenguaje natural (PNL). El uso de estas funciones solo está disponible a través de la API de Gemini o la app web de Google AI Studio. El uso de la API de Gemini también está sujeto a la Política de Uso Prohibido de IA Generativas y las Condiciones del Servicio de la API de Gemini.

Parte de lo que hace que los modelos de lenguaje grandes (LLM) sean tan útiles es que son herramientas creativas que pueden abordar muchas tareas de lenguaje diferentes. Lamentablemente, esto también significa que los modelos de lenguaje grandes pueden generar resultados inesperados, incluido texto ofensivo, insensible o incorrecto desde el punto de vista fáctico. Además, la increíble versatilidad de estos modelos es lo que dificulta predecir exactamente qué tipos de resultados no deseados podrían producir. Si bien la API de Gemini se diseñó teniendo en cuenta los principios de la IA de Google, es responsabilidad de los desarrolladores aplicar estos modelos de manera responsable. Para ayudar a los desarrolladores a crear aplicaciones seguras y responsables, la API de Gemini tiene un filtro de contenido integrado y parámetros de configuración de seguridad ajustables en 4 dimensiones de daño. Consulta la guía de parámetros de configuración de seguridad para obtener más información.

El objetivo de este documento es presentarte algunos riesgos de seguridad que pueden surgir cuando se usan LLMs y recomendarte sugerencias emergentes de diseño y desarrollo de seguridad. (Ten en cuenta que las leyes y reglamentaciones también pueden imponer restricciones, pero esas consideraciones quedan fuera del alcance de esta guía).

Se recomiendan los siguientes pasos cuando se crean aplicaciones con LLMs:

• Comprende los riesgos de seguridad de tu aplicación
• Considera realizar ajustes para mitigar los riesgos de seguridad
• Realiza pruebas de seguridad adecuadas según tu caso de uso
• Solicitar comentarios de los usuarios y supervisar el uso

Las fases de ajuste y prueba deben ser iterativas hasta que alcances el rendimiento adecuado para tu aplicación.

Comprende los riesgos de seguridad de tu aplicación

En este contexto, la seguridad se define como la capacidad de un LLM para evitar causar daño a sus usuarios, por ejemplo, generando lenguaje tóxico o contenido que promueva estereotipos. Los modelos disponibles a través de la API de Gemini se diseñaron teniendo en cuenta los principios de la IA de Google, y su uso está sujeto a la Política de Uso Prohibido de IA Generativas. La API proporciona filtros de seguridad integrados para abordar algunos problemas comunes de los modelos de lenguaje, como el lenguaje tóxico y el discurso de odio, y se esfuerza por lograr la inclusión y evitar los estereotipos. Sin embargo, cada aplicación puede representar un conjunto diferente de riesgos para sus usuarios. Por lo tanto, como propietario de la aplicación, eres responsable de conocer a tus usuarios y los posibles daños que tu aplicación pueda causar, así como de garantizar que tu aplicación use LLMs de forma segura y responsable.

Como parte de esta evaluación, debes considerar la probabilidad de que se produzca un daño y determinar su gravedad y los pasos de mitigación. Por ejemplo, una app que genera ensayos basados en eventos fácticos debería tener más cuidado para evitar la desinformación que una app que genera historias ficticias para el entretenimiento. Una buena manera de comenzar a explorar los posibles riesgos de seguridad es investigar a los usuarios finales y a otras personas que podrían verse afectadas por los resultados de tu aplicación. Esto puede adoptar muchas formas, como investigar estudios de vanguardia en el dominio de tu app, observar cómo las personas usan apps similares o realizar un estudio de usuarios, una encuesta o entrevistas informales con usuarios potenciales.

Considera realizar ajustes para mitigar los riesgos de seguridad.

Ahora que comprendes los riesgos, puedes decidir cómo mitigarlos. Determinar qué riesgos priorizar y qué tanto debes hacer para prevenirlos es una decisión fundamental, similar a la clasificación de errores en un proyecto de software. Una vez que hayas determinado las prioridades, puedes comenzar a pensar en los tipos de mitigaciones más adecuados. A menudo, los cambios simples pueden marcar la diferencia y reducir los riesgos.

Por ejemplo, cuando diseñes una aplicación, ten en cuenta lo siguiente:

• Ajustar el resultado del modelo para que refleje mejor lo que es aceptable en el contexto de tu aplicación El ajuste puede hacer que la salida del modelo sea más predecible y coherente, y, por lo tanto, puede ayudar a mitigar ciertos riesgos.
• Proporcionar un método de entrada que facilite resultados más seguros La entrada exacta que le das a un LLM puede marcar la diferencia en la calidad del resultado. Vale la pena experimentar con las instrucciones de entrada para encontrar lo que funciona de manera más segura en tu caso de uso, ya que luego puedes proporcionar una UX que lo facilite. Por ejemplo, puedes restringir a los usuarios para que solo elijan entre una lista desplegable de instrucciones de entrada, o bien ofrecer sugerencias emergentes con frases descriptivas que hayas descubierto que funcionan de forma segura en el contexto de tu aplicación.

• Bloqueamos las entradas inseguras y filtramos el resultado antes de que se muestre al usuario. En situaciones sencillas, se pueden usar listas de entidades bloqueadas para identificar y bloquear palabras o frases no seguras en instrucciones o respuestas, o bien solicitar a revisores humanos que modifiquen o bloqueen manualmente ese contenido.

• Usamos clasificadores entrenados para etiquetar cada instrucción con posibles daños o señales adversas. Luego, se pueden emplear diferentes estrategias para administrar la solicitud en función del tipo de daño que se detectó. Por ejemplo, si la entrada es de evidente naturaleza adversaria o abusiva, se podría bloquear y, en su lugar, emitir una salida predeterminada.

  Sugerencia avanzada

  • Si los indicadores determinan que el resultado es perjudicial, la aplicación puede emplear las siguientes opciones:
    • Proporcionar un mensaje de error o una salida predeterminada
    • Vuelve a intentarlo con la instrucción, en caso de que se genere un resultado alternativo seguro, ya que, a veces, la misma instrucción genera resultados diferentes.

• Implementar medidas de protección contra el uso inadecuado deliberado, como asignar a cada usuario un ID único y establecer un límite en la cantidad de consultas de usuarios que se pueden enviar en un período determinado Otra medida de protección es intentar evitar la posible inyección de instrucciones. La inyección de instrucciones, al igual que la inyección de SQL, es una forma en que los usuarios maliciosos diseñan una instrucción de entrada que manipula el resultado del modelo, por ejemplo, enviando una instrucción de entrada que le indica al modelo que ignore cualquier ejemplo anterior. Consulta la Política de Uso Prohibido de IA Generativas para obtener detalles sobre el uso inadecuado deliberado.

• Ajustar la funcionalidad a algo que sea inherentemente de menor riesgo Las tareas que tienen un alcance más limitado (p.ej., extraer palabras clave de pasajes de texto) o que tienen una mayor supervisión humana (p.ej., generar contenido de formato corto que revisará un humano) suelen representar un riesgo menor. Por ejemplo, en lugar de crear una aplicación para escribir una respuesta por correo electrónico desde cero, podrías limitarla a ampliar un esquema o sugerir frases alternativas.

Realiza pruebas de seguridad adecuadas según tu caso de uso.

Las pruebas son una parte fundamental de la creación de aplicaciones sólidas y seguras, pero su alcance, ámbito y estrategias variarán. Por ejemplo, es probable que un generador de haikus para divertirse plantee riesgos menos graves que, por ejemplo, una aplicación diseñada para que los estudios de abogados resuman documentos legales y ayuden a redactar contratos. Sin embargo, el generador de haikus puede ser utilizado por una mayor variedad de usuarios, lo que significa que el potencial de intentos adversarios o incluso entradas dañinas no deseadas puede ser mayor. El contexto de implementación también es importante. Por ejemplo, una aplicación con resultados que son revisados por expertos humanos antes de que se tome cualquier medida podría considerarse menos propensa a producir resultados dañinos que la misma aplicación sin esa supervisión.

No es raro pasar por varias iteraciones de cambios y pruebas antes de sentir la confianza necesaria para lanzar la aplicación, incluso en el caso de las aplicaciones que tienen un riesgo relativamente bajo. Hay dos tipos de pruebas que son particularmente útiles para las aplicaciones basadas en IA:

• La comparativa de seguridad implica diseñar métricas de seguridad que reflejen las formas en que tu aplicación podría ser insegura en el contexto de cómo es probable que se use y, luego, probar qué tan bien se desempeña tu aplicación en las métricas con conjuntos de datos de evaluación. Es una buena práctica pensar en los niveles mínimos aceptables de las métricas de seguridad antes de realizar las pruebas para que 1) puedas evaluar los resultados de las pruebas en función de esas expectativas y 2) puedas recopilar el conjunto de datos de evaluación en función de las pruebas que evalúan las métricas que más te interesan.

  Sugerencias avanzadas

  • Ten cuidado de no depender demasiado de los enfoques “listos para usar”, ya que es probable que debas crear tus propios conjuntos de datos de prueba con evaluadores humanos para que se adapten por completo al contexto de tu aplicación.
  • Si tienes más de una métrica, deberás decidir cómo compensarás si un cambio genera mejoras en una métrica en detrimento de otra. Al igual que con otras técnicas de ingeniería de rendimiento, es posible que desees enfocarte en el rendimiento en el peor de los casos en tu conjunto de evaluación en lugar del rendimiento promedio.

• Las pruebas adversarias implican intentar de forma proactiva que tu aplicación falle. El objetivo es identificar los puntos débiles para que puedas tomar las medidas necesarias para corregirlos. Las pruebas adversarias pueden requerir mucho tiempo y esfuerzo por parte de los evaluadores con experiencia en tu aplicación, pero cuanto más realices, mayores serán las probabilidades de detectar problemas, en especial aquellos que ocurren con poca frecuencia o solo después de ejecutar la aplicación varias veces.

  • Las pruebas adversarias son un método para evaluar de manera sistemática un modelo de AA con la intención de aprender cómo se comporta cuando se le proporcionan entradas maliciosas o inadvertidamente dañinas:
    • Una entrada puede ser maliciosa cuando está claro que está diseñada para producir una salida insegura o dañina, por ejemplo, pedir a un modelo de generación de texto que genere una diatriba de odio sobre una religión en particular.
    • Una entrada es inadvertidamente dañina cuando la entrada en sí puede ser inocua, pero produce una salida dañina. Por ejemplo, pedirle a un modelo de generación de texto que describa a una persona de una etnia determinada y recibir una salida racista.
  • Lo que distingue una prueba adversaria de una evaluación estándar es la composición de los datos que se usan para la prueba. Para las pruebas adversarias, selecciona los datos de prueba que tengan más probabilidades de generar resultados problemáticos del modelo. Esto significa sondear el comportamiento del modelo para todos los tipos de daños posibles, incluidos ejemplos raros o inusuales y casos extremos que sean relevantes para las políticas de seguridad. También debe incluir diversidad en las diferentes dimensiones de una oración, como la estructura, el significado y la longitud. Para obtener más detalles sobre qué tener en cuenta cuando crees un conjunto de datos de prueba, consulta las prácticas de IA responsable de Google en relación con la equidad.

    Sugerencias avanzadas

    • Usa pruebas automatizadas en lugar del método tradicional de reclutar personas en "equipos rojos" para intentar vulnerar tu aplicación. En las pruebas automatizadas, el "equipo rojo" es otro modelo de lenguaje que encuentra texto de entrada que genera resultados dañinos del modelo que se está probando.

Supervisa en busca de problemas

Sin importar cuánto pruebes y mitigues, nunca podrás garantizar la perfección, por lo que debes planificar con anticipación cómo detectarás y abordarás los problemas que surjan. Entre los enfoques comunes, se incluyen configurar un canal supervisado para que los usuarios compartan comentarios (p.ej., calificaciones de Me gusta y No me gusta) y realizar un estudio de usuarios para solicitar comentarios de forma proactiva a una combinación diversa de usuarios, lo que es especialmente valioso si los patrones de uso son diferentes de lo esperado.

Próximos pasos

• Consulta la guía de parámetros de seguridad para obtener información sobre los parámetros de seguridad ajustables disponibles a través de la API de Gemini.
• Consulta la introducción a la creación de instrucciones para comenzar a escribir tus primeras instrucciones.