For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navegação principal

Monitoramento de desalinhamento

Lide com conversas interrompidas e alertas de segurança do projeto.

O monitoramento de desalinhamento verifica se um agente está interpretando corretamente as instruções do usuário em contextos com consequências importantes, como transferir dados sensíveis, acessar dados sensíveis ou fazer alterações destrutivas. Ele analisa o raciocínio e as ações do modelo de forma assíncrona e pode interromper uma conversa ao identificar um possível problema.

Uma sinalização indica que as ações do agente precisam de revisão. Ela não comprova que o usuário violou uma política ou que o agente agiu de forma contrária às instruções. O monitoramento pode deixar passar problemas ou sinalizar atividades legítimas. Por isso, continue usando medidas de proteção no aplicativo, incluindo aprovação humana para ações com consequências importantes.

Para mais contexto, consulte a visão geral do monitoramento de desalinhamento na Central de Ajuda.

Cobertura das solicitações

Para os modelos cobertos por este sistema, o monitoramento e a interrupção automática dependem da API usada na solicitação e de como ela preserva o contexto da conversa:

SolicitaçõesComportamento
Solicitações à Responses API que usam raciocínio persistido, WebSockets ou compactação da OpenAIMonitoradas. O sistema pode identificar continuações de uma conversa e bloquear a continuidade da execução.
Solicitações à Responses API que não usam nenhum desses mecanismosMonitoradas. Os webhooks configurados podem receber alertas, mas o sistema não interrompe a conversa automaticamente.
Solicitações à API chat completionsNão cobertas por este sistema de monitoramento. Outras verificações de segurança continuam se aplicando.

Consulte preservação do raciocínio entre chamadas, modo WebSocket e compactação para obter orientações sobre o contexto da conversa. Configurar um webhook de alertas não habilita a interrupção automática.

Lide com uma solicitação interrompida

Quando o monitoramento de desalinhamento bloqueia uma solicitação antes do início do streaming, a API retorna HTTP 403, com o tipo de erro invalid_request_error e o código misalignment_policy_violation. Identifique o erro pelo código, em vez do texto da mensagem. As integrações com streaming também devem tratar erros durante o consumo do fluxo, mesmo depois de receber dados de saída.

Se o seu aplicativo receber esse erro:

  1. Pare de encaminhar novas ações para a conversa afetada. Não tente executar novamente o fluxo de trabalho bloqueado de forma automática.
  2. Preserve os IDs de solicitação e resposta, as chamadas de ferramentas e os registros do aplicativo relevantes, de acordo com suas políticas de tratamento de dados.
  3. Mostre as informações disponíveis sobre o erro ao usuário ou operador responsável pela tarefa. Peça que ele compare as ações do agente com o trabalho pretendido e revise as alterações já feitas.

A API não oferece uma forma geral de retomar uma conversa interrompida pelo monitoramento de desalinhamento.

Como o monitoramento é assíncrono, uma ação pode já ter sido concluída quando ele identifica um possível problema. Interromper uma solicitação não desfaz ações anteriores.

Receba alertas de segurança do projeto

Inscreva-se em safety.alert.created para encaminhar alertas de monitoramento de um projeto de API a um sistema operado pela sua equipe. Receber alertas não substitui o tratamento de erros nas solicitações à API.

Siga as instruções de Criação de endpoints de webhook para cada projeto cujos alertas você deseja receber. Consulte o guia de Webhooks para saber mais sobre verificação de assinaturas, confirmações de recebimento, novas tentativas e entregas duplicadas.

O webhook contém um ID de alerta, em vez dos detalhes do alerta:

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

Após verificar o webhook e confirmar seu recebimento, recupere o alerta durante o processamento em segundo plano. Substitua o valor de exemplo salert_123 por data.id do webhook. O id do evento identifica o evento de webhook, e não o alerta. Use uma chave de API autorizada para o mesmo projeto com a permissão api.safety.alerts.read:

curl "https://api.openai.com/v1/safety/alerts/salert_123" \
  -H "Authorization: Bearer ${OPENAI_API_KEY}"
Recupere um alerta de segurança do projeto
# 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)

Use os valores retornados de request_id e response_id para localizar o trabalho afetado nos registros do seu aplicativo. Trate a categoria do alerta como um possível problema a investigar. Quando request_paused é true, o bloqueio de segurança foi registrado com sucesso; isso não confirma que a execução foi interrompida nem que as ações anteriores foram revertidas. Verifique o estado da tarefa e os registros das ferramentas no seu aplicativo.

O campo reason do alerta pode ser null, inclusive em solicitações com zero retenção de dados (ZDR). Um reason não nulo é uma descrição da categoria, não uma transcrição nem um relatório completo de investigação. Mantenha os registros necessários de acordo com as políticas de dados da sua organização. Consulte Seus dados para saber mais sobre os controles de dados da API.

Se a recuperação retornar 404 com o código safety_alert_not_found, verifique o ID do alerta e as credenciais do projeto. Registros ausentes, inacessíveis ou incompletos podem retornar esse erro. A entrega e a recuperação de alertas não fornecem um histórico completo de auditoria.