Agentes de IA dentro dos seus sistemas: o que um agente pode fazer sozinho, o que uma pessoa precisa aprovar e como começar sem perder o controle

Um agente de IA é um modelo de linguagem que pode pedir ao seu software que execute funções, ou seja, ações como consultar um pagamento, atualizar um ticket ou emitir um reembolso. O modelo só faz o pedido. São os seus sistemas que decidem se o executam, e é aí que você mantém o controle. Comece com uma tarefa restrita, em que o agente lê dados e prepara rascunhos sozinho. Uma pessoa designada aprova tudo o que movimenta dinheiro, altera o cadastro de um cliente ou sai da empresa.

O que é um agente de IA, em palavras simples?

Um modelo de linguagem, o tipo de IA por trás do ChatGPT, produz texto. Um agente é um modelo de linguagem conectado a funções dos seus sistemas, então o resultado dele pode ser uma ação, e não só uma resposta.

A documentação da Anthropic para os seus modelos Claude diz: “O uso de ferramentas (também chamado de function calling) permite que o Claude chame funções que você define ou que a Anthropic fornece.” Para as funções que você define, o modelo “retorna uma chamada estruturada que a sua aplicação executa”. Ele escreve o pedido, e o seu software o executa ou o recusa. Todas as fontes deste artigo foram consultadas em 2 de novembro de 2026.

Um agente repete isso em loop. Ele chama uma função, lê o resultado e escolhe o próximo passo até a tarefa terminar. Uma publicação de 2024 no blog de engenharia da Anthropic descreve os agentes como “normalmente apenas LLMs usando ferramentas com base no feedback do ambiente, em loop.” LLM é a sigla em inglês de modelo de linguagem grande, e as ferramentas são as funções que ele pode chamar.

Portanto, um agente só pode fazer o que as funções dele permitem. A lista de funções é a descrição de cargo dele, e é o primeiro documento a pedir.

Por que importa se o agente lê dados ou os altera?

Porque ler não altera nada. Se o agente puxa os últimos cinco pagamentos de um cliente e erra um deles, o resultado é um rascunho errado, que uma pessoa consegue pegar.

Escrever altera algo fora do modelo: um reembolso é pago ou um e-mail chega a um cliente. Algumas dessas alterações não podem ser desfeitas.

O guia da OpenAI para construir agentes sugere classificar cada função como de risco baixo, médio ou alto “com base em fatores como acesso somente leitura versus escrita, reversibilidade, permissões de conta necessárias e impacto financeiro.” Ler continua sendo de baixo risco apenas enquanto o agente não puder enviar o que leu para lugar nenhum. A seção sobre injeção de prompt, um truque que planta instruções em um e-mail ou documento, mostra por quê.

Quais ações o agente pode realizar sozinho, e quais precisam de uma pessoa?

Separe cada função em um de três grupos:

• O agente sozinho: ler dados, buscar em documentos, etiquetar e escrever rascunhos que ficam dentro dos seus sistemas até que alguém os use
• O agente propõe, uma pessoa aprova: tudo o que movimenta dinheiro, altera o cadastro ou a situação de um cliente, ou envia uma mensagem para fora da empresa
• Nunca: alterações de direitos de acesso, de limites ou de dados bancários, e decisões que o seu regulador espera que uma pessoa designada tome

Quatro perguntas definem o grupo da maioria das funções:

• A ação pode ser desfeita, e por quem?
• Movimenta dinheiro ou altera o que um cliente deve?
• Um cliente, um parceiro ou um regulador vai ver o resultado?
• Uma lei, uma condição da licença ou a sua própria política diz que uma pessoa precisa decidir?

O guia da OpenAI dá o mesmo conselho para o grupo do meio: “Ações sensíveis, irreversíveis ou de alto impacto devem acionar a supervisão humana até que a confiança na confiabilidade do agente aumente.” Os exemplos dele incluem “cancelar pedidos de usuários, autorizar reembolsos grandes ou fazer pagamentos.”

O OWASP Top 10 for LLM Applications 2025, uma lista de riscos publicada pelo projeto de segurança OWASP, tem um item chamado agência excessiva (excessive agency). Ele trata do dano que um agente pode causar quando tem mais funções, direitos ou liberdade do que a tarefa exige. Um dos controles que ele lista é “exigir que um humano aprove as ações de alto impacto antes que sejam executadas.”

Como isso fica no suporte, no onboarding, nos pagamentos e nos relatórios?

Em cada área, o agente lê e redige, e as decisões ficam com uma pessoa. A sua própria lista depende dos seus sistemas e do que o seu regulador espera.

• Suporte: o agente etiqueta os tickets e redige respostas. No início, uma pessoa aprova cada resposta, e reembolsos e isenções de taxas sempre precisam de aprovação. O agente nunca altera o e-mail ou o telefone de um cliente, já que quem os controla consegue redefinir o login do cliente
• Onboarding: o agente verifica se faltam campos nos documentos e os resume para o analista. Uma mudança na classificação de risco aguarda aprovação, e a aceitação de um cliente continua com uma pessoa
• Pagamentos: o agente casa as linhas do extrato bancário com as faturas e sinaliza o que não bate. Liberar um pagamento retido aguarda aprovação, e os dados bancários de um beneficiário nunca podem ser alterados pelo agente
• Relatórios: o agente redige o relatório mensal com a fonte de cada número. Uma pessoa aprova tudo o que é enviado a um cliente, ao conselho ou a um regulador

Onde deve ficar a etapa de aprovação?

Coloque a aprovação no software que executa a função, e não apenas no prompt, que é o conjunto de instruções que o modelo recebe. Um modelo pode ignorar uma linha do prompt ou ser convencido a desobedecê-la. Uma função de reembolso que não roda sem o clique de um aprovador não pode ser convencida de nada.

A orientação do OWASP concorda: “Implemente a autorização nos sistemas a jusante, em vez de depender de um LLM para decidir se uma ação é permitida ou não.”

Uma tela de aprovação útil mostra ao aprovador:

• A ação, o registro que ela altera e o valor
• O registro antes e depois da alteração
• As evidências que o agente usou, como o ticket ou a linha do extrato
• Um motivo obrigatório sempre que o aprovador rejeita

Se todas as propostas são aprovadas em segundos, as pessoas pararam de conferir. O AI Act da UE tem um nome para isso: viés de automação. O artigo dele sobre supervisão humana diz que as pessoas que supervisionam um sistema de alto risco precisam ser capazes de se manter conscientes da “possível tendência para confiar automaticamente ou excessivamente no resultado”. Reconfira toda semana uma amostra das ações aprovadas.

Que direitos a conta do agente deve ter?

A conta do agente deve permitir as funções da lista dele e nada mais. Dê a cada agente uma conta própria em cada sistema que ele acessa, nunca uma conta de administrador ou o login de um funcionário. Defina esses direitos no próprio sistema, onde o modelo não consegue alterá-los. Senhas e chaves ficam no seu software, fora da vista do modelo.

O exemplo do OWASP é um agente que recomenda produtos e “talvez só precise de acesso de leitura a uma tabela 'products'”. Ele também alerta contra funções abertas, como executar qualquer comando em um servidor, e prefere funções restritas, cada uma fazendo uma única coisa.

Quando o agente trabalha para um único funcionário, ele deve agir “no contexto desse usuário específico e com os privilégios mínimos necessários”, nas palavras do OWASP. Assim, ele não consegue ver nem fazer mais do que essa pessoa.

O que é injeção de prompt, e por que ela importa mais para agentes?

Injeção de prompt (prompt injection) significa plantar instruções em um texto que o agente lê, como um e-mail, um ticket ou um documento enviado. O modelo pode segui-las como se tivessem vindo de você. As instruções podem ficar ocultas para um leitor humano, e, com um agente, podem virar ações. O OWASP coloca a injeção de prompt em primeiro lugar na sua lista de 2025 e diz que “não está claro se existem métodos infalíveis de prevenção contra a injeção de prompt.”

O item do OWASP sobre agência excessiva descreve um assistente que lê uma caixa de e-mail para resumir as mensagens recebidas. O complemento que ele usa também consegue enviar e-mails. Um e-mail preparado de propósito engana o assistente para que ele procure informações sensíveis na caixa de entrada e as encaminhe ao atacante.

As correções do OWASP começam com uma função que só consegue ler e-mails e com acesso somente leitura à caixa de e-mail. Uma pessoa também precisa “revisar manualmente e clicar em 'enviar' em cada e-mail redigido pela extensão de LLM.” Como a injeção de prompt não pode ser descartada, planeje para o caso de o agente ser enganado e mantenha pequeno o dano que ele pode causar.

O que devemos registrar em log, e como desfazemos um erro?

Registre em log cada chamada de função. Cada entrada mostra o agente, a função e os dados de entrada dela, o resultado, o texto que levou à chamada, o modelo e a versão do prompt, e quem aprovou e quando. Alguém de fora do time que construiu o sistema deve conseguir ler o log e dizer o que aconteceu com um determinado cliente.

O OWASP observa que logs e limites de taxa não impedem a agência excessiva, “mas podem limitar o nível de dano causado”. Um limite de taxa restringe quantas ações de um mesmo tipo o agente pode realizar em um determinado período, então uma sequência de ações ruins para cedo.

Antes do lançamento, registre por escrito como cada função que altera dados é desfeita e quem faz isso. Prefira funções que criam algo pendente, como um reembolso aguardando em uma fila. Um item pendente pode ser apagado, enquanto um pagamento enviado é difícil de recuperar. Tenha um interruptor que desliga de uma só vez as funções do agente, sem precisar lançar uma nova versão do software, e teste-o antes da entrada em produção.

A lei diz que uma pessoa precisa aprovar?

Na UE, o AI Act define regras de supervisão humana para os sistemas de IA que classifica como de alto risco. Essas regras estão no artigo 14, e o Anexo III lista os usos de alto risco. A lista inclui avaliar a capacidade de crédito de pessoas físicas ou definir a pontuação de crédito delas, embora os sistemas que detectam fraude financeira fiquem de fora. Ela também inclui a avaliação de riscos e a precificação para pessoas físicas em seguros de vida e de saúde. O AI Act Service Desk da Comissão Europeia indica 2 de dezembro de 2027 como a data a partir da qual se aplicam as regras para os sistemas de alto risco do Anexo III. Essa data reflete as mudanças feitas pelo Digital Omnibus on AI. Datas como essa podem mudar, então confira o cronograma atual antes de planejar em torno dele.

O artigo 14 diz que as medidas de supervisão “devem ser proporcionais aos riscos, ao nível de autonomia e ao contexto de utilização” do sistema. As pessoas que o supervisionam precisam ser capazes de “decidir, em qualquer situação específica, não utilizar o sistema de IA de alto risco ou ignorar, anular ou reverter de outro modo o resultado”. Elas também precisam conseguir pará-lo com “um botão de ‘parar’ ou um procedimento semelhante”.

Essas regras se aplicam apenas aos sistemas de alto risco que o AI Act lista, e muitos agentes de suporte e de operações não estarão entre eles. Os mesmos controles continuam fazendo sentido para esses agentes. Saber se o seu sistema se enquadra nas regras é uma questão para os seus advogados. Este artigo não é aconselhamento jurídico e trata apenas das regras da UE.

Como começamos sem perder o controle?

Comece perguntando se a tarefa precisa mesmo de um agente. A publicação de engenharia da Anthropic recomenda “encontrar a solução mais simples possível e só aumentar a complexidade quando necessário”, e acrescenta: “Isso pode significar não construir sistemas agênticos de forma alguma.” Para muitas tarefas, uma única requisição ao modelo ou uma sequência fixa de etapas resolve. Uma sequência fixa também se comporta de forma mais previsível do que um agente que escolhe os próprios passos.

Escolha um fluxo de trabalho com muitos casos por semana, regras claras e erros baratos de corrigir, como classificar tickets de suporte e redigir respostas. Depois avance em etapas:

• Meça o fluxo de trabalho como ele funciona hoje: tempo por caso, a parcela de casos refeitos e o backlog semanal
• Rode o agente em modo sombra (shadow mode) com casos reais. Ele propõe, as pessoas trabalham como antes, e você compara os dois
• Passe para o modo de aprovação, em que uma pessoa aprova cada ação, e registre com que frequência os aprovadores editam ou rejeitam
• Deixe o agente agir sozinho apenas nos tipos de ação com menos correções, e continue conferindo uma amostra semanal

Combine com antecedência quais números levam o agente à etapa seguinte e quem decide. O guia da OpenAI termina com: “Comece pequeno, valide com usuários reais e amplie as capacidades ao longo do tempo.” A publicação da Anthropic recomenda “testes extensivos em ambientes de sandbox”, ou seja, uma cópia dos seus sistemas em que os erros não custam nada.

O que devemos verificar antes de o agente entrar em produção?

• Cada função está em um dos três grupos e tem um responsável designado do seu lado
• Alguém tentou uma ação proibida com a conta do agente em cada sistema e viu que ela falhou
• Tickets e documentos com instruções plantadas passaram pelo agente, e nada aconteceu fora do que os grupos permitem
• Para qualquer cliente, o log mostra o que o agente fez e quem aprovou
• Uma nova versão do modelo só entra em produção depois que os mesmos testes rodam de novo

Quem é o dono do código, dos prompts e dos logs?

A sua empresa deve ser a dona, e o contrato deve dizer isso. O código é só uma parte do agente. Os prompts, a lista de funções, as regras de aprovação e os casos de teste decidem como ele se comporta. Liste todos eles como entregáveis, guardados em um armazenamento que a sua empresa controla.

Os logs contêm dados de clientes, então precisam das mesmas regras de acesso e do mesmo prazo de retenção dos registros que descrevem. Se o modelo roda em um provedor externo, pergunte se esse provedor guarda o que o agente envia a ele, e por quanto tempo.

O que devemos perguntar a uma empresa que o construiria?

• Podemos ver cada função que o agente vai chamar, com o grupo em que cada uma está?
• Onde as aprovações são garantidas: nos nossos sistemas, no código de vocês ou só no prompt?
• Que conta o agente usa em cada sistema, e como vocês testaram que ele não consegue fazer mais do que isso?
• Como vocês fazem testes de injeção de prompt, e o que acontece quando um teste é bem-sucedido?
• O nosso time de compliance consegue ler o log sem a ajuda de vocês?
• Como cada ação é desfeita, e com que rapidez conseguimos desligar o agente?
• O que será nosso no fim: o código, os prompts, as definições de funções, os casos de teste e os logs?

Onde a amBrain se encaixa?

A amBrain usa agentes no seu próprio produto. A frase dela sobre esse produto diz: “Nosso produto próprio, o shyash.ai, roda em agentes de IA que pesquisam, escrevem, verificam e medem a partir de uma memória compartilhada dos fatos da empresa. Uma pessoa aprova tudo o que sai.”

O único projeto de cliente com modelo de linguagem que a amBrain descreve publicamente é este: “Levamos à produção uma integração de LLM dentro do perímetro de FinTech de um cliente: extração e normalização de avisos não estruturados de corretoras e de venues — eventos corporativos, alterações de instrumentos e de margem — em registros estruturados que o sistema de trading consome.”

Este artigo não é um estudo de caso e não descreve nenhum trabalho para clientes além da frase acima. Essa frase não diz nada sobre agentes ou aprovações, e o artigo não diz que a amBrain constrói sistemas de agentes para clientes. Os exemplos de suporte, onboarding, pagamentos e relatórios são gerais, não tirados do trabalho da amBrain.

As empresas e organizações mencionadas aqui são citadas com base nas páginas que publicaram. O artigo não afirma nenhuma relação entre a amBrain e qualquer uma delas e não traz preços nem prazos da amBrain.

A amBrain constrói software desde 2019. Ela trabalha em três formatos: entrega completa, time dedicado ou engenheiros embarcados no seu time. A frase dela sobre propriedade é: “O cliente mantém a propriedade integral do produto e do código, exceto dos nossos componentes reutilizáveis.” As perguntas acima valem para qualquer empresa que você esteja considerando.