Bonnes pratiques de sécurité

Pour connaître les protections appliquées par OpenAI, consultez les pages Classificateurs de sécurité, Vérifications de cybersécurité et Surveillance du désalignement. Si votre application s’adresse à des mineurs, suivez également les recommandations pour les moins de 18 ans.

Utilisez notre API Moderation gratuite

L’API Moderation d’OpenAI est gratuite et peut contribuer à réduire la fréquence des contenus dangereux dans vos réponses générées. Vous pouvez aussi développer votre propre système de filtrage de contenu adapté à votre cas d’usage.

Si votre application génère du texte avec l’API Responses ou Chat Completions, vous pouvez également demander des scores de modération dans la requête de génération.

Tests adversariaux

Nous vous recommandons de soumettre votre application à des tests de « red teaming » pour vérifier sa résistance aux entrées malveillantes. Testez votre produit avec un large éventail d’entrées et de comportements utilisateurs, couvrant à la fois des usages représentatifs et des tentatives de faire dysfonctionner votre application. S’écarte-t-elle du sujet ? Est-il facile de détourner la fonctionnalité par des attaques par injection de prompt, par exemple : « ignorez les instructions précédentes et faites plutôt ceci » ?

Intervention humaine dans la boucle (HITL)

Dans la mesure du possible, nous recommandons de faire vérifier les sorties par une personne avant leur utilisation concrète. Cette vérification est particulièrement importante dans les domaines à forts enjeux et pour la génération de code. Les personnes chargées de cette vérification doivent connaître les limites du système et avoir accès à toutes les informations nécessaires pour contrôler les sorties. Par exemple, si l’application résume des notes, elles doivent pouvoir consulter facilement les notes originales.

Ingénierie de prompts

L’« ingénierie de prompts » peut aider à encadrer le sujet et le ton du texte généré. Elle réduit ainsi le risque de produire du contenu indésirable, même si un utilisateur cherche à en obtenir. Fournir davantage de contexte au modèle, par exemple quelques exemples de qualité du comportement attendu avant la nouvelle entrée, peut faciliter l’orientation des sorties du modèle dans le sens souhaité.

Connaissance du client (KYC)

En règle générale, les utilisateurs devraient devoir s’inscrire et se connecter pour accéder à votre service. Associer ce service à un compte existant, par exemple via une connexion Gmail, LinkedIn ou Facebook, peut être utile, même si cette approche ne convient pas à tous les cas d’usage. Exiger une carte de crédit ou une carte d’identité réduit encore les risques.

Encadrez les entrées utilisateur et limitez les tokens de sortie

Limiter la quantité de texte qu’un utilisateur peut saisir dans le prompt aide à éviter les attaques par injection de prompt. Limiter le nombre de tokens de sortie contribue à réduire le risque d’utilisation abusive.

Restreindre l’éventail des entrées ou des sorties, notamment en s’appuyant sur des sources fiables, réduit les possibilités d’utilisation abusive d’une application.

Permettre aux utilisateurs de saisir leurs entrées au moyen de listes déroulantes validées, par exemple une liste de films sur Wikipédia, peut être plus sûr que d’autoriser la saisie de texte libre.

Dans la mesure du possible, renvoyer des réponses issues d’un ensemble de contenus validés côté serveur peut être plus sûr que de générer du contenu inédit. Par exemple, vous pouvez orienter un client vers l’article d’assistance existant qui correspond le mieux à sa question, plutôt que de tenter de formuler une réponse de toutes pièces.

Permettez aux utilisateurs de signaler des problèmes

En règle générale, les utilisateurs devraient disposer d’un moyen facilement accessible pour signaler un dysfonctionnement ou toute autre préoccupation concernant le comportement de l’application : adresse e-mail affichée, formulaire de création de ticket, etc. Une personne devrait assurer le suivi de ces signalements et y répondre de manière appropriée.

Comprenez les limites et communiquez-les

Hallucinations produisant des informations inexactes, sorties offensantes, biais et autres problèmes : les modèles de langage peuvent nécessiter des modifications importantes pour convenir à certains cas d’usage. Déterminez si le modèle est adapté à votre objectif et évaluez les performances de l’API sur un large éventail d’entrées possibles afin de repérer les cas où elles pourraient se dégrader. Tenez compte de votre clientèle et des types d’entrées qu’elle utilisera, et veillez à ce que ses attentes restent réalistes.

Mettez en place des identifiants de sécurité

L’envoi d’identifiants de sécurité dans vos requêtes peut aider OpenAI à surveiller et à détecter les abus. Si nous détectons des violations de nos règles dans votre application, ces identifiants nous permettent de fournir à votre équipe des informations plus précises pour agir.

Les identifiants de sécurité peuvent également aider votre équipe à réagir plus rapidement aux abus. Ils offrent un moyen stable de relier une activité à un utilisateur final précis et réduisent le risque que les abus d’un seul utilisateur perturbent l’accès pour le reste de votre organisation.

Un identifiant de sécurité doit être une chaîne de caractères qui identifie chaque utilisateur de manière unique. Hachez le nom d’utilisateur ou l’adresse e-mail pour éviter de nous envoyer des informations permettant de l’identifier. Si vous proposez un aperçu de votre produit à des utilisateurs non connectés, vous pouvez envoyer un identifiant de session à la place.

Les identifiants de sécurité sont recommandés pour les produits où les utilisateurs interagissent individuellement avec un modèle, mais ils ne sont pas obligatoires. Incluez des identifiants de sécurité dans vos requêtes à l’API à l’aide du paramètre safety_identifier :

1
2
3
4
5
6
7
8
9
10
11
12import OpenAI from "openai";

const client = new OpenAI();

const response = await client.chat.completions.create({
  model: "gpt-6-astra",
  messages: [{ role: "user", content: "This is a test" }],
  max_completion_tokens: 5,
  safety_identifier: "user_123456",
});

console.log(response.choices[0].message.content);

1
2
3
4
5
6
7
8
9
10from openai import OpenAI

client = OpenAI()

response = client.chat.completions.create(
    model="gpt-6-astra",
    messages=[{"role": "user", "content": "This is a test"}],
    max_completion_tokens=5,
    safety_identifier="user_123456",
)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22package main

import (
	"context"
	"fmt"

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

func main() {
	client := openai.NewClient()
	response, err := client.Chat.Completions.New(context.Background(), openai.ChatCompletionNewParams{
		Model:               "gpt-6-astra",
		Messages:            []openai.ChatCompletionMessageParamUnion{openai.UserMessage("This is a test")},
		MaxCompletionTokens: openai.Int(5),
		SafetyIdentifier:    openai.String("user_123456"),
	})
	if err != nil {
		panic(err)
	}
	fmt.Println(response.Choices[0].Message.Content)
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14import com.openai.client.OpenAIClient;
import com.openai.client.okhttp.OpenAIOkHttpClient;
import com.openai.models.chat.completions.ChatCompletionCreateParams;

ChatCompletionCreateParams params =
    ChatCompletionCreateParams.builder()
        .model("gpt-6-astra")
        .addUserMessage("Help me plan a study schedule.")
        .safetyIdentifier("user_1234")
        .build();

client.chat().completions().create(params).choices().stream()
    .flatMap(choice -> choice.message().content().stream())
    .forEach(System.out::println);

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15require "openai"

client = OpenAI::Client.new
completion = client.chat.completions.create(
  model: "gpt-6-astra",
  messages: [
    {
      role: :user,
      content: "Help me plan a study schedule."
    }
  ],
  safety_identifier: "user_1234"
)

puts(completion.choices.fetch(0).message.content)

1
2
3
4
5
6
7
8
9
10
11curl https://api.openai.com/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-d '{
"model": "gpt-6-astra",
"messages": [
{"role": "user", "content": "This is a test"}
],
"max_completion_tokens": 5,
"safety_identifier": "user123456"
}'

Pour les requêtes à Realtime API, fournissez le même identifiant stable et respectueux de la vie privée dans l’en-tête OpenAI-Safety-Identifier. Lorsque vous créez un secret client Realtime éphémère, incluez cet en-tête dans la requête côté serveur qui crée le secret afin d’associer l’identifiant à cette session. Pour les requêtes de connexion directe WebSocket ou WebRTC effectuées depuis un backend de confiance, incluez cet en-tête dans la requête de connexion.

Les identifiants de sécurité ne sont pas transmis automatiquement d’une API ou d’une session à l’autre. Si votre application envoie déjà safety_identifier dans les requêtes à l’API Responses, transmettez séparément la même valeur stable lors de la création de chaque session Realtime ou de la connexion à celle-ci.

Révoquez les clés API compromises

Si vous pensez qu’une clé API a été exposée, utilisée de manière abusive ou compromise d’une autre façon, révoquez-la rapidement et remplacez-la par une nouvelle clé. Accédez à vos paramètres de sécurité pour afficher toutes les clés API et révoquer celles qui sont compromises.

Recommandations concernant le matériel pédopornographique

OpenAI a travaillé avec des spécialistes de la protection de l’enfance, notamment NCMEC et Thorn, pour proposer aux développeurs des conseils pratiques afin de protéger les enfants. Consultez les recommandations concernant le matériel pédopornographique.