Como avaliar o risco de um agente de IA antes da produção

10 de maio de 2026 · 10 min de leitura

A avaliação de risco de um agente de IA deve acontecer antes da produção, não depois do primeiro incidente, da primeira solicitação de auditoria ou de uma escalada confusa.

Ela não precisa ser pesada. Se o processo ficar pesado demais, os times vão contorná-lo. A versão útil é uma entrada estruturada que ajuda produto, compliance, segurança, arquitetura e responsáveis de negócio a responder uma pergunta:

O que este agente poderia fazer, quem seria afetado e quais controles precisam existir antes que ele possa operar?

Este artigo apresenta um modelo prático para avaliar agentes de IA corporativos no momento em que já existe um caso de uso real, uma arquitetura preliminar e um caminho de lançamento, mas ainda não uma aprovação de produção.

Versão curta

Antes da produção, avalie sete dimensões:

O resultado deve ser um nível de risco curto, uma checklist de controles, responsáveis nomeados e evidências reutilizáveis em revisões de segurança, privacidade, compliance e arquitetura.

Por que avaliar agentes é diferente

Revisões tradicionais de IA costumam focar no modelo, dados, uso pretendido, qualidade da saída, viés, explicabilidade e privacidade. Isso continua importante.

Agentes adicionam risco operacional.

Um agente pode:

• Chamar ferramentas ou APIs.
• Recuperar documentos ou registros.
• Usar permissões delegadas.
• Armazenar memória.
• Executar planos de múltiplas etapas.
• Rodar a partir de gatilhos em segundo plano.
• Enviar mensagens, atualizar registros, abrir tickets, aprovar etapas de workflow ou acionar processos de clientes, funcionários, finanças, jurídico, segurança ou infraestrutura.

A avaliação não pode parar em "a resposta está correta?" Ela também precisa perguntar: "o que o sistema pode fazer com essa resposta?"

O modelo deve avaliar comportamento, não rótulos. Um chatbot chamado agente pode ter baixo risco. Um assistente de workflow com ferramentas pode ter alto risco mesmo usando um modelo conhecido.

Etapa 1: comece pelo intake

O intake define os limites. Sem limites, o restante da avaliação fica abstrato.

Registre:

• Nome do agente e responsável de negócio.
• Objetivo pretendido.
• Usuários principais.
• Clientes, funcionários, fornecedores ou terceiros afetados.
• Processo de negócio suportado.
• Canal de implantação: site, Teams, Slack, portal interno, API ou workflow em segundo plano.
• Gatilho de produção: prompt do usuário, criação de ticket, e-mail recebido, job agendado, webhook ou evento de fila.
• Escopo do lançamento: piloto, produção interna, voltado ao cliente ou corporativo.
• Responsável por suporte e incidentes.

O ponto central é ownership. Se o agente não tem responsável de negócio, caminho de suporte e responsável por incidentes, ele não está pronto para produção.

Etapa 2: pontue a autonomia

Autonomia mede quanto o agente pode decidir e agir sem uma pessoa conduzindo cada etapa.

Perguntas:

• Ele pode rodar sem mensagem de usuário?
• Pode concluir mais de uma etapa antes de voltar a uma pessoa?
• Pode escolher qual ferramenta chamar?
• Pode decidir quando uma tarefa terminou?
• Pode tentar de novo, escalar, delegar ou mudar planos?
• Pode afetar registros de negócio, comunicação com cliente, pagamento, decisão de RH, contrato, controle de segurança ou configuração de infraestrutura?

Alta autonomia não é automaticamente inaceitável. Mas exige limites claros, logging forte, aprovação para ações de alto impacto, monitoramento e uma forma rápida de parar o agente.

Etapa 3: pontue o acesso a ferramentas

Acesso a ferramentas torna o risco concreto. Ferramentas incluem APIs, bancos de dados, navegadores, e-mail, tickets, CRM, ERP, RH, automação, execução de código, arquivos, pagamentos e ferramentas de segurança.

Para cada ferramenta, documente nome, objetivo, leitura ou escrita, autenticação, identidade usada, escopos, limites, se o modelo escolhe argumentos, se a saída influencia chamadas futuras e se exige aprovação.

Aqui entra o menor privilégio. Se o agente só precisa do status do pedido, não dê permissão de reembolso. Se só precisa criar um rascunho, não permita enviar a mensagem.

Etapa 4: pontue a sensibilidade dos dados

Agentes podem expor dados diretamente ou indiretamente, ao resumir, transformar, combinar ou enviar dados por outro canal.

Pergunte:

• Quais fontes de dados o agente pode acessar?
• Ele pode combinar dados de vários sistemas?
• Pode acessar dados pessoais?
• Pode ver contratos confidenciais, arquivos de funcionários, finanças, código-fonte, credenciais, logs de segurança ou material jurídico?
• Pode mover dados para canais menos protegidos?
• Pode armazenar memória?
• Retenção e exclusão estão definidas?
• Minimização e limitação de finalidade foram tratadas?

Quando há dados pessoais, conecte a avaliação à revisão de privacidade. Em contexto europeu, o GDPR é relevante para base legal, minimização, segurança, violações e DPIA quando necessário.

Etapa 5: defina a supervisão humana

Supervisão humana não significa ter uma pessoa perto do processo. Ela precisa ser específica o suficiente para mudar o resultado.

Para cada ação relevante, defina quem revisa, o que vê, qual decisão pode tomar, se pode rejeitar, editar, escalar ou pausar, se a aprovação fica em log, o que acontece se a pessoa não estiver disponível e se alguém pode parar o agente.

Deve haver aprovação quando a ação é difícil de reverter, afeta direitos ou acesso, movimenta dinheiro, muda status de RH, envia comunicação externa, altera registros legais ou contratuais, muda postura de segurança ou afeta infraestrutura de produção.

Supervisão fraca:

Há um humano no loop.

Supervisão útil:

Um supervisor de suporte deve aprovar reembolsos acima de CHF 100. A tela mostra solicitação do cliente, política recuperada, valor proposto, motivo, pedido de origem, flags de risco e trace ID. Aprovação ou rejeição é registrada antes da chamada à API de reembolso.

Esse nível de especificidade sobrevive à produção.

Etapa 6: pontue o impacto no negócio

Impacto no negócio descreve o que acontece se o agente falhar.

Considere se o agente erra, age com excesso de confiança, segue prompt injection, chama a ferramenta certa com argumentos errados, expõe dados, pula aprovação, age em escala, falha em silêncio, não explica o ocorrido ou cria registros confiados por sistemas downstream.

Escala importa. Um rascunho ruim não é igual a 10.000 e-mails errados para clientes. Uma recomendação ruim não é igual a um gatilho autônomo que se repete a cada poucos minutos.

Etapa 7: atribua o nível final

Uma abordagem prática é pontuar autonomia, ferramentas, dados e impacto de 0 a 3, usando a maior pontuação e red flags.

A fórmula ajuda, mas não substitui julgamento. Um agente com baixa autonomia e acesso à folha de pagamento ainda exige revisão forte. Um agente sem dados sensíveis, mas com permissão para mudar firewall, não é baixo risco.

Checklist do gate de produção

Antes do lançamento, exija evidências:

• Responsável de negócio e técnico.
• Intake aprovado.
• Entrada no inventário.
• Matriz de permissões de ferramentas.
• Classificação de dados e revisão de privacidade quando necessário.
• Desenho da supervisão humana.
• Plano de logging e rastreabilidade.
• Testes de prompt injection e mau uso para agentes com ferramentas.
• Plano de monitoramento e alertas.
• Responsável por incidentes e caminho de escalada.
• Data de revisão e gatilhos de reavaliação.

Agentes de alto risco também precisam de revisão de arquitetura, aceitação explícita do risco, testes de workflows de aprovação, cenários red team, rollback ou kill switch, change control para prompts, ferramentas, fontes de retrieval e políticas, além de regras de retenção de evidências.

Exemplo: agente de suporte para reembolso

Um agente de suporte pode ler histórico de pedidos, resumir mensagens, verificar políticas e preparar reembolsos.

Nível final: Alto.

Controles necessários:

• Ferramenta de reembolso limitada ao escopo mínimo.
• Limite de valor.
• Aprovação humana acima de um valor definido.
• Bloqueio automático de padrões incomuns.
• Testes de prompt injection com mensagens e anexos de clientes.
• Audit log para solicitação, política recuperada, decisão proposta, aprovação, chamada de ferramenta e resultado.
• Owner de suporte e rota de incidente claros.

O objetivo não é bloquear sistemas úteis, mas tornar visíveis os controles antes de tocar clientes e dinheiro reais.

Exemplo: assistente de políticas de RH

Um assistente de RH responde perguntas de funcionários usando documentos aprovados. Ele não tem ferramentas de escrita nem acesso a arquivos individuais.

Nível final: Baixo a médio, dependendo da audiência e dos temas.

Controles: fontes aprovadas, owner para atualização das políticas, links de fonte, escalada para temas trabalhistas, jurídicos, benefícios ou dados sensíveis, e logging de uso.

Base de referência

Este padrão se alinha ao NIST AI Risk Management Framework 1.0, NIST AI RMF Generative AI Profile, NIST AI 600-1, OWASP Top 10 for LLM Applications 2025, OWASP Agentic AI - Threats and Mitigations, EU AI Act, Regulation (EU) 2024/1689 e GDPR, Regulation (EU) 2016/679.

A lição prática é simples: avaliar agentes não deve ser documentação de modelo com outro nome. Deve conectar capacidades reais do agente a impacto de negócio e controles de produção.

Regra prática

Se um agente só responde, avalie qualidade e acesso a dados.

Se pode agir, avalie o caminho da ação.

Se pode agir sem esperar uma pessoa, avalie o modelo operacional.

E se ninguém consegue explicar quem é dono do agente, o que ele pode fazer, o que fez e como pará-lo, ele não está pronto para produção.