Segurança em agentes de IA: guia para empresas brasileiras

A segurança de um agente de IA não depende apenas do modelo. Ela depende dos dados enviados, das fontes consultadas, das ferramentas conectadas, das permissões concedidas, da forma como a saída é usada e da capacidade de detectar e interromper uma operação insegura. Uma adoção responsável começa com inventário, classificação de risco, privilégio mínimo, testes adversariais, revisão humana e monitoramento contínuo.

Por que agentes de IA mudam o modelo de risco?

Uma ferramenta de geração de texto produz conteúdo. Um agente pode, além de gerar texto, escolher ferramentas, buscar dados, preencher parâmetros e iniciar ações. Quanto maior a autonomia e o acesso, maior o impacto possível de uma interpretação incorreta, de uma instrução maliciosa ou de uma integração vulnerável. O risco deixa de ser apenas “resposta errada” e passa a incluir alteração de registros, envio de mensagens, exposição de informação e execução de fluxos indevidos.

O NIST organiza a gestão de risco de IA em funções como governar, mapear, medir e gerenciar. Para IA generativa, o instituto publicou um perfil específico que reforça a necessidade de considerar riscos ao longo de todo o ciclo de vida. A OWASP, por sua vez, mantém uma lista de vulnerabilidades críticas em aplicações com modelos de linguagem, incluindo prompt injection e tratamento inseguro da saída. Essas referências não substituem a análise do contexto brasileiro, mas fornecem uma base útil para estruturar controles.

Mapa dos principais riscos e controles

1. Vazamento e uso inadequado de dados

O vazamento pode ocorrer antes, durante ou depois da resposta. Um colaborador pode copiar dados pessoais para uma ferramenta não aprovada; o agente pode recuperar um documento que o usuário não deveria acessar; logs podem armazenar informações sensíveis; um fornecedor pode manter entradas além do necessário; ou a resposta pode combinar trechos e revelar conteúdo de outra área.

No Brasil, o uso de IA não elimina as obrigações relacionadas ao tratamento de dados pessoais. A ANPD destaca desafios como uso para finalidade diferente da originalmente prevista, falta de transparência, viés e aumento do risco de tratar dados pessoais sem salvaguardas. Para agentes de pequeno porte, a Autoridade também oferece guia e checklist de segurança da informação. A análise jurídica depende do caso concreto, mas a engenharia pode aplicar controles objetivos:

• inventariar quais dados entram, onde são processados, quem recebe e por quanto tempo permanecem;
• remover dados pessoais e segredos que não sejam necessários ao objetivo;
• separar ambientes de teste e produção e proibir dados reais em protótipos não autorizados;
• usar identidade individual, controle de acesso por função e revisão periódica de permissões;
• avaliar contrato, subprocessadores, localização, retenção, exclusão e uso para treinamento;
• proteger logs e backups com a mesma disciplina aplicada ao sistema principal;
• definir canal de incidente, responsável e procedimento de contenção.

2. Alucinação e informação sem fundamento

Modelos de linguagem geram sequências plausíveis; plausibilidade não é comprovação. Um agente pode inventar preço, prazo, número de contrato, regra interna, citação ou explicação técnica. O problema se agrava quando a resposta é inserida automaticamente em um sistema ou apresentada com confiança excessiva.

A mitigação começa pelo desenho do caso de uso. Para perguntas sobre a empresa, conecte o agente a fontes autorizadas e atualizadas. Exija que a resposta aponte a fonte quando isso for importante. Configure um comportamento explícito de abstinência: se não houver evidência suficiente, o agente deve informar a limitação ou transferir o caso. Construa um conjunto de teste com casos conhecidos, ambíguos, desatualizados e fora do escopo. Em decisões com impacto jurídico, financeiro, médico, de segurança ou sobre direitos, mantenha especialista humano responsável.

Não use apenas uma taxa média de acerto. Registre a gravidade do erro. Confundir um horário de atendimento é diferente de criar uma instrução de pagamento. A aceitação deve considerar precisão, cobertura, capacidade de recusar, fidelidade à fonte e custo de revisão.

3. Viés algorítmico e tratamento desigual

Viés pode entrar pelos dados históricos, pelos rótulos, pela definição do objetivo, pela cobertura desigual da base de conhecimento, pelas instruções ou pela forma como a saída é usada. Um agente de triagem pode interpretar estilos de escrita de maneira desigual; um sistema de recomendação pode reforçar padrões históricos; uma automação de recrutamento pode usar sinais inadequados como aproximação de desempenho.

Mitigar viés exige transformar a preocupação ética em teste. Defina quais grupos e situações precisam ser avaliados, compare taxas de erro e encaminhamento, analise falsos positivos e falsos negativos, documente critérios e permita contestação. Remova atributos sensíveis apenas quando isso fizer sentido: apagar uma coluna não elimina correlações indiretas. Casos de alto impacto exigem avaliação especializada e governança proporcional.

A empresa também deve questionar o próprio objetivo. Se o indicador escolhido reproduz uma prática injusta, um modelo tecnicamente preciso apenas automatiza o problema com mais velocidade.

4. Prompt injection: quando conteúdo vira instrução

Prompt injection ocorre quando uma entrada tenta alterar o comportamento do modelo. O ataque pode ser direto, em uma mensagem do usuário, ou indireto, escondido em página, e-mail, documento ou campo recuperado pelo agente. Um texto pode instruir o sistema a ignorar regras, revelar informações, usar uma ferramenta ou enviar dados a outro destino.

Não existe uma frase mágica que elimine prompt injection. O controle precisa existir fora do modelo. Separe instruções confiáveis de conteúdo não confiável; limite ferramentas por allowlist; valide argumentos; aplique autorização no sistema chamado, não apenas no prompt; exija confirmação para ações sensíveis; restrinja destinos; filtre dados de saída; e teste documentos maliciosos. O agente nunca deve ganhar acesso apenas porque “entendeu” que o usuário pediu.

O modelo pode sugerir uma ação. A autorização precisa ser decidida por uma camada determinística que conhece identidade, permissão, contexto e limite.

5. Tratamento inseguro da saída

A saída de um modelo deve ser tratada como entrada não confiável. Se um sistema executa diretamente SQL, HTML, código, comando de terminal, filtro, URL ou parâmetros produzidos pelo agente, uma resposta manipulada pode atravessar a fronteira entre texto e execução. A OWASP destaca esse risco como tratamento inseguro da saída.

Use parâmetros estruturados e schemas; valide tipos, tamanho e valores permitidos; normalize destinos; evite interpretação dinâmica; sanitize conteúdo exibido; aplique consultas parametrizadas; e mantenha a regra de autorização no serviço final. Para código gerado, utilize ambiente isolado, recursos limitados, rede controlada e revisão antes de qualquer uso em produção.

6. Agência excessiva e ações indevidas

Um agente não precisa de todas as permissões de um funcionário. Se o caso de uso é consultar status, forneça acesso somente de leitura aos campos necessários. Se precisa criar rascunho, não conceda envio. Se propõe pagamento, separe proposta, validação e aprovação. Credenciais devem ser específicas, rotacionáveis e auditáveis.

Controles importantes incluem limite de valor, quantidade e frequência; confirmação explícita; dupla aprovação em ações críticas; bloqueio de operações fora do horário ou contexto; timeout; idempotência; e botão de interrupção. Planeje também o caminho de exceção: quando o agente falha, o processo deve continuar de forma segura por uma pessoa.

7. Dependências, fornecedores e cadeia de suprimentos

Uma aplicação de IA pode depender de modelo, provedor de nuvem, banco vetorial, conector, biblioteca, canal, ferramenta de observabilidade e documentos externos. Cada componente adiciona dados, credenciais, versões e mudanças fora do controle direto da empresa.

Mantenha um inventário com proprietário, finalidade, dados tratados, versão e fornecedor. Acompanhe comunicados de segurança e mudanças de termos. Fixe versões quando possível, avalie dependências, segmente segredos, mantenha cópias das instruções e testes, e defina um plano de saída. Se trocar o modelo altera completamente a resposta e não existe conjunto de regressão, a organização não controla o comportamento do sistema.

8. Indisponibilidade, abuso e custo descontrolado

Agentes podem entrar em loops de chamadas, repetir ferramentas, processar arquivos enormes ou ser induzidos a consumir recursos. Uma falha do provedor pode interromper o atendimento. O efeito é operacional e financeiro.

Defina limites de passos, tokens, tempo, tamanho de arquivo, chamadas por usuário e orçamento. Use filas, rate limits, cache seguro, circuit breaker e alertas. Tenha uma degradação controlada: o agente pode passar para FAQ estática, registrar pedido ou transferir para humano quando um componente estiver indisponível.

Controles em quatro camadas

Governança

Inventário de casos de uso, proprietário, classificação de risco, política de uso, critérios de aprovação, fornecedores, responsabilidades e revisão periódica.

Dados e identidade

Minimização, finalidade, classificação, acesso por função, criptografia, segregação, retenção, exclusão, DLP e credenciais específicas.

Aplicação e modelo

Fontes autorizadas, instruções versionadas, filtros, validação de saída, ferramentas permitidas, autorização externa, confirmação, limites e testes adversariais.

Operação e resposta

Logs protegidos, métricas de qualidade e segurança, alertas, revisão humana, botão de interrupção, investigação, comunicação e melhoria após incidente.

Roteiro prático antes de implantar

1. Defina a decisão ou ação: o agente informa, recomenda, prepara ou executa?
2. Classifique o impacto: o que acontece se a resposta estiver errada ou indisponível?
3. Mapeie dados e fornecedores: entradas, saídas, logs, retenção e terceiros.
4. Reduza o escopo: comece com leitura e rascunho antes de permitir escrita e envio.
5. Imponha autorização: valide identidade, permissão e limites fora do modelo.
6. Crie casos de teste: normais, ambíguos, maliciosos, fora de escopo e de falha.
7. Defina métricas: qualidade, recusa, transferência, incidente, latência e custo.
8. Prepare o humano: treinamento, fila, contexto e responsabilidade.
9. Planeje a interrupção: desligamento, rollback e processo alternativo.
10. Revise antes de escalar: compare evidências do piloto com os critérios de aceitação.

Como avaliar a maturidade de segurança

Perguntas frequentes

Quais são os principais riscos de segurança?

Vazamento e uso inadequado de dados, respostas inventadas, viés, prompt injection, saída insegura, permissões excessivas, dependências vulneráveis, indisponibilidade e falta de registros para investigar falhas.

Uma política de uso de IA é suficiente?

Não. A política precisa ser acompanhada por inventário, acesso, minimização de dados, testes, logs, treinamento, revisão humana e resposta a incidentes.

Como reduzir alucinações?

Delimite o escopo, conecte fontes autorizadas, exija referência, configure abstinência, teste casos reais, mantenha revisão humana e monitore erros depois da implantação.

Fontes técnicas

• NIST — AI Risk Management Framework e perfil para IA generativa.
• OWASP — Top 10 para aplicações com modelos de linguagem.
• ANPD — desafios de IA, dados pessoais, transparência e viés.
• ANPD — guia de segurança para agentes de tratamento de pequeno porte.

Nota: este conteúdo é informativo e técnico. Não constitui parecer jurídico, certificação de conformidade ou garantia de ausência de incidentes. Controles precisam ser adaptados ao contexto, aos dados, ao impacto e às obrigações de cada organização.