Las demos de IA son fáciles. La IA en producción es otro problema completamente distinto.
Hace unas semanas, una de nuestras funcionalidades de generación de vídeo estuvo caída en producción. No degradada: caída. Fallaban todas las peticiones.
Ningún error en los dashboards. Ninguna alerta. Ningún pico de latencia. Un proveedor se había quedado sin crédito, y el fallo caía por un camino que, visto desde fuera, era indistinguible de una tarde tranquila.
Nos enteramos porque lo preguntó un cliente.
Ese incidente es el mejor resumen que tengo de los últimos dos años construyendo un producto de vídeo con IA. No porque fuera lo peor que nos ha pasado, sino por cómo falló.
El modo de fallo del que nadie te avisa
En software clásico, los fallos gritan. Un 500. Una excepción. Un stack trace con su número de línea. Tu trabajo es leerlo.
En sistemas de IA, el fallo característico es silencioso y plausible.
El sistema devuelve algo. El usuario recibe un vídeo. El pipeline reporta éxito. Y el producto sigue roto — o cuesta cuatro veces más, o es apreciablemente peor que la semana pasada, y nada en tu stack de observabilidad tiene una opinión al respecto.
Una demo no puede fallar así. En una demo tú eres el usuario, el input es limpio, hay exactamente una petición, estás mirando el resultado directamente y la factura la pagas tú. En producción, las cinco condiciones son falsas.
Estas son cinco formas en que esa diferencia me ha costado dinero, usuarios y fines de semana.
1. Tu sistema no escala a la capacidad de tu cola. Escala a la de su cuello de botella más lento.
Nuestras colas estaban configuradas para despachar mil trabajos en paralelo. Número impresionante. Número irrelevante.
La concurrencia real de extremo a extremo era de unos diez, fijada por un único worker de composición de vídeo haciendo el encoding pesado. Todo lo que había aguas arriba era teatro de escalabilidad: el trabajo avanzaba rapidísimo hasta el punto exacto en que se amontonaba contra el único componente que no podía ir más deprisa.
El número que gobierna tu sistema no está en la configuración de tu cola. Está en tu componente más caro. Hasta que no has medido ese, no conoces tu capacidad: conoces tu ambición.
2. Los reintentos también mienten.
Teníamos una cadena de fallback entre proveedores de vídeo: prueba el bueno, cae al siguiente, cae al siguiente. El presupuesto total de reintentos sumaba unos 1.500 segundos.
El contenedor que lo ejecutaba tenía un timeout de 600.
Así que el sistema reportaba diligentemente ALL_FALLBACKS_EXHAUSTED en trabajos donde al tercer proveedor no se le había llegado a llamar nunca. Dedicamos tiempo real a depurar la calidad de un proveedor basándonos en un mensaje de error que describía un mundo que no había ocurrido.
Un presupuesto de reintentos que no cabe dentro de tu timeout no es resiliencia. Es una fábrica de mensajes de error falsos. Y un error falso es peor que ningún error, porque te manda con total confianza en la dirección equivocada.
3. Vas a culpar al modelo. Casi siempre eres tú.
Durante semanas atribuimos un defecto visual en el vídeo generado al modelo del proveedor. Era un parámetro que sencillamente nunca enviábamos.
Su hermano gemelo: un flag de FFmpeg (-shortest) que, en un camino concreto de composición, recortaba el vídeo a la duración de la música de fondo en lugar de al revés. Output técnicamente válido. Producto comercialmente inservible. Cero errores en ninguna parte.
«El modelo es malo» es la hipótesis más cómoda que tiene disponible un equipo de ingeniería, y la que menos veces se comprueba. Antes de cambiar de proveedor, demuestra que estás llamando bien al actual. Esa única disciplina nos ha ahorrado más dinero que cualquier mejora de modelo.
4. La degradación silenciosa es peor que una caída.
Cuando nuestro proveedor de vídeo premium da timeout, el sistema cae a un camino más barato: un zoom estático en lugar de movimiento generado de verdad.
Sin error. Sin alerta. Sin trabajo fallido. El cliente simplemente recibe un producto peor que el que ha pagado, decide que la herramienta es mediocre y no vuelve.
Una caída es ruidosa y la arreglas en una hora. Una bajada de calidad es invisible y te la comes durante un trimestre.
Si tienes un camino de fallback, necesitas una métrica sobre la tasa de ese fallback, y un umbral encima, tratado con la misma seriedad que una tasa de error. Un fallback sin métrica no es una red de seguridad. Es una fuga.
5. La observabilidad de IA no es la observabilidad de siempre.
Tres cosas en las que me equivoqué.
La primera: durante mucho tiempo, el registro de qué proveedor y qué modelo habían producido cada pieza vivía solo en logs de aplicación, con 30 días de retención. El día 31, la pregunta «¿qué modelo generó este vídeo?» quedaba sin respuesta para siempre. Para un producto cuyo valor entero son artefactos generados, eso no es una carencia de logging: es amnesia sobre tu propio inventario.
La segunda: nuestras métricas etiquetaban a un proveedor con el nombre de otro. Todos los gráficos de coste y latencia construidos encima estaban atribuyendo trabajo al sistema equivocado. Los dashboards estaban verdes, precisos, y describiendo otra cosa.
La tercera: el incidente con el que abrí. Nada, en ningún sitio, vigilaba si un proveedor seguía pudiendo aceptar nuestras peticiones.
La observabilidad tradicional responde: ¿está arriba, va rápido, está dando errores? La observabilidad de IA tiene que responder: qué modelo, con qué parámetros, a qué coste unitario, produciendo qué calidad — y reconstruible meses después, para un output concreto. Casi nadie construye eso el primer día. Yo tampoco.
Y la que decide si tienes un negocio
El coste.
Una vez cambiamos a un modelo que parecía funcionalmente equivalente y vimos subir la factura, porque generaba a una resolución que nunca pedimos y nunca necesitamos.
En una demo, el coste unitario es invisible. En producción, el coste unitario es tu margen bruto. Si no puedes decir cuánto te cuesta servir una acción concreta de un cliente — no de media a lo largo del mes, sino esa acción — no tienes un modelo de precios. Tienes una esperanza.
De qué voy a escribir aquí
Todo lo anterior pasó después de que la demo funcionara.
Ese es el territorio que quiero ocupar: no cómo deberían construirse estos sistemas, sino qué se rompe de verdad cuando llegan usuarios reales, concurrencia real y facturas reales. Un incidente real por entrada: qué pasó, qué creíamos, qué era en realidad, qué cambiamos.
Postmortems, no thought leadership.
No escribo sobre cómo debería hacerse esto. Escribo sobre lo que me ha costado: dinero, usuarios y fines de semana.
Si tienes IA en producción, me interesa de verdad tu peor fallo silencioso. Son los que merece la pena intercambiar.