Existe uma ideia confortável sobre segurança em inteligência artificial: se as informações recebidas pelo sistema forem verdadeiras, a decisão produzida por ele estará pelo menos construída sobre uma base confiável. Um novo trabalho mostra por que essa intuição é insuficiente. Um agente pode receber apenas frases corretas, interpretar o pedido de maneira aparentemente razoável e ainda assim executar uma ação proibida porque uma informação decisiva não apareceu na resposta de uma ferramenta.
O problema parece semântico, mas é operacional. Um sistema que consulta um banco de dados, uma agenda, um prontuário, um sistema financeiro ou uma API de permissões não precisa encontrar uma falsidade para falhar. Basta não perceber que a resposta está incompleta. Quando o agente transforma silêncio em autorização, a ausência de evidência passa a funcionar como uma evidência falsa.
O perigo escondido entre o pedido e a resposta
Imagine um agente encarregado de organizar o acesso a um sistema corporativo. Um funcionário pede que ele compartilhe um arquivo com uma pessoa externa. A ferramenta consultada informa corretamente que o destinatário existe e que o arquivo está disponível. Entretanto, a resposta não menciona que o documento contém dados pessoais protegidos por uma regra adicional. Se o agente interpretar a ausência dessa informação como ausência da restrição, poderá concluir que o compartilhamento é permitido.
Nenhuma etapa precisa conter uma mentira explícita. O funcionário pode ter feito um pedido legítimo. O diretório pode ter retornado um registro verdadeiro. O arquivo pode realmente existir. O erro surge porque o sistema não perguntou o que deveria perguntar, não identificou a lacuna e não interrompeu a execução.
Esse tipo de falha é especialmente relevante para agentes que usam ferramentas. Um modelo de linguagem tradicional pode produzir uma resposta equivocada, mas um agente conectado a sistemas externos pode alterar permissões, cancelar serviços, liberar pagamentos, movimentar dados ou tomar decisões sobre pessoas. A diferença entre responder e agir transforma uma falha de interpretação em uma falha de governança.
O que o EpiSEM-Bench tenta medir
O estudo EpiSEM-Bench: Evaluating Safety and Evidence Recovery in LLM Agents under Missing Evidence propõe um benchmark voltado justamente para esse cenário. A avaliação reúne trezentos pares de tarefas seguras e inseguras distribuídas por seis domínios. Em cada par, o pedido pode parecer semelhante, mas uma informação relevante é suprimida da resposta disponível ao agente.
A pergunta central não é apenas se o sistema sabe classificar uma tarefa como permitida ou proibida quando recebe todos os fatos. O teste pergunta se ele consegue perceber que falta algo, buscar a informação ausente e, caso a dúvida permaneça, recusar a ação proibida. Essa diferença é importante porque muitos protocolos de segurança avaliam o resultado em um ambiente com evidência completa. Na prática, ferramentas falham, registros são parciais, permissões não são exibidas, sensores ficam indisponíveis e respostas podem ser truncadas.
O benchmark mede pelo menos três comportamentos. O primeiro é a execução insegura diante da omissão de um fato crítico. O segundo é a capacidade de respeitar limites de segurança quando a evidência está incompleta. O terceiro é a recuperação de evidências: o agente procura deliberadamente a informação que falta antes de agir?
Há também uma preocupação metodológica importante. O trabalho procura identificar o menor número de fatos omitidos capaz de produzir uma falha, além de verificar se o sistema já falha mesmo quando toda a evidência está disponível. Isso separa dois problemas diferentes: a incapacidade de raciocinar sobre regras e a incapacidade de reconhecer que o próprio contexto é insuficiente.
Verdade local não garante decisão segura
O resultado mais inquietante desse tipo de avaliação é que a veracidade de cada frase não garante a segurança da decisão. Um agente pode construir um raciocínio impecável a partir de um conjunto incompleto de fatos e chegar a uma conclusão perigosa. É uma forma de erro que sistemas de verificação textual tendem a deixar passar, porque não existe uma afirmação obviamente falsa para ser corrigida.
Isso desafia uma prática comum no desenvolvimento de agentes: fornecer uma ferramenta e instruir o modelo a confiar na resposta. A confiança deveria ser condicional. Uma resposta só pode sustentar uma ação se também houver motivos para acreditar que ela contém os campos necessários para aquela decisão.
Em outras palavras, segurança não depende apenas de perguntar “o que esta ferramenta respondeu?”. Também é necessário perguntar “o que esta ferramenta deveria ter respondido para que a decisão fosse válida?”. Essa segunda pergunta exige contratos de dados, esquemas explícitos, indicadores de completude e regras que definam quando uma resposta é inconclusiva.
Uma API que retorna apenas “usuário encontrado” não deveria ser tratada como uma autorização de compartilhamento. Um prontuário sem o histórico necessário não deveria ser interpretado como um histórico sem ocorrências. Um sistema de compras que não informa a alçada de aprovação não deveria ser entendido como um sistema sem alçada. O silêncio precisa ter um significado controlado, e não um significado inventado pelo agente.
O impacto para empresas brasileiras
No Brasil, esse problema aparece em praticamente todos os setores que estão experimentando automação. Bancos e fintechs usam modelos para triagem, prevenção a fraudes e atendimento. Operadoras analisam pedidos e documentos. Empresas de varejo automatizam concessão de descontos, suporte e logística. Hospitais e clínicas começam a explorar agentes para organizar informações. Órgãos públicos lidam com processos em que uma única restrição ausente pode alterar o tratamento de um cidadão.
A Lei Geral de Proteção de Dados não transforma toda decisão automatizada em um caso proibido, mas aumenta a responsabilidade sobre finalidade, segurança, necessidade e prestação de contas. Se um agente compartilha um documento porque uma ferramenta não retornou um marcador de sensibilidade, a organização terá dificuldade para explicar por que considerou aquela resposta suficiente.
O problema também é econômico. Uma automação que encaminha corretamente a maioria dos casos pode parecer eficiente até produzir um incidente caro. O custo de uma rota errada, uma transferência indevida ou uma autorização irregular frequentemente supera o custo de encaminhar o caso duvidoso para um especialista. Por isso, a métrica relevante não é apenas quantas tarefas o agente conclui sozinho, mas quantas decisões perigosas ele evita quando não sabe o bastante.
Para empresas brasileiras, uma arquitetura mais madura deveria incluir respostas com estado explícito: autorizado, negado, inconclusivo ou indisponível. As ferramentas deveriam informar quais verificações foram realizadas e quais não puderam ser realizadas. O agente deveria ser treinado e avaliado para fazer perguntas adicionais, não apenas para produzir uma resposta fluente.
Como transformar a ausência em um sinal de segurança
A primeira medida é separar desconhecimento de negação. “Não encontrei uma restrição” não significa “não existe restrição”. Essa distinção precisa aparecer tanto nas instruções do agente quanto no desenho das ferramentas.
A segunda é criar checkpoints de recuperação. Antes de uma ação sensível, o sistema pode verificar se possui todos os campos obrigatórios, consultar uma fonte independente ou solicitar confirmação humana. A verificação não deve ser acionada somente quando o modelo demonstra baixa confiança linguística. Um agente pode escrever uma justificativa convincente e ainda assim estar operando sobre um contexto incompleto.
A terceira é medir o custo da omissão. Nem toda informação ausente tem a mesma gravidade. A falta de uma preferência estética é diferente da falta de um bloqueio jurídico, de uma contraindicação médica ou de uma restrição financeira. Políticas de risco devem definir quais lacunas exigem paralisação imediata.
A quarta é testar combinações realistas. Avaliações precisam incluir respostas truncadas, campos vazios, sistemas fora do ar, permissões parcialmente visíveis e conflitos entre fontes. Um agente seguro não é aquele que funciona apenas quando todas as ferramentas cooperam, mas aquele que muda de comportamento quando a cooperação falha.
O futuro dos agentes dependerá da humildade operacional
A indústria costuma apresentar agentes como sistemas capazes de executar tarefas de ponta a ponta. Mas autonomia sem consciência dos próprios limites é apenas velocidade aplicada ao desconhecido. O avanço mais importante pode ser ensinar o agente a reconhecer quando uma ação exige uma evidência que ele ainda não possui.
Isso não significa tornar toda automação lenta ou inútil. Significa reservar a cautela para os pontos certos. Um agente pode agir diretamente em tarefas reversíveis e de baixo risco, enquanto exige confirmação, fonte adicional ou revisão humana para decisões com impacto financeiro, jurídico, médico ou social.
A questão filosófica é simples e profunda: uma máquina deve ser considerada responsável por uma decisão que tomou porque ninguém a informou do fato decisivo? Na prática, a responsabilidade continuará pertencendo às pessoas e organizações que desenharam o sistema. Por isso, a ausência de evidência não pode ser tratada como um detalhe técnico. Ela é uma escolha de governança.
O agente realmente confiável não é o que sempre responde sim, nem o que recusa tudo por medo. É o que sabe distinguir uma resposta completa de uma resposta apenas verdadeira, identifica o que falta e interrompe o caminho antes que a lacuna vire dano.