Introducción a las barreras de protección y controles en Microsoft Foundry

Microsoft Foundry proporciona guías de seguridad y protección que usted puede aplicar a los modelos y agentes principales. Los límites de protección del agente están en versión preliminar. Las barreras de seguridad constan de controles. Los controles definen un riesgo que se debe detectar, los puntos de intervención para escanear el riesgo y la acción de respuesta que se debe tomar en el modelo o agente cuando se detecta el riesgo.

Un límite de protección es una colección denominada de controles. Las variaciones en las configuraciones de API y el diseño de aplicaciones pueden afectar a las finalizaciones y, por tanto, al comportamiento de filtrado.

Los riesgos se marcan mediante modelos de clasificación diseñados para detectar contenido dañino. Se admiten cuatro puntos de intervención:

• Entrada del usuario : mensaje enviado a un modelo o agente.
• Llamada a herramienta (versión preliminar): la acción y los datos que el agente propone enviar a una herramienta. Solo agentes.
• Respuesta de la herramienta (versión preliminar): el contenido devuelto de una herramienta al agente. Solo agentes.
• Salida : la finalización final devuelta al usuario.

Para obtener más información sobre los puntos de intervención, vea Puntos de intervención y controles.

Requisitos previos

• Una suscripción Azure. Cree uno gratis.
• Un proyecto Microsoft Foundry.
• Al menos una implementación de modelos en el proyecto.
• Rol de propietario de cuenta de Azure IA.
  • Acceso a un rol que le permite crear un recurso Foundry, como Azure Propietario de IA de Cuenta o Azure Propietario de IA en la suscripción o grupo de recursos. Para obtener más información sobre los permisos, consulte Control de acceso basado en roles para Microsoft Foundry.

Límites de protección para agentes frente a modelos

Un guardarraíl individual de Foundry se puede aplicar a uno o varios modelos y a uno o varios agentes en un proyecto. Algunos controles dentro de una directriz pueden no ser relevantes para los modelos porque el riesgo, el punto de intervención o la acción son específicos del comportamiento del agente o de las invocaciones de herramientas. Esos controles no se ejecutan en modelos con esa barrera de protección.

Todavía no se admiten algunos riesgos en la versión preliminar para los agentes. Cuando los controles que implican esos riesgos se agregan a una barrera de protección y la barrera de protección se aplica a un agente, esos controles no tienen efecto en ese agente. Todavía se aplican a los modelos que usan la misma barrera de protección.

Aplicabilidad de riesgos

En la tabla siguiente se resumen los riesgos que se aplican a los modelos y agentes:

Niveles de gravedad

Para los riesgos de contenido (Odio, Sexual, Auto-daño, Violencia), cada control usa un umbral de nivel de gravedad que determina qué contenido se marca:

Para obtener un desglose detallado de lo que detecta cada nivel de gravedad, consulte Categorías de filtrado de contenido.

Aplicabilidad del punto de intervención

En la tabla siguiente se resumen los puntos de intervención que se aplican a los modelos y agentes:

Ejemplo: Comportamiento de invalidación de barrera de protección

Tenga en cuenta este escenario:

• Un despliegue de un modelo cuenta con un control con la detección de violencia establecida en Alta para la entrada y salida de usuario.
• Un agente que usa ese modelo tiene un control con detección de violencia establecido en Bajo para la entrada y salida del usuario. El agente no tiene absolutamente ningún control para la detección de violencia en las llamadas y respuestas de las herramientas.

Aplicabilidad de acciones

Cuando un control detecta un riesgo, puede realizar una de estas dos acciones. En la tabla siguiente se resumen las acciones que se aplican a los modelos y agentes:

Herencia e invalidación de límites de protección

Escenario de ejemplo:

• Un despliegue de un modelo cuenta con un control con la detección de violencia establecida en Alta para la entrada y salida de usuario.
• Un agente que usa ese modelo tiene un control con detección de violencia establecido en Bajo para la entrada y salida del usuario. El agente no tiene controles para detectar violencia en las llamadas y respuestas de herramientas.

Comportamiento esperado para la detección de violencia en ese agente:

Dada la configuración anterior, aquí se muestra cómo funciona la detección de violencia en cada fase:

• Las consultas de usuario al agente se examinan en busca de violencia en un nivel bajo
• Las solicitudes de herramienta generadas internamente hacia el agente por su modelo subyacente, incluyendo el contenido enviado a dicha herramienta durante la ejecución de la solicitud, no serán examinadas en busca de violencia.
• La respuesta de la herramienta no se analizará en busca de violencia
• La respuesta final que se entrega al usuario en respuesta a su consulta original se examina en busca de violencia a un nivel bajo.

Límites de protección predeterminados

De forma predeterminada, a los modelos se les asigna la directriz Microsoft.DefaultV2. Para obtener más información sobre qué controles se incluyen, consulte Filtrado de contenido.

La asignación de barreras de seguridad predeterminada para los agentes sigue estas reglas:

• Si asigna una barrera de seguridad personalizada a un agente, se utiliza esa barrera de seguridad.
• Si no se asigna ningún límite de protección personalizado, el agente hereda el límite de protección de la implementación de su modelo base.
• Un agente solo usa el Microsoft. DefaultV2 límite de protección si su implementación del modelo usa esa barrera de protección o si la asigna explícitamente.

Solución de problemas

La barrera de protección no se aplica al agente

Síntoma: El comportamiento del agente no coincide con la configuración de límite de protección asignada.

Causas:

• Guardrail contiene controles con riesgos de vista previa que aún no se admiten para los agentes (Resaltado, Solidez)
• Agente que usa la barrera de protección del modelo en lugar de la barrera de protección asignada

Solución:

• Comprobación de la barrera de protección asignada mediante Fundición de IA de Azure portal o SDK
• Compruebe que los controles de la barrera de seguridad no se basan en riesgos no admitidos por el agente.
• Asignar explícitamente límite de protección al agente para invalidar los valores predeterminados del modelo

Contenido marcado inesperadamente

Síntoma: Contenido legítimo bloqueado por barrera de protección.

Causas:

• Nivel de gravedad establecido demasiado restrictivamente (bloqueo alto)
• El modelo de clasificación detectó un patrón de caso límite.

Solución:

• Revisar la configuración del nivel de gravedad para la categoría de riesgo afectada
• Prueba con diferentes niveles de gravedad para encontrar el umbral adecuado
• Para los falsos positivos persistentes, póngase en contacto con el soporte técnico de Azure para revisar la clasificación.

No se examinan las llamadas a la herramienta

Síntoma: El contenido dañino pasa a través de llamadas o respuestas de herramientas.

Causas:

• Puntos de intervención de llamada a herramientas y respuesta a herramientas no configurados en la barrera de protección
• Uso de características en versión preliminar que pueden no estar totalmente habilitadas

Solución:

• Verificar que la barrera de protección incluya controles para los puntos de intervención de llamada y respuesta de herramientas
• Asegúrese de que las características de la versión preliminar del servicio Foundry Agent estén habilitadas para el proyecto.

Pasos siguientes

• Configurar límites de protección y controles
• Más información sobre los puntos de intervención y los controles
• Comprender el filtrado de contenido en Azure OpenAI
• Configurar filtros de contenido para Azure OpenAI