Tu modelo es un proveedor, no infraestructura

Hay una suposición silenciosa metida en la mayoría de los productos de IA: que el modelo es infraestructura — como la electricidad o el DNS, algo que simplemente siempre está ahí. Conectas tu producto directo al mejor modelo de un proveedor y sigues adelante, porque ¿por qué iba a desaparecer?

Por esto. No es infraestructura. Es un proveedor — uno con una vida útil cada vez más corta y un botón de apagado que no tienes tú.

La vida útil se acorta, no se alarga

Las ventanas de soporte de los modelos se han comprimido de los 18–24 meses que solías tener a aproximadamente 6–12 meses. OpenAI lanzó varias oleadas de deprecación en 2026; GPT-4o fue retirado, la Assistants API eliminada, y clases enteras de integración tuvieron que reescribirse según el calendario del proveedor, no el tuyo. Aquello sobre lo que construiste es un objetivo en movimiento que se mueve estés listo o no.

Y puede moverse por razones que no tienen nada que ver contigo. Claude Fable 5 se lanzó en junio de 2026 y, días después, el acceso fue supuestamente suspendido en todo el mundo bajo una directiva estadounidense de control de exportaciones. Imagina que ese es el modelo del que depende tu producto. Ningún bug de tu lado, ninguna advertencia sobre la que pudieras actuar — el proveedor simplemente desapareció, por orden del gobierno.

Si el roadmap de una sola empresa — o la política de exportación de un gobierno — puede tumbar tu producto de la noche a la mañana, no construiste un producto. Construiste una dependencia con pantalla de login.

Por qué "usa el mejor modelo y ya" es un riesgo de negocio

Cablear el buque insignia de un solo proveedor parece una decisión de calidad. En realidad es una apuesta de continuidad: estás apostando a que este modelo específico, en este endpoint específico, siga disponible y estable durante todo el tiempo que tu negocio lo necesite. Cada deprecación, cambio de precio, bloqueo por región y giro de política es ahora tu emergencia. El modelo nunca fue tu foso — y desde luego no es tu cimiento.

La portabilidad es el seguro barato que nadie contrata

El arreglo es aburrido y es la misma disciplina en la que sigo aterrizando:

• Pon el modelo detrás de un adaptador. Tu producto habla con tu interfaz; el proveedor se sienta detrás de ella. Cambiar de modelo es un cambio de config, no una reescritura. Esto es exactamente lo que te compra un router como OpenRouter en la capa de infra.
• Mantente evaluado en dos proveedores, no en uno. Ten un segundo modelo caliente y probado sobre tus tareas reales, para que "nuestro proveedor se apagó" sea un interruptor que accionas, no un proyecto que arrancas.
• Sé dueño de las partes que de verdad son tuyas. Tus prompts, tus datos de grounding, tus evals, tu pegamento — esos son activos portables. Mantén el modelo como la parte reemplazable, porque lo es.
• Lee la política de deprecación antes de construir, no después. La ventana de soporte, el plazo de aviso y los términos de región son decisiones de producto. Trátalos como tratarías el contrato de cualquier proveedor crítico.

Nada de esto es sobreingeniería. Es lo que haces con cualquier dependencia que puede desaparecer — y esta puede cambiar de dueño o esfumarse de la noche a la mañana.

En resumen

El modelo de frontera parece un servicio público porque es cómodo fingir que lo es. Pero los servicios públicos no quedan sujetos a control de exportaciones, ni se retiran según el calendario de un proveedor, ni se reprecian a voluntad. El tuyo sí.

Trata al modelo como un proveedor que puedes despedir — ponlo detrás de un adaptador, mantén un segundo probado, y sé dueño de todo lo que lo rodea. El mal día del proveedor no debería ser tu caída.