Jev: el modelo que decide en vez de escribir. Análisis a fondo y diez casos de uso

El 15 de septiembre, TypeSafe AI publicó Jev. En tres días, la demanda había tumbado su API durante un rato, LangChain había sacado una integración y TechCrunch titulaba que un nuevo tipo de modelo estaba entusiasmando a los desarrolladores. Detrás está Diogo Almeida, que viene de OpenAI y figura —según la propia TypeSafe— entre los coinventores del RLHF, la técnica que convirtió los modelos de lenguaje en ChatGPT.

Jev no es un modelo de lenguaje al uso: no escribe ni una palabra. Recibe un estado —un ticket, un expediente, la traza de un agente— y una batería de preguntas cerradas, y devuelve decisiones tipadas con una probabilidad para cada opción. Según TypeSafe, en 70-500 milisegundos y cobrando sólo la entrada.

Antes de seguir, lo que preguntaría cualquier CTO: Jev salió hace cuatro días y nosotros todavía no lo tenemos en producción. Esta pieza sale de leer entera su documentación técnica, sus cookbooks, lo que han contado los primeros que lo han probado y, sobre todo, la página en la que TypeSafe enumera los fallos conocidos de su versión 1.13. Es la página más útil del lanzamiento y la que menos se está citando.

Nuestra lectura cabe en una frase: la mayor parte de lo que las empresas le piden hoy a un LLM dentro de una automatización no es escribir, es decidir, y para esa parte Jev cambia las cuentas. Pero lo que cambia de verdad no es lo que dicen los titulares —la velocidad y el precio—, sino que cada respuesta llega con una probabilidad calibrada sobre la que se puede apoyar un umbral. Eso es lo que convierte una clasificación en una decisión que se puede automatizar.

Qué es exactamente Jev, y qué no es

La interfaz es la idea entera. En vez de un prompt y un texto de vuelta, se envía un estado —texto, un objeto JSON o una lista— y unas preguntas de tres tipos, que TypeSafe llama primitivas:

Todas las preguntas de una llamada ven el mismo estado y se evalúan en paralelo y por separado: la respuesta de una no contamina a la otra. Añadir preguntas apenas cambia el tiempo de respuesta, y agruparlas sale mucho más barato que hacerlas de una en una. En uno de sus cookbooks, trece preguntas en una sola llamada fueron en torno a diez veces más rápidas y más de once veces más baratas que trece llamadas sueltas, con las mismas respuestas. De ahí sale el patrón que más repite su documentación: preguntad todo lo que el código pueda necesitar, aunque sólo sirva para algunos casos, y que el código decida qué respuestas usa.

El entrenamiento es la otra mitad. Los LLM de chat se afinan para producir el texto que prefiere un evaluador humano (RLHF) o para acertar en problemas que se pueden verificar de forma automática (RLVR). TypeSafe entrena Jev con lo que llama Reinforcement Learning for Calibrated Decisions (RLCD), cuyo objetivo es que las probabilidades sean honestas: si el modelo dice 0,8 sobre un conjunto de casos, alrededor del 80% deberían ser correctos. La propia documentación añade el matiz importante: la calibración se mide sobre grupos de predicciones y no garantiza que una respuesta concreta sea correcta.

Y lo que no es. No escribe respuestas, no genera código, no explica su razonamiento y no es un agente: no decide el siguiente paso de nada, contesta preguntas cerradas que le hace el código. El nombre de la categoría, System One, viene del sistema 1 de Kahneman: juicios rápidos e intuitivos, de los que una persona experta hace en un segundo si tiene delante el contexto adecuado. Todo lo que requiera razonar en varios pasos sigue siendo terreno de un LLM.

Lo que cambia de verdad es la probabilidad, no la velocidad

Los titulares se quedaron con las cifras de 40 a 200 veces más rápido y cientos de veces más barato. Importan, pero no son lo más importante.

En la pieza sobre la ruta de excepción explicábamos por qué la confianza que declara un LLM es un mal disparador para decidir qué casos van a una persona: el informe técnico de GPT-4 mostró que el post-entrenamiento empeoraba la calibración del modelo. RLCD apunta exactamente a ese problema. La tabla comparativa del anuncio de TypeSafe lo resume mejor que nosotros: si un modelo puede hacer una tarea el 95% de las veces pero no dice cuándo está en el 5%, no puede automatizarla.

Los primeros testimonios van en la misma dirección. Nikhil Mudholkar, CTO de Bryo AI, comparó Jev con Gemini clasificando correos de negocio: Gemini acertó algo más, pero costaba entre diez y veinte veces más. Lo que le interesó, según contó a TechCrunch, fue la confianza: es el único que devuelve una probabilidad real. Armin Ronacher, CTO de Earendil, lo formuló al revés: Jev «delega un poco el problema de la alucinación en el usuario». Si la respuesta llega con un 50%, es una moneda al aire y la descartas; si llega con un 95%, puedes actuar.

Esa frase es la clave práctica: el umbral pasa a ser una decisión vuestra, explícita, que se puede medir y ajustar. Y la otra mitad del argumento de la ruta de excepción sigue en pie, porque ningún modelo la resuelve: la probabilidad mide la duda del modelo, no lo que os jugáis en el caso. La documentación de TypeSafe lo aplica en sus propios ejemplos, con umbrales distintos para consultar un saldo y para aprobar una transferencia. Quien decide cuánta seguridad exige cada acción es el código.

Así se ve un triage con enrutado por confianza en el SDK de Python. Las instrucciones van en castellano a propósito, porque es lo primero que hay que medir:

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient(model="jev-1.13.0")  # versión fijada: los umbrales se calibran contra ella

r = client.system_one(
    state={"ticket": ticket, "cliente": {"plan": plan, "antiguedad": antiguedad}},
    questions={
        "area": Choice(
            instructions="¿Qué equipo debe resolver `ticket`?",
            criteria={
                "facturacion": "Cobros, facturas y devoluciones",
                "tecnico": "Errores, integraciones y caídas",
                "cuenta": "Accesos, usuarios y permisos",
                "otro": "Nada de lo anterior",
            },
        ),
        "pide_reembolso": Noul(
            instructions="¿El cliente pide que se le devuelva dinero?",
        ),
        "riesgo_baja": Score(
            instructions="¿Qué riesgo de baja expresa `ticket`?",
            criteria=[
                "Ninguno",
                "Queja puntual",
                "Menciona irse o compara con otro proveedor",
            ],
        ),
    },
)

area = r.answers["area"]
if area.confidence < 0.6:
    a_bandeja_humana(ticket)           # la ruta de excepción, no un error
elif r.answers["pide_reembolso"].noul > 0.9:
    abrir_flujo_reembolso(ticket)      # importe y política se comprueban en código
else:
    enrutar(area.choice, prioridad=r.answers["riesgo_baja"].score)

Tres detalles del ejemplo son decisiones de diseño, no de estilo. La opción otro, para que el modelo no tenga que forzar una respuesta. La versión fijada, porque el alias jev-latest se mueve cuando TypeSafe publica una versión nueva y los umbrales se calibran contra un modelo concreto. Y el umbral de 0,6, que es un punto de partida y no una recomendación: el vuestro sale de medir.

La letra pequeña, leída entera

TypeSafe merece un reconocimiento poco habitual: su anuncio incluye un apartado de matices detrás de cada cifra, y la documentación tiene una página de fallos conocidos. Leídos enteros, dejan un mapa bastante claro de dónde no conviene usarlo, o no sin precauciones.

Dos cosas más que conviene saber, aunque no cambien el diseño. TypeSafe no explica su arquitectura, y observadores externos citados por TechCrunch sospechan que está construido sobre un LLM de pesos abiertos. Y dice entrenar exclusivamente con datos sintéticos que produce su propio equipo.

Nada de lo anterior es un reproche. Que un laboratorio publique el día del lanzamiento la lista de sus propios fallos es más honesto que casi todo lo que se ve en este mercado. Pero hay que leerla antes de diseñar, no después del primer incidente.

Diez casos de uso donde aporta muchísimo valor

No hemos elegido los casos por lo vistosos, sino por cuatro criterios: que la tarea sea decidir y no escribir; que haya volumen o prisa, que es donde el coste y la latencia de un LLM duelen; que la probabilidad sirva para algo concreto; y que exista, o se pueda diseñar, una ruta para los casos dudosos. Van ordenados de más inmediato a más ambicioso.

1 · Triage de soporte y de bandejas de entrada

El problema. Cada correo o ticket pasa hoy por un LLM que devuelve un JSON con el área, la urgencia y el tono, o por una persona que lo lee y lo reenvía. Lo primero es caro y lento a escala; lo segundo, más.

Cómo se monta. Un Choice para el área, con una opción «otro»; unas Nouls para reembolso, urgencia o petición de hablar con una persona; un Score para frustración o riesgo de baja. Todo en una llamada, y el código enruta. Es el ejemplo de arriba.

Por qué aquí. Es la tarea que más se parece a lo que Jev hace mejor, y el volumen convierte la diferencia de coste y latencia en dinero. El caso de Bryo AI es exactamente éste.

La trampa. La lectura literal. «Pide un reembolso» no es lo mismo que «está descontento y pregunta qué opciones tiene», y Jev contesta a lo que está escrito. Los casos frontera van en los criterios, con ejemplos de lo que entra y lo que no.

2 · Rutas de excepción con umbral: siniestros, facturas, reclamaciones

El problema. El proceso automatizado resuelve la mayoría de los casos y tiene que decidir cuáles van a una persona. Con un LLM, esa decisión se apoya en una confianza que no está calibrada.

Cómo se monta. Preguntas atómicas sobre el expediente —¿aplica la cobertura?, ¿falta documentación?, ¿hay algo que merezca revisión?—, combinadas en código en tres salidas: pagar, denegar o persona. Uno de los cookbooks de TypeSafe construye precisamente un triage de reclamaciones con esas tres salidas.

Por qué aquí. Es el caso en que la probabilidad calibrada vale más que la velocidad. Otro cookbook, de moderación, lo cuantifica: exigiendo al menos 0,6 a la opción más probable, lo que no llega pasa a revisión humana, y la coincidencia entre ejecuciones repetidas sube del 90,8% al 99,2% con el 74,2% de las respuestas automatizadas. Es la curva de cobertura frente a error de la ruta de excepción, con los números a la vista. Con una salvedad: el experimento repite quince veces un único mensaje dudoso, así que enseña el mecanismo, no el rendimiento que tendréis.

La trampa. Los importes, las franquicias y los plazos. Jev no compara cantidades ni fechas de forma fiable: la cobertura la juzga Jev y la aritmética se hace en código. Y el umbral se decide por consecuencia, no por comodidad.

3 · Guardrails antes de que el agente actúe

El problema. Un agente con herramientas puede recibir malas instrucciones, por error o porque alguien se las ha colado. Revisar cada llamada con otro LLM es caro y lento, y casi nadie lo hace.

Cómo se monta. Antes de ejecutar una llamada a herramienta, un puñado de Nouls: ¿es destructiva?, ¿hace algo que el usuario no ha pedido?, ¿envía datos fuera? LangChain ya lo empaqueta como middleware experimental que bloquea la llamada antes de que se ejecute.

r = client.system_one(
    state={"peticion": peticion_usuario, "llamada": {"herramienta": "bash", "comando": comando}},
    questions={
        "destructivo": Noul(instructions="¿`llamada.comando` borra o sobrescribe datos de forma irreversible?"),
        "fuera_de_encargo": Noul(instructions="¿`llamada.comando` hace algo que `peticion` no ha pedido?"),
        "saca_datos": Noul(instructions="¿`llamada.comando` envía datos o credenciales a un destino externo?"),
    },
)

riesgo = max(r.answers[k].noul for k in ("destructivo", "fuera_de_encargo", "saca_datos"))
if riesgo > 0.3:
    pedir_confirmacion(comando)   # y la lista de permisos sigue mandando sobre lo que se ejecuta

Por qué aquí. Porque el coste y la latencia permiten revisar todas las llamadas, no una muestra. Pranit Sharma, ingeniero de Vercel, contó a TechCrunch que sustituyeron por Jev el LLM que revisaba la seguridad de los comandos y obtuvieron resultados entre cinco y dieciocho veces más rápidos, y con más acierto.

La trampa. La más seria de la lista: la propia documentación de Jev advierte que un texto escrito para manipularlo puede mover su respuesta. Un guardrail probabilístico sube el coste del ataque, pero no autoriza nada. Lo que el agente puede ejecutar lo sigue decidiendo una lista de permisos determinista, como defendíamos en la pieza sobre inyección de prompts. Por eso el umbral del ejemplo es bajo: aquí sale más barato pedir una confirmación de más que ejecutar una de menos.

4 · Enrutado de modelos

El problema. Mandar todas las peticiones al modelo más potente es caro; mandarlas todas al barato empeora las difíciles. Y un router hecho con un LLM añade la latencia y el coste que se quería ahorrar.

Cómo se monta. Un Choice sobre la petición —modelo rápido o potente, con criterios de qué va a cada uno— y un Score de dificultad o de riesgo; el código elige el modelo. LangChain ofrece también un middleware experimental de enrutado sobre Jev, y Ronacher lo señalaba como uno de los usos más útiles.

Por qué aquí. Es la palanca de coste más directa en cualquier sistema con volumen, y ataca de frente lo que contábamos sobre por qué la factura crece entre el piloto y la escala.

La trampa. El error del router es silencioso: una tarea difícil enviada al modelo barato no da error, da una respuesta peor. Hay que muestrear lo que el router mandó al modelo barato y revisarlo, como cualquier otra ruta automática.

5 · Qué contexto y qué skill carga el agente

El problema. Los agentes cargan demasiado: todas las skills del catálogo, todos los fragmentos que devolvió la búsqueda. Más contexto no es más inteligencia; es más coste y más distracción.

Cómo se monta. Una llamada que puntúa cada skill o cada fragmento frente a la petición, y una Noul que pregunta si hace falta alguno. En uno de los cookbooks, con un catálogo de 182 skills y 488 peticiones a Claude Haiku 4.5, sugerir como mucho una skill con Jev bajó las cargas equivocadas del 16,8% al 7,3% y las innecesarias del 9,8% al 4,0%. Otro filtra los fragmentos recuperados antes de que lleguen al modelo que responde, y descarta los que esconden instrucciones.

Por qué aquí. Porque es ingeniería de contexto automatizada: decidir qué entra en la ventana es una decisión, y ahora es barata.

La trampa. Descartar el fragmento que contenía la respuesta no genera ningún aviso. El filtro necesita su propio conjunto de evaluación.

6 · Reordenar los resultados de un RAG

El problema. La búsqueda por embeddings o por palabras clave encuentra el documento correcto, pero rara vez lo pone el primero.

Cómo se monta. Una pregunta por cada par consulta-candidato sobre una lista corta, y se reordena por la puntuación.

Por qué aquí. Mejora lo que ve el modelo que responde sin tocarlo. En el cookbook de TypeSafe sobre consultas jurídicas, con listas cortas de treinta pasajes en las que el correcto siempre estaba, el pasaje correcto quedó primero en el 18% de las consultas frente al 5% de la búsqueda sola, y entre los diez primeros en el 62% frente al 38%.

La trampa. Son cuarenta consultas: sirven para ver el orden de magnitud, no para prometer ese resultado. Y el coste crece con el tamaño de la lista: aquellas cuarenta consultas fueron 1.200 llamadas.

7 · Verificar lo que escribe otro LLM

El problema. Los LLM fallan de formas conocidas: citan mal, inventan referencias, llaman a una herramienta con el argumento equivocado. Revisar cada salida con otro LLM duplica el coste; revisarla con personas no escala.

Cómo se monta. Preguntas atómicas sobre la salida y su fuente: ¿el pasaje citado respalda la afirmación?, ¿la cita existe en el documento?, ¿el argumento de la llamada coincide con lo que pidió el usuario? La documentación descompone la verificación de una traza de herramientas en nueve preguntas de sí o no, una por cada cosa que puede fallar.

Por qué aquí. Porque convierte la verificación en algo que se hace sobre el cien por cien de las salidas, y las respuestas quedan registradas como datos: justo lo que necesita el muestreo del error silencioso que describíamos en la ruta de excepción.

La trampa. Comprobar que una cita está en el documento es un juicio; comprobar que un número cuadra es aritmética. Lo segundo, otra vez, en código.

8 · Extracción: el LLM propone, Jev elige, el código calcula

El problema. Extraer campos de facturas, contratos o formularios con un LLM funciona hasta que inventa un valor que no estaba en el documento.

Cómo se monta. Jev no extrae escribiendo, porque no escribe: elige. Una expresión regular o un LLM proponen los candidatos —importes, fechas, NIF, correos— y Jev elige cuál corresponde al campo pedido, con una opción «no consta». Las fechas se piden por partes, como opciones cerradas, y el código las ensambla. Uno de los cookbooks trae un detalle muy nuestro: preguntar con una Noul si el documento escribe «1.315,50 €» o «1,315.50», porque el código que normaliza el importe necesita saberlo.

Por qué aquí. Porque el valor extraído es literal: existe en el documento. En cuentas por pagar, ésa es la diferencia entre un apunte erróneo y una excepción visible. TypeSafe publica además una cascada en la que un modelo pequeño extrae, Jev verifica campo a campo y sólo se paga el modelo grande cuando la verificación duda.

La trampa. Creer que la parte difícil la hace Jev. La hace el diseño: qué candidatos se proponen y qué hace el código con cada respuesta.

9 · Conciliar entidades en el CRM y el ERP

El problema. El mismo cliente aparece tres veces con nombres distintos; el mismo proveedor, con dos direcciones. Cualquier agente que lea esos sistemas hereda el desorden.

Cómo se monta. Para cada par candidato, un Score con tres niveles que son las tres cosas que se pueden hacer —fusionar, dejar separados o pasar a una persona— y unas Nouls que le dicen a esa persona en qué campo discrepan. Es el diseño del cookbook de TypeSafe sobre catálogos, con 450 pares candidatos.

Por qué aquí. Porque es la cuarta pregunta de la frontera del ERP —¿y si el dato del sistema está mal?— resuelta antes de conectar el agente. Limpiar el maestro es la preparación de datos más rentable que hay.

La trampa. Los identificadores —CIF, IBAN, códigos internos— se comparan en código, nunca con el modelo. Jev juzga si «Distribuciones Pérez» y «Dist. Pérez e Hijos, SL» son la misma empresa, no si dos números coinciden.

10 · Revisión semántica en CI y triage de pull requests

El problema. Las convenciones de un equipo —cómo se nombran las cosas, qué no se hace en según qué capa, qué exige un cambio en una API pública— no caben en un linter clásico, y revisarlas a mano es lo primero que se salta cuando crece el volumen de código generado.

Cómo se monta. Una Noul por regla sobre cada fragmento del diff, dentro del pipeline de CI; lo que supera el umbral se marca para revisión. TypeSafe lo incluye entre sus casos de uso como linting semántico.

Por qué aquí. Porque en los equipos que desarrollan con IA el cuello de botella ya no es escribir código, sino revisarlo, como contábamos en la pieza sobre el review de código generado. Un filtro barato que dirige la atención humana a lo que importa vale más que otro asistente que escriba.

La trampa. El código de bajo nivel y las representaciones numéricas están entre lo que peor lleva Jev, según su propia documentación. Para reglas sobre intención y estructura, bien; para encontrar un fallo de lógica, no.

Tres usos prometedores que dejamos fuera de la lista, por ahora

Decisiones en tiempo real dentro de una interfaz. Es la demostración más vistosa del lanzamiento —Jev jugando a Doom con diez consultas por segundo, por unos siete dólares la hora— y el ejemplo de la banca por voz de su documentación. Pocos procesos de una empresa mediana necesitan decidir en 100 milisegundos en vez de en tres segundos; los que sí, como el fraude en el momento del pago, merecen un análisis propio.

Convertir históricos en variables para modelos clásicos. Pasar años de tickets, notas comerciales o reseñas por cientos de preguntas y usar las probabilidades como variables de un modelo de predicción es de los usos con más recorrido, y TypeSafe publica un bucle completo para hacerlo. Pero exige una verdad de referencia contra la que medir y un equipo de datos que lo mantenga: no es por donde se empieza.

Agentes que manejan el navegador o el ordenador. Hay quien ya lo está usando para decidir cada clic por fracciones de céntimo. Es demasiado pronto para recomendarlo en un proceso de negocio.

Cómo saber si sirve para vuestro caso antes de comprometer nada

TypeSafe pide que cada cliente se construya sus evaluaciones, y tiene razón. Esta es la prueba que haríamos nosotros antes de meter Jev en un proceso:

1. Elegid una decisión, no un proceso. Una sola llamada a un LLM de las del segundo montón: la que más se repite o la que más cuesta.
2. Reunid entre 200 y 300 casos reales con la respuesta correcta, en vuestro idioma y con vuestra suciedad. Es el golden set de siempre, y probablemente ya tenéis la mitad en el histórico.
3. Descomponed la pregunta en preguntas atómicas, con criterios que digan qué entra y qué no en cada opción. Probad las instrucciones en castellano y en inglés.
4. Corred Jev y vuestro LLM actual sobre el mismo conjunto, y medid acierto, latencia y coste por decisión.
5. Mirad la calibración, no sólo el acierto. Agrupad las respuestas por tramos de confianza y comprobad qué porcentaje acierta en cada tramo. Si en el tramo de 0,9 aciertan nueve de cada diez, podéis construir un umbral encima; si no, la confianza no vale como disparador y Jev pierde su principal ventaja.
6. Probad lo que sabéis que le cuesta: mensajes escritos para engañarlo, casos con importes y fechas, estados con mucho ruido.
7. Decidid antes de desplegar la versión fijada, el umbral por tipo de acción y qué hace el sistema cuando Jev no responde. Y pasad el acuerdo de tratamiento de datos a quien lleve protección de datos.

El criterio de decisión es sencillo de enunciar: Jev compensa si, al umbral que vuestro proceso necesita, resuelve más casos que el sistema actual con el mismo error silencioso, o los mismos casos con menos coste y latencia. Si la calibración no aguanta en vuestros datos, la velocidad y el precio no lo compensan: habréis cambiado un clasificador caro por uno barato que no sabe cuándo duda.

El producto puede cambiar; el patrón se queda

Puede que dentro de un año Jev tenga competidores —Ronacher lo daba por hecho— o que TypeSafe no cumpla lo que promete. Lo que no va a desaparecer es el patrón que pone sobre la mesa, y conviene adoptarlo con independencia del proveedor.

El patrón es este. El código es el dueño del flujo. Los LLM se quedan con lo que sólo ellos hacen bien: redactar, razonar en varios pasos, resolver lo abierto. Y los cientos de decisiones pequeñas que hay entre medias —a quién va esto, es esto seguro, cuál de estos es el bueno, falta algo— se convierten en preguntas cerradas que devuelven una probabilidad, se combinan en código y se enrutan con umbrales que alguien ha decidido y medido. Es arquitectura de sistema 1 y sistema 2, y es lo que separa a un agente que es software de un agente que es una demo.

Por eso la documentación de TypeSafe insiste en que Jev sirve para construir software con IA, no agentes: cada vuelta del bucle de un agente es una oportunidad más de salirse del camino, y cada decisión que se saca del bucle y se convierte en una pregunta tipada es una oportunidad menos.

La pregunta útil, entonces, no es si Jev es mejor que GPT o que Claude. Es cuántas de vuestras llamadas a un LLM eran, en realidad, una decisión con forma de texto.

Preguntas frecuentes

¿Qué es Jev de TypeSafe?

Es el primer modelo de lo que TypeSafe AI llama System One: un modelo que no genera texto, sino que responde preguntas cerradas sobre un estado —un ticket, un expediente, la traza de un agente— y devuelve decisiones tipadas con una probabilidad para cada opción. Hay tres tipos de pregunta: Choice para elegir entre opciones, Score para situar algo en una escala y Noul para preguntas de sí o no. Se lanzó el 15 de septiembre de 2026 en acceso anticipado y está pensado para que lo consuma el código, no una persona.

¿En qué se diferencia de pedirle a un LLM una respuesta en JSON?

En tres cosas. La salida está restringida por construcción a las opciones que definís, así que no hay que validar ni parsear nada. Todas las preguntas se evalúan en paralelo en una sola llamada, en torno a 100 milisegundos, en vez de generar texto token a token. Y cada respuesta trae una probabilidad entrenada para estar calibrada, que es lo que permite construir umbrales. Un LLM con salida estructurada puede devolver el mismo formato, pero su confianza declarada no suele estar calibrada.

¿Es verdad que Jev no alucina?

Es verdad en un sentido estrecho: no puede devolver un valor que no esté entre las opciones que le habéis dado. No lo es en el sentido que importa: puede elegir la opción equivocada, y con una probabilidad alta. La propia documentación recuerda que la calibración se mide sobre grupos de predicciones y no garantiza que una respuesta concreta sea correcta. Hay que medir acierto y calibración con casos reales, como con cualquier modelo.

¿Funciona en español y en catalán?

Acepta cualquier idioma, pero TypeSafe indica que el inglés es su idioma principal de entrenamiento y que los demás funcionan con menos precisión. Para una empresa española eso significa medir antes de fiarse: montar un conjunto de casos reales en castellano o catalán, comparar su acierto y su calibración y probar las instrucciones escritas en castellano y en inglés. Y vigilar especialmente la confianza al enrutar.

¿Se puede usar con datos personales de clientes europeos?

Se puede, con trabajo previo. El servicio está hoy en Estados Unidos y las transferencias desde la UE se amparan en las cláusulas contractuales tipo de su acuerdo de tratamiento de datos. TypeSafe dice no entrenar con datos de clientes, pero la retención cero sólo se ofrece en el plan enterprise. Antes de enviar datos personales conviene una evaluación de impacto y de la transferencia, y minimizar lo que va en el estado: muchas decisiones no necesitan nombres ni identificadores.

¿Sustituye a GPT o a Claude en nuestros flujos?

No, los complementa. Jev no redacta, no razona en varios pasos y no genera código. Lo que sí puede sustituir son las llamadas a un LLM que en realidad son decisiones: clasificar, enrutar, puntuar, verificar o elegir entre candidatos. El patrón que proponemos es que el código gobierne el flujo, que los LLM se queden con lo que requiere escribir o razonar y que las decisiones pequeñas se hagan con preguntas cerradas y umbrales medidos.