E se a única trava da minha IA de atendimento falhar?
Não existe trava única numa IA de atendimento bem montada. Se a sua depende de uma checagem no fim da linha, ela tem um ponto único de falha — e ponto único de falha, mais cedo ou mais tarde, falha. A proteção que aguenta vem em camadas independentes: uma confere cada afirmação antes dela sair (preço, prazo, promessa), outra trava a ação que não dá pra desfazer, outra impede o agente de mudar de ideia no meio da conversa, e a última garante que, quando a pergunta foge do roteiro, a conversa não trava nem inventa resposta — ela sempre volta pra um humano. Se uma camada escapa, a de trás segura.
Por que uma checagem no fim não resolve?
Uma trava só é um ponto único de falha — e todo ponto único de falha, cedo ou tarde, falha. Se a sua IA só confere o texto pronto antes de mandar, basta um caso fora do previsto pra passar batido: a checagem final enxerga a frase inteira, não enxerga sozinha se o preço ali dentro é real ou inventado, se a ação que ela vai disparar pode ser desfeita, ou se ela já prometeu o contrário duas mensagens atrás. Um check genérico tentando resolver quatro problemas diferentes de uma vez é frágil por desenho.
A alternativa não é "fazer a checagem melhor" — é separar o que cada camada vigia, cada uma respondendo uma pergunta diferente, e nenhuma dependendo da outra ter funcionado.
Quais são essas camadas, na prática?
São quatro, cada uma cuidando de um risco específico:
- Grounding — confere cada afirmação antes dela chegar no cliente: se o agente disse um preço, uma data, uma condição, esse dado precisa bater com o que o negócio cadastrou. Importante: o grounding valida o que o agente afirma, não o que ele decide — ele não julga se a rota da conversa está certa, só se o fato dito é real. E um fato só existe pro grounding se estiver em dois lugares ao mesmo tempo: na lista de fatos que o sistema usa pra conferir, e no texto que o modelo usa pra responder. Fato só num lugar não existe pro modelo — ele responde evasivo ou inventa.
- Gate por reversibilidade × risco — decide o que precisa de aprovação humana antes de sair. A régua não é "o lead parece importante", é "dá pra desfazer se der errado". Qualificar o lead e registrar no CRM roda sozinho; o que trava é a ação que não tem volta.
- Decision-lock — depois que a conversa decide uma rota, ela vira fato travado no código. O modelo não fica re-decidindo a cada mensagem nova — isso é o que impede o flip-flop, aquele vai-e-volta que confunde o cliente no meio do atendimento.
- Fallback que fecha o loop — quando a pergunta foge de tudo previsto, o agente não trava nem repete a mesma frase morta: ele reconhece que aquilo específico não sabe responder e encaminha pra um humano — sem deixar o cliente no vácuo esperando.
Nenhuma dessas quatro substitui a outra. Se o grounding deixar passar uma afirmação torta, o gate de risco ainda segura a ação sensível que viria depois. Se o gate não se aplicar porque a ação é reversível, o decision-lock evita que o agente contradiga o que já disse. É assim que uma resposta errada não vira uma ação errada: cada camada corta o problema num ponto diferente da cadeia.
E se o agente tentar mudar de ideia no meio da conversa?
Essa é a função específica do decision-lock, e ela resolve um problema que as outras três camadas não resolvem: depois que a conversa decide uma rota (qual oferta faz sentido pra aquele lead, por exemplo), essa decisão vira fato travado no código — o modelo de linguagem não recebe a tarefa de "decidir de novo" a cada mensagem nova, só de escrever a resposta em cima da decisão que já existe. Ela só é reaberta sob um sinal novo e concreto, definido em regra fixa, nunca por uma impressão do modelo. É uma camada que não tem nada a ver com fato errado (isso é grounding) nem com ação arriscada (isso é o gate) — ela existe só pra matar o vaivém que confunde o cliente no meio do atendimento.
Repara que essa é a terceira pergunta diferente que uma proteção de verdade precisa responder — depois de "o que foi dito é real?" e "essa ação pode ser desfeita?" vem "essa conversa está sendo coerente com ela mesma?". Três perguntas, três camadas, nenhuma cobrindo o território da outra.
O que acontece quando a pergunta foge do script?
É o fallback que entra — e o detalhe que separa um bom fallback de um ruim é esse: ele fecha o loop. Um fallback ruim repete a mesma frase genérica toda vez que não entende, e o cliente sente que está falando com uma gravação. Um fallback que funciona reconhece explicitamente que aquele ponto específico está fora do que ele pode responder com segurança, e passa a conversa pra um humano já com o resumo do que foi dito até ali — em vez de deixar a pessoa catando uma resposta que não vai vir.
É por isso que as quatro camadas trabalham juntas em vez de na fila: cada uma assume que as outras podem falhar, e nenhuma aposta que "a anterior já resolveu".
O histórico do próprio agente de atendimento da Estefani & Co é a prova de que uma camada só não cobre tudo. Ao longo da construção e dos testes, o time precisou endereçar, em momentos e por causas diferentes, quatro pontos separados do mesmo agente: o portão que decide quando propor um próximo passo ao lead — que numa revisão de 17/07/2026 teve que virar regra em código, fora do prompt, porque uma instrução de texto sozinha não travava direito (o modelo obedecia rápido demais); a trava que impede o agente de reabrir uma rota de conversa já decidida sem motivo novo; o que o agente tem permissão de afirmar sobre preço e prazo, auditado contra os fatos cadastrados daquele negócio antes de sair pro cliente; e o que acontece quando uma ferramenta interna falha no meio do atendimento, pra conversa nunca ficar sem resposta. Nenhuma dessas quatro correções resolveu as outras três — cada uma fechou um buraco que as outras três não cobriam, porque são quatro tipos de falha sem relação entre si. É a prova, no histórico real do próprio agente, de que camada em guardrail não é redundância por paranoia: é a única forma de cobrir riscos que não se parecem entre si.
Perguntas frequentes
Um bom prompt não basta pra IA nunca inventar preço?
Não sozinho. O grounding roda depois do texto pronto e confere cada afirmação de preço, prazo ou condição contra os fatos que o negócio cadastrou — se não bate, não sai. Instrução de texto é um pedido; grounding é uma checagem.
Toda ação da IA passa por aprovação de um humano?
Não — só a que é difícil ou impossível de desfazer. Qualificar o lead e registrar no CRM roda sozinho; o gate trava a ação irreversível, nunca a que só "parece" importante por causa do interesse do cliente.
A IA pode mudar de ideia no meio do atendimento?
A rota decidida vira fato travado assim que escolhida — o modelo não re-decide a cada mensagem nova. Só reabre sob um sinal novo e concreto, definido em código, nunca por sensação do modelo. É o que evita o vai-e-volta que confunde o cliente.
E se a pergunta do cliente for algo que a IA nunca viu antes?
O fallback não repete a mesma frase nem trava a conversa: reconhece que aquele ponto específico foge do que pode responder com segurança e passa pra um humano com o resumo da conversa até ali.
Se uma dessas camadas falhar, o atendimento todo quebra?
Não é esse o desenho. São checagens independentes — se uma deixa passar algo, a seguinte ainda segura antes de chegar no cliente. É redundância de propósito, não retrabalho.