Um documento pode tentar dar ordens à IA: o risco que exige atenção na automação jurídica

Uma ferramenta recebe a tarefa de resumir um documento, mas encontra dentro dele um trecho que tenta orientar sua própria conduta. Em vez de apenas descrever o conteúdo, pode ser induzida a mudar a resposta ou propor uma ação que o usuário não solicitou. Esse risco, conhecido como injeção de instruções, é relevante para escritórios que incorporam inteligência artificial à leitura de arquivos e à automação de rotinas.

O projeto de segurança em IA generativa da OWASP, organização que mantém referências abertas de segurança de aplicações, descreve a injeção indireta como aquela que chega por fontes externas, a exemplo de páginas e arquivos. A ameaça não depende de o usuário legítimo querer alterar o funcionamento do sistema. Ele pode simplesmente pedir a análise de um material que contém uma tentativa de interferência.

O problema não transforma todo documento em arquivo malicioso nem demonstra que qualquer ferramenta será afetada da mesma maneira. O resultado depende de como o sistema processa o conteúdo e das operações que consegue realizar. A distinção importante é entre material apresentado para análise e instruções de quem tem autoridade para definir a tarefa.

Na rotina jurídica, essa fronteira é especialmente visível. Uma peça pode conter pedidos dirigidos ao juízo, uma notificação pode exigir uma providência e um contrato pode atribuir obrigações às partes. O assistente precisa interpretar esses elementos como conteúdo do documento. Eles não são, por esse motivo, autorização para alterar a agenda do escritório, enviar arquivos ou modificar os critérios de revisão adotados pelo profissional.

O risco muda quando o assistente também pode agir

Considere um exemplo hipotético: um escritório utiliza uma ferramenta para preparar resumos de documentos recebidos de terceiros. Um trecho tenta induzi-la a omitir uma ressalva desfavorável à posição de quem enviou o arquivo. Se a resposta for aceita sem conferência, a análise interna pode ficar incompleta. O ponto de verificação é a correspondência entre o material original e o resumo, não apenas a fluidez do texto produzido.

Agora imagine que o mesmo assistente também consiga encaminhar mensagens. A tentativa de interferência pode buscar uma ação fora do pedido original. Ter acesso ao conteúdo e ter permissão para agir sobre outros sistemas são capacidades distintas. A avaliação da automação precisa identificar ambas, pois uma falha de interpretação pode ter consequências diferentes conforme os recursos disponíveis.

A OWASP trata separadamente do excesso de autonomia concedida a sistemas baseados em modelos de linguagem. Entre os cuidados está limitar funções e permissões ao necessário para o uso pretendido. No escritório, isso sugere uma pergunta prática antes de ativar uma integração: para elaborar um resumo, a ferramenta realmente precisa conseguir enviar e-mails, editar arquivos de outros assuntos ou operar com permissões administrativas?

A resposta deve orientar a configuração e a avaliação do serviço, não ficar apenas em uma declaração de boas intenções. Se determinada ação não integra a tarefa, convém que o desenho da operação não a disponibilize por conveniência. Um controle fora da resposta do modelo pode restringir o que o sistema consegue executar mesmo quando a saída produzida contém uma sugestão inadequada.

A separação também ajuda a organizar responsabilidades. Quem solicita uma leitura pode não ter atribuição para autorizar envio de documentos a destinatários externos. A existência de uma conta com acesso a vários recursos não significa que todo pedido feito por ela tenha o mesmo alcance. O procedimento precisa preservar essa diferença entre capacidade técnica e autorização para aquela execução concreta.

O conteúdo suspeito, por sua vez, não deve ser transformado em recomendação operacional apenas porque veio acompanhado de linguagem convincente. Uma instrução que aparece em um arquivo analisado pode se apresentar como aviso urgente, regra de segurança ou orientação de uma autoridade. Sua formulação não muda a origem: continua sendo material externo, sujeito a avaliação, e não uma ordem automaticamente válida para a ferramenta.

Revisar exige enxergar o que será executado

Pedir aprovação humana é uma medida importante, mas a forma dessa aprovação faz diferença. Um botão genérico de continuar pode não esclarecer que haverá envio de um documento, alteração de destinatário ou modificação de um registro. A pessoa responsável precisa receber informação suficiente sobre a ação, seu alcance e os elementos envolvidos para decidir com conhecimento do que está autorizando.

Em uma rotina de envio, por exemplo, uma conferência útil pode mostrar o destinatário, os anexos e o texto final antes da execução. Esse é um exemplo de organização defensiva, não uma garantia universal de segurança. O responsável ainda precisa verificar se o conteúdo corresponde à demanda e se o envio está dentro das atribuições e das condições do atendimento.

O exame de um resumo segue outra lógica. Pode ser necessário voltar ao documento, localizar a passagem que sustenta uma conclusão e conferir se ressalvas relevantes foram preservadas. Uma referência que parece específica não demonstra, sozinha, que a afirmação está correta. O trabalho de revisão envolve a substância do material, inclusive aquilo que a resposta deixou de mencionar.

Testes com conteúdo fictício permitem avaliar essas fronteiras sem utilizar dados de clientes ou executar ações reais. A equipe pode verificar se o sistema mantém o objetivo autorizado diante de material incompatível com ele e se exige a confirmação prevista antes de uma operação relevante. O teste deve ter limites definidos, responsáveis identificados e um ambiente adequado à avaliação.

Passar em um conjunto de testes não elimina a necessidade de acompanhamento. Uma mudança de modelo, integração ou configuração pode alterar o comportamento da solução. Convém registrar o que foi testado, em qual versão e com quais critérios, para que a avaliação não se transforme em uma aprovação indefinida de funcionalidades adicionadas posteriormente.

Também há diferenças entre falha e suspeita de ataque. Uma resposta incorreta pode decorrer de interpretação inadequada, contexto incompleto ou outros problemas. Antes de atribuir intenção maliciosa a um remetente, é necessário examinar as evidências. Para a operação do escritório, a primeira providência é impedir que o resultado duvidoso avance sem conferência e preservar os elementos necessários à análise técnica.

A preservação deve evitar uma nova exposição. Ao solicitar suporte, o escritório pode identificar o comportamento observado e utilizar canais apropriados, sem publicar documentos de clientes em fóruns ou mensagens abertas. O que precisa ser compartilhado depende da investigação e das condições do serviço; reproduzir todo o acervo não é uma resposta automática a uma falha localizada.

Para gestores, o tema altera a pergunta feita ao fornecedor. Além de saber se a ferramenta produz um bom texto, é necessário entender que fontes ela lê, quais ações consegue realizar e onde existem limites efetivos de autorização. O desenho de segurança deve ser discutido com quem conhece a solução, porque uma política interna não substitui recursos que o produto não oferece.

A automação jurídica pode separar preparação e execução: o assistente reúne informações ou elabora uma proposta, enquanto a providência relevante depende de uma validação adequada. O risco de injeção de instruções reforça a importância dessa separação. Um documento pode conter argumentos e pedidos a serem compreendidos; não deve, apenas por ser lido, receber o poder de comandar a operação do escritório.