Cuando una función 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 funciones de IA cuyo comportamiento se desvía en producción casi nunca tienen un problema de modelo. Tienen un problema de arquitectura: el modelo se convirtió en orquestador del flujo de trabajo, así que cuando la distribución de entradas se amplía, cada desviación en la interpretación se convierte en una desviación en el flujo de trabajo. La solución duradero mueve la orquestación a código tipado y mantiene el modelo sólo para las tareas en las que aporta una ventaja específica.
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 flujo de trabajo, 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.