Saltar al contenido principal
Cuando necesitas enmascarar datos sensibles que lleva un prompt de llm — emails, números de tarjeta, IDs nacionales, secretos — el gateway reescribe cada coincidencia en su lugar antes de que el modelo la vea. Un valor enmascarado se convierte en una etiqueta tipada (jane@acme.com → [EMAIL]), así que el modelo aún lee un prompt coherente mientras el valor en bruto nunca sale de tu espacio de trabajo. Esta página es la mirada enfocada en qué renderiza el enmascarado, cómo cambiar la etiqueta y cómo enmascarar algunas entidades mientras bloqueas otras en una sola regla. Para el motor completo — cada tipo de regla, etapa y ruta — ver la referencia de Guardrails, y para el enmascarado de la solicitud específicamente, Reglas de la etapa de entrada.

​
1. Enmascara datos sensibles que llevan los prompts de llm, con etiquetas tipadas

Una regla pii con la acción mask detecta una entidad y reemplaza cada coincidencia con una etiqueta de redacción tipada — una etiqueta en mayúsculas entre corchetes que nombra qué se eliminó sin revelar el valor:
EntidadEtiqueta renderizada
email[EMAIL]
credit_card[CREDIT_CARD]
ssn[SSN]
El conjunto completo de detectores integrados — email, phone, credit_card, ssn, ip, iban, mac_address, jwt, aws_access_key, api_key_openai, bitcoin_address, más los regionales jp_mynumber, kr_rrn y cn_resident_id — renderiza cada uno su propia etiqueta entre corchetes ([PHONE], [IBAN], [JP_MYNUMBER], y así sucesivamente). La etiqueta es determinista: la misma entidad siempre renderiza la misma etiqueta, así que los prompts downstream permanecen estables y tus logs leen limpiamente.
Las etiquetas tipadas superan a un [REDACTED] genérico en calidad del modelo. El modelo aún sabe que está mirando un email vs. un número de cuenta vs. un número de teléfono, así que puede seguir razonando sobre la forma de los datos — “responde a [EMAIL]” sigue siendo una instrucción accionable — sin sostener nunca el valor real.
El enmascarado de entrada está totalmente activo — el gateway reescribe el prompt antes de que llegue al modelo, con o sin streaming. El enmascarado de salida está activo en respuestas sin streaming también: una regla mask en la etapa de salida reescribe el completado antes de que regrese. Solo el enmascarado de salida en streaming está en el roadmap; en una respuesta con streaming, prefiere block en la etapa de salida. Ver Cobertura de streaming para la matriz exacta de etapa/stream.

​
2. Un ejemplo concreto

Crea la regla en la consola bajo tu propia sesión — la configuración de guardrails requiere Developer+, no una clave de relay. Añade una sola regla pii a un guardrail llamado pii-shield: 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ssn"]
}
Vincúlala a una clave (establece guardrail_id, o márcala como valor por defecto del espacio de trabajo — ver Vincular a una clave), luego llama al gateway con esa clave de relay sk-orca-...: 
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": "Reply to jane@acme.com about her SSN 123-45-6789"}
    ]
  }'
El gateway reescribe el prompt a “Reply to [EMAIL] about her SSN [SSN]” antes de reenviar. El modelo upstream nunca ve la dirección ni el número. Prueba el renderizado exacto en la pestaña Test del editor primero (sin llamada upstream, sin cuota) — ver Pruebas y eval.

​
3. Sobrescribe la etiqueta con mask_with

Las entidades integradas renderizan una etiqueta fija. Las entidades personalizadas — tus propios detectores regex superpuestos sobre el conjunto integrado — te permiten establecer el texto de reemplazo tú mismo con mask_with: 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "custom_entities": [
    {
      "name": "employee_id",
      "pattern": "EMP-[0-9]{6}",
      "mask_with": "[STAFF_ID]"
    }
  ]
}
mask_with es la cadena de reemplazo literal para las coincidencias de esa entidad. EMP-004217 se convierte en [STAFF_ID]. Déjalo vacío y la coincidencia renderiza la etiqueta por defecto [<UPPERCASE_NAME>] — aquí, [EMPLOYEE_ID] — así que un detector personalizado siempre produce una redacción legible y tipada incluso sin sobrescritura.
name (ASCII en minúsculas / dígitos / guion bajo, debe empezar con una letra), pattern (un regex RE2 de Go — tiempo lineal, sin backreferences), checksum opcional (luhn valida números con forma de tarjeta) y mask_with opcional. Hasta 25 entidades personalizadas por regla — cada una es un escaneo sobre el texto completo, así que el tope mantiene la ruta caliente lineal. Ver Entidades PII personalizadas.
Un name fluye sin comillas a los logs de auditoría y el feed de Matches, así que mantenlo en letras ASCII en minúsculas, dígitos y guiones bajos empezando con una letra (p. ej. employee_id, internal_ticket). El validador rechaza cualquier otra cosa.

​
4. Enmascara algunas entidades, bloquea otras — entity_actions

Una sola regla pii puede aplicar diferentes acciones a diferentes entidades vía entity_actions, en vez de apilar tres reglas solapadas. La forma clásica: enmascarar datos de contacto de baja sensibilidad, pero bloquear los campos de alta sensibilidad directamente. 
{
  "type": "pii",
  "stage": "input",
  "action": "mask",
  "entities": ["email", "phone", "ip", "credit_card", "ssn"],
  "entity_actions": {
    "credit_card": "block",
    "ssn": "block"
  }
}
Aquí email, phone e ip siguen el mask de nivel superior de la regla y renderizan [EMAIL] / [PHONE] / [IP]; una coincidencia de credit_card o ssn en cambio bloquea toda la solicitud con HTTP 400 guardrail_blocked.
CampoRegla
ClavesDebe ser una entidad declarada en la regla (integrada o personalizada).
Valoresblock, mask, flag o annotate.
Una solicitud bloqueada no cuesta cuota — un bloqueo en la etapa de entrada se dispara antes de la medición. Una solicitud enmascarada pasa con el texto saneado. Así que una regla puede redactar silenciosamente los campos rutinarios y detener en seco los regulados, con una sola vinculación y sin cambio en la aplicación.

​
5. Mask vs. block vs. flag

El enmascarado es una de las acciones que una regla (o sobrescritura por entidad) puede tomar. Elige según cuánto quieras perturbar el tráfico:

mask

Redacta la coincidencia a una etiqueta tipada y deja pasar la solicitud con el texto saneado. El modelo nunca ve el valor en bruto.

block

Rechaza toda la solicitud con HTTP 400 guardrail_blocked. Nada llega al modelo. Úsalo para datos que nunca deben transitar.

flag

No cambia nada del tráfico — solo registra una coincidencia. Mide con qué frecuencia se dispararía una regla antes de aplicarla.
Un buen despliegue es flag → mask → block: marca para dimensionar el impacto, enmascara una vez que confíes en el detector, y reserva block para los campos que no puedes dejar pasar en absoluto. Ver Acciones y Afinar falsos positivos.

​
6. Verifica qué se enmascaró

Cada regla que se dispara registra una coincidencia en el Feed de coincidencias del espacio de trabajo — tipo de regla, acción, etapa y una cadena de detalle. La propia subcadena coincidente (el email en bruto, el número de tarjeta real) se registra solo cuando Log raw content está activado, que está apagado por defecto — la postura conservadora con la privacidad, ya que todo el punto es mantener los valores en bruto fuera de tus logs.
Activa Log raw content solo cuando genuinamente necesites la subcadena para triaje, y solo por guardrail. Con él apagado, el feed prueba que un [CREDIT_CARD] fue enmascarado sin almacenar nunca el número. El toggle no es retroactivo. Ver Registro y privacidad.

​
7. Dónde ir a continuación

Lee la referencia de Guardrails para el motor completo, o exposición de PII y fuga de secretos para las amenazas que el enmascarado está construido para contener.