Gating por confianza y escalado a una persona

La página anterior sostiene que el código debería poseer el umbral. Esta página trata de lo que el umbral divide: las tres franjas a cada lado.

Tres franjas, no dos

Los proyectos reales rara vez lo plantean como «automático o no». La forma común es la de tres franjas:

La tercera franja es fácil de pasar por alto y es la más barata de las tres. «No mirarlo» y «que una persona le eche un vistazo» se diferencian en una persona.

Una implementación de triaje es típica: avisa solo cuando P(SEV1) + P(SEV2) ≥ 0.80; descarta por debajo de 0.20 solo cuando una comprobación de accionabilidad también lo contradice; envía la franja media a una persona.

La franja media es donde viven los problemas de verdad

En cuanto existen las tres franjas, todas las preguntas difíciles se trasladan a la del medio:

Es capacidad humana, no capacidad ociosa. Cuanto más ancha es la franja, más escalados hay y más atiende una persona. Una tasa de escalado del 9% suena baja, hasta que la tasa base es de miles al día.

Necesita una salvaguarda, o se queda atascada en silencio. Una vez que le entregas una decisión a una persona, no pasa nada hasta que una persona mira. En un panel eso se ve exactamente igual que «todo va bien». La respuesta de la herramienta de triaje es tajante: si no hay acuse de recibo en 15 minutos, avisa igual. Mejor despertar a alguien que dejar que un P1 se quede en la cola.

La condición de escalado también puede fallar. Una puerta de autonomía dentro de un agente continúa solo cuando un Choice supera 0.6 y un Noul de seguridad de autonomía supera 0.5; en caso contrario, devuelve el turno a la persona. Ambos números deben pasar — porque «qué debo hacer» y «esto es seguro» son preguntas distintas, y una sola confianza no puede responder a las dos con honestidad.

Fijar el umbral: primero mide

Elegir 0.8 al azar es el enfoque más común y el que más probabilidades tiene de volverse ruido tres meses después. El enfoque reproducible es medir, con tus propios datos etiquetados, el umbral necesario para alcanzar tu precisión objetivo.

Un ejemplo público: con 0.7 como puerta de baja confianza, una corrida sobre n=130 atrapó 3 de 3 clasificaciones erróneas con una tasa de escalado del 9%. La muestra es pequeña. Su valor no es el 0.7, sino que esto es cómo debería reportarse un número así: el tamaño de la muestra, la tasa de escalado y qué se atrapó.

La latencia es el riesgo subestimado

Los números medidos de la herramienta de triaje merecen su propia tabla:

p95 es 3.5× p50. Eso significa que la cola importa más que la media — porque la política de timeout se dispara en la cola, y cuando se dispara estás en la rama de respaldo, no en la que diseñaste. La llamada más lenta quedó a 151 ms del timeout, es decir, el determinismo del sistema dependía de una moneda que resultó no caer mal.

Así que los sistemas de gating suelen fallar no por «juzgar mal», sino por agotar el tiempo y tomar el respaldo. Prueba el respaldo de forma independiente de la ruta principal.

Dos direcciones de respaldo, ambas correctas

Cuando algo falla, las implementaciones públicas se dividen en dos bandos, y los dos tienen razón:

• fail-closed: un juez de permisos deniega ante un timeout o un error. Una puerta de seguridad tiene que funcionar así — una puerta de seguridad fail-open es un agujero silencioso.
• fail-open: un hook Stop de Claude Code permite ante cualquier error. Una puerta de eficiencia tiene que funcionar así — una puerta de eficiencia fail-closed bloquea todo el flujo.

El criterio no es «cuál es más seguro», sino qué coste es mayor: un bloqueo en falso o un bloqueo omitido. Y hay que decidirlo cuando escribes el código, porque lo que determina es la ruta de excepción, no la principal.

En una frase

En un diseño de tres franjas, el trabajo está en la franja media: su anchura es un coste, su salvaguarda es una propiedad de fiabilidad. Diseña ambas de forma explícita en lugar de dejarlas por defecto.