Para conhecer as medidas de proteção aplicadas pela OpenAI, consulte Classificadores de segurança, verificações de cibersegurança e monitoramento de desalinhamento. Se seu aplicativo atende menores de idade, siga também as Orientações para menores de 18 anos.
Use nossa API de Moderação gratuita
A API de Moderação da OpenAI é gratuita e pode ajudar a reduzir a frequência de conteúdo inseguro nas respostas geradas. Outra opção é desenvolver seu próprio sistema de filtragem de conteúdo, adaptado ao seu caso de uso.
Se seu aplicativo gera texto com a Responses API ou o Chat Completions, você também pode solicitar pontuações de moderação na requisição de geração.
Testes adversariais
Recomendamos realizar “red teaming” no seu aplicativo para garantir que ele seja resistente a entradas adversariais. Teste seu produto com uma ampla variedade de entradas e comportamentos de usuários, incluindo tanto um conjunto representativo quanto tentativas de fazer o aplicativo falhar. Ele sai do assunto? Alguém consegue redirecionar facilmente a funcionalidade por meio de injeções de prompt, como “ignore as instruções anteriores e faça isto no lugar”?
Participação humana no processo (HITL)
Sempre que possível, recomendamos que uma pessoa revise as saídas antes de serem usadas na prática. Isso é especialmente importante em áreas de alto risco e na geração de código. As pessoas responsáveis pela revisão devem conhecer as limitações do sistema e ter acesso a todas as informações necessárias para verificar as saídas (por exemplo, se o aplicativo resume anotações, a pessoa deve ter acesso fácil às anotações originais para consultá-las).
Engenharia de prompt
A “engenharia de prompt” pode ajudar a delimitar o assunto e o tom do texto gerado. Isso reduz a chance de produzir conteúdo indesejado, mesmo que um usuário tente induzir sua geração. Fornecer contexto adicional ao modelo (por exemplo, apresentando alguns exemplos de alta qualidade do comportamento desejado antes da nova entrada) pode facilitar o direcionamento das saídas do modelo para os resultados desejados.
“Conheça seu cliente” (KYC)
Em geral, os usuários devem precisar se cadastrar e fazer login para acessar seu serviço. Vincular o serviço a uma conta existente, como uma conta do Gmail, LinkedIn ou Facebook, pode ajudar, embora isso possa não ser adequado para todos os casos de uso. Exigir um cartão de crédito ou documento de identidade reduz ainda mais o risco.
Restrinja a entrada do usuário e limite os tokens de saída
Limitar a quantidade de texto que um usuário pode inserir no prompt ajuda a evitar injeções de prompt. Limitar o número de tokens de saída ajuda a reduzir a chance de uso indevido.
Restringir as opções de entrada ou saída, especialmente usando fontes confiáveis, reduz as possibilidades de uso indevido de um aplicativo.
Permitir que os usuários forneçam entradas por meio de listas suspensas com opções validadas (por exemplo, uma lista de filmes da Wikipédia) pode ser mais seguro do que permitir entradas de texto livre.
Sempre que possível, retornar saídas de um conjunto validado de materiais no backend pode ser mais seguro do que retornar conteúdo novo gerado pelo modelo (por exemplo, direcionar a dúvida de um cliente ao artigo de suporte existente mais adequado, em vez de tentar responder à dúvida do zero).
Permita que os usuários relatem problemas
Em geral, os usuários devem ter um meio facilmente acessível para relatar falhas de funcionamento ou outras preocupações sobre o comportamento do aplicativo (um endereço de e-mail divulgado, uma forma de abrir chamados etc.). Uma pessoa deve monitorar esse canal e responder conforme necessário.
Entenda e comunique as limitações
Por poderem gerar informações incorretas por alucinação, saídas ofensivas, vieses e outros problemas, os modelos de linguagem podem não ser adequados para todos os casos de uso sem modificações significativas. Considere se o modelo é adequado ao seu objetivo e avalie o desempenho da API com uma ampla variedade de entradas possíveis para identificar situações em que ele pode piorar. Leve em conta sua base de clientes e a variedade de entradas que eles usarão, e garanta que suas expectativas estejam alinhadas às capacidades do sistema.
A segurança e a proteção são muito importantes para nós na OpenAI.
Se você notar qualquer problema de segurança ou proteção ao desenvolver com a API ou em qualquer outro contexto relacionado à OpenAI, informe-o por meio do nosso Programa de Divulgação Coordenada de Vulnerabilidades.
Implemente identificadores de segurança
Enviar identificadores de segurança nas suas requisições pode ajudar a OpenAI a monitorar e detectar abusos. Isso permite que a OpenAI forneça à sua equipe feedback mais útil para tomar medidas caso detectemos alguma violação de política no seu aplicativo.
Os identificadores de segurança também podem ajudar sua equipe a responder mais rapidamente a abusos. Eles oferecem uma forma estável de associar atividades a um usuário final específico e reduzem a chance de que o uso indevido por um usuário interrompa o acesso do restante da organização.
Um identificador de segurança deve ser uma string que identifique cada usuário de forma única. Aplique uma função de hash ao nome de usuário ou endereço de e-mail para evitar nos enviar informações que permitam identificá-lo. Se você oferece uma prévia do seu produto a usuários que não fizeram login, pode enviar um ID de sessão no lugar.
Os identificadores de segurança são recomendados para produtos em que usuários individuais interagem
com um modelo, mas não são obrigatórios. Inclua identificadores de segurança nas suas requisições
à API com o parâmetro safety_identifier:
import 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);Nas requisições à Realtime API, forneça o mesmo identificador estável que preserva a privacidade
por meio do cabeçalho OpenAI-Safety-Identifier. Ao criar um segredo de cliente efêmero do Realtime,
inclua o cabeçalho na requisição feita pelo servidor que cria o
segredo, para que o identificador fique vinculado àquela sessão. Para requisições de conexão direta via WebSocket ou WebRTC
feitas a partir de um backend confiável, inclua o cabeçalho na
requisição de conexão.
Os identificadores de segurança não são transferidos entre APIs ou sessões. Se seu
aplicativo já envia safety_identifier nas requisições à Responses API, passe
o mesmo valor estável separadamente ao criar cada sessão Realtime
ou se conectar a ela.
Revogue chaves de API comprometidas
Se você acredita que uma chave de API foi exposta, usada indevidamente ou comprometida de outra forma, revogue-a imediatamente e substitua-a por uma nova chave. Acesse suas Configurações de segurança para ver todas as chaves de API e revogar as que estiverem comprometidas.
Orientações sobre CSAM
A OpenAI trabalhou com especialistas em segurança infantil, incluindo o NCMEC e a Thorn, para oferecer aos desenvolvedores orientações práticas para proteger crianças. Leia as orientações sobre CSAM.