A discussão sobre agentes de IA costuma começar pela parte mais chamativa: o que eles conseguem fazer sozinhos. Escrever, pesquisar, resumir, abrir tarefas, consultar sistemas, montar relatórios, acionar APIs e conduzir etapas inteiras de uma operação.
Mas a pergunta mais importante vem antes: até onde esse agente pode ir sem criar risco para o negócio?
Autonomia sem limite parece produtividade no começo. Depois, aparece como retrabalho, decisão sem dono, acesso desnecessário, falha difícil de rastrear e uma sensação perigosa de que a ferramenta está funcionando porque está se mexendo. Em operação real, agente de IA não precisa apenas de prompt melhor. Precisa de fronteira, permissão, validação e registro.
O problema não é o agente. É a autonomia mal desenhada
Um agente é diferente de um chatbot simples porque pode combinar raciocínio, memória, ferramentas e execução. Ele recebe um objetivo, quebra em etapas, consulta informações e pode agir em sistemas conectados. Esse salto muda a natureza do risco.
Quando a IA apenas sugere um texto, o impacto de um erro costuma ficar limitado à revisão. Quando ela executa uma ação, o erro entra na operação: altera um registro, envia uma resposta, cria uma tarefa, consulta dados sensíveis, move uma oportunidade de etapa ou toma uma decisão que alguém depois precisa desfazer.
Por isso, a maturidade não está em liberar tudo mais rápido. Está em decidir quais ações merecem autonomia, quais precisam de confirmação humana e quais nunca deveriam ficar disponíveis para um modelo.
O que a OWASP chama de agência excessiva
A OWASP separa um risco muito prático nas aplicações com LLMs: agência excessiva. Em termos simples, é quando o sistema permite que o modelo execute ações danosas porque recebeu função demais, permissão demais ou autonomia demais.
Isso pode acontecer por alucinação, por uma instrução ambígua, por prompt injection ou por conteúdo externo manipulado. O ponto central é que o estrago não nasce apenas da resposta errada do modelo. Nasce do que o modelo estava autorizado a fazer depois da resposta.
Três excessos que aparecem na prática
Excesso de funcionalidade: o agente tem ferramentas que não precisa para cumprir o trabalho. Um assistente criado para consultar documentos também consegue apagar ou alterar arquivos.
Excesso de permissão: a ferramenta deveria ler dados, mas usa uma credencial com poder de editar, inserir ou excluir informações. A empresa confia no prompt para segurar algo que deveria estar travado na permissão do sistema.
Excesso de autonomia: uma ação de alto impacto acontece sem revisão. O agente envia, apaga, aprova, responde ou modifica antes de alguém validar se aquilo fazia sentido naquele contexto.
Prompt injection não é detalhe técnico
Prompt injection acontece quando uma entrada muda o comportamento do modelo de forma não prevista. O risco fica mais forte quando o agente lê documentos, páginas, e-mails, comentários, planilhas ou qualquer conteúdo externo. A instrução maliciosa pode estar dentro do material que o próprio agente foi buscar.
Na rotina de uma empresa, isso significa que não basta escrever um prompt dizendo “ignore instruções externas”. Esse tipo de comando ajuda, mas não substitui separação de contexto, validação de saída, escopo mínimo de ferramentas e bloqueios determinísticos.
A lógica precisa ser simples: o modelo pode interpretar; o sistema deve limitar. O que é perigoso não deve depender apenas da obediência do modelo. Deve estar travado por arquitetura, permissão, fluxo e revisão.
O que muda quando a IA entra no processo de verdade
Um artigo da Harvard Data Science Review sobre empresas centradas em agentes reforça um ponto importante: os maiores ganhos não vêm de encaixar IA em fluxos antigos, mas de redesenhar a forma como o trabalho acontece. A tese é boa, mas existe uma consequência operacional que muita empresa pula: redesenhar fluxo também significa redesenhar controle.
Se o processo antigo era humano, muita coisa ficava protegida por atrito. A pessoa perguntava, esperava, confirmava, lembrava de uma exceção ou chamava alguém antes de seguir. Quando o agente entra, parte desse atrito desaparece. Isso é ótimo quando o fluxo está bem definido. É perigoso quando o processo ainda depende de memória informal.
Antes de pedir que um agente acelere uma operação, a empresa precisa transformar conhecimento tácito em regra explícita. O que pode ser feito? Com quais fontes? Em nome de quem? Com qual limite? Onde registra? Quem revisa? O que acontece quando há dúvida?
Um modelo simples para dar autonomia com critério
A forma mais prática de começar é separar o agente em quatro camadas: tarefa, dados, ferramenta e decisão. Essa separação evita tratar tudo como um grande prompt e ajuda a descobrir onde está o risco real.
1. Tarefa
Defina o trabalho em linguagem operacional, não em desejo abstrato. “Ajudar o comercial” é vago. “Ler o briefing, identificar ausência de informação obrigatória e sugerir perguntas para a próxima reunião” é controlável.
Quanto mais clara for a tarefa, menor a chance de o agente improvisar um caminho que parece útil, mas atrapalha a operação.
2. Dados
Liste quais fontes o agente pode consultar. Separe dado confiável, dado externo e dado sensível. Informação de CRM, contrato, nota fiscal, proposta, e-mail e base pública não têm o mesmo nível de confiança nem o mesmo nível de exposição.
Também vale definir o que o agente não pode usar. Esse limite é tão importante quanto a fonte permitida.
3. Ferramentas
Dê apenas as ferramentas necessárias. Se o agente precisa consultar status, não entregue uma credencial que também altera status. Se precisa escrever rascunho, não entregue permissão direta para enviar. Se precisa abrir tarefa, limite o projeto, o tipo de tarefa e os campos permitidos.
Esse é o princípio de menor privilégio aplicado à IA. Não é burocracia. É desenho de segurança para que um erro pequeno não vire ação grande.
4. Decisão
Classifique a decisão em baixo, médio ou alto impacto. Baixo impacto pode seguir automático com registro. Médio impacto pode exigir amostragem ou revisão posterior. Alto impacto deve pedir aprovação antes da execução.
Enviar uma sugestão interna não tem o mesmo peso de responder cliente. Atualizar um campo informativo não tem o mesmo peso de mudar uma etapa comercial. Resumir um contrato não tem o mesmo peso de aprovar uma condição.
O papel da revisão humana muda
Revisão humana não deveria ser sinônimo de ler tudo que a IA produz. Isso mata o ganho de produtividade e transforma automação em fila de conferência. O papel humano precisa ser mais inteligente.
Antes de colocar um agente em produção, vale passar por uma lista curta e objetiva:
- A tarefa está descrita com começo, fim e critério de sucesso?
- As fontes permitidas estão claras?
- O agente acessa apenas os dados necessários?
- As ferramentas têm permissões mínimas?
- Ações de alto impacto exigem aprovação humana?
- Existe log de decisão, entrada, saída e ação executada?
- Há um caminho simples para pausar o agente?
- Existe uma métrica que prove redução de retrabalho ou melhoria de decisão?
Se qualquer resposta for não, a empresa talvez ainda não precise de mais autonomia. Precise de mais desenho operacional.
Conclusão
Agentes de IA não são perigosos por definição. O risco aparece quando a empresa confunde capacidade com autorização. Um modelo conseguir executar uma tarefa não significa que ele deva executar sem limite.
A boa adoção de IA passa menos por encantamento e mais por engenharia de rotina: escopo claro, fonte confiável, permissão mínima, revisão proporcional, log e métrica. Esse conjunto pode parecer menos empolgante do que falar em autonomia total, mas é o que transforma IA em operação confiável.
Mais reflexões sobre IA, automação e rotina de negócios estão no meu Instagram: https://www.instagram.com/felipebelloni
FAQ
Toda ação de agente de IA precisa de aprovação humana?
Não. A aprovação deve ser proporcional ao impacto. Ações reversíveis, internas e de baixo risco podem ser automáticas. Ações externas, sensíveis, financeiras, comerciais ou difíceis de reverter precisam de aprovação ou, no mínimo, de uma regra de controle mais forte.
Um bom prompt resolve o risco de prompt injection?
Não sozinho. Prompt ajuda, mas não substitui limite de ferramenta, separação de conteúdo externo, validação determinística e menor privilégio. O modelo deve ser orientado; o sistema deve ser protegido.
Qual é o primeiro passo para usar agentes de IA com segurança?
Escolher uma tarefa pequena, repetível e bem delimitada. Depois, definir fontes, permissões, revisão e métrica. A autonomia deve aumentar conforme a operação prova que o fluxo é confiável.
Como saber se um agente está gerando valor real?
Procure sinais operacionais: menos retrabalho, menor tempo de ciclo, menos exceções, decisões mais consistentes e maior rastreabilidade. Volume de saída, sozinho, não é prova de produtividade.
Fontes e referências
- NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
- NIST Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
- OWASP LLM01:2025 Prompt Injection: https://genai.owasp.org/llmrisk/llm01-prompt-injection/
- OWASP LLM06:2025 Excessive Agency: https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
- Harvard Data Science Review — The Agent-Centric Enterprise: https://hdsr.mitpress.mit.edu/pub/0mrfxamu
