#llmops#guardrails#llm-engineering#owasp-llm#pii#human-in-the-loop#runtime-safety

Guardrails de LLM em Runtime: Como Construir um Sistema Governável

Defesa em profundidade para entrada, saída e escalada humana

Anderson LimaSoftware Engineer & Architect

October 4, 2026

24 min read

87 views

Guardrails de LLM em Runtime: Como Construir um Sistema Governável

English summary: LLM guardrails are not a bag of content filters. They are a governable runtime that separates model proposals from authorized effects through layered policy enforcement, narrow tool permissions, sandboxing, budgets, human approval, audit evidence, adversarial evals, and explicit fail-open or fail-closed decisions.

Published: July 2026
Reading time: 24 minutes
Keywords: #LLMOps #Guardrails #LLMEngineering #AISecurity #ToolPermissions #Sandboxing #HumanInTheLoop #RuntimeGovernance

Seu agente leu uma fatura, encontrou um e-mail no documento e decidiu enviá-la. A resposta estava em JSON válido. O tom era confiante. O destinatário estava errado.

Esse incidente não é, em primeiro lugar, uma falha de linguagem. É uma falha de arquitetura: o sistema confundiu uma proposta probabilística com uma decisão autorizada.

Tese: guardrails de produção são um runtime governável entre intenção e efeito — não uma lista de palavras proibidas ao redor do prompt.

Um filtro pode ser uma peça desse runtime. Não é o runtime inteiro. A fronteira real precisa decidir quais dados entram, qual contexto é confiável, quais ferramentas existem, com quais permissões, por quanto tempo, dentro de qual orçamento, quando uma pessoa precisa aprovar e quais evidências permitem explicar ou reverter o que aconteceu.

Vamos construir primeiro a menor versão que prova essa separação.

Rode em 60 segundos: a proposta não executa a ação

Crie guardrails.mjs com o código abaixo e rode node guardrails.mjs. Dependência: Node.js 20 ou superior. O exemplo não chama um modelo nem uma API externa; ele simula uma resposta do LLM para deixar a fronteira de autorização visível.

javascript

import { createHash } from 'node:crypto';

const TOOL_POLICY = Object.freeze({
  lookup_invoice: {
    effect: 'read',
    scopes: ['billing:read'],
    maxCalls: 3,
    approval: false,
  },
  send_invoice: {
    effect: 'external_write',
    scopes: ['billing:write'],
    maxCalls: 1,
    approval: true,
  },
});

const EMAIL = /\b[\w.+-]+@[\w-]+(?:\.[\w-]+)+\b/i;
const INJECTION = /ignore (previous|all) instructions|reveal .*system prompt/i;

function block(code, detail) {
  return { kind: 'blocked', code, detail };
}

function parseProposal(raw) {
  let value;
  try {
    value = JSON.parse(raw);
  } catch {
    return block('output.invalid_json', 'A resposta não é JSON.');
  }

  if (!value || typeof value !== 'object' || Array.isArray(value)) {
    return block('output.invalid_schema', 'Contrato de saída inválido.');
  }

  const allowedKeys = ['summary', 'tool', 'args'];
  const exactKeys = Object.keys(value).every((key) => allowedKeys.includes(key));
  const validArgs = value.args && typeof value.args === 'object' &&
    !Array.isArray(value.args) &&
    Object.values(value.args).every((item) => typeof item === 'string');

  if (!exactKeys || typeof value.summary !== 'string' ||
      typeof value.tool !== 'string' || !validArgs) {
    return block('output.invalid_schema', 'Contrato de saída inválido.');
  }
  if (EMAIL.test(JSON.stringify(value))) {
    return block('output.pii', 'A proposta contém dado pessoal.');
  }
  return { kind: 'parsed', value };
}

function decide({ input, rawReply, scopes, budget }) {
  if (Date.now() > budget.deadlineMs) {
    return block('budget.deadline', 'Tempo total esgotado.');
  }
  if (budget.modelCalls > budget.maxModelCalls) {
    return block('budget.model_calls', 'Limite de chamadas esgotado.');
  }
  if (input.length > 12_000) {
    return block('input.too_large', 'Input acima do limite.');
  }
  if (INJECTION.test(input)) {
    return block('input.suspicious', 'Input requer revisão.');
  }

  const parsed = parseProposal(rawReply);
  if (parsed.kind === 'blocked') return parsed;

  const { tool, args } = parsed.value;
  const policy = TOOL_POLICY[tool];
  if (!policy) return block('tool.unknown', 'Ferramenta fora da allowlist.');
  if (!policy.scopes.every((scope) => scopes.includes(scope))) {
    return block('tool.scope_denied', 'Escopo insuficiente.');
  }
  if ((budget.toolCalls[tool] ?? 0) >= policy.maxCalls) {
    return block('budget.tool_calls', 'Limite da ferramenta esgotado.');
  }

  const plan = { tool, args, effect: policy.effect };
  if (policy.approval) {
    const digest = createHash('sha256')
      .update(JSON.stringify(plan))
      .digest('hex');
    return {
      kind: 'needs_approval',
      plan,
      digest,
      expiresAt: new Date(Date.now() + 5 * 60_000).toISOString(),
    };
  }
  return { kind: 'allowed', plan };
}

const candidate = JSON.stringify({
  summary: 'Enviar a fatura aprovada ao cliente.',
  tool: 'send_invoice',
  args: { invoiceId: 'inv_123', customerId: 'cus_456' },
});

const result = decide({
  input: 'Envie a fatura de agosto.',
  rawReply: candidate,
  scopes: ['billing:write'],
  budget: {
    deadlineMs: Date.now() + 2_000,
    maxModelCalls: 4,
    modelCalls: 1,
    toolCalls: {},
  },
});

console.log(result.kind, result.plan.tool);
// needs_approval send_invoice

O que acabou de acontecer

O programa não tentou descobrir se o modelo “parecia seguro”. Ele avaliou propriedades que o modelo não pode conceder a si mesmo:

A resposta precisa obedecer a um contrato fechado.
A ferramenta precisa existir em uma allowlist.
A identidade chamadora precisa carregar o escopo exigido.
O tempo, as chamadas ao modelo e as chamadas à ferramenta têm limites.
Um efeito externo vira um plano com hash e expiração, não uma execução.

A saída é needs_approval send_invoice. Isso é sucesso: o modelo propôs; o runtime interrompeu.

O exemplo é deliberadamente incompleto. A expressão regular não detecta toda prompt injection ou PII, o parser não substitui uma biblioteca de schema, o contador não é distribuído e nenhum sandbox foi criado. Também faltam autenticação, isolamento por tenant, armazenamento durável de aprovação e um executor idempotente. O objetivo é provar uma invariante pequena antes de adicionar infraestrutura:

Nenhum texto produzido pelo modelo atravessa diretamente a fronteira de efeitos colaterais.

A intuição: o modelo é um estagiário dentro de uma sala de controle

Imagine uma sala de controle industrial. Um estagiário pode observar painéis, interpretar sinais e sugerir “feche a válvula 7”. Ele não recebe a chave mestra da planta. Um controlador verifica se a válvula existe, se aquela pessoa pode operá-la, se a pressão permite a mudança, se outra ação já está em andamento e se a operação exige dupla confirmação.

O LLM ocupa a posição do estagiário: excelente para interpretar contexto ambíguo e propor próximos passos; inadequado para ser a própria autoridade que valida sua proposta.

O runtime é a sala de controle. Ele transforma intenção em uma máquina de estados observável:

Essa arquitetura não torna o modelo determinístico. Ela torna determinística a forma como o sistema responde à incerteza.

Seis falhas recorrentes — e o diagnóstico correto

Antes de escolher controles, vale nomear o que costuma quebrar. Caso contrário, “adicionar guardrails” vira uma tarefa sem propriedade verificável.

Falha observada	Diagnóstico	Por que a correção ingênua falha	Propriedade a restaurar
O prompt diz “nunca envie dados”, mas o agente envia	Política crítica existe apenas em linguagem natural	O mesmo componente interpreta a regra e decide se a obedece	Enforcement fora do modelo, com DLP e permissão no executor
O JSON é válido, mas cancela o pedido errado	Validação sintática foi confundida com autorização	Schema prova forma, não identidade, intenção, tenant ou estado	Policy check contextual imediatamente antes do efeito
Uma página recuperada faz o agente chamar uma tool	Conteúdo externo perdeu proveniência e virou instrução	Delimitadores ajudam o modelo, mas não removem a capacidade perigosa	Dados não confiáveis rotulados + tool allowlist + menor privilégio
Um loop consome milhares de tokens e chamadas	Não há orçamento global nem local	Timeout HTTP não limita retries, fan-out ou custo acumulado	Deadline, quotas e contadores compartilhados por execução
Uma pessoa “aprova”, mas os argumentos mudam depois	Aprovação não está vinculada ao plano executado	Revisão de uma descrição vaga não autoriza os bytes finais	Hash, expiração, identidade e idempotency key vinculados ao plano
O incidente é descoberto, mas ninguém o explica	Log é texto bruto sem versão de política ou decisão	Mais prompt em log aumenta exposição sem provar o caminho	Trilha mínima, redigida, correlacionável e com owner

Há outras falhas — envenenamento de corpus, supply chain, indisponibilidade do provedor, alucinação factual —, mas essas seis expõem a raiz operacional: capacidade, autoridade e evidência foram misturadas.

Classifique o risco antes de escolher o guardrail

“Conteúdo seguro” é apenas um eixo. Uma saída inofensiva pode acionar uma ferramenta poderosa; uma saída desconfortável pode não produzir efeito algum. Classifique cada rota por cinco dimensões:

Sensibilidade dos dados: público, interno, confidencial, regulado.
Capacidade: responder, ler, escrever, executar código, movimentar valor, alterar acesso.
Raio de impacto: um usuário, um tenant, muitos tenants, infraestrutura global.
Reversibilidade: reversível automaticamente, compensável, manualmente recuperável, irreversível.
Incerteza contextual: intenção clara, ambígua, conflitante ou baseada em fonte não confiável.

Uma matriz simples já produz decisões melhores do que uma coleção uniforme de filtros:

Classe	Exemplo	Default de runtime	Evidência mínima
R0 — informacional	resumir documentação pública	permitir com limites e citações quando necessário	request ID, modelo/versão, latência
R1 — leitura privada	consultar pedido do próprio tenant	autenticar, filtrar tenant, minimizar dados, controlar saída de rede	principal, escopos, fontes acessadas
R2 — escrita reversível	criar rascunho interno	preview, idempotência, quota e opção de desfazer	diff, policy version, resultado
R3 — efeito consequente	enviar e-mail, cancelar pedido, mudar permissão	fail closed, aprovação ligada ao plano, rechecagem no executor	aprovador, digest, estado antes/depois
R4 — crítico ou irreversível	pagamento alto, produção, segredo, dado regulado	capability dedicada, dupla aprovação ou proibição	trilha imutável, owner, runbook e revisão posterior

Os limiares são decisões de produto, segurança e domínio. Não existe um valor universal que transforme R2 em R3. Uma transferência de R$ 10 pode ser trivial em um sandbox financeiro e proibida em uma conta real sem mandato. A política precisa receber o contexto; o modelo não deve inventá-lo.

R0–R4 é uma classificação operacional local, não uma renomeação da OWASP. Em 12 de agosto de 2026, a edição mais recente listada pela OWASP era o LLM Top 10 2026, publicada em 3 de agosto. As páginas LLM01, LLM06 e LLM10 citadas ao final permanecem identificadas como edição 2025; por isso, a versão aparece explicitamente em vez de ser tratada como taxonomia atemporal.

Enforcement em camadas: cada controle responde a uma pergunta

Defesa em profundidade não significa repetir o mesmo detector sete vezes. Significa colocar mecanismos independentes nas fronteiras onde eles têm autoridade.

1. Especificação e evals: o que nunca pode acontecer?

Comece com invariantes executáveis, não com frases como “o agente deve ser seguro”. Para a rota de faturas:

nenhum send_invoice sem billing:write;
nenhuma execução sem aprovação válida para o digest exato;
nenhum acesso cross-tenant;
no máximo uma tentativa de envio por request;
nenhum e-mail ou CPF em trace;
toda decisão de deny tem reason code estável;
falha antes do efeito não altera estado; falha depois do efeito inicia compensação ou incidente.

Essas propriedades orientam código, teste e observabilidade. Se você não consegue dizer como provar a invariante, ainda não terminou a especificação.

2. Ingress: identidade, proveniência e minimização

O runtime autentica o principal antes de montar contexto. Arquivos, RAG, páginas, e-mails e resultados de tools carregam origem, tenant, classificação e nível de confiança. Conteúdo recuperado continua sendo dado não confiável mesmo quando parece uma instrução.

Minimize antes do modelo. Se a tarefa só precisa de [CUSTOMER_17], não envie nome, CPF e endereço. A tabela de reidentificação fica fora do contexto, com controle de acesso e retenção próprios. Mas não chame pseudonimização de anonimização: a LGPD define dado pessoal e anonimização pelo risco razoável de associação ou reversão. A decisão jurídica depende do caso; este texto é orientação de engenharia, não aconselhamento jurídico.

3. Contrato do modelo: estrutura, limites e abstention

Peça um plano estreito: tool, args, justification, citations e confidence quando a rota precisar. Valide schema estrito, tamanhos, enums e encoding no consumidor. Campos desconhecidos são erro; “consertar” JSON silenciosamente pode mudar intenção.

Saída estruturada reduz ambiguidade de integração. Não concede permissão. Um objeto perfeitamente válido ainda pode apontar para o tenant errado, usar dados expirados ou propor uma ação proibida.

4. Policy engine: contexto vira decisão

O motor de políticas recebe fatos verificados — principal, tenant, ferramenta, argumentos, classificação de dados, estado atual, risco, orçamento e versão da política — e retorna allow, deny, degrade ou require_approval com um código de motivo estável.

Mantenha essa função determinística sempre que possível. Um segundo LLM pode ajudar a detectar conteúdo difícil, mas não deve ser a única autoridade para escopo, limite financeiro ou acesso. Detecção probabilística informa a política; não substitui IAM.

5. Executor: revalide no último metro

Entre aprovação e execução, o mundo pode mudar. O executor verifica novamente identidade, tenant, escopo, digest, expiração, budget e estado do recurso. A operação usa idempotency key para que retry não duplique o efeito.

Essa rechecagem evita o clássico time-of-check/time-of-use: o pedido estava cancelável quando o plano foi criado, mas já foi enviado quando a tool tentou cancelá-lo.

6. Auditoria e recuperação: registre decisão, não segredos

Free

react · boilerplate

React Zero to Hero Starter

A public React starter with TypeScript, Zustand, React Query, Tailwind CSS, PWA, and documented AI integrations. The repository does not declare an SPDX license; review its terms before commercial use.

View product

R$19.99

nextjs · saas

SaaS Landing Page

A Next.js, TypeScript, and Tailwind CSS SaaS landing page with SEO, themes, i18n, PWA, and integration points for auth, Stripe, and AI. A clear foundation for leaving the blank screen behind and shaping your positioning.

View product

Explore all products

Continue exploring similar topics

#llmops#llm-engineering#production

Introdução ao LLMOps: O Ciclo de Vida de Aplicações de LLM em Produção

--- title: "Introdução ao LLMOps: O Ciclo de Vida de Aplicações de LLM em Produção" subtitle: "Como orquestrar modelos de fundação com gateway, roteamento, cache, guardrails e eval

17 min read

October 4, 2026

#llmops#model-routing#llm-engineering

Roteamento de modelos LLM: a política que controla custo, qualidade e falhas

English summary: Production LLM routing is an executable policy for choosing models under quality, cost, latency, privacy, and failure constraints. This guide builds a minimal rout

20 min read

109

October 4, 2026

#llmops#observability#opentelemetry

Observabilidade e Evals em Produção: O Fechamento do LLMOps

Observabilidade generativa não é log com texto bonito. É prompt completo, versão do modelo, tools usadas, latência, custo e veredito do eval no mesmo span. Fechamento da série LLMOps em Produção.

11 min read

625

July 29, 2026

Free checklist

Is your AI-built app production-ready?

A practical checklist to validate security, cost, evals, and observability before you ship your AI app to production.

Lemon.dev Store

Turn what you learned into shipped code

Production-tested templates trusted by developers. Save weeks of setup on your next project.

Browse templates

Permissões de ferramentas: capacidade estreita vence inteligência ampla

Ferramentas devem representar operações de domínio, não atalhos administrativos. Compare:

ruim: run_sql(query), shell(command), admin_request(method, url, body);
melhor: find_invoice(customerToken, month), draft_invoice_email(invoiceId), send_approved_invoice(approvalId).

Cada tool precisa declarar:

schema de argumentos e resposta;
efeitos: read, local_write, external_write, privilege_change;
escopos e tenant exigidos;
dados que pode ler e emitir;
limite de chamadas, timeout e tamanho;
egress permitido;
necessidade de aprovação;
estratégia de idempotência e compensação;
owner e runbook.

Credencial temporária e restrita é parte da permissão. Se o processo do agente recebe uma chave que pode apagar todo o bucket, nenhuma frase no system prompt reduz essa capacidade real.

Sandbox: contenha o processo, não apenas a conversa

Permissão responde “o que esta identidade pode fazer?”. Sandbox responde “onde e com quais recursos este processo pode operar?”. Você precisa das duas.

Para execução de código ou ferramentas não confiáveis, restrinja pelo menos:

filesystem: diretório efêmero, read-only por padrão, sem home ou sockets sensíveis;
processo: usuário sem privilégio, syscalls/capabilities reduzidas, sem acesso ao host;
rede: egress negado por padrão ou allowlist de destinos e métodos;
segredos: injeção just-in-time, escopo por ação, rotação e revogação;
recursos: CPU, memória, descritores, disco, tamanho de output e número de processos;
tempo de vida: ambiente descartado ao fim, sem estado residual entre tenants.

Sandbox não corrige uma autorização errada. Se você permite payments.example e injeta uma credencial de pagamento ampla, o processo isolado ainda pode pagar ao destinatário errado. E permissão estreita sem isolamento ainda pode permitir leitura acidental do host. São controles ortogonais.

Orçamentos e timeouts são políticas, não otimizações

Um timeout por requisição não limita um agente que abre subtarefas, repete chamadas ou alterna provedores. Defina orçamentos em múltiplos níveis:

Orçamento	Exemplo	Ao esgotar
Parede	30 s por turno, 5 min por job	cancelar filhos e devolver estado parcial seguro
Modelo	6 chamadas, 40 mil tokens	parar o loop; não trocar de modelo silenciosamente
Tool	3 leituras, 1 escrita	negar novas chamadas com reason code
Dinheiro	R$ 0,80 por execução, teto diário por tenant	degradar rota ou bloquear conforme criticidade
Fan-out	4 subtarefas concorrentes	enfileirar ou rejeitar expansão
Output	1 MB por tool, 8 mil tokens ao usuário	truncar com marcador ou falhar antes do parser

O contador deve ser compartilhado entre novas tentativas e subagentes. O cancelamento precisa se propagar. O fallback de provedor consome o mesmo orçamento e deve aparecer na trilha. Caso contrário, “resiliência” vira consumo sem limite e comportamento impossível de reproduzir.

Aprovação humana que realmente interrompe

Human-in-the-loop existe somente se o estado para antes do efeito. Uma notificação depois do envio é auditoria tardia, não aprovação.

O aprovador deve ver o plano exato: ação, alvo, diff, valor, origem dos dados, argumentos finais, risco, expiração e efeito esperado. A aprovação fica vinculada a:

identidade e papel do aprovador;
principal e tenant da solicitação;
digest canônico dos argumentos;
versão da política;
prazo curto;
idempotency key;
requisito de uma ou duas pessoas conforme risco.

Qualquer mudança invalida o aceite. A UI deve oferecer aprovar, rejeitar e editar criando novo plano; nunca “aprovar qualquer variação”.

Aprovação tem custo e pode virar teatro. Se revisores aprovam centenas de ações idênticas sob pressão, a taxa de rejeição cai sem que o risco caia. Automatize rotas comprovadamente baixas; mantenha humanos onde julgamento de domínio muda o resultado; proíba o que não pode ser revisado com segurança.

Fail closed ou fail open? Decida por rota e dependência

“Sempre fail closed” parece seguro até o detector de PII ficar indisponível e bloquear um canal de emergência. “Sempre fail open” parece resiliente até o serviço de autorização cair e liberar uma transferência. O comportamento padrão depende do impacto de uma decisão errada e do custo de indisponibilidade.

Falha	Contexto	Decisão recomendada	Motivo
IAM ou tenant indeterminado	qualquer dado privado ou tool	fail closed	não existe autoridade verificável
Serviço de aprovação indisponível	escrita R3/R4	fail closed e preservar o plano	indisponibilidade é menos grave que efeito não autorizado
Detector probabilístico indisponível	resumo de documento público R0	fail open degradado, sem tools e com limite menor	não há efeito externo nem dado privado
Telemetria central indisponível	leitura privada R1	buffer local redigido; bloquear se não houver trilha recuperável	auditabilidade pode ser requisito da rota
Provedor principal indisponível	rota informacional	fallback explícito dentro do mesmo budget	mantém serviço sem ampliar capacidade
Sandbox indisponível	execução de código	fail closed	executar no host muda o raio de impacto

Fail open não significa ignorar política. Significa entrar em um modo degradado previamente especificado: menos dados, nenhuma escrita, menos ferramentas, budget menor e resposta marcada. Se o modo não foi testado, ele não é um fallback; é improviso.

Artefato copiável: contrato de política por rota

Este YAML não é um produto pronto, mas força as decisões certas a aparecerem em review. Adapte os nomes ao seu policy engine.

yaml

route: invoice_assistant.send
owner: billing-platform
policy_version: 3.2.0
risk_class: R3

data:
  allowed: [invoice_id, customer_token, billing_month]
  forbidden: [raw_email, tax_id, payment_card]
  tenant_isolation: required

tool:
  name: send_approved_invoice
  effect: external_write
  required_scopes: [billing:write]
  max_calls: 1
  timeout_ms: 3000
  egress_allowlist: [billing-api.internal]
  sandbox: required

budget:
  wall_time_ms: 30000
  model_calls: 4
  input_tokens: 20000
  output_tokens: 4000
  max_cost_brl: 0.80

approval:
  required: true
  bind: [principal, tenant, tool, args_digest, policy_version]
  expires_in_seconds: 300
  approver_role: billing-operator

failure:
  authorization_unknown: fail_closed
  detector_unavailable: fail_closed
  provider_unavailable: preserve_plan

evidence:
  log: [request_id, principal_id, tenant_id, decision, reason_code,
        tool, args_digest, approver_id, latency_ms, outcome]
  redact: [prompt, raw_tool_output, personal_data]
  retention_days: 90

success:
  critical_policy_violations: 0
  duplicate_side_effects: 0
  p95_added_latency_ms: 400
  max_false_block_rate: 0.01

O valor está menos na sintaxe do que na revisão: produto aceita o modo degradado? Segurança aceita o egress? Billing assume o runbook? Privacidade aceita dados e retenção? Plataforma consegue medir os SLOs? Sem respostas, a configuração é decoração.

Red team: ataque propriedades, não frases

Um teste fraco pergunta se o modelo recusou “ignore as instruções anteriores”. Um teste útil tenta produzir o efeito proibido e inspeciona o estado final.

Monte casos em cinco famílias:

Instrução hostil: injection direto, indireto em HTML/PDF, Unicode confusável, conteúdo repartido e tool output malicioso.
Autorização: tenant trocado, escopo expirado, ID previsível, confused deputy e privilégio herdado de subagente.
Integridade do plano: argumentos alterados após aprovação, replay, corrida, estado obsoleto e retry depois de timeout.
Contenção: tentativa de ler filesystem, acessar metadata service, abrir egress não permitido, exfiltrar via DNS ou inflar output.
Disponibilidade: loop infinito, fan-out, respostas gigantes, provedor lento, detector fora e fila humana congestionada.

Para cada caso, registre três evidências: decisão do runtime, chamadas que chegaram ao executor e estado externo antes/depois. O texto da resposta é secundário.

Separe regressões conhecidas de um conjunto de release mantido fora do prompt de desenvolvimento. Faça red-team novamente quando mudar modelo, system prompt, tool, policy, conector, sandbox ou fluxo de aprovação. O risco é propriedade do sistema composto.

Métricas que mostram controle — e custo

Não use “número de bloqueios” como sinônimo de segurança. Um detector que bloqueia tudo tem recall excelente e produto inútil.

Métrica	Pergunta operacional	Segmentação necessária
Violações críticas executadas	Alguma invariante R3/R4 escapou?	rota, tool, policy version
False-block rate	Quantos casos legítimos foram negados?	idioma, tenant, classe de risco
Precisão de escalada	Revisores confirmam o risco sinalizado?	reason code, detector, versão
Taxa de rejeição humana	A aprovação encontra planos ruins ou só adiciona clique?	tool, aprovador, horário
Side effects duplicados	Idempotência funciona sob retry?	executor, erro anterior
Budget-exhaustion rate	Onde loops e fan-out consomem o teto?	modelo, workflow, tenant
P95/P99 de latência adicionada	Qual segurança cabe no SLO?	camada, região, modo degradado
Tempo para conter e recuperar	O runbook funciona durante incidente?	severidade, owner, dependência

Defina numerador, denominador, janela e fonte. “False-block abaixo de 1%” não é verificável sem conjunto rotulado ou revisão amostral. “Zero incidentes” pode significar ausência de detecção. Combine métricas preventivas, de detecção, de impacto e de recuperação.

Responsabilidade operacional: quem decide, quem opera, quem responde

Guardrail sem responsável envelhece em silêncio.

Responsável	Decisão que não pode ser terceirizada ao modelo
Produto/domínio	ação permitida, risco aceitável, quando humano agrega julgamento
Segurança	capabilities, threat model, sandbox, segredos, red-team e resposta
Plataforma de IA	runtime, policy engine, budgets, versões, eval harness e observabilidade
Dados/privacidade/jurídico	finalidade, minimização, base aplicável, retenção e direitos
Operações/SRE	SLO, modo degradado, alertas, kill switch, recuperação e postmortem
Dono da tool	contrato, autorização final, idempotência, compensação e runbook

Uma pessoa pode acumular papéis em equipe pequena. As decisões continuam precisando de nomes, revisão e evidência.

Checklist de release

A rota tem owner, classe de risco e invariantes aprovadas.
Identidade e tenant são resolvidos antes de recuperar contexto.
Input de usuário, RAG, arquivos e tools preservam proveniência e confiança.
Dados são minimizados antes do modelo e redigidos antes da telemetria.
A saída obedece a schema estrito, limites e encoding do consumidor.
Tools são estreitas, têm escopo mínimo, credencial temporária e egress controlado.
Código e tools não confiáveis executam em sandbox com recursos limitados.
Deadline, tokens, custo, tool calls, retries e fan-out compartilham budget.
Escritas usam idempotency key e rechecagem no executor.
Aprovação interrompe antes do efeito e está ligada ao digest exato.
Fail-open/fail-closed está decidido por dependência e testado em caos.
Trace registra versão da política, reason code, decisão e outcome sem segredos.
Red-team cobre instruction, autorização, integridade, contenção e disponibilidade.
Dashboards medem escapes, falsos bloqueios, custo, latência e recuperação.
Kill switch, revogação, compensação e escalada têm runbook e owner.

Exercícios

Vincule a aprovação ao estado. Adicione tenantId, principalId, policyVersion e idempotencyKey ao plano do exemplo. Faça qualquer mudança invalidar o digest. Você terminou quando o teste prova que um plano aprovado não autoriza outro.
Implemente budget compartilhado. Faça duas subtarefas consumirem o mesmo contador atômico de tools e o mesmo deadline. Você terminou quando nenhuma corrida excede maxCalls.
Crie modo degradado. Simule detector indisponível em uma rota R0 e em uma R3. R0 deve responder sem tools e com limite menor; R3 deve preservar o plano e negar execução.
Ataque o executor. Tente replay, tenant trocado, aprovação expirada e timeout após o efeito. Você terminou quando não há efeito duplicado e todo deny tem reason code.
Audite sem vazar. Produza um trace suficiente para reconstruir a decisão sem prompt bruto, e-mail ou output de tool. Peça a outra pessoa para explicar o incidente só com essa evidência.

Critérios de sucesso

Você aprendeu — e o runtime está começando a ficar governável — quando consegue demonstrar, em ambiente de teste:

zero violações críticas executadas no conjunto adversarial acordado;
zero side effects duplicados sob retry e timeout;
100% das ações R3/R4 com principal, política, digest, aprovador quando aplicável e estado final correlacionáveis;
nenhuma credencial ampla ou dado pessoal nos traces inspecionados;
budgets respeitados com concorrência e cancelamento;
modos fail-open e fail-closed reproduzíveis por teste;
false-block, latência e custo dentro dos limiares definidos pelo produto;
um owner consegue conter, revogar e recuperar usando o runbook.

Esses critérios não provam segurança universal. Eles provam propriedades delimitadas em um sistema e uma versão específicos. Mudou modelo, tool, política, dado ou fluxo? A evidência precisa ser regenerada.

Versão de brinquedo versus produção: onde o exemplo para

O script inicial é uma catraca. Produção é o prédio inteiro.

Toy	Produção
objeto local de policy	policy store versionado, review e rollout gradual
contadores em memória	quota atômica distribuída e propagada entre jobs
regex de injection/PII	sinais múltiplos, DLP de domínio, amostragem e revisão
`scopes` passados pela função	IAM autenticado, capability temporária e tenant binding
plano com hash	aprovação durável, assinatura, expiração e idempotência
nenhum executor	executor isolado, transacional e com compensação
`console.log`	trace redigido, acesso controlado, retenção e alertas

Há trade-offs inevitáveis. Mais camadas aumentam latência, custo e superfície operacional. Sandbox reduz impacto, mas dificulta cache e debugging. Aprovação reduz autonomia e pode congestionar. Fail closed protege integridade, mas derruba disponibilidade. Detecção agressiva reduz escapes e aumenta falsos bloqueios. Logs detalhados ajudam investigação e elevam risco de privacidade.

Governança não elimina esses conflitos. Ela os torna explícitos, atribuídos e mensuráveis.

Também há limites que runtime guardrails não resolvem sozinhos: qualidade ou viés do modelo, segurança da supply chain, governança de treinamento, contrato com fornecedores, verdade factual universal, desenho jurídico da finalidade e falhas do sistema consumidor. O runtime reduz raio de impacto e cria decisões auditáveis; não emite certificado de “IA segura”.

Uma ordem prática de implementação

Se você está saindo de um protótipo, não comece comprando cinco classificadores.

Remova tools desnecessárias e credenciais amplas.
Separe proposta de execução com schema e executor próprio.
Classifique rotas por dado, capacidade, impacto e reversibilidade.
Imponha tenant, escopo, idempotência, budget e timeout no último metro.
Adicione aprovação para efeitos consequentes e sandbox para execução não confiável.
Registre decisão redigida, reason codes e versões.
Defina evals adversariais, métricas, owners e modos de falha.
Só então refine detectores probabilísticos com dados dos seus incidentes e falsos bloqueios.

O primeiro ganho vem de retirar poder, não de adicionar inteligência.

Conclusão

Guardrails maduros não tentam convencer o LLM a nunca errar. Eles partem do pressuposto de que inputs serão ambíguos, modelos serão manipuláveis, dependências falharão e políticas mudarão.

O sistema governável preserva três separações: dado não confiável não vira instrução; proposta não vira autorização; autorização não vira efeito sem revalidação e evidência.

Quando essas separações existem, “dizer não” deixa de ser uma personalidade do modelo. Vira uma propriedade testável do runtime — com contexto, owner, custo, exceção, recuperação e prova.

Fontes primárias e datas

OWASP GenAI LLM Top 10 2026 — edição mais recente indicada pela OWASP na consulta de 12 ago. 2026; publicada em 3 ago. 2026.
OWASP LLM01:2025 Prompt Injection, LLM06:2025 Excessive Agency e LLM10:2025 Unbounded Consumption — páginas versionadas de riscos e mitigações da edição 2025; consultadas em 12 ago. 2026.
NIST AI Risk Management Framework 1.0 — publicado em 26 jan. 2023.
NIST AI 600-1: Generative AI Profile — publicado em 26 jul. 2024; página do NIST atualizada em 8 abr. 2026.
NIST AI Resource Center — consultado em 12 ago. 2026; nessa data, o NIST sinalizava que o AI RMF 1.0 estava em revisão.
Lei Geral de Proteção de Dados, Lei nº 13.709 — texto compilado consultado em 12 ago. 2026.
OpenAI, Understanding prompt injections — orientação oficial sobre defesa em camadas, sandbox, acesso limitado e confirmação de ações consequentes; consultada em 12 ago. 2026. É uma fonte de fornecedor, não evidência de eficácia universal.

Navegação da série “LLMOps em Produção”

Artigo anterior: Cache Semântico e Memória para LLMs
Próximo artigo: Observabilidade e Evals em LLMOps

Guardrails de LLM em Runtime: Como Construir um Sistema Governável

Rode em 60 segundos: a proposta não executa a ação

O que acabou de acontecer

A intuição: o modelo é um estagiário dentro de uma sala de controle

Seis falhas recorrentes — e o diagnóstico correto

Classifique o risco antes de escolher o guardrail

Enforcement em camadas: cada controle responde a uma pergunta

1. Especificação e evals: o que nunca pode acontecer?

2. Ingress: identidade, proveniência e minimização

3. Contrato do modelo: estrutura, limites e abstention

4. Policy engine: contexto vira decisão

5. Executor: revalide no último metro

6. Auditoria e recuperação: registre decisão, não segredos

FastAPI Clean Architecture

React Native Boilerplate

AI Agents Starter Kit

AI First MongoDB

AI SaaS First Ultra

AI SaaS First Firebase

Buy me a coffee

React TestForge — Vitest + Playwright Starter

React Cupertino UI

IgnitionStack

LuminALL Boilerplate – Multi-Tenant AI SaaS Starter Kit

React Zero to Hero Starter

SaaS Landing Page

Related Articles

Introdução ao LLMOps: O Ciclo de Vida de Aplicações de LLM em Produção

Roteamento de modelos LLM: a política que controla custo, qualidade e falhas

Observabilidade e Evals em Produção: O Fechamento do LLMOps

Is your AI-built app production-ready?

Turn what you learned into shipped code

Permissões de ferramentas: capacidade estreita vence inteligência ampla

Sandbox: contenha o processo, não apenas a conversa

Orçamentos e timeouts são políticas, não otimizações

Aprovação humana que realmente interrompe

Fail closed ou fail open? Decida por rota e dependência

Artefato copiável: contrato de política por rota

Red team: ataque propriedades, não frases

Métricas que mostram controle — e custo

Responsabilidade operacional: quem decide, quem opera, quem responde

Checklist de release

Exercícios

Critérios de sucesso

Versão de brinquedo versus produção: onde o exemplo para

Uma ordem prática de implementação

Conclusão

Fontes primárias e datas