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
Theme

Monitoramento de desalinhamento

Saiba como lidar com conversas interrompidas e alertas de segurança do projeto.

O monitoramento de desalinhamento verifica se o agente interpreta corretamente as instruções do usuário em situações de maior impacto, como transferir ou acessar dados sensíveis ou fazer alterações destrutivas. O sistema 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. Por si só, ela não comprova que o usuário violou uma política nem que o agente agiu contra as instruções. O monitoramento pode deixar passar problemas ou sinalizar atividades legítimas. Por isso, continue usando medidas de segurança no aplicativo, incluindo a aprovação humana para ações de maior impacto.

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

Quais solicitações são monitoradas

Para os modelos cobertos por esse sistema, o monitoramento e a interrupção automática dependem da API usada na solicitação e de como o contexto da conversa é preservado.

Solicitações Comportamento
Solicitações à API Responses que usam raciocínio persistido, WebSockets ou compactação da OpenAI São monitoradas. O sistema pode identificar solicitações que dão continuidade a uma conversa e bloquear sua execução.
Solicitações à API Responses que não usam nenhum desses mecanismos São monitoradas. Os webhooks configurados podem receber alertas, mas o sistema não interrompe a conversa automaticamente.
Solicitações à API chat completions Esse sistema não monitora essas solicitações. Outras verificações de segurança continuam em vigor.

Para saber como preservar o contexto da conversa, consulte como preservar o raciocínio entre chamadas, modo WebSocket e compactação. Configurar um webhook de alertas não ativa a interrupção automática.

Como tratar uma solicitação interrompida

Quando o monitoramento de desalinhamento bloqueia uma solicitação antes do início do streaming, a API retorna o status HTTP 403, com o tipo de erro invalid_request_error e o código misalignment_policy_violation. Identifique o erro pelo código, e não pelo texto da mensagem. Integrações que usam streaming também precisam tratar erros durante a leitura do fluxo, mesmo depois de já terem recebido parte da saída.

Se o aplicativo receber esse erro:

  1. Pare de enviar novas ações para execução na conversa afetada. Não tente executar novamente o fluxo de trabalho bloqueado de forma automática.
  2. Preserve os IDs das solicitações e respostas relevantes, as chamadas de ferramentas e os registros do aplicativo 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 a essa pessoa que compare as ações do agente com o que deveria ter sido feito e revise as alterações já realizadas.

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

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

Como receber alertas de segurança do projeto

Assine o evento safety.alert.created para encaminhar os alertas de monitoramento de um projeto da API a um sistema operado pela sua equipe. Mesmo que receba alertas, o aplicativo ainda precisa tratar erros nas solicitações à API.

Siga as instruções em Como criar endpoints de webhook para cada projeto do qual você quer receber alertas. No guia de webhooks, consulte as orientações sobre verificação de assinaturas e confirmações de recebimento, novas tentativas e entregas duplicadas.

O webhook contém o ID do alerta, mas não inclui os detalhes:

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

Após verificar o webhook e confirmar o recebimento, consulte o alerta em segundo plano. Substitua o valor de exemplo alert_0123456789abcdef0123456789abcdef pelo valor de data.id do webhook. O campo id do evento identifica o evento do webhook, e não o alerta. Use uma chave de API autorizada para o mesmo projeto e que tenha a permissão api.safety.alerts.read:

curl "https://api.openai.com/v1/safety/alerts/alert_0123456789abcdef0123456789abcdef" \
  -H "Authorization: Bearer ${OPENAI_API_KEY}"
Consultar 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("alert_0123456789abcdef0123456789abcdef")
print(alert.error_type, alert.reason)

Use os valores de request_id e response_id retornados para localizar a atividade afetada nos registros do aplicativo. A categoria do alerta indica um possível problema a investigar. Quando request_paused é true, o sistema conseguiu registrar um bloqueio de segurança. Isso não confirma que a execução foi interrompida nem que ações anteriores foram desfeitas. Verifique o estado da tarefa e os registros das ferramentas no aplicativo.

O campo reason do alerta pode ter o valor null, inclusive em solicitações com zero retenção de dados (ZDR). Quando tem um valor diferente de nulo, reason descreve a categoria do alerta, sem fornecer uma transcrição ou um relatório completo da 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 consulta retornar 404 com o código safety_alert_not_found, verifique o ID do alerta e as credenciais do projeto. Esse erro pode ocorrer quando os registros estão ausentes, inacessíveis ou incompletos. A entrega e a consulta de alertas não fornecem um histórico completo de auditoria.