Guardrails para agentes AI em produtos B2B: o que tem de existir

Por que agentes AI empresariais precisam de controlos diferentes

Um chatbot que responde perguntas tem risco limitado: no pior caso, dá uma resposta errada. Um agente que executa acções — envia emails, actualiza registos, faz chamadas a APIs externas — tem um perfil de risco completamente diferente.

Em contexto B2B, as consequências de um agente a comportar-se mal incluem: exposição de dados de clientes, acções irreversíveis em sistemas críticos, e violações de compliance regulatório. Não é hype — é engenharia de sistemas.

Este artigo cobre o conjunto mínimo de guardrails que qualquer produto B2B com agentes AI deve implementar antes de ir para produção.

Camada 1: Definição clara de scope e permissões

O primeiro guardrail é arquitectural: o agente só deve ter acesso ao que precisa para a sua função. Princípio do mínimo privilégio aplicado a AI.

Na prática: um agente de suporte ao cliente não deve ter permissões de escrita na base de dados de pagamentos. Um agente de análise de contratos não deve conseguir enviar comunicações externas. As permissões definem-se antes do código do agente.

Implementa este controlo a nível de infra (OAuth scopes, API keys com permissões restritas, row-level security) e não apenas como instrução de sistema prompt — instruções podem ser contornadas, controlos de acesso a nível de infra não.

Camada 2: Validação de input antes de chegar ao modelo

Tudo o que o utilizador envia ao agente deve ser validado antes de entrar no contexto do modelo. Isto inclui:

• Sanitização básica: comprimento máximo, caracteres proibidos, formato esperado
• Detecção de prompt injection: padrões conhecidos de tentativas de manipulação de instruções
• Classificação de intenção: o pedido está dentro do escopo definido para o agente?
• Filtragem de PII: impedir que dados sensíveis sejam enviados desnecessariamente ao modelo

Camada 3: Validação de output antes de executar qualquer acção

Um agente pode decidir executar uma tool call — chamar uma API, escrever num ficheiro, enviar uma mensagem. Esta decisão deve ser validada antes de ser executada.

O padrão mais robusto: structured output com schema estrito para tool calls. O agente não pode invocar uma ferramenta que não está no schema definido, nem com argumentos fora dos valores permitidos.

Para acções com efeitos permanentes, implementa uma camada de 'dry run' que valida o que ia acontecer sem executar de facto, e regista a decisão para auditoria.

Camada 4: Human-in-the-loop para acções de alto risco

Define explicitamente quais acções requerem aprovação humana antes de executar. A classificação de risco deve ser do produto, não do modelo.

Um framework simples para classificar:

• Verde (automação total): acções de leitura, geração de rascunhos, análise sem output externo
• Amarelo (confirmação implícita): acções reversíveis com impacto limitado — o utilizador confirma antes de executar
• Vermelho (aprovação explícita): envio de emails externos, pagamentos, deleção de dados, chamadas a APIs de terceiros com efeitos permanentes

Camada 5: Logging e rastreabilidade completa

Em contexto B2B, 'o agente fez isto' não é resposta suficiente para um cliente ou regulador. Precisas de uma trilha completa: que prompt foi usado, que contexto estava disponível, que decisão o modelo tomou, e que acção foi executada.

O mínimo viável de logging para agentes em produção:

• ID de sessão e de request ligados ao utilizador e ao contexto de negócio
• Snapshot do prompt completo (com contexto injectado) para cada execução
• Tool calls tentadas e executadas com os argumentos reais
• Latência e tokens por step para diagnóstico de custo e performance
• Erros e fallbacks activados

Camada 6: Rate limiting e circuit breakers

Agentes autónomos podem entrar em loops — um bug de lógica, um caso edge inesperado, ou um utilizador malicioso pode levar o agente a executar centenas de acções em segundos.

Implementa limites explícitos: máximo de tool calls por sessão, máximo de chamadas externas por minuto, e um circuit breaker que para o agente e alerta uma pessoa quando um threshold é atingido.

Este controlo é trivial de implementar e evita incidentes de custo e de dados que são difíceis de reverter.

O que não é guardrail

Importante distinguir: instrução no system prompt ('nunca faças X') não é um guardrail — é uma sugestão que o modelo pode ignorar, especialmente sob adversarial input. Guardrails reais são controlos fora do modelo: validação de schema, permissões de acesso, aprovações humanas, rate limiting.

Um sistema seguro não depende de o modelo obedecer a instruções. Depende de a arquitectura tornar acções problemáticas impossíveis de executar, independentemente do que o modelo decida.