Registro de decisões para agentes de IA: como criar

A configuração mostra o que mudou, mas não explica a decisão

Uma equipe reduz a revisão humana de cem para vinte por cento dos casos. Meses depois, ninguém lembra qual evidência sustentou a mudança. O painel atual parece estável, mas a composição já trocou de modelo, base de conhecimento e integração. Quando surge uma falha, a empresa encontra commits, tickets e mensagens. Falta a razão que conectou esses registros à autorização de ampliar autonomia.

O registro de decisões para agentes de IA documenta escolhas que alteram capacidade, risco, custo ou responsabilidade. Ele preserva contexto, alternativas, evidências, aprovadores, condições de validade e critérios de revisão.

Esse registro é diferente do log de execução. O log mostra o que o sistema fez em um caso. O registro de decisão explica por que a organização permitiu que aquela versão, fonte, ferramenta ou política operasse daquela forma.

Quais decisões merecem registro

Nem toda alteração precisa de um documento. Registre decisões que mudam pelo menos uma destas fronteiras:

finalidade do agente;
processo ou população atendida;
fonte oficial ou hierarquia entre fontes;
modelo, provedor ou perfil de configuração;
ferramenta disponível;
permissão de leitura ou escrita;
nível de autonomia;
exigência de aprovação humana;
limite de valor, volume ou horário;
política de retenção e uso de dados;
critério de qualidade;
tratamento de exceções;
contingência;
responsabilidade interna ou contratada;
regra para ampliar, restringir ou desligar.

Uma correção visual na interface pode seguir o fluxo comum de produto. Liberar envio automático para clientes precisa deixar uma decisão recuperável.

O teste prático é simples: se uma falha futura levar a empresa a perguntar "quem autorizou isso e com base em quê?", o registro deveria existir.

Registro de decisão, log de auditoria e controle de mudanças

Esses artefatos se conectam, mas resolvem perguntas diferentes.

Log de auditoria

Registra eventos de uma execução: identidade, horário, versão, fontes, ferramenta, objeto afetado, aprovação e resultado. Ele ajuda a reconstruir um caso específico.

O guia sobre log de auditoria para agentes de IA detalha essa trilha.

Controle de mudanças

Governa a promoção de uma composição para produção. Inclui teste, aprovação, implantação gradual, observação e rollback.

O controle de mudanças em agentes de IA responde se uma versão candidata pode entrar e como será publicada.

Registro de decisão

Preserva a escolha que orientou a mudança. Explica o problema, as alternativas consideradas, a evidência disponível, os riscos aceitos, quem decidiu e em que condições a decisão continua válida.

Um único registro de decisão pode gerar várias mudanças técnicas. Uma mudança também pode implementar partes de decisões diferentes. Os identificadores devem criar a ligação entre os artefatos sem copiar tudo em todos os lugares.

O registro precisa ser curto e verificável

Um bom registro não é uma ata extensa. Ele deve permitir que outra pessoa reconstrua a escolha sem conversar com quem participou da reunião.

Use uma ficha com estes campos:

| Campo | Conteúdo esperado | |---|---| | identificador | código único e pesquisável | | título | decisão expressa como ação | | estado | proposta, aprovada, substituída, revogada ou expirada | | data | momento da decisão | | dono | responsável por manter a decisão | | autoridade | pessoa ou fórum que aprovou | | contexto | problema operacional e restrição vigente | | decisão | escolha realizada e alcance | | alternativas | opções consideradas | | evidências | dados, testes, incidentes e documentos usados | | riscos aceitos | exposição que permanece depois dos controles | | controles | barreiras exigidas para a decisão valer | | validade | evento ou prazo que exige revisão | | métricas | sinais acompanhados depois da implantação | | links | tickets, testes, versões, políticas e painéis relacionados |

A ficha pode viver em repositório, sistema de gestão, wiki ou portal. O local importa menos que quatro propriedades: identificador estável, histórico de alteração, acesso adequado e ligação com a operação.

Escreva o título como uma escolha

Títulos vagos dificultam busca. "Autonomia do agente comercial" nomeia um tema. "Liberar criação automática de tarefas comerciais para oportunidades ativas" registra uma decisão.

Prefira verbo, objeto e limite:

adotar o CRM como fonte oficial do estágio comercial;
manter aprovação humana para descontos acima da alçada;
usar modelo econômico apenas na classificação inicial;
suspender envio automático fora do horário comercial;
retirar acesso direto ao banco de produção;
ampliar modo autônomo para documentos de baixo risco;
encerrar o conector sem manutenção ativa.

O título deve permitir que uma pessoa encontre o registro quando procura pela capacidade afetada.

Descreva o contexto sem reconstruir toda a história

O contexto explica por que a decisão apareceu naquele momento. Inclua:

processo afetado;
perda, risco ou restrição observada;
versão ou estado atual;
evento que abriu a decisão;
partes envolvidas;
prazo relevante;
limitações conhecidas da evidência.

Exemplo:

O agente prepara próximas ações para oportunidades ativas. Durante o piloto, vendedores aprovaram a maior parte das tarefas sem edição, mas foram encontrados casos de oportunidades encerradas entre a leitura e o registro. A decisão trata somente a criação de tarefas internas. Envio de mensagens e alteração de estágio permanecem fora do escopo.

Esse texto delimita o problema. Evita transformar um bom resultado em uma autorização genérica para outras ações.

Separe fato, interpretação e hipótese

Decisões ficam frágeis quando esses três níveis aparecem misturados.

Fato

Algo observado e ligado a uma fonte:

taxa de saídas válidas na amostra;
incidentes registrados;
tempo de ciclo medido;
volume processado;
resultado de teste;
permissão presente no sistema;
cláusula contratual vigente.

Interpretação

Leitura da equipe sobre os fatos:

a revisão atual consome parte pequena do ganho;
uma classe de erro está ligada à fonte desatualizada;
o risco pode ser limitado com revalidação no momento da escrita.

Hipótese

Condição ainda não comprovada:

a qualidade permanecerá em volume maior;
o novo modelo reduzirá custo sem perder cobertura;
a equipe incorporará a rotina depois do treinamento.

A decisão pode usar hipóteses, desde que as identifique e defina como serão testadas. Escrever hipótese como fato facilita expansão sem evidência.

Registre alternativas reais

Uma escolha perde valor documental quando só registra a opção aprovada. Liste caminhos plausíveis e o motivo da rejeição ou adiamento.

Para ampliar autonomia de um agente, as alternativas podem ser:

manter revisão de todos os casos;
automatizar somente classes de baixo risco;
revisar uma amostra aleatória;
usar aprovação por valor ou cliente;
corrigir a fonte antes de alterar autonomia;
encerrar a capacidade.

A comparação deve considerar resultado, custo, risco, prazo, reversibilidade e manutenção. "Não fazer nada" pode ser uma alternativa legítima quando o ganho esperado é pequeno ou a evidência ainda é fraca.

O artigo sobre matriz de autonomia para agentes de IA ajuda a separar observação, sugestão, aprovação e execução por classe de ação.

Vincule cada decisão às evidências

Evite anexar uma pasta genérica. Aponte para itens identificáveis:

versão do dataset de avaliação;
relatório de modo sombra;
período da linha de base;
resultados por classe de caso;
incidentes e quase incidentes;
teste de segurança;
parecer do dono da fonte;
custo por unidade válida;
contrato ou política aplicável;
versão da arquitetura proposta.

Registre também o que não foi medido. Uma decisão pode ser válida para um piloto limitado e insuficiente para escala. A ausência precisa acompanhar o alcance.

A linha de base para projeto de IA organiza volume, esforço, qualidade, custo e resultado antes da comparação.

Declare o risco residual

Controles reduzem risco. Raramente eliminam toda possibilidade de falha.

Para cada decisão relevante, registre:

erro que ainda pode ocorrer;
classe de caso exposta;
impacto máximo considerado;
probabilidade ou frequência quando houver base;
capacidade de detecção;
tempo para contenção;
reversibilidade;
autoridade que aceitou o risco.

Evite frases como "risco mitigado" sem dizer qual barreira existe. Um controle observável pode ser:

a ferramenta revalida o estado antes da escrita;
valores acima da alçada são bloqueados por regra;
a identidade não possui permissão de exclusão;
mensagens externas exigem aprovação;
uma amostra semanal passa por revisão independente;
o kill switch interrompe gatilhos e ferramentas.

O risco residual determina a validade da decisão. Se a barreira for removida, falhar ou mudar de versão, a autorização pode deixar de valer.

Defina condições de validade

Uma decisão permanente sobre um sistema variável é uma contradição operacional. Estabeleça eventos de revisão.

Exemplos:

troca do modelo principal;
alteração da fonte oficial;
nova categoria de cliente;
aumento relevante de volume;
mudança de permissão;
incidente crítico;
queda da qualidade abaixo do limite;
custo por unidade acima da faixa;
alteração contratual;
vencimento de política;
entrada de uma nova ferramenta;
data de revisão periódica.

A condição precisa produzir uma ação: revisar, suspender, reduzir alcance ou iniciar nova avaliação. Um lembrete sem dono costuma vencer em silêncio.

Dê um dono para manter a decisão viva

O aprovador autoriza. O dono mantém.

O dono do registro deve:

acompanhar eventos de revisão;
confirmar se métricas continuam disponíveis;
atualizar links para evidências;
abrir nova decisão quando o contexto muda;
marcar substituição ou revogação;
evitar que registros incompatíveis permaneçam ativos;
garantir que a mudança correspondente seja implementada.

Em decisões técnicas com consequência de negócio, use dois responsáveis: dono operacional e responsável técnico. O primeiro responde pelo resultado e pelas exceções. O segundo responde pela composição, pelos controles e pela capacidade de aplicar ou reverter a mudança.

Uma pessoa pode exercer os dois papéis em empresas menores. A ficha ainda deve separar as responsabilidades.

Use estados claros

Evite editar silenciosamente a decisão antiga até ela parecer atual. Preserve os estados:

Proposta

A escolha está em análise e não autoriza mudança em produção.

Aprovada

A decisão possui autoridade, alcance, controles e validade definidos. Sua implementação ainda pode depender do fluxo de mudança.

Substituída

Uma decisão posterior ocupa o mesmo objeto e informa o identificador anterior.

Revogada

A autorização foi retirada antes de uma substituição. Registre motivo, alcance e ação de contenção.

Expirada

A condição de validade venceu sem nova aprovação. O sistema deve seguir a política prevista, como voltar ao modo restrito ou bloquear ampliação.

Histórico ajuda a explicar a arquitetura atual. Ele também mostra quando uma permissão permaneceu ativa depois que a decisão perdeu validade.

Ligue o registro à versão executada

O registro precisa chegar à operação. Inclua seu identificador em:

ticket de mudança;
pull request ou commit quando aplicável;
configuração publicada;
versão da política;
catálogo de ferramentas;
inventário do agente;
conjunto de testes;
painel de acompanhamento;
procedimento de suporte;
comunicação aos usuários.

O log de execução não precisa copiar a decisão inteira. Ele pode registrar a versão da política e o identificador que autorizou aquela capacidade. Durante uma auditoria ou incidente, a equipe percorre a cadeia: execução, composição, mudança e decisão.

A configuração como código para agentes de IA ajuda a manter modelos, ferramentas, limites e políticas sob versão. O registro acrescenta a justificativa organizacional.

Exemplo de registro

Identificação

ID: ADR-IA-027
Título: liberar criação automática de tarefas para oportunidades ativas
Estado: aprovada
Dono operacional: gestão comercial
Responsável técnico: plataforma de automação
Autoridade: diretor comercial e responsável por segurança

Contexto

O agente recupera compromissos de reuniões e prepara a próxima ação no CRM. O piloto mostrou boa qualidade para oportunidades ativas com responsável definido. Foram observadas divergências quando o estágio mudou entre a leitura e a escrita.

Decisão

Permitir criação automática de tarefa interna somente quando a oportunidade permanece ativa, o responsável atual está confirmado e não existe tarefa aberta para o mesmo compromisso. Alteração de estágio, valor, contato e envio externo continuam bloqueados.

Alternativas consideradas

manter aprovação em todos os casos;
liberar todas as atualizações propostas;
criar tarefa somente por integração determinística;
aguardar nova versão do CRM.

A opção escolhida preserva o ganho de continuidade e limita o efeito a um registro reversível.

Evidências

dataset e versão da avaliação;
resultado do piloto por classe;
linha de base do esforço comercial;
testes de concorrência e idempotência;
parecer do dono do processo.

Controles

revalidação do estado antes da escrita;
chave idempotente por oportunidade e compromisso;
conta de serviço sem permissão para alterar estágio;
log com estado anterior, tarefa criada e confirmação do CRM;
revisão semanal por amostragem;
feature flag por equipe.

Validade

Revisar em noventa dias, em troca de modelo, mudança do schema do CRM, incidente de duplicidade ou expansão para contas estratégicas.

Métricas

tarefas válidas sem correção;
duplicidades bloqueadas;
tarefas removidas por erro;
oportunidades elegíveis cobertas;
esforço humano por próxima ação;
incidentes por versão.

O exemplo é delimitado. Ele não transforma uma autorização para criar tarefas em permissão genérica para operar o CRM.

Organize decisões por objeto

Um repositório cresce rápido. Use metadados simples:

agente ou função;
processo;
tipo de decisão;
sistema afetado;
risco;
estado;
dono;
data de revisão.

Tipos úteis:

arquitetura;
dados e fontes;
modelo e configuração;
ferramentas;
identidade e permissão;
autonomia;
qualidade;
custo;
fornecedor;
operação e suporte;
contingência e encerramento.

Uma busca por agente deve mostrar todas as decisões vigentes. Uma busca por sistema deve revelar quais agentes dependem daquela fonte ou ferramenta.

Crie uma rotina de revisão

A revisão não precisa virar uma reunião permanente para cada registro. Use três gatilhos.

Evento

Mudança, incidente, novo risco ou alteração contratual abre revisão imediata.

Métrica

Qualidade, custo, volume, adoção ou falha atravessa uma faixa definida.

Calendário

Decisões relevantes recebem revisão periódica mesmo sem alerta. Isso captura dependências que mudaram devagar e critérios que perderam sentido.

A rotina deve terminar em uma destas saídas:

manter sem alteração;
corrigir controles;
reduzir alcance;
ampliar com nova evidência;
substituir a decisão;
revogar;
encerrar o agente.

Registre a saída e a próxima data. Revisão que termina em "acompanhar" sem responsável e condição apenas adia a escolha.

Erros comuns

Registrar apenas a decisão final

Sem contexto, alternativas e evidência, a ficha vira uma ordem sem memória.

Copiar a ata da reunião

A conversa contém opiniões, digressões e tarefas. O registro deve consolidar a escolha, seus limites e sua base.

Usar o ticket como justificativa

Tickets organizam execução. Eles raramente explicam risco aceito, alternativa rejeitada e validade.

Tratar aprovação como eterna

Modelos, fontes, equipes e processos mudam. Toda decisão relevante precisa de evento ou prazo de revisão.

Esconder hipótese dentro de linguagem segura

"A solução manterá qualidade em escala" é hipótese até haver evidência. Registre como condição a testar.

Deixar registros incompatíveis ativos

Uma decisão libera uma ferramenta e outra posterior revoga a permissão. Marque substituição, aplique a mudança e verifique o estado real.

Documentar sem ligar à configuração

A política diz uma coisa e a credencial permite outra. Verifique a implementação antes de encerrar o item.

Exigir documento para qualquer ajuste

Burocracia excessiva empurra decisões para canais informais. Defina um limiar baseado em capacidade, risco, custo e responsabilidade.

Checklist do registro de decisões

[ ] O título expressa ação, objeto e limite?
[ ] O contexto descreve o problema operacional?
[ ] Fatos, interpretações e hipóteses estão separados?
[ ] Alternativas reais foram consideradas?
[ ] Evidências possuem versão, período ou identificador?
[ ] O alcance da decisão está explícito?
[ ] Riscos residuais e controles foram registrados?
[ ] Existe autoridade de aprovação adequada?
[ ] Um dono mantém a decisão depois da reunião?
[ ] Eventos e prazo de revisão estão definidos?
[ ] Métricas podem invalidar ou ampliar a escolha?
[ ] O identificador aparece na mudança e na configuração?
[ ] Decisões substituídas ou revogadas mantêm histórico?
[ ] O estado real foi verificado depois da implementação?

Decisões recuperáveis reduzem risco e retrabalho

Agentes acumulam escolhas sobre dados, modelos, permissões, ferramentas e autonomia. Quando essas escolhas vivem apenas em mensagens e na memória de quem participou, a arquitetura perde explicação antes de perder funcionamento.

O registro preserva a ligação entre evidência e autoridade. Ele mostra qual problema foi tratado, o que ficou fora do escopo, quais controles sustentam a autorização e quando a escolha precisa voltar à mesa. Isso acelera incidentes, mudanças, auditorias e substituição de responsáveis sem transformar cada revisão em investigação histórica.