El 14 de abril de 2026, Anthropic avisó a los desarrolladores que usaban Claude Sonnet 4 y Claude Opus 4: esas versiones se apagarían el 15 de junio. Dos meses de margen. Quien tenía una rutina apoyada específicamente en esa versión tuvo que probar, ajustar y cambiar antes de la fecha — o dejar de funcionar al día siguiente.
No es un episodio aislado. Según la propia documentación de Anthropic, cada vez que se retira una versión de modelo, las solicitudes enviadas después de la fecha de retiro simplemente fallan. OpenAI sigue una lógica parecida: los modelos de disponibilidad general reciben un mínimo de 6 meses de aviso, las variantes especializadas 3 meses, y los modelos aún en prueba pueden salir del aire con apenas 2 semanas.
Para quien decide dónde va a correr la IA en la empresa, el hecho relevante no es la fecha en sí. Es que la rutina que funcionaba ayer puede simplemente dejar de responder mañana — y el aviso, cuando llega, alcanza a equipos que ya tratan ese flujo como parte de la operación.
Retirar es solo la mitad del problema
Anthropic clasifica cada modelo en cuatro etapas: activo, legado, descontinuado y retirado. En la etapa "descontinuado", el modelo todavía funciona, pero ya no se recomienda — y recibe una fecha de retiro. En la etapa final, la llamada a la API falla por completo. La tabla pública de modelos muestra versiones enteras de Claude 3, Claude Sonnet 4 y Claude Opus 4 ya fuera de servicio en 2026, cada una con una fecha de aviso y una fecha de corte registradas.
OpenAI describe el mismo ciclo con plazos propios: seis meses para un modelo de uso general, tres para una variante especializada, dos semanas para algo todavía en fase de prueba. En algunos casos, la empresa ofrece capacidad dedicada mediante contrato para quien necesita mantener acceso a una versión específica después del apagado — una opción, no una garantía.
El calendario público de Anthropic muestra el patrón repitiéndose año tras año: Claude Opus 4.1 fue avisado el 5 de junio de 2026 y salió de servicio el 5 de agosto — exactamente los 60 días mínimos que promete la política. Antes de él, Claude 2, Claude 2.1 y otras versiones pasaron por el mismo ciclo. El plazo es público y previsible. El problema es que casi nadie en la empresa lo está vigilando hasta que llega el correo de aviso.
El segundo problema, menos comentado, es que el comportamiento cambia incluso cuando el modelo no se retira. Un estudio de investigadores de Stanford y Berkeley comparó el mismo servicio de IA en dos fechas, con tres meses de diferencia, en siete tipos de tarea: matemática, preguntas sensibles, opiniones, razonamiento en varios pasos, generación de código, examen de licencia médica y razonamiento visual. En una de las tareas — identificar si un número es primo o compuesto — el acierto cayó de 84% en marzo a 51% en junio, con la misma etiqueta de versión.
Los autores del estudio resumen el hallazgo en una frase directa: el comportamiento del "mismo" servicio de IA puede cambiar de forma sustancial en un período corto, lo que exige monitoreo continuo. Es decir: ni siquiera esperar el aviso de retiro es suficiente. La versión puede seguir en línea y aun así responder distinto de como respondía hace tres meses.
Por qué el aviso rara vez llega a tiempo a quien decide
El aviso de descontinuación normalmente llega a quien administra la conexión técnica con el modelo de IA — no a quien diseñó la rutina que depende de él. Un comunicado por correo sobre una fecha de corte en dos meses circula entre pocas personas, y el registro de "por qué lo hacemos así" y "qué tiene que entregar esta rutina" casi nunca queda escrito en ningún lado.
Cuando llega la fecha, una pregunta que debería ser simple — "¿qué hace esta rutina y qué necesita seguir haciendo?" — no tiene respuesta lista. Alguien tendrá que reconstruirla a partir del resultado que la rutina producía, sin saber qué instrucciones, qué ejemplos y qué ajustes llevaron a ese resultado. Es trabajo de reconstrucción, no de cambio.
Lo mismo vale para el cambio silencioso que describe el estudio de Stanford y Berkeley. Sin una forma de comparar la respuesta de hoy con la de hace tres meses, nadie nota la caída hasta que aparece un error en producción — y, cuando aparece, el primer instinto suele ser desconfiar de quien operó la rutina, no de la versión del modelo detrás de ella.
Para una empresa de Brasil o América Latina, el efecto suele ser más duro, no más leve. El equipo que arma la rutina de IA rara vez es el mismo que sigue el calendario de versiones de cada proveedor — normalmente es un área de negocio, no un equipo de infraestructura dedicado a eso. Cuando el aviso llega en inglés, con una fecha de corte a dos meses, el mensaje compite con la operación del día a día y, con frecuencia, solo se lee después de que algo ya dejó de funcionar.
Lo que tiene que existir en la práctica
El guion de la rutina pertenece a la empresa, no a una conversación suelta. Lo que la rutina debe hacer, con qué instrucciones, para qué resultado — eso tiene que estar registrado en un lugar central, no solo en la memoria de quien armó la primera versión.
Cada tarea se dirige al modelo de IA adecuado, no fijada a uno solo. Cambiar el modelo detrás de una rutina debería ser una decisión de configuración, hecha en minutos, y no una reconstrucción desde cero cuando el proveedor manda el aviso de apagado.
Probar antes de cambiar es parte del proceso, no un paso extra. Antes de que una rutina crítica pase a correr en un modelo nuevo, el resultado de la versión nueva se compara con el de la anterior en los mismos casos — la misma disciplina que recomienda el estudio de Stanford y Berkeley para cualquier cambio de comportamiento.
Un historial de auditoría muestra qué cambió y cuándo. Cuando un resultado sale distinto de lo esperado, se puede verificar si la causa fue un cambio de modelo, un ajuste en la instrucción u otra cosa — en vez de investigar a ciegas.
Así fue diseñada Skyller: el guion y el historial de cada rutina quedan registrados en la plataforma, con enrutamiento automático hacia el modelo de IA más adecuado para cada tarea, y un historial de auditoría que muestra cada cambio.
La ganancia de no atar la operación a un solo modelo
Cuando el guion pertenece a la empresa y no a una versión específica de modelo, un aviso de descontinuación se vuelve un evento operativo — configuración revisada, resultado comparado, rutina liberada — en vez de una crisis que exige reconstruir desde cero en semanas.
Lo mismo vale para la caída silenciosa de calidad. Un equipo que monitorea el resultado de una rutina crítica nota la variación antes de que un cliente o un auditor la note por ellos. Y el historial de quién aprobó cada versión del guion queda disponible para cualquier revisión futura.
Esto no elimina el trabajo de seguir el mercado de modelos de IA — ninguna empresa se libra de eso. Lo que cambia es dónde vive el conocimiento sobre la propia rutina: en la plataforma que la empresa controla, no solo en la cabeza de quien la creó ni atado a un proveedor específico.
Preguntas para llevar a la próxima reunión de tecnología
Antes de que llegue el próximo aviso de descontinuación, vale la pena responder estas preguntas con quien administra las rutinas de IA de la empresa:
- Si el modelo detrás de la rutina más crítica saliera de servicio mañana, ¿quién sabe reconstruirla y en cuánto tiempo? Si la respuesta depende de una persona específica, el guion no pertenece a la empresa — le pertenece a ella.
- ¿Existe una forma de comparar el resultado de hoy con el de hace tres meses? Sin esa comparación, una caída de calidad solo aparece cuando ya causó un problema visible.
- ¿Cambiar el modelo detrás de una rutina es una configuración o un proyecto? Si es un proyecto, cada aviso de descontinuación se convierte en una crisis evitable.
