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, sigue puntuando, sigue 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 costo de mantenerlo con vida, exactamente el tipo de costo que nunca aparece en una agenda.

Por lo tanto, la decisión se pospone. Reconstruir suena costoso y disruptivo; continuar suena gratuito. No lo es, y la tarea de un líder aquí es notar el momento en que los costos de mantenimiento superan a los de reemplazo.

Las cinco señales

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

• Los cambios pequeños dejaron de ser pequeños. Una regla de precios que tomó dos días ajustar en el primer año ahora toma tres semanas e impacta 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. Esa hoja de cálculo ahora 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 ejecutando cuando los números cambiaron? Si nadie puede responder sin una semana de investigación, estás asumiendo riesgos de personalización disfrazados como técnicos.
• El conocimiento vive en una o dos personas. Cada cambio espera en la misma persona. No están ocultando nada; simplemente son la única copia sobreviviente de las decisiones de diseño. Eso es un riesgo de personalización bajo el disfraz de un problema técnico.
• La restricción cambió. 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

Un único mal trimestre 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 no es evidencia tampoco —los incidentes se concentran alrededor de sistemas visibles, no frágiles.

La distinción que importa es entre un sistema que está funcionando mal y uno que se ha vuelto costoso de cambiar. El primero es solucionable. El segundo es un veredicto estructural, y ninguna cantidad de parcheo lo revertirá.

Precia el costo de mantener, no solo la reconstrucción

Las propuestas de reconstrucción pierden porque solo un lado del balance recibe un número. Ponle un precio al otro 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 la computación, las horas que la gente dedica a correcciones manuales hacia abajo, y el valor de los cambios que el negocio solicitó y no obtuvo. Ese ú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 se mantiene plana, tienes tu respuesta, y la tienes en la única moneda con la que una junta directiva argumenta.

Reconstruye en rebanadas, y conserva los datos

Reconstruir 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 al lado de la vieja, compara las salidas en casos reales, mueve la rebanada, repite. El viejo sistema permanece hasta que la última rebanada se vaya. En ningún momento depende el negocio 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 costo 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.