Chrome 157 mete un modelo de decisiones en el navegador: cuándo le gana a tu motor de reglas y cuándo no

La Decisions API de Chrome (window.DecisionModel) permite que un sitio le haga preguntas cerradas al navegador —sí/no, elegir entre opciones, puntuar— y reciba la respuesta con su probabilidad, calculadas en el equipo del usuario, en una sola pasada del modelo y sin que el texto salga del dispositivo. El código aterrizó en Chromium entre el 6 y el 8 de octubre de 2026, la bandera chrome://flags#decisions-api viaja en la beta de Chrome 157 —que sale hoy, 14 de octubre— con estable previsto para el 3 de noviembre. Nuestra postura, después de leer los code reviews y las pruebas independientes: todavía no la enviaríamos a una interfaz en producción. La precisión va del 38% al 85% según el esquema de preguntas, así que el esquema es el producto, y una puerta de confianza mal diseñada es peor que un if de verdad.

Qué es, en una sola frase

Un if cuya condición la entiende el modelo en lugar de la persona que escribió el código. Describes las preguntas en un esquema —cada una de tipo boolean, choice o score—, le pasas el texto del usuario y recibes, por cada pregunta, la etiqueta ganadora, un confidence entre 0 y 1 y la distribución completa de probabilidades:

const model = await DecisionModel.create({
  questions: [{
    id: "intention",
    prompt: "¿El visitante busca comprar o solo informarse?",
    type: "choice",
    options: [
      { label: "comprar", description: "quiere precio, stock o demo" },
      { label: "informarse", description: "quiere explicación o comparativa" }
    ]
  }]
});

const result = await model.decide(textoDelVisitante);
// result.intention.label / .confidence / .probabilities

Antes de crear nada, DecisionModel.availability() devuelve available, downloadable, downloading o unavailable. downloadable no es "sí": es "todavía no".

Por qué no es solo otro Prompt API

La diferencia no es de nombre, es de arquitectura. El Prompt API decodifica token a token —cientos de milisegundos por respuesta, salida libre que hay que parsear—. La Decisions API hace scoring logarítmico en una sola pasada: el texto de entrada y cada respuesta candidata se comparan por similitud de coseno y las semejanzas se convierten en probabilidades con un softmax a temperatura 0,05. El resultado es un motor de decisión de tipo "Sistema 1", no un generador de frases.

Las cifras de los primeros tests independientes dan la escala: ~0,2 s por decisión con EmbeddingGemma, ~1,5 s con Laya y ~2,4 s con Gemma 4 (RESONEO, pruebas sobre 414 consultas). Ninguno compite con un if local: la comparación correcta es contra un viaje de red a un LLM de servidor.

Tres límites del código conviene conocer antes de entusiasmarse:

La API comparte además la Permissions Policy language-model con el Prompt API: quien ya controla quién puede usar IA integrada en su origen controla esta con la misma llave.

Las tres piezas que llegaron en la misma semana

Esto no es una función aislada. Entre el 6 y el 8 de octubre de 2026 se movieron tres piezas que solo tienen sentido juntas:

MediaPipe Decision Maker ya funciona hoy en cualquier sitio (documentación oficial): mismas tres primitivas (BooleanQuestion, ChoiceQuestion, ScoreQuestion), mismos motores, salida con probabilidades calibradas. La diferencia está en quién paga el modelo: en MediaPipe cada sitio descarga el suyo —RESONEO midió unos 165 MB con EmbeddingGemma 2 y 678 MB con Laya—, mientras que Chrome compartiría un único modelo entre todos los sitios del mismo usuario. Cambia también la telemetría: MediaPipe reporta a Google el sitio, el navegador, el recuento de decisiones y los tiempos, pero no el texto.

El esquema es el producto: del 38% al 85%

Es el hallazgo que debería frenar cualquier entusiasmo. En la prueba independiente más completa publicada hasta ahora —414 consultas en francés e inglés sobre 11 esquemas simulados de coches, hoteles y electrodomésticos—, el motor por defecto con el esquema por defecto acertó el 38% de las veces y cayó en la opción "cualquiera" el 70%. Cuatro ajustes de redacción del esquema —describir cada opción, no solo etiquetarla— subieron eso al 58%. Con el mejor motor de los probados, hasta el 85%. La misma API, la misma consulta, cuatro reescrituras de esquema: 47 puntos de diferencia.

Un segundo dato viene de la lectura de los code reviews (DEJAN, 8 de octubre de 2026): como cada respuesta candidata repite el texto de la pregunta, sus embeddings comparten un componente grande, el margen entre ellas se estrecha y la confianza colapsa hacia el uniforme. Un revisor de Google lo señaló en la propia revisión. Traducción práctica: confidence > 0.5 como umbral de seguridad es casi una declaración de intenciones, no una puerta.

Por eso nuestra política se apoya en el margen entre la primera y la segunda opción, no en la confianza bruta: la diferencia tiene que ser lo bastante grande como para que la alternativa determinista no tenga nada que decir.

Cuatro caminos para la misma decisión

El error típico es presentar esta API como el sustituto del motor de reglas. No lo es: es una cuarta vía para un tipo de decisión muy concreto —texto libre del usuario convertido en una opción cerrada—.

Y dentro de la vía on-device, tres motores con perfiles distintos:

Nuestra política de envío: seis reglas

Antes de que un modelo de decisión toque una interfaz real:

1. Nunca en caminos sin supervisión. Dinero, permisos, publicación, borrado: fuera. Un motor de decisiones con 38% de acierto en el peor caso no firma nada irreversible.
2. Puerta por margen, no por confianza bruta. Exige que la opción ganadora supere a la segunda por un margen definido (nosotros fijamos 0,15 sobre la distribución). La confianza colapsa hacia el uniforme; el margen no miente tanto.
3. availability() antes que promesa. downloadable y downloading se tratan como "todavía no". Si el modelo no está listo, la ruta determinista gana, no espera.
4. Descarga solo tras gesto del usuario. Chrome ya lo exige desde el 8 de octubre: lanza la descarga en la primera interacción real, no en el render.
5. Dos semanas de sombra. Registra las decisiones del modelo al lado de las de tus reglas, sin aplicarlas: dos semanas de tu tráfico real dicen si el esquema acierta sobre tu texto, no sobre 414 consultas ajenas.
6. El fallback determinista nunca se borra. Misma doctrina que con navigator.cpuPerformance: lo desconocido se trata como el valor seguro. Sin API —Firefox, Safari, Android, Chrome anterior a 157—, el sitio se comporta exactamente como antes.

Qué hacemos hoy

Nada de esto es nuevo como doctrina; lo que cambia es el objeto. Cuando argumentamos que el ciclo de dos semanas de Chrome obliga a un patrón de adopción —habilitar cuando existe, seguir funcionando cuando no— hablábamos de APIs de CSS. La Decisions API es el mismo patrón con una pregunta de producto detrás: ¿qué parte de tu interfaz decide cosas que hoy resuelves con reglas escritas a mano?

Las reglas ganan cuando el criterio es explícito, auditable y el input ya llega estructurado —la automatización con reglas sigue ganando a los agentes en procesos acotados, y esta API no cambia eso. El modelo gana cuando el input es texto escrito por una persona y la salida es una de tres opciones posibles: filtros de búsqueda, intención de una consulta, clasificación de un mensaje entrante. Ahí, y solo ahí, un "if semántico" en el dispositivo ahorra un viaje de red, una factura de tokens y una fuga de datos.

La línea de fondo

Chrome 157 convierte una pregunta de arquitectura en algo que puedes probar este trimestre: no "¿debería usar IA en el front-end?" sino "¿qué decisiones de mi interfaz siguen dependiendo de que alguien haya escrito la regla correcta". La respuesta correcta hoy es conservadora —bandera, sombra, margen, fallback— y lo seguirá siendo: la API es solo de escritorio, caduca en el hito 160 y su acierto depende casi por completo de cómo escribas el esquema. Escríbelo bien y es un salto de 47 puntos. Escríbelo como lo escribiría cualquiera y tienes un 38% firmando decisiones que antes eran gratuitas y correctas.