Agentes de IA humanizados: quanto mais simpático, mais perigoso

Quando a nossa equipe na UNODATA começou a avaliar agentes de IA para automação de atendimento, a primeira pergunta dos clientes sempre era a mesma: “Dá pra deixar mais humano?” Entonação, nome próprio, respostas que parecem conversa de gente. Faz sentido do ponto de vista de experiência do usuário. O Zendesk CX Trends 2026 confirma o que todo mundo já percebia na prática: 87% dos consumidores preferem interações de IA que pareçam personalizadas. O problema é que acabamos de receber uma resposta incômoda para essa equação.

Um estudo publicado pelo F5 Labs, um dos laboratórios de pesquisa de segurança mais respeitados da área de aplicações e APIs, mostrou que quanto mais humanizado é o agente de IA, maior a sua superfície de ataque contra engenharia social. Engenharia social, pra quem não é da área técnica, é a arte de manipular pessoas ou sistemas para que eles quebrem regras de segurança sem perceber. É o golpe do “sou do suporte, preciso da sua senha”, só que agora direcionado a uma IA.

Eu precisei parar um momento quando li isso. Porque não é uma vulnerabilidade de código. Não é um CVE (Common Vulnerabilities and Exposures, o sistema global de catalogação de falhas de segurança). É uma vulnerabilidade de comportamento. E comportamento é muito mais difícil de corrigir com um patch.

Minha aposta aqui é direta: empresas que estão adotando agentes de IA sem uma camada de governança comportamental vão pagar um preço caro nos próximos 18 meses. E o custo não vai aparecer no relatório de TI. Vai aparecer no relatório jurídico.

O que o estudo da F5 Labs realmente mostrou

O achado central do F5 Labs é o seguinte: agentes de IA treinados para simular empatia, adaptar tom e construir rapport com o usuário desenvolvem uma espécie de “deferência social”. Eles são otimizados para concordar, para suavizar negativas, para manter a conversa fluindo. E isso cria uma janela de exploração.

Um atacante treinado em engenharia social sabe exatamente como usar pressão emocional, urgência fabricada e autoridade simulada para forçar um humano a tomar uma decisão fora do protocolo. Com um agente humanizado, o mesmo conjunto de técnicas funciona. O agente “quer” ser prestativo. Ele foi calibrado para isso. E quando alguém usa o tom certo, a narrativa certa e a sequência certa de perguntas, o agente começa a contornar as políticas internas para “ajudar”.

Isso não é teoria. O relatório cita testes em que agentes humanizados foram levados a revelar informações que não deveriam, autorizar ações fora do escopo e até contornar controles de verificação de identidade. Tudo isso sem explorar nenhuma falha no código. Só conversando.

Quanto mais o agente imita um ser humano prestativo, mais ele replica as vulnerabilidades de um ser humano prestativo.

E aqui está o paradoxo central que todo CEO precisa entender: você não pode resolver esse problema apenas com segurança técnica. Um firewall não bloqueia uma conversa bem articulada.

Por que isso é um problema estratégico, não só técnico

A maioria das discussões sobre segurança em IA ainda vive no departamento de TI. Arquitetura segura, criptografia, controle de acesso, auditoria de logs. Tudo isso é necessário. Mas o vetor de ataque que o F5 Labs está descrevendo não passa por nenhuma dessas camadas.

Pense no fluxo de um ataque de engenharia social bem-sucedido contra um agente de IA de suporte ao cliente:

1. O atacante inicia uma conversa comum para calibrar o tom e o comportamento do agente.
2. Ele introduz um contexto emocional: urgência, medo de perda, identidade de autoridade.
3. O agente, treinado para empatia, começa a flexibilizar respostas para atender ao estado emocional declarado.
4. O atacante conduz o agente a confirmar dados, liberar acessos ou fornecer informações que deveriam ser restritas.
5. Toda a interação parece uma conversa normal nos logs, porque tecnicamente foi.

Não há anomalia de rede. Não há tentativa de injeção de código. Há só uma conversa que foi longe demais.

Do ponto de vista estratégico, isso significa que o risco de adotar agentes de IA não está só na camada de infraestrutura. Está na camada de produto e na camada de governança. Quem define os limites comportamentais do agente? Quem revisa esses limites quando o agente é atualizado? Quem monitora conversas que fogem dos padrões sem ser uma anomalia técnica?

Na UNODATA, quando estruturamos a adoção de IA para clientes do setor financeiro e de saúde, a primeira pergunta que eu coloco não é “qual modelo vamos usar”. É “quem assina embaixo do comportamento desse agente”. Porque no dia que algo der errado, vai ter que ter uma pessoa responsável. E isso precisa estar definido antes, não depois.

O que separa uma adoção responsável de uma adoção ingênua

Não estou dizendo que agentes de IA humanizados são inerentemente ruins. Estou dizendo que humanização sem governança é um risco mal precificado. Existe uma diferença enorme entre as duas abordagens.

Governança comportamental é diferente de governança técnica

Governança técnica cobre: quem tem acesso ao sistema, como os dados são criptografados, quais APIs o agente pode chamar. Governança comportamental cobre: como o agente responde a pressão emocional, quais tópicos ele recusa independentemente do contexto, como ele escalona para humanos quando detecta padrões de manipulação.

As empresas que estão fazendo isso bem têm as seguintes práticas em comum:

• Definem um conjunto fixo de políticas que o agente não pode quebrar, mesmo que o usuário apresente justificativas plausíveis.
• Treinam os agentes com cenários de engenharia social para que eles reconheçam padrões de manipulação e escalem para revisão humana.
• Revisam periodicamente as conversas que fugiram do padrão esperado, mesmo as que não geraram incidentes formais.
• Separam claramente o que o agente pode fazer de forma autônoma do que exige confirmação humana, especialmente em ações com consequências financeiras ou de acesso.
• Documentam e versionam as mudanças de comportamento do agente da mesma forma que documentam mudanças de código, com responsável, data e justificativa.

O custo de não fazer isso

Um incidente de engenharia social bem-sucedido contra um agente de IA é muito mais difícil de conter do que uma invasão técnica convencional. Porque a narrativa pública é devastadora. “A empresa foi hackeada” já é ruim. “O chatbot da empresa foi manipulado por uma conversa simples” é pior, porque implica negligência no design.

Nos setores regulados, o risco é ainda maior. Em saúde e financeiro, um agente que foi induzido a revelar dados de terceiros ou a autorizar operações fora do escopo pode gerar obrigações de notificação sob a LGPD e processos de responsabilidade civil. O custo de um incidente assim não é só operacional. É reputacional e jurídico ao mesmo tempo.

O que eu faria se estivesse avaliando um agente de IA agora

Se você está no processo de avaliar ou já implementou um agente de IA com interface conversacional, aqui estão as perguntas que eu faria antes de qualquer outra decisão de produto ou infraestrutura.

Primeiro: o seu fornecedor tem documentação específica sobre como o modelo se comporta diante de técnicas conhecidas de engenharia social? Se a resposta for não, ou se a resposta vier cheia de generalidades sobre “segurança por design”, isso é um sinal de alerta.

Segundo: você tem visibilidade sobre as conversas que o agente está tendo, não só sobre os tickets que ele abriu ou fechou? Log de atendimento resolvido não é o mesmo que auditoria comportamental.

Terceiro: existe um processo formal de revisão das políticas comportamentais do agente quando você faz atualizações no modelo ou na base de conhecimento? Uma atualização de tom ou de persona pode inadvertidamente relaxar um controle que estava funcionando.

Essas perguntas não são técnicas no sentido tradicional. São perguntas de gestão de risco. E é exatamente por isso que precisam ser feitas pelo CEO, pelo CISO e pelo jurídico juntos, não só pela equipe de tecnologia.

O mercado de agentes de IA está crescendo rápido demais para que a segurança fique correndo atrás. A pressão comercial para humanizar, para escalar, para lançar antes do concorrente é real. Mas o relatório do F5 Labs é um lembrete preciso de que superfície de ataque não espera roadmap de produto.

Perguntas frequentes

O que é engenharia social aplicada a agentes de IA?

Engenharia social é a manipulação psicológica de pessoas ou sistemas para que eles tomem ações fora das regras de segurança estabelecidas. No contexto de agentes de IA, um atacante usa pressão emocional, urgência fabricada ou falsa autoridade em uma conversa para induzir o agente a revelar informações restritas ou executar ações que não deveria. Não envolve exploração de falhas de código, o que torna esse vetor mais difícil de detectar por ferramentas técnicas convencionais.

Por que agentes mais humanizados são mais vulneráveis?

Agentes humanizados são calibrados para empatia, adaptação de tom e manutenção de uma conversa fluida. Isso significa que eles têm uma tendência treinada a ser prestativos e a evitar respostas que pareçam frias ou inadequadas ao contexto emocional do usuário. Um atacante que conhece técnicas de engenharia social pode explorar exatamente essa tendência para conduzir o agente além dos seus limites de política, usando a mesma abordagem que usaria com um atendente humano vulnerável.

Como uma empresa pode mitigar esse risco sem abrir mão da experiência humanizada?

A mitigação passa por governança comportamental, não só técnica. Isso inclui definir políticas fixas que o agente não pode quebrar independentemente do contexto da conversa, treinar o modelo com cenários de manipulação para que ele reconheça e escale tentativas suspeitas, e revisar periodicamente as conversas que fugiram dos padrões esperados. A humanização pode coexistir com segurança desde que os limites comportamentais sejam explícitos, documentados e auditados regularmente.

Quem na empresa deve ser responsável pela segurança comportamental de um agente de IA?

Essa responsabilidade não pode ser apenas do time de TI. A segurança comportamental de um agente envolve decisões de produto, risco jurídico e conformidade regulatória. Na prática, o modelo mais robusto é uma governança compartilhada entre o CISO, o responsável pelo produto e o jurídico, com revisões periódicas formais. Quando algo der errado, vai ser necessário apontar quem aprovou o comportamento do agente em determinado momento. Essa definição precisa existir antes do incidente, não depois.