Enruta por dificultad, no por defecto

Enterrada en la reconstrucción de Siri hay una decisión de arquitectura que merece más atención que el titular sobre Gemini. La nueva Siri de Apple usa un sistema de enrutamiento de tres niveles que decide dónde se procesa cada petición. Lo simple —poner un temporizador, reproducir una canción— corre por completo en el teléfono, sin que ningún dato salga del dispositivo. Las peticiones de complejidad moderada van al propio Private Cloud Compute de Apple, donde se procesan y se olvidan de inmediato. Solo el razonamiento más pesado se envía al modelo gigante Gemini en la nube de Google.

Fíjate en lo que Apple no hizo: elegir un solo modelo y enviarle todo. Y esa es la lección, porque elegir un solo modelo para todo es exactamente lo que hace la mayoría de la gente que construye productos de IA, y es, calladamente, el valor por defecto equivocado en dos ejes distintos a la vez.

Un solo modelo para todo se equivoca dos veces

Manda cada petición a un único modelo grande y cometes dos errores al mismo tiempo.

El primero es el costo. La mayoría de las peticiones son fáciles. «Reformatea esta fecha», «¿es spam este correo?», «resume este párrafo»: estas no necesitan un modelo de frontera más de lo que sumar necesita una supercomputadora. Enrutarlas a tu modelo más caro significa pagar precios premium por trabajo trivial, en cada llamada, para siempre. La investigación sobre enrutamiento basado en dificultad muestra que puedes recortar las llamadas al modelo grande en alrededor de un 40% sin pérdida de calidad, con solo mandar el trabajo fácil a un modelo pequeño y escalar únicamente cuando de verdad es difícil. Esa es la idea del modelo barato para la mayor parte del trabajo, convertida en infraestructura.

El segundo error es la exposición. Algunas de tus peticiones contienen datos sensibles: detalles de salud, registros financieros, mensajes privados. Mandar eso a un modelo en la nube de un tercero está bien para buscar una receta y es un problema serio para un expediente médico. Un solo modelo para todo significa que tu dato más sensible viaja por el mismo camino que el más trivial, hacia quienquiera que aloje el modelo. Todo el punto de Apple es que el temporizador y la consulta privada no deberían recorrer la misma ruta.

El enrutamiento arregla ambas cosas a la vez. Y los dos ejes —qué tan difícil es esto y qué tan sensible es esto— son todo el diseño.

Las dos preguntas que deciden la ruta

Antes de que una petición llegue a un modelo, hazle dos preguntas:

¿Qué tan difícil es? Enruta por dificultad. Manda todo por defecto al modelo más barato y rápido que plausiblemente pueda manejarlo, y escala a uno más grande solo cuando el pequeño no sea suficiente. Este es el patrón de «cascada»: prueba primero lo local o lo barato, promueve al modelo caro al fallar, y no al revés. El modelo caro se vuelve la excepción, no el valor por defecto, y tu factura lo sigue.

¿Qué tan sensible es? Enruta por dato, no solo por costo. Las peticiones genuinamente sensibles deberían quedarse en el nivel más privado que tengas —en el dispositivo o en tu propia infraestructura— y, esto es clave, no deberían caer silenciosamente a una nube pública si la ruta privada está ocupada. La disciplina aquí es "fail closed": si no puedes procesar un dato sensible de forma privada, te rehúsas, no lo mandas calladamente a un tercero. Apple lo impone con anonimización y contratos que impiden que Google entrene con las consultas de los usuarios; tu versión quizá sea más simple, pero el principio es el mismo: la sensibilidad decide la ruta, y la falla segura es «no», no «mándalo de todos modos».

Por qué la mayoría de quienes construyen se lo saltan

El enrutamiento es más trabajo que llamar a un solo endpoint, así que la razón honesta por la que la gente se lo salta es que un solo modelo para todo es fácil de lanzar. Conectas el modelo de frontera, maneja todos los casos, listo. Funciona; solo que es caro y permeable de maneras que no ves hasta que llega la factura o la fuga.

Pero no necesitas los tres niveles de Apple para obtener el beneficio. Incluso una versión tosca rinde frutos: un modelo barato como valor por defecto, una escalada a un modelo fuerte cuando una comprobación de confianza o el tipo de tarea dice «esto es difícil», y una regla dura de que las peticiones marcadas como sensibles se quedan en una ruta que tú controlas. Son unas pocas horas de plomería que recortan el costo de forma significativa y encogen tu superficie de exposición al mismo tiempo. La sofisticación puede venir después; lo que importa es la forma: barato y privado por defecto, escalar a propósito.

En resumen

La parte llamativa de la historia de Siri es que Apple rentó el cerebro de Google. La parte útil es lo que Apple puso delante de ese cerebro: un enrutador que manda cada petición al lugar más pequeño y más privado que pueda manejarla, y recurre al modelo grande y caro de la nube solo cuando no le queda otra. Eso no es un lujo de Apple. Es el patrón que cae por su propio peso en cuanto tomas en serio el costo y la privacidad, y escala hasta abajo, hasta un proyecto de una sola persona.

Así que deja de mandar todo a un solo modelo por defecto. Haz las dos preguntas —qué tan difícil, qué tan sensible— y deja que las respuestas elijan la ruta. La mayor parte de tu tráfico es fácil y nada especial, y enrutarlo en consecuencia es la diferencia entre un producto de IA que es barato y seguro por diseño y uno que es caro y está expuesto por accidente. Un solo modelo para todo no es simplicidad. Es un valor por defecto que en realidad nunca elegiste.