Para testar IA no atendimento sem colocar a operação inteira em risco, escolha uma tarefa estreita, crie casos de avaliação representativos, comece sem resposta autônoma, mantenha um responsável humano e defina antes do teste o que permite avançar, o que exige ajuste e o que interrompe o piloto.
Comece pelo contrato operacional, não pelo modelo
Escreva em uma página a tarefa permitida, a população atendida, os canais, as fontes de conhecimento, as ações proibidas, o responsável pelo piloto e o limite de risco. “Melhorar atendimento com IA” não é escopo. “Sugerir respostas sobre status de pedido usando uma base aprovada, sem alterar pedido, preço ou prazo” é verificável.
O núcleo do AI Risk Management Framework do NIST pede que propósito, contexto, limites de conhecimento, supervisão humana e tolerância a risco sejam documentados. Ele também recomenda testar antes da implantação e monitorar o comportamento em produção. Para uma equipe de atendimento, isso vira um contrato simples: o que a IA pode fazer, que evidência deve usar, quando deve parar e quem assume a conversa.
Defina a alternativa sem IA. Se o piloto falhar, a operação precisa continuar com fila, mensagens aprovadas e responsáveis humanos. Um teste reversível protege o cliente e torna o aprendizado mais honesto: a equipe não precisa defender a automação apenas porque desligá-la seria caótico.
Cinco etapas entre a ideia e a expansão
Não trate “piloto” como um único botão de ativação. Separe etapas com evidência e decisão ao final de cada uma.
| Etapa | Exposição do cliente | Evidência para avançar |
|---|---|---|
| Avaliação offline | Nenhuma | Casos comuns, limites e falhas críticas testados |
| Modo sombra | Nenhuma resposta da IA | Sugestões comparadas com decisões humanas reais |
| Modo assistido | Humano revisa antes do envio | Aceite, correções e motivos de rejeição registrados |
| Piloto ao vivo limitado | Um escopo, canal ou fila | Critérios de qualidade, segurança e handoff passam |
| Expansão controlada | Aumento gradual | Estabilidade por janela definida e rollback testado |
“Modo sombra” aqui significa gerar e registrar uma sugestão para comparação, sem mostrá-la ao cliente nem executar uma ação. No modo assistido, a pessoa pode aceitar, corrigir ou rejeitar. Essas correções são dados de avaliação; não devem virar apenas um número de aceitação. Registre o motivo: fonte ausente, interpretação errada, tom inadequado, risco, falta de contexto ou handoff necessário.
A metodologia de testagem publicada pela ANPD para seu Sandbox Regulatório de IA e proteção de dados organiza experimentos em preparação, experimentação e gestão de riscos, avaliação e ajuste. Ela não é um checklist obrigatório para todo negócio, mas oferece um padrão útil: confrontar promessas com documentos, registros técnicos, testes e pareceres, revendo arquitetura, fluxos de dados e controles a cada ciclo.
Monte um conjunto de casos que represente o trabalho real
Comece com perguntas frequentes, mas inclua variações, linguagem ambígua, informações faltantes, clientes frustrados, dados conflitantes, tentativas de desviar instruções e situações que devem ir para uma pessoa. Separe o conjunto usado para ajustar do conjunto usado para decidir. Se toda falha entra no ajuste e é imediatamente retestada no mesmo material, o resultado pode parecer melhor sem generalizar para novas conversas.
As boas práticas de avaliação da OpenAI recomendam testes específicos da tarefa, avaliação cedo e frequente, registros úteis, dados próximos da distribuição real e calibração de métricas com julgamento humano. A orientação também trata avaliação como processo contínuo, não como cerimônia antes do lançamento.
- Casos comuns com resposta e fonte esperadas
- Casos de borda, dados ausentes e linguagem local
- Pedidos fora do escopo e tentativas de induzir ação indevida
- Situações que exigem passagem para uma pessoa
- Falhas históricas convertidas em testes de regressão
- Exemplos novos reservados para a decisão final
- Revisão por quem conhece a operação e atende clientes
Quando usar conversas reais, minimize e controle os dados. Não copie históricos completos para planilhas soltas. Defina acesso, retenção e finalidade, remova o que não é necessário e envolva os responsáveis internos por privacidade e segurança. O guia de segurança da informação da ANPD reúne medidas administrativas e técnicas para proteger dados pessoais; ele deve ser lido conforme o contexto da organização, não como aconselhamento jurídico desta página.
Decida antes quais são os critérios de go/no-go
Não existe uma taxa universal que torne um atendimento seguro. O limite depende da tarefa e do impacto do erro. Uma sugestão de etiqueta pode tolerar correção humana; uma ação que muda cadastro, pagamento, cancelamento ou acesso exige controles muito mais fortes e talvez deva ficar fora do piloto.
| Dimensão | Pergunta de decisão | Stop condition |
|---|---|---|
| Correção | A resposta usa a fonte aplicável e não inventa fatos? | Falha crítica ou padrão novo de erro |
| Escopo | A IA reconhece quando não deve responder? | Ultrapassa ação, tema ou permissão definida |
| Handoff | Transfere com contexto e responsável visível? | Cliente fica preso ou caso fica sem dono |
| Privacidade e segurança | Dados e acessos permanecem no limite aprovado? | Exposição, acesso indevido ou registro inseguro |
| Operação | Fila, latência e exceções continuam administráveis? | Backlog, falha técnica ou perda de contexto |
| Recuperação | A equipe consegue desativar e reconciliar? | Rollback não funciona ponta a ponta |
Combine métricas agregadas com revisão de conversas. Taxa de aceite alta pode esconder correções silenciosas; média de qualidade pode esconder uma falha rara e grave. Use o scorecard de auditoria de conversas de IA para separar evidência, resultado, risco e handoff. Dê poder ao responsável do turno para interromper o fluxo sem esperar uma reunião executiva quando uma condição crítica aparecer.
Monitore o piloto e teste o rollback de verdade
Durante o piloto, acompanhe diariamente falhas críticas, rejeições humanas, motivos de correção, handoffs, recontato, reclamações, latência e backlog. Segmente por intenção, canal, versão, fonte e fila. Uma melhoria média pode esconder piora em português informal, clientes novos ou uma categoria sensível.
Registre a versão do fluxo, das instruções, das fontes e das integrações. Toda mudança relevante deve rodar novamente o conjunto de regressão antes de entrar no piloto. O perfil de IA generativa do NIST reforça gestão de riscos ao longo do ciclo de vida; mudar modelo, conhecimento ou ferramenta muda o sistema avaliado, mesmo que a tela pareça igual.
Teste o rollback em horário controlado: pare a automação, devolva casos em andamento à fila correta, preserve o histórico, avise a equipe, reconcilie ações pendentes e confirme que o cliente tem uma rota humana. O playbook de incidente de IA ajuda a transformar falhas encontradas em contenção, correção e novos testes.
Plano prático de quatro semanas
- Semana 1 — contrato e avaliação: escolha uma tarefa, mapeie riscos, fontes, dados e responsáveis; crie casos comuns, de borda e proibidos; teste offline.
- Semana 2 — sombra: gere sugestões sem exposição ao cliente; compare com decisões humanas; classifique divergências e corrija conhecimento, instruções ou escopo.
- Semana 3 — assistência: permita envio somente após revisão; meça aceite, edição, rejeição, handoff e tempo operacional; teste o rollback.
- Semana 4 — piloto limitado: libere apenas a população aprovada, revise diariamente, rode regressões após mudanças e tome uma decisão documentada de manter, ajustar, ampliar ou encerrar.
O resultado do piloto não é “a IA funcionou”. É uma decisão rastreável sobre uma tarefa, sob condições definidas, com limitações conhecidas, responsáveis nomeados e um próximo passo reversível. Essa disciplina permite aprender rápido sem transferir o custo do experimento para o cliente.
