Guía de seguridad

Los modelos de inteligencia artificial generativos son herramientas poderosas, pero no están libres de sus limitaciones. Su versatilidad y aplicabilidad a veces pueden conducir a resultados inesperados, como resultados imprecisos, ofensivos o sesgados. El procesamiento posterior y la evaluación manual rigurosa son esenciales para limitar el riesgo de daños como resultado de tales 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 (PLN). 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 que hagas de la API de Gemini también está sujeto a la Política de Uso Prohibido de IA Generativas y a las Condiciones del Servicio de la API de Gemini.

Parte de lo que hace que los modelos grandes de lenguaje (LLM) sean tan útiles es que son herramientas creativas que pueden abordar muchas tareas de lenguaje diferentes. Por desgracia, esto también significa que los modelos grandes de lenguaje pueden generar resultados inesperados, como texto ofensivo, insensible o incorrecto. Además, la increíble versatilidad de estos modelos también dificulta la predicción exacta de los tipos de resultados no deseados que podrían producir. Si bien la API de Gemini se diseñó teniendo en cuenta los principios de la IA de Google, la responsabilidad de los desarrolladores es 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, así como una configuración de seguridad ajustable en 4 dimensiones de daño. Consulta la guía sobre 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 usas LLM y recomendar recomendaciones emergentes de diseño y desarrollo de seguridad. (Ten en cuenta que las leyes y reglamentaciones también pueden imponer restricciones, pero tales consideraciones están fuera del alcance de esta guía).

Se recomiendan los siguientes pasos para compilar aplicaciones con LLM:

• Comprende los riesgos de seguridad de tu aplicación
• Considerar ajustes para mitigar los riesgos de seguridad
• Realizar pruebas de seguridad adecuadas para 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 un rendimiento apropiado 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 de evitar dañar a sus usuarios, por ejemplo, a través de la generación de lenguaje o contenido tóxico 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 el uso que hagas de ellos está sujeto a la Política de Uso Prohibido de IA Generativas. La API proporciona filtros de seguridad integrados para ayudar a abordar algunos problemas comunes del modelo de lenguaje, como el lenguaje tóxico y la incitación al odio o a la violencia, y la búsqueda de inclusión y evitar los estereotipos. Sin embargo, cada aplicación puede representar un conjunto de riesgos distinto para los usuarios. Por lo tanto, como propietario de la aplicación, eres responsable de conocer a tus usuarios y de los posibles daños que puede causar tu aplicación, y de asegurarte de que tu aplicación use los LLM de forma segura y responsable.

Como parte de esta evaluación, debes considerar la probabilidad de que se produzca el daño y determinar su gravedad y los pasos de mitigación. Por ejemplo, una app que genera ensayos basados en eventos reales debería tener más cuidado a la hora de evitar la información errónea, en comparación con una app que genera historias ficticias para entretenerse. Una buena manera de comenzar a explorar los posibles riesgos de seguridad es investigar a tus usuarios finales y a otras personas que podrían verse afectadas por los resultados de tu aplicación. Esto puede adoptar muchas formas, como la investigación de estudios de vanguardia en el dominio de tu app, la observación de cómo las personas usan apps similares, la ejecución de un estudio o una encuesta de usuarios, o la realización de 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 debes priorizar y cuánto debes hacer para tratar de prevenirlos es una decisión crítica, similar a clasificar errores en un proyecto de software. Una vez que hayas determinado las prioridades, puedes comenzar a pensar en los tipos de mitigaciones que serían más adecuadas. A menudo, los cambios simples pueden marcar la diferencia y reducir los riesgos.

Por ejemplo, cuando diseñes una aplicación, considera lo siguiente:

• Ajusta la salida del modelo para reflejar mejor lo que es aceptable en el contexto de tu aplicación. El ajuste puede hacer que el resultado 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 los resultados más seguros La entrada exacta que le brindas a un LLM puede marcar una diferencia en la calidad del resultado. Experimentar con instrucciones de entrada para encontrar lo que funciona de manera más segura en tu caso de uso vale la pena, ya que puedes proporcionar una UX que lo facilite. Por ejemplo, puedes restringir a los usuarios para que elijan solo de una lista desplegable de instrucciones de entrada, o bien ofrecer sugerencias en ventanas emergentes con frases descriptivas que consideres que funcionan de manera segura en el contexto de tu aplicación.

• Bloquea las entradas no seguras y filtra las salidas antes de que se muestren al usuario. En situaciones simples, se pueden usar listas de entidades bloqueadas para identificar y bloquear palabras o frases no seguras en instrucciones o respuestas, o requerir que revisores manuales modifiquen o bloqueen manualmente ese contenido.

• Usar clasificadores capacitados para etiquetar cada instrucción con posibles daños o indicadores adversarios Se pueden emplear diferentes estrategias para manejar la solicitud según el tipo de daño detectado. Por ejemplo, si la entrada es de naturaleza abiertamente adversaria o abusiva, se podría bloquear y, en su lugar, generar una respuesta predefinida.

  Sugerencia avanzada

  • Si los indicadores determinan que el resultado es dañino, la aplicación puede emplear las siguientes opciones:
    • Proporciona un mensaje de error o un resultado predefinido.
    • Vuelve a probar la instrucción, en caso de que se genere un resultado seguro alternativo, ya que a veces la misma instrucción generará diferentes resultados.

• Implementar protecciones contra el uso inadecuado deliberado, como asignar a cada usuario un ID único o imponer un límite al volumen de consultas de usuarios que se pueden enviar en un período determinado Otra medida es intentar brindar protección contra una posible inserción de instrucciones. Al igual que la inyección de SQL, la inyección de instrucciones permite que los usuarios maliciosos diseñen una instrucción de entrada que manipula la salida 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 es inherentemente menos riesgos. 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 una persona revisará), suelen implicar un riesgo menor. Entonces, por ejemplo, en lugar de crear una aplicación para escribir una respuesta de correo electrónico desde cero, puedes limitarla a expandir un esquema o sugerir frases alternativas.

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

Las pruebas son una parte clave de la compilación de aplicaciones sólidas y seguras, pero el alcance, el alcance y las estrategias de las pruebas variarán. Por ejemplo, es probable que un generador de haiku por diversión implique riesgos menos graves que, por ejemplo, una aplicación diseñada para que los bufetes de abogados las usen para resumir documentos legales y ayudar a redactar contratos. Sin embargo, el generador de haiku puede ser utilizado por una mayor variedad de usuarios, lo que significa que la posibilidad de intentos adversarios o incluso de entradas dañinas no deseadas puede ser mayor. El contexto de la implementación también es importante. Por ejemplo, se podría considerar que una aplicación con resultados revisados por expertos humanos antes de realizar cualquier acción puede considerarse menos probable que produzca resultados dañinos que una aplicación idéntica sin tal supervisión.

No es raro realizar varias iteraciones de cambios y pruebas antes de sentirte seguro de que estás listo para el lanzamiento, incluso para aplicaciones de riesgo relativamente bajo. Hay dos tipos de pruebas que son particularmente útiles para las aplicaciones de IA:

• Las comparativas de seguridad implican diseñar métricas de seguridad que reflejen las formas en que tu aplicación podría no ser segura en el contexto de cómo es probable que se use y, luego, probar su rendimiento en las métricas usando conjuntos de datos de evaluación. Te recomendamos que pienses en los niveles mínimos aceptables de métricas de seguridad antes de realizar las pruebas para que 1) puedas evaluar los resultados de la prueba en función de esas expectativas y 2) puedas recopilar el conjunto de datos de evaluación según 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 compilar tus propios conjuntos de datos de prueba con evaluadores humanos para adaptarlos al contexto de tu aplicación.
  • Si tienes más de una métrica, deberás decidir cómo sacrificarías un cambio si un cambio genera mejoras en una métrica en detrimento de otra. Al igual que con otras ingeniería de rendimiento, es posible que desees enfocarte en el peor de los casos en todo tu conjunto de evaluación en lugar del rendimiento promedio.

• Las pruebas adversarias implican intentar dañar tu aplicación de forma proactiva. El objetivo es identificar los puntos de debilidad para que puedas tomar medidas y solucionarlos según corresponda. Las pruebas adversarias pueden requerir un tiempo y un esfuerzo considerables de los evaluadores con experiencia en tu aplicación, pero cuanto más realices, mayores serán las probabilidades de detectar problemas, en especial los que ocurren poco o solo después de ejecuciones repetidas de la aplicación.

  • Las pruebas adversarias son un método para evaluar sistemáticamente un modelo de AA con la intención de aprender cómo se comporta cuando se le proporciona una entrada maliciosa o dañina de forma involuntaria:
    • Una entrada puede ser maliciosa cuando está claramente diseñada para producir una salida no segura o dañina, por ejemplo, cuando se le pide a un modelo de generación de texto que genere una incitación al odio sobre una religión en particular.
    • Una entrada es dañina de forma involuntaria cuando la entrada en sí puede ser inocua, pero produce un resultado perjudicial, por ejemplo, cuando se le pide a un modelo de generación de texto que describa a una persona de un origen étnico en particular y que recibe una salida racista.
  • Lo que distingue una prueba adversaria de una evaluación estándar es la composición de los datos usados para las pruebas. Para pruebas adversarias, selecciona los datos de prueba que tengan más probabilidades de generar resultados problemáticos por parte del modelo. Esto significa sondear el comportamiento del modelo para todos los tipos de daños posibles, incluidos ejemplos raros o inusuales y casos límite que son 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. Puedes consultar las prácticas de IA responsable de Google en equidad para obtener más detalles sobre lo que debes tener en cuenta cuando se compila un conjunto de datos de prueba.

    Sugerencias avanzadas

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

Supervisa para detectar problemas

Sin importar cuánto pruebes y mitigues, nunca puedes garantizar la perfección, así que planifica por adelantado cómo detectarás y abordarás los problemas que surjan. Los enfoques comunes incluyen configurar un canal supervisado para que los usuarios compartan comentarios (p.ej., calificaciones de Me gusta o No me gusta) y ejecutar un estudio de usuarios para solicitar comentarios de una combinación diversa de usuarios de forma proactiva, lo que es especialmente útil si los patrones de uso son diferentes a las expectativas.

Próximos pasos

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