El debate sobre Claude “Nerfing” no se trata de Claude. Se trata de lo que sucede cuando sus operaciones dependen de las decisiones de otra persona.

A principios de este año, Stella Laurenzo, Directora Senior de IA en AMD, publicó telemetría de casi 7.000 sesiones de código Claude que documentaban algo que los ingenieros habían estado sintiendo pero luchando por articular: entre enero y marzo, la profundidad de razonamiento visible parecía haber disminuido un 73%, las llamadas a la API por tarea se habían multiplicado por 80, y el modelo estaba leyendo muchos menos archivos antes de realizar ediciones. Los números se difundieron rápidamente. La interpretación se difundió aún más rápido.

Anthropic disputa el marco. La empresa dice que los cambios reflejan decisiones de producto deliberadas, incluyendo un nuevo mecanismo de pensamiento adaptativo y un cambio al esfuerzo medio como valor predeterminado. Los analistas independientes también han cuestionado partes de la metodología. El debate sigue en curso, y personas razonables no están de acuerdo en lo que realmente sucedió.

Pero aquí está la parte que importa si está ejecutando un negocio sobre estos sistemas: ya sea que esto fuera degradación o ajuste deliberado, no cambia lo que los operadores empresariales experimentaron. No podían predecirlo. No podían controlarlo. Y algunos de ellos lo sintieron en producción antes de entender qué estaba sucediendo. Esa es la historia real, y no tiene nada que ver con Anthropic específicamente.

Este es un problema de dependencia, no un problema de modelo.

Lo que estamos describiendo tiene un nombre: fragilidad del modelo. Es la condición en la que las operaciones críticas de la misión están estrechamente vinculadas al comportamiento de un solo modelo, de modo que cualquier cambio en la capa del modelo, ya sea una decisión de ajuste, un nuevo valor predeterminado, un cambio de enrutamiento impulsado por la capacidad o una deprecación silenciosa, golpea directamente al negocio, sin amortiguador y sin advertencia.

Este no es un patrón nuevo. GPT-4 pasó por una versión de esto en 2023. Claude 3.5 pasó por uno en 2024. Claude Opus está pasando por uno ahora. Volverá a suceder con el próximo modelo fronterizo y con el siguiente. No porque algún proveedor esté actuando de mala fe, sino porque optimizar un modelo fronterizo para costo, latencia y escala a volumen global es exactamente lo que los proveedores fronterizos tienen que hacer. Sus incentivos y los incentivos de una empresa que ejecuta operaciones de producción sobre ellos están relacionados. No son idénticos. Nunca lo serán.

Comenzamos Qurrent en 2023 y tenemos el conocimiento histórico para saber cómo se desarrollan los ciclos de software empresarial: una empresa invierte en IA. La demostración funciona. El piloto funciona. Luego se pone en vivo, algo cambia en la capa del modelo y, de repente, el cliente es dueño del problema. Son ellos quienes mantienen los flujos de trabajo, persiguen las regresiones, absorben la interrupción. Eso nunca me pareció un modelo sostenible para operaciones empresariales.

La versión empresarial de esta historia es operativa, no técnica.

Para los desarrolladores, la situación actual es inconveniente. Los presupuestos de tokens se queman más rápido. Las sesiones de codificación se estancan. Las pruebas de rendimiento decepcionan. Ese es un problema real, pero es recuperable.

Para las empresas que ejecutan operaciones financieras, flujos de trabajo de cumplimiento, cuentas por cobrar y pagar, y procesos de oficina trasera complejos, las apuestas son diferentes. Estos flujos de trabajo no pueden absorber una mala semana. Los errores se acumulan. El volumen se acumula. Los SLA son compromisos con clientes reales, no preferencias internas. En el momento en que un modelo comienza a funcionar mal en un proceso de alto riesgo, el daño se acumula ya sea que alguien lo haya notado o no.

Lo que hace que esto sea más difícil es que la mayoría de las empresas que intentaron adelantarse a la IA construyendo agentes internos sobre un solo modelo ahora están descubriendo lo incompleta que fue esa base. El primer agente fue la parte fácil. Lo que no se construyó fue la infraestructura circundante: marcos de evaluación que detectan el desvío de comportamiento antes de que alcance a un cliente, lógica de conmutación por error que redirige el trabajo automáticamente cuando un modelo comienza a funcionar mal, y gobernanza continua capaz de mantener el ritmo de un paisaje que cambia cada trimestre. Esas tres brechas no se mantienen manejables. Crecen en una función de ingeniería permanente que nadie presupuestó, ocupada por personas cuyo trabajo es esencialmente mantenerse al día con decisiones tomadas por proveedores sobre los que no tienen influencia.

Qué es la resiliencia en producción.

En Qurrent, construimos la fuerza laboral digital para ser agnóstica de modelo desde el principio, no como una posición de marketing sino como un requisito arquitectónico. Cada tarea se enruta al modelo con mejor rendimiento para esa tarea, evaluado continuamente. Cuando se lanza un modelo mejor, los clientes lo obtienen automáticamente. Cuando un modelo actual se degrada en un flujo de trabajo específico, la capa de orquestación redirige ese trabajo en segundos, sin intervención humana y sin que nadie se despierte a una conversación de Slack a las 2 am.

Debajo de eso, simulaciones automatizadas se ejecutan contra flujos de trabajo de producción durante todo el día, midiendo si las salidas coinciden con el comportamiento esperado. El desvío se detecta en la capa de infraestructura, antes de que el equipo de operaciones lo sienta y mucho antes de que un cliente lo haga. Y cada decisión tomada por cada trabajador digital se registra y se puede revisar, una caja de vidrio completa, porque no se puede gobernar lo que no se puede ver.

Estas no son características de lujo. Son el precio de admisión para ejecutar IA en producción a escala empresarial. La mayoría de las empresas están aprendiendo eso en medio de un ciclo de noticias, lo que es la forma costosa de descubrirlo.

La pregunta que vale la pena hacer este trimestre.

Si el modelo en el que dependen la mayoría de sus operaciones tuviera una mala semana el próximo trimestre, ¿cuántos de sus flujos de trabajo lo sentirían? ¿Cómo lo sabrían? ¿Y cuán rápido podrían redirigirlo?

Si la respuesta a la segunda pregunta es “nos enteraríamos por un cliente”, la operación no está lista para producción. Es un piloto que se ejecuta a escala, y la distinción importa más de lo que la mayoría de los líderes se dan cuenta hasta que no lo hace.

El debate actual es, de manera indirecta, útil. Cada CFO y COO que ve esto desarrollarse acaba de obtener una vista previa gratuita de cómo se ve la fragilidad del modelo bajo una carga operativa real, sin tener que pagar por ello ellos mismos. La respuesta correcta no es cambiar de modelo. Es construir operaciones que no dependan de ninguno en particular.

La tecnología seguirá cambiando. Esa es la única certeza en este mercado. Las empresas que salgan de esta década más fuertes no serán las que eligieron el modelo correcto. Serán las que cuyas operaciones nunca tuvieron que preocuparse.