Entre la respuesta de un modelo y una acción en tus sistemas hay un paso. Zarel es un runtime de gobernanza para ese paso, una capa distinta de una barrera sobre el texto del modelo, de un framework de evaluación o de un router de modelos: la IA propone, un contrato declara qué se puede ejecutar y para quién, y el runtime lo hace cumplir.

Cuando decidir sale barato

El 15 de septiembre de 2026, TypeSafe AI abrió el acceso anticipado a Jev, con lista de espera, y lo presentó como su primer "System One model" (DataCamp). Jev recibe el estado de un programa y preguntas tipadas, y devuelve decisiones tipadas, sin generar texto: una opción de una lista (Choice), un puntaje sobre niveles ordenados (Score) o la probabilidad de que un enunciado sea cierto (Noul). Cada respuesta trae una probabilidad que TypeSafe describe como calibrada, y el modelo se entrena con un método que la empresa llama Reinforcement Learning for Calibrated Decisions (MarkTechPost). No se publicaron ni los pesos ni la arquitectura.

Las cifras de velocidad y de precio salen de benchmarks del propio TypeSafe. DataCamp aclara que todavía nadie las reprodujo de forma independiente, y que TypeSafe admite que no puede demostrar que el precio no esté subsidiado. Importa más la dirección que el multiplicador: una decisión que antes requería llamar a un modelo de frontera se abarata lo suficiente como para ponerla en cualquier rama de un programa. Flavio Copes describe a Jev como "un if inteligente" [1] y lo muestra decidiendo si a un email se le manda el tarifario o queda para que lo responda una persona.

Las decisiones baratas se automatizan en volumen. Y entonces la pregunta ya no es sólo si el modelo acierta, sino quién autorizó que cada decisión se ejecute, bajo qué política y cómo se demuestra después.

Qué garantiza una salida tipada

El resumen de DataCamp dice que Jev "no puede alucinar ni producir errores de tipo, porque las salidas válidas se definen de antemano en el esquema" [2]. Leída con cuidado, es una afirmación sobre la forma: cada respuesta es uno de los valores que declaraste. Copes cuenta la otra mitad: las respuestas pueden estar mal, Jev necesita preguntas literales y específicas, y cuando la pregunta da rodeos pierde precisión.

Una respuesta equivocada dentro del esquema sigue siendo un valor válido, y el código que decide según ella la ejecuta igual. El esquema sacó las opciones inválidas; cuál de las válidas vuelve sigue dependiendo del modelo. Tom's Hardware lo dice sin vueltas: Jev "todavía puede clasificar mal la información, caer ante ataques adversariales o responder a la literalidad de lo escrito en lugar de a su sentido" [3]. Acotar la salida no cambia quién escribió la entrada. Es la misma exposición que tiene cualquier clasificador, y por eso el veredicto de un clasificador sirve poco como barrera de seguridad (No se combate el probabilismo con probabilismo).

Calibrar y autorizar son preguntas distintas

Vanessa Barroeta, PMO Team Manager en Telefónica Tech, puso a prueba a Jev en vez de creerse los benchmarks. La herramienta que construyó para eso, judge-audit, no mide si un juez acierta: mide si su "estoy un 96 % seguro" es verdad, "porque en producción, equivocarse convencido es PEOR que equivocarse". La prueba abarca cuatro datasets, seis jueces y 3.800 decisiones, y parte de una pregunta que vale la pena conservar: "Y si tu agente delega decisiones en él… ¿quién vigila al que decide?"

El primer resultado, 200 de 200 en emails limpios, Barroeta lo deja de lado por demasiado perfecto: sale de un dataset fácil y sintético. Los que importan vienen después. Con 200 emails con trampas (inyección de prompt, homoglifos, ingeniería social, datos personales), Jev acertó el 95,5 %, y cuando una inyección lo engañaba, su confianza casi siempre caía con él, de 0,996 a 0,71. Claude Sonnet 4.5 acertó un poco más, el 96,5 %, y siguió seguro cuando se equivocaba. Barroeta convierte esa diferencia en un umbral: por debajo, la decisión pasa a una persona, y en esa prueba de 200 emails eso le permitió a Jev automatizar el 73 % de las decisiones sin un solo error observado, contra el 2 % de Claude. Usado como router, Jev mandó todas las tareas al modelo barato con un 96 % de confianza hasta que cada opción llevó una frase de descripción: "El fallo no era del modelo, era de cómo le preguntaba, y nada en el accuracy lo delata." Barroeta señala además que el campo de confianza que devuelve la API de Jev es una reescala de la probabilidad máxima y no una medida de incertidumbre, y por eso judge-audit contrasta la probabilidad con etiquetas humanas.

Esa es la forma correcta de usar la confianza de un modelo: medida contra tus propias decisiones, y usada para mandarle a una persona las dudosas.

El umbral decide, entonces, qué decisiones se saltean al revisor. No dice nada sobre si la acción que dispara una decisión se puede ejecutar, para este actor, sobre este registro, y un 0,9 bien calibrado sigue equivocándose más o menos una de cada diez veces. Qué acciones puede disparar una decisión, y dónde hace falta una persona diga lo que diga la confianza, es una cuestión de autoridad, y la resuelve una regla declarada antes de que el modelo respondiera. Un umbral puede sumar un revisor, y que no pueda sacar uno que esa regla exige es trabajo de la capa siguiente.

Dónde va la barrera

Un modelo como Jev es, en todo caso, un buen proponente. Su salida es acotada y tipada, así que entra al sistema como un dato fácil de chequear, y sigue siendo una entrada en la que no se puede confiar.

En Zarel, lo que se puede ejecutar está declarado en un contrato, y el runtime lo hace cumplir. El contrato enumera las acciones, los roles y qué puede hacer cada rol. Una escritura pasa por la barrera: el permiso, la fase del proceso y las precondiciones declaradas, y después los bindings de valores, que completan un campo con la identidad del actor o contrastan el valor propuesto con los registros guardados, en vez de creerle al modelo. Una acción que nunca se le otorgó al rol del actor se rechaza. Si una escritura tiene que esperar la confirmación de una persona, el contrato lo declara con effect: confirm sobre la escritura o sobre la transición de estado; la confirmación se le pide al usuario que actúa y, si la regla nombra roles, sólo cuando ese usuario tiene alguno. La confianza del modelo no interviene. Cada veredicto de la barrera queda registrado con la versión del contrato con la que se decidió, en una tabla que está fuera de la cadena de hash. La cadena cubre las transiciones de la máquina de estados y los eventos de los flows, con checkpoints firmados, así que cualquiera que tenga la clave publicada puede detectar si se editaron; verificarlo sin confiar en el operador requiere un deployment que opere el propio cliente, con claves en su poder.

La probabilidad de un modelo sí tiene un lugar en Zarel, donde sólo puede sumar cautela: un flow declarado no arranca si la confianza del modelo en la intención queda por debajo del piso que declara el contrato (o de un valor por defecto, si el contrato no declara ninguno), o si el modelo no informa ninguna. En sentido inverso no hay nada: una probabilidad alta no saltea un permiso, una precondición ni una confirmación requerida.

Hay un patrón que conectaría la capa de Barroeta con esta: registrar la probabilidad que informó el modelo junto al veredicto sobre la acción que propuso, para poder auditar después la calibración contra lo que efectivamente pasó. Zarel hoy no la registra.

Dos capas

Un sistema que automatiza decisiones baratas necesita las dos capas: una medición de si la confianza del modelo se sostiene con tus datos, y una regla declarada de qué se puede ejecutar, diga lo que diga esa confianza.

Este es el caso de las decisiones tipadas dentro de una línea más amplia: la comunicación y la propuesta pueden ser probabilísticas; la autoridad, la consecuencia y el compliance tienen que ser determinísticos y declarados. El argumento general está en No se combate el probabilismo con probabilismo.


Las citas están traducidas por el autor. Los originales, en inglés:

  1. Flavio Copes, A deep dive into Jev, TypeSafe's System One model: "a smart if statement".
  2. DataCamp, Jev: TypeSafe's System One Model That Never Hallucinates: "cannot hallucinate or produce type errors, because valid outputs are defined in the schema in advance".
  3. Tom's Hardware, Bruno Ferreira, 21-sep-2026: "Jev can still misclassify information, fall victim to adversarial attacks, or answer literal wording rather than meaning."

Nicolás Moreno construye Zarel: operaciones de IA gobernadas, donde la IA propone y el contrato dispone.