Descontinuación de modelos de IA en producción

La descontinuación de modelos de IA comienza antes de que la API deje de responder. El 30/09/2026, Anthropic anunció el retiro de Claude Sonnet 4.5 de la Claude API para el 30/11: son 61 días en ese caso. La fecha no identifica quién hace las llamadas. Un inventario, las pruebas y la comprobación del uso residual convierten el aviso en una migración verificable.

Cuadro de decisión / Datos clave: El plazo anunciado debe confirmarse en la plataforma contratada. Cada dependencia necesita un responsable y un criterio de aceptación. Un sustituto recomendado todavía debe probarse con la carga de trabajo. El fallback protege ante fallas; no demuestra que la dependencia se haya retirado.

La secuencia de trabajo tiene cinco pasos:

1. Registrar el aviso y la fecha aplicable a la ruta contratada.
2. Identificar las aplicaciones que todavía llaman al modelo.
3. Priorizar las dependencias y asignar plazos de decisión.
4. Evaluar sustitutos con los criterios de la carga de trabajo.
5. Migrar por etapas y preparar un retorno seguro.

Después del cambio, el equipo verifica el uso residual por aplicación. Que un modelo todavía responda no garantiza que el plazo siga disponible, y un fallback bien configurado no demuestra que todos los consumidores se hayan migrado. La guía de fallback de LLM aborda la disponibilidad durante fallas; aquí el problema es retirar una dependencia que ya tiene fecha de cierre.

¿Qué requisitos exige la descontinuación de modelos de IA?

El equipo necesita documentación de la ruta contratada, un historial de llamadas con una ventana conocida y acceso a la configuración de las aplicaciones. También necesita responsables de negocio e ingeniería, presupuesto para pruebas y un entorno autorizado. Las llamadas directas cuentan. El relevamiento debe incluir las solicitudes que no pasan por el gateway.

Antes de abrir la hoja de cálculo, alguien debe confirmar quién puede consultar los registros, las exportaciones y los repositorios, además del tiempo de retención de cada fuente. Sin registros no hay prueba. Si una fuente no cubre el período necesario, existe una brecha de cobertura y el equipo no puede concluir que la aplicación dejó de usar el modelo. Debe registrar la fuente, la ventana disponible y quién puede confirmar el uso fuera de ella.

El inventario incluye producción y los demás entornos capaces de enviar solicitudes relevantes, integraciones, tareas programadas e identificadores de claves. Un identificador no es el secreto. El registro no debe contener el valor de la clave, y el acceso a las evidencias de prueba debe seguir las reglas internas para los datos utilizados. El responsable de negocio define el resultado aceptable; ingeniería identifica la ruta y organiza las pruebas. Finanzas necesita conocer el límite disponible para la evaluación.

Paso 1: registra el aviso y la fecha de tu ruta

El registro del aviso reúne la URL, el modelo y su versión, el proveedor, la plataforma contratada, el alcance, el sustituto indicado y el responsable. La fecha de retiro debe corresponder a la plataforma que usa la aplicación. La hora puede faltar. En ese caso, el campo permanece como GAP hasta que el proveedor lo confirme.

La documentación de Anthropic distingue modelos activos, heredados, descontinuados y retirados. Según la definición de la empresa, un modelo de IA descontinuado todavía funciona, pero deja de recomendarse y recibe una fecha de retiro; las solicitudes a un modelo retirado fallan. Esta conducta corresponde a la política citada y no debe atribuirse automáticamente a otro proveedor.

Para claude-sonnet-4-5-20250929, el aviso del 30/09/2026 y el retiro indicado para el 30/11/2026 delimitan 61 días calendario. La política es específica. Anthropic declara un aviso mínimo de 60 días para clientes con implementaciones activas de modelos disponibles públicamente. Ninguna de esas cifras establece un plazo típico universal del mercado: ese dato sigue siendo un GAP.

La fecha también tiene dirección. La documentación indica que sus fechas se aplican a plataformas operadas por Anthropic y que las plataformas operadas por socios pueden tener calendarios propios. El equipo consulta la vía contratada antes de incorporar el plazo al plan y fija una fecha interna anterior al retiro. Esa anticipación es una decisión operativa del equipo, no un acuerdo de nivel de servicio universal.

Paso 2: identifica quién todavía llama al modelo

El inventario cruza las llamadas registradas en el gateway, las exportaciones del proveedor y las referencias en código, configuraciones y tareas programadas. Cada dependencia recibe aplicación, entorno, identificador seguro de la clave, equipo, responsable principal, sustituto y última llamada observada. Las fuentes y la ventana de recolección deben figurar junto a los resultados.

Un inventario de migración es el registro conciliado de aplicaciones, identificadores de llamada, responsables, ventana de observación y estado de sustitución de cada dependencia de un modelo con retiro anunciado. Es una definición editorial para orientar el trabajo, no una clasificación creada por el proveedor. Sin responsable, la fila queda abierta. Asígnala o escálala.

En la propia Claude API, Anthropic indica exportar los datos de Usage y analizar el CSV por clave y modelo. La exportación ayuda a localizar el uso de esa API, pero no demuestra que todas las aplicaciones de la empresa pasen por ella. El cruce con registros del gateway y configuraciones busca diferencias entre las fuentes; el artículo sobre observabilidad de LLM en producción detalla las señales que apoyan esa lectura.

La ventana debe cubrir la rutina.

Una recolección de 30 días no cubre automáticamente tareas mensuales, trimestrales ni llamadas directas: el equipo compara la ventana con el ciclo de cada carga y solicita confirmación al responsable. También registra el volumen y la última llamada observados, sin convertir la falta de registros en volumen cero. Un historial insuficiente, la retención vencida y el acceso directo desconocido se anotan como GAP.

El flujo exige conciliación. Las dependencias sin responsable y los accesos directos siguen la rama de excepción hasta que el equipo logre resolverlos. El diagrama no representa una interfaz de producto.

Paso 3: prioriza dependencias y define el plazo de respuesta

La prioridad combina impacto de negocio, criticidad, frecuencia, permisos y esfuerzo de cambio. Para cada dependencia, el equipo registra quién acepta el resultado, quién ejecuta la modificación, qué evidencia falta y cuándo debe tomarse la decisión. Sin responsable, escala la dependencia.

La tabla es una plantilla de registro. El NIST recomienda inventariar los sistemas de IA según los riesgos de la organización. No hay clientes ni resultados reales. El equipo usa una fila por dependencia y sustituye las instrucciones por sus propios registros, conservando la fuente de la información y la fecha de revisión.

La frecuencia no define la prioridad. Una tarea infrecuente puede concentrar una entrega que no admite repetición inmediata; por eso, el responsable debe evaluar la consecuencia de una falla, no solo el volumen de llamadas. Los permisos de acceso y el esfuerzo de adaptación también entran en la decisión: si el equipo no puede probar el sustituto a tiempo, debe escalar esa restricción antes de aprobar el cambio.

El plazo de decisión antecede al retiro para permitir correcciones y una nueva validación. El equipo define el margen según la carga y registra quién recibe el escalamiento. No hay una cifra autorizada para establecer ese margen en todas las operaciones.

Paso 4: evalúa sustitutos antes de cambiar la ruta

El sustituto sugerido por el proveedor es un candidato, no una aprobación. El equipo compara acceso contratado, modalidades, contexto, herramientas, formato de salida, parámetros, privacidad, calidad, latencia y costo mediante tareas autorizadas. Lo no verificado es GAP. Antes de decidir, registra al responsable y la forma de prueba.

En la consulta del 11/11/2026, la tabla de Anthropic indicaba claude-sonnet-5-5 como sustituto recomendado para claude-sonnet-4-5-20250929. La indicación no demuestra compatibilidad con una aplicación, precio contratado ni disponibilidad en la plataforma elegida. La documentación cambia. Confirma los datos antes de publicar y de migrar.

El responsable de la carga aprueba los criterios antes de la comparación, incluidos el formato esperado, el contenido obligatorio, los límites de latencia y el tratamiento de respuestas inadecuadas. Ingeniería ejecuta los mismos casos reales autorizados y casos límite relevantes en los candidatos y, cuando está disponible, en el modelo anterior, registra condiciones, entradas y resultados conforme a las reglas de seguridad de la organización y compara los resultados con los criterios aprobados. Los datos sensibles no necesitan aparecer en el informe para que la decisión sea auditable.

La compatibilidad de la interfaz merece una prueba separada. La documentación de Anthropic indica que los parámetros de la API pueden descontinuarse de forma independiente de los modelos. Por eso, el equipo verifica los parámetros de la ruta contratada y corrige incompatibilidades antes de aumentar el tráfico. Que se acepte el nombre del modelo no demuestra que la respuesta cumpla la tarea.

Paso 5: migra por etapas y prepara un retorno seguro

La migración comienza después de confirmar acceso, presupuesto y criterios de aceptación. El equipo revisa la interfaz y los parámetros, envía una muestra autorizada a la nueva ruta y observa los resultados antes de aprobar aumentos graduales. Este control es una propuesta de ingeniería. No se presupone en Router.

El cambio de ruta debe tener un responsable identificado, una forma de detener el avance y un registro de las condiciones que permiten continuar. El equipo observa errores, latencia, consumo y calidad en la muestra y compara los resultados con los límites aprobados. Si falla un criterio, suspende la ampliación e investiga antes de enviar más tráfico.

El retorno depende del calendario. Mientras el modelo anterior siga disponible, el equipo puede mantener un plan para volver a él, siempre que esa ruta siga autorizada y el plazo permita utilizarla. Después del retiro, no debe prometerse el retorno al modelo retirado. La alternativa es otra ruta previamente probada o la interrupción con el procedimiento definido por el responsable de la operación.

El fallback complementa la protección. La alternativa debe servir a la carga. El fallback no identifica a todos los consumidores ni sustituye la aceptación. Aunque la alternativa atienda llamadas, el equipo debe eliminar de la configuración de la ruta la dependencia del modelo que tiene fecha de cierre y verificar que el cambio se haya aplicado.

¿Cómo verificar que la migración concluyó?

La conclusión de la migración de modelos de IA exige conciliar llamadas recientes por aplicación y clave, cubrir la periodicidad de las cargas y confirmar accesos fuera del gateway. Cada responsable acepta el cambio e identifica la evidencia correspondiente. Las excepciones, las pruebas, la ventana analizada y la fecha de revisión se registran junto al estado de cada dependencia.

El cambio debe ser visible. El equipo compara el inventario original con las fuentes y busca el modelo anterior en configuraciones, código y tareas programadas. Si aparece una llamada residual, identifica al responsable y devuelve esa dependencia para su tratamiento. Un cambio anunciado en una reunión no es un cambio aplicado en la ruta.

La ventana de la métrica importa. Un agregado de 30 días puede conservar llamadas anteriores a la migración; no tiene que llegar a cero inmediatamente para que el cambio reciente haya ocurrido. En sentido inverso, cero llamadas recientes en una ventana corta no demuestra la ausencia de una tarea trimestral. Para cada carga, el equipo documenta la ventana adecuada y confirma el ciclo con su responsable.

Si una fuente no cubre el período necesario o una aplicación tiene acceso directo sin registros conciliados, la conclusión queda condicionada a resolver ese GAP. La aceptación final reúne el cambio aplicado, la prueba aprobada y la verificación del uso residual en las fuentes y ventanas cubiertas, con las excepciones y los límites de observación documentados. Cerrar sin esas evidencias cambia el plazo del proveedor por un pendiente sin fecha.

¿Cuánto cuesta migrar bajo presión?

La estimación reúne el esfuerzo medido por función, el consumo incremental medido y otros costos comprobados. Incluye inventario, adaptación, validación, pruebas de aceptación, observabilidad y revisión de seguridad, además del acceso al sustituto y una posible operación degradada. Si falta una tarifa o una medición, el valor permanece como GAP.

La fórmula de trabajo es: costo estimado = horas por función multiplicadas por el costo aplicable + consumo incremental multiplicado por las tarifas aplicables + otros costos comprobados, sin doble contabilización. Para aplicar la fórmula, el equipo asigna horas a las funciones involucradas, registra la base de cálculo de esas horas y separa el consumo de prueba del que habría ocurrido sin la migración. También anota los gastos adicionales que pueda comprobar. Los valores previstos y observados quedan en campos separados.

El precio del sustituto es un GAP mientras no se confirme la tarifa aplicable. El costo promedio de migración, las pérdidas evitadas y el porcentaje de tráfico afectado también son GAP en esta guía; no hay una base autorizada para completarlos con cifras de mercado. Una ruta aceptada por su calidad puede tener un consumo y un precio distintos de la anterior, pero la dirección y la magnitud de esa diferencia requieren medir la carga.

El estudio sobre costo por tarea trata otro tema. Compara costos. En la migración, antes de hacer la cuenta, la pregunta es si el candidato cumple la tarea y si el equipo puede cambiar la ruta antes del plazo. Sin esos dos registros, una tarifa menor no resuelve el costo de la dependencia que sigue activa.

¿Qué errores impiden la continuidad?

Para preservar la continuidad de la producción de IA, el equipo debe corregir dependencias sin responsable, fuentes que dejan de registrar llamadas y sustitutos aceptados sin pruebas. La respuesta consiste en asociar cada síntoma con una verificación y una acción, con plazo de resolución y escalamiento a la persona responsable.

La tabla no cierra la investigación. Si el historial está incompleto, el equipo registra el límite de la fuente y busca confirmación en otra evidencia; si el sustituto falla en calidad, precio o latencia, el cambio no recibe aceptación. En la guía de criterios de fallback en atención, la decisión se trata al nivel de la interacción; aquí debe seguirse hasta retirar la dependencia de cada aplicación.

Preguntas frecuentes

La descontinuación de modelos de IA exige tratar por separado el aviso, el cambio de ruta y la comprobación de que las aplicaciones dejaron de depender del modelo. Las respuestas delimitan lo que afirma la política citada y lo que todavía requiere pruebas y confirmación del equipo responsable.

¿Qué es la descontinuación de un modelo de IA?

En la política de Anthropic citada, es la fase en la que el modelo todavía funciona, pero deja de recomendarse y recibe una fecha de retiro. La consecuencia varía según la plataforma. En la documentación de Anthropic, las solicitudes a modelos retirados fallan.

¿Cómo identificar quién todavía usa un modelo?

El equipo cruza registros, exportaciones del proveedor y configuraciones de aplicaciones para relacionar cada llamada observada con un identificador seguro y un responsable; las claves compartidas y los alias requieren conciliación adicional. Incluye accesos directos y tareas infrecuentes. Cubre el ciclo completo de la carga, desde su entrada en producción hasta el último flujo estacional, y registra la brecha cuando falte cobertura.

¿El sustituto recomendado es compatible?

La recomendación señala un candidato. No garantiza equivalencia. El responsable debe confirmar el acceso contratado y probar formato de salida, parámetros, calidad, privacidad, latencia y costo en su propia carga. Sin medición, registra GAP. El equipo necesita evidencia antes de decidir.

¿El fallback resuelve una descontinuación?

El fallback puede proteger la ruta cuando falla el modelo, siempre que exista una alternativa configurada y apta para la carga. No sustituye el inventario, la prueba del sustituto ni la confirmación de que se retiró cada dependencia. El retorno tiene un límite. Deja de ser una opción cuando la plataforma utilizada por la aplicación retira el modelo anterior.

¿Cuándo debe cerrarse la migración?

El cierre llega después de conciliar las fuentes, verificar una ventana adecuada a la frecuencia de cada carga y obtener la aceptación de los responsables. Registra excepciones, pruebas y revisión. La ausencia de llamadas en una ventana corta, por sí sola, no demuestra la ausencia de dependencias.

Referencias y lecturas complementarias

La documentación oficial de Anthropic respalda el caso con fecha y los límites de la política atribuida al proveedor. Los artículos internos citados tratan disponibilidad, observabilidad, criterios de fallback y costo por tarea desde perspectivas distintas. Vuelve a consultarlos antes de publicar.

La página de descontinuaciones de Anthropic se consultó el 11/11/2026. La fecha depende de la plataforma. Los procedimientos de inventario y aceptación de esta guía son recomendaciones editoriales para el equipo responsable, no una descripción de herramientas específicas del proveedor ni una promesa de compatibilidad.

¿Cuál es el siguiente paso para el equipo?

El equipo debe iniciar el inventario por la ruta contratada y asignar un responsable a cada dependencia antes de elegir el orden de las pruebas. El registro debe sobrevivir al cambio de modelo: conserva la decisión, la fuente de la fecha y la evidencia utilizada para cerrar la migración.

Nexforce Router es un gateway de modelos con reglas de enrutamiento por clave, límites de gasto, registros, métricas, trazabilidad, alertas y paneles, además de fallback de modelo configurable y failover de proveedor. Estas funciones apoyan el seguimiento de las llamadas que pasan por Router. Los accesos directos necesitan otra verificación. Las funciones no aceptan el cambio en nombre del responsable. El equipo sigue a cargo de probar sustitutos, confirmar responsables y retirar las dependencias antes de la fecha aplicable.