Guardrails LLM: como controlar o que a IA pode fazer

Guardrails LLM precisam atuar em 5 pontos de controle: solicitações recebidas, contexto recuperado, propostas do modelo, ações de ferramentas e respostas enviadas. Filtros de conteúdo podem barrar uma resposta proibida; cabe à aplicação decidir se o cliente tem permissão para consultar um registro ou autorizar um reembolso. Uma equipe pequena deve definir essas permissões antes de acrescentar mais classificadores.

Guardrails LLM: o que são e como funcionam?

Guardrails fazem uma política escrita valer na prática, controlando o que uma aplicação de IA pode receber, revelar ou executar. Um grande modelo de linguagem, ou LLM, gera respostas e propõe ações; os guardrails verificam essas entradas e saídas ou impõem limites ao software que o cerca.

Pense em um museu. A entrada confere os ingressos, cada sala tem suas regras de acesso e um conservador precisa de permissão para mover uma peça. Ter o ingresso conferido não autoriza qualquer ação dentro do prédio. Da mesma forma, uma mensagem inofensiva de um cliente não comprova que determinado pedido pertence a ele.

Um guardrail só funciona quando reúne três elementos: uma regra, uma verificação e uma consequência. “Não exponha dados de clientes” é a regra. Comparar o titular do registro solicitado com o cliente autenticado é a verificação. Recusar a leitura no banco de dados é a consequência. Um log sem bloqueio efetivo apenas registra a falha depois que ela acontece.

Algumas verificações são determinísticas: com a mesma regra e as mesmas entradas, produzem a mesma decisão. A lista de ferramentas permitidas e os campos obrigatórios são exemplos. Outras usam classificadores, modelos que estimam se um conteúdo viola uma política. A detecção de assuntos e a classificação de conteúdo nocivo entram nesse grupo. A aprovação humana acrescenta uma avaliação antes de uma ação permitida, mas de impacto relevante.

Guardrails de IA é o nome desse conjunto amplo de controles. Guardrails AI é um framework específico dentro dele. Confundir a categoria com um produto pode deixar pontos importantes sem ninguém responsável por protegê-los.

Guardrails na prática: um pedido de reembolso do início ao fim

Uma solicitação de reembolso exige verificações diferentes em momentos diferentes, mesmo quando a mensagem parece comum. Considere este pedido hipotético: “Por favor, reembolse meu último pedido e envie a confirmação para meu novo e-mail.” Suponha que a política exija aprovação antes de qualquer reembolso e permita enviar confirmações apenas para um endereço verificado da conta.

O caminho da solicitação é: verificações de entrada → contexto com escopo restrito → proposta do modelo → ação autorizada e aprovada → verificações de saída. Cada chamada posterior de ferramenta repete as verificações pertinentes.

Antes do modelo: autenticar, filtrar e minimizar dados

Comece identificando o cliente pela sessão autenticada, e não pelo nome ou identificador de conta digitado no chat. Aplique limites de tamanho e de frequência das solicitações antes das etapas de processamento mais caras.

Depois, verifique se a mensagem contém conteúdo proibido, assuntos fora do escopo ou dados sensíveis desnecessários. Um filtro de assuntos pode impedir que um assistente de suporte dê orientações sem relação com sua função. Um filtro de informações pessoais pode remover um telefone colado na conversa quando a tarefa não precisa dele. PII é a sigla em inglês para informações de identificação pessoal, como e-mail ou telefone.

Não remova informações de que o fluxo realmente precisa sem oferecer outro caminho. Mantenha os dados verificados da conta na aplicação e envie ao modelo apenas o contexto mínimo necessário. Mascarar o texto antes de uma chamada ao modelo também não elimina cópias já registradas nos logs de requisições; minimize os dados na coleta e nos logs.

Antes da recuperação: limitar quais registros podem entrar

Busque o pedido do cliente com uma consulta restrita à conta dele. Essa restrição precisa valer antes que qualquer conteúdo privado chegue ao modelo. Um filtro de saída entra tarde demais para ser a principal barreira entre os registros de clientes diferentes.

Documentos recuperados, páginas da web e resultados de ferramentas também são entradas. Um artigo de ajuda pode conter uma instrução que tenta se sobrepor às regras da aplicação, um tipo de falha chamado injeção indireta de prompt. Trate o texto recuperado como informação a ser examinada, e não como permissão para alterar o fluxo.

O modelo pode precisar da política de devolução e da elegibilidade do pedido. Não precisa das transações de todos os clientes. Restrinja o escopo da busca, elimine campos desnecessários e verifique os riscos de conteúdo relevantes no material selecionado.

Na etapa do modelo: delimitar a proposta

Peça ao modelo uma proposta estruturada com campos conhecidos, como a ação solicitada e o identificador do pedido. Valide a estrutura antes de interpretar os dados.

Um JSON válido segundo o esquema comprova apenas que os dados têm um formato aceitável. Um identificador de pedido inventado ainda pode ser uma string válida. Não permita que o modelo estabeleça a identidade do cliente, a elegibilidade para reembolso ou o próprio status de aprovação ao preencher um campo.

Neste exemplo, o modelo pode propor um reembolso e identificar o pedido de troca de e-mail. Cabe à aplicação decidir se cada uma dessas ações é permitida.

Antes de executar uma ferramenta: verificar autorização e aprovação

Uma ferramenta é uma função da aplicação que o modelo pode solicitar. Antes de executar a função de reembolso, verifique o nome, os argumentos, se o pedido pertence ao cliente, o estado atual do pedido e a elegibilidade segundo as regras de negócio. Rejeite campos inesperados e faça o serviço que executa a ação aplicar as mesmas verificações.

A aprovação humana deve acontecer depois que a proposta exata estiver definida e antes que a ação produza efeitos. Mostre ao responsável pela revisão o pedido, o reembolso pretendido, o destino e o motivo. Vincule a aprovação àquela ação específica. Se os argumentos mudarem, a aprovação anterior deixa de autorizar a execução.

O novo endereço de e-mail é uma questão de permissão separada. Neste exemplo, a aplicação encaminha o cliente para a verificação da conta e usa o endereço já verificado até o processo terminar. Um filtro de conteúdo não comprova que alguém é titular de uma conta de e-mail.

Antes de enviar a resposta: conferir resultados e informações divulgadas

Examine os resultados das ferramentas antes de colocá-los de volta no contexto do modelo. Restrinja os campos retornados, confira sua estrutura e trate explicitamente as operações que falharam ou tiveram resultado ambíguo.

Depois, verifique se a resposta ao cliente contém conteúdo proibido, informações sensíveis ou afirmações sem respaldo, e se segue a estrutura exigida. “Seu reembolso foi concluído” precisa depender de um resultado confirmado pela ferramenta. Se a aprovação estiver pendente, a resposta deve informar isso.

As verificações de entrada e saída podem usar classificadores semelhantes, mas têm funções diferentes: a primeira decide o que entra no processamento; a última, o que chega ao cliente. Nenhuma delas desfaz uma ação não autorizada que já ocorreu.

Ferramentas de guardrails: o que consta na documentação

Escolha a ferramenta pelo ponto de controle que ela ajuda a proteger e pelas regras que sua equipe está preparada para manter. O mapa de recursos abaixo foi conferido na documentação disponível dos fornecedores em 17 de outubro de 2026. Ele compara o escopo documentado, não a precisão de detecção medida em testes.

Os links das fontes e os limites de implementação de cada ferramenta estão a seguir. A coluna “O que continua sob sua responsabilidade” descreve a consequência arquitetural desses escopos documentados; não significa que algum framework impeça a criação de controles próprios.

O que é o Guardrails AI?

Guardrails AI é um framework Python para combinar validadores ao redor das entradas e saídas do modelo e gerar dados estruturados. A introdução apresenta o framework e sua coleção de validadores.

Um validador verifica um valor segundo um critério e retorna aprovação ou falha; a política on_fail configurada define o tratamento da falha. A documentação traz exemplos de linguagem tóxica e PII e permite validadores personalizados. Conceitos de validação.

Use quando regras explícitas de validação se encaixarem em uma aplicação Python existente. O limite está na cobertura: adicionar um framework não define quais verificações rodam em cada caminho nem o que uma falha impede. Escreva e teste essas decisões junto com a aplicação.

NVIDIA NeMo Guardrails

NVIDIA NeMo Guardrails oferece controles programáveis em várias etapas da interação com um LLM. Os tipos de controle documentados incluem entrada, recuperação, diálogo, execução e saída.

Os controles de entrada podem tratar segurança de conteúdo, jailbreaks, assuntos e PII; os de recuperação verificam o contexto; os de diálogo restringem o fluxo da conversa. Os controles de execução podem validar entradas e resultados de ferramentas, enquanto os de saída podem filtrar, editar ou bloquear respostas.

Use quando precisar controlar o fluxo da interação. O limite está na implementação da política: os controles de execução oferecem um ponto para verificar ações, mas seu código precisa fornecer as regras de negócio e as verificações de titularidade. O serviço responsável pela operação também deve impor essas permissões.

Amazon Bedrock Guardrails

Amazon Bedrock Guardrails oferece filtros configuráveis de conteúdo, assuntos proibidos, palavras e informações sensíveis, além de fundamentação contextual e verificações de Automated Reasoning. Os filtros de informações sensíveis podem bloquear ou mascarar tipos de PII compatíveis e padrões personalizados; as verificações de Automated Reasoning avaliam respostas segundo regras lógicas. Visão geral das proteções.

A API ApplyGuardrail avalia texto sem depender de uma chamada a um modelo fundacional. Ela pode ser inserida antes da recuperação de conteúdo ou antes do envio de uma resposta.

É uma opção para aplicações que buscam verificações gerenciadas de políticas. O limite está em supor que todas as verificações cobrem todo tipo de conteúdo: cada recurso tem um escopo específico, e a visão geral exclui blocos de conteúdo de raciocínio. Passar em uma avaliação de conteúdo continua sem autorizar um reembolso.

Segurança em IA: os controles dos fornecedores de modelos

A moderação da OpenAI classifica conteúdo nocivo em entradas de texto e imagem compatíveis e retorna sinalizações, categorias e pontuações. A documentação de moderação também alerta que uma recusa que mencione conteúdo nocivo pode gerar uma sinalização.

Trate esses resultados como sinais para aplicar a política. Uma conversa de suporte que cita uma mensagem abusiva pode exigir tratamento diferente de um pedido para gerar uma mensagem desse tipo. A moderação ajuda nas decisões sobre conteúdo; ela não fornece as regras de acesso aos seus pedidos.

O Gemini, do Google, oferece configurações de segurança que associam categorias de conteúdo nocivo a limiares de bloqueio. O guia atual dessas configurações abrange categorias como assédio, discurso de ódio, conteúdo sexual, conteúdo perigoso e jailbreaks.

O Google distingue a probabilidade de um conteúdo ser inseguro da gravidade do dano potencial. Essa distinção impõe um limite prático: uma pontuação baixa no classificador não demonstra que uma ação teria consequências pequenas. Os controles do fornecedor são componentes úteis, mas a aplicação continua precisando de permissões, delimitação dos dados e tratamento de falhas.

Guardrails para agentes de IA: o que você precisa projetar

Um agente precisa de uma barreira efetiva entre propor uma ação e executá-la. Essa barreira pode ser implementada com pontos de integração de um framework ou com código comum de serviço, mas precisa usar uma identidade confiável e o estado atual da aplicação.

Mantenha uma lista explícita de ferramentas permitidas e verifique os argumentos e o recurso de destino em cada chamada. Permitir “reembolso” não torna qualquer pedido elegível. Um shell de uso geral ou uma ferramenta de rede sem restrições também amplia o conjunto de ações possíveis para muito além de uma função de negócio específica.

Faça da aprovação um registro que o sistema exige e verifica, não um “sim” na conversa. Armazene o que foi aprovado, por quem e com quais detalhes da ação. Confira novamente o estado antes da execução: o pedido pode ter sido reembolsado enquanto o responsável avaliava a proposta.

Faça o serviço exigir uma chave de idempotência, um identificador estável da operação que permite às novas tentativas retornar o resultado existente em vez de emitir outro reembolso. Restrinja as permissões das credenciais e mantenha o caminho de aplicação dos controles fora do alcance do modelo. O agente não deve conseguir escolher um segundo endpoint que contorne a verificação.

Nosso guia de guardrails e limites de impacto para agentes de IA em produção detalha a arquitetura ao redor desses controles. Para esta solicitação, a pergunta decisiva é simples: se o modelo propuser a ação errada, qual serviço se recusará a executá-la?

Limites que precisam estar claros antes do lançamento

Os nomes dos recursos são mais abrangentes do que suas condições de funcionamento. Confira o escopo da verificação exata que pretende usar.

Por exemplo, a AWS documenta a fundamentação contextual para resumo, paráfrase e resposta a perguntas com uma fonte de referência e uma consulta, mas exclui explicitamente os casos de perguntas e respostas em conversas ou chatbots. Os máximos documentados são 100,000 caracteres de fonte, 1,000 de consulta e 5,000 de resposta. Esses limites de caracteres valem para esse recurso; não são limites gerais de contexto do modelo nem uma proibição de usar outras proteções do Bedrock em chatbots. Documentação de fundamentação contextual.

A fundamentação verifica se uma resposta segue a fonte fornecida. Se a própria fonte estiver desatualizada ou errada, concordar com ela não comprova a veracidade da resposta. No exemplo do reembolso, o estado atual do pedido precisa vir do serviço que mantém o registro oficial.

O streaming muda o ponto de aplicação do controle. A AWS alerta que uma decisão sobre relevância na fundamentação contextual pode chegar depois que a resposta já foi transmitida por streaming. De modo geral, se uma política exige verificar a resposta completa antes de divulgá-la, retenha a resposta até a verificação ser aprovada. Uma recusa posterior não recolhe o texto que já foi exibido.

Um timeout precisa ter um desfecho definido. Se uma verificação obrigatória de permissão ou aprovação exceder o tempo limite, interrompa a alteração e ofereça um caminho de pendência ou atendimento humano. Para respostas de menor risco, defina explicitamente qual alternativa limitada é aceitável. Não transforme silenciosamente a falha de uma verificação em permissão para continuar.

Meça a latência adicional e os bloqueios indevidos na sua própria carga de trabalho. Nenhuma pontuação de fornecedor substitui saber se clientes legítimos conseguem concluir a tarefa real de suporte.

Seis controles para uma equipe pequena começar

Comece com seis controles que sua equipe consiga explicar, testar e atribuir a um responsável. Não é preciso adotar todos os frameworks da tabela.

1. 1

   Identidade e escopo dos dados

   Use o contexto do cliente autenticado na recuperação de dados e nas ferramentas. Teste para garantir que um cliente não consiga consultar o pedido de outro, mesmo quando o modelo solicita esse acesso.

2. 2

   Política de entrada e minimização de dados

   Defina a tarefa atendida, verifique os riscos de conteúdo relevantes e remova campos sensíveis desnecessários. Escolha uma resposta segura para pedidos fora do escopo.

3. 3

   Contrato de saída

   Valide os campos obrigatórios, as regras de divulgação e as afirmações sobre ações concluídas. Se a resposta não tiver respaldo confiável, faça com que reconheça a incerteza ou encaminhe o caso ao suporte.

4. 4

   Ações restritas e aprovação

   Disponibilize ferramentas de negócio com funções bem delimitadas. Confira identidade, argumentos e estado atual antes da execução; exija aprovação para as ações que sua política classifica como de impacto relevante.

5. 5

   Comportamento em falhas e limites operacionais

   Defina limites de solicitações, chamadas de ferramentas, novas tentativas e tempo de execução adequados ao fluxo. Estabeleça o que acontece quando uma verificação obrigatória ou um serviço do qual o fluxo depende falha. Valide novamente as propostas revisadas e as novas tentativas.

6. 6

   Testes de regressão e trilha de auditoria

   Registre versões das regras, decisões, resultados das ferramentas e referências às aprovações sem copiar dados sensíveis desnecessários. Faça os casos conhecidos de divulgação de dados ou ações não autorizadas bloquearem um lançamento.

Quem desenvolve precisa agir agora se uma funcionalidade voltada ao cliente consulta registros privados ou pode alterar o estado do sistema. Implemente primeiro as permissões no serviço. Quem opera precisa definir um responsável pelos encaminhamentos, pelas solicitações legítimas bloqueadas e pelas verificações indisponíveis. Uma fila sem responsável é um fluxo incompleto.

Quem compra deve esperar antes de contratar outro produto de guardrails até identificar qual ponto de controle falta. Um assistente que consulta documentos públicos e não tem ferramentas de escrita não precisa de um fluxo de aprovação de reembolsos. Ainda assim, precisa de verificações de conteúdo relevantes, recuperação confiável e uma alternativa clara para quando o fluxo não puder prosseguir. Os controles sobre ações se tornam necessários à medida que suas capacidades aumentam.

Como testar a aplicação com Promptfoo

Promptfoo é uma ferramenta de avaliação e red teaming: ajuda a testar tanto o comportamento normal quanto solicitações deliberadamente adversariais. A documentação de testes de agentes descreve verificações de restrições por função, acesso não autorizado a objetos e acesso não autorizado a funções.

Direcione os testes à interface da aplicação com identidades representativas e dados de teste preparados. Testar apenas o modelo deixa de fora as permissões de recuperação, o fluxo de aprovação e os serviços de ferramentas que os clientes realmente usam.

Para o fluxo hipotético de reembolso, comece por estes casos:

• Um pedido elegível: a proposta chega à etapa de aprovação, e a execução aguarda essa aprovação.
• O pedido de outro cliente: tanto a recuperação quanto a execução negam acesso.
• Uma troca de endereço para a confirmação: a aplicação exige o processo separado de verificação.
• Instruções ocultas no conteúdo recuperado: elas não conseguem conceder permissões nem mudar a política de aprovação.
• Uma proposta alterada depois da aprovação: a aprovação anterior não pode autorizar os novos argumentos.
• Uma verificação indisponível ou uma solicitação repetida: as verificações obrigatórias não são contornadas, e a mesma operação não é executada duas vezes.

Esses são casos de teste propostos, não resultados de testes realizados. Examine os efeitos das ações e o estado armazenado, além da resposta final. “Não posso fazer isso” não oferece garantia alguma se a ferramenta já tiver feito.

O guia de início rápido do Promptfoo percorre a configuração do alvo, as categorias de ataque, a execução dos testes e a análise do relatório. Nossa análise do Promptfoo detalha o fluxo de avaliação. Mantenha solicitações normais de clientes junto dos casos adversariais para que filtros mais rígidos não prejudiquem silenciosamente a tarefa útil.

O que está sendo superestimado?

Um produto de guardrails não é um botão universal de segurança. Seu valor depende do que ele verifica, de onde roda e do que sua decisão impede.

Um prompt de sistema mais longo pode expressar uma política, mas não impõe permissões no banco de dados. Um segundo modelo pode criticar uma resposta, mas a concordância entre modelos não comprova que ela está correta. Empilhar mais classificadores também pode aumentar bloqueios indevidos e trabalho operacional sem preencher a lacuna no controle das ações.

O melhor ponto de partida é um conjunto pequeno de controles explícitos, ligados a casos concretos de falha. Acrescente uma verificação quando ela cobrir uma lacuna demonstrada; meça se ela melhora o resultado.

IA sem guardrails: quais controles estão faltando?

Em uma funcionalidade voltada ao cliente, a pergunta útil é quais controles estão ausentes. Uma aplicação pode ter filtragem de conteúdo do fornecedor e ainda não ter permissões específicas por cliente, validação de saída ou mecanismos que exijam aprovação. Chamá-la de “protegida” esconde essas lacunas.

Por outro lado, uma aplicação com controles de acesso determinísticos ainda pode precisar de verificações de conteúdo. Segurança de conteúdo e comportamento autorizado são requisitos separados; nenhum rótulo responde pelos dois.

Perguntas frequentes

Quais são os tipos de guardrails de IA?

Na implementação, categorias úteis incluem verificações de entrada, de contexto recuperado e de saída, controles de execução de ferramentas e aprovação humana. Filtros de assuntos e de PII podem atuar em vários desses pontos de controle.

Como criar guardrails de IA?

Defina um resultado que não pode acontecer, coloque uma verificação antes da divulgação de dados ou da ação correspondente, estabeleça a resposta à falha e teste a aplicação completa. Atribua a alguém a manutenção da política e o tratamento dos casos encaminhados.

O que o Guardrails AI faz?

O Guardrails AI combina validadores em controles de entrada e saída e oferece suporte à geração de dados estruturados. Sua configuração e o código da aplicação determinam quais riscos são verificados e como as falhas são tratadas.

Existe IA sem guardrails?

As aplicações variam nos controles que adotam. Antes de colocar uma em produção, audite os pontos de controle específicos: as proteções de conteúdo do modelo não estabelecem a autorização do cliente nem a aprovação humana.

Quais são os 3 principais riscos de segurança em IA?

Para este exemplo de atendimento ao cliente, comece por injeção de prompt, divulgação não autorizada de dados e ações não autorizadas. É uma priorização prática para esse fluxo, não um ranking universal dos riscos de IA.

Por onde começar na segunda-feira

Escolha uma solicitação real de cliente e desenhe seu caminho da autenticação até a resposta final. Em cada ponto de controle, anote a regra, o componente que a impõe, a resposta à falha e o responsável. Transforme a leitura não autorizada de um registro e a execução de uma ação sem aprovação em testes que bloqueiem o lançamento antes de ampliar as permissões do agente.

Receba guias práticos de implementação de IA na newsletter.