Os agentes de IA precisam de sistemas de permissões, não de melhores prompts: guia para fundadores

A maioria das falhas de agentes de IA não começa com um modelo fraco. Começa quando se dá a um modelo capaz uma chave de API com permissões amplas, uma instrução ambígua e autorização para agir. O agente funciona na perfeição numa demo, chega depois à produção e pode enviar um e-mail ao cliente errado, alterar um registo que só devia ler ou fazer uma alteração cara sem um responsável humano claro.

Um prompt melhor ajuda o agente a escolher o passo seguinte. Não decide o que o agente está autorizado a fazer. Isso é um problema de produto e de desenho de sistemas. Os fundadores que conseguem levar agentes em segurança para fluxos de trabalho reais tratam as permissões como uma camada de primeira linha: identidade, privilégio mínimo, pontos de aprovação e um registo de auditoria para cada ação com consequências.

A mudança essencial: das instruções à autoridade

Um prompt de sistema pode dizer «emite apenas reembolsos abaixo de $100». Mas um prompt não é uma fronteira de autorização nem um registo duradouro da intenção. A ferramenta que emite o reembolso tem de aplicar por si própria o montante, o âmbito da conta e a política de aprovação. Parta do princípio de que o agente pode interpretar mal um texto, seguir um documento não fiável ou receber um pedido inesperado. As suas ferramentas têm de continuar a dizer que não.

• Dê a cada agente uma identidade própria. Não faça passar os fluxos de suporte, finanças e engenharia por uma única credencial de serviço partilhada. A identidade torna possíveis a política, a revogação e a investigação.
• Associe as permissões ao trabalho, não ao modelo. Uma mudança de modelo não deve alargar o acesso em silêncio. Defina o que um agente de «triagem de suporte» pode ler e escrever e associe essa política ao modelo que executar a tarefa, seja ele qual for.
• Torne a camada de ferramentas a autoridade final. A API ou função que executa a ação verifica o âmbito, a propriedade do recurso, os limites e as aprovações antes de alterar o que quer que seja.

Um modelo de permissões que funciona para um MVP

Não precisa de uma enorme plataforma de governação para começar. Use um modelo de capacidades compacto: cada chamada a uma ferramenta leva uma identidade de agente, uma ação específica, um âmbito de recursos definido e uma data de expiração. O serviço de autorização avalia esses dados antes de o sistema de destino ver o pedido.

1. Separe ler, redigir e executar. Deixe um agente pesquisar registos e preparar um rascunho antes de ganhar a capacidade de enviar, publicar, apagar ou cobrar. Muitos fluxos valiosos nunca precisam de acesso direto de escrita.
2. Restrinja o acesso a um cliente e a uma tarefa. Um agente de suporte que trata de uma conta não deve poder percorrer todos os clientes. Um assistente de implementação deve operar num único ambiente, e nunca em produção por omissão.
3. Use credenciais de curta duração. Crie um token restrito quando uma execução começa e faça-o expirar quando a tarefa termina. Isto limita tanto a reutilização acidental como o raio de impacto de uma credencial divulgada.
4. Coloque em lista de permissões as ferramentas e os intervalos de parâmetros. Um agente pode chamar create_draft, não um executor genérico de base de dados. Uma ferramenta de reembolsos pode permitir de $0 a $100, em vez de depender de o agente se lembrar do limite.

Desenhe os pontos de aprovação em função das consequências

A revisão humana não é um fracasso da automação. É a forma de automatizar em segurança enquanto aprende onde devem ficar os limites. O essencial é reservar a revisão para ações cujas consequências sejam irreversíveis, financeiramente relevantes, visíveis externamente ou difíceis de corrigir, e não obrigar uma pessoa a aprovar cada passo inofensivo.

• Aprove automaticamente as ações de baixo impacto. Classificar um pedido recebido, enriquecer um registo do CRM ou redigir uma resposta pode correr sem supervisão quando o âmbito é restrito e reversível.
• Exija uma decisão de um clique para ações externas. Enviar um e-mail a um cliente, publicar conteúdo, alterar preços ou iniciar um pagamento deve apresentar a ação proposta pelo agente, e as respetivas evidências, a um aprovador identificado.
• Escale por limiares. Defina regras claras: reembolsos acima de um determinado valor, exportações acima de um certo número de registos e alterações em produção exigem uma aprovação mais rigorosa. A política deve ser legível para quem opera o sistema.

O registo de auditoria é uma funcionalidade do produto

Registe mais do que a transcrição do chat. Para cada ação, guarde a identidade do agente, o utilizador que a iniciou, o nome da ferramenta, as entradas depuradas, a decisão da política, o estado da aprovação, o resultado e um ID de correlação da execução. Quando um cliente perguntar porque é que uma alteração aconteceu, é isto que distingue um produto explicável de uma caixa negra.

Estes registos tornam-se também os seus dados operacionais. Reveja todas as semanas as chamadas recusadas, as aprovações anuladas e os casos-limite repetidos. Mostram onde melhorar o agente, onde apertar a política e que pontos de aprovação estão suficientemente maduros para serem automatizados.

Uma implementação em quatro semanas para fundadores

1. Semana 1: escolha um fluxo restrito e mapeie todas as ações de leitura e escrita que pode executar. Remova qualquer ferramenta que não seja necessária.
2. Semana 2: acrescente uma identidade de agente própria, credenciais restritas por cliente, listas de ferramentas permitidas e registos estruturados de ações.
3. Semana 3: execute o fluxo em modo de rascunho. Meça a taxa de aprovação, as edições, as falhas e os pedidos que a política recusa.
4. Semana 4: aprove automaticamente apenas o caminho de baixo risco e alta confiança. Mantenha as ações com consequências atrás de um ponto de aprovação humana rápido até que os dados justifiquem mais autonomia.

Conclusão

Os agentes em produção precisam de uma resposta clara a duas perguntas distintas: o que deve este agente fazer, e o que está autorizado a fazer? Os prompts respondem à primeira. Os sistemas de permissões respondem à segunda. Construa a fronteira cedo, torne-a visível para a sua equipa e para os seus clientes, e o seu agente poderá ganhar autonomia sem perder confiança.

Quer ajuda para desenhar um fluxo de agentes capaz de chegar à produção em segurança? Marque uma chamada de descoberta gratuita: ajudamos os fundadores a transformar demos de IA em produtos fiáveis.

Related Posts

Porque é que a IA é difícil: os problemas reais com que os fundadores se deparam depois de a demo funcionar1 de julho de 2026

O comando /loop do Claude Code: como usá-lo para fluxos de programação mais inteligentes em 20263 de julho de 2026

O stack multimodelo: como as startups estão a cortar 85% nos custos de programação com IA em 20268 de julho de 2026