Guardrails para agentes de IA: o que são, os principais tipos e onde cada um precisa ficar

“Guardrails” virou a resposta padrão para toda pergunta sobre risco de agentes de IA, e a palavra hoje quer dizer quase qualquer coisa. Para um time, é um filtro de conteúdo na saída do modelo. Para outro, é um parágrafo no system prompt dizendo ao agente o que não fazer. Para um terceiro, é a tela de permissões da plataforma de agentes. Os três são guardrails. Eles não protegem contra as mesmas coisas, e só alguns sobrevivem a um agente que foi manipulado.

Este guia organiza os principais tipos, com exemplos de produtos e casos que já analisamos, e termina com o teste que separa um controle de verdade de uma instrução esperançosa.

O que é um guardrail de agente de IA

Um guardrail é qualquer controle que limita o que um agente de IA pode dizer ou fazer, ou quanto pode fazer, independentemente do que pediram a ele. A distinção útil é onde o controle roda:

• Dentro do raciocínio do agente: instruções no prompt, regras que pedimos ao modelo para seguir. O agente lê essas regras, então pode ser convencido a ignorá-las.
• Em volta do modelo: filtros que inspecionam entradas e saídas, como temas bloqueados, detecção de dados sensíveis ou checagens de que a resposta se apoia nas fontes.
• Fora do agente: controles que o agente não vê nem consegue mudar, aplicados pelo sistema operacional, pelo runtime, por um gateway, por um sistema de identidade ou por uma pessoa.

Onde ficam os guardrails de agentes, do mais forte ao mais fraco contra manipulação

Identidade e permissões

• Em nome de quem o agente age
• O que as credenciais dele alcançam

Aplicado pelos sistemas de registro

Contenção no runtime

• Arquivos, rede e processos que o agente toca

Aplicado pelo sistema operacional ou runtime

Gateway de ferramentas e modelos

• Quais ferramentas e modelos, com que frequência, a que custo

Aplicado em cada chamada

Filtros de entrada e saída do modelo

• Temas bloqueados, dados sensíveis, checagem de fontes

Instruções no prompt

• Regras que pedimos ao agente para seguir

O agente lê, então pode ser convencido a ignorar

Os principais tipos, com exemplos

1. Instruções de prompt e de política. O system prompt diz “nunca compartilhe dados de clientes” ou “responda só perguntas de RH”. Barato, útil para comportamento e tom, e não é um controle de segurança: um prompt injection num documento que o agente lê pode passar por cima. Explicamos por que em guardrails de prompt não são fronteira de segurança.

2. Filtros de entrada e saída do modelo. Produtos como o Amazon Bedrock Guardrails e o NeMo Guardrails, open source da NVIDIA, verificam prompts e respostas em busca de temas proibidos, conteúdo nocivo ou dados sensíveis, e podem checar se uma resposta se apoia nas fontes. Bons para risco de conteúdo; cegos para o que o agente faz com as ferramentas.

3. Contenção no runtime. O sistema operacional ou o runtime limita quais arquivos, redes e processos o agente alcança. Exemplos: os Execution Containers da Microsoft no Windows e o OpenShell da NVIDIA, que a ServiceNow usa para governar o seu agente pessoal Arc. É a camada que limita o estrago quando todo o resto falha.

4. Gateways de ferramentas e de modelos. Toda chamada de ferramenta ou de modelo passa por um gateway que permite, bloqueia ou registra. O Agent 365 da Microsoft consegue bloquear as ferramentas MCP que um agente chama no gateway; gateways de IA definem quais modelos um time pode usar e a que custo.

5. Regras de sequência e de contexto. Algumas ações são seguras sozinhas e perigosas em conjunto: ler o cadastro de um cliente e depois mandar um e-mail para fora da empresa. O Strands Box da AWS faz a autorização depender do que o agente acabou de fazer.

6. Aprovação humana. Uma pessoa aprova antes de o agente enviar, pagar, apagar ou fazer o deploy. É mais forte quando usa o processo de aprovação que a empresa já audita, como a gestão de mudanças, e mais fraca quando quem aprova não consegue ver o que está aprovando.

7. Orçamentos e limites de taxa. Limites de gasto e de volume param loops descontrolados e abusos. A Databricks descobriu que uma fricção que aumenta aos poucos funciona melhor que tetos rígidos para pessoas; para agentes autônomos, limites rígidos continuam sendo uma rede de segurança sensata.

O teste que importa

Para cada guardrail, faça uma pergunta: se um documento malicioso convencesse o agente a fazer a coisa proibida, este controle ainda o impediria? Se a resposta for não, ele é uma diretriz de comportamento, valiosa para qualidade e inútil para segurança. Os tipos 1 e 2 costumam falhar nesse teste. Os tipos 3 a 7 costumam passar, porque rodam fora do agente.

A segunda pergunta é sobre quem é dono. Esses controles respondem a perguntas diferentes, rodam em ritmos diferentes e devem ficar com times diferentes; organizamos isso como seis autoridades independentes sobre um agente.

Um conjunto mínimo para um agente em produção

• Uma identidade própria, com permissões limitadas à sua tarefa.
• Contenção que limita o que ele pode tocar, aplicada fora do agente.
• Um gateway que registra cada chamada de ferramenta e de modelo.
• Aprovação humana para ações difíceis de desfazer.
• Um orçamento com alerta e um teto rígido.
• Instruções no prompt e filtros de saída para comportamento e conteúdo, por cima de tudo isso, e não no lugar disso.

Guardrails não são um produto nem uma camada. Os agentes que falham com segurança são aqueles cujos limites não dependem de o agente concordar com eles.