Agente de superinteligência no atendimento: limites e supervisão

Agente de superinteligência no atendimento: limites e supervisão

Um agente de superinteligência no atendimento, na prática de hoje, é um agente de IA cada vez mais capaz que continua precisando de limites escritos, transbordo para pessoas e auditoria contínua. A capacidade do modelo sobe a cada troca, mas a responsabilidade pelo que o agente pode fazer, dizer e decidir continua sendo da empresa. Quem trata o limite como configuração fixa e o modelo como peça substituível mantém o controle mesmo quando o agente fica mais competente.

Principais pontos

• Capacidade maior não é permissão maior: o que o agente pode fazer deve ser definido pela empresa, não herdado do modelo.
• Limites devem viver fora do prompt, em permissões de ferramentas, regras de negócio e validações que o modelo não consegue contornar.
• O transbordo para humano precisa de gatilhos objetivos, fila definida e contexto entregue, não apenas uma frase de desculpas.
• Toda troca de modelo deve passar por um conjunto fixo de testes e por um período de operação supervisionada antes de ganhar autonomia.
• Auditoria útil registra decisão, motivo, dados consultados e ação executada, com acesso restrito por causa da LGPD.

O que significa superinteligência no atendimento hoje?

O termo carrega mais expectativa do que descrição técnica. Os agentes que as empresas operam hoje são sistemas de linguagem com ferramentas, memória limitada e instruções. Eles podem ser muito bons em tarefas específicas, como entender uma reclamação confusa, consultar um pedido e redigir uma resposta clara, mas não são uma inteligência geral que dispensa regras. A diferença entre os conceitos é tratada em AGI e superinteligência: o que sua empresa realmente opera.

Para quem decide, a pergunta útil não é se o agente é superinteligente. É: se amanhã o modelo por trás dele ficar mais capaz, o que impede que ele faça algo que ninguém autorizou? Essa pergunta organiza todo o resto do artigo.

Uma separação ajuda a manter a conversa honesta. O que está na documentação oficial dos fornecedores é fato sobre o produto. O que se observa ao implementar e operar é experiência, e vale só para aquele contexto. O que se espera dos próximos modelos é hipótese, e não deve entrar no desenho de controle como se fosse garantia.

Por que a troca de modelo muda o risco do agente?

Modelos novos tendem a seguir instruções melhor, mas também mudam de comportamento de formas difíceis de prever. Um agente que antes pedia confirmação pode passar a inferir a resposta. Outro que respondia de forma curta pode passar a explicar demais e prometer algo que a política da empresa não cobre. Mais capacidade amplia o que o agente consegue fazer quando encontra uma brecha.

Há três riscos recorrentes quando o modelo evolui:

• Mudança de tom e de promessa: a resposta fica mais convincente, e por isso um erro de conteúdo fica mais difícil de notar.
• Mais iniciativa com ferramentas: o agente tenta resolver sozinho coisas que antes encaminhava, como reembolso, troca ou cancelamento.
• Falsa sensação de segurança: a equipe revisa menos porque o agente parece confiável, justamente quando a revisão deveria se manter.

Nada disso exige desconfiança do modelo. Exige que o controle esteja em camadas que não dependem do modelo se comportar bem. O guia de riscos de IA do NIST e a lista de riscos para aplicações com modelos de linguagem da OWASP, citados nas fontes, tratam exatamente dessa ideia: riscos são geridos por processo, não por confiança no componente.

Quais limites definir antes de qualquer troca de modelo?

Limite bom é aquele que continua valendo quando o modelo muda. Por isso, ele não deve depender só do texto das instruções. Instruções são importantes (veja como escrever instruções para atendimento com IA), mas o cinto de segurança fica em outro lugar.

Um conjunto mínimo de limites para atendimento:

• Escopo de assunto: sobre o que o agente responde e o que ele recusa, com resposta padrão para fora do escopo.
• Escopo de dados: quais campos do cliente ele pode ler, e quais nunca aparecem na conversa, como documentos completos ou dados de saúde.
• Escopo de ações: o que ele executa sozinho (consultar status, agendar), o que ele propõe para aprovação (desconto, exceção) e o que é proibido (reembolso, cancelamento de contrato).
• Limites de valor e de repetição: tetos que a ferramenta aplica, independentemente do que o modelo pedir.
• Linguagem de compromisso: o agente não promete prazo, resultado ou condição que não esteja em uma fonte aprovada.
• Identidade: o cliente sabe que fala com um agente de IA e pode pedir uma pessoa a qualquer momento.

O ponto técnico central é aplicar as regras nas ferramentas. Se a função de reembolso rejeita qualquer valor acima do teto, não importa o quanto o modelo esteja convencido. A orientação de autorização da OWASP, que aparece em outros contextos de software, vale aqui: quem decide se a ação é permitida é a camada de autorização, não quem solicita.

Quando o agente deve transferir para uma pessoa?

O transbordo falha quando os gatilhos são vagos. Frases como transferir se necessário deixam o modelo julgar sozinho, e esse julgamento muda a cada versão. Gatilhos objetivos são mais estáveis.

Um guia de decisão simples:

• Transferir sempre que o cliente pedir uma pessoa, na primeira vez que pedir.
• Transferir quando houver reclamação formal, ameaça de ação judicial ou menção a órgão de defesa do consumidor.
• Transferir quando a ação envolver dinheiro acima do teto, exceção de política ou dado sensível.
• Transferir quando o agente não encontrar a resposta em fonte aprovada, em vez de improvisar.
• Transferir depois de um número definido de tentativas sem resolver, medido pelo sistema e não pelo modelo.
• Transferir quando houver sinal de urgência, como segurança, saúde ou perda financeira em andamento.

Transferir bem também importa. A pessoa que assume deve receber resumo do caso, o que já foi tentado e o motivo do transbordo, para o cliente não repetir a história. Fora do horário comercial, o agente deve dizer quando haverá retorno e registrar o caso na fila certa. Se o canal for WhatsApp, vale conhecer as regras de janela de conversa da API, porque elas afetam como e quando a equipe pode responder depois.

Existe ainda um ponto legal. Quando uma decisão automatizada afeta o titular, a LGPD prevê o direito de pedir revisão. O artigo sobre decisões automatizadas e o art. 20 da LGPD detalha o que isso pede do desenho do atendimento, e o transbordo é um dos caminhos práticos para cumpri-lo.

O que registrar para auditar o agente?

Auditoria não é guardar tudo. É guardar o suficiente para reconstruir uma decisão sem expor mais dados do que o necessário. Os conceitos de observabilidade (logs, métricas e rastros) servem de base, e há convenções abertas para sistemas de IA generativa, como as do OpenTelemetry.

Para cada atendimento, o registro útil contém:

• Versão do modelo e das instruções em uso naquele momento.
• Fontes consultadas (artigo da base, status de pedido) e o que foi devolvido.
• Ferramentas chamadas, com parâmetros e resultado, inclusive as recusadas pela camada de autorização.
• Motivo de cada transbordo e tempo até uma pessoa assumir.
• Avaliação posterior por amostragem, feita por uma pessoa, com o veredito e a causa do erro.

A versão do modelo no registro é o item mais esquecido e o mais valioso. Sem ela, não dá para responder se um problema começou depois da troca. Já os dados pessoais nos registros pedem base legal, prazo de retenção e acesso restrito. Se o fornecedor processa dados fora do Brasil, vale ler também sobre transferência internacional de dados com IA, e a página da ANPD é a referência oficial para orientações.

Cenário ilustrativo: um modelo melhor, uma exceção que ninguém autorizou

Imagine uma loja de móveis com um agente no WhatsApp que informa prazo de entrega e abre chamados de troca. Com o modelo anterior, quando o cliente reclamava de um defeito, o agente abria o chamado e encaminhava. Depois da troca para um modelo mais capaz, ele passa a perceber que o cliente está frustrado e, querendo ajudar, sugere um desconto na próxima compra como compensação.

Nenhuma regra proibia isso de forma técnica, apenas a instrução em texto dizia para não oferecer compensações. Como o modelo novo pesou o contexto de outro jeito, a frase foi ignorada em um caso de borda. O desconto não existe como ferramenta, então nada foi concedido, mas o cliente guardou a mensagem e a loja precisou lidar com uma expectativa criada pelo agente.

O que teria evitado: um teste fixo com reclamações de cliente irritado, rodado antes da troca; uma checagem de saída que bloqueia linguagem de compensação; e uma amostra de conversas lida por uma pessoa na primeira semana. Este é um exemplo inventado para ilustrar o mecanismo, não um caso real.

Como trocar de modelo sem perder o controle?

A troca deve ser tratada como uma mudança de sistema, com etapas. Um plano em passos:

• Congelar a linha de base: salvar o conjunto de conversas de teste, as métricas atuais e a versão em produção.
• Rodar os testes fixos no modelo novo, incluindo casos de recusa, transbordo, dado sensível e tentativa de manipulação. Para testar sem tocar em sistemas reais, use ambientes simulados, como no artigo sobre testes de agentes com mocks e sandbox.
• Comparar respostas lado a lado com uma pessoa revisando as diferenças, não apenas a nota automática.
• Liberar em modo sombra ou com pouco volume, com transbordo mais sensível do que o normal.
• Ampliar a autonomia só depois de um período de revisão por amostragem sem achados relevantes.
• Manter a volta ao modelo anterior pronta, com a versão registrada.
• Registrar a decisão: expandir, ajustar ou parar, com quem aprovou.

Os guias da Anthropic sobre avaliação de agentes e sobre construção de agentes eficazes, listados nas fontes, reforçam a mesma lógica: avaliações recorrentes e fluxos simples e observáveis antes de autonomia maior. A OpenAI também mantém documentação sobre avaliações, útil como segunda referência.

Como esse trabalho se organiza na prática?

O método que usamos tem quatro movimentos: mapear, limitar, pilotar e transferir. Mapear é descrever o processo atual de atendimento e medir uma linha de base. Limitar é decidir dados, ações e gatilhos de transbordo antes de escolher o modelo. Pilotar é rodar um único fluxo real, com registros e uma métrica de sucesso combinada. Transferir é entregar o fluxo para a equipe, com a decisão explícita de expandir, ajustar ou parar. A troca de modelo entra como um novo ciclo curto desse mesmo processo, e não como um evento isolado. Para decidir o que automatizar e o que manter com pessoas, o artigo sobre SAC com inteligência artificial ajuda a começar.

Perguntas frequentes

Um agente mais inteligente precisa de menos supervisão? Não. Mais capacidade reduz alguns erros e cria outros, geralmente menos óbvios e mais convincentes. A supervisão pode mudar de forma, com mais amostragem e menos revisão de tudo, mas só depois de evidência registrada do comportamento do novo modelo.

Onde devem ficar os limites: no prompt ou no sistema? Nos dois, com pesos diferentes. O prompt orienta o tom e o escopo, mas os limites que importam, como valores, permissões e dados acessíveis, devem ser aplicados pelas ferramentas e pela camada de autorização, porque elas não mudam quando o modelo muda.

Com que frequência revisar as conversas do agente? Defina uma rotina fixa de amostragem, mais intensa logo após qualquer troca de modelo ou de instruções, e depois estável. A frequência exata depende do volume e do risco do fluxo, e deve ser decidida com a equipe de atendimento e registrada junto às métricas.

O transbordo para humano deixa o atendimento mais lento? Pode deixar, se a fila e o horário da equipe não estiverem definidos. Por isso, o transbordo precisa de gatilhos objetivos, resumo do caso e expectativa clara de retorno. Bem desenhado, ele reserva a atenção das pessoas para os casos em que elas realmente fazem diferença.

Fontes

• NIST: AI Risk Management Framework
• OWASP: Top 10 for LLM Applications
• Anthropic: Demystifying evals for AI agents
• Anthropic: Building effective agents