Cómo gestionar el tráfico Unknown en tu app

¿Unknown es un error o un resultado?

Cuando empiezas a clasificar interacciones como Human, Human + AI, Agent o Unknown, el grupo Unknown suele ser más grande de lo que la gente espera. Es tentador tratarlo como una brecha que hay que ocultar, ya sea metiendo Unknown en Human o considerándolo sospechoso. Ambas opciones generan problemas.

Unknown significa que la evidencia disponible no permite una determinación fiable. Una solicitud desde un cliente que no ejecuta JavaScript, una llamada a un endpoint donde no recoges señales, una sesión que terminó tras una sola página: todo eso puede ser perfectamente legítimo, y nada de ello te da suficiente información para saber quién o qué estaba actuando.

Informar Unknown con honestidad es lo que mantiene confiables a las demás clases. Si tu sistema nunca dice Unknown, cada resultado Human es en parte una suposición, y no puedes saber qué parte lo es. Nuestra publicación sobre por qué Unknown es un resultado válido al clasificar tráfico de IA expone el razonamiento con más detalle.

Esta guía cubre cómo gestionar Unknown en la práctica: alternativas explícitas por ruta, las reglas que evitan que se filtre a otras clases, cómo monitorizarlo y cómo reducirlo donde importa.

Paso 1: Nunca asignes Human por defecto

El error más común es una función de clasificación que devuelve Human cuando no encuentra ninguna señal de automatización. Parece razonable y está mal. La ausencia de una señal de bot no es la presencia de una señal humana.

// Wrong: silence becomes Human
function classifyWrong(e: Evidence) {
  if (e.signatureValid) return { actor: "agent", basis: "verified" };
  if (e.declaredAgent) return { actor: "agent", basis: "declared" };
  return { actor: "human", basis: "inferred" };
}

// Right: Human requires positive evidence, otherwise Unknown
function classify(e: Evidence) {
  if (e.signatureValid) return { actor: "agent", basis: "verified" };
  if (e.declaredAgent) return { actor: "agent", basis: "declared" };
  if (e.interactiveSession) return { actor: "human", basis: "inferred" };
  return { actor: "unknown", basis: "unknown" };
}

Aplica la misma regla en todos los lugares donde se producen resultados: timeouts, errores, entradas de caché obsoletas y telemetría ausente producen Unknown. Escribe una prueba para cada una de estas rutas para que el comportamiento no se desvíe en silencio. El ejemplo de abajo usa el Node.js test runner integrado.

import { test } from "node:test";
import assert from "node:assert/strict";

test("missing evidence is unknown, not human", () => {
  const r = classify({ signatureValid: false, declaredAgent: false, interactiveSession: false });
  assert.equal(r.actor, "unknown");
});

Paso 2: Dale a cada ruta una alternativa explícita

Unknown necesita un comportamiento definido, y el comportamiento adecuado depende de la ruta. Decídelo por ruta, escríbelo y mantenlo en la configuración. Para ver cómo encajan estas alternativas en un modelo de políticas más amplio, consulta diseñar políticas a nivel de app para humanos y agentes de IA.

El patrón es simple. En rutas de bajo riesgo, Unknown se comporta como tráfico normal. En rutas de alto riesgo, Unknown recibe la misma protección que la ruta ya tiene. En ninguno de los dos casos el resultado del actor empeora la situación para un usuario no clasificado pero legítimo.

type Fallback = "allow" | "standard_limit" | "existing_checks" | "review";

const unknownFallback: Record<string, Fallback> = {
  "GET /docs/*": "allow",
  "GET /api/catalog": "standard_limit",
  "POST /signup": "existing_checks",
  "POST /account/password": "existing_checks",
  "POST /exports": "review",
};

Paso 3: Trata timeouts y errores de la misma manera

La evaluación del actor está en la ruta de la solicitud, así que debe tener un presupuesto de tiempo estricto. Cuando se supera ese presupuesto, produce Unknown y aplica la alternativa de la ruta. Nunca bloquees una solicitud porque la evaluación fue lenta.

async function withBudget<T>(work: Promise<T>, ms: number, onTimeout: T): Promise<T> {
  let timer: NodeJS.Timeout;
  const timeout = new Promise<T>((resolve) => {
    timer = setTimeout(() => resolve(onTimeout), ms);
  });
  try {
    return await Promise.race([work, timeout]);
  } finally {
    clearTimeout(timer!);
  }
}

const result = await withBudget(evaluateActor(req), 150, { actor: "unknown", basis: "unknown" });

Registra por qué un resultado es Unknown: falta de evidencia, timeout, error de evaluación o evidencia obsoleta. Esos motivos te dicen qué hay que corregir.

Paso 4: No trates Unknown como sospechoso

Unknown no es una puntuación de riesgo. Muchos clientes legítimos serán siempre Unknown en algunas rutas: herramientas de línea de comandos, integraciones del lado del servidor sin firmas, herramientas de accesibilidad, navegadores centrados en la privacidad y lectores de feeds simples. Incluso los grandes operadores de IA identifican hoy sobre todo sus fetchers mediante user agent y rangos de IP publicados. La documentación del crawler de OpenAI, por ejemplo, enumera una cadena de user agent y un archivo de direcciones IP publicadas para cada uno de sus bots a fecha de noviembre de 2026.

Si quieres actuar ante un comportamiento sospechoso, basarlo en conductas que puedas describir, como tasas de solicitudes, patrones de fallos de inicio de sesión o informes de abuso, con su propia evidencia. Mantén esa lógica separada de la clase del actor para que ninguna distorsione a la otra.

Paso 5: ¿Cómo monitorizas tu tasa de Unknown?

La tasa de Unknown es la proporción de interacciones clasificadas como Unknown. Haz seguimiento por ruta, por contexto de integración y a lo largo del tiempo. Es una de las métricas de salud más útiles que tienes.

type Row = { route: string; actor: string };

export function unknownRate(rows: Row[]) {
  const byRoute = new Map<string, { total: number; unknown: number }>();
  for (const r of rows) {
    const s = byRoute.get(r.route) ?? { total: 0, unknown: 0 };
    s.total += 1;
    if (r.actor === "unknown") s.unknown += 1;
    byRoute.set(r.route, s);
  }
  return [...byRoute].map(([route, s]) => ({ route, rate: s.unknown / s.total, total: s.total }));
}

Lo que indican los números:

• Una tasa alta y estable en una ruta suele significar que te falta una señal ahí. Una página que nunca carga tu integración de navegador, o una API que nunca ve solicitudes firmadas, se mantendrá mayoritariamente en Unknown.
• Un aumento repentino suele significar que algo cambió en tu stack, por ejemplo un lanzamiento que eliminó un header, una regla de CDN que quita headers de firma, o un cambio en el frontend que dejó de enviar las declaraciones de tu app.
• Una caída repentina también merece revisión. Si Unknown baja mientras Human sube, confirma que llegó nueva evidencia en lugar de que una alternativa haya cambiado en silencio.

Activa alertas por cambios bruscos, no por niveles absolutos. Cada aplicación tiene su propio normal.

Paso 6: ¿Cómo reduces Unknown donde importa?

No necesitas llevar Unknown a cero. Necesitas suficiente evidencia en las rutas donde importan las decisiones. Trabaja en ellas por orden de impacto:

1. Añade evidencia primero en las rutas de alto impacto. Si los cambios de cuenta son mayoritariamente Unknown, ahí es donde una integración de navegador o una comprobación del lado del servidor aporta valor.
2. Invita a los clientes automatizados a identificarse. Publica documentación para tu API que explique cómo los agentes pueden firmar solicitudes con HTTP Message Signatures y las convenciones de IETF Web Bot Auth, y ofrece a los clientes verificados una mejor experiencia, como límites más altos o respuestas estructuradas. Los clientes que puedan verificarse empezarán a hacerlo.
3. Usa el conocimiento de tu propia aplicación. Si los usuarios interactúan con tu asistente integrado, regístralo como una declaración. Tu app suele saber más que la red.
4. Arregla la infraestructura. Asegúrate de que los proxies reenvían los headers en los que confías y de que la evaluación tiene suficiente presupuesto de tiempo para completarse.

Para ver de forma práctica qué señales sacan el tráfico de Unknown, lee cómo saber si el tráfico de un sitio web proviene de agentes de IA.

Paso 7: Muestra Unknown con honestidad en los paneles

Muestra Unknown como su propia serie, con el mismo peso visual que las otras clases. No lo ocultes en una categoría de "otros" y no lo colorees como una alerta. Cuando las partes interesadas ven una cuota grande de Unknown, la reacción correcta es "dónde necesitamos más evidencia", no "dónde están los bots".

Paso 8: Revisa Unknown con resultados, no con suposiciones

Cada pocas semanas, toma una muestra de interacciones Unknown de tus rutas más importantes y revisa qué ocurrió realmente. ¿La sesión completó una compra, creó un proyecto, leyó tres artículos o falló repetidamente al iniciar sesión? Los resultados te dicen qué tipo de tráfico hay en el grupo sin forzarle una etiqueta prematura.

Agrupa lo que encuentres en tres categorías prácticas:

1. Legítimo y de bajo riesgo. Lectores de feeds, vistas previas de enlaces, herramientas de monitorización y personas con ajustes de privacidad. Mantén la alternativa de la ruta tal como está.
2. Automatización legítima que podría identificarse. Integraciones y agentes que usarían encantados una ruta estructurada o firmarían solicitudes si les ofrecieras una. Publica orientación y ponte en contacto donde puedas.
3. Comportamiento que necesita su propio control. Patrones de credential stuffing o scraping, ambos catalogados en el proyecto OWASP Automated Threats to Web Applications. Aborda esto con controles basados en comportamiento que tengan su propia evidencia, como tasas de fallo de inicio de sesión, y manténlos separados de la clase del actor.

Esta revisión mantiene tus alternativas ancladas en tu tráfico real y te da una lista clara de dónde añadir evidencia después.

Preguntas comunes

¿Unknown debe contar para los límites de tasa? Usa tus límites estándar. El rate limiting por clase está bien para agentes verificados, que pueden obtener límites más altos, pero Unknown debe recibir el límite normal, no uno punitivo.

¿Podemos challenge a los usuarios Unknown? Solo donde la ruta ya challenge a todo el mundo en esa situación. Añadir un challenge solo porque el resultado es Unknown penaliza a usuarios legítimos cuyos clientes envían menos señales.

¿Unknown se reducirá a medida que maduren los estándares? A medida que más clientes automatizados firmen solicitudes, más tráfico de agentes pasará de Unknown o declarado a verificado. Tu monitorización mostrará ese cambio ruta por ruta.

Dónde encaja Proof of Actor

Proof of Actor informa Unknown como un resultado de primera clase, con el motivo, y nunca lo convierte en Human. Tu aplicación elige la alternativa para cada ruta, y la analítica muestra dónde termina la cobertura para que puedas añadir evidencia donde importa.

Para configurarlo en una aplicación de producción con nuestro equipo, solicita acceso anticipado. Para entender exactamente qué puede establecer la evidencia, lee Detection & Limitations.

Fuentes

• RFC 9421: HTTP Message Signatures: el estándar que los clientes automatizados pueden usar para firmar solicitudes
• draft-ietf-webbotauth-httpsig-protocol: borrador de IETF Web Bot Auth para tráfico automatizado firmado (trabajo en curso a fecha de noviembre de 2026)
• OpenAI: Overview of OpenAI Crawlers: cadenas de user agent y archivos de direcciones IP publicadas para los bots de OpenAI
• OWASP Automated Threats to Web Applications: taxonomía de amenazas automatizadas como credential stuffing y scraping
• Node.js test runner: el módulo node:test usado en el ejemplo