Critérios de aceite para agente de IA: como definir

Aceitar uma demonstração é diferente de aceitar uma operação

O fornecedor apresenta o agente, executa alguns casos escolhidos e mostra a integração funcionando. A equipe aprova a reunião. Semanas depois, aparecem divergências sobre o que foi entregue, quais erros estavam dentro da tolerância e quem deveria tratar as falhas.

Esse problema começa antes da homologação. O contrato descreve funcionalidades, o cronograma lista etapas e os testes verificam exemplos. Falta uma regra comum para decidir se a solução pode assumir trabalho real.

Critérios de aceite definem as condições que uma entrega precisa cumprir para ser considerada apta a um escopo operacional específico. Eles ligam requisito, caso de teste, evidência, limite de erro, responsabilidade e decisão.

A avaliação de agentes de IA mede comportamento e resultado. O aceite usa essa evidência para autorizar uma transição: seguir para piloto, entrar em produção limitada, ampliar autonomia, exigir correção ou recusar a entrega.

O aceite precisa nomear a capacidade entregue

"Agente comercial implantado" permite interpretações incompatíveis. Uma parte pode entender que o sistema lê o CRM e sugere a próxima ação. Outra pode esperar que ele envie mensagens, altere estágio e acompanhe respostas.

Comece pela unidade de trabalho e pelo desfecho válido.

Exemplo:

Para oportunidades ativas com reunião futura, o agente reúne histórico autorizado, identifica compromissos, aponta lacunas e gera um briefing vinculado às fontes. O vendedor recebe o material até duas horas antes da reunião.

Essa definição informa:

qual evento inicia o trabalho;
quais registros entram no escopo;
que resultado conta como conclusão;
onde a saída será usada;
qual prazo faz parte da utilidade;
que ações permanecem fora da entrega.

O aceite deve acompanhar essa fronteira. Se o primeiro projeto autoriza somente leitura e preparação, a empresa não deveria avaliar envio autônomo como requisito. Também não deveria aceitar uma atualização no CRM como substituta do briefing prometido.

Requisito, teste e aceite cumprem funções próprias

Esses elementos costumam aparecer misturados em uma planilha.

Requisito

Descreve uma capacidade ou restrição. Exemplo: o agente deve usar somente oportunidades ativas e não pode consultar negócios encerrados.

Caso de teste

Cria uma situação observável para verificar o requisito. Exemplo: uma amostra contém oportunidades ativas, perdidas, ganhas e duplicadas.

Critério de aceite

Define qual resultado autoriza a aprovação. Exemplo: todos os casos encerrados precisam ser bloqueados, e qualquer consulta indevida a esse grupo impede a entrada em produção.

A separação evita frases vagas como "a integração precisa funcionar". O requisito indica a obrigação, o teste produz evidência e o critério determina a decisão.

Organize o aceite por dimensões

Um agente pode responder bem e ainda falhar no processo. Por isso, o aceite precisa cobrir o caminho entre entrada e consequência.

Resultado da tarefa

Verifique se a saída resolve a unidade de trabalho:

campos obrigatórios presentes;
classificação correta por classe de caso;
fontes ligadas às afirmações relevantes;
informação ausente tratada sem invenção;
formato utilizável pelo próximo responsável;
conclusão registrada no destino esperado.

Qualidade textual isolada raramente basta. Um briefing elegante com oportunidade errada continua sendo uma falha.

Execução e integração

Confirme se o agente percorre o processo de forma confiável:

localiza o registro correto;
usa a fonte autorizada;
chama apenas ferramentas previstas;
valida parâmetros antes da ação;
trata timeout e indisponibilidade;
evita duplicidade em novas tentativas;
confirma o efeito no sistema final;
preserva estado quando a execução é interrompida.

A página sobre ambiente de teste para agentes de IA ajuda a separar dados, credenciais e consequências durante a homologação.

Segurança e limites

Liste erros que bloqueiam a aprovação independentemente da média:

acesso a cliente, área ou ambiente fora do escopo;
exposição de dado ou segredo;
ação sem identidade atribuível;
uso de ferramenta proibida;
envio externo sem a aprovação exigida;
alteração financeira ou contratual fora da alçada;
mistura de memória entre clientes;
impossibilidade de interromper a execução.

Uma taxa geral alta não compensa uma falha crítica. Segurança precisa entrar como condição impeditiva, não como nota diluída na pontuação.

Operação e suporte

A solução também precisa sobreviver ao primeiro dia:

dono operacional identificado;
responsável técnico e canal de suporte definidos;
alertas chegam a alguém capaz de agir;
falhas entram em fila com contexto;
procedimento manual ou degradado está documentado;
instruções, modelos e integrações possuem versão;
monitoramento mostra prazo, qualidade, custo e erro;
manutenção e revisão têm cadência.

A entrega pode cumprir requisitos técnicos e continuar inapta se ninguém souber assumir uma exceção na segunda-feira de manhã.

Adoção no trabalho real

Aceite técnico não prova uso. Em piloto, observe se as pessoas recebem a saída no lugar certo, entendem quando confiar, conseguem corrigir e economizam esforço no fluxo completo.

Meça elementos como:

percentual de casos em que a saída foi usada;
tempo de revisão humana;
correções feitas antes da conclusão;
tarefas devolvidas por falta de contexto;
tempo total do processo;
backlog criado pelo novo sistema;
abandono ou uso paralelo fora do fluxo.

A página sobre plano de adoção de IA detalha rotina, dono, treinamento aplicado e expansão baseada em valor percebido.

Defina erros impeditivos antes de executar os testes

Se a equipe classifica a gravidade depois de ver o resultado, o prazo e o entusiasmo começam a negociar o critério.

Crie pelo menos três classes.

Impeditivo

Bloqueia o aceite ou reduz imediatamente o escopo. Inclui violação de acesso, ação irreversível indevida, mistura de cliente, perda de registro, envio proibido e falha em interromper uma capacidade crítica.

A tolerância costuma ser zero no conjunto testado e na janela observada. Isso não prova risco zero futuro. Prova apenas que a empresa recusará publicar uma versão que já demonstrou o erro.

Relevante

Prejudica a tarefa ou exige retrabalho, mas possui contenção e correção possíveis. Exemplos: classificação incorreta de caso comum, fonte incompleta ou escalonamento desnecessário.

Defina limite por classe, não apenas média. Um agente pode acertar muitos casos simples e falhar em todas as exceções comerciais.

Menor

Afeta apresentação sem comprometer decisão, registro ou consequência. Ajustes de redação e ordem visual podem entrar aqui quando não alteram significado.

A classificação deve considerar impacto, alcance, detectabilidade e reversibilidade. Um campo aparentemente pequeno pode ser impeditivo se alimenta faturamento ou obrigação contratual.

Monte uma matriz rastreável

Uma matriz simples impede que requisitos desapareçam entre proposta, desenvolvimento e homologação.

| ID | Unidade ou requisito | Caso de teste | Resultado esperado | Limite | Evidência | Responsável | Decisão | |---|---|---|---|---|---|---|---| | AC-01 | usar apenas oportunidades ativas | registro ativo e encerrado | ativo entra; encerrado é bloqueado | zero consulta indevida | trace e log do CRM | comercial | pendente | | AC-02 | gerar briefing antes da reunião | agenda e histórico completos | briefing disponível no prazo | faixa aprovada | artefato com horário | operação | pendente | | AC-03 | escalar conflito de valor | CRM e proposta divergentes | nenhuma escolha silenciosa | zero decisão automática | pacote de escalonamento | gestor comercial | pendente | | AC-04 | manter continuidade | API do CRM indisponível | tarefa preservada e responsável alertado | prazo definido | fila e alerta | tecnologia | pendente |

Os exemplos mostram a estrutura. Faixas, prazos e volumes devem vir da operação e do risco do projeto.

Cada linha precisa apontar para evidência pesquisável. Captura de tela solta pode comprovar interface, mas raramente mostra versão, entrada, ferramenta, decisão e efeito final.

Escolha uma amostra que represente o processo

Casos selecionados apenas pelo fornecedor tendem a mostrar o caminho feliz. A empresa deve participar da amostra com histórico real anonimizado e exceções conhecidas.

Inclua:

situações comuns em proporção representativa;
entradas incompletas;
registros duplicados;
fontes conflitantes;
valores próximos de alçadas;
restrições de cliente ou consentimento;
falha de ferramenta;
confirmação perdida;
solicitação fora do escopo;
caso que precisa ser interrompido;
tarefa executada mais de uma vez;
mudança de estado durante o processamento.

Casos sintéticos são úteis para riscos raros. Eles complementam o histórico, pois a operação real contém sujeira e dependências difíceis de inventar com fidelidade.

Separe aceite por estágio

Um único aceite final cria uma surpresa grande no fim. Use marcos que reduzem incertezas diferentes.

Aceite de desenho

Confirma processo, unidade, fontes, escopo, exclusões, alçadas, métrica e responsabilidades. Ainda não aprova a tecnologia.

Aceite técnico

Confirma integração, identidade, permissões, ambientes, ferramentas, logs, tratamento de erro e capacidade de interrupção.

Aceite de qualidade

Compara a solução com resultados esperados em casos comuns, difíceis e críticos. Inclui regressão e erros impeditivos.

Aceite de piloto

Observa pessoas, prazo, volume, suporte, correção e impacto no fluxo real com alcance limitado.

Aceite para produção

Autoriza uma versão, uma classe de caso, um volume, um nível de autonomia e uma janela de acompanhamento. Não concede liberdade para qualquer uso futuro.

Mudança de fonte, modelo, permissão ou procedimento pode exigir novo aceite proporcional ao risco. O controle de mudanças em agentes de IA organiza essa passagem entre versões.

Registre pendências sem fingir aprovação completa

Nem toda divergência precisa bloquear o projeto. A decisão pode aceitar parte da capacidade com restrições.

Use estados claros:

aceito para o escopo definido;
aceito com pendências e prazo;
aceito somente em produção assistida;
aceito para classes de baixo risco;
devolvido para correção;
suspenso até nova evidência;
recusado por requisito impeditivo.

Uma pendência deve ter dono, prazo, impacto e condição de fechamento. "Ajustar depois" transfere risco sem governança.

Também registre desvios conhecidos. Se o ERP não possui sandbox equivalente, o aceite pode exigir produção limitada, janela acompanhada e bloqueio de operações críticas. A limitação continua visível em vez de desaparecer na ata.

O termo de aceite precisa preservar responsabilidade

O documento final deve identificar:

capacidade e versão avaliadas;
unidade de trabalho e escopo autorizado;
ambientes, fontes e integrações incluídos;
conjunto de testes e período do piloto;
resultados e erros encontrados;
critérios cumpridos e pendentes;
riscos aceitos e restrições vigentes;
nível de autonomia liberado;
responsáveis pela operação, suporte e decisão;
métricas e janela de acompanhamento;
condições de pausa ou rollback;
ativos entregues para continuidade;
decisão e aprovadores.

O termo não transfere para o cliente toda consequência de uma implementação mal definida. Contrato, responsabilidade técnica, obrigação legal e tratamento de dados continuam valendo. O aceite registra uma decisão operacional sobre evidências conhecidas.

Ativos que devem acompanhar a entrega

A empresa precisa receber o necessário para usar, revisar e encerrar a solução:

mapa do processo;
arquitetura e integrações;
inventário de identidades e permissões;
versões das instruções e configurações;
catálogo de ferramentas autorizadas;
conjunto de testes e resultados;
procedimentos de suporte e contingência;
painel ou consulta de monitoramento;
registro de limitações conhecidas;
plano de manutenção e mudança;
procedimento de interrupção e saída.

A RFP para agente de IA deve pedir esses ativos antes da contratação. Negociar portabilidade somente no encerramento deixa a empresa sem alavanca.

Checklist para aceitar um agente de IA

A capacidade entregue cabe em uma frase operacional?
A unidade de trabalho possui início e conclusão verificáveis?
Requisitos, testes e critérios estão separados?
Casos reais e exceções participam da amostra?
Erros impeditivos foram definidos antes do teste?
A análise separa qualidade média de risco crítico?
Integrações confirmam o efeito no sistema final?
Permissões reais correspondem ao escopo declarado?
Falhas, filas e contingência possuem dono?
Usuários conseguem revisar e corrigir a saída?
A versão aceita pode ser identificada em cada execução?
Pendências possuem responsável, prazo e impacto?
O aceite informa autonomia, volume e classes autorizadas?
Existem condições de pausa e reversão?
A empresa recebeu os ativos para sustentar ou encerrar a solução?

O aceite fecha uma decisão, não a observação

Critérios claros evitam que uma demonstração convincente vire autorização implícita para operar. Eles dão ao cliente e ao fornecedor uma base comum para testar, corrigir e encerrar discussões sobre escopo.

A entrega aceita continua sob monitoramento. Novos dados, volumes, usuários e permissões alteram o risco. O valor do aceite está em autorizar uma capacidade delimitada com evidência, responsáveis e condições de revisão. É assim que um projeto deixa a fase de apresentação e entra na empresa sem carregar ambiguidade junto com a tecnologia.