Jev: qué cambia cuando la IA deja de escribir y empieza a decidir

Varias preguntas pueden evaluarse sobre el mismo contexto en una sola llamada. Eso permite dividir una decisión compleja en evaluaciones pequeñas, en lugar de entregar al modelo un único prompt con todos los criterios mezclados.

Documentación de TypeSafe sobre Jev.

El problema no es que un LLM no pueda hacerlo

Un LLM clasifica sin dificultad una incidencia como crítica, detecta si un correo es una reclamación o decide a qué departamento corresponde una solicitud. Pero la cuestión real es si hace falta toda la capacidad de un gran modelo generativo para ese trabajo.

Muchas automatizaciones actuales tienen una arquitectura parecida a esta:

Información
↓
Prompt
↓
LLM
↓
Texto / JSON
↓
Validación
↓
IF / Switch
↓
Acción

El modelo genera una respuesta, comprobamos el formato, extraemos el valor que nos interesa y con ese valor decidimos qué hace la aplicación.

Sin embargo, en muchos casos, lo único que necesitábamos desde el principio era esto:

Información
↓
Decisión
↓
Acción

Jev está diseñado alrededor de ese segundo esquema.

TypeSafe publica mejoras de hasta 193.6 veces en velocidad y 444.6 veces en coste frente a determinados modelos generalistas en algunos de sus flujos de evaluación. Son cifras del propio proveedor, obtenidas en tareas especialmente adecuadas para este tipo de modelo, y la compañía explica que representan algunos de sus mejores resultados.

Al escribir este artículo, el precio publicado era de 0.042 dólares por millón de tokens de entrada, sin coste por los de salida (página de modelos de TypeSafe).

No obstante, conviene poner ese ahorro en su sitio ya que, a los volúmenes habituales de una pyme, clasificar con un LLM pequeño suele tener ya un coste marginal. Ahí el ahorro no es el argumento, sino la latencia, tener menos piezas que mantener y disponer de una probabilidad asociada a cada decisión.

La conclusión correcta no es que Jev sea cientos de veces mejor que un LLM, porque sencillamente no hacen lo mismo, sino que estamos utilizando modelos mucho más complejos de lo necesario para determinadas tareas.

Presentación técnica de Jev publicada por TypeSafe.

Código, modelo de decisión o LLM: no sirven para lo mismo

Esta es la distinción que importa al diseñar una automatización o una aplicación con Inteligencia Artificial.

Una condición como esta:

importe > 10.000 €

no necesita Inteligencia Artificial. Necesita código. Un nodo IF en n8n o una condición en PHP, Python o JavaScript la resuelve de forma determinista, rápida y prácticamente gratuita.

Otra condición:

¿El contenido de esta incidencia indica que necesita intervención urgente?

Aquí no hay regla exacta que escribir. Hay que interpretar lenguaje, contexto y significado, y la respuesta sigue siendo cerrada. Es el espacio de un modelo de decisión como Jev.

Y una tercera petición:

Explica por qué esta incidencia debería escalarse, identifica los principales riesgos y redacta una respuesta para el cliente.

Esto exige análisis y generación de lenguaje. Es trabajo para un LLM.

La segunda fila no es una categoría nueva. Los clasificadores entrenados a medida llevan años haciendo ese trabajo. Lo que cambia es que ya no hay que entrenar uno para cada pregunta; hay que definir la pregunta, sus opciones y sus criterios, y probarlo con datos propios.

Jev tampoco debe llevarnos a sustituir los nodos IF por Inteligencia Artificial. Sería el mismo error que usar un LLM para todo.

Jev llega a n8n: un IF capaz de interpretar contexto

n8n anunció el 30 de septiembre de 2026 la disponibilidad de Jev mediante el nodo de TypeSafe AI. Su publicación lo presentaba como un nodo IF o Switch para las situaciones en las que una regla tradicional resulta demasiado rígida.

Podemos preguntar si una operación necesita revisión ejecutiva y obtener la probabilidad de que la respuesta sea sí. O clasificar una incidencia como Crítica, Alta, Media o Baja y hacer que cada categoría continúe por una salida distinta del flujo.

Eso introduce una decisión semántica en mitad de una automatización sin convertirla en una conversación completa con un LLM.

En instalaciones autoalojadas o Community Edition, que es como trabajo yo, se utiliza el nodo de TypeSafe con una clave propia del proveedor.

Ahora bien, conviene aclarar algo: instalar el nodo de TypeSafe en un n8n autoalojado no significa instalar Jev en nuestro servidor. La integración se ejecuta desde nuestra instancia, pero el modelo se procesa en la infraestructura de TypeSafe.

Nota a 2 de octubre de 2026: Jev puede probarse en determinados planes de n8n Cloud mediante Gateway Credits sin consumirlos hasta el 10 de octubre de 2026 a las 23:59 UTC.

Anuncio oficial de Jev en la comunidad de n8n.

Si quieres ver cómo funciona Jev dentro de n8n, en este vídeo se muestran varios ejemplos prácticos de uso:
Ver demostración de Jev en n8n en YouTube (vídeo en inglés).

Que no invente categorías no significa que acierte

Uno de los mensajes más repetidos sobre Jev es que no alucina. Ciertamente, tiene base técnica, pero dice menos de lo que parece.

En Jev las respuestas posibles están definidas de antemano. Si las opciones son Crítica, Alta, Media y Baja, el modelo no puede devolver una quinta.

Esa ventaja no es exclusiva de Jev. Un LLM utilizado mediante una API que imponga salidas estructuradas con un esquema estricto también queda limitado a los valores permitidos. La diferencia es que Jev está diseñado para este tipo de decisiones y devuelve de forma nativa una distribución de probabilidad sobre las opciones.

Y ninguna de las dos garantías elimina el error, porque Jev puede elegir una de las categorías permitidas y elegir la equivocada. La propia publicación de n8n lo advierte.

La formulación exacta es esta: Jev evita la respuesta fuera del esquema, pero no el error de decisión.

TypeSafe publica las limitaciones conocidas de la versión actual. Y tres son las que importan especialmente en un proceso de empresa:

• Lectura literal. El modelo responde a la pregunta escrita, no a la que queríamos hacer. Negaciones, matices y condiciones implícitas se interpretan al pie de la letra.
• Contenido adversario. Un texto redactado para influir en su propia clasificación puede mover la respuesta.
• Exceso de contexto. La precisión cae cuando el contexto incluye información irrelevante. TypeSafe recomienda filtrar antes y enviar solo lo que la pregunta necesita.

Limitaciones conocidas de Jev 1.13, en la documentación de TypeSafe.

La diferencia entre formato válido y decisión correcta pesa más cuando dejamos de usar la IA para redactar y empezamos a usarla para determinar qué ocurre después en un proceso.

Probabilidad y confianza no son el mismo número

Las respuestas Choice y Score traen dos datos distintos: la probabilidad de cada opción y una métrica llamada confidence.

La confianza no es la probabilidad de acertar ni tampoco es la probabilidad de la opción elegida. TypeSafe la calcula a partir de cómo se reparte la probabilidad entre las opciones: vale 1 cuando toda cae en una y 0 cuando se reparte por igual.

Para una pregunta Choice con n opciones, la fórmula es esta:

confianza = (probabilidad más alta − 1/n) / (1 − 1/n)

Con las cuatro prioridades del ejemplo, si Jev asigna a Crítica una probabilidad de 0,70, la confianza que devuelve es 0.60.

Por eso un valor como:

confidence = 0.95

no significa que exista un 95% de probabilidad de que la decisión sea correcta.

Las preguntas Noul funcionan de otra manera. Devuelven sólo la probabilidad de que la respuesta sea sí, sin confianza aparte. Un valor cercano a 0.5 es el modelo diciendo que no lo sabe.

TypeSafe afirma que entrena Jev para que sus probabilidades estén calibradas. Es una afirmación del proveedor y una calibración que se cumple con sus datos de evaluación no tiene por qué cumplirse con los nuestros.

El uso práctico es separar las decisiones en tres caminos:

La documentación añade cuatro reglas para fijar los umbrales:

1. Se ajustan con datos reales del caso de uso, empezando por valores conservadores.
2. No hay un umbral único. Asignar un departamento admite más margen de error que rechazar una reclamación.
3. Un umbral ajustado para una pregunta Noul no sirve para una Choice, aunque pregunten lo mismo.
4. El alias jev-latest cambia de modelo cuando sale una versión nueva. Si los umbrales están ajustados, hay que fijar la versión concreta.

Documentación de TypeSafe sobre la métrica de confianza.

Jev en español: probar antes de confiar

Todo lo comentado hasta ahora sale de la documentación del proveedor. Y la propia documentación deja una advertencia que afecta de lleno a cualquier empresa española: el inglés es el idioma principal de entrenamiento de Jev y donde su precisión es mayor. Otros idiomas se procesan, pero no igual de bien, y TypeSafe recomienda probar con contenido propio antes de confiarle una carga de trabajo que no sea en inglés (página de modelos).

Antes de llevarlo a producción con textos en español, esa prueba es obligatoria.

La siguiente pregunta: qué información le damos para decidir

Que Jev sea rápido, barato y sencillo de integrar no resuelve la cuestión esencial de cualquier proyecto serio de Inteligencia Artificial: qué información necesita recibir el modelo para hacer su trabajo.

TypeSafe declara que no entrena Jev con las peticiones ni con las respuestas de sus clientes, y publica un acuerdo de tratamiento de datos. También contempla las Cláusulas Contractuales Tipo de la Unión Europea para transferencias internacionales. La retención cero de datos aparece en su documentación asociada a clientes corporativos, no como condición general.

Pero nada de eso cambia el hecho central: usar Jev es enviar la información a la infraestructura de TypeSafe. Tener n8n en nuestro servidor no convierte ese procesamiento en local. Y si el acceso pasa por una pasarela, como los créditos de n8n Cloud, hay un intermediario más en la cadena.

Para el RGPD, que un sistema lea un dato ya es tratarlo. Por tanto, pedirle al modelo que ignore un campo no sirve: el dato tiene que filtrarse antes de llegar a él. ALgo que es irrelevante al clasificar información pública o sin datos personales, pero cambia por completo con información confidencial, clientes, empleados o procesos de Recursos Humanos.

Un caso real muestra cómo debe integrarse un modelo de este tipo.

Cómo lo aplicaría en una aplicación real de Recursos Humanos

Hace un tiempo desarrollé, dentro de una consultoría de Inteligencia Artificial, una aplicación para el departamento de Recursos Humanos de una empresa. Y uno de sus principales objetivos era facilitar la gestión y el análisis de candidaturas con IA como apoyo al proceso.

Antes de elegir el modelo había que decidir algo más importante: cómo debía circular la información dentro de la aplicación.

Lo más sencillo habría sido enviar cada currículum completo a un modelo y pedirle el análisis. Pero un currículum contiene mucha información que el modelo no necesita ni debe conocer para evaluar aspectos profesionales: nombre, correo electrónico, teléfono y fotografía pueden hacer falta para que Recursos Humanos gestione la candidatura, pero no para analizar si existe determinada experiencia o si una trayectoria reúne determinadas competencias.

Por qué la aplicación utiliza dos bases de datos

La primera base de datos contiene la información completa necesaria para gestionar la candidatura. Mientras, la segunda contiene una representación minimizada y seudonimizada, destinada al procesamiento con Inteligencia Artificial.

BASE DE DATOS OPERATIVA
Información completa de la candidatura
│
│ relación gestionada por la aplicación
↓
MINIMIZACIÓN + SEUDONIMIZACIÓN
↓
BASE DE DATOS PARA IA
Referencia + información necesaria
↓
MODELO DE IA
↓
Resultado asociado a la referencia
↓
APLICACIÓN
↓
Relación interna con la candidatura

La IA trabaja sobre una referencia y sobre la información necesaria para el análisis. Después, es la aplicación la que vuelve a relacionar el resultado con la candidatura.

La idea es sencilla: la IA no necesita conocer la identidad de una persona para analizar muchos de los elementos profesionales de su candidatura.

Esto no convierte los datos en anónimos porque, si la organización conserva la información que permite relacionar la referencia con la persona, hablamos de seudonimización, no de anonimización.

Tampoco lo resuelve todo. El texto libre de un currículum conserva identificadores indirectos, como nombres de empresas, fechas o centros de estudio, y atributos que el modelo no necesita, como el género que revela la redacción. Por ello, la minimización reduce la exposición, no la elimina.

Y dos bases de datos no convierten en legal cualquier tratamiento con IA, ya que la arquitectura facilita aplicar la minimización y la protección de datos desde el diseño, nada más.

Hay, además, un motivo técnico, ya visto en las limitaciones: el contexto irrelevante resta precisión. Minimizar protege a la persona y mejora la decisión.

Qué cambiaría si incorporase Jev

Hoy un LLM recibe la información minimizada de la candidatura y realiza varios análisis sobre ella. Un modelo de decisión permitiría separar mejor las responsabilidades.

Supongamos que el puesto exige cinco años de experiencia y la candidatura acredita siete:

Experiencia mínima requerida: 5 años
Experiencia acreditada: 7 años

La comparación es código. No necesita Jev ni un LLM, y TypeSafe expresamente dejar la aritmética y la comparación de fechas fuera del modelo.
Lo que no es código es el paso anterior: obtener esos siete años de experiencia relevante a partir del texto de un currículum. Decidir qué experiencia cuenta como relevante ya es un juicio semántico, y se parece a esta pregunta:

¿La experiencia descrita está relacionada con las funciones de mantenimiento industrial definidas para este puesto?

Un modelo de decisión es adecuado aquí si definimos bien las respuestas posibles y los criterios.

Otra tarea es mucho más elaborada:

Explica las principales fortalezas y carencias de esta candidatura respecto al puesto e indica qué evidencias sustentan cada conclusión.

Necesita análisis y generación de lenguaje. Sigue siendo trabajo para un LLM.