El benchmark de Jev identifica un modelo de decisión útil, no un razonador de frontera

TypeSafe AI presentó Jev como una inteligencia de nivel frontera sin alucinaciones, pero un benchmark independiente de Jev que abarcó 16.379 solicitudes reales llegó a una conclusión más moderada.

Jev es rápido, económico de operar y excepcionalmente eficaz en decisiones acotadas. No es un razonador de frontera, según los investigadores. Tampoco puede reemplazar a un modelo de lenguaje cuando una tarea exige texto original, explicaciones detalladas o razonamiento sostenido.

Ese resultado solo parece una derrota si Jev debe competir directamente con los modelos más grandes. Una comparación más útil es entre dos herramientas diferentes: un modelo general capaz de generar casi cualquier cosa y un servicio compacto de decisiones diseñado para devolver respuestas predefinidas con rapidez.

La segunda categoría es menos llamativa. También podría encajar en miles de decisiones de software que los sistemas actuales de IA resuelven de forma ineficiente.

El benchmark de Jev replantea las mayores afirmaciones de TypeSafe AI

Los resultados independientes debilitan la narrativa de Jev como modelo de frontera, a la vez que refuerzan el argumento a favor de Jev como infraestructura especializada.

TypeSafe AI lanzó Jev como su primer modelo “System One”. El término describe un modelo optimizado para juicios rápidos en lugar de deliberación lenta y explícita.

La empresa presenta el servicio como una vía directa desde información no estructurada hasta decisiones tipadas. Una aplicación proporciona un estado, como un ticket de soporte o un registro de transacción, seguido de una o más preguntas.

Jev no devuelve un párrafo. Puede elegir entre opciones proporcionadas, asignar una posición en una escala ordenada o devolver una probabilidad para una proposición de sí o no.

Esa interfaz respalda una propuesta atractiva. El software recibe un valor predecible en vez de texto generado que debe analizarse, validarse y, a veces, volver a intentarse.

TypeSafe también asocia Jev con inteligencia de frontera, latencia muy baja e incapacidad de alucinar. Estas afirmaciones hacen que el modelo parezca un sustituto del razonamiento general de alto coste.

El repositorio del benchmark de Jev independiente pone a prueba esa interpretación. Sus autores evaluaron la API jev-1.13.0 durante septiembre de 2026 y publicaron la tercera revisión de su informe el 3 de octubre.

El proyecto envió 16.379 solicitudes de benchmark reales a través de tres conjuntos de evaluación congelados. También realizó una prueba de arquitectura de 987 llamadas, experimentos de conteo de tokens, pruebas de comunicación interactiva y comparaciones con 12 modelos económicos.

Las puntuaciones principales fueron respetables. Jev alcanzó el 82,7 por ciento en la evaluación MMLU-Pro solicitada en su totalidad y el 76,5 por ciento en GPQA Diamond.

MMLU-Pro mide conocimientos y razonamiento en muchas materias mediante preguntas desafiantes de opción múltiple. GPQA Diamond contiene preguntas científicas difíciles diseñadas para resistir la coincidencia superficial de patrones.

Estos resultados sitúan a Jev muy por encima de un clasificador simple. No establecen estatus de frontera, especialmente cuando los protocolos de comparación difieren entre proveedores.

Los investigadores advierten explícitamente contra tratar los números de clasificaciones externas como evidencia de comparaciones directas controladas. Los modelos pueden recibir distintos prompts, formatos de respuesta, configuraciones de muestreo o reglas de puntuación.

La conclusión más sólida del informe surge del patrón general de capacidades. Jev manejó bien las elecciones restringidas, pero tuvo dificultades con el perfil de razonamiento más amplio esperado de los principales modelos generales.

Sus conocimientos evaluados parecían más sólidos en torno a la información de 2024 y poco fiables respecto a las noticias de 2025. Su comportamiento aritmético y a nivel de dígitos también reveló debilidades incompatibles con un razonador general de primer nivel.

La descripción final del equipo es tajante pero útil: Jev parece ser un modelo pequeño con una salida de probabilidad que reemplaza una cabeza de generación convencional.

Ese juicio sigue siendo una inferencia basada en el comportamiento observable de la API. Los investigadores no inspeccionaron los pesos, datos de entrenamiento, gradientes ni infraestructura de servicio de TypeSafe.

Aun así, la escala de la evaluación importa. Una demostración de empresa puede mostrar lo que hace un sistema en condiciones favorables. Miles de solicitudes congeladas revelan lo que hace repetidamente, incluidos los casos en los que el lenguaje de marketing supera a la evidencia.

Por qué “no puede alucinar” necesita una definición acotada

Jev puede garantizar una forma de salida válida, pero no puede garantizar un juicio correcto.

La mayoría de las personas entiende una alucinación de IA como una respuesta segura que es falsa o carece de respaldo. Bajo esa definición, un modelo puede alucinar incluso cuando devuelve datos con un formato perfecto.

TypeSafe usa el término de manera más restringida. Jev no puede generar una categoría fuera de las opciones proporcionadas por quien realiza la llamada. Tampoco puede inventar un nombre de herramienta malformado ni añadir un ensayo inesperado a una respuesta estructurada.

Considere una pregunta de enrutamiento de soporte con tres respuestas permitidas: facturación, soporte técnico y seguridad de la cuenta. Jev debe elegir dentro de ese conjunto declarado.

No puede devolver “departamento de felicidad del cliente”, porque ese valor no existe en el tipo de respuesta. Un modelo generativo al que se le pide producir JSON podría inventar una etiqueta así o incumplir el esquema requerido.

Esa es una ventaja real de ingeniería. Los fallos de esquema crean bucles de reintento, lógica de respaldo, ruido de monitorización y latencia impredecible.

Sin embargo, Jev aún puede enviar un problema de facturación a seguridad de la cuenta. La respuesta sigue siendo válida a nivel de tipo, pero incorrecta a nivel de tarea.

La distinción es esencial porque “no puede alucinar” sugiere más certeza de la que ofrece la seguridad de tipos. Jev elimina salidas no válidas, no decisiones incorrectas.

El benchmark detectó un cumplimiento del esquema muy sólido bajo carga. En las etapas de preguntas de texto, los investigadores registraron solo 19 respuestas no válidas según el contrato. Dieciocho se produjeron entre las 12.032 llamadas de MMLU-Pro.

Las demás etapas evaluadas no produjeron fallos comparables. Ese rendimiento respalda la afirmación de TypeSafe de que la interfaz devuelve valores estructurados de forma fiable.

No respalda una afirmación más amplia de que Jev nunca produzca respuestas falsas. Las puntuaciones de precisión inferiores al 100 por ciento ya refutan esa interpretación.

La salida de probabilidad de Jev ayuda a gestionar el riesgo restante. Una aplicación puede aceptar automáticamente clasificaciones seguras, enviar casos inciertos a un modelo de frontera y reservar decisiones ambiguas o de alto impacto para las personas.

Ese flujo de trabajo depende de la calibración. Un modelo calibrado asigna probabilidades que coinciden con las frecuencias observadas en muchos casos similares. Las predicciones cercanas al 80 por ciento deberían ser correctas aproximadamente el 80 por ciento de las veces dentro de un grupo adecuadamente definido.

La calibración no es una promesa sobre una respuesta individual. Un resultado con alta probabilidad aún puede ser incorrecto.

Los investigadores independientes también encontraron que el campo de confianza separado de Jev podía recuperarse en gran medida a partir de la mayor probabilidad mostrada y del número de opciones. No parecía aportar una señal independiente sobre la corrección factual.

Esto no vuelve inútil el campo. Sí significa que los desarrolladores deberían evitar interpretar la “confianza” como un segundo experto que verifica la decisión.

Los equipos necesitan datos de validación de su propia carga de trabajo. Un umbral que funciona para el enrutamiento de atención al cliente puede fallar en la detección de fraude, el análisis de contratos o la moderación de contenido.

La automatización de alto riesgo también necesita una vía de abstención. Un modelo que solo puede devolver opciones válidas siempre parecerá ordenado desde el punto de vista operativo, incluso cuando ninguna de esas opciones se ajuste a la realidad.

La seguridad de tipos evita respuestas malformadas. Un diseño cuidadoso del sistema aún debe impedir que errores bien formados se conviertan en acciones irreversibles.

Qué parece ser Jev internamente

El comportamiento medido apunta a un modelo compacto de estilo transformador con una salida de probabilidad entrenada, no a una API de frontera oculta.

TypeSafe no ha publicado los pesos, el número de parámetros ni la arquitectura detallada de Jev. Eso deja a los desarrolladores con documentación, comportamiento observado e inferencias.

El equipo del benchmark probó cómo cambiaba la latencia con la longitud de entrada, el número de preguntas, el número de opciones, la concurrencia, los patrones de tokens y las solicitudes idénticas repetidas.

Su análisis de arquitectura describe el mecanismo de salida como una lectura de probabilidad entrenada sobre opciones proporcionadas por quien realiza la llamada. No parece texto generado primero y analizado después.

Los valores de probabilidad publicados se situaron en incrementos de 0,01. Entre 704.277 valores reportados en 7.887 vectores de probabilidad, los investigadores no encontraron ningún valor fuera de esa cuadrícula.

Las respuestas de elección podían incluir hasta 255 opciones. Añadir opciones incrementaba los tamaños de entrada y de respuesta serializada, pero generaba poco coste de decisión medido adicional más allá de esos tokens.

Los investigadores también agruparon muchas preguntas en solicitudes individuales. El tiempo de servicio ascendente creció lentamente a medida que aumentaba el número de preguntas, lo que respalda una pasada de evaluación compartida con múltiples salidas.

Ese comportamiento coincide con la afirmación central de diseño de TypeSafe. Jev lee el estado una vez y luego evalúa muchas preguntas sobre él en paralelo.

La documentación del modelo de TypeSafe describe un límite de solicitud de 64.000 tokens, con una restricción adicional de 32.000 tokens que cubre el estado y la pregunta más larga. Enumera el texto como la única entrada nativa.

Por tanto, las imágenes, el audio y el vídeo requieren preprocesamiento. Otro sistema debe convertir esos formatos en texto o campos estructurados antes de que Jev los evalúe.

Las mediciones de latencia aportan la evidencia más convincente del valor especializado de Jev. La prueba independiente estimó un mínimo fijo de tiempo de servicio ascendente cercano a 73 milisegundos, seguido de aproximadamente seis milisegundos adicionales por cada 1.000 tokens de entrada.

Estas cifras procedían de una cabecera de respuesta de Envoy. Incluyen el procesamiento ascendente y el salto de red del proxy, y pueden incluir encolamiento o serialización.

No son una medición pura de la ejecución del modelo en hardware conocido. Aun así, resultan útiles porque describen el comportamiento del servicio que una aplicación encontró realmente.

El tiempo se mantuvo cercano a lineal para entradas de hasta alrededor de 29.000 tokens. Los investigadores no observaron un gran aumento cuadrático en el intervalo probado.

Las adiciones de preguntas y opciones también fueron económicas. El informe no encontró una fase visible de decodificación por token similar a la de un modelo de lenguaje autorregresivo, que genera salida de forma secuencial.

Esa diferencia explica buena parte de la velocidad de Jev. Un modelo de frontera puede leer el prompt, generar una respuesta textual token por token y serializar una llamada a herramienta.

Jev solo necesita puntuar los resultados permitidos y devolver valores numéricos. Evita la larga ruta de generación porque nunca redacta una explicación.

La investigación de arquitectura estima una banda de capacidad equivalente densa de alrededor de cuatro mil millones a 14 mil millones de parámetros. Un modelo denso cuantizado en la parte inferior de ese rango fue la interpretación más sencilla de los investigadores.

Un diseño de mezcla de expertos sigue siendo posible. Las mediciones de la API no pueden revelar si todos los parámetros participan en cada solicitud.

Esta incertidumbre merece énfasis. El equipo reconstruyó Jev a partir de señales externas. No descubrió el código fuente real ni identificó un modelo base.

Sin embargo, sus experimentos hacen que varias alternativas parezcan poco probables. El perfil de latencia, la estructura de salida y el comportamiento de conocimiento no se parecen a un envoltorio que llama en secreto a un proveedor de frontera.

Por tanto, los beneficios de Jev parecen provenir de la especialización, no de acceso oculto a un modelo más grande. Cambia la generación abierta por una ruta computacional adaptada a la clasificación y la puntuación.

Ese intercambio es menos misterioso de lo que implica el marketing. También es más creíble.

El verdadero rival es un modelo general sobredimensionado

Jev importa porque muchos sistemas de producción usan razonamiento generativo costoso para decisiones que nunca requirieron texto generado.

Una plataforma de soporte puede necesitar decidir qué cola debe recibir un mensaje. Un agente puede tener que seleccionar la siguiente herramienta. Un proceso de moderación puede evaluar si un fragmento infringe una política.

Ninguna de esas tareas necesita inherentemente un párrafo. La respuesta suele ser una categoría, una probabilidad o una posición en una rúbrica.

Los desarrolladores suelen enviar este tipo de trabajo a modelos generales de lenguaje porque estos entienden el lenguaje natural sin entrenamiento específico para cada tarea. Luego, la aplicación instruye al modelo para que devuelva JSON.

Ese método es flexible, pero implica una sobrecarga evitable. El modelo genera estructuras token a token, puede incumplir el esquema solicitado y quizá invierta más cómputo en explicar una decisión que la aplicación nunca lee.

Los clasificadores tradicionales ofrecen otra vía. Un equipo puede etiquetar ejemplos, entrenar un codificador más pequeño, calibrarlo, desplegarlo y volver a entrenarlo cuando cambien las categorías o la distribución de los datos.

Ese enfoque puede superar a un servicio general en una tarea estable y de gran volumen. También exige datos, experiencia en aprendizaje automático, infraestructura de despliegue y mantenimiento.

Jev ocupa el espacio entre estos dos enfoques. Acepta criterios en lenguaje natural sin un ciclo de entrenamiento personalizado, pero devuelve resultados preparados para su consumo directo por software.

Esto lo hace especialmente relevante para los sistemas de agentes. Los agentes se enfrentan repetidamente a pequeñas decisiones: qué herramienta corresponde, si un resultado cumple una condición, si una acción parece arriesgada o si otro modelo debería tomar el relevo.

Una aplicación puede plantear varias de estas preguntas en una sola solicitud a Jev. Después, puede aplicar umbrales y políticas mediante código convencional.

Esta división del trabajo importa más que cualquier afirmación de que Jev compite con un modelo de frontera. El código debe realizar la aritmética exacta y la validación determinista. Jev puede gestionar juicios difusos. Un modelo mayor puede generar o razonar cuando la tarea realmente lo requiera.

Una cascada práctica podría enrutar una solicitud con Jev, realizar comprobaciones fijas en código y enviar solo los casos inciertos a un modelo más capaz.

Este diseño reduce la latencia media sin fingir que toda decisión merece aprobación automática. También facilita la inspección del sistema.

El modelo propone probabilidades. La aplicación controla los umbrales, los permisos, las reglas de escalamiento y las acciones irreversibles.

Los informes independientes de campo ya apuntan a este papel. Una prueba de etiquetado de transacciones encontró que Jev era mucho más rápido que varios modelos de frontera, aunque reconocía una clara ventaja de precisión para los sistemas más grandes.

Otra evaluación de decisiones empresariales multilingües informó una precisión cercana a una referencia de frontera en su conjunto de datos específico. También detectó que textos formulados de manera adversarial podían inducir a error al modelo de decisión.

Estos informes usan conjuntos de datos pequeños y específicos de cada tarea. No deben generalizarse como una clasificación universal.

Sí muestran por qué Jev atrae atención. Los desarrolladores tienen muchas tareas acotadas en las que un juicio suficientemente bueno, una estructura predecible y una baja demora importan más que una respuesta elocuente.

Jev no es la única solución posible. Los modelos abiertos pequeños, los codificadores ajustados, los clasificadores de embeddings, las reglas y las API de moderación alojadas pueden abordar cargas de trabajo superpuestas.

Su propuesta distintiva es una interfaz general de decisión. La misma API puede clasificar un ticket, puntuar una respuesta, enrutar un agente o evaluar si una proposición se desprende del texto proporcionado.

Esa flexibilidad reduce el coste inicial de probar un nuevo flujo de trabajo. No elimina la necesidad de comparar Jev con alternativas más simples.

Una regla de palabras clave podría resolver un problema sencillo de enrutamiento con mayor fiabilidad. Un codificador entrenado puede imponerse una vez que un equipo acumule suficientes datos etiquetados. Un modelo de frontera puede seguir siendo necesario cuando las categorías dependan de largas cadenas de razonamiento.

El rival correcto no es un modelo concreto. Es el hábito de usar un sistema generativo grande para cada ramificación difusa de una aplicación.

Dónde sigue fallando el modelo de decisión Jev

La interfaz limitada de Jev elimina una clase de fallos, pero concentra el riesgo en los criterios, el estado de entrada y la política de automatización.

La limitación más evidente es la generación. Jev no puede redactar un correo electrónico, resumir una reunión, producir código, explicar un veredicto ni mantener una conversación normal.

Los desarrolladores pueden simular la comunicación ofreciendo palabras o fragmentos como opciones. Los experimentos Talk-to-Jev del benchmark exploraron versiones de esa idea.

Esas pruebas no revelaron un modelo conversacional oculto. Restringir la comunicación a menús produjo un comportamiento incómodo y, en ocasiones, dependió en gran medida del programa local de puntuación.

Un segundo problema es la profundidad de razonamiento. Jev puede hacer más que clasificación superficial, como muestran sus puntuaciones en GPQA y MMLU-Pro.

Sin embargo, los resultados independientes no respaldan la idea de que realice de forma consistente razonamiento de varios pasos al nivel de los modelos de frontera. Sus capacidades se asemejan más a las de un modelo pequeño competente optimizado para elecciones.

La aritmética es otro punto débil. El cálculo exacto debe permanecer en el código, donde los resultados son deterministas y fáciles de probar.

El mismo principio se aplica a fechas, recuentos, comparaciones y transformaciones que el software puede calcular directamente. Pedir a un modelo probabilístico que las realice introduce errores innecesarios.

Los estados largos o ruidosos también exigen precaución. Jev puede aceptar un contexto considerable, pero aceptar texto no es lo mismo que identificar con fiabilidad todos los detalles relevantes.

Los desarrolladores deberían eliminar el material irrelevante, definir los criterios con precisión y comprobar si añadir elementos distractores modifica los resultados. Una ventana de contexto grande no garantiza una atención estable.

La cobertura lingüística plantea otra limitación. TypeSafe afirma que el inglés es el idioma principal de entrenamiento de Jev y recomienda probar otros idiomas en la carga de trabajo objetivo.

El análisis de arquitectura encontró un perfil de tokenizador centrado en inglés. Muchos sistemas de escritura no latinos parecían recibir menos fusiones de varios caracteres, lo que puede hacer que la misma información consuma más tokens.

La inyección de instrucciones sigue siendo una preocupación seria. Jev evalúa el estado proporcionado como lenguaje natural. El texto malicioso dentro de ese estado puede influir en el juicio, a menos que la aplicación circundante separe las instrucciones de confianza del contenido no confiable.

La salida tipada no resuelve esto. Un atacante no necesita que Jev invente una nueva acción si puede empujar la probabilidad hacia una acción permitida pero peligrosa.

Los desarrolladores deberían tratar cada documento, mensaje y página web suministrados externamente como una entrada hostil. Las decisiones de alto impacto necesitan controles independientes fuera del modelo.

El benchmark también observó falta de determinismo. Solicitudes idénticas a nivel de bytes produjeron en ocasiones firmas de respuesta distintas, especialmente en distribuciones de opciones casi planas.

Esto no es inusual en los modelos neuronales alojados. Significa que un equipo no debería construir una política frágil en torno a diferencias minúsculas de probabilidad.

Jev informa probabilidades en incrementos de 0,01. Los umbrales deberían tener en cuenta esta cuadrícula de visualización gruesa, la variación normal del modelo y el cambio de distribución esperado.

Una evaluación de producción debería incluir llamadas repetidas, ejemplos adversariales, categorías poco frecuentes, información faltante y casos en los que ninguna opción proporcionada sea correcta.

También debería medir las consecuencias empresariales. La precisión agregada puede ocultar una tasa de error inaceptable en una clase sensible.

Por ejemplo, enrutar incorrectamente un ticket rutinario genera inconvenientes. Aprobar una transacción fraudulenta o ejecutar una llamada destructiva a una herramienta genera un nivel de daño distinto.

El patrón de despliegue más seguro comienza en modo sombra. Jev produce decisiones, pero el sistema existente conserva la autoridad mientras el equipo mide las discrepancias.

La siguiente fase puede automatizar casos de bajo riesgo y alta confianza. La revisión humana o mediante un modelo de frontera se encarga del resto incierto.

Para flujos de trabajo intensivos en conocimiento, los equipos también necesitan trazabilidad. Jev devuelve un juicio, no una justificación generada con citas.

El sistema circundante debería conservar la entrada, la versión del modelo, los criterios, el vector completo de probabilidades, el umbral y la acción final. Ese registro permite auditorías posteriores cuando cambie el comportamiento.

Aquí es donde una base de conocimiento de IA con búsqueda puede ayudar a los equipos a conservar notas de evaluación, versiones de políticas y evidencias de incidentes. La decisión del modelo nunca debería convertirse en el único registro que sobreviva.

Las limitaciones de Jev son manejables cuando su función se mantiene acotada. Se vuelven peligrosas cuando «no puede alucinar» se interpreta como permiso para eliminar la validación.

Tres señales decidirán si Jev se gana un papel duradero

La siguiente fase debería juzgarse por la replicación independiente, la calibración en producción y la dirección de las actualizaciones del modelo de Jev.

La primera señal es la reproducibilidad del benchmark. El proyecto publicado ofrece código, hashes de entradas congeladas, resultados agregados y una metodología extensa.

Sin embargo, los conjuntos de datos con licencia impiden que el repositorio redistribuya cada elemento del benchmark y cada respuesta sin procesar. Los equipos independientes con acceso legal deberían volver a ejecutar los mismos protocolos frente a la misma versión del modelo.

Los resultados coincidentes reforzarían la conclusión del informe de que Jev ofrece un razonamiento competente propio de modelos más pequeños. Grandes discrepancias revelarían sensibilidad al enrutamiento, los cambios del servicio, los prompts o los detalles de la evaluación.

Los investigadores también deberían comparar Jev con modelos abiertos pequeños actuales en condiciones idénticas. Las puntuaciones de clasificaciones externas ayudan a establecer contexto, pero los prompts y las métricas equivalentes son más convincentes.

La segunda señal es la calibración en producción. Más equipos necesitan publicar curvas de fiabilidad procedentes de tareas reales de clasificación, enrutamiento, moderación y control de agentes.

Los informes más valiosos separarán la precisión global de los errores de alta confianza. También deberían describir las reglas de abstención, las tasas de revisión humana y cómo cambia el rendimiento después de que se alteren las distribuciones de entrada.

Un modelo puede ser valioso sin ganar todas las comparaciones de precisión. Si resuelve rápidamente la mayoría de los casos de bajo riesgo y escala la incertidumbre de manera fiable, puede reducir el coste y la demora totales del sistema.

Esa ventaja desaparece si los errores confiados se concentran precisamente en los casos que un equipo esperaba automatizar.

La tercera señal es la trayectoria de lanzamientos de TypeSafe. La documentación identifica Jev 1.13 como el modelo estable y advierte que los alias pueden cambiar cuando se publique una nueva versión.

Los equipos deberían fijar identificadores de modelo versionados después de calibrar los umbrales. Un cambio de alias puede alterar las probabilidades sin ninguna actualización del código de la aplicación.

Una futura versión de Jev podría mejorar el conocimiento, el razonamiento, el rendimiento multilingüe y la calibración. También podría revelar si la arquitectura actual escala más allá de su nicho actual.

TypeSafe puede facilitar la evaluación publicando tarjetas de modelo, protocolos de benchmark comparables, detalles de calibración y definiciones más claras de sus afirmaciones de marketing.

La empresa no necesita que Jev se convierta en un redactor de frontera. Su oportunidad más defendible es convertirse en la capa de juicio predeterminada dentro del software que ya usa código y modelos más grandes.

Ese mercado depende de la confianza. Los desarrolladores necesitan versiones estables, comportamiento documentado, límites predecibles y evidencia de que la confianza sigue siendo significativa con sus datos.

El benchmark independiente de Jev cambia la historia sin cerrarla. Jev parece más pequeño y menos mágico de lo anunciado. También parece más útil que otro chatbot compitiendo por los mismos prompts.

La pregunta práctica no es si Jev puede sustituir a un modelo de frontera. Es si su aplicación sigue pagando a un modelo de frontera para devolver respuestas que siempre estuvieron limitadas a sí, no o un elemento de una lista.

Audite esas decisiones, cree un conjunto de prueba etiquetado y compare Jev con reglas, modelos pequeños y su proveedor actual. Esa evidencia mostrará si este modelo más limitado merece un lugar en su stack.