Cenário ilustrativo. O fornecedor mostra o agente de apoio ao cliente: responde bem a seis perguntas e a sala aplaude. O marco é faturado. Três semanas depois, a responsável pelo atendimento diz que «não está concluído» porque se perde nas encomendas devolvidas; o fornecedor responde que isso nunca esteve no âmbito. Nenhum dos dois mente. Ninguém escreveu o que queria dizer «concluído».
A tese numa linha: um agente de IA não se entrega quando funciona na demo, mas quando cumpre critérios de aceitação escritos antes de começar e assinados por alguém do negócio. Sem esse papel, o projeto nunca acaba ou acaba por cansaço.
O que são os critérios de aceitação de um agente de IA e porque não basta a demo?
Os critérios de aceitação de um agente de IA são as condições mensuráveis que o agente tem de cumprir, sobre casos reais e durante um período acordado, para o cliente o dar por entregue. Num formulário web, «funciona» é binário: guarda o dado ou não guarda. Um agente responde de forma diferente de cada vez e acerta numa certa proporção dos casos, pelo que «funciona» é sempre uma pergunta incompleta: com que frequência, em que casos e a que custo quando falha?
A demo não responde a nenhuma das três, porque é escolhida por quem vende: os melhores casos no melhor dia (explicamos isto em a demo usava os teus melhores casos). E o problema de fundo não é técnico. A análise da RAND sobre porque falham os projetos de IA, baseada em entrevistas com engenheiros e cientistas de dados, aponta entre as causas mais comuns que o problema a resolver foi mal compreendido ou mal comunicado (RAND, 2024). Os critérios de aceitação são essa conversa posta por escrito, com data e com nomes.
O que deve incluir o documento de aceitação de um agente?
Seis coisas, e as seis cabem numa página. Se alguma não couber, ainda não sabem o que estão a comprar.
- Casos de teste que vêm da tua operação, não da do fornecedor. Um conjunto fechado de casos reais, com os difíceis e as exceções lá dentro, congelado antes de começar. Se o conjunto mudar a meio do projeto, os resultados deixam de ser comparáveis. Como avaliar: avaliar a qualidade dos agentes de IA e evals: sem medir não sabes se funciona.
- O erro tolerado, por tipo de erro. Não um «95 % de acerto» global: enganar-se no tom não custa o mesmo que prometer um reembolso que a política não permite. Porque a média engana: 95 % de acerto não chega em produção.
- O que faz quando não sabe. Critérios de escalamento: em que situações passa a uma pessoa, com que contexto e em quanto tempo. O desenho está em o que faz um agente quando não sabe.
- O que pode tocar e até onde. Que sistemas lê, em quais escreve e que ações exigem aprovação humana, segundo os níveis de autonomia de um agente.
- Como se mede e durante quanto tempo. Um período de teste supervisionado em produção real, com a métrica definida à partida. O que medir sem se enganar a si próprio: medir o desempenho das tuas automatizações.
- Quem assina. Um nome e um cargo do negócio, não um departamento.
Quem tem de assinar que o agente está concluído?
A pessoa que sofre as consequências se ele falhar: o dono do processo. Não quem compra a tecnologia nem quem a constrói. O fornecedor propõe os critérios e demonstra que se cumprem; o negócio decide se lhe chegam. Se só a área de tecnologia assinar, o que se aceita é que o sistema está de pé, não que o trabalho é bem feito.
A assinatura inclui o direito de recusar. Um documento que só se pode assinar é um trâmite. E ajuda uma segunda assinatura: a de quem vai manter o agente depois. Aceitar algo que ninguém saberá operar é empurrar o problema para o mês seguinte (ver quem mantém os agentes de IA quando já estão em produção).
| O que se escreve antes de começar | O que acontece se não se escrever | Quem o define |
|---|---|---|
| Um conjunto de casos reais | O fornecedor testa com o que sabe que funciona | O negócio fornece, o fornecedor ajuda a cobrir lacunas |
| Erro tolerado por tipo | Uma média bonita esconde o erro caro | O negócio, segundo o que lhe custa cada falha |
| Quando escala para uma pessoa | O agente improvisa precisamente onde não deve | Negócio e fornecedor, em conjunto |
| Permissões e ações com aprovação | O âmbito real descobre-se no dia do incidente | Negócio e responsável de segurança |
| Período de teste e métrica | «Concluído» mede-se por sensação | O negócio, com o fornecedor como consultor |
| Assinatura | O projeto não acaba ou acaba por cansaço | Um cargo do negócio com nome próprio |
O que acontece se não houver critérios de aceitação?
Há dois finais possíveis e nenhum é bom. No primeiro, o projeto nunca acaba: cada novo pedido é vivido como uma falha do agente, o fornecedor sente o âmbito a crescer sem limite e o cliente sente que paga para corrigir o que já comprou. No segundo, acaba por cansaço: dá-se por bom porque ninguém aguenta mais uma reunião, e o agente entra em produção sem que ninguém conheça a sua taxa de erro real.
O segundo final é o pior, porque parece um sucesso. É a versão contratual do que explicamos em porque falham os projetos de automatização com IA: o projeto não falha na demo, falha no vazio entre o que cada parte dava por entendido.
Como se escreve um critério que se possa mesmo verificar?
Com três ingredientes: um conjunto de casos, um limiar e uma condição de falha inegociável. Um exemplo de redação (os números são ilustrativos; os teus fixas tu, conforme o que te custa cada erro):
Repara na assimetria: o limiar negoceia-se, a condição de falha não. Há erros que se toleram numa proporção e erros que não se toleram de todo. Escrevê-lo evita a discussão mais cara do projeto, a que acontece quando a falha já chegou a um cliente.
Quando não é preciso um documento de aceitação formal?
Quando é um protótipo declarado como tal, uma experiência interna sem clientes nem dados pessoais, ou um caso em que errar é barato e reversível. Aí bastam uma frase e uma data: «isto é um teste e revê-se no dia X». Assim que o agente toca em clientes, dinheiro ou dados pessoais, a página escreve-se.
Se já tens um agente a funcionar e ninguém se lembra do que foi aceite, o momento de escrever o documento é agora, antes da próxima ampliação. E se estás prestes a contratar um, avaliar a qualidade dos agentes de IA é o trabalho que transforma esta página num conjunto de casos e num limiar executáveis.
A linha para levar: um agente não está concluído quando impressiona, mas quando alguém do negócio, com nome e cargo, assina que cumpre o que foi escrito antes de começar.
Fontes (consultadas a 27 de outubro de 2026): «The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed», RAND Corporation (2024). O cenário inicial e os números do exemplo são ilustrativos, não um caso real.