De dos APIs a un Smart API Router: reglas, una puerta neuronal y Deep Analyze tras un solo endpoint

IngenieríaJohn Silver9 min de lectura

Actualizado el 2026-10-17: marcada como entrada histórica, con una referencia a la arquitectura actual; se eliminaron los límites de los planes y las cifras que ya no valen.

Entrada histórica. Describe el router tal como era el 2026-09-12: el modelo neuronal, el nivel Deep Analyze y los límites de los planes de esa fecha. Desde el 12 de octubre de 2026 la comprobación en la nube usa Galvanize 2 (umbral 0,662) y los niveles del router son rules, advanced y deep. Para los planes y límites actuales, consulta precios.

Hasta esta semana, zn ofrecía dos APIs. Elegías una por petición y los límites de tu plan estaban repartidos entre ambas. Era un impuesto de diseño en cada integración: elegir mal daba una falsa sensación de seguridad, y elegir bien exigía entender nuestras tripas mejor de lo que deberías tener que entenderlas.

Hoy hay un solo endpoint. POST /analyze enruta cada petición por tres capas escalonadas — reglas deterministas, la puerta neuronal y Deep Analyze — y te dice cuál decidió.

TL;DR

  • POST /analyze es ahora un Smart API Router (SAR): Nivel 1 reglas deterministas (<50 µs), Nivel 2 neural int8 (~15–18 ms), Nivel 3 Deep Analyze (mmBERT v8, ~166 ms en caliente) para la banda ambigua.
  • /v30/analyze sigue funcionando como alias de compatibilidad. La ruta de producto POST /prod/analyze se mantiene solo-reglas para quien quiera la puerta de latencia ultrabaja.
  • El router es fail-open: si Deep Analyze expira (presupuesto de 6 s) o falla, sigues recibiendo el veredicto neuronal. Una puerta de seguridad nunca debe convertirse en la caída.
  • Los límites de los planes cambiaron después de esta entrada. Los actuales están en la página de precios.
  • No guardamos el texto que envías en ningún plan, salvo que actives el Modo Contributor. Guardamos metadatos de evidencia, incluida una huella SHA-256 del input, durante 90 días. La respuesta incluye tier, decided_by, latency_ms y un evidence_id que puedes auditar.

Por qué dos APIs era la forma equivocada

El primer endpoint, POST /analyze, es un motor de reglas deterministas: normalización más un catálogo de patrones de inyección (pi-direct y compañía). Responde en microsegundos, es trivialmente auditable y, cuando una regla salta, casi nunca se equivoca. Pero las reglas solo cazan lo que ya has visto.

El segundo endpoint, POST /v30/analyze, ejecuta una puerta neuronal: un transformer multilingüe, exportado a ONNX y cuantizado a int8, que puntúa el texto crudo y bloquea por encima de un umbral calibrado (τ = 0,950 tras la pasada de endurecimiento multilingüe). El intercambio es otro: ~15–18 ms p50 en CPU, cobertura muchísimo mejor, y aún así lejos del coste y la latencia de un guard basado en LLM.

Ambos son productos honestos. Juntos eran una mala interfaz. Los clientes tenían que saber en qué modelo de amenaza estaban para elegir endpoint en cada llamada, las cuotas estaban partidas y la evidencia de los dos caminos no era directamente comparable. En la práctica, la gente acababa usando el camino rápido y perdiendo en silencio la cobertura neuronal que estaba pagando.

Un endpoint, tres cerebros

El router decide por petición, a la vista de todos:

  1. Nivel 1 — Reglas. Normaliza, busca patrones deterministas. Si una regla salta, devuelve. Coste: microsegundos.
  2. Nivel 2 — neural. Si las reglas no concluyen, puntúa con el modelo int8. Los casos con alta confianza de ser benignos o ataques se resuelven aquí.
  3. Nivel 3 — Deep Analyze. Solo cuando la puntuación neuronal cae en la banda incierta (0,50–0,935) la petición va a Deep Analyze, el modelo mmBERT v8 que existe exactamente para eso: texto que parece benigno a un encoder pequeño pero merece una segunda opinión.

La fusión del veredicto es simple a propósito: el router combina la puntuación neuronal con la de Deep Analyze y bloquea a partir de 0,935. Cada respuesta lleva ahora tier (rules, advanced, deep), decided_by, latency_ms y evidence_id, para que midas tu propio tráfico por camino de decisión.

Antes: dos endpoints separados. Después: un endpoint Analyze enrutado por el Smart API Router entre reglas, neural y Deep AnalyzeEl panel superior muestra los antiguos POST /analyze de reglas y POST /v30/analyze neural obligando al cliente a elegir. El panel inferior muestra un único POST /analyze enrutado por el Smart API Router al Nivel 1 reglas bajo 50 microsegundos, Nivel 2 int8 unos 15 milisegundos y Nivel 3 Deep Analyze mmBERT unos 166 milisegundos en caliente, con presupuesto fail-open de 6 segundos y respuesta con tier, latencia y evidence id.FIGURA 1: DOS ENDPOINTS → UN SMART API ROUTERANTES · ELIGE POR PETICIÓNPOST /analyzeReglas deterministas · <50 µs · solo cobertura de patronesPOST /v30/analyzeneural int8 · ~15–18 ms · cuotas partidasDESPUÉS · UNA LLAMADAPOST /analyze→ SMART API ROUTERNIVEL 1 · REGLAS<50 µs · deterministapatrones exactos, auditableNIVEL 2 · NEURAL~15–18 ms · ONNX int8multilingüe, alta coberturaNIVEL 3 · DEEP ANALYZE~166 ms caliente · mmBERT v8solo la banda 0,50–0,935respuesta: veredicto · tier · decided_by · latency_ms · evidence_idfail-open: Deep tiene 6 s, después responde el veredicto neuronal

Deep Analyze: el nivel que tuvo que ganarse su sitio

Deep Analyze es nuestro detector multilingüe mmBERT v8, exportado a ONNX int8 y servido desde una Lambda de contenedor (3 GB de memoria, 4 GB efímeros, techo de 120 s). En caliente responde en ~166 ms. Los arranques en frío tardan ~24 s, y por eso nunca está en el borde síncrono de un camino desprotegido: solo se ejecuta para la banda ambigua, dentro de un presupuesto duro de 6 s del router, y el router vuelve al veredicto neuronal si no llega.

Conseguir un modelo lo bastante bueno para merecer ese hueco llevó más que el propio router. Nuestros posts anteriores contaron la historia completa: el dataset que nos mentía y diecisiete entrenamientos fallidos donde el modelo puntuaba 0,498–0,509 con todo porque la pérdida nunca veía una etiqueta. El arreglo fue ordinario —entrenamiento supervisado de extremo a extremo, congelar el split, dejar de ajustar sobre el test— y el resultado fue una puerta que funcionaba de extremo a extremo sobre el split de test congelado.

Escalera de decisión y presupuesto de latencia en escala logarítmica: reglas bajo 50 microsegundos, la puerta neuronal unos 15 milisegundos, Deep Analyze unos 166 milisegundos, presupuesto del router 6 segundosEje logarítmico de 10 microsegundos a 10 segundos. La barra del Nivel 1 reglas termina cerca de 50 microsegundos. La del Nivel 2 neural cerca de 15 milisegundos. La del Nivel 3 Deep Analyze cerca de 166 milisegundos. Una línea discontinua marca el presupuesto fail-open de 6 segundos. Deep Analyze solo se ejecuta cuando la puntuación neuronal cae en la banda 0,50 a 0,935; 0,935 o más bloquea.FIGURA 2: ESCALERA DE DECISIÓN · PRESUPUESTO (ESCALA LOG)banda neuronal 0,50–0,935 → Deep Analyze · puntuación ≥0,935 → bloquearNIVEL 1 · REGLAScoincidencia concluyente~50 µsNIVEL 2 · NEURALONNX int8, p50~15–18 msNIVEL 3 · DEEP ANALYZEmmBERT v8, caliente~166 msLÍMITE FAIL-OPEN 6 s10 µs100 µs1 ms10 ms100 ms1 s10 sCada nivel registra tier, decided_by, latency_ms y evidence_id.Fail-open: un timeout de Deep nunca se convierte en petición fallida.

Desplegarlo sin romper producción

Un router delante de cada petición da miedo de desplegar. Lo hicimos en tres movimientos: primero modo sombra, donde el camino en vivo y el router decidían y solo comparábamos —Deep Analyze puntuando junto al veredicto de producción sin tocarlo—. Después canary al 50 % tras el alias, con alarmas de CloudWatch sobre errores de Lambda, fail-opens de Deep y latencia p99, conectadas a SNS. Después el 100 %.

Las garantías aburridas son lo importante: el rollback es cambiar la versión del alias, el router tiene 39/39 tests unitarios incluyendo una suite de equivalencia que demuestra que el camino enrutado devuelve el mismo veredicto que la llamada directa, y el fail-open se ejercita en tests, no se espera que funcione.

Planes

Los límites de los planes descritos cuando se publicó esta entrada han cambiado. Consulta precios para ver los planes y cuotas actuales.

La retención no cambia: el input solo se guarda en el Modo Contributor. Guardamos el veredicto, el nivel y los hashes necesarios para el Evidence Vault, con 90 días de retención. El Modo Contributor es opcional y es el único caso en que se almacena input, anonimizado, y solo porque aceptas la telemetría comunitaria para entrenar el modelo. Si no activas el Modo Contributor, no usamos tus prompts para entrenar. (Editado el 15 de octubre de 2026.)

Qué cambia para ti

Si llamabas a /v30/analyze, no se rompe nada: mismo camino, misma forma de respuesta, ahora con tier y decided_by diciéndote de dónde salió cada veredicto. Si llamabas a /analyze esperando solo reglas, pásate a /prod/analyze para el camino determinista —o quédate y obtén el router completo por el mismo precio. Una clave, un endpoint, tres cerebros.

Si quieres ver el camino de decisión sobre tu propio tráfico antes de fiarte, el plan Free (10.000 llamadas al mes) sirve para eso: un POST, una clave de API y evidencia de cada bloqueo.

Actualizado el 14 de octubre de 2026: el texto sobre tratamiento de datos se ha reformulado para describir lo que hacen hoy el paquete y la API.

Compartir