El mayor riesgo en IA no es el modelo, es todo lo que lo rodea. Cómo una mentalidad de ingeniería de producción convierte demos frágiles en sistemas de producción robustos.
Celestino Salim
Senior Software Engineer | AI Systems | Product Engineering
La observabilidad tradicional fue diseñada para sistemas deterministas. Los sistemas de IA son probabilísticos -- misma entrada, distinta salida. Así es como construí monitoreo que realmente funciona para sistemas con LLM en producción.
El software es frágil. Los sistemas son robustos.
Veo el mismo patrón repetirse: un ingeniero construye un prototipo, el LLM impresiona, la demo funciona, las partes interesadas asienten, el equipo lo pasa a producción. Y entonces la API falla un jueves por la noche. El modelo alucina una cita legal. La factura mensual llega al triple de lo proyectado. El sistema no falla con gracia. Simplemente falla.
El problema nunca fue el modelo. El problema fue que nadie diseñó el sistema.
La mayoría de ingenieros de IA piensan en funcionalidades, no en sistemas. Optimizan el prompt pero ignoran el fallback. Evalúan el modelo pero nunca prueban qué pasa cuando el modelo no está disponible. Este ensayo propone una forma diferente de pensar. Una que aprendí de 8+ años construyendo software a escala, donde el uptime no es negociable y "funciona en mi máquina" no es una estrategia de despliegue.
La mejor analogía que he encontrado para sistemas de IA viene de la ingeniería de hardware, un mundo donde los componentes se sobrecalientan, las señales se degradan y las fuentes de poder fluctúan. La ingeniería de hardware enseña que cada componente en un sistema está intentando fallar. Tu trabajo como ingeniero es diseñar el sistema para que cuando las partes fallen, el todo siga funcionando.
Tres analogías tomadas del hardware que aplico todos los días:
Los reguladores de voltaje son guardrails. Un regulador toma un voltaje de entrada impredecible (ruidoso, fluctuante, con picos) y lo estabiliza en un rango de salida definido. Sin uno, los componentes posteriores se queman. Los guardrails de un LLM hacen exactamente lo mismo: toman la salida impredecible del modelo y la restringen a un rango aceptable. Ambos aceptan entrada variable, producen salida acotada y disipan el exceso. Un regulador disipa energía como calor. Un guardrail descarta contenido alucinado como tokens rechazados. Y ambos tienen un límite de diseño. Excederlo significa que la protección falla. Conocer ese límite separa la ingeniería de la improvisación.
La relación señal-ruido es la tasa de alucinación. En procesamiento de señales, el SNR mide cuánta señal útil existe respecto al ruido de fondo. En IA, la "señal" es salida factual y contextualmente relevante; el "ruido" son alucinaciones y detalles confabulados. Mejor retrieval mejora la señal. Mejores prompts filtran el ruido. Pero también puedes reducir el ruido en la fuente: en hardware usarías un filtro pasa-banda para eliminar frecuencias fuera de rango; en IA, restringes la ventana de contexto a solo los documentos más relevantes. Mismo principio, diferente medio.
Los circuit breakers son patrones de fallback. Un breaker físico se dispara cuando la corriente supera un umbral seguro. Sacrifica la disponibilidad de un circuito para proteger el edificio. Los circuit breakers de software hacen lo mismo: cuando la tasa de error de una API cruza un umbral, el breaker se activa, el sistema deja de llamar al servicio que falla y un fallback toma el relevo. El principio es simple pero fácil de olvidar: una falla sin protección puede propagar y destruir todo lo que está después. Cada dependencia externa en mis sistemas de IA tiene un circuit breaker. Cada una.
Cinco propiedades que separan software frágil de infraestructura robusta:
1. Redundancia. Sin punto único de falla. Si toda tu funcionalidad de IA depende de una sola API de un solo proveedor, no tienes un sistema, tienes una apuesta. Redundancia significa múltiples proveedores de LLM con failover automático, embeddings cacheados para las consultas más frecuentes, y una capa de retrieval que pueda caer de búsqueda semántica a búsqueda por keywords sin que el usuario vea un error.
2. Estados de falla definidos. Cada componente debe tener un modo de falla conocido y probado. No "podría crashear", sino "cuando este componente retorna un 503, el sistema responde con X." Documento estados de falla como las hojas de datos documentan límites de operación.
3. Observabilidad. No puedes arreglar lo que no puedes ver. No puedes degradar con gracia si no detectas la falla. Esto significa logging de latencia, uso de tokens y tasas de error por request. Alertas por anomalías de costo, no solo picos de errores. Capacidad de reproducir un request fallido desde los logs. La observabilidad no es una funcionalidad que agregas después. Es la base sobre la que construyes primero.
4. Degradación elegante. Cuando algo se rompe, el sistema empeora, no se quiebra. La diferencia entre "los resultados son menos precisos ahora" y "500 Internal Server Error." Cada funcionalidad de IA que construyo tiene un fallback sin IA, aunque sea una respuesta estática o una redirección a un humano.
5. Conciencia de costos. La propiedad que más ingenieros ignoran y la que más proyectos mata. Si tu costo por request se duplica a escala, tu sistema tiene un defecto de diseño. Monitoreo el costo igual que la latencia: por request, con alertas de anomalías y presupuestos claros por funcionalidad. Un sistema sin conciencia de costos es un sistema esperando que finanzas lo apague.
Tu LLM no es tu sistema. Es un componente dentro de tu sistema.
Suena obvio. No lo es. La mayor parte de la ingeniería de IA actual trata al modelo como el centro de gravedad. Todo lo demás (retrieval, caching, fallbacks, monitoreo) es secundario. El pensamiento de sistemas invierte esto. El modelo es un componente con modos de falla conocidos, igual que un transistor en un circuito. Y necesita infraestructura de soporte para funcionar de manera confiable.
El cambio que propongo es de prompt engineering a systems engineering. La habilidad más importante para un ingeniero de IA no es escribir un mejor prompt, sino diseñar un mejor sistema alrededor de ese prompt. Cuando evalúo un sistema de IA, no empiezo leyendo los prompts. Empiezo preguntando: "¿Qué pasa cuando el modelo no está disponible?" La respuesta dice más sobre la madurez del sistema que cualquier benchmark.
Preguntas que hago antes de que cualquier funcionalidad de IA llegue a producción:
Redundancia
Estados de Falla
Observabilidad
Degradación Elegante
Conciencia de Costos
Los sistemas no los construyen optimistas. Los construyen ingenieros que respetan las formas en que las cosas se rompen y diseñan en consecuencia.
El software es frágil. Los sistemas son robustos. Construye el sistema.