La mayoría de las demos de IA funcionan. La mayoría de los sistemas de IA no.
La brecha entre esas dos afirmaciones le cuesta semanas a los equipos. A veces meses. El modelo está bien. Los prompts se ven bien en el notebook. Luego llegan datos reales y el pipeline se rompe.
Esto no es un problema del modelo. Es un problema de diseño del pipeline.
La brecha entre una demo que funciona y un sistema que funciona
Una demo corre sobre inputs curados. Un sistema corre sobre todo.
En una demo, tú controlas la longitud del documento, el formato de respuesta y el timing. En producción, un usuario envía una transcripción de earnings call de 40,000 tokens a las 2 AM, tu paso de clasificación agota el tiempo de espera, y nada en el flujo posterior sabe por qué.
Los equipos pierden semanas aquí porque depuran en la dirección equivocada. Ajustan el prompt. Cambian el modelo. El problema real es que nadie diseñó para el camino de fallo.
Un sistema que funciona define qué ocurre cuando cada paso falla. Una demo que funciona no necesita hacerlo.
Tres modos de fallo específicos
1. Desbordamientos del presupuesto de tokens
Construyes un paso de resumen. Funciona en tu conjunto de pruebas — artículos con un promedio de 800 tokens. Lo pones en producción. Tres días después, un lote de archivos SEC llega al pipeline. Longitud promedio: 18,000 tokens. El costo por ejecución sube 20x. La latencia se triplica. Los pasos posteriores que esperan un resumen de 200 tokens ahora reciben 1,400 tokens y rompen sus propias ventanas de contexto.
La solución no es un mejor modelo. La solución es un budget gate antes de la llamada al LLM — un paso que mide la longitud del input, enruta documentos largos a un camino de chunking, y aplica restricciones de longitud de output de forma explícita. Lo escribes una vez. Corre silenciosamente para siempre.
2. Cascadas de timeouts
El paso A llama a un LLM. El paso B espera al paso A. El paso C espera al paso B. Configuras un timeout de 30 segundos en el paso A. Bajo carga, el proveedor del LLM tarda 35 segundos. El paso A agota el tiempo. El paso B no recibe nada y lanza un error de referencia nula. El paso C nunca corre. Tu pipeline reporta éxito porque ningún paso falló explícitamente — simplemente se detuvo.
Esto es una cascada. Ocurre porque cada paso fue diseñado de forma aislada.
La solución son contratos de fallo explícitos entre pasos. Cada paso debe manejar tres estados: éxito, fallo y sin-respuesta. Pruebas el camino de sin-respuesta antes de hacer el deploy. En un pipeline de ingesta de noticias que procesa 300 artículos por hora, un timeout no manejado puede descartar silenciosamente 40 artículos antes de que alguien lo note.
3. Drift silencioso de clasificación
Este es más lento y más difícil de detectar.
Construyes un clasificador que enruta leads entrantes por industria. Funciona bien en el mes uno. Para el mes tres, la distribución del input ha cambiado — tu equipo de ventas está apuntando a un nuevo vertical, el lenguaje en los mensajes entrantes ha cambiado, y el clasificador ahora está enrutando mal el 18% de los leads. Sin errores. Sin alertas. Solo outputs incorrectos.
El drift silencioso es peligroso porque el sistema parece saludable. Los logs están limpios. La latencia es normal. El daño se acumula en resultados de negocio, no en dashboards.
La solución es un conjunto de referencia con re-evaluación programada. Mantienes 50 ejemplos etiquetados. Corres el clasificador contra ellos de forma programada — semanal suele ser suficiente. Generas una alerta cuando la precisión cae por debajo de un umbral. Tratas al clasificador como un componente que se degrada, no como uno que permanece fijo.
Cómo se ve la corrección en la práctica
Toma un pipeline de ingesta y clasificación de noticias. Extrae artículos de 12 feeds RSS, los clasifica por tema y los enruta a consumidores posteriores.
Antes del hardening:
- Sin verificaciones de longitud de input. Un solo artículo largo detiene el lote.
- Timeouts configurados solo en la capa HTTP. Los bloqueos a nivel de LLM son invisibles.
- Precisión de clasificación verificada manualmente, una vez al lanzamiento.
Después del hardening:
- El input gate rechaza o hace chunking de artículos de más de 4,000 tokens antes de que lleguen al modelo. Las detenciones del lote caen a cero.
- Cada llamada al LLM tiene un hard timeout de 15 segundos con un fallback registrado. Los fallos en cascada se detienen.
- Un conjunto de referencia de 60 artículos corre cada domingo. Una precisión por debajo del 88% dispara una alerta en Slack. El drift se detecta en días, no en meses.
Ninguna de estas correcciones requirió un mejor modelo. Requirieron tratar el pipeline como un problema de ingeniería, no como un problema de prompting.
El patrón
Cada modo de fallo anterior comparte una causa raíz: el pipeline fue diseñado para el happy path.
Los sistemas en producción necesitan un diseño explícito para el unhappy path — desbordamientos de presupuesto, respuestas faltantes y degradación gradual. Ese trabajo de diseño no es glamoroso. No mejora una demo. Hace un sistema que corre el día 90 de la misma forma que corrió el día uno.
Lo aburrido gana.
Si estás construyendo pipelines de IA y quieres un segundo par de ojos sobre los caminos de fallo antes de hacer el deploy, Inicia una conversación →