Bonnes pratiques de sécurité

Pour connaître les mesures de protection qu’OpenAI applique, consultez les pages sur les classificateurs de sécurité, les contrôles de cybersécurité et la surveillance des défauts d’alignement. Si des mineurs utilisent votre application, suivez également les recommandations pour les moins de 18 ans.

Utilisez notre API de modération gratuite

L’API de modération d’OpenAI est gratuite et peut vous aider à réduire la fréquence des contenus dangereux dans les réponses générées. Vous pouvez aussi développer votre propre système de filtrage de contenu en fonction de votre cas d’usage.

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

Tests adversariaux

Nous vous recommandons de soumettre votre application à un exercice de « red teaming » pour vérifier qu’elle résiste aux entrées malveillantes. Testez votre produit avec des entrées et des comportements variés. Couvrez aussi bien les usages représentatifs que les tentatives de « faire dérailler » votre application. S’écarte-t-elle du sujet ? Quelqu’un peut-il facilement détourner la fonctionnalité par une attaque par injection de prompt, par exemple avec « Ignore les instructions précédentes et fais ceci à la place » ?

Supervision humaine (HITL)

Dans la mesure du possible, nous vous recommandons de faire vérifier les résultats par une personne avant de les utiliser en pratique. 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 la vérification doivent connaître les limites du système et avoir accès aux informations nécessaires pour contrôler les résultats. Par exemple, si l’application résume des notes, la personne qui vérifie le résumé doit pouvoir consulter facilement les notes d’origine.

Ingénierie de prompts

L’« ingénierie de prompts » peut vous aider à délimiter le sujet du texte généré et à en définir le ton. Vous réduisez ainsi le risque de générer du contenu indésirable, même si un utilisateur cherche à en obtenir. En donnant davantage de contexte au modèle, vous pouvez orienter plus facilement ses réponses dans le sens souhaité. Par exemple, avant chaque nouvelle entrée, vous pouvez lui fournir quelques exemples de qualité qui illustrent le comportement attendu.

« Connaissance du client » (KYC)

En règle générale, demandez aux utilisateurs de s’inscrire et de se connecter pour accéder à votre service. Leur permettre de se connecter avec un compte existant, par exemple Gmail, LinkedIn ou Facebook, peut être utile, même si cette solution ne convient pas à tous les cas d’usage. Exiger une carte de crédit ou une carte d’identité réduit davantage le risque.

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

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

Restreindre les entrées ou les sorties possibles, notamment en les sélectionnant dans des sources fiables, limite les possibilités d’utilisation abusive de l’application.

Il peut être plus sûr de laisser les utilisateurs choisir parmi les valeurs validées d’une liste déroulante (par exemple, une liste de films sur Wikipédia) que de leur proposer un champ de texte libre.

Lorsque c’est possible, il peut être plus sûr de renvoyer un contenu issu d’un ensemble de ressources validées côté serveur que de générer un nouveau contenu. Par exemple, vous pouvez orienter un client vers l’article d’assistance existant qui répond le mieux à sa question plutôt que de tenter de rédiger une réponse de toutes pièces.

Permettez aux utilisateurs de signaler des problèmes

En règle générale, les utilisateurs devraient pouvoir signaler facilement un dysfonctionnement ou toute autre préoccupation concernant le comportement de l’application. Vous pouvez par exemple afficher une adresse e-mail ou proposer un formulaire de ticket d’assistance. Confiez le suivi de ces signalements à une personne qui pourra y répondre de manière appropriée.

Identifiez et expliquez les limites du modèle

Les modèles de langage peuvent inventer des informations erronées, produire des réponses offensantes ou présenter des biais, entre autres limites. Certains cas d’usage peuvent donc nécessiter des modifications importantes. Vérifiez que le modèle convient à votre objectif et évaluez les performances de l’API sur un large éventail d’entrées possibles pour repérer les situations où elle risque d’être moins performante. Tenez compte de votre clientèle et de la diversité des entrées qu’elle utilisera. Veillez à ce que vos clients sachent ce qu’ils peuvent raisonnablement attendre du modèle.

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 une infraction à nos politiques dans votre application, ces identifiants nous permettent de fournir à votre équipe des indications plus précises pour qu’elle puisse agir.

Les identifiants de sécurité peuvent aussi aider votre équipe à réagir plus rapidement aux abus. Ils permettent de rattacher de manière fiable une activité à un utilisateur final précis et réduisent le risque qu’un usage abusif de sa part perturbe l’accès au service pour le reste de votre organisation.

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

Les identifiants de sécurité sont recommandés pour les produits dans lesquels des utilisateurs interagissent individuellement avec un modèle, mais ils restent facultatifs. Pour les inclure dans vos requêtes API, utilisez le 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 l’API Images, incluez safety_identifier dans chaque requête de génération d’images (POST /v1/images/generations) et de modification d’image (POST /v1/images/edits). Transmettez-le dans une propriété JSON pour les requêtes JSON ou dans un champ de formulaire pour les requêtes de modification d’image au format multipart. Au sein de votre organisation, utilisez le même identifiant stable pour toutes les requêtes d’un même utilisateur final. Sa longueur ne doit pas dépasser 128 caractères.

Le paramètre user de l’API Images est obsolète. Pour effectuer la migration, transmettez l’identifiant que vous fournissiez dans user via le paramètre safety_identifier. L’API continue de prendre en charge les requêtes existantes qui utilisent user. Si vous fournissez les deux champs, safety_identifier est prioritaire dès lors que sa valeur n’est pas vide. Si safety_identifier est absent, vaut null ou contient une chaîne vide, l’API utilise user si ce champ est disponible.

Pour les requêtes adressées à la Realtime API, transmettez le même identifiant stable et respectueux de la confidentialité dans l’en-tête OpenAI-Safety-Identifier. Lorsque vous créez un secret client éphémère pour Realtime, incluez cet en-tête dans la requête côté serveur qui crée le secret afin d’associer l’identifiant à la session. Si vous établissez une connexion WebSocket ou WebRTC directe depuis un serveur 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 ses requêtes à l’API Responses, transmettez séparément la même valeur stable dans chaque requête à l’API Images, ainsi qu’à chaque création de session Realtime ou connexion à une session Realtime.

Révoquez les clés API compromises

Si vous pensez qu’une clé API a été divulgué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é. Ouvrez vos paramètres de sécurité pour afficher toutes vos 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, dont le NCMEC et Thorn, pour proposer aux développeurs des conseils pratiques sur la protection des enfants. Consultez les recommandations concernant le matériel pédopornographique.