Nuestra feature de IA fue fiable durante meses y luego empezó a driftear. ¿Qué cambió?

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.

¿Por qué añadir más instrucciones al system prompt deja de funcionar?

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.

¿Cuán invasivo es el cambio arquitectónico para arreglar esto?

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.

La pregunta de las 3 de la mañana que todo CTO acaba haciéndose: "¿Por qué nuestra IA se olvida de cómo hacer su trabajo?"

body{background:#050510;color:#fff;font-family:system-ui,sans-serif;padding:2rem;max-width:720px;margin:0 auto;line-height:1.6}La pregunta de las 3 de la mañana que todo CTO acaba haciéndose: "¿Por qué nuestra IA se olvida de cómo hacer su trabajo?"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.Continue