Pensamiento de Sistemas para Ingenieros de IA
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.
Pensamiento de Sistemas para Ingenieros de IA
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, los stakeholders 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 features, 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 Perspectiva de Ingeniería de Hardware
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.
Las Cinco Propiedades de un Sistema Endurecido
Cinco propiedades que separan software frágil de infraestructura robusta:
1. Redundancia. Sin punto único de falla. Si toda tu feature 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 un feature 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 feature 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 feature. Un sistema sin conciencia de costos es un sistema esperando que finanzas lo apague.
El Cambio Mental
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.
Checklist: Pensamiento de Sistemas Antes de Lanzar
Preguntas que hago antes de que cualquier feature de IA llegue a producción:
Redundancia
- ¿Qué pasa si tu proveedor principal de LLM cae por cuatro horas?
- ¿Tienes un fallback cacheado o estático para tus rutas de usuario críticas?
- ¿Puedes cambiar de proveedor sin redesplegar?
Estados de Falla
- ¿Puedes nombrar cada modo de falla de cada dependencia externa?
- ¿Cada modo de falla tiene una respuesta documentada y probada?
Observabilidad
- ¿Estás registrando latencia, conteo de tokens y tasa de error por request?
- ¿Tienes alertas por anomalías de costo, no solo errores?
Degradación Elegante
- Si el componente de IA falla, ¿el usuario aún obtiene valor del feature?
- ¿Tu ruta de degradación está probada en CI o solo existe en un documento?
Conciencia de Costos
- ¿Cuál es tu costo por request a 10x tu tráfico actual?
- ¿Tienes un kill switch si los costos se disparan más allá del presupuesto?
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.