Agente de IA humanizado: quanto mais simpático, mais perigoso

Tem uma armadilha no centro da estratégia de IA conversacional que ninguém na sala de boardroom quer nomear em voz alta. A pressão do negócio empurra o agente de IA para ser cada vez mais natural, mais empático, mais parecido com um ser humano. Enquanto isso, a pesquisa do F5 Labs publicada neste mês mostra que exatamente essa humanização é o vetor que aumenta a exposição a ataques de engenharia social, a técnica em que o atacante manipula o interlocutor para que ele mesmo quebre as regras de segurança.

E o dado de contexto que torna tudo mais tenso: o Zendesk CX Trends 2026 aponta que 87% dos consumidores preferem experiências de IA personalizadas. Personalização, nesse contexto, significa agentes com tom de voz, memória de contexto e respostas adaptadas ao estado emocional do usuário. Ou seja: as duas pressões estão em rota de colisão direta.

Na UNODATA, acompanhamos clientes que já operam ou estão prestes a operar com agentes em canais críticos, desde atendimento financeiro até suporte técnico de infraestrutura. Quando li o relatório da F5, não consegui ignorar. Esse é exatamente o tipo de risco que aparece tarde demais na conversa de produto, sempre depois do go-live.

Minha aposta aqui é direta: a maioria das empresas que vão implantar agentes de IA em 2025 e 2026 não tem esse risco no radar de segurança. E vai pagar caro por isso.

O que a F5 descobriu e por que importa para quem decide

O estudo do F5 Labs testou agentes de IA configurados com diferentes níveis de persona humanizada, desde um bot funcional e seco até versões com nome próprio, histórico de conversas e linguagem afetiva. O resultado foi consistente: quanto mais o agente foi treinado para ser empático e adaptável, mais ele era suscetível a ceder a pedidos que violavam as políticas internas configuradas para ele.

O mecanismo é o mesmo da engenharia social clássica aplicada a humanos. Você cria rapport, estabelece urgência emocional, constrói uma narrativa de exceção, e o interlocutor abre uma porta que deveria estar fechada. Com agentes humanizados, a diferença é que o atacante pode fazer isso em escala, de forma automatizada, testando dezenas de variações do mesmo ataque em paralelo até encontrar a formulação que funciona.

Humanizar um agente de IA sem blindar seu comportamento contra manipulação é como contratar um atendente gentil e não treiná-lo para dizer não.

O que a F5 chama de “quebra de política” pode parecer abstrato, mas na prática significa coisas concretas: o agente revela informações que não deveria, executa uma ação fora do escopo autorizado, ou contorna uma verificação de identidade porque a narrativa do usuário pareceu convincente o suficiente. Em ambientes financeiros, de saúde ou de infraestrutura crítica, cada um desses cenários tem consequência real e mensurável.

A persona como superfície de ataque

Há um detalhe técnico no relatório que merece atenção separada. Agentes com persona forte tendem a ter system prompts mais elaborados, com mais instruções de comportamento, mais exemplos de tom e mais contexto de como tratar o usuário. Cada linha adicional no system prompt é uma superfície que pode ser explorada via prompt injection, a técnica em que o atacante insere instruções no input do usuário tentando sobrescrever o comportamento original do agente.

Isso não é especulação teórica. CVEs (Common Vulnerabilities and Exposures, o sistema de catalogação de vulnerabilidades de segurança) relacionados a prompt injection já existem e o número vai crescer à medida que mais agentes entram em produção com acesso a sistemas reais.

O dilema que o produto e a segurança precisam resolver juntos

O problema que eu vejo na prática é que as decisões sobre persona e tom do agente são tomadas pelo time de produto ou de CX, e as decisões sobre controles de segurança são tomadas pelo time de segurança da informação. Os dois times raramente estão na mesma sala quando o agente está sendo desenhado.

O resultado é previsível. O time de produto entrega um agente excelente do ponto de vista de experiência do usuário. O time de segurança herda um sistema já configurado e tenta adicionar camadas de proteção em cima de uma arquitetura que não foi pensada para recebê-las. Isso é tarde demais.

Os pontos de tensão que eu identifico nesse processo são os seguintes:

1. Definição de persona acontece antes da modelagem de ameaças. O nome, o tom e o nível de empatia do agente são decididos no início do projeto, mas a análise de como esses atributos podem ser explorados raramente acontece antes do desenvolvimento.
2. Os testes de segurança não cobrem engenharia social. A maioria dos testes de penetração em agentes de IA foca em injeção técnica e exposição de dados. Poucos testam sistematicamente o comportamento do agente diante de narrativas manipuladoras.
3. O guardrail padrão não é suficiente. As plataformas de agentes entregam filtros de conteúdo e limites de escopo, mas esses controles foram pensados para bloquear linguagem ofensiva ou respostas fora do tema, não para detectar manipulação contextual sofisticada.
4. A memória de contexto amplia o risco. Agentes com memória persistente de sessão acumulam informações que um atacante paciente pode usar para construir uma narrativa progressiva ao longo de múltiplas interações.
5. Não existe revisão humana escalável para isso. Em volume, você não consegue ter um humano revisando cada conversa. O controle precisa estar no próprio agente, o que exige design intencional desde o início.

Esse não é um problema que se resolve com uma ferramenta. É um problema de processo e de governança.

O que eu faria se fosse colocar um agente em produção hoje

Não estou dizendo que empresa nenhuma deve usar agentes humanizados. Seria uma conclusão equivocada e inútil. O ponto é que o nível de sofisticação do agente precisa ser proporcional ao nível de maturidade dos controles em torno dele.

Na minha visão, há três camadas que precisam ser tratadas antes do go-live:

Camada de design comportamental: O agente precisa ter limites explícitos de comportamento que não são negociáveis, independentemente do que o usuário disser. Isso significa que a instrução de não revelar determinada informação não pode ser formulada como uma preferência. Precisa ser uma restrição hard, testada adversarialmente antes de entrar em produção.

Camada de detecção de manipulação: Existem hoje modelos de classificação que conseguem identificar padrões de engenharia social em texto, como urgência artificial, apelos emocionais fora de contexto e tentativas de redefinição de papel do agente. Integrar esse tipo de classificador como uma camada de análise paralela é viável e não compromete a latência de forma significativa.

Camada de auditoria e resposta: Todo desvio de comportamento do agente precisa gerar um evento auditável. Não apenas log de conversa, mas classificação automática do tipo de desvio e gatilho para revisão humana quando a anomalia passar de um limiar definido. Sem isso, você não tem visibilidade do que está acontecendo em escala.

Nenhuma dessas camadas é tecnologia de ficção científica. O que falta é a decisão de investir nelas antes de o agente ir ao ar, e não depois do primeiro incidente.

Governança de agente não é projeto de TI, é decisão de CEO

Essa é a parte que eu preciso dizer com todas as letras porque é onde o problema de fato acontece. Governança de agente de IA é frequentemente tratada como um projeto técnico delegado para o time de segurança ou para o time de engenharia. Não é.

Quando um agente humanizado quebra uma política de segurança e isso gera um vazamento de dados ou uma fraude, quem responde perante o cliente, perante o regulador e perante a imprensa não é o engenheiro que configurou o system prompt. É o CEO. É a empresa.

A decisão de qual nível de humanização um agente vai ter, quais canais ele vai operar, quais ações ele vai poder executar de forma autônoma: essas são decisões de risco de negócio. Precisam passar pelo mesmo processo de aprovação que qualquer outra decisão de risco relevante.

O que eu vejo acontecer é o seguinte: a pressão por experiência do cliente empurra o produto para maximizar a humanização. A pressão por velocidade de entrega empurra a engenharia para não atrasar o lançamento com mais um ciclo de testes. A segurança fica com o problema no colo e sem orçamento para resolvê-lo direito. E o CEO só fica sabendo quando o problema já virou notícia.

A F5 colocou dados em cima de um risco que muita gente sabia que existia mas não queria nomear. Agora que está nomeado, a pergunta que fica é quanto tempo vai levar até que as empresas coloquem isso no processo de decisão antes do lançamento e não depois.

---

O mercado vai continuar acelerando a adoção de agentes, isso é fato. O que vai diferenciar as empresas que saem na frente das que pagam o custo do aprendizado é exatamente a capacidade de tratar segurança de agente como parte do design e não como um problema de operação. Se você está prestes a colocar um agente em produção ou está revisando um que já está rodando, vale a pena perguntar: quem no seu time fez o teste adversarial desse agente antes do go-live?

Perguntas frequentes

O que é engenharia social aplicada a agentes de IA?

Engenharia social é a técnica de manipular um interlocutor, humano ou sistema, para que ele quebre regras ou forneça informações que não deveria. Aplicada a agentes de IA, significa usar linguagem persuasiva, narrativas de urgência ou redefinição de contexto para fazer o agente ignorar as políticas de segurança configuradas para ele. O estudo da F5 Labs mostrou que agentes com persona mais humanizada são mais suscetíveis a esse tipo de ataque.

Agentes de IA menos humanizados são mais seguros?

Não necessariamente, mas a pesquisa da F5 indica que o nível de humanização aumenta a superfície de ataque por engenharia social. Um agente mais seco e funcional tem menos contexto comportamental para ser explorado. O ponto não é evitar humanização, mas garantir que o nível de sofisticação dos controles de segurança seja proporcional ao nível de humanização adotado.

O que é prompt injection e como ela afeta agentes conversacionais?

Prompt injection é a técnica em que um usuário mal-intencionado insere instruções no input da conversa tentando sobrescrever ou modificar o comportamento original do agente. Em agentes com personas elaboradas e system prompts longos, a superfície para esse tipo de ataque é maior. É uma vulnerabilidade catalogada em CVEs e já documentada em sistemas de IA em produção.

Como uma empresa pode se proteger sem abrir mão da experiência do usuário?

O caminho está em três frentes simultâneas: definir restrições de comportamento como regras hard no design do agente, integrar classificadores de detecção de manipulação como camada paralela de análise, e criar auditoria automática com gatilhos para revisão humana em casos de desvio. Essas medidas não eliminam a humanização, mas colocam limites que não podem ser contornados por narrativa, independentemente de como o usuário formule o pedido.