Cuando una feature de IA que funcionaba de maravilla en la demo empieza a saltarse pasos, entrar en bucle o dar respuestas distintas a la misma pregunta un martes, el instinto es culpar al modelo. El instinto es incorrecto. La causa real y el cambio arquitectónico que lo arregla de verdad.
Las features de IA que driftean en producción casi nunca tienen un problema de modelo. Tienen un problema de arquitectura: el modelo se convirtió en orquestador del workflow, así que cuando la distribución de entradas se amplía, cada drift en entendimiento se vuelve drift en workflow. El arreglo duradero mueve la orquestación a código tipado y mantiene el modelo sólo para aquello en lo que es únicamente bueno.
En casi cada caso que auditamos, el modelo no cambió — la distribución de entradas sí. Nuevos segmentos de cliente, nuevos formatos de partner, nuevos code paths internos amplían las entradas más allá de aquello para lo que se afinó el prompt original. Cuando el modelo es además el orquestador del workflow, cada drift en entendimiento se vuelve drift en lo que el sistema hace.
Los prompts que acumulan cicatrices — añadiendo cláusulas por cada incidente pasado — terminan optimizando para casos cola a costa del centro. Hemos visto prompts crecer de cinco párrafos a cuarenta en un año, con el sistema mediblemente menos fiable al final. Más instrucciones producen más sitios por donde se filtra la atención, no más obediencia.
Menos de lo que los equipos esperan. El cambio es mover la orquestación del workflow fuera del modelo y a código tipado, manteniendo el modelo para los pasos que genuinamente se benefician del razonamiento probabilístico. Es un rediseño de dónde viven las decisiones, no una reescritura de la feature. La mayoría de los engagements mueven la arquitectura en dos a cuatro semanas.