Quando sua IA erra na frente de um cliente
Como projetar caminhos de escalonamento, pedidos de desculpas e trilhas de auditoria antes que o seu sistema de IA cometa seu primeiro erro público.
Decida o que significa "errado" antes de precisar
Nem todas as respostas erradas merecem a mesma reação. Classifique-as antes do lançamento, em linguagem clara, com o nome de alguém atribuído a cada classificação.
Um problema de tom — o sistema é rude ou formal de maneira pouco útil — é uma questão de treinamento para o lançamento da próxima semana. Um erro factual sobre uma política, um preço ou uma data de entrega é uma correção do mesmo dia e um contato com o cliente. Um erro que afeta dinheiro, segurança, um compromisso legal ou dados pessoais é um evento de parada: a funcionalidade é desativada até que você entenda o que aconteceu.
Escreva essas três categorias em uma página. Atribua a cada categoria um responsável, um relógio de resposta e uma autoridade explícita para desligar o sistema. A pessoa que pode puxar o plugue não deve precisar encontrar um executivo primeiro. Se o seu único interruptor for o deploy, você não tem um interruptor.
Ofereça ao cliente uma pessoa, não um loop
O padrão mais prejudicial em serviços com IA é o loop fechado: o cliente discorda do sistema, o sistema se explica novamente e não há uma saída visível. As pessoas perdoam uma resposta errada. Elas não perdoam ser presas.
Cada interação com IA precisa de uma rota para um humano disponível na primeira solicitação, não na terceira. Faça isso visível na interface, não em uma página de ajuda. Encaminhe-a para alguém que possa ver a conversa completa que o cliente acabou de ter, para que o cliente não precise recontar tudo. E acompanhe a taxa de escalonamento como uma métrica de destaque — um sistema que nunca escala geralmente é um sistema cuja saída ninguém consegue encontrar.
Estabeleça um limite que acione uma intervenção humana proativamente também. Se um cliente repetir-se duas vezes, se uma conversa durar mais do que o esperado ou se o tópico envolver reembolsos ou reclamações, encaminhe sem esperar ser solicitado.
O pedido de desculpas é uma decisão de negócios
Ao entrar em contato com um cliente sobre uma resposta errada, três coisas importam: velocidade, especificidade e o que você oferece para corrigir isso. Redija o modelo agora, enquanto ninguém está sob pressão.
Diga o que o sistema errou. Diga a posição correta. Diga o que você está fazendo para que isso não se repita. Não culpe o modelo, não explique a arquitetura e não use a frase "halucinação da IA" com um cliente — isso soa como uma desculpa de uma empresa que enviou algo que não controlava.
Em seguida, decida a política de remediação com antecedência. Se o sistema citou um preço errado, você o honrará? Se ele prometeu uma data de entrega que não pode cumprir, o que você oferece? Responda a essas perguntas em uma sala, uma vez, e não caso a caso sob pressão. O custo de uma política consistente é quase sempre menor do que o custo da improvisação.
Registre o que você desejará ter registrado
Um rastro de auditoria é o que transforma um argumento em uma investigação. Capture-o desde o início, porque você não poderá reconstruí-lo mais tarde:
- O entrada exata e a saída exata, com carimbo de data e hora e ID de conversa que o cliente possa citar
- Qual modelo e qual versão produziram isso, e qual prompt ou configuração estava ativa
- Quais documentos ou registros o sistema recuperou, para que você possa diferenciar uma má fonte de uma má resposta
- Toda intervenção humana: quem escalonou, quem sobrepôs, o que eles mudaram
- O resultado — resolvido, reembolsado, reclamado, churnado
As regras de retenção e acesso vêm com isso. Decida por quanto tempo você armazena as conversas, quem pode acessá-las e como um cliente exercendo seus direitos de dados recebe uma resposta limpa. Revisão legal antes do lançamento é mais barata do que revisão legal após uma reclamação.
Ensaie uma vez
Faça um teste de 30 minutos antes de ir ao vivo. Leve uma resposta errada plausível, passe-a pelo processo de detecção, escalonamento, contato com o cliente e correção. Você encontrará as lacunas imediatamente: nenhum responsável nos fins de semana, nenhuma maneira de desativar uma funcionalidade sem desativar todas e nenhum registro de qual prompt versão estava ativo.
Tudo acima é pouco glamouroso, e é a parte que determina se uma resposta errada permanece uma resposta errada. Construímos esses caminhos em sistemas antes do lançamento, em vez de depois da primeira semana ruim — o peso é mais fácil de carregar quando alguém já planejou para isso.