Agentes de IA: autonomia sem controle é risco operacional!

Em uma aula recente, debatemos um tema que considero fundamental para a adoção corporativa da IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI →: a segurança dos agentes. A discussão não pode se limitar ao que esses sistemas conseguem fazer. Precisamos definir o que estão autorizados a executar, quais riscos introduzem e como controlar suas consequências.

Diferentemente de um chatbot restrito à geração de respostas, um agente pode consultar bases de dados, acessar sistemas corporativos, acionar APIs, modificar registros e delegar tarefas. Dependendo de sua arquitetura e permissões, uma interpretação incorreta pode produzir consequências operacionais, financeiras e regulatórias.

Os riscos variam conforme o grau de autonomia, os privilégios concedidos e o impacto potencial das ações. Um agente que consulta documentos públicos exige controles diferentes daqueles necessários a sistemas que movimentam recursos financeiros ou alteram informações críticas.

Nesse contexto, considero essenciais dez questões.

1. Como impedir ações não autorizadas?

Imagine um agente responsável pela agenda de um executivo que decide cancelar uma reunião importante para resolver um conflito de horários.

Não basta incluir no prompt uma instrução exigindo aprovação. A restrição precisa ser aplicada pelo sistema responsável pela execução, por meio de mecanismos de autorização independentes do modelo.

O agente pode sugerir alterações, mas não deve conseguir efetivá-las sem a autorização necessária. Segurança não pode depender exclusivamente da obediência do LLM às instruções.

2. Como limitar o acesso a dados e sistemas?

Um agente de RH encarregado de responder a dúvidas sobre férias não precisa consultar salários, avaliações de desempenho ou informações médicas.

O princípio do menor privilégio exige restringir acessos à finalidade autorizada. Isso envolve identidades próprias, credenciais de curta duração quando viável e mecanismos centralizados de autenticação e autorização.

Também é necessário distinguir os privilégios do usuário, do agente e das ferramentas utilizadas, impedindo que a delegação de tarefas amplie indevidamente as permissões.

3. Como enfrentar ataques de prompt injection?

Um agente recebe um e-mail para resumir. No corpo da mensagem, encontra uma instrução maliciosa solicitando o envio de documentos confidenciais para um endereço externo.

O risco surge quando conteúdo recebido como dado passa a ser tratado como instrução operacional.

A proteção exige tratar fontes externas como não confiáveis, restringir ferramentas, controlar destinos de comunicação e validar ações sensíveis fora do modelo.

Como nenhuma defesa isolada elimina completamente o risco, a arquitetura precisa limitar os danos mesmo quando uma instrução maliciosa influencia o comportamento do agente.

4. Como controlar agentes que delegam tarefas?

Um agente de compras identifica fornecedores, outro compara propostas e um terceiro prepara o pedido.

Embora cada etapa possa parecer legítima, sua combinação pode resultar em uma aquisição não autorizada.

A delegação precisa preservar os limites de acesso e autoridade estabelecidos para o processo. Operações sensíveis exigem limites financeiros, segregação de funções e rastreabilidade entre os agentes envolvidos.

O controle deve considerar o fluxo completo, pois componentes individualmente seguros não garantem um processo seguro.

5. Como garantir a integridade das operações?

Um agente financeiro interpreta incorretamente o valor de uma fatura ou os dados bancários de um fornecedor. Mesmo seguindo o fluxo previsto, pode provocar prejuízos.

Operações críticas exigem validações determinísticas, conferência com fontes autorizadas, controles transacionais e proteção contra execuções duplicadas.

Quando houver aprovação humana, ela deve estar vinculada aos dados específicos da operação. Autorizar um pagamento não significa autorizar qualquer valor ou destinatário escolhido posteriormente pelo agente.

6. Como monitorar e auditar o comportamento?

Um agente de atendimento começa a consultar repetidamente informações de clientes sem justificativa operacional.

Identificar esse comportamento exige registrar identidades, chamadas de ferramentas, autorizações, alterações realizadas e resultados. Também é importante preservar versões relevantes de modelos, prompts e configurações.

Esses registros precisam ser protegidos contra alterações indevidas e observar requisitos de privacidade e retenção.

A observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps → deve permitir reconstruir operações e investigar incidentes sem depender exclusivamente das explicações produzidas pelo próprio agente.

7. Quando exigir supervisão humana?

Um agente pode responder a perguntas frequentes ou consultar pedidos com relativa autonomia. Entretanto, conceder reembolsos elevados, alterar dados bancários ou executar operações de alto impacto exige controles adicionais.

A necessidade de aprovação deve considerar risco financeiro, sensibilidade das informações, reversibilidade e obrigações regulatórias.

Mas supervisão humana não pode ser apenas formal. O responsável precisa receber informações verificáveis, compreender as consequências e ter condições efetivas de rejeitar a ação.

8. Como proteger memória e bases de conhecimento?

Um agente comercial armazena informações sobre clientes para personalizar atendimentos futuros.

Se registrar dados desnecessários, misturar informações de diferentes clientes ou incorporar conteúdo malicioso à memória, poderá comprometer a confidencialidade e a integridade das próximas interações.

É necessário controlar proveniência, acesso, retenção e exclusão das informações, distinguindo memória temporária de persistente e assegurando isolamento entre usuários e organizações.

Documentos recuperados e bases vetoriais também precisam de controles de integridade e atualização, pois podem conter informações incorretas, desatualizadas ou manipuladas.

9. Como conter falhas e recuperar operações?

Um agente de suporte entra em um ciclo de chamadas a uma API, consome recursos excessivos ou repete uma operação já concluída.

Limites de tempo, tentativas e orçamento ajudam a conter esses problemas. Sistemas críticos também precisam prever interrupção segura, tratamento de operações parcialmente executadas e procedimentos de recuperação.

Desligar um agente não desfaz automaticamente suas ações anteriores. Por isso, mecanismos de reversão, quando viáveis, e procedimentos compensatórios devem fazer parte da arquitetura.

Um kill switch é necessário em determinados contextos, mas não substitui um plano de resposta a incidentes.

10. Quem responde pelas decisões e consequências?

Imagine um agente utilizado em processos de crédito que produz recomendações sistematicamente inadequadas ou discriminatórias.

A responsabilidade não desaparece porque houve participação de IA. A organização precisa definir previamente responsáveis pelo processo de negócio, pela sustentação técnica, pela segurança e pela conformidade. Também deve estabelecer mecanismos de contestação, revisão de decisões e correção de danos, conforme as exigências legais aplicáveis.

Responsabilidade organizacional não pode ser improvisada depois de um incidente.

Essas questões evidenciam que segurança em agentes de IA não se resolve apenas com modelos mais avançados ou prompts mais elaborados. Exige combinar engenharia de software, cibersegurança, gestão de identidades, governança de dados e controles organizacionais.

Há ainda aspectos que atravessam todas essas dimensões.

Um deles é a segurança da cadeia de suprimentos. Modelos, bibliotecas, conectores e serviços externos podem introduzir vulnerabilidades. Alterações nesses componentes precisam ser avaliadas, pois podem modificar tanto a superfície de ataque quanto o comportamento dos sistemas.

Outro é a necessidade de avaliações contínuas. Testar se um agente consegue concluir uma tarefa não equivale a verificar se consegue executá-la com segurança diante de instruções maliciosas, dados incorretos ou falhas inesperadas. Testes adversariais, regressão comportamental e monitoramento em produção são essenciais, especialmente após mudanças em modelos, ferramentas e processos.

Também é importante distinguir segurança de governança. A primeira busca proteger sistemas e operações contra ameaças e falhas. A segunda estabelece políticas, responsabilidades, critérios de decisão e mecanismos de prestação de contas. São disciplinas complementares que precisam atuar de forma integrada.

Tenho defendido que agentes em produção sejam tratados como componentes de software com identidades, permissões, responsáveis e ciclos de vida definidos, e não como funcionários digitais aos quais simplesmente delegamos atividades.

Isso exige incorporar controles desde a concepção e conceder autonomia progressivamente, conforme a criticidade das tarefas, a maturidade dos mecanismos de proteção e as evidências de confiabilidade obtidas em testes e na operação.

A maturidade de uma empresa em IA não será demonstrada pela quantidade de agentes colocados em produção, mas pela capacidade de operá-los com confiabilidade, resultados mensuráveis, custos sustentáveis e riscos controlados.

A autonomia de um agente nunca deveria exceder a capacidade da organização de limitar suas ações, monitorar seu comportamento e responder às consequências de suas decisões.

Na adoção corporativa da IA, demonstrar capacidade é importante. Demonstrar controle é indispensável.