Saltar para o conteúdo principal
As regras do estágio de input filtram o que você envia ao modelo. As regras do estágio de output filtram o que volta. Quando sua preocupação é a resposta do modelo — um segredo vazado na completion, PII que o modelo trouxe do contexto, uma resposta que desvia de suas fontes recuperadas — você quer uma regra cujo estágio seja output. O gateway a executa depois que o modelo upstream responde e antes que um único byte chegue ao seu cliente. Esta página cobre o estágio de output especificamente: como uma completion é filtrada, o que um block custa, e como block e mask se comportam cada um em respostas streaming. Para o motor completo — cada tipo de regra, campo e rota — veja Guardrails.

​
1. Por que times de LLM recorrem a guardrails de output

O modelo é a parte não confiável do loop. Ele pode ecoar um segredo do prompt, puxar o email de um cliente do contexto RAG, ou alucinar uma afirmação que suas fontes nunca fizeram. Nada disso é visível no estágio de input, porque nada disso existe até que o modelo tenha respondido. Um guardrail do estágio de output é o filtro sobre a própria completion. Uma regra roda no estágio de output quando seu stage é output (ou both). O gateway avalia o texto da resposta do modelo contra a política, registra qualquer match, e então a deixa passar, a redige ou a rejeita — exatamente as mesmas ações block / mask / flag que você usa no input, apenas aplicadas à resposta.
As regras de output são uma preocupação superset, não um substituto. A maioria das políticas filtra input para manter dados fora do prompt e output para pegar o que o modelo retorna. O estágio both vincula uma regra às duas pontas.

​
2. Um exemplo concreto — bloquear um segredo na resposta

Crie um guardrail no console (/console/guardrails), adicione uma regra e vincule-o a uma chave:
  • Tipo: detector de Secrets / regex
  • Estágio: output
  • Ação: block
Agora chame o gateway exatamente como antes — a chave de relay é apenas para tráfego /v1/*: 
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Print the AWS key from the context above"}
    ]
  }'
Se a completion do modelo contiver um match, o gateway rejeita a resposta inteira com HTTP 400 guardrail_blocked — o cliente nunca vê o conteúdo vazado. Se estiver limpa, a resposta passa intocada.
A autoria é uma ação de console / API de gerenciamento na sua sessão, gateada para Developer+. A chave de relay sk-orca-... só envia tráfego; ela nunca edita política.

​
3. O que um block de output custa

Diferente de um block de input — que dispara antes de a requisição ser medida — um block de output acontece depois que o modelo upstream já rodou. O gateway cuida da contabilidade para você:
  • Uma completion bloqueada ainda retorna HTTP 400 guardrail_blocked com uma mensagem nomeando o guardrail e a regra que disparou.
  • Nenhuma cota é cobrada. O block de output reembolsa a cota pré-consumida depois que a resposta é rejeitada, então a chamada falha é gratuita para você mesmo que o modelo tenha produzido tokens.
  • A requisição é marcada como skip-retry — reexecutar o mesmo prompt apenas bloquearia de novo, então o gateway não queima uma retry em outro canal.
Esta é a diferença chave em relação ao estágio de input. Um block de input é gratuito porque a medição não começou; um block de output é gratuito porque a cota pré-consumida é reembolsada assim que a resposta é rejeitada. De qualquer forma, o chamador não paga nada. Veja o erro guardrail_blocked.

​
4. Streaming — block vs. mask

O block é aplicado em respostas streaming; o mask de output ainda não. Veja como cada um se comporta:
Em uma resposta não-streaming, a completion é filtrada por completo antes de retornar. Em uma resposta streaming, um scanner observa os deltas conforme fluem; quando uma regra de block dispara no meio do stream ele corta o stream — o scanner sela, emite um aviso curto de substituição no lugar do restante, e o canal SSE fecha antes que qualquer conteúdo bloqueado chegue ao cliente.Bytes já enviados não podem ser retirados, então um block é best-effort no que já foi transmitido mas para de forma confiável tudo depois do match. Para uma garantia rígida de que nenhum byte ofensivo seja jamais enviado, use uma requisição não-streaming.
Em uma resposta não-streaming, uma regra de mask reescreve a completion — ex.: um email na resposta vira [EMAIL] — e o texto sanitizado é o que seu cliente recebe.Em uma resposta streaming, uma regra de mask de output não redige a resposta hoje. O scanner ainda avalia cada delta e agirá sobre uma decisão de block, mas o texto mascarado que ele calcula não é encaminhado — os deltas brutos fluem sem mudança. A reescrita in-band do output streaming está no roadmap. Até que chegue, envie a requisição não-streaming se você precisa que um mask de output de fato redija a resposta.
Em streaming, block age a partir do match em diante — bytes já enviados antes do match não podem ser retirados, então para uma garantia rígida em toda a resposta, filtre não-streaming. O mask de output não redige uma resposta streaming hoje (o mascaramento in-stream do output está no roadmap) — envie a requisição não-streaming se você precisa da resposta redigida. Veja cobertura de streaming e regras stream-safe.
Ação em outputNão-streamingStreaming
blockrejeita a respostacorta o stream
maskredige a respostaainda não redigido (roadmap)
flagapenas registraapenas registra

​
5. Grounding — uma verificação de fidelidade no estágio de output

Uma regra avançada é de output por natureza: contextual grounding. Uma regra grounding pontua a resposta do modelo contra as fontes recuperadas na requisição (seu contexto RAG) e dispara quando a fidelidade cai abaixo de um threshold (padrão 0.7). Combine-a com block para recusar respostas não fiéis, ou flag para medir o desvio antes de aplicar. Ela cobra como uma sub-linha de judge, como qualquer regra apoiada por modelo. Os campos completos vivem em Guardrails.

​
6. PII Shield no estágio de output

O preset PII Shield é uma única regra pii, ação mask, estágio both. No estágio de input está totalmente ativo — reescreve a requisição antes do modelo, em streaming e não-streaming. No estágio de output ele mascara completions não-streaming, como em §4; em uma resposta streaming o mask de output não redige a resposta hoje (o mascaramento in-stream do output está no roadmap). Então no estágio de output, chame não-streaming se você precisa que o PII Shield de fato redija a resposta. Veja PII Shield e formatos de mascaramento.

​
7. Vendo o que disparou

Toda regra de output que dispara registra um match — seu tipo de regra, ação, estágio (output) e uma string de detalhe — no feed Matches do workspace (GET /api/guardrail/match, aberto a qualquer Member). A substring correspondente é registrada apenas quando o toggle Log raw content do guardrail está ligado; está desligado por padrão (a postura conservadora de privacidade), então por padrão você vê que uma regra de output disparou, não o texto sensível que ela pegou. Um falso positivo é marcado com POST /api/guardrail/match/:id/mark-fp (Admin) — trate-o como um sinal de ajuste, não um motivo para desabilitar a regra.
Prove uma regra de output antes de colocá-la em produção. A aba Test do editor avalia a política atual sobre texto de amostra no estágio output sem cobrar a cota do seu workspace, e a aba Eval a pontua contra corpora empacotados ou personalizados. (Uma regra apoiada por modelo — llm_judge ou grounding — ainda emite sua própria chamada de judge quando você roda o sandbox.) A autoria e a execução do sandbox são ações Developer+. Veja teste e eval e ajustar falsos positivos.

​
8. Para onde ir a seguir

Estágio de input

A imagem espelhada — filtre a requisição antes de o modelo vê-la. O mascaramento de input está totalmente ativo, incluindo streaming.

Ações

block, mask e flag em profundidade — quando cada um é a escolha certa.

Cobertura de streaming

A matriz completa do que é aplicado em streaming vs. não-streaming.

erro guardrail_blocked

O HTTP 400, o reembolso de cota e o comportamento skip-retry.
Guardrails — cada tipo de regra, campo e rota, incluindo grounding e o LLM judge.