Cuando el modelo dice que no

Esta semana nuestro reporte de errores marcó una clase de rechazos que no habíamos contemplado: en temas histórica o políticamente sensibles, la API del proveedor del modelo responde con un rechazo por política de contenido en lugar de una completion — incluso cuando la solicitud es claramente legítima. El rechazo es de la capa propia del proveedor, no nuestra, y el usuario ve un cuerpo de error crudo en un idioma que casi con seguridad no lee.

Dos filtros, no uno

Cada prompt en OnePress pasa primero por nuestro propio filtro de entrada — un requisito contractual de nuestro procesador de pagos, y uno razonable. Estas solicitudes lo pasan, correctamente: el trabajo claramente legítimo es exactamente el tipo de tráfico que debería pasar sin fricción.

El rechazo viene de un segundo filtro que ni nosotros ni el usuario controlamos: el filtrado de contenido a nivel de plataforma del propio proveedor del modelo, que inspecciona el tráfico por encima del modelo mismo. Las solicitudes que tocan temas políticamente sensibles caen en un territorio que la capa de cumplimiento de una jurisdicción trata como inseguro. La misma solicitud es trabajo completamente ordinario en cualquier otro lugar.

El descubrimiento útil: el filtro no está en el modelo

Esta es la parte que cambió nuestra arquitectura. Enviamos una solicitud similar propia — la misma clase de contenido — a los exactos mismos pesos del modelo, pero servidos a través de un host distinto: OpenRouter, enrutado a proveedores de inferencia en EE. UU. Mismos pesos, misma clase de prompt. Generación completa, sin rechazo.

Así que el rechazo nunca estuvo en el modelo. Vive en la capa de servicio — la envoltura de cumplimiento que un proveedor pone alrededor de su API. Lo que significa que se puede enrutar alrededor de ella, de forma limpia y abierta, sin tocar el modelo en absoluto.

Lo que cambiamos

• Cada modelo ahora existe dos veces en el selector. El conjunto por defecto enruta vía OpenRouter a proveedores de inferencia fuera de la China continental; los mismos cuatro modelos siguen disponibles en sus API de origen, etiquetados (CN), para quien los prefiera.
• Las solicitudes de OpenRouter llevan una lista permitida upstream. Fijamos las solicitudes a proveedores concretos y desactivamos el fallback — si la lista fijada no puede servir, la llamada falla ruidosamente en lugar de aterrizar silenciosamente en una ruta filtrada.
• Los rechazos del proveedor ahora producen un mensaje legible. Un rechazo por política de contenido se explica en lenguaje claro y apunta al selector de modelos — se acabaron los bloques de error crudos en un idioma que el usuario no lee. Los marcos de error incrustados a mitad del stream, que antes se tragaba el sistema y parecían una respuesta vacía, también salen a la superficie como deben.
• Las tareas en segundo plano también se movieron. La generación de títulos y resúmenes lee el mismo contenido de la conversación, así que usa el mismo endpoint de OpenRouter.

Los bordes honestos

Dos compromisos que vale la pena nombrar. Primero, no todos los modelos tienen una ruta sin filtrar: el tier flash hospedado de Qwen solo existe detrás del upstream propio de Alibaba, así que el slot de OpenRouter para Qwen ejecuta la variante de pesos abiertos de 27B — un modelo diferente, y lo etiquetamos honestamente. Segundo, fijar significa que una lista permitida totalmente caída devuelve un error en lugar de degradar a una ruta filtrada. Es una elección deliberada: un fallo visible le gana a un cambio invisible de sede.

El mayor es filosófico. Para un producto internacional, la ruta por defecto probablemente no debería heredar la línea editorial de ninguna jurisdicción en concreto — no porque el filtro sea malicioso, sino porque su definición de «sensible» fue escrita para otra audiencia. Los valores por defecto ahora asumen el contexto del usuario, no el del proveedor.