Surveillance du désalignement

La surveillance du désalignement vérifie qu’un agent interprète correctement les instructions de l’utilisateur dans des situations aux conséquences importantes, comme le transfert de données sensibles, l’accès à ces données ou l’application de modifications destructives. Elle examine le raisonnement et les actions du modèle de manière asynchrone et peut interrompre une conversation lorsqu’elle détecte un problème potentiel.

Un signalement indique que les actions de l’agent doivent être examinées. Il ne prouve pas que l’utilisateur a enfreint une règle ni que l’agent a agi à l’encontre des instructions. La surveillance peut manquer certains problèmes ou signaler une activité légitime. Continuez donc à utiliser des mesures de protection dans votre application, notamment l’approbation humaine pour les actions aux conséquences importantes.

Pour en savoir plus, consultez la présentation de la surveillance du désalignement dans le centre d’aide.

Requêtes couvertes

Pour les modèles couverts par ce système, la surveillance et l’arrêt automatique dépendent de l’API utilisée pour la requête et de la manière dont elle conserve le contexte de la conversation :

Consultez les sections sur la conservation du raisonnement entre les appels, le mode WebSocket et le compactage pour savoir comment gérer le contexte de la conversation. La configuration d’un webhook d’alerte n’active pas l’arrêt automatique.

Gérez une requête interrompue

Lorsque la surveillance du désalignement bloque une requête avant le début du streaming, l’API renvoie le statut HTTP 403, avec le type d’erreur invalid_request_error et le code misalignment_policy_violation. Identifiez l’erreur à partir de son code plutôt que du texte du message. Les intégrations en streaming doivent également gérer les erreurs pendant la lecture du flux, même après avoir reçu des données en sortie.

Si votre application reçoit cette erreur :

1. Cessez de déclencher de nouvelles actions pour la conversation concernée. Ne relancez pas automatiquement le workflow bloqué.
2. Conservez les identifiants des requêtes et des réponses, les appels d’outils et les enregistrements de l’application pertinents, conformément à vos politiques de traitement des données.
3. Présentez les informations disponibles sur l’erreur à l’utilisateur ou à l’opérateur responsable de la tâche. Demandez-lui de comparer les actions de l’agent au travail prévu et d’examiner les modifications déjà effectuées.

L’API ne fournit pas de mécanisme général permettant de reprendre une conversation interrompue par la surveillance du désalignement.

La surveillance étant asynchrone, une action peut déjà être terminée lorsqu’un problème potentiel est détecté. L’interruption d’une requête n’annule pas les actions antérieures.

Recevez les alertes de sécurité des projets

Abonnez-vous à safety.alert.created pour acheminer les alertes de surveillance d’un projet API vers un système géré par votre équipe. La réception d’alertes ne remplace pas la gestion des erreurs des requêtes API.

Suivez les instructions de la section Création de points de terminaison de webhook pour chaque projet dont vous souhaitez recevoir les alertes. Consultez le guide des webhooks pour la vérification des signatures ainsi que les accusés de réception, les nouvelles tentatives et les envois en double.

Le webhook contient un identifiant d’alerte, et non les détails de l’alerte :

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

Après avoir vérifié le webhook et en avoir accusé réception, récupérez l’alerte dans votre traitement en arrière-plan. Remplacez la valeur d’exemple salert_123 par la valeur data.id du webhook. Le champ id de l’événement identifie l’événement webhook, et non l’alerte. Utilisez une clé API autorisée pour le même projet et disposant de la permission api.safety.alerts.read :

curl "https://api.openai.com/v1/safety/alerts/salert_123" \
  -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 = "salert_123";

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("salert_123")
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(), "salert_123")
	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("salert_123");
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("salert_123")
puts(alert.error_type)
puts(alert.reason)
puts(alert.request_paused)

Utilisez les valeurs request_id et response_id renvoyées pour retrouver le travail concerné dans les enregistrements de votre application. Considérez la catégorie de l’alerte comme un problème potentiel à examiner. Lorsque request_paused vaut true, un blocage de sécurité a bien été enregistré ; cela ne confirme pas que l’exécution s’est arrêtée ni que les actions antérieures ont été annulées. Vérifiez l’état de la tâche et les enregistrements des outils dans votre application.

Le champ reason de l’alerte peut valoir null, y compris pour les requêtes soumises à la politique de non-conservation des données (ZDR). Une valeur non nulle de reason décrit une catégorie ; il ne s’agit ni d’une transcription ni d’un rapport d’investigation complet. Conservez les enregistrements dont vous avez besoin conformément aux politiques de votre organisation en matière de données. Consultez Vos données pour connaître les options de contrôle des données de l’API.

Si la récupération renvoie 404 avec le code safety_alert_not_found, vérifiez l’identifiant de l’alerte et les informations d’authentification du projet. Des enregistrements manquants, inaccessibles ou incomplets peuvent provoquer cette erreur. L’envoi et la récupération des alertes ne fournissent pas un historique d’audit complet.