Surveillance des écarts par rapport aux instructions

La surveillance des écarts par rapport aux instructions vérifie si l’agent interprète correctement les instructions de l’utilisateur lorsqu’une action peut avoir des conséquences importantes, par exemple lors d’un transfert de données sensibles, d’un accès à ces données ou d’une modification destructive. Le système examine de manière asynchrone le raisonnement et les actions du modèle. Il peut interrompre une conversation s’il détecte un problème potentiel.

Un signalement indique que les actions de l’agent doivent être examinées. Il ne prouve ni que l’utilisateur a enfreint une règle ni que l’agent a agi à l’encontre des instructions. Certains problèmes peuvent échapper au système, qui peut aussi signaler une activité légitime. Continuez donc à appliquer des mesures de protection dans votre application, notamment en exigeant une approbation humaine pour les actions susceptibles d’avoir des conséquences importantes.

Pour en savoir plus, consultez la présentation de la surveillance des écarts par rapport aux instructions 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 du mécanisme de conservation du contexte de la conversation.

Pour savoir comment gérer le contexte d’une conversation, consultez les sections sur la conservation du raisonnement d’un appel à l’autre, le mode WebSocket et le compactage. Configurer un webhook pour les alertes n’active pas l’arrêt automatique.

Traiter une requête bloquée

Lorsque le système de surveillance bloque une requête avant le début de la diffusion en continu, 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 qui utilisent la diffusion en continu doivent aussi gérer les erreurs survenant pendant la lecture du flux, même après réception de premiers résultats.

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 concernées, les appels d’outils et les enregistrements de l’application correspondants, conformément à vos règles 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 avec le travail prévu et d’examiner les modifications déjà effectuées.

L’API ne propose pas de mécanisme général pour reprendre une conversation interrompue par le système de surveillance.

La surveillance étant asynchrone, une action peut déjà être terminée lorsque le système détecte un problème potentiel. Le blocage d’une requête n’annule pas les actions antérieures.

Recevoir les alertes de sécurité d’un projet

Abonnez-vous à safety.alert.created pour acheminer les alertes de surveillance d’un projet API vers un système géré par votre équipe. Même si vous recevez ces alertes, vous devez gérer les erreurs renvoyées par les requêtes à l’API.

Pour chaque projet dont vous souhaitez recevoir les alertes, suivez les instructions de création de points de terminaison pour les webhooks. Consultez le guide des webhooks pour vérifier les signatures et gérer les accusés de réception, les nouvelles tentatives et les envois en double.

Le webhook contient l’identifiant de l’alerte, sans en fournir les détails :

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 lors du traitement en arrière-plan. Remplacez la valeur d’exemple alert_0123456789abcdef0123456789abcdef par la valeur de data.id reçue via le webhook. Le champ id de l’événement identifie l’événement du webhook, et non l’alerte. Utilisez une clé API autorisée pour ce même projet et disposant de l’autorisation 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)

Utilisez les valeurs de request_id et de response_id renvoyées pour retrouver les opérations concernées dans les enregistrements de votre application. La catégorie de l’alerte indique le type de problème à examiner. Lorsque request_paused vaut true, le système a bien enregistré le blocage de sécurité. Cela ne confirme ni l’arrêt de l’exécution ni l’annulation des actions antérieures. Vérifiez l’état de la tâche dans votre application ainsi que les enregistrements relatifs aux outils.

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). Lorsque reason a une valeur non nulle, ce champ décrit la catégorie de l’alerte, sans fournir de transcription ni de rapport d’enquête complet. Conservez les enregistrements dont vous avez besoin conformément aux règles de votre organisation en matière de données. Consultez la section Vos données pour connaître les options de gestion des données de l’API.

Si la récupération de l’alerte renvoie le statut 404 avec le code safety_alert_not_found, vérifiez l’identifiant de l’alerte et les identifiants d’accès au projet. Cette erreur peut survenir si l’enregistrement est introuvable, inaccessible ou incomplet. L’envoi et la récupération des alertes ne fournissent pas un historique d’audit complet.