Quando o agente de IA parece humano demais, a segurança vai embora

Teve um momento, no ano passado, em que eu estava avaliando uma plataforma de atendimento com agente de IA para um cliente da UNODATA. A demo era impressionante: o agente respondia com empatia, ajustava o tom conforme o humor do usuário, usava o primeiro nome da pessoa, fazia pequenas pausas antes de responder como se estivesse “pensando”. Todo mundo na sala ficou encantado. Eu fiquei com uma pulga atrás da orelha.

A pulga tinha nome agora. O F5 Labs publicou um estudo mostrando que agentes de IA quanto mais humanizados, mais vulneráveis a ataques de engenharia social (social engineering, isto é, manipulação psicológica para extrair informações ou forçar comportamentos fora das políticas de segurança). Ao mesmo tempo, o Zendesk CX Trends 2026 aponta que 87% dos consumidores preferem experiências de IA personalizadas. É uma contradição embutida no produto que você está comprando.

O problema não é a tecnologia em si. É que a maioria das decisões de adoção de agentes de IA em ambientes B2B não inclui essa camada de análise. A gerente de TI fica sabendo do risco depois que o contrato está assinado, o deploy feito e o agente respondendo a clientes. Este artigo é sobre o que mudar antes disso.

O que a pesquisa da F5 diz na prática

A F5 Labs testou agentes de IA com diferentes graus de personalização e humanização. O resultado que importa para quem toma decisão de TI é direto: quanto mais o agente simula traços humanos (nome próprio, memória afetiva de conversas anteriores, linguagem emocional, hesitação simulada), maior a taxa de sucesso de ataques de engenharia social contra ele.

Engenharia social contra humanos funciona porque explora confiança, urgência, medo e reciprocidade. Um agente humanizado está, por design, programado para responder a esses mesmos gatilhos porque eles fazem parte do que torna a experiência “natural”. O atacante não precisa hackear a infraestrutura. Basta conversar com o agente da forma certa para que ele quebre uma política, forneça um dado que não deveria ou execute uma ação fora do escopo.

Isso tem um nome técnico no setor de segurança: prompt injection (injeção de instrução maliciosa via texto para manipular o comportamento do modelo). Mas aqui o vetor não é código malicioso escondido em documento. É linguagem comum, tom emocional, contexto fabricado. Qualquer pessoa com intenção pode tentar.

Quanto mais o agente parece humano, mais ele responde aos mesmos gatilhos que tornam humanos vulneráveis a manipulação.

O que isso significa para o ambiente corporativo

Em B2B, os agentes de IA não estão só no atendimento ao consumidor final. Eles aparecem em portais de fornecedores, sistemas internos de helpdesk, interfaces de RH, fluxos de aprovação de compras. Em cada um desses pontos há dados sensíveis, políticas de acesso e autorização de ações.

Um agente de helpdesk interno que foi configurado para ser “empático e prestativo” pode ser persuadido a resetar credenciais sem seguir o fluxo correto de verificação. Um agente de atendimento de fornecedor pode ser convencido de que há urgência num pedido que deveria passar por aprovação humana. O nível de sofisticação necessário para o atacante é baixo. O nível de dano potencial é alto.

Por que essa contradição chega para a gerente de TI depois do contrato

Tenho visto isso acontecer por uma razão estrutural: a decisão de comprar um agente de IA costuma ser conduzida por três critérios que raramente incluem segurança comportamental.

1. Qualidade da experiência do usuário (UX, naturalidade, satisfação em demo).
2. Integração técnica com sistemas existentes (API, compatibilidade, tempo de deploy).
3. Custo e modelo de licenciamento.

Segurança entra como checklist depois: LGPD, criptografia em trânsito, autenticação. Nenhum desses itens captura o risco comportamental do agente. A pergunta “como esse agente responde a tentativas de manipulação linguística?” não está no RFP (Request for Proposal, documento de solicitação de proposta usado em processos de compra de TI).

E tem uma dinâmica de gênero aqui que vale nomear. Gerentes de TI mulheres frequentemente relatam que já carregam o ônus extra de provar que a análise técnica foi rigorosa o suficiente. Quando você levanta uma objeção de segurança que não está no checklist padrão, o ambiente pode tratar isso como excesso de cautela em vez de diligência. A pressão para fechar a adoção rápido, mostrar resultado de inovação, não “atrasar” o projeto, é real. E ela faz com que análises legítimas de risco sejam descartadas antes de chegar à mesa de decisão.

O que avaliar antes de adotar (ou antes de expandir o escopo)

Não estou dizendo para não adotar agentes de IA. Estou dizendo para incluir perguntas que os vendedores não vão trazer espontaneamente. Algumas que uso na UNODATA quando avaliamos essas plataformas:

• O agente tem limites explícitos de escopo codificados no sistema, não só nas instruções de prompt? Instrução de prompt pode ser sobrescrita por manipulação. Limite de escopo em nível de sistema é mais robusto.
• Existe registro (log) auditável de todas as interações do agente, incluindo tentativas de desvio de política?
• Como o agente responde quando detecta contradição entre o que o usuário pede e a política configurada? Ele recusa, escala para humano ou tenta “resolver” de forma criativa?
• Há revisão periódica do comportamento do agente em produção, com alguém responsável por esse monitoramento?
• O grau de humanização é configurável? É possível reduzir traços de personalidade em contextos de maior sensibilidade sem perder a usabilidade?
• O fornecedor tem documentação sobre testes adversariais (adversarial testing, testes em que o agente é atacado intencionalmente para mapear vulnerabilidades) realizados antes do lançamento?

Essas perguntas não exigem que você seja especialista em segurança de modelos de linguagem. Elas exigem que você saiba que o risco existe e que coloque o ônus da resposta no fornecedor.

Como apresentar esse risco internamente sem parecer obstáculo

Este é o ponto que a maioria dos artigos técnicos ignora. Saber do risco é metade do problema. A outra metade é conseguir que ele seja levado a sério numa organização onde a pressão é pelo “sim rápido”.

O que funciona, na minha experiência, é conectar o risco a um custo concreto antes de apresentar a objeção. Não “esse agente pode ser manipulado” (abstrato, fácil de descartar). Em vez disso: “se um fornecedor convencer o agente a aprovar um pedido fora do fluxo normal, o custo de auditoria retroativa e eventual contestação é X. O custo de incluir esse critério no processo de avaliação agora é zero.”

Você não está pedindo para pausar o projeto. Está pedindo para adicionar três perguntas ao processo de RFP que já existe. Isso é facilmente aprovável.

Além disso, documentar a análise por escrito, mesmo que brevemente, cumpre duas funções. Protege você se o risco se materializar depois. E cria precedente para que análises de segurança comportamental entrem no processo padrão de avaliação de fornecedores de IA da empresa.

Fecho

A tensão entre experiência do usuário e segurança não vai desaparecer. Quanto mais os agentes de IA evoluírem para parecer humanos, mais sofisticada vai precisar ser a camada de proteção. A boa notícia é que a gerente de TI que entende esse trade-off hoje está numa posição muito melhor do que a que vai descobrir isso depois de um incidente.

A pergunta que fica: no seu processo atual de avaliação de fornecedores de IA, existe espaço formal para testar comportamento adversarial antes de assinar?

Perguntas frequentes

Por que agentes de IA mais humanizados são mais vulneráveis a engenharia social?

Porque humanização significa responder a gatilhos emocionais e contextuais, como urgência, empatia e reciprocidade. Esses mesmos gatilhos são os que ataques de engenharia social exploram. O agente não distingue contexto legítimo de contexto fabricado com intenção maliciosa quando os dois usam a mesma linguagem.

O que é prompt injection e como afeta agentes de IA corporativos?

Prompt injection é a técnica de inserir instruções maliciosas em linguagem comum para fazer o modelo agir fora das suas políticas. Em contexto corporativo, um usuário mal-intencionado pode conversar com o agente de helpdesk ou atendimento de forma a fazê-lo executar ações que deveriam exigir aprovação humana, como resetar credenciais ou liberar acessos.

Quais perguntas devo incluir no RFP ao contratar uma plataforma de agente de IA?

Pergunte se o agente passa por testes adversariais antes do lançamento, se os limites de escopo são configurados em nível de sistema (não só em prompt), se há logs auditáveis de todas as interações e como o agente é monitorado em produção. Essas perguntas colocam o ônus da transparência no fornecedor.

Como apresentar risco de segurança de agentes de IA para liderança sem parecer obstáculo ao projeto?

Conecte o risco a custo concreto antes de apresentar a objeção. Mostre o custo de um incidente (auditoria, contestação, reputação) comparado ao custo de incluir critérios de segurança comportamental no processo de avaliação, que é próximo de zero. Proponha adição de critérios ao RFP existente, não pausa no projeto.