Quando o agente não sabe: as seis situações, e o que fica escrito para cada uma

"Ele vai inventar resposta?" é a pergunta errada, e é a única que fazem.

Quem cogita colocar um agente de IA entre a própria empresa e o cliente chega quase sempre com a mesma dúvida, e ela vem inteira nessa forma. E se ele inventar? E se responder errado para um cliente meu, com toda a confiança do mundo, e eu só descobrir depois?

A dúvida é boa. O problema é que a resposta que circula é sempre a mesma frase: ele não inventa, porque consulta a base de conhecimento da sua empresa, e quando não sabe transfere para um humano. Eu li doze materiais publicados sobre isso enquanto preparava este texto, entre páginas de fornecedor, guias de plataforma e artigos de mercado. Nenhum deles separa as situações em que o agente pode não saber. Todos descrevem um comportamento só.

Só que "não sei" não é um evento. Não encontrar a resposta na base é uma coisa. Encontrar duas respostas que se contradizem é outra. Não ter entendido o que a pessoa pediu é outra. Ter entendido perfeitamente e não ter permissão para fazer aquilo é outra. E ter permissão, mas estar diante de uma ação que não dá para desfazer, é outra ainda.

São situações diferentes, com causas diferentes, e a conduta correta em cada uma é diferente. Quando o material publicado trata as cinco como uma, ele não está simplificando: está escondendo o lugar onde a maioria dos problemas acontece.

O que vem abaixo é a divisão que eu uso para desenhar isso antes de um agente falar com cliente. Não é comparação de plataforma, não é tutorial de configuração e não promete que o agente para de errar. Promete uma coisa só: que você consiga perguntar a quem for construir o seu agente o que está escrito para cada uma das seis situações, e reconhecer quando a resposta não existe.

Responder sempre é o comportamento padrão, e ele foi treinado assim.

Antes das seis situações, vale entender por que a primeira delas precisa ser desenhada, e não vem pronta.

Um artigo publicado por pesquisadores da OpenAI em 2025 investiga exatamente isso, e a conclusão é desconfortável. Modelos de linguagem chutam quando estão inseguros porque os procedimentos de treino e de avaliação recompensam o chute em vez do reconhecimento da incerteza. A comparação que os autores usam é a de um aluno diante de uma prova difícil: quem responde qualquer coisa tem chance de acertar, quem deixa em branco tem zero. Se a nota é o que importa, chutar é a estratégia correta.

A consequência prática para quem vai contratar um agente é direta. Dizer "não sei" não é uma característica que vem de fábrica, e não é uma coisa que se compra escolhendo um modelo melhor. É configuração, é regra escrita e é disciplina de operação. O comportamento padrão, aquele que aparece se ninguém desenhar nada, é produzir uma resposta plausível.

Isso muda a leitura de tudo que vem depois. Quando um fornecedor diz que o agente reconhece o próprio limite, ele não está descrevendo uma propriedade do modelo. Está descrevendo, na melhor das hipóteses, um trabalho que alguém fez. A pergunta útil não é se o agente sabe reconhecer o limite. É quem escreveu o que ele faz em cada limite, e onde isso está registrado.

Vale dizer o que isso não significa. Não significa que agentes são inseguros por natureza, nem que a tecnologia não está pronta. Significa que a parte que decide se ele é confiável não está no modelo: está no que foi combinado antes de ligar.

"Não sei" não é um estado. São seis, e a diferença muda quem age depois.

As seis situações se organizam em três famílias, e a família importa porque ela diz de quem é o próximo passo.

Conhecimento. A pergunta foi entendida, e o que está em jogo é o que a base tem a dizer. Três situações moram aqui: a base sustenta a resposta; a base sustenta duas respostas que se contradizem; a busca não encontrou nada que sustente. O próximo passo, quando falha, é de quem cuida do conteúdo.

Compreensão. A base pode até ter a resposta, mas ninguém sabe qual pergunta foi feita. Uma situação mora aqui: o pedido não foi entendido. O próximo passo é de quem está conversando, e ele é o único caso em que a coisa certa a fazer é devolver uma pergunta.

Ação. A pergunta foi entendida, a resposta existe, e o que está em jogo é fazer alguma coisa no mundo. Duas situações moram aqui: o agente não tem permissão; ou tem permissão, e a ação não é reversível. O próximo passo é de quem detém autoridade, e não de quem cuida do conteúdo.

Repare no que a divisão faz. Uma base de conhecimento impecável não resolve nada na família de ação, porque ali o limite não é de informação. E uma política de permissões rigorosa não impede uma resposta errada na família de conhecimento, porque ali não se está executando nada. São problemas de naturezas diferentes, e tratá-los com a mesma frase é o que produz a sensação de que o agente "às vezes funciona".

Uma observação sobre o que não é uma situação. Encaminhar para uma pessoa aparece como conduta correta em quatro das seis, por quatro motivos diferentes, e por isso não entra na lista como se fosse a sétima. Encaminhar é o que o agente faz, não o que aconteceu com ele.

Conhecimento: encontrou, encontrou demais, ou não encontrou nada.

Situação um: a base sustenta a resposta. É o caso comum e o que quase todo mundo desenha bem. Existe um trecho recuperado que responde ao que foi perguntado, e ele é um só. O agente responde dentro do que aquele trecho diz, sem esticar, e informa de onde veio quando isso estiver combinado. Se a resposta depende de uma informação que muda, como preço, prazo ou política, informar também de quando ela é vale mais do que parece.

O que ele não faz aqui é ampliar. A resposta para "vocês atendem aos sábados?" é o que está escrito sobre sábado, não uma dedução educada sobre o funcionamento provável de um negócio parecido.

Aqui cabe desmontar a promessa mais comum da categoria, e vale usar documentação em vez de opinião. Existe uma técnica bastante difundida de fazer o modelo responder consultando os documentos da empresa em vez de responder de memória, e ela é a base de quase todo agente de atendimento sério. A documentação do Google Cloud para o serviço que verifica esse tipo de resposta é explícita sobre o que está sendo medido: o serviço avalia o quanto a resposta é sustentada pelos fatos fornecidos, e cita quais trechos sustentam cada afirmação. Ele confere a correspondência com as fontes que você deu, não a verdade daquilo fora delas.

A consequência é a frase mais importante desta seção. Base errada, consultada com perfeição, produz erro perfeitamente ancorado. Se a tabela de preço no seu servidor está desatualizada há quatro meses, o agente vai citar a fonte, vai acertar a correspondência e vai dizer o valor errado com uma segurança que ninguém questiona. Nenhuma tecnologia de consulta conserta conteúdo desatualizado, e vender isso como se conseguisse é o erro de comunicação mais frequente do mercado.

Situação dois: a base sustenta duas respostas que se contradizem. O site diz uma coisa, a tabela interna diz outra, e as duas foram recuperadas. Esse caso é mais comum do que parece em empresas que crescem sem arrumar a casa, e é o menos desenhado de todos.

A conduta correta é reconhecer o conflito e não escolher. O agente diz que encontrou informações divergentes, diz quais são, e encaminha. O que ele não pode fazer é o que acontece por padrão quando ninguém desenha: escolher em silêncio a que apareceu primeiro e apresentá-la como se fosse a única. Uma resposta errada que se sabe errada é um incidente. Uma resposta errada escolhida em silêncio entre duas é um incidente que ninguém vai descobrir.

Situação três: procurou e não encontrou. Nenhum trecho responde. E aqui vale um detalhe técnico que muda quem consegue resolver o problema. Um estudo publicado em 2024, que acompanhou três implementações reais desse tipo de sistema, catalogou os pontos onde a coisa falha, e "não encontrou" aparece em pelo menos três formas distintas: o conteúdo não está na base; o conteúdo está na base e não foi recuperado; e o conteúdo foi recuperado e não foi extraído da forma certa. Para quem está do lado de fora as três parecem idênticas, e o dono do conserto é diferente em cada uma. A primeira é de quem cuida do conteúdo. As outras duas são de quem construiu.

Para o agente, a conduta é a mesma nas três: dizer que não encontrou sustentação, não completar a lacuna por plausibilidade, registrar a pergunta e encaminhar quando houver rota definida. A diferença entre as três aparece depois, na hora de decidir o que fazer com o registro, e é por isso que registrar importa.

Nas três situações desta família existe uma pergunta anterior que quase ninguém faz antes de contratar: de quem é a base, quem consegue atualizá-la e o que acontece com ela se você trocar de fornecedor. Quem consegue mexer no conteúdo que sustenta as respostas, e como conferir isso antes.

Compreensão: quando o problema não é a base, é o pedido.

Situação quatro: não entendeu o pedido. A mensagem chegou ambígua, contraditória, ou misturando três assuntos na mesma frase. Isso não é falha de base, e mexer no conteúdo não melhora em nada.

A conduta correta é pedir esclarecimento, e é a única das seis em que devolver uma pergunta é a resposta certa. O esclarecimento precisa ser objetivo e específico: não "não entendi, pode reformular?", mas "você quer remarcar a consulta ou cancelar?". A primeira devolve o problema para quem já não sabia explicar. A segunda oferece um caminho.

O que o agente não pode fazer aqui é escolher uma interpretação em silêncio e responder a ela. É a falha mais difícil de detectar depois, porque a conversa parece ter funcionado: houve pergunta, houve resposta, e ninguém percebe que foram sobre coisas diferentes.

O esclarecimento também precisa de um teto. Insistir indefinidamente irrita, e a certa altura o problema deixou de ser resolvível por reformulação. Uma das plataformas de atendimento que documenta isso publicamente fixa o limite em duas tentativas antes de acionar o encaminhamento. Esse número é a escolha daquela plataforma, e não uma regra do assunto. O que precisa existir no seu caso é um teto qualquer, decidido por você e escrito, e não a ausência de teto.

Uma armadilha para evitar: nem toda pergunta ambígua merece esclarecimento. Se a ambiguidade não muda a resposta, perguntar é atrito. Se muda, perguntar é obrigatório. Quem desenha o agente precisa saber diferenciar as duas, e essa é a parte que exige conhecer o negócio, não a ferramenta.

Ação: ter permissão e conseguir executar não são a mesma coisa.

As duas últimas situações não são sobre saber. São sobre fazer, e é onde o discurso de mercado some por completo.

Situação cinco: entendeu, sabe fazer, e não tem permissão. O pedido é claro, a informação existe, e a ação exige um acesso ou uma autoridade que o agente não recebeu. Cancelar um pedido de outra pessoa, consultar um dado que exige identificação confirmada, alterar um cadastro.

A conduta correta é reconhecer o limite de acesso, dizer o que falta, e encaminhar para quem tem a autoridade. O que ele não pode fazer é contornar. E existe uma confusão específica que vale nomear, porque ela aparece em projeto real: capacidade técnica não é permissão. Um agente conectado a um sistema com credencial ampla consegue fazer muito mais do que deveria, e "consegue" nunca foi argumento para "pode".

Situação seis: tem permissão, e a ação não é reversível. Cancelar, cobrar, apagar, autorizar, prometer. São ações que o agente tecnicamente pode executar e que, uma vez executadas, ninguém desfaz com um pedido de desculpas.

A conduta correta aqui é a mais específica das seis: propor, e não executar. O agente monta a ação, mostra o que vai acontecer, e espera aprovação de alguém nomeado. A referência de segurança da OWASP para agentes de IA descreve exatamente esse desenho: separar a decisão da execução, de modo que o agente proponha e outro componente valide escopo, privilégio e estado de aprovação antes de qualquer coisa acontecer. E exigir confirmação explícita para ações destrutivas.

A mesma referência traz o princípio que resume a família inteira, e ele é mais simples do que a linguagem sugere: dê a cada ferramenta a permissão mais estreita que o trabalho exige. Um agente que só precisa consultar não precisa de acesso de escrita. Um agente que responde sobre horários não precisa conseguir alterar agenda.

A pergunta que abre essas duas situações vem antes da tecnologia e não é técnica: quem, dentro da sua empresa, pode autorizar o quê. Ela é a mesma pergunta que decide o andamento de qualquer projeto, e não muda por causa da ferramenta. Quem precisa liberar cada acesso, e por que essa parte não se delega junto com a execução.

Para cada situação, quatro respostas precisam estar escritas antes.

As seis situações viram instrumento quando cada uma responde a quatro perguntas. Não é pontuação, não é nota e não tem semáforo. É uma tabela que existe ou não existe.

O que o agente faz. A conduta. Sem ela, o comportamento é o padrão treinado, e o padrão treinado é responder.

O que o agente não faz. A conduta proibida naquela situação. É a coluna que ninguém publica, e é a que evita a maior parte dos incidentes, porque a maioria deles não é o agente falhando em responder: é o agente respondendo quando não deveria.

O que fica registrado. A pergunta original, o que foi encontrado, o que foi decidido e por quê. Aqui há uma razão técnica forte, e ela vem do mesmo estudo de 2024 citado acima: os autores concluem que a validação desse tipo de sistema só é viável durante a operação, e que a robustez evolui com o uso em vez de ser desenhada de uma vez no começo. Registro não é burocracia. É o único caminho por onde a coisa melhora.

Quem recebe o caso. Um papel nomeado, não "a equipe". Encaminhamento sem destinatário é fila sem dono, e fila sem dono é a forma mais educada de perder um cliente.

Sobre o encaminhamento, vale ser específico, porque é a conduta que quatro das seis situações produzem e por motivos diferentes. Encaminhar não é dizer "não consigo ajudar, procure o suporte". É passar o caso adiante com o que a pessoa já disse, com o que foi encontrado e com o motivo do encaminhamento, para que ninguém precise repetir a história do começo. E é definir o que acontece depois: se alguém responde no mesmo canal, em quanto tempo, e o que o cliente ouve enquanto isso.

Fecha o instrumento o que eu chamo de retorno. Quando a situação três se repete com a mesma pergunta, aquilo deixou de ser exceção e virou lacuna de conteúdo: entra na base. Quando a situação dois se repete, existem duas fontes brigando e alguém precisa decidir qual vale. Quando a quatro se repete, o problema costuma ser de como a pergunta chega, não de quem pergunta. É aqui que a coisa fica sua: quem lê esses registros e atualiza a base não precisa ser quem construiu o agente, e não deveria ser.

Um exemplo inventado, para trocar pelos seus. Uma clínica fictícia liga um agente no WhatsApp. Chega "queria saber sobre terça". O pedido é ambíguo e a ambiguidade muda a resposta, então o agente pergunta se é sobre horário de atendimento ou sobre um agendamento existente. A pessoa responde que quer saber o horário de terça. A base tem a tabela de horários, atualizada na semana anterior, e o agente responde com o horário e com a data da última atualização. Em seguida vem "então cancela a minha de quinta". O agente entendeu, a informação existe, e cancelar é irreversível: ele não cancela. Diz o que precisa para prosseguir, registra o pedido com o contexto da conversa e encaminha para a recepção, que confirma. Três situações, três condutas, e em nenhuma delas o agente precisou saber mais do que sabia.

Se as seis não têm resposta escrita, o próximo passo não é um agente.

Junte o que as seções anteriores pedem e você tem a lista do que precisa estar decidido antes de alguém escrever a primeira linha de configuração. Quais fontes valem e qual vence quando duas discordam. O que o agente faz quando não encontra. Quando ele pede esclarecimento e quantas vezes. O que ele pode acessar. Quais ações ficam proibidas e quais ficam condicionadas a aprovação. Quem recebe cada tipo de encaminhamento. O que fica registrado. E quem mantém o conteúdo depois que o projeto acabar.

Se essa lista não tem respostas, o achado não é que o seu caso é ruim. É que o próximo passo não é implementar um agente: é organizar a base, as permissões e o fluxo de exceção. Esse trabalho tem valor por si só, resolve parte do problema sem nenhuma tecnologia nova, e é a resposta mais frequente que eu dou nessa conversa.

Preciso dizer de onde eu falo, em uma linha: eu construo agentes de IA, e mesmo assim a saída acima é legítima e é a que eu recomendo quando a lista está vazia.

Vale registrar o que este instrumento não faz. Ele não estima quanto o agente erra, e não existe número honesto para isso fora do seu caso e das suas perguntas reais. Ele não elimina erro: as seis condutas reduzem a chance de o erro passar despercebido, e é uma promessa menor e mais verdadeira do que a que circula por aí. Ele não escolhe plataforma nem tecnologia, e não substitui o teste com perguntas reais antes de o agente falar com cliente, que continua sendo a etapa que mais alonga um projeto e a que menos se pode pular.

Ele também não decide se o seu caso justifica contratar alguma coisa. Essa é uma verificação anterior e independente desta, e ela tem saída própria. A verificação anterior a esta, e as saídas dela que não terminam em projeto.

E quando a lista tem respostas, quando existe base confiável, quando os limites estão definidos, quando alguém acompanha o que o agente respondeu e o que ele não soube, e quando o caminho da exceção está claro, aí a conversa deixa de ser sobre risco e passa a ser sobre escopo. Como um agente é construído nessas condições, do entendimento ao teste com pergunta real.