Saltar al contenido principal
Las verificaciones de seguridad solo importan si realmente se ejecutan — pero no deberías tener que sacrificar rendimiento por seguridad. Esta página responde la pregunta que los desarrolladores hacen más: ¿la aplicación ralentizará mi agente y cuánto? La respuesta corta: las reglas integradas no cuestan nada medible. Las reglas avanzadas cuestan como máximo una llamada de modelo acotada, concurrente y fail-open. He aquí por qué, y cómo controlarlo.

​
1. Dos clases de verificación

Cada regla de guardrail y cada evaluación del firewall cae en una de dos clases.

​
Verificaciones integradas / deterministas

Las reglas de guardrail de lista de denegación de palabras clave (keyword), expresión regular (regex), detección de PII (pii) y longitud máxima (max_chars) son operaciones locales puras de cadena y regex — sin llamada al modelo, sin salto de red, nada que pueda agotar el tiempo. La evaluación de reglas del firewall (coincidencia de glob de nombre de herramienta, predicados de argumentos, alcance de egress) es lo mismo: determinista y local. En términos prácticos, estas verificaciones añaden latencia despreciable a tu solicitud. Son seguras para ejecutar en la ruta caliente y son de lo que están hechas las plantillas de guardrail integradas.

​
Verificaciones avanzadas / semánticas

Las reglas de proveedor llm_judge, grounding y external delegan la verificación a un modelo o un proveedor. Sí cuestan un round-trip. Tres propiedades acolan ese coste:
  1. Despacho concurrente. Si tu política tiene múltiples reglas avanzadas, se despachan en paralelo — una verificación lenta nunca se serializa detrás de otra.
  2. Tiempo de espera por regla. Cada regla avanzada tiene un tiempo de espera (judge_timeout_ms / grounding_timeout_ms / timeout_ms). La verificación de grounding por defecto es ~3 000 ms; el juez usa un valor configurable (0 → valor por defecto del motor). La regla está acotada — no puede colgar indefinidamente.
  3. Fail-open por defecto. Cuando una regla agota el tiempo o su proveedor devuelve un error, el evento se registra pero la solicitud continúa. Establece judge_fail_open: false (juez) o fail_open: false (externo) para cambiar a fail-closed en su lugar.
Por tanto, el peor caso para cualquier número de reglas avanzadas es el tiempo de espera individual más largo, no la suma de todos los tiempos de espera.

​
2. De un vistazo

Tipo de verificación¿Añade latencia?Cómo está acotada
Lista de denegación keywordDespreciable — escaneo local de cadenaSin red; sin tiempo de espera necesario
regexDespreciable — coincidencia RE2 localSin red; sin tiempo de espera necesario
Detección piiDespreciable — escaneo local de regex/entidadSin red; sin tiempo de espera necesario
max_charsDespreciable — conteo de caracteresSin red; sin tiempo de espera necesario
Evaluación de regla del firewallDespreciable — coincidencia de glob + predicadoSin red; sin tiempo de espera necesario
llm_judgeUna llamada de modelo acotadajudge_timeout_ms; fail-open por defecto
groundingUna llamada de modelo acotadagrounding_timeout_ms (por defecto ~3 000 ms); fail-open por defecto
Proveedor externalUna llamada de proveedor acotadatimeout_ms; fail_open por defecto
Múltiples reglas avanzadasUn round-trip acotado (despacho concurrente)Peor caso = máximo tiempo individual, no la suma

​
3. Dónde en el ciclo de vida de la solicitud se ejecutan las verificaciones

La aplicación no ocurre toda en el mismo punto. El examen de entrada y salida añade tiempo en lugares diferentes: 
Cliente
  │
  ▼
[Examen del guardrail de entrada]     ← añade tiempo AQUÍ, antes del upstream
  │
  ▼
Llamada al modelo upstream
  │
  ▼
[Examen del guardrail de salida]    ← añade tiempo AQUÍ, después de que el modelo responde
  │
  ▼
Cliente
Los guardrails de entrada se ejecutan antes de la llamada al modelo upstream. Una regla de entrada integrada añade una sobrecarga despreciable al inicio. Una regla de entrada avanzada (p. ej. un llm_judge que verifica inyección de prompts) añade una llamada de modelo acotada antes de que comience la llamada al modelo principal. Los guardrails de salida se ejecutan después de que el modelo responde. Una regla de salida integrada añade una sobrecarga despreciable al final. Una regla de salida avanzada (p. ej. grounding verificando fidelidad RAG) añade una llamada acotada después de que ya tienes la respuesta del modelo. La evaluación de reglas del firewall es determinista y ocurre en línea en el enrutamiento de llamadas a herramienta — despreciable, como se indicó anteriormente.
Una solicitud bloqueada no cuesta tokens de modelo y no añade latencia upstream para bloques en la etapa de entrada. Un bloqueo de entrada se dispara antes de la medición y antes de la llamada upstream, así que no pagas ni cuota ni tiempo de round-trip upstream. Un bloqueo en la etapa de salida reembolsa la cuota preconsumida después de que la respuesta se rechaza.

​
4. Cómo los tiempos de espera y fail-open acolan el peor caso

Las reglas avanzadas tienen dos diales: Tiempo de espera — el tiempo de reloj máximo que se permite la verificación. La solicitud espera a lo sumo este tiempo para esa regla. El despacho concurrente significa que este tope aplica por regla, no por política. Si tienes tres reglas llm_judge cada una con un tiempo de espera de 2 000 ms, las tres se ejecutan a la vez y la espera total es ~2 000 ms, no ~6 000 ms. Fail-open vs fail-closed — qué hacer cuando la regla no se completa a tiempo (o el proveedor da error):
ConfiguraciónComportamiento en tiempo de espera / error
fail_open: true (por defecto)Registrar el evento; dejar que la solicitud continúe como si la verificación hubiera pasado
fail_open: falseTratar el tiempo de espera / error como un bloqueo; devolver HTTP 400 guardrail_blocked
Fail-open preserva la disponibilidad al coste de una verificación perdida. Fail-closed preserva la garantía de la política al coste de la disponibilidad si el juez es lento o inalcanzable. Elige según lo que importa más para tu caso de uso.

​
5. Orientación práctica

Mantén las reglas de la ruta caliente integradas. Si tu preocupación principal es PII, fuga de credenciales, longitud de prompt o lista de denegación de palabras clave — todas esas son reglas integradas. No añaden latencia medible y deben ser tu elección por defecto para cualquier verificación que el emparejamiento de texto pueda manejar. Usa llm_judge y grounding donde necesites semántica. Toxicidad, acoso, detección fuera de tema, intención de inyección de prompts y fidelidad RAG son genuinamente difusos — ningún regex los captura de forma confiable. Estos son los casos correctos para una regla avanzada. Acepta que cada una añade una llamada de modelo extra acotada. Ajusta los tiempos de espera a tu presupuesto de latencia. Si tu objetivo de extremo a extremo es 1 000 ms, establece judge_timeout_ms: 800 (o menos) para que el juez no pueda consumir todo tu presupuesto. El tiempo de espera por defecto del motor es un buen punto de partida; redúcelo si tienes requisitos estrictos. Para grounding en la salida, la llamada al modelo ya está hecha. La verificación grounding se ejecuta después de que el modelo upstream responde — la latencia extra es solo en el final, no en el camino crítico para el tiempo hasta el primer token. Esto lo convierte en un lugar de bajo riesgo para añadir aplicación semántica. ¿Múltiples reglas avanzadas? Distribuye el trabajo. Porque las reglas avanzadas se ejecutan concurrentemente, apilar tres reglas llm_judge cuesta aproximadamente lo mismo que una — el tiempo de espera individual más largo determina el tiempo de reloj, no el conteo. Usa esto para capas de verificaciones semánticas sin coste aditivo.

Modos de aplicación

Fail-open vs fail-closed — la referencia completa para ajustar el comportamiento de tu política bajo condiciones de tiempo de espera y error.

Guardrails

Tipos de regla, campos del juez, umbrales de grounding y la referencia completa de configuración de guardrails.
Las reglas integradas son despreciables en cada camino; las reglas avanzadas cuestan una llamada acotada, concurrente y fail-open — ajusta el tiempo de espera y el modo de fallo, y la aplicación no añade latencia incontrolada a tus agentes.