Saltar al contenido principal
Tienes una lista de términos que nunca deben llegar a un modelo ni regresar de uno — el nombre de un competidor, un nombre en clave interno, un insulto prohibido, un producto que aún no se anuncia. El control más rápido para eso es una denylist de keywords: una lista de términos literales que el gateway escanea en cada llamada y luego bloquea, enmascara o marca. Este es un aterrizaje enfocado para el caso de uso de términos prohibidos. Para el motor de guardrails completo — cada tipo de regla, campo y ruta — ver la referencia de Guardrails.

​
1. El caso de uso de filtro de palabras sensibles en el gateway de IA

Una regla keyword es la regla más simple del motor: le das una lista de términos, y el gateway coincide con cualquiera de ellos contra el texto en una etapa. La coincidencia es por subcadena sin distinguir mayúsculas y minúsculas — BadWord, badword y BADWORD coinciden todos, y el término coincide incluso cuando está embebido en una palabra más larga (así class también coincide con classic). Cada término se trata como una cadena literal, no un patrón; no escapas metacaracteres regex. Guarda la regla una vez en la consola, vincula el guardrail a cualquier clave API (o márcalo como valor por defecto del espacio de trabajo), y cada llamada en esa clave se examina sin cambio de SDK y sin redespliegue. La política vive en el gateway, no en tu aplicación — tu app sigue llamando a /v1/chat/completions exactamente como antes.
Recurre a una regla keyword cuando tu denylist es un conjunto finito de términos literales. Cuando necesites comodines, límites de palabra o estructura (un formato de SKU, una forma de número de pedido), usa un detector regex en su lugar.

​
2. Crea la regla en la consola

Cada paso aquí es una acción de consola bajo tu propia sesión. Crear y editar guardrails requiere Developer+ en el espacio de trabajo. Solo la llamada final /v1/* usa una clave de relay sk-orca-....
1

Crea un guardrail

En la consola, abre Guardrails y haz clic en New guardrail. Nómbralo (≤ 64 caracteres), p. ej. banned-terms.
2

Añade una regla keyword

Añade una regla:
  • Tipo: Keyword denylist (keyword)
  • Etapa: Both (solicitud y respuesta)
  • Acción: Block
  • Keywords: tus términos prohibidos, uno por fila
Guarda.
3

Pruébalo

Abre la pestaña Test, pega una muestra que contenga un término prohibido, elige una etapa y ejecuta la política localmente — sin llamada upstream, sin cuota (ver §5).
4

Vincula una clave

Edita una clave API y elige banned-terms del desplegable Guardrail (establece guardrail_id en la clave), o marca el guardrail como valor por defecto del espacio de trabajo. Ver Vincular a una clave y Valor por defecto de cuenta.
El JSON de la regla es exactamente lo que esperarías: 
{
  "type": "keyword",
  "stage": "both",
  "action": "block",
  "keywords": ["project-orca", "competitor-name", "unannounced-sku"]
}

​
3. Elige la acción

Una regla keyword elige una acción por regla:
Cualquier coincidencia rechaza la solicitud con HTTP 400 guardrail_blocked. Una solicitud bloqueada no cuesta cuota — un bloqueo en la etapa de entrada se dispara antes de la medición; un bloqueo en la etapa de salida reembolsa la cuota preconsumida — y se marca como skip-retry. Úsalo para términos que nunca deben pasar en ninguna dirección. Ver el error guardrail_blocked.
Cada coincidencia se reemplaza en su lugar con una etiqueta de redacción y la solicitud continúa con el texto saneado — el modelo upstream nunca ve el término original. Ver Acciones.
Registra una coincidencia y no cambia nada del tráfico. Úsalo para medir con qué frecuencia aparece un término antes de pasar a la aplicación.
Envuelve el texto coincidente en delimitadores (p. ej. ⟦UNTRUSTED⟧…⟦/UNTRUSTED⟧) para que el modelo lo trate como datos, no instrucciones — una defensa de inyección de prompts en la etapa de entrada. El texto aún llega al modelo, solo que vallado. Ver Acciones.
La etapa importa. input escanea la solicitud del llamador, output escanea la respuesta del modelo, both escanea cada lado independientemente. Un término prohibido que tus usuarios escriben y uno que un modelo podría emitir son problemas diferentes — elige la(s) etapa(s) que encajen. Ver Reglas de la etapa de entrada y Reglas de la etapa de salida.

​
4. Cobertura de streaming

La acción que eliges interactúa con si la respuesta hace streaming:
AcciónSin streamingCon streaming
block (salida)AplicadoAplicado — el escáner corta el stream
mask (salida)AplicadoAún no — la decisión de bloqueo se honra, el texto enmascarado no se reenvía (roadmap)
Las reglas de la etapa de entrada se ejecutan antes de la llamada upstream, así que no se ven afectadas por el streaming — un mask de entrada sanea la solicitud haga o no streaming la respuesta. Un block de término prohibido obtiene cobertura completa en cualquier caso. Un mask de salida, sin embargo, solo redacta en respuestas sin streaming hoy: en una respuesta con streaming el escáner aún actúa sobre la decisión de bloqueo, pero la reescritura en banda del texto transmitido está en el roadmap, no activa. Ver Cobertura de streaming.

​
5. Prueba antes de vincular

Prueba que la regla hace lo que esperas antes de que cualquier clave la apunte. Abre la pestaña Test dentro del editor, pega una muestra, elige la etapa y ejecuta: 
Tell me about Project-Orca and our competitor-name
El sandbox evalúa la política actual localmente y devuelve el veredicto — nada se envía upstream, nada se mide. Con una acción block la muestra es rechazada; con mask el texto renderizado regresa con cada término redactado. Para una rejilla A/B contra un corpus — para confirmar que una denylist captura lo que debe sin marcar tráfico benigno — el arnés de Eval vive una pestaña al lado.

​
6. Envía una solicitud

Usando una clave vinculada a banned-terms, llama a OrcaRouter exactamente como antes — sin nuevas cabeceras, sin cambio de SDK: 
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": "Summarize Project-Orca for me"}
    ]
  }'
Con una acción block la llamada es rechazada con HTTP 400 guardrail_blocked antes de que llegue jamás al modelo. Cambia la acción a mask y el término se redacta en su lugar antes de reenviar en su lugar.

​
7. Ve qué se disparó

Cada regla que se dispara registra una coincidencia — tipo de regla, acción, etapa y una cadena de detalle (para reglas keyword, cuántos términos coincidieron) — que aparece en el feed Matches del espacio de trabajo.
El término coincidente en sí se registra solo cuando Log raw content está activado, que está apagado por defecto — la postura conservadora con la privacidad. Con él apagado todavía ves que una regla keyword se disparó y con qué frecuencia, solo que no el término literal. Actívalo por guardrail cuando necesites la subcadena para triaje; el ajuste no es retroactivo. Ver Feed de coincidencias y Registro y privacidad.
Si un término benigno sigue coincidiendo (una entrada de denylist que es una subcadena de una palabra común), márcalo como falso positivo desde el feed de Matches y acota la entrada. Ver Afinar falsos positivos.

​
8. Dónde ir a continuación

Detectores regex

Coincide con patrones estructurados — SKUs, números de pedido, formatos — cuando una denylist literal no es suficiente.

Seguridad de marca

Presets de profanidad, menciones a competidores y seguridad infantil construidos sobre reglas keyword.

Acciones

Cómo difieren block, mask y flag y cuándo usar cada una.

Referencia de Guardrails

El motor completo — cada tipo de regla, campo y ruta.
Una denylist de keywords gobierna contenido. Para gobernar las llamadas a herramienta de un agente — denegar acciones destructivas, redactar argumentos de llamada a herramienta, requerir aprobación — usa el Firewall. Para políticas difusas que ninguna lista literal puede expresar (toxicidad, fuera de tema, intención de inyección), una regla llm_judge ejecuta una verificación semántica contra un modelo del espacio de trabajo.