Reparar o reconstruir: Cinco señales de que un sistema de IA ha cumplido su ciclo

El sistema AI casi nunca muere de una manera que obligue a tomar una decisión

Sigue respondiendo, generando puntuaciones y produciendo un archivo cada mañana. Mientras tanto, el equipo encuentra formas de evitarlo, las solicitudes de cambio se acumulan y el gasto anual crece sin que nadie decida aumentarlo. El final de vida llega como un aumento lento en el coste de mantenerlo, un tipo de gasto que nunca aparece en la agenda.

Por lo tanto, la decisión se pospone. La reconstrucción suena cara y disruptiva; continuar parece gratuita. No lo es, y la tarea del líder aquí es notar el momento en que los costes de mantenimiento superan a la sustitución.

Las cinco señales

Estas son las que se mantienen constantes a través de las industrias y tipos de sistemas. Cualquiera por sí sola es una señal para examinar más de cerca. Tres juntas significan que la decisión ya ha sido tomada para ti.

Los cambios pequeños dejan de ser pequeños. Una regla de precios que tomó dos días ajustarse en el primer año ahora tarda tres semanas y afecta a cuatro cosas más. El sistema ha acumulado suficientes casos especiales que nadie puede predecir el alcance de un cambio.
Las soluciones alternativas se han convertido en el proceso. La gente exporta la salida y la corrige en una hoja de cálculo antes de que alguien la use. Ahora esa hoja de cálculo tiene un propietario, una convención de nomenclatura y una copia de seguridad. El sistema real es la solución alternativa; el oficial es una fuente de datos.
No puedes responder preguntas básicas sobre él. ¿Por qué se rechazó a este cliente en marzo? ¿Qué versión estaba en funcionamiento cuando los números cambiaron? Si nadie puede responder sin una semana de investigación, estás asumiendo riesgos de personalización y reputación que no has cuantificado.
El conocimiento vive en una o dos personas. Cada cambio espera a la misma persona. No están ocultando nada; simplemente son la única copia sobreviviente de las decisiones de diseño. Esto es un riesgo de personalización disfrazado de técnico.
La restricción ha cambiado. El sistema se construyó alrededor de una limitación que ya no existe —un contexto de ventana, un techo de latencia, un precio por llamada, una capacidad que requería tres componentes y ahora solo necesita uno. Gran parte de lo que mantienes es andamiaje para un problema que desapareció.

Lo que no es una señal

Una sola mala temporada de calidad de salida suele ser un problema de datos, no de diseño. El lanzamiento de un nuevo modelo no es motivo para reconstruir nada; si tu sistema está bien estructurado, cambiar el modelo es un cambio de configuración y deberías probar si funciona. Un incidente ruidoso tampoco lo es —los incidentes se concentran en sistemas visibles, no en los frágiles.

La distinción importante es entre un sistema que funciona mal y uno que se ha vuelto caro de cambiar. El primero es solucionable. El segundo es un veredicto estructural, y ninguna cantidad de parcheo lo revierte.

Precia el mantenimiento, no solo la reconstrucción

Las propuestas de reconstrucción pierden porque solo una parte del balance obtiene un número. Asigna una cifra a la otra parte antes de tomar una decisión.

Suma lo que el sistema actual consumió en los últimos doce meses: horas de ingeniería en mantenimiento e incidentes, la factura del proveedor y del cómputo, las horas que la gente dedica a correcciones manuales a continuación, y el valor de los cambios que la empresa solicitó y no obtuvo. Este último elemento suele ser el más grande y casi nunca se cuenta. Luego mira los mismos doce meses dos años atrás. Si la línea está subiendo mientras la salida es plana, tienes tu respuesta, y la tienes en la única moneda con la que una junta directiva argumenta.

Reconstruye por rebanadas, conserva los datos

La reconstrucción no significa un programa de dos años con una fecha de cambio. Los sistemas que se reemplazan bien son reemplazados una capacidad a la vez: levanta la nueva ruta para una rebanada estrecha del tráfico, ejecútala junto al viejo sistema, compara las salidas en casos reales, mueve la rebanada, repite. El viejo sistema permanece en funcionamiento hasta que la última rebanada se vaya. En ningún momento depende la empresa de un único fin de semana de cambio.

La única cosa digna de ser llevada hacia adelante es los datos —los ejemplos etiquetados, las correcciones, el registro de lo que el sistema se equivocó y cómo la gente lo corrigió. Esa juicio acumulado es el activo verdaderamente valioso. El código alrededor de él es reemplazable, y en algún momento debería serlo.

La mayoría de las organizaciones esperan aproximadamente un año demasiado largo. El coste de ese año rara vez es visible, que es precisamente por qué necesita medirse. Construimos nuestra práctica alrededor de cargar esa carga por nuestros clientes, pero la medición es tuya para hacerla, y vale la pena hacerlo antes del próximo ciclo presupuestario en lugar de después.