Quando a sua IA se engana na presença de um cliente
Como projetar caminhos de escalada, 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 inadequada - é 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 imediata e contato com o cliente. Um erro que afeta dinheiro, segurança, um compromisso legal ou dados pessoais é um evento de parada: a funcionalidade deve ser desativada até que você entenda o que aconteceu.
Escreva essas três categorias em uma página. Atribua a cada categoria um proprietário, um relógio de resposta e 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 de desligamento for um deploy, você não tem um interruptor de desligamento.
Ofereça ao cliente uma pessoa, não um loop
O padrão mais danoso em serviços com IA é o loop fechado: o cliente discorda do sistema, o sistema se explica novamente e não há 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-o 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 provoque uma intervenção humana proativamente também. Se um cliente repetir-se duas vezes, se uma conversa durar muito tempo ou se o tópico envolver reembolsos ou reclamações, entregue sem esperar ser solicitado.
O pedido de desculpas é uma decisão de negócios
Quando você entra 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 "hallucinação de IA" com um cliente - soa como uma desculpa para uma empresa que enviou algo que não controlava.
Em seguida, decida a política de remediação antecipadamente. Se o sistema citou um preço errado, você o honrará? Se ele prometeu uma data de entrega que você não pode cumprir, o que você oferece? Responda a essas questões em uma sala, uma vez, em vez de 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
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, churned
As regras de retenção e acesso vêm com isso. Decida por quanto tempo você armazena 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 trinta minutos antes de entrar no ar. Leve uma resposta errada plausível, passe-a por detecção, escalonamento, contato com o cliente e correção. Você encontrará as lacunas imediatamente: sem proprietário nos fins de semana, sem maneira de desativar uma funcionalidade sem desativar todas elas, sem 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.