Agentes com ferramentas: como conceber permissões, memória e recuperação de falhas sem ceder o controlo

De chatbot a agente: autonomia situada, não confiança cega

Um agente não é apenas um assistente que responde numa conversa. Numa definição operacional útil para a conceção, combina um modelo que interpreta uma tarefa com estado de execução, acesso a ferramentas, uma política que delimita as decisões permitidas e um ciclo que observa resultados e decide o passo seguinte. Pode consultar uma base de dados, abrir um ticket, procurar informação, atualizar um registo ou invocar uma API. A diferença relevante não é o modelo “raciocinar”, mas sim o sistema poder afetar outros sistemas para lá da janela de chat.

Esta distinção obriga a mudar a pergunta inicial. Não é conveniente começar por «que modelo tem melhores resultados?», mas por «o que pode este sistema fazer, com que identidade, sobre que recursos e sob que condição?». A capacidade de um modelo pode ajudar a concluir uma tarefa, mas não substitui limites de autorização, validação do resultado nem supervisão. Esta conclusão também é válida ao ler análises de GPT‑6 Astra, Claude Opus 5 ou Gemini 3.8 Flash: uma maior capacidade declarada ou medida não elimina a necessidade de controlos operacionais.

Nem todas as tarefas requerem um agente autónomo. Um fluxo fixo, com passos previsíveis e poucas exceções, pode ser resolvido melhor através de automação convencional ou de um workflow em que o modelo apenas classifica ou redige uma proposta. A autonomia adicional deve ser justificada pela variabilidade da tarefa e pela capacidade de conter os seus efeitos. Como regra de partida, uma ação externa deve ser mais restringida do que uma consulta, e uma alteração difícil de desfazer deve exigir mais evidência e mais supervisão do que uma ação reversível.

O cartão de entrada recomendado para a página matriz é «Agentes: conceção, avaliação e supervisão». A partir daí, este guia deve ser apresentado como um quadro de arquitetura e decisão, e não como uma receita universal nem uma comparação de fornecedores.

Antes de ligar uma ferramenta: classificar o impacto de cada ação

Uma ferramenta não deve ser ativada apenas porque parece útil numa demonstração. Deve ter uma ficha de ação: finalidade, sistemas afetados, dados que recebe, identidade utilizada, operações permitidas, limites de volume, efeito reversível ou irreversível, dependência externa e responsável humano. Esta ficha torna visível uma diferença que costuma ficar escondida: “consultar encomendas” e “cancelar encomendas” podem usar a mesma API, mas não representam o mesmo risco.

A classificação pode combinar quatro eixos. O impacto estima o dano se a ação estiver errada; a reversibilidade determina se pode ser desfeita com segurança; o alcance mede quantas contas, registos ou sistemas podem ser afetados; e a sensibilidade avalia os dados ou segredos expostos. Um quinto eixo prático é a ambiguidade: se o pedido admitir várias interpretações razoáveis, a ação não deverá ser executada de forma autónoma, mesmo que isso seja tecnicamente possível.

As comunicações externas merecem uma categoria própria. Enviar um e-mail a um cliente, publicar uma resposta ou criar uma ocorrência pode ser reversível em sentido técnico, mas não necessariamente em termos reputacionais, contratuais ou de privacidade. O mesmo acontece com alterações em produção: dispor de uma operação de reversão não torna inofensiva uma implementação incorreta. Nestes casos, a conceção deve prever revisão do conteúdo, do destinatário, do alcance e do momento de execução.

No primeiro terço da implementação, é conveniente ligar esta classificação ao guia sobre «ações irreversíveis e aprovações», quando for publicado. O objetivo é que a aprovação não seja um gesto genérico de confirmação, mas uma decisão informada sobre uma ação concreta, os seus parâmetros e as suas possíveis consequências.

Permissões de privilégio mínimo: controlos que não dependem do texto do modelo

O privilégio mínimo consiste em conceder apenas as permissões necessárias para uma tarefa definida, durante o tempo necessário e sobre os recursos necessários. Nos agentes, isto exige ir além de um token geral com acesso amplo. Uma credencial que permite ler, editar e eliminar todos os recursos transforma uma saída errada, uma instrução manipulada ou uma falha de integração num incidente de grande alcance.

Uma prática sólida é separar identidades por ferramenta, ambiente e finalidade. O agente de suporte não deve usar a mesma identidade que o processo de implementação, e uma identidade de testes não deve ter acesso à produção. As credenciais de duração limitada reduzem a janela de exposição, mas não corrigem por si só uma autorização excessiva: também são necessários âmbitos de acesso específicos, quotas, restrições de rede e validação do lado do servidor.

A ferramenta deve verificar a autorização de forma determinística. É preferível uma interface que exponha operações concretas — por exemplo, criar um rascunho de resposta para um caso atribuído — a uma interface genérica que permita executar consultas ou comandos arbitrários. Quando o sistema usar listas de recursos permitidos, montantes máximos ou funções, esses limites devem ser aplicados fora do contexto que o modelo pode modificar. As instruções do prompt podem orientar; não são uma fronteira de segurança suficiente.

Os conectores devem tratar todo o conteúdo recebido de páginas, documentos, e-mails, tickets e respostas de ferramentas como dados potencialmente não confiáveis. O facto de um texto incluir uma ordem não lhe concede autoridade. A política de ações, a identidade de serviço e o validador de parâmetros devem prevalecer sobre qualquer instrução encontrada durante a tarefa.

Esta secção deve ligar, quando existir, a «dados sensíveis e credenciais». Para equipas que tratam dados pessoais, a minimização também implica evitar fornecer à ferramenta mais atributos do que os necessários para concluir a ação e definir quem pode aceder aos registos resultantes.

Quando exigir um humano no circuito

A revisão humana é mais útil quando está integrada num ponto de decisão definido. Pedir confirmação para cada consulta de baixo risco torna o trabalho mais lento e favorece aprovações mecânicas; não a pedir para ações relevantes transfere o ónus de detetar o erro para quem sofre os seus efeitos. A conceção deve fixar limiares explícitos e apresentar à pessoa revisora a informação necessária para decidir.

Uma aprovação deve mostrar a ação prevista, os parâmetros finais, os sistemas afetados, a identidade que a executará, a justificação gerada pelo agente e o efeito de aprovar ou rejeitar. Se a ação depender de factos incertos, a interface deve também mostrar essa incerteza, em vez de apresentar uma recomendação como se fosse uma verificação. Aprovar uma intenção abstrata, como “resolver o caso”, é menos seguro do que aprovar uma operação delimitada, como “enviar este rascunho para este destinatário”.

Devem passar por revisão humana, como ponto de partida, as eliminações, pagamentos ou compromissos económicos, alterações em produção, comunicações externas, modificações de permissões, tratamento de categorias especialmente sensíveis e operações cujo pedido seja ambíguo. A organização pode acrescentar limiares de montante, número de registos ou gravidade operacional. Esses limiares são decisões de política interna: não existe um número universal que torne uma ação segura.

A supervisão humana também não deve ser entendida como uma desculpa para descurar o sistema. A pessoa revisora precisa de autoridade real para rejeitar, corrigir e escalar; formação sobre o processo; e uma carga de trabalho que permita rever. Se receber centenas de pedidos quase idênticos, o controlo pode transformar-se numa formalidade.

Memória útil sem retenção indefinida

A memória pode melhorar a continuidade de uma tarefa, mas também aumenta a superfície de privacidade, o risco de usar informação desatualizada e a dificuldade de corrigir erros. Convém distinguir pelo menos entre contexto de sessão, estado operacional de uma tarefa, preferências persistentes autorizadas, conhecimento recuperado de fontes documentais e registos de auditoria. Estas categorias cumprem finalidades diferentes e não devem partilhar automaticamente a mesma retenção nem as mesmas permissões.

O contexto de sessão serve para manter coerência durante uma interação e costuma expirar no seu final ou após um prazo curto. O estado operacional preserva informação necessária para retomar um trabalho, como uma referência de caso ou um ponto de controlo. As preferências persistentes exigem uma finalidade clara, proveniência conhecida e um mecanismo de consulta e correção. O conhecimento recuperado deve preservar a sua origem, versão e data, para que o sistema possa detetar se a fonte foi substituída ou invalidada.

A proveniência é tão importante quanto o conteúdo. Se uma memória tiver origem num utilizador, num sistema de negócio ou numa inferência do próprio agente, o sistema deve distingui-la. Uma inferência não verificada — por exemplo, uma prioridade ou uma preferência deduzida — não deve ser tratada como um dado confirmado. Além disso, uma memória persistente não deve transformar-se numa via para conservar segredos, dados irrelevantes ou instruções introduzidas por conteúdo externo.

Antes de armazenar, é preciso responder a quatro perguntas: que finalidade concreta cobre, quem pode lê-la, quando expira e como é invalidada. O futuro guia sobre «memória, retenção e expiração» pode desenvolver estas políticas. No âmbito europeu, se a memória contiver dados pessoais, a sua conceção deve ser avaliada no quadro das obrigações aplicáveis de proteção de dados; este guia não substitui a análise jurídica nem determina, por si só, a base de licitude de um tratamento.

Conceber para a falha: parar, verificar e recuperar

As falhas de ferramentas, redes e dependências externas são normais. Também o são as respostas incompletas, os tempos de espera e os estados ambíguos: uma chamada pode ter chegado ao sistema recetor apesar de o agente não ter recebido confirmação. Uma conceção robusta não presume que “tentar novamente” é sempre seguro. Primeiro, deve saber que operação foi tentada, que resultado foi confirmado e que operações podem ser repetidas sem alterar o efeito final.

A semântica HTTP distingue as operações idempotentes, cujo efeito previsto é o mesmo após um ou vários pedidos idênticos, das que não o são. Esta distinção ajuda a conceber novas tentativas, mas não elimina a necessidade de verificar o estado de negócio. Um pedido tecnicamente idempotente pode continuar a ter consequências não previstas se os seus parâmetros estiverem errados. Para operações de criação, pagamento ou envio, uma chave de idempotência e uma consulta de estado antes de tentar novamente costumam ser controlos mais adequados do que repetir cegamente a chamada.

O agente precisa de condições de paragem. Devem ser definidos um número limitado de tentativas, tempos de espera, orçamento de chamadas e critérios de escalamento. Depois de ultrapassar um limiar, o caso deve entrar numa fila de revisão com o contexto mínimo necessário: ação prevista, identificador de correlação, respostas recebidas e passos já efetuados. Tentar novamente indefinidamente pode amplificar uma ocorrência externa ou gerar ações duplicadas.

Toda a ação relevante deve ter um ponto de controlo antes do seu efeito irreversível e, quando viável, um plano de compensação. Uma compensação nem sempre equivale a uma reversão perfeita: devolver um montante não apaga uma comunicação já enviada, e restaurar um registo não elimina uma possível divulgação. A documentação de recuperação deve declarar expressamente esses limites.

Observabilidade e auditoria sem recolher dados desnecessários

A observabilidade permite reconstruir o que aconteceu; não exige conservar sem limite todos os dados trocados. Para uma ação relevante, o registo deve associar o pedido inicial, a política aplicada, as ferramentas escolhidas, os parâmetros autorizados ou uma representação protegida destes, a identidade de execução, o resultado, as novas tentativas e a intervenção humana. Os identificadores de correlação permitem acompanhar um caso entre componentes sem depender de copiar o conteúdo completo em todos os registos.

Os registos devem ser protegidos como um ativo sensível. Se incluírem prompts, respostas, documentos ou parâmetros, podem conter informação pessoal, segredos ou instruções não confiáveis. Por isso, necessitam de controlos de acesso, retenção definida, separação de ambientes e mecanismos que impeçam alterações silenciosas. Também é útil distinguir o registo operacional para detetar falhas do registo de auditoria orientado para investigar uma decisão; podem requerer diferentes níveis de detalhe e acesso.

Uma boa reconstrução separa factos de interpretação. Deve ser possível saber que dado uma ferramenta devolveu, que regra bloqueou ou permitiu uma operação e que recomendação o modelo formulou. Não é razoável prometer uma explicação completa de todo o comportamento do modelo, mas é possível registar a cadeia de decisões programáticas e os artefactos operacionais que determinam se uma ação foi executada.

A minimização não é apenas uma obrigação de privacidade; melhora a segurança e a utilidade dos registos. Um log excessivo dificulta encontrar sinais relevantes e alarga o conjunto de dados expostos perante um acesso indevido.

Avaliar antes da implementação: tarefa, permissões e recuperação

A avaliação deve reproduzir o ambiente de decisão, e não apenas medir a qualidade de uma resposta textual. Um plano mínimo combina tarefas representativas, casos-limite, erros de ferramentas, pedidos ambíguos, tentativas de introduzir instruções através de conteúdo externo e verificações de autorização. O critério de êxito deve incluir tanto concluir corretamente uma tarefa permitida como rejeitar uma ação proibida, parar perante incerteza e escalar quando for adequado.

Os benchmarks são úteis para comparar determinadas capacidades em condições definidas. O Terminal-Bench avalia a resolução de tarefas em ambientes de terminal isolados, enquanto o OSWorld reúne tarefas sobre aplicações web e de ambiente de trabalho em ambientes reais de avaliação. Essas medições podem fornecer sinais sobre o desempenho de um agente nessas tarefas, mas não certificam que a sua identidade tenha permissões corretas, que proteja os dados de uma organização ou que recupere de forma segura numa integração concreta.

Por isso, quando estiverem disponíveis, devem ser incluídas ligações para o Terminal-Bench e o OSWorld com um texto que esclareça que os benchmarks não substituem os testes no ambiente próprio. Os testes internos exigem contas de ensaio, dados sintéticos ou devidamente controlados, simulação de dependências e casos de recuperação. Devem também verificar que uma rejeição de autorização não desencadeia rotas alternativas mais permissivas.

O quadro de gestão de riscos pode ajudar a atribuir responsáveis, documentar decisões e rever controlos ao longo do ciclo de vida. Não substitui a especificação técnica de cada permissão. A evidência de testes, os incidentes e as alterações de ferramentas devem alimentar revisões periódicas da matriz de autonomia.

Modelo final: decidir o nível de autonomia

A decisão de autonomia deve poder ser revista como uma política, e não ficar implícita num prompt. Para cada ferramenta e ação, documente a categoria de risco, os dados envolvidos, a permissão concreta, a identidade, os limites, a necessidade de aprovação, a estratégia de recuperação, os registos e o proprietário. Se algum destes elementos não estiver definido, a autonomia atribuída é provavelmente prematura.

Um ponto de partida razoável é usar quatro níveis. O nível de apenas leitura permite consultar recursos autorizados. O nível de proposta com aprovação permite investigar e preparar uma ação, mas reserva a execução a uma pessoa. O nível de execução limitada ativa operações reversíveis e delimitadas sob regras determinísticas. O nível de execução autónoma fica reservado a ações de baixo impacto, com alcance reduzido, reversão ou compensação conhecida, supervisão disponível e evidência de testes suficientes.

A matriz não deve ser permanente. Um incidente, uma mudança de fornecedor, uma ferramenta nova, uma ampliação dos dados acessíveis ou uma modificação da política de negócio justificam revê-la. Do mesmo modo, um agente pode começar em modo de proposta e ganhar autonomia apenas depois de demonstrar comportamento fiável dentro de um âmbito medido. Reduzir a autonomia após uma anomalia é uma resposta de controlo, não um fracasso do projeto.

Como passo editorial seguinte, o encerramento pode ligar a «decidir se deve automatizar um fluxo». A pergunta decisiva não é se um agente consegue realizar uma tarefa, mas se a organização consegue delimitar, observar e recuperar os seus efeitos com um nível de risco aceitável.

Âmbito e incertezas

Este guia apresenta um quadro técnico e operacional baseado em fontes institucionais, documentação técnica e guias de construção de agentes fornecidos. As suas recomendações de arquitetura não garantem, por si só, a segurança de um caso de utilização nem substituem testes, análise de ameaças, revisão de privacidade, controlos setoriais ou aconselhamento jurídico.

A aplicação do Regulamento Geral sobre a Proteção de Dados depende das circunstâncias do tratamento, das funções das partes e de outros requisitos aplicáveis. Em particular, o guia não determina se um caso concreto se enquadra nas regras sobre decisões individuais baseadas exclusivamente em tratamento automatizado, nem que salvaguardas adicionais são aplicáveis. Também não abrange obrigações nacionais, laborais, financeiras, de saúde ou contratuais que possam ser relevantes.

As características das ferramentas, modelos, APIs e benchmarks mudam rapidamente. Antes da implementação, a equipa deve confirmar a versão avaliada, o comportamento das integrações, as permissões efetivas e as condições de execução. A evidência de um ambiente de testes não deve ser extrapolada automaticamente para a produção.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.