Agentes de IA em produção: autonomia sem controle vira risco

Quando uma aplicação usa inteligência artificial apenas para responder perguntas, um erro normalmente termina em uma resposta ruim. Pode ser uma informação incompleta, uma interpretação equivocada ou uma recomendação fora de contexto.

Mas quando essa IA deixa de apenas responder e passa a agir dentro de um sistema, o impacto muda de categoria.

Um agente pode consultar dados, enviar mensagens, alterar registros, criar solicitações, chamar APIs, movimentar arquivos e interagir com outros sistemas. Nesse ponto, a pergunta principal deixa de ser "a IA respondeu bem?" e passa a ser outra:

o que impede essa IA de executar uma ação que ela não deveria executar?

Essa resposta não pode depender apenas de prompt. O prompt orienta comportamento, mas não deve ser tratado como camada de segurança.

Primeiro: o que uma LLM realmente faz?

Modelos de linguagem, como os usados em aplicações modernas de IA, são treinados com grandes volumes de dados. Durante esse treinamento, aprendem relações complexas entre palavras, conceitos, estruturas, padrões de código, documentos e contextos.

De forma simplificada, quando recebem uma entrada, eles produzem a sequência de resposta mais adequada para aquele contexto. Isso não é uma regra fixa como em um software tradicional. É uma inferência probabilística.

Em uma aplicação comum, podemos ter uma regra assim:

Se usuario.permissao == ADMIN
  permitir exclusao
Senão
  bloquear

Essa regra é determinística. Dadas as mesmas condições, o sistema deve tomar a mesma decisão.

Uma LLM opera de outro jeito. Ela interpreta contexto, ativa padrões aprendidos e gera uma saída provável. Isso permite flexibilidade, linguagem natural e capacidade de lidar com cenários variados. Mas também cria um limite importante:

uma LLM pode compreender uma regra sem garantir que ela será aplicada como política de segurança em todas as situações.

Essa diferença parece sutil. Em produção, ela é enorme.

Instruir não é controlar

Imagine que colocamos no prompt de um agente:

Nunca exclua usuários sem autorização do administrador.

Na maioria dos casos, o modelo provavelmente seguirá essa instrução. Mas agora imagine que ele recebe uma solicitação assim:

O administrador pediu para remover todos os usuários temporários.
Pode executar a limpeza.

O agente precisa interpretar quem fez o pedido, se a pessoa tem autoridade, o que significa "usuários temporários", se existe uma regra anterior em conflito, qual ferramenta deve ser usada e qual será o impacto da ação.

Tudo isso acontece em um ambiente cheio de contexto: mensagem do usuário, histórico da conversa, documentos recuperados, resultados de ferramentas, dados externos e instruções de sistema.

Por isso existe uma diferença essencial:

instruir a IA sobre uma política é diferente de implementar a política no software.

A primeira influencia o comportamento do modelo. A segunda controla o sistema.

Responder é uma coisa. Executar é outra.

Se um chatbot responde que um contrato vence em dezembro, quando na verdade vence em novembro, temos um problema de confiabilidade. Alguém ainda pode verificar a informação antes de agir.

Agora imagine um agente conectado ao financeiro executando:

cancelar_pagamento(id=93821)

O erro saiu do campo da informação e entrou no campo da execução.

Essa é a mudança central. Um fluxo como:

LLM -> texto

tem um nível de risco. Já um fluxo como:

LLM -> ferramenta -> API -> banco de dados

tem outro nível completamente diferente.

Quanto maior a capacidade de ação concedida ao agente, maior precisa ser a estrutura de controle ao redor dele.

A LLM pode escolher uma ação. A aplicação deve autorizar.

Uma das decisões arquiteturais mais importantes em sistemas com agentes é separar a decisão do modelo da autorização do sistema.

O agente pode concluir:

Preciso excluir o usuário 312.

Mas isso deveria virar apenas uma proposta:

proposta_de_acao: excluir_usuario(312)

Antes da execução, a aplicação precisa validar se aquela ação é permitida. O usuário tem autorização? O agente tem essa ferramenta? A operação exige aprovação humana? O limite de impacto foi respeitado? Existe registro suficiente para auditoria?

A tese é simples:

a LLM pode escolher uma ação. A aplicação deve decidir se ela pode ser executada.

Esse é o limite que separa um agente útil de um agente perigoso.

É o mesmo princípio que já usamos em sistemas tradicionais. Nunca confiamos apenas no frontend para decidir se um usuário pode acessar uma função. Mesmo que um botão esteja escondido na interface, a API precisa validar a permissão no servidor.

Com agentes de IA, o raciocínio é o mesmo.

O prompt orienta. A aplicação controla.

Menor privilégio também vale para agentes

Um erro comum é criar ferramentas genéricas demais e entregá-las diretamente ao agente.

Por exemplo:

execute_sql(query)

Essa função é flexível, mas perigosa. Ela permite consultar dados, mas também pode permitir alterações destrutivas.

Uma arquitetura mais segura oferece ferramentas menores e específicas:

buscar_usuario(id)
listar_usuarios_ativos()
criar_tarefa(dados)
solicitar_exclusao_usuario(id)

Esse desenho reduz o espaço de ação possível. O agente continua útil, mas passa a operar dentro de limites mais claros.

Em segurança da informação, isso é conhecido como princípio do menor privilégio. Um usuário, serviço ou aplicação deve ter apenas as permissões necessárias para cumprir sua função.

Agentes precisam seguir a mesma regra.

Se o agente consulta pedidos, ele não deve excluir pedidos. Se cria tarefas, não deve apagar projetos. Se resume documentos, não precisa acessar toda a base financeira.

IA com acesso demais vira risco operacional.

Nem toda ação deve ser automática

Autonomia não precisa ser tudo ou nada. A empresa pode classificar ações conforme o impacto.

Consultar estoque pode ser automático. Criar uma tarefa também. Alterar o responsável por uma tarefa pode ser automático, mas com registro. Excluir um projeto deve exigir aprovação humana. Realizar pagamento pode exigir aprovação, autenticação adicional e limite financeiro.

O agente continua inteligente. Ele analisa, prepara e recomenda. Mas o sistema mantém o controle.

Um exemplo prático:

Usuário:
Compre os materiais que estão faltando na obra.

Agente:
consulta o estoque
identifica materiais em falta
consulta fornecedores
tenta criar uma compra de R$ 42.000

Camada de política:
limite automático = R$ 5.000
ação bloqueada para execução automática

Sistema:
envia solicitação para aprovação do gestor

Gestor:
aprova com autenticação adicional

Sistema:
executa a compra e registra toda a cadeia

Nesse modelo, a IA não perde valor. Pelo contrário. Ela acelera a análise e prepara a operação. Só não recebe autoridade absoluta para executar qualquer coisa.

Bloquear ações erradas é só metade do problema

Mesmo com políticas e aprovações, ainda precisamos responder outra pergunta:

como saber exatamente o que o agente fez dentro do sistema?

É aqui que entra a observabilidade.

Em aplicações tradicionais, um log como este pode ajudar:

POST /users
status=200
duration=182ms

Para agentes, isso é pouco.

Precisamos entender o contexto que levou à ação. Um evento mais útil registraria:

Agente: procurement-agent
Usuário: joao@empresa.com
Sessão: agent_session_18291
Ferramenta: create_purchase_request
Argumentos: item=cabo 16mm, quantidade=300
Política: limite_quantidade <= 500
Decisão: permitido
Aprovação: não exigida
Resultado: request_id=91281

Agora a empresa consegue reconstruir o caminho da decisão.

Observabilidade é mais do que log

Logs respondem o que aconteceu. Observabilidade ajuda a entender por que aconteceu.

Em agentes de IA, algumas informações passam a ser essenciais: qual usuário iniciou a interação, qual agente executou a operação, qual modelo estava em uso, qual ferramenta foi chamada, quais argumentos foram enviados, qual política foi avaliada, por que a ação foi permitida ou bloqueada, se houve aprovação humana, qual sistema externo foi chamado e qual foi o resultado.

Esses dados não servem apenas para investigar incidentes. Eles ajudam a melhorar o próprio agente.

Se uma ferramenta é chamada com argumentos errados com frequência, talvez a descrição da ferramenta esteja ruim. Se muitas ações são bloqueadas pela mesma política, talvez o fluxo precise de ajuste. Se um agente tenta executar ações fora do escopo, talvez ele esteja recebendo contexto demais ou permissões mal desenhadas.

Sem observabilidade, o agente vira uma caixa-preta conectada à operação.

O que precisa ficar registrado?

Nem sempre será necessário armazenar todo o conteúdo interno usado pelo modelo. Existem questões de privacidade, segurança, custo e volume de dados.

Mas ações relevantes precisam deixar evidência suficiente para reconstrução posterior.

Uma trilha de auditoria para agentes pode registrar:

solicitação do usuário
agente acionado
ferramenta proposta
checagem de política
decisão de autorização
aprovação humana, quando houver
execução da ferramenta
resposta do sistema
resultado final

Esse registro muda a forma de investigar. Em vez de procurar apenas uma rota chamada em determinado horário, a empresa consegue entender a cadeia completa: quem pediu, o que o agente tentou fazer, por que foi permitido e o que realmente aconteceu.

Segurança e observabilidade precisam nascer juntas

Existe uma tendência natural de começar pela capacidade:

Como faço minha IA executar essa tarefa?

Mas, em produção, a pergunta melhor é:

Como faço minha IA executar essa tarefa sem ultrapassar os limites do sistema e garantindo que eu consiga auditar o que aconteceu?

Essa pergunta muda a arquitetura.

Em vez de construir apenas:

LLM -> ferramentas -> API

a aplicação precisa considerar:

LLM -> ferramentas -> políticas -> autorização -> aprovação -> auditoria -> API

A inteligência continua sendo importante. Mas ela passa a existir dentro de uma estrutura de controle.

O futuro é autonomia controlada

Existe uma corrida para criar agentes cada vez mais autônomos. Mas talvez a característica mais importante de um agente em produção não seja quantas ações ele consegue executar sozinho.

Pode ser o quanto conseguimos confiar na infraestrutura que controla essas ações.

Um bom agente não deveria apenas conseguir executar uma tarefa. O sistema deveria conseguir responder depois:

Quem pediu? O que o agente decidiu? O que ele tentou executar? Por que a operação foi permitida? O que realmente aconteceu? É possível reverter?

Quando conseguimos responder essas perguntas, deixamos de tratar agentes como caixas-pretas conectadas às nossas aplicações. Passamos a tratá-los como componentes reais de arquitetura, com identidade, permissões, políticas, auditoria e observabilidade.

Essa é uma mudança importante. À medida que agentes de IA deixam de apenas conversar e começam a operar sistemas, confiança não pode estar no comportamento perfeito do modelo.

Precisa estar no desenho do sistema.