Nuestra entrada original sobre ADC09 plantea una observación pragmática: no todas las aplicaciones encajan perfectamente en modelos de entrega estandarizados. Algunas requieren un enrutamiento personalizado, integraciones especializadas o un tratamiento específico que queda fuera de los patrones predeterminados de equilibrio de carga y seguridad. La conclusión es igualmente pragmática. Si intenta forzar todas las aplicaciones para que encajen en el mismo molde, acabará dañando la aplicación o generando una carga operativa adicional. La respuesta siempre ha sido incorporar capacidad de programación en la capa de entrega, para poder adaptarse sin tener que reescribirlo todo.
Esa premisa sigue siendo válida.
Lo que ha cambiado es que la IA ha aumentado drásticamente el número de aplicaciones que se comportan de esta manera. Lo que antes eran casos excepcionales se está convirtiendo rápidamente en la norma.
Los sistemas de IA no son estáticos. Son modulares, se adaptan al contexto y gozan de una autonomía cada vez mayor a la hora de atender las solicitudes. Esto significa que la «personalización» ya no es una característica exclusiva de unas pocas aplicaciones, sino de la propia arquitectura.
Consecuencias de los requisitos específicos de las aplicaciones de IA
Impacto en la disponibilidad
En los sistemas tradicionales, los requisitos específicos solían complicar la disponibilidad porque introducían lógica personalizada en el enrutamiento y la conmutación por error. Los patrones estándar presuponen un comportamiento predecible. Cuando una aplicación se desvía de ese comportamiento, las estrategias de disponibilidad deben adaptarse en consecuencia.
La IA desplaza el problema del enrutamiento de solicitudes a la toma de decisiones.
Una solicitud a un sistema de IA no es una simple transacción. Puede implicar seleccionar un modelo, recuperar contexto, aplicar políticas, generar una respuesta y, posiblemente, invocar servicios o herramientas adicionales. Cada uno de esos pasos puede completarse correctamente o fallar de forma independiente, y puede estar sujeto a distintas restricciones, como umbrales de latencia, límites de costes o requisitos normativos.
Esto significa que la disponibilidad ya no depende únicamente de si se puede acceder a un endpoint, sino de si el sistema puede ejecutar correctamente toda la cadena de decisiones necesaria para atender la solicitud.
Puede darse el caso de que todos los componentes de un sistema estén técnicamente operativos y, aun así, la aplicación no sea capaz de generar una respuesta. Puede que un modelo esté disponible, pero no esté autorizado para un conjunto de datos determinado. Un paso de recuperación puede devolver datos que no se puedan utilizar debido a las políticas aplicables. Un agente puede iniciar un flujo de trabajo y no poder completarlo porque una acción necesaria esté bloqueada.
Esto plantea un tipo diferente de reto en materia de disponibilidad. La conmutación por error tradicional presupone que se puede enviar la solicitud a otro lugar. En los sistemas de IA, a menudo es necesario encontrar una forma alternativa de completar la tarea. Esto requiere una toma de decisiones dinámica en la capa de entrega, no solo redundancia en la infraestructura.
Impacto en la escalabilidad
La entrada original pone de relieve la dificultad de escalar aplicaciones que dependen de integraciones a medida. Cada dependencia adicional añade complejidad, y el escalado suele requerir un esfuerzo de desarrollo adicional para gestionar esas integraciones de forma eficaz. La IA agrava esta situación porque se basa intrínsecamente en la composición.
Una aplicación basada en IA puede depender de varios modelos, bases de datos vectoriales, API y fuentes de datos externas. La combinación de estos elementos no es fija, sino que puede cambiar en función de la solicitud, el usuario o el contexto. Esta variabilidad se convierte en el factor dominante de la escalabilidad.
Escalar ya no consiste únicamente en gestionar más solicitudes por segundo, sino en gestionar más combinaciones de comportamientos en cada solicitud.
Si cada variación tiene que implementarse en el código de la aplicación, el sistema se vuelve rápidamente inmanejable. Los cambios entrañan riesgos, los despliegues se ralentizan y la aplicación acaba convirtiéndose en un mosaico de lógica condicional.
Por tanto, la misma solución utilizada para las aplicaciones tradicionales cobra aún más importancia. Esa variabilidad se traslada de la aplicación a la capa de entrega. Las decisiones de enrutamiento se amplían para incluir decisiones de orquestación. La inserción de servicios se convierte en una composición dinámica. La capa de entrega pasa a ser responsable de seleccionar la combinación adecuada de componentes para atender cada solicitud.
Sin ese cambio, la escalabilidad se derrumba bajo el peso de su propia complejidad.
Impacto en la eficiencia operativa
Los requisitos a medida siempre han aumentado la carga operativa. Cada excepción requiere mantenimiento. Cada personalización introduce otro posible punto de fallo. Con el tiempo, todo ello da lugar a un sistema más difícil de gestionar y que evoluciona con mayor lentitud. Eso es deuda operativa, y la IA acelera su acumulación.
El sistema ya no se limita a gestionar rutas predefinidas, sino que las genera. Distintas instrucciones pueden activar diferentes rutas de ejecución. Los agentes pueden encadenar acciones de formas que no se diseñaron explícitamente de antemano. Periódicamente se incorporan nuevos modelos y servicios, cada uno con sus propias características y limitaciones.
Esto genera un flujo constante de variaciones que los equipos de operaciones deben tener en cuenta.
Si la única forma de gestionar esa variación consiste en modificar el código de la aplicación o actualizar configuraciones estáticas, el sistema se vuelve frágil. Los equipos dedican su tiempo a reaccionar ante casos extremos en lugar de gestionar el sistema en su conjunto. Surgen incoherencias entre los distintos entornos y el comportamiento se desvía.
Por tanto, la eficiencia operativa depende de que se pueda centralizar el control de esa variabilidad. La capa de entrega debe actuar como una fuerza estabilizadora, absorbiendo las diferencias y aplicando políticas coherentes en un sistema que, por lo demás, es dinámico. Sin ello, la personalización se convierte rápidamente en caos.
Mejores prácticas para gestionar requisitos personalizados
La programabilidad como capacidad de primer nivel
La programabilidad sigue siendo clave para abordar requisitos específicos, ya sean de IA, tradicionales, modernos o de <inserte aquí la próxima generación>. En lugar de integrar la lógica directamente en el código de las aplicaciones, se introduce una capa programable en la ruta de entrega que puede adaptarse a distintas necesidades.
Con la IA, esto se vuelve esencial porque los sistemas de IA evolucionan rápidamente. Se introducen nuevos modelos, cambian las políticas, varían las fuentes de datos y surgen nuevos patrones de interacción. No es posible prever todo esto durante la fase de diseño ni reconstruir las aplicaciones cada vez que algo cambia.
Una capa de entrega programable permite adaptarse sobre la marcha. Puede inspeccionar las solicitudes, aplicar un enrutamiento basado en el contexto, modificar las entradas y salidas, y añadir o eliminar servicios según sea necesario. Y, lo que es más importante, puede hacerlo de forma coherente en todas las aplicaciones.
Es aquí donde la entrega de aplicaciones empieza a parecerse menos a una mera infraestructura de conexión y más a un plano de control. No se limita a gestionar el tráfico, sino que determina cómo se comporta el sistema.
La gestión del tráfico se convierte en enrutamiento de decisiones
La entrega tradicional de aplicaciones se centra en dirigir el tráfico al destino adecuado. La pregunta siempre ha sido: «¿Adónde debe dirigirse esta solicitud?». La IA transforma esa pregunta en otra con más matices: «¿Cuál es la mejor manera de atender esta solicitud?»
A veces, eso implica seleccionar entre varios modelos en función de la latencia, el coste o los requisitos de cumplimiento normativo. Otras veces, implica enriquecer la solicitud con contexto adicional antes de enviarla a un modelo. Y, en ocasiones, implica prescindir por completo de la IA y dirigir la solicitud a un servicio determinista que pueda proporcionar una respuesta más precisa o conforme con la normativa.
La decisión ya no depende únicamente de la ubicación, sino de la ejecución.
Este cambio convierte el enrutamiento en una función de nivel superior. Pasa a ser responsable de seleccionar la ruta que seguirá la solicitud entre un conjunto de capacidades posibles. También implica que la capa de entrega necesita tener visibilidad de algo más que las condiciones de la red. Debe conocer las políticas, el contexto y los resultados deseados.
Esta es una extensión natural de lo que ADC09 siempre ha defendido. Cuando las aplicaciones tienen requisitos específicos, la capa de entrega debe adaptarse. La IA simplemente eleva el nivel en el que se produce esa adaptación.
Conclusión
La programabilidad como capacidad siempre ha reconocido una verdad sencilla: las aplicaciones no son uniformes y la infraestructura debe adaptarse a sus diferencias. Esa verdad no ha cambiado.
Lo que hace la IA es aumentar tanto la frecuencia como la complejidad de esas diferencias. Los sistemas se vuelven más dinámicos, más modulares y más dependientes de las decisiones tomadas en tiempo de ejecución. La idea de una ruta de aplicación «estándar» resulta cada vez más difícil de mantener.
La respuesta es la misma de siempre, pero ahora es más urgente.
Necesita capacidad de programación en la capa de entrega. Necesita un control centralizado sobre cómo se gestionan, enrutan y atienden las solicitudes. Y necesita poder adaptarse a nuevos requisitos sin tener que reescribir las aplicaciones cada vez que algo cambia.
Porque, en una arquitectura impulsada por la IA, las soluciones a medida ya no son una excepción en torno a la cual se diseña.
Es el modelo operativo para el que se diseña.
Más información sobre los 10 principales retos de la entrega de aplicaciones a los que se enfrentan las organizaciones de todo el mundo.
Sobre el autor
Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.
Más artículos de Lori Mac VittieArtículos relacionados del blog
Las 10 principales amenazas en la entrega de aplicaciones de IA: falta de seguridad y cumplimiento normativo
La IA amplía el alcance del cumplimiento normativo: ya no se limita a proteger rutas y almacenes, sino que también abarca la gobernanza del comportamiento en tiempo de ejecución —el acceso a los modelos, el contexto de recuperación, los resultados y las acciones de los agentes—, por lo que los controles deben situarse más cerca de la inferencia.
¿Qué es el Top 10 de entrega de aplicaciones?
F5 tiene como objetivo ayudar a las organizaciones a afrontar los retos relacionados con la entrega y la protección de aplicaciones, API e IA generativa mediante la lista de los 10 principales desafíos de la entrega de aplicaciones.
Las 10 principales amenazas para la entrega de aplicaciones de IA: políticas de entrega incompatibles
Las discrepancias entre políticas se convierten en generadores de interrupciones de la IA: la falta de coherencia en la conmutación por error, los tiempos de espera, los límites y los controles de seguridad provoca fallos leves, resultados parciales y resultados distintos según el endpoint.
Los 10 principales riesgos en la entrega de aplicaciones de IA: incapacidad para gestionar la latencia
La IA convierte la latencia en un problema de confianza, no solo de rendimiento: las respuestas lentas del «asistente» se perciben como vacilación o fallo, y los prompts y las respuestas con muchos tokens aumentan la carga de trabajo incluso en sistemas que funcionan correctamente.
Las 10 principales amenazas en la entrega de aplicaciones de IA: direccionamiento del tráfico no optimizado
La IA rompe con los supuestos tradicionales sobre el direccionamiento del tráfico: los backends no son intercambiables, los costes varían y los agentes distribuyen las solicitudes de forma impredecible, por lo que el enrutamiento debe tener en cuenta el modelo, el estado de las GPU y la ubicación de los datos.
Las 10 principales amenazas en la entrega de aplicaciones de IA: controles de tráfico insuficientes
Los límites de tasa y la limitación de tráfico tradicionales no reflejan el verdadero alcance del impacto. Las cargas de trabajo de IA se distribuyen entre modelos, almacenes vectoriales y servicios, lo que provoca picos de latencia, fallos en cascada y reintentos.