Apanhar alucinações da IA: 3 guardrails para equipas B2B

Como são as alucinações da IA em workflows B2B reais

Uma alucinação é quando o modelo gera uma resposta com tom seguro mas errada. No B2B aparece em três formas clássicas: (1) inventar um número de encomenda que não existe para um pedido de suporte, (2) "citar" uma data que não está realmente no contrato ao resumi-lo, (3) inventar uma categoria nova ao classificar faturas fora do conjunto definido.

As três partilham o mesmo padrão: sem âncora real, o modelo preenche o vazio. O problema é que a saída parece confiante — mesmo quando errada. "A IA erra" não é acionável; é preciso saber onde e porquê. Os três guardrails abaixo fazem isso.

Três guardrails: fonte, regra, humano

1) Citação de fonte: o modelo devolve cada resposta com o id ou número de linha do documento fonte. Sem fonte, responde "não sei". As alucinações caem ~80%.

2) Pré-check por regras: validar a saída contra regras de domínio antes de chegar — o número de encomenda tem 8 dígitos? A categoria da fatura está na lista? O formato de data é válido? Estes checks baratos em Python apanham a maioria.

3) Aprovação humana prévia: ações de alto risco (reembolsos, assinaturas de contrato) são propostas pela IA mas aprovadas por um humano. A IA trata ~95% sozinha; os 5% de exceções são encaminhados a si para revisão.

Os três juntos: em auditorias independentes a taxa de alucinação cai abaixo dos 2%.

Construir um processo de avaliação (eval) antes de lançar

Não é possível detetar uma taxa de alucinação apenas olhando para os resultados; é preciso um conjunto de teste. Construa um "golden set" de 50 a 200 exemplos reais com respostas corretas conhecidas, e garanta que cobre casos-limite — dados em falta, consultas ambíguas, pedidos fora do âmbito. Corra o modelo contra esse conjunto antes de cada alteração de prompt ou de modelo, não apenas no lançamento.

Acompanhe dois números distintos: a exatidão (se deu a resposta certa) e a taxa de abstenção (se disse corretamente "não sei" quando devia). Um modelo que nunca se abstém parece confiante, mas é mais arriscado; um modelo que se abstém demasiadas vezes é incómodo, mas mais seguro. O limiar certo depende de quão dispendiosa é uma resposta errada em comparação com uma resposta evitada.

Os testes adversariais são tão importantes como os testes de casos normais — alimente deliberadamente o modelo com consultas concebidas para provocar alucinações: perguntas sobre entidades que não existem, pedidos que misturam dois registos, prompts que pedem para extrapolar para além do documento de origem. Se não conseguir falhar de forma controlada num teste, também não vai falhar de forma controlada em produção.

Trate isto como um pipeline vivo, e não como uma barreira de uma única vez. Sempre que alterar o prompt, trocar de modelo ou adicionar uma nova fonte de documentos, corra novamente o conjunto de avaliação e compare os novos números de exatidão e abstenção com a sua base de referência antes de implementar em produção. É a mesma disciplina dos testes de regressão no software tradicional — só que testa julgamento em vez de lógica.

Que tarefas apresentam maior risco de alucinação

Nem todas as tarefas de IA acarretam o mesmo risco, pelo que o orçamento dedicado a barreiras de proteção (guardrails) também não deve ser distribuído de forma uniforme. A geração de conteúdo aberto — redigir um e-mail para um cliente, resumir uma reunião, escrever texto de marketing — deixa espaço para a criatividade, mas é exatamente nesse espaço que a alucinação se esconde: estatísticas inventadas, citações fabricadas, promessas que a empresa nunca fez. Esta é a categoria de maior risco, porque não existe um resultado "correto" fixo para comparar, apenas um leque de resultados aceitáveis.

A extração numérica e financeira fica logo a seguir. Extrair um total de uma fatura, calcular um desconto, extrair um número de identificação fiscal — os erros aqui são silenciosos (o número parece plausível) e dispendiosos (alimenta diretamente a movimentação de dinheiro). Afirmações de natureza legal ou próxima da área médica — obrigações contratuais, declarações de conformidade, indicações de dosagem ou de segurança — pertencem ao mesmo nível de risco elevado: um único erro e o dano resultante não é constrangimento, é responsabilidade legal.

No extremo oposto, a extração estruturada segundo um esquema fixo — analisar um currículo para extrair nome/e-mail/competências, classificar um ticket numa de 12 categorias, atribuir a uma transação um código de comerciante — é comparativamente de baixo risco. O modelo tem menos espaço para inventar porque o espaço de resultados é limitado e fácil de validar mecanicamente: pode verificar-se que a categoria existe, que o e-mail tem um "@", que o valor é uma das 12 opções. A classificação num conjunto fechado e pequeno comporta-se da mesma forma — mesmo quando o modelo erra, falha dentro dos limites definidos, o que é um modo de falha fundamentalmente mais barato.

Use este gradiente para decidir onde investir o esforço em barreiras de proteção. As tarefas de baixo risco e esquema fechado podem, muitas vezes, funcionar com validação ligeira e verificações pontuais. As tarefas de alto risco, abertas ou numéricas/legais merecem o conjunto completo descrito na secção anterior — citação de fontes, verificações de regras e um humano no ciclo — antes de deixar a automação tocar num cliente ou num livro de contas.