Monitoreo de desalineación

El monitoreo de desalineación verifica si un agente interpreta correctamente las instrucciones del usuario en situaciones en las que sus acciones pueden tener consecuencias importantes, como transferir datos sensibles, acceder a ellos o realizar cambios destructivos. El sistema revisa de forma asíncrona el razonamiento y las acciones del modelo y puede detener una conversación si detecta un posible problema.

Si el sistema marca la actividad del agente, es necesario revisar sus acciones. Esto no demuestra que el usuario haya infringido una política ni que el agente haya actuado en contra de las instrucciones. El sistema puede pasar por alto problemas o marcar actividades legítimas. Por eso, sigue aplicando medidas de protección en tu aplicación, incluida la aprobación humana para acciones que puedan tener consecuencias importantes.

Para obtener más información, consulta la descripción general del monitoreo de desalineación en el Centro de ayuda.

Solicitudes cubiertas

En los modelos que cubre este sistema, el monitoreo y la detención automática dependen de la API que se use para la solicitud y de cómo se conserve el contexto de la conversación:

Para saber cómo gestionar el contexto de la conversación, consulta cómo conservar el razonamiento entre llamadas, cómo usar el modo WebSocket y cómo funciona la compactación. Configurar un webhook para recibir alertas no habilita la detención automática.

Cómo gestionar una solicitud detenida

Cuando el sistema de monitoreo de desalineación bloquea una solicitud antes de que comience la transmisión, la API devuelve el estado HTTP 403, con el tipo de error invalid_request_error y el código misalignment_policy_violation. Identifica el error por su código, no por el texto del mensaje. Las integraciones que usan transmisión también deben gestionar los errores que se produzcan al leer el flujo de datos, incluso si ya recibieron parte de la respuesta.

Si tu aplicación recibe este error:

1. Deja de enviar acciones para la conversación afectada. No vuelvas a intentar el flujo de trabajo bloqueado de forma automática.
2. Conserva los identificadores de las solicitudes y respuestas pertinentes, las llamadas a herramientas y los registros de la aplicación de acuerdo con tus políticas de manejo de datos.
3. Muestra la información disponible sobre el error al usuario u operador responsable de la tarea. Pídele que compare las acciones del agente con el trabajo previsto y revise los cambios que ya se hayan realizado.

La API no ofrece un mecanismo general para reanudar una conversación detenida por el sistema de monitoreo de desalineación.

Como el monitoreo es asíncrono, es posible que una acción ya se haya completado cuando el sistema detecte un posible problema. Detener una solicitud no revierte las acciones anteriores.

Cómo recibir alertas de seguridad del proyecto

Suscríbete a safety.alert.created para enviar las alertas de monitoreo de un proyecto de la API a un sistema que administre tu equipo. Aunque recibas alertas, también debes gestionar los errores de las solicitudes a la API.

Sigue las instrucciones para crear puntos de acceso para webhooks en cada proyecto del que quieras recibir alertas. Consulta la guía de webhooks para saber cómo verificar las firmas y cómo confirmar la recepción y gestionar los reintentos y las entregas duplicadas.

El webhook contiene el identificador de la alerta, sin los detalles:

123456789{
  "object": "event",
  "id": "evt_123",
  "type": "safety.alert.created",
  "created_at": 1787659200,
  "data": {
    "id": "alert_0123456789abcdef0123456789abcdef"
  }
}

Después de verificar el webhook y confirmar su recepción, recupera la alerta durante el procesamiento en segundo plano. Reemplaza el valor de ejemplo alert_0123456789abcdef0123456789abcdef por el valor de data.id del webhook. El campo id del evento identifica el evento del webhook, no la alerta. Usa una clave de API autorizada para ese mismo proyecto que tenga el permiso api.safety.alerts.read:

curl "https://api.openai.com/v1/safety/alerts/alert_0123456789abcdef0123456789abcdef" \
  -H "Authorization: Bearer ${OPENAI_API_KEY}"

1
2
3
4
5
6
7
8// Replace the illustrative IDs and URLs below with your own resource values.
import OpenAI from "openai";

const client = new OpenAI();
const alertId = "alert_0123456789abcdef0123456789abcdef";

const alert = await client.safety.alerts.retrieve(alertId);
console.log(alert.error_type, alert.reason, alert.response_id);

1
2
3
4
5
6
7# Replace the illustrative IDs and URLs below with your own resource values.

from openai import OpenAI

client = OpenAI()
alert = client.safety.alerts.retrieve("alert_0123456789abcdef0123456789abcdef")
print(alert.error_type, alert.reason)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20// Replace the illustrative IDs and URLs below with your own resource values.
package main

import (
	"context"
	"fmt"

	"github.com/openai/openai-go/v3"
)

func main() {
	client := openai.NewClient()
	alert, err := client.Safety.Alerts.Get(context.Background(), "alert_0123456789abcdef0123456789abcdef")
	if err != nil {
		panic(err)
	}
	fmt.Println(alert.ErrorType)
	fmt.Println(alert.Reason)
	fmt.Println(alert.RequestPaused)
}

1
2
3
4
5
6
7// Replace the illustrative IDs and URLs below with your own resource values.
import com.openai.models.safety.alerts.SafetyAlert;

SafetyAlert alert = client.safety().alerts().retrieve("alert_0123456789abcdef0123456789abcdef");
System.out.println(alert.errorType());
alert.reason().ifPresent(System.out::println);
System.out.println(alert.requestPaused());

1
2
3
4
5
6
7
8# Replace the illustrative IDs and URLs below with your own resource values.
require "openai"

client = OpenAI::Client.new
alert = client.safety.alerts.retrieve("alert_0123456789abcdef0123456789abcdef")
puts(alert.error_type)
puts(alert.reason)
puts(alert.request_paused)

Usa los valores de request_id y response_id que devuelve la API para localizar la actividad afectada en los registros de tu aplicación. La categoría de la alerta indica un posible problema que debes investigar. Cuando request_paused es true, el sistema registró correctamente un bloqueo de seguridad. Esto no confirma que la ejecución se haya detenido ni que se hayan revertido las acciones anteriores. Comprueba el estado de la tarea en tu aplicación y revisa los registros de las herramientas.

El campo reason de la alerta puede tener el valor null, incluso en solicitudes con retención cero de datos (ZDR). Si reason tiene un valor distinto de nulo, contiene una descripción de la categoría, no una transcripción ni un informe completo de la investigación. Conserva los registros que necesites de acuerdo con las políticas de datos de tu organización. Consulta Tus datos para conocer los controles de datos de la API.

Si al recuperar la alerta recibes el estado 404 con el código safety_alert_not_found, verifica el identificador de la alerta y las credenciales del proyecto. Este error puede aparecer si el registro no existe, no es accesible o está incompleto. La entrega y la recuperación de alertas no proporcionan un historial de auditoría completo.