# Tu triage no necesita un modelo de chat

> Enrutar, etiquetar, decidir elegibilidad y moderar son el trabajo de IA de mayor volumen de casi cualquier producto, y el más barato de hacer mal. Un modelo System One los responde con una probabilidad calibrada — y la economía no está ni cerca.

2026-09-20 · https://synsema.com/es/blog/tu-triage-no-necesita-un-modelo-de-chat


Contá las llamadas al modelo que hace tu producto en una semana y ordenalas por para qué fueron. En la mayoría de los productos la cola larga no es la parte impresionante — no es la respuesta que lee el cliente ni el resumen del hilo. Son decisiones: a qué cola va esto, si es un pedido de reembolso, qué tan urgente es, si este mensaje necesita una persona, si esta publicación rompe una regla.

Ese trabajo tiene tres propiedades que hacen del modelo de chat una elección rara: la respuesta pertenece a un conjunto que ya conocés, el volumen es alto, y equivocarse sale caro de una manera aburrida.

## Qué estás pagando hoy

Un modelo de chat responde una clasificación con una oración. Así que pagás los tokens de salida, y después pagás otra vez en ingeniería: un prompt que ruega por JSON, un parser, un normalizador para "Billing." contra `billing`, un reintento para las veces que se disculpa en vez de responder, y una "confianza" que el modelo escribió en prosa porque nada en su entrenamiento ató ese número a con qué frecuencia acierta.

Y después pagás una tercera vez, en las decisiones mismas: sin una medida honesta de incertidumbre, o mandás todo a una persona (y no automatizás nada) o automatizás todo (y te comés los errores).

## Cuánto cuesta, en cambio, un modelo System One

**Jev**, de TypeSafe, el primer modelo de esta clase, no genera texto. Toma un estado y preguntas tipadas y devuelve respuestas tipadas con probabilidades calibradas en una sola pasada paralela. Las cifras que publica TypeSafe son 70–500 ms de punta a punta — 40–200× más rápido que los modelos frontera en tareas comparables — a **0,042 dólares por millón de tokens de entrada, con la salida gratis**.

Nuestra propia medición, a través del motor contra `jev-1.13.0`, es sobre la forma de la llamada más que sobre el precio: hacer ocho preguntas en **un bloque** en vez de ocho llamadas sueltas fue **7,6× más rápido y usó 4,9× menos tokens de entrada**, y la latencia se mantuvo plana — unos 0,8 s tanto con una pregunta como con cuarenta. El estado se lee una vez y las preguntas se responden contra él en paralelo.

Juntá esas dos cosas para una bandeja de soporte con 50.000 tickets al mes, cada ticket de unos cientos de tokens y con seis preguntas hechas en un bloque, y la línea del modelo en esa carga queda en dólares de un dígito al mes. Lo importante no es la cifra exacta — tus tickets son más largos o más cortos que mi supuesto —, sino que el costo de la decisión deja de ser una razón para no automatizarla, y la restricción vuelve adonde corresponde: qué tan seguro necesitás estar antes de que una máquina actúe.

## El número que destraba la automatización

Este es el cambio real, y no es el precio. Cada respuesta viene con una probabilidad calibrada y, en las elecciones y las escalas, una confianza — qué tan concentrada está la distribución:

```synsema
when v.team.available and v.team.choice != nothing and confidence of v.team >= 0.9
    route(v.team.choice)
otherwise
    approve "Route to " + text(v.team.choice) + "?"
```

Esa única línea es el control de negocio que antes no podías escribir. Arriba de la línea actúa la máquina; abajo lo ve una persona. El umbral lo movés con datos — medí qué proporción de los 0,9 acertó — en vez de discutir si el modelo "parecía seguro".

Dos detalles que medimos y que protegen esa misma línea. Primero: una elección **tiene** que elegir algo; una pregunta sobre horarios de atención, con solo *billing* y *technical* como opciones, respondió `technical` con 0,69 — derecho por una compuerta de 0,5. Agregar una opción de escape explícita ("ninguna de estas encaja") convirtió eso en `none` con 1,00 y no costó nada en los casos claros. Segundo: cuando el proveedor no está disponible, la respuesta vuelve con confianza 0 y sin valor, nunca con un número inventado, así que una caída manda la cola a las personas por sí sola en lugar de decidir mal, en silencio y a toda velocidad.

## Qué se queda con el modelo de chat

La respuesta que lee el cliente. El resumen de un hilo largo. La explicación de por qué se rechazó algo. Todo aquello cuya salida es prosa para una persona. Los dos corren al lado — el juez decide, el modelo de lenguaje escribe — y en la Plataforma Synsema son dos configuraciones separadas, dos presupuestos y dos permisos, así que un servicio puede tener permitido clasificar sin tener permitido generar.

## Por dónde empezar

Elegí la decisión de mayor volumen de tu producto — para casi todos los equipos es el enrutamiento de la bandeja o el etiquetado de primera línea. Preguntala como un bloque con opción de escape, registrá la respuesta al lado de lo que terminó haciendo la persona, y compará después de una semana. Vas a tener el umbral, y el argumento, en datos.

El lado operativo — claves, presupuestos, el preflight, qué pasa durante una caída — está en [Poner un modelo System One en producción](/es/blog/poner-un-modelo-system-one-en-produccion). El código está en [Cómo usar Jev desde Synsema](https://synsema.org/es/blog/how-to-use-jev-the-judge-block), y corre contra un proveedor mock determinista sin ninguna cuenta.