Reasoning Drift en la IA: cómo un modelo se degrada mientras el servicio sigue funcionando

El reasoning drift como problema operativo oculto

En Reddit ha estallado un debate sobre Claude: quejas por lentitud, peor calidad del código, pérdida de coherencia, respuestas a medias, rechazos extraños. El servicio, formalmente, sigue funcionando: las respuestas llegan, la suscripción está activa, la interfaz no se cae. La sensación generalizada es que el modelo se rinde antes, mantiene peor el contexto y entrega cada vez más soluciones incompletas.

Esa sensación se vio reforzada por una señal más seria: apareció en GitHub un issue detallado sobre Claude Code que describía una degradación de calidad, vinculado a Stella Laurenzo, responsable del grupo de IA de AMD. Pero la pregunta clave no es si Claude se degradó realmente. La pregunta clave es: ¿existe alguna garantía que proteja a los usuarios cuando un modelo de IA comercial sigue funcionando formalmente pero la calidad de sus resultados cae? Para las empresas que han incorporado la IA a procesos críticos para su negocio, esto es una amenaza real.

Tres fenómenos distintos bajo una misma etiqueta

La frase "el modelo ha empeorado" refleja bien la frustración, pero ayuda poco a entender qué está pasando. Bajo ella se mezclan, como mínimo, tres escenarios:

• Un empeoramiento real en la calidad de las soluciones: el modelo realmente resuelve peor las tareas • Un cambio en el formato de respuesta: el modelo responde más corto o más seco, aunque la eficacia pueda seguir siendo la misma • Un aumento de la imprevisibilidad: el nivel medio se mantiene, pero los resultados varían más de una consulta a otra

Este artículo se centra sobre todo en el primer escenario: el reasoning drift, una situación en la que el modelo, con el tiempo, mantiene peor el hilo de una solución, se desvía del plan, deja de respetar condiciones establecidas, pierde el rumbo en sesiones largas y da respuestas que suenan convincentes pero no llevan la tarea a buen término. Esto se nota especialmente en tareas largas, de varios pasos, que exigen mucho contexto.

Cerca del reasoning drift, pero de naturaleza distinta, está el safety drift: el modelo no razona necesariamente peor, sino que se vuelve más cauteloso y rechaza incluso escenarios perfectamente aceptables. Son casos diferentes, aunque el usuario los confunda con facilidad.

Cómo se ve esto en condiciones reales

Uno de los síntomas más molestos son las respuestas a medias: contestaciones que suenan coherentes pero que, en esencia, no resuelven la tarea planteada:

• El modelo propone un enfoque pero no lo lleva hasta un resultado funcional • Responde solo a un aspecto de una pregunta compleja • Empieza a escribir código pero se corta mucho antes de terminar la función • Olvida su propio plan al cabo de un rato y se salta pasos clave

En discusiones reales, los usuarios cuentan casos concretos: código que se corta en mitad de una función, un simple ajuste de formulario en el frontend que antes llevaba minutos y ahora se alarga veinte. El modelo puede completar 2 de 7 puntos de una tarea o directamente empezar a alucinar. Un ejemplo revelador: un usuario gastó más de 50.000 tokens solo para devolver al modelo a un plan que ya estaba acordado.

El problema es que las métricas de monitorización habituales (latencia de respuesta, tasa de fallos, disponibilidad) detectan bien las caídas del servicio, pero captan mal la situación en la que el servicio funciona, pero la calidad del resultado se hunde en tareas críticas.

La paradoja: qué estás comprando en realidad

Si pago por acceder a un modelo potente, su funcionamiento debería permanecer estable. Pero esa expectativa no coincide con la realidad de los servicios de IA. Una suscripción no es el acceso a una versión fija de un algoritmo. Es el acceso a un servicio externo en el que cambian constantemente:

• La distribución de carga: cómo el sistema reparte las peticiones entre servidores • Los recursos asignados: cuánta potencia de cálculo se destina a procesar cada petición • El sistema de prompts: qué datos e instrucciones influyen en la respuesta del modelo antes de iniciarse el diálogo • El tratamiento de textos largos: cómo gestiona el sistema los mensajes extensos • Los parámetros de generación: la variabilidad de las respuestas ("temperatura") y el grado de esfuerzo aplicado • El rendimiento bajo carga: si la plataforma resiste los picos de demanda

Un modelo con el mismo nombre puede ser, en la práctica, un sistema completamente distinto según su comportamiento real. El usuario a menudo no sabe —ni puede saber— si está recibiendo la misma configuración que tenía hace una semana.

Aquí hay un matiz poco evidente: un proveedor puede lanzar una actualización que mejore el modelo para la mayoría, reduzca costes y haga el comportamiento más seguro, y al mismo tiempo empeore la calidad en una clase de tareas estrecha pero crítica para un cliente concreto. El proveedor optimiza velocidad, coste, seguridad y calidad media. Una mejora en unas métricas puede venir acompañada perfectamente de un empeoramiento en la clase de tareas que te importa a ti. La paradoja: puede no haber una caída global de calidad del modelo, pero para una empresa concreta el panorama es otro: su flujo de trabajo se desmorona.

Por qué esto duele más en el B2B

Para un usuario particular, una caída de rendimiento es una molestia incómoda. Para una empresa que ha integrado la IA en su operativa, se convierte en un problema operativo. Un escenario típico: un analista o desarrollador se apoya habitualmente en la IA para tareas largas y costosas en tiempo. Mientras el modelo funciona de forma estable, puede asumir la carga de trabajo. Pero si la calidad empieza a caer poco a poco, crece no solo el número de reintentos, sino también el volumen de revisión manual, correcciones y vuelta a pasos que ya se habían acordado.

El problema es que esto rara vez se ve como una avería evidente. Es fácil atribuir la lentitud a la complejidad de la tarea, a un encargo poco claro o a un mal día. La degradación de la calidad del razonamiento puede traducirse no en un fallo obvio, sino en un aumento oculto de los costes y de los plazos del proyecto, pese a que el servicio siga funcionando formalmente.

Lo que el mercado promete y lo que no promete

Los proveedores (OpenAI, Anthropic, Google) han trabajado bien:

• Los procedimientos de retirada de modelos y el fin del soporte • El versionado y las instantáneas de estado, con una designación clara de versiones y el uso de alias • La descripción de cambios en cada lanzamiento y las etapas del ciclo de vida • Los niveles de servicio (SLA) con descripción de garantías de disponibilidad • El soporte a usuarios y las recomendaciones para migraciones

Sin embargo, apenas existen normas para:

• La estabilidad de la calidad en escenarios críticos: no hay compromisos sobre clases de tareas específicas de cada cliente • La estabilidad del nivel de razonamiento: no hay garantías sobre cadenas lógicas de varios pasos • La comunicación de cambios de calidad significativos que no lleguen a romper la API • Los mecanismos para demostrar regresiones ocultas: cómo documentar y verificar la degradación • Las compensaciones a clientes cuando la interfaz está disponible pero la eficacia cae

Una de las razones de la ausencia de estándares es que no existe un enfoque unificado para medir la calidad en tareas reales, especialmente en aquellas donde importan los razonamientos largos, la completitud de la respuesta y la robustez. Los proveedores equilibran calidad, velocidad, coste y seguridad. Para el usuario, esto significa una sola cosa: está mal protegido frente a una regresión de calidad silenciosa.

Una señal indirecta relevante: según el Foundation Model Transparency Index de Stanford HAI para 2025, la transparencia en la industria de la IA está disminuyendo. Esto no habla directamente de la degradación del razonamiento, pero explica por qué, de momento, no conviene esperar transparencia en este tema concreto.

Conclusión: existe una protección fragmentaria, pero exige un esfuerzo considerable por parte del propio cliente: establecer sus propios procedimientos de control, reforzar su infraestructura y mantener una relación activa con el proveedor. Quien confía en un servicio de IA externo sin ninguna red de seguridad corre el riesgo de topar con una caída de rendimiento oculta, pero muy real.