Cuando las empresas trasladan sus proyectos de inteligencia artificial (IA) desde la fase piloto hasta entornos de producción, la entrega de datos se convierte en un factor crítico que determina la escalabilidad y fiabilidad de estos sistemas. Aunque las arquitecturas directas punto a punto que conectan almacenamiento y computación funcionan bien en entornos de prueba, en producción suelen fallar bajo tráfico sostenido y concurrente. Esto provoca interrupciones en las cadenas de inferencia, retrasos en sistemas basados en recuperación aumentada de información (RAG), GPUs infrautilizadas y violaciones de niveles de servicio (SLA), todo lo cual tiene consecuencias directas para la empresa.
Según Hunter Smit, gerente sénior de marketing de producto en F5, «las organizaciones logran operacionalizar la IA exitosamente cuando su infraestructura está diseñada para soportar fallos reales, no solo condiciones controladas».
El tráfico real desenmascara la fragilidad arquitectónica
En un piloto, una transferencia detenida supone una mera molestia; en producción, esa misma parada es una interrupción que alguien debe resolver. A menudo, la arquitectura subyacente es la misma: el cliente conectado directamente al almacenamiento. Bajo tráfico concurrente y sostenido, esta conexión directa se vuelve frágil, ya que si un nodo falla o hay un pico de tráfico, el sistema carece de mecanismos para responder adecuadamente. Esto provoca reintentos, timeouts y un efecto cascada que bloquea toda la cadena justo cuando el negocio depende de los resultados. 
Paul Pindell, arquitecto principal de soluciones en F5, señala que «las arquitecturas punto a punto donde el cliente S3 se conecta directamente al almacenamiento S3 no son resilientes. Si un nodo de almacenamiento falla, todo el tráfico se degrada e incluso el clúster puede caer completamente».
El problema radica en que los flujos de trabajo de IA, incluyendo la inferencia basada en RAG y la IA agentiva, están tratando cada vez más al almacenamiento S3 como un elemento fundamental en el clúster de IA. Sin embargo, la conectividad de red diseñada entre almacenamiento y clúster no está preparada para el movimiento continuo y de alto rendimiento de datos necesario para mantener las GPUs operando de manera óptima.
Consecuencias reales de pipelines detenidos y GPUs infrautilizadas
Tanu Mutreja, directora senior de gestión de producto en F5, explica que «los líderes empresariales suelen enfocarse en la utilización de GPUs como métrica principal, pero lo que diferencia a la IA de cargas tradicionales es que la infraestructura influye constantemente en esos resultados a cada interacción».
Por ejemplo, cuando los pipelines de inferencia se paralizan, no solo se rompe un SLA, sino que también se perjudica la experiencia del cliente. Retrasos en los sistemas RAG hacen que los modelos pierdan acceso a contexto relevante y actualizado, derivando en respuestas inexactas, obsoletas o con alucinaciones, lo que genera riesgos operativos, regulatorios y de reputación. A la vez, los problemas de infraestructura que originan estas situaciones aumentan los costes al dejar GPUs caras inactivas o con baja utilización.
Mutreja añade que «las GPUs infrautilizadas son señal de ineficiencias que elevan costos y limitan escalabilidad y rapidez. La pregunta que deben hacerse los líderes es si la infraestructura de IA ofrece siempre experiencias de alta calidad, fiables y reguladas a un coste unitario sostenible».
Crear una capa de entrega de datos preparada para producción
F5 aborda la entrega de datos como una capa fundamental de la infraestructura, en lugar de asumir que la ruta de red funcionará sin más. Mientras que la entrega de aplicaciones optimiza el flujo de peticiones entre usuarios y aplicaciones, la entrega de datos se centra en optimizar el flujo entre almacenamiento, redes y computación, incluyendo IA.
Esto implica construir tres características esenciales:
- Observabilidad: visibilidad en tiempo real sobre latencia, rendimiento y estado del flujo de datos.
- Programabilidad: control basado en políticas para gestionar dinámicamente rutas, optimizar tráfico, controlar tasas y automatizar conmutaciones por fallo.
- Conciencia de fallos: capacidad para resistir redes degradadas, limitación en almacenamiento y cortes de servicio.
La arquitectura desarrollada por F5 y Dell ObjectScale ubica el dispositivo BIG-IP entre ObjectScale y la computación de IA como un punto de control programable en el borde de almacenamiento. Pindell comenta que en ocasiones una mala configuración en la capa de computación AI puede saturar involuntariamente la infraestructura S3, causando caídas del sistema para toda la organización.
Colocar BIG-IP como controlador de entrega entre almacenamiento y computación protege el almacenamiento con QoS, límites de tasa y conexiones, manteniéndolo resiliente durante cargas elevadas. Ensayos validados por SecureIQLab confirmaron que estas protecciones no sacrifican el rendimiento de throughput, algo clave para la arquitectura.
“Mantener e incluso mejorar el throughput es indispensable”, explica Pindell, “ya que permite añadir resiliencia y seguridad sin perder rendimiento.”
Desafíos añadidos en entornos híbridos y multicloud para IA
Las implementaciones de IA en entornos híbridos multicloud enfrentan una mayor complejidad en la entrega de datos debido a la heterogeneidad de políticas, controles de seguridad, sistemas de identidad, gobernanza y visibilidad fragmentada, además de límites de fallo distintos.
El manejo programable del tráfico junto con la observabilidad permiten superar esta complejidad coordinando una visión unificada de la salud del sistema en aplicaciones, redes e infraestructura, incluso en entornos dispares. Utilizando esta información, el tráfico puede ser dirigido y balanceado inteligentemente, y la conmutación por fallo aplicada en tiempo real, creando un sistema de retroalimentación cerrado que garantiza políticas uniformes, mayor resiliencia y entrega de datos de alta calidad en cualquier ubicación de usuarios, datos o aplicaciones.
De pilotos eternos a IA en producción: la diferencia está en la ingeniería
Según Hunter Smit, las organizaciones que avanzan realmente hacia producción aplican una disciplina de ingeniería específica: diseñar pensando en que el fallo es la normalidad, no la excepción.
“Asumen que ocurrirán latencias, congestiones y fallos parciales, y por ello construyen rutas de datos observables y conscientes de fallos capaces de absorber esos incidentes, aplicando mitigaciones explícitas para cada situación degradada, en lugar de confiar en que la red resistirá”, afirma.
En cambio, los equipos atrapados en pilotos eternos siguen buscando resultados perfectos en laboratorio y solo descubren la brecha en producción, donde el problema no radica en la calidad del modelo o la cantidad de GPUs, sino en que la capa de entrega de datos no ha sido diseñada con la misma rigurosidad que el cómputo.
Pindell concluye: “Es fundamental entender que una red real se comporta muy distinto a una optimizada en laboratorio, y tener un plan de mitigación para los fallos y cuellos de botella que aparecerán cuando todo esté en producción.”
