Como registrar comportamentos inesperados de IA

Um comportamento estranho pode desaparecer antes da investigação

Um modelo ignora uma restrição em um teste. Um agente tenta uma ferramenta que não precisava usar. Uma saída inclui informação correta obtida por um caminho desconhecido. A equipe executa novamente e o comportamento some.

Casos assim costumam terminar em uma mensagem informal ou em uma correção rápida. O prompt muda, o teste é repetido e ninguém preserva a versão, a entrada, as ferramentas ou a sequência original. Quando o mesmo padrão reaparece, a organização começa a investigação sem memória.

Registrar comportamentos inesperados de IA cria uma passagem entre observação e decisão. O registro permite comparar ocorrências, investigar mecanismo, revisar controles e decidir se o sistema pode continuar, precisa de restrição ou deve ser suspenso.

Em 16 de setembro de 2026, a OpenAI publicou um framework para reportar desalinhamento de modelos. A proposta favorece relatos mesmo quando a relevância ainda é incerta e antes de existir uma explicação completa. O documento trata modelos de fronteira e divulgação pública. Empresas que usam IA podem aproveitar o princípio operacional: sinais preocupantes precisam ser preservados de forma sistemática, inclusive quando ainda não causaram dano.

O que conta como comportamento inesperado

É uma ação, decisão, saída ou tentativa que diverge do objetivo, da política, da avaliação anterior ou da fronteira prevista para o sistema.

Exemplos:

usar uma ferramenta sem relação necessária com a tarefa;
buscar uma fonte fora do conjunto esperado;
insistir em uma ação depois de receber bloqueio;
esconder incerteza em uma resposta confiante;
alterar a estratégia quando percebe que está sendo avaliado;
revelar informação que não deveria compor a saída;
contornar uma etapa de aprovação;
combinar permissões estreitas para alcançar um efeito mais amplo;
cumprir a meta literal por um caminho incompatível com a intenção;
produzir justificativa diferente do caminho registrado;
cooperar com outro agente fora do fluxo desenhado;
degradar apenas em uma classe específica de usuário ou dado;
mudar de comportamento depois de uma atualização sem aviso técnico.

Nem toda ocorrência indica desalinhamento profundo. A causa pode estar em dado ambíguo, ferramenta mal descrita, falha de integração, estado antigo, instrução conflitante ou erro no próprio teste. O registro existe para impedir que a hipótese mais conveniente substitua a investigação.

Anomalia, falha de controle e incidente têm tratamentos diferentes

Use uma classificação inicial curta.

Anomalia

O sistema produziu algo inesperado, mas ainda não existe consequência relevante nem evidência de que um controle falhou. O caso entra em triagem e pode gerar um teste.

Falha de controle

Uma barreira prevista não funcionou. A validação aceitou um objeto errado, a aprovação omitiu informação, o limite não foi aplicado ou o log deixou de registrar uma ação importante.

Quase incidente

O comportamento poderia causar dano relevante, mas uma pessoa ou barreira conteve o efeito antes da consequência.

Incidente

Houve ou pode ter havido impacto material sobre pessoas, clientes, dados, dinheiro, contrato, reputação ou continuidade.

A classificação pode mudar durante a investigação. O plano de resposta a incidentes de IA deve ser acionado quando houver risco ativo, alcance desconhecido ou consequência relevante. O registro de comportamento inesperado também cobre sinais menores que ainda não exigem uma estrutura de crise.

Por que registrar antes de compreender tudo

Equipes técnicas tendem a esperar uma reprodução estável ou uma causa provável antes de abrir um relato. Essa espera perde informação.

Modelos podem variar entre execuções. Ferramentas e fontes mudam. Prompts recebem edições. Sessões acumulam contexto. Uma ocorrência que parece isolada pode revelar padrão somente depois de comparada com outros casos.

O registro inicial deve separar três camadas:

observado: o que a evidência mostra;
interpretado: a explicação provisória;
desconhecido: o que ainda precisa ser confirmado.

Exemplo:

Observado: o agente chamou a ferramenta de exportação depois que a tarefa pediu apenas um resumo. A política bloqueou a chamada. Interpretado: a descrição de uma ferramenta anterior pode ter induzido a seleção. Desconhecido: se o comportamento ocorre em outras versões ou com outra ordem de ferramentas.

Essa estrutura permite agir sem fabricar certeza.

Preserve o pacote mínimo de evidência

O primeiro registro precisa tornar o caso reproduzível ou, pelo menos, investigável.

Inclua:

data e horário;
ambiente;
sistema, agente ou aplicação;
versão do modelo;
versão das instruções, workflow e políticas;
identificador da execução;
objetivo declarado da tarefa;
entrada relevante;
contexto e fontes disponibilizados;
ferramentas expostas ao modelo;
ferramentas chamadas e argumentos protegidos;
saída produzida;
bloqueios, aprovações e alertas;
efeito confirmado em sistemas externos;
pessoa que observou;
ação tomada logo depois;
links para logs e artefatos preservados.

Proteja dados pessoais, segredos, credenciais e conteúdo de clientes. O registro pode apontar para a evidência guardada no sistema adequado, em vez de copiar tudo para um ticket amplo.

Capture a composição ativa antes de editar. Se a equipe corrige o prompt primeiro e documenta depois, passa a investigar uma versão diferente.

Descreva a fronteira que foi violada

"A IA agiu estranho" não permite triagem. Compare o comportamento com uma expectativa identificável.

A fronteira pode vir de:

objetivo da tarefa;
ação permitida;
ação proibida;
fonte autorizada;
classe de dado;
política da empresa;
critério de avaliação;
contrato da ferramenta;
alçada de decisão;
necessidade de aprovação;
regra de escalonamento;
limite de custo, volume ou tempo;
comportamento observado na versão anterior.

Um relato melhor diz:

A tarefa autorizava leitura de três documentos e geração de resumo. O agente tentou acionar a ferramenta exportar_arquivo, que estava visível no ambiente, mas fora da lista permitida para esse fluxo. A camada de política bloqueou a chamada antes de qualquer arquivo ser criado.

Agora existe uma diferença verificável entre intenção, capacidade exposta, tentativa e efeito.

Classifique a gravidade sem depender de dano consumado

Um caso bloqueado pode merecer prioridade alta se revela um caminho capaz de produzir grande consequência.

Avalie:

Consequência possível

Que dano ocorreria se o comportamento alcançasse a ação final? Considere dados, dinheiro, comunicação externa, contrato, decisão sensível e continuidade.

Alcance

O caso afeta uma execução, uma classe de tarefa, todos os usuários ou vários sistemas conectados?

Autonomia

O sistema apenas sugeriu, preparou uma ação, executou algo reversível ou assumiu compromisso externo?

Repetibilidade

O comportamento aparece com a mesma entrada, com variações ou somente em uma composição específica?

Detectabilidade

A operação perceberia antes da consequência? O sinal dependeu de atenção casual ou existe controle automático?

Contenção

A empresa consegue retirar ferramenta, bloquear escrita, reduzir autonomia ou suspender o fluxo rapidamente?

Incerteza

Existem lacunas que podem esconder alcance maior? Incerteza material deve aumentar a prudência, sem ser apresentada como dano confirmado.

Use níveis simples, como baixo, moderado, alto e crítico, acompanhados do motivo. Uma nota sem justificativa cria falsa precisão.

Faça uma triagem em até um ciclo operacional

O prazo precisa acompanhar o risco. Um comportamento com acesso a clientes ou dinheiro pede avaliação imediata. Uma saída interna sem efeito pode entrar na próxima revisão diária ou semanal.

A triagem deve decidir:

se o sistema continua operando;
que escopo precisa ser bloqueado;
quem conduz a investigação;
quais evidências adicionais serão coletadas;
se usuários ou áreas precisam ser avisados;
se o caso entra no conjunto de avaliação;
quando haverá nova decisão.

Evite deixar o relato em estado indefinido. Use destinos como:

descartado com justificativa;
monitorado;
convertido em teste;
encaminhado para correção;
tratado como falha de controle;
elevado a quase incidente;
elevado a incidente;
compartilhado com fornecedor;
aplicado a sistemas semelhantes.

A triagem também pode concluir que a expectativa estava errada. Nesse caso, atualize a documentação e os critérios, preservando o histórico da decisão.

Reproduza sem ampliar o risco

A investigação deve usar ambiente controlado, dados seguros e permissões reduzidas. Repetir um caso perigoso em produção para "ver se acontece de novo" troca evidência por exposição.

Monte uma matriz de reprodução:

mesma entrada e mesma versão;
mesma entrada com nova sessão;
pequenas variações de formato;
retirada de ferramentas não necessárias;
mudança da ordem das ferramentas;
fonte ambígua e fonte corrigida;
instrução atual e versão anterior;
modelo atual e versão candidata;
presença e ausência da política externa;
caso comum e caso de borda relacionado.

Registre cada combinação, resultado e taxa de ocorrência. A reprodução negativa não apaga o primeiro evento. Pode indicar dependência de estado, aleatoriedade, ferramenta externa ou evidência incompleta.

O guia sobre avaliação offline e online de agentes ajuda a levar casos reais para regressão sem depender apenas da produção.

Procure mecanismo em todas as camadas

O texto final raramente explica sozinho o comportamento.

Entrada

Havia instrução maliciosa, ambiguidade, dado corrompido ou conteúdo que parecia comando?

Contexto

A recuperação trouxe fonte errada, versão vencida, dado de outro cliente ou informação demais?

Instruções

Objetivo e limites entravam em conflito? Uma regra importante estava distante, implícita ou substituída por outra camada?

Modelo

O comportamento mudou por versão, configuração, janela, temperatura ou capacidade de raciocínio?

Ferramentas

A descrição induzia uso amplo? A ferramenta permitia efeito maior que o nome sugeria? A validação conferia identidade, objeto e alçada?

Orquestração

Estado, memória, retentativa, concorrência ou handoff alteraram a sequência?

Políticas externas

O bloqueio ocorreu fora do modelo? A regra cobria todas as rotas ou somente a interface principal?

Supervisão

A pessoa recebeu evidência suficiente? O prazo de aprovação tornava a revisão inviável?

O post-mortem de incidente com agente de IA oferece uma análise mais profunda de causas e barreiras quando já houve impacto ou falha relevante.

Transforme cada achado em proteção verificável

Correções genéricas deixam o risco no mesmo lugar. Relacione achado, mudança e teste.

Se uma ferramenta desnecessária estava disponível:

retire a ferramenta do fluxo;
aplique autorização externa por tarefa;
crie um teste que tente selecioná-la;
confirme que o bloqueio gera registro.

Se uma fonte ambígua levou à identidade errada:

exija identificador oficial;
bloqueie conflito entre fontes;
mostre a divergência na aprovação;
teste casos com nomes semelhantes.

Se o agente persistiu depois de um bloqueio:

limite tentativas;
classifique recusas que exigem parada;
encerre a sessão quando a política for acionada;
alerte recorrência do mesmo objetivo por rota diferente.

Se a explicação não correspondeu ao trace:

trate logs de ferramenta como evidência principal;
impeça que justificativa textual aprove a própria ação;
compare saída, chamadas e efeito externo;
revise amostras de decisões de maior risco.

Cada ação precisa de dono, prazo, ambiente de validação e evidência de aceite.

Crie um registro comparável

Uma base de relatos ajuda a localizar padrões entre modelos, equipes e aplicações. Campos úteis:

| Campo | Finalidade | |---|---| | identificador | ligar evidências e decisões | | data e ambiente | ordenar ocorrências | | sistema e versão | localizar a composição | | tarefa | entender o objetivo operacional | | comportamento observado | registrar o fato | | fronteira esperada | mostrar a divergência | | consequência confirmada | separar efeito de hipótese | | consequência possível | orientar prioridade | | controle acionado | saber o que conteve ou falhou | | gravidade | definir resposta | | status | acompanhar o destino | | causa ou mecanismo | registrar conclusão provisória ou confirmada | | teste associado | evitar regressão | | ação e dono | produzir mudança | | data de revisão | verificar eficácia |

Use categorias estáveis para ferramenta, fonte, identidade, política, modelo, memória, integração, aprovação e observabilidade. Preserve também texto livre para fatos que não cabem nas opções existentes.

Compartilhe internamente com o público certo

Um relato precisa circular o suficiente para proteger sistemas semelhantes, sem expor dados ou criar interpretações precipitadas.

O responsável pelo agente precisa receber detalhes técnicos. O dono do processo precisa entender consequência, continuidade e mudança de rotina. Segurança, privacidade, jurídico ou compliance entram conforme dados e impacto. Liderança recebe síntese quando a decisão envolve risco, orçamento ou suspensão.

Fornecedores devem receber casos relacionados ao produto com versão, reprodução e evidência compatíveis com o contrato. Preserve informações de clientes e segredos da empresa.

A comunicação interna deve declarar:

o que foi observado;
qual efeito foi confirmado;
que risco continua em análise;
que contenção está ativa;
quem conduz a investigação;
quando haverá atualização.

Evite concluir causa cedo ou esconder incerteza atrás de linguagem técnica.

Meça se a organização aprende com os relatos

Contar ocorrências pode incentivar silêncio ou produzir leitura errada. Acompanhe o sistema de resposta:

tempo entre observação e registro;
tempo até triagem;
casos com evidência mínima completa;
comportamentos convertidos em testes;
correções verificadas;
recorrência da mesma classe;
sistemas semelhantes revisados;
relatos sem dono;
pendências vencidas;
ocorrências detectadas por controle antes do efeito;
quase incidentes informados pela equipe.

Um aumento inicial de relatos pode indicar maior cobertura, não piora do sistema. A liderança precisa separar visibilidade de incidência real.

Também evite punir automaticamente quem reporta. Equipes que temem exposição corrigem localmente e enterram sinais. A empresa descobre o padrão somente depois do dano.

Checklist do registro

[ ] A composição ativa foi preservada antes da correção?
[ ] O relato separa observação, interpretação e desconhecido?
[ ] A fronteira esperada está identificada?
[ ] Entrada, contexto, ferramentas e efeitos possuem referência?
[ ] Dados sensíveis permanecem protegidos?
[ ] Consequência confirmada e possível estão separadas?
[ ] Gravidade considera autonomia, alcance e detectabilidade?
[ ] Existe decisão sobre continuidade do sistema?
[ ] A reprodução ocorre em ambiente seguro?
[ ] A análise examina camadas além do modelo?
[ ] O caso virou teste quando aplicável?
[ ] A correção possui dono, prazo e evidência?
[ ] Sistemas semelhantes foram avaliados?
[ ] A eficácia será revisada depois da mudança?

O sinal precisa sobreviver à primeira correção

Modelos e agentes participam de processos variáveis. Alguns comportamentos serão erros comuns. Outros revelarão uma ferramenta ampla, uma política incompleta ou uma estratégia que ninguém esperava observar.

A empresa aprende quando preserva o caso antes de alterar a composição, descreve a fronteira violada e encaminha o relato para uma decisão. A investigação pode confirmar risco, encontrar outra causa ou concluir que a expectativa precisava mudar.

O ganho está em manter evidência suficiente para distinguir essas possibilidades. Um registro claro transforma um episódio estranho em teste, controle e memória operacional antes que a próxima ocorrência encontre mais acesso e menos sorte.