Seu produto precisa de IA em qual etapa?

Como escolher uma tarefa para a IA, comparar o resultado com o processo atual e limitar o que ela pode fazer antes de colocar um agente em produção.

neste artigo

"Vamos colocar IA no atendimento" ainda não descreve um projeto. Pode significar classificar uma mensagem, encontrar um pedido ou responder ao cliente. Cada uma dessas tarefas pede dados diferentes e aceita erros diferentes.

Considere uma operação de suporte em que alguém lê uma mensagem, procura a compra e encaminha o caso. É possível testar a classificação sem entregar ao modelo a permissão de alterar a compra. Esse recorte ajuda a descobrir se a IA melhora o trabalho antes de aumentar sua responsabilidade.

Nossa preferência é começar pela menor etapa que tenha valor sozinha. Se classificar mensagens não ajuda ninguém a terminar o atendimento, a demonstração bonita não justifica a integração.

Escolha uma tarefa com uma saída verificável

Uma primeira versão poderia sugerir uma categoria e apresentar o trecho da mensagem que sustenta a escolha. O atendente aceita ou corrige a sugestão. A aplicação registra as duas decisões.

Antes de desenvolver, reúna uma amostra de mensagens que você tem autorização para usar. Remova dados desnecessários. Inclua pedidos comuns, mensagens ambíguas e casos que devem ir direto para uma pessoa. Separe parte dos exemplos para avaliar mudanças futuras, sem usá-los para ajustar o prompt.

Peça a quem conhece a operação para classificar os mesmos casos. Quando duas pessoas discordam, talvez falte uma regra de atendimento. Trocar o modelo não resolve uma categoria que a própria equipe não sabe definir.

Um fluxo fixo pode ser suficiente

A Anthropic distingue fluxos com etapas definidas no código de agentes que escolhem seus próximos passos. Essa diferença ajuda a decidir quanta liberdade a tarefa precisa.

No exemplo do suporte, a sequência pode ser fixa. Receber a mensagem, pedir a classificação, validar a saída e mostrar a sugestão ao atendente. O código decide a ordem. O modelo interpreta o texto.

Um agente passa a fazer sentido quando os próximos passos dependem de descobertas intermediárias. Mesmo nesse caso, descreva quais ações ele pode executar e quando deve parar. "Resolver o atendimento" é amplo demais para virar uma permissão.

Compare o custo do atendimento completo

Medir apenas a porcentagem de categorias corretas deixa parte do trabalho de fora. Uma classificação errada pode passar por duas equipes antes de voltar ao começo. Uma sugestão correta também pode levar tanto tempo para aparecer que ninguém espera por ela.

Para um piloto, acompanhe o tempo até o encaminhamento correto, as correções feitas pelo atendente e os casos sem resposta útil. Some o custo das chamadas e o tempo humano gasto na revisão. Compare com o processo atual usando casos de dificuldade parecida.

Não trate o nível de confiança declarado pelo modelo como prova de acerto. Defina critérios observáveis para revisão humana, como categoria ausente, dados insuficientes ou solicitação fora do escopo.

Estabeleça o critério de continuidade antes do piloto. Um exemplo seria aceitar a sugestão apenas se ela reduzir o tempo de triagem sem aumentar encaminhamentos incorretos. Os limites numéricos dependem da operação e precisam de uma medida inicial.

Permissão fica no código

Um texto de cliente pode conter instruções para ignorar regras. A aplicação deve tratá-lo como conteúdo recebido. Esse texto não pode conceder acesso a ferramentas ou a dados de outro cliente.

No piloto de classificação, o modelo não precisa de credenciais para editar pedidos. Se uma versão futura puder executar ações, cada chamada deve passar pela autorização do servidor. Limite os recursos acessíveis e registre a ação com seu resultado.

Defina também um teto de tentativas e um tempo máximo. Ao atingir o limite, encaminhe o caso com o contexto disponível. Um atendimento preso em tentativas automáticas continua sendo um atendimento parado.

Prepare a operação para desligar a sugestão

Mantenha um caminho para o atendente trabalhar quando o modelo estiver indisponível. Registre a versão do prompt e do modelo usada em cada avaliação, sem guardar dados pessoais desnecessários. Antes de uma troca, execute novamente os casos separados para avaliação.

O primeiro resultado útil pode ser modesto. Uma sugestão que evita procurar a fila certa já merece ser medida. Só amplie a autonomia quando os registros mostrarem qual etapa seguinte vale automatizar.