A IA inventa resposta quando não tem a informação?

Por que uma IA "sem freio" inventa resposta?

Um modelo de linguagem não sabe distinguir, por conta própria, "fato real do negócio" de "frase que parece plausível". Ele foi treinado pra completar texto de um jeito coerente — e coerente nem sempre é verdadeiro. Pergunte a hora de funcionamento, o preço de um serviço ou se a empresa atende um bairro específico: se não houver nada por fora garantindo essa resposta, o modelo responde com a mesma confiança tanto quando sabe quanto quando está chutando. O cliente do outro lado da tela não vê diferença entre as duas — só descobre quando o combinado não se sustenta.

É por isso que "treinar a IA pra não inventar" com instrução de prompt resolve só parte do problema: funciona na maioria das conversas e falha exatamente na hora que mais custa, quando o lead pressiona por um número.

O grounding trava a conversa, ou só a frase?

Aqui está o ponto que a maioria confunde — e que separa um guardrail bem desenhado de um que trava o atendimento inteiro: o grounding audita o que a IA afirma, não o que ela decide. São duas coisas diferentes, e a mecânica trata cada uma de um jeito.

A IA continua decidindo normalmente — para qual estágio mover a conversa, se vale a pena marcar um próximo passo, quais perguntas fazer, quando escalar. Nada disso passa pelo grounding; é fluxo de qualificação, roteado em código, acontecendo o tempo todo. O que o grounding intercepta é a frase pronta, no instante antes de ela virar mensagem no WhatsApp do cliente: se aquela frase contém uma afirmação de fato — um preço, uma data, uma cobertura, um "sim, nós atendemos isso" — essa afirmação específica é comparada com a lista de fatos autorizados daquele negócio. Se bate, segue. Se não bate, só aquela frase é reescrita ou substituída; a conversa não para, a qualificação não reinicia, o lead não perde o lugar onde estava.

Na prática: o agente pode estar no meio de agendar uma visita, confirmar um horário, levantar um pedido — e, ao mesmo tempo, não ter autorização pra cravar um dado específico que apareceu ali. As duas coisas correm em paralelo, sem uma travar a outra.

Por que um fato cadastrado às vezes não basta?

Tem uma regra mecânica pouco intuitiva por trás disso, documentada como invariante da plataforma: um fato que o agente precisa dizer tem que existir em dois lugares ao mesmo tempo — na lista de fatos que o guardrail confere, e no material que alimenta a geração da resposta do modelo. Cadastrar o fato só no guardrail não resolve: o modelo nunca lê aquela lista enquanto escreve a frase, então ele não "conhece" o fato — e o resultado típico é uma evasiva tipo "depende da agenda", mesmo quando a informação existe no sistema, só não chegou no lugar certo.

Na prática, isso significa que configurar essa trava não é só "anotar os preços num lugar" — é garantir que o mesmo fato apareça nos dois pontos do fluxo que precisam dele. Esse é o tipo de detalhe que a camada de guardrails em camadas existe pra cobrir: o grounding é uma dessas camadas, não a única, e cada uma resolve um risco diferente do atendimento.

Quando falta o fato, a IA trava ou escala?

Nem uma coisa nem outra, no desenho certo. A regra de design é que o fallback — a resposta de reserva pra quando a afirmação não pode ser confirmada — sempre fecha o loop. Isso quer dizer duas coisas na prática: a conversa nunca morre num silêncio sem resposta, e a IA nunca repete a mesma frase genérica duas vezes seguidas quando não sabe algo — ela varia a resposta de recuperação, sempre apontando um próximo passo real ("vou confirmar e te retorno", "posso te chamar numa conversa rápida com o time?"). Escalar pra um humano, nesse contexto, não é a IA falhando: é o mecanismo funcionando exatamente como projetado — melhor um "vou confirmar" honesto do que um número chutado que a empresa vai ter que desmentir depois.