Seguimos fingiendo que los modelos no son más que endpoints. Es como si los servidores que alojan los motores que codifican los datos de entrada en una serie de números incomprensibles no existieran.
Ah, amigo mío, existen, y van a ser tan importantes para la entrega de aplicaciones como lo han sido los servidores web y de aplicaciones. Además, una vez más, te obligarán a replantearte la arquitectura de tu infraestructura.
Verás, en cuanto colocas un modelo detrás de un endpoint (es decir, despliegas un servidor de inferencia), este pasa a circular por las mismas autopistas de las capas 4 a 7 (L4–L7) sobre las que funciona tu empresa. Nuestro último estudio sobre seguridad de la IA revela que el 80 % de las organizaciones ya ejecutan inferencias en la nube o en sus propias instalaciones, lo que significa que tu modelo se convierte en otra carga de trabajo de producción que pasa por balanceadores de carga, puertas de enlace, WAF y brókeres de API.
También descubrimos una serie de verdades posiblemente incómodas.
La inferencia multiplica las API
En primer lugar, operar la inferencia multiplica las API. Cada nuevo asistente, servicio de puntuación y marcador de funcionalidad asociado a un modelo se convierte en otro punto de entrada. Esto crea más vías de entrada para la inyección de instrucciones, las filtraciones y la manipulación de resultados, así como más rutas este-oeste por las que el contexto puede circular sin control. El despliegue de la inferencia se correlaciona con una mejor higiene en tiempo de ejecución, pero la brecha sigue siendo un problema. Entre los equipos que operan la inferencia, el 14 % todavía deja pasar instrucciones sin inspeccionarlas. Entre quienes solo consumen SaaS, la cifra asciende al 40 %. Omitir la inspección no es «mantener las cosas sencillas». Es dejar la puerta del establo abierta y felicitar al caballo por su resistencia mientras sale disparado.
Por eso es importante el punto de control. La inferencia circula por los mismos canales que tus API, por lo que las políticas deben aplicarse durante el tránsito. Quienes despliegan sistemas de inferencia parecen tenerlo claro. El 61 % utiliza una pasarela de IA para inspeccionar las entradas y salidas, el 39 % añade cortafuegos y el 35 % emplea proxies personalizados. Los consumidores que solo utilizan SaaS dependen de la configuración predeterminada del proveedor, y se nota. Tienen tres veces más probabilidades de omitir por completo las pruebas o la supervisión, y el 30 % no registra los prompts ni las respuestas para realizar auditorías, frente a solo el 8 % de quienes despliegan sistemas de inferencia. Esto refleja una brecha de madurez, pero también supone una oportunidad. Si tus aplicaciones consumen IA de terceros, una pasarela de IA se convierte en el punto de integración para aplicar pruebas, filtrado y políticas de forma continua. No confíes únicamente en un prompt cortés y una oración.
La inferencia aumenta la importancia de las DPU
En segundo lugar, la inferencia está haciendo que las DPU pasen de ser algo deseable a convertirse en imprescindibles. Entre los equipos que ejecutan inferencia, el 71 % tiene en cuenta o adopta DPU al comprar hardware o elegir instancias. En el grupo que no la implementa, esa cifra se sitúa en el 43 %. Cuando el tráfico cifrado, la inspección en línea y la evaluación de políticas pasan por los mismos equipos que mantienen activas las aplicaciones, la descarga de tareas no es un mero truco para mejorar el rendimiento. Es la forma de mantener una latencia aceptable mientras se descifra, clasifica, inspecciona y aplican políticas a gran escala. Las DPU aceleran precisamente las tareas que más necesita la inferencia: la seguridad de la capa de transporte (TLS), la telemetría, las políticas granulares y las comprobaciones por solicitud. En pocas palabras, una mayor inferencia implica más trabajo en la red, y las DPU soportan esa carga.
La inferencia implica prestar atención al contexto
Por último, el contexto es el segundo pilar que la mayoría de los equipos olvida respetar. La inferencia no se limita a las entradas y salidas. También abarca el historial, las recuperaciones de información, las herramientas y la comunicación entre agentes. A medida que las organizaciones se plantean adoptar el Protocolo de Contexto de Modelo (MCP), ya observamos el mismo patrón. Quienes realizan despliegues prevén estandarizarlo: un 58 % señala que adoptará MCP, frente al 21 % del grupo que no realiza despliegues. Su atractivo es evidente. MCP promete estructurar los flujos de contexto.
El riesgo también es evidente. Un contexto opaco puede convertirse en un canal lateral que eluda sus flamantes políticas. Esto exige una inspección que comprenda las instrucciones y las respuestas, pero también la procedencia y las políticas del propio contexto. Si no permitiría que datos sin auditar alimentaran su motor de negociación, tampoco permita que un contexto sin auditar entre en su modelo.
El impacto en la arquitectura de la infraestructura
Entonces, ¿qué implica todo esto para tu arquitectura? Porque sabes que tiene implicaciones.
Conclusiones clave
- Integre las políticas en el flujo. Las puertas de enlace y los proxies de capa 7 ya forman parte del flujo. Haga que sean conscientes de la inferencia. Inspeccione las instrucciones, filtre los resultados, etiquete los datos y aplique límites por aplicación y por usuario que sean realmente relevantes para los modelos.
- Utiliza DPU para mantener la latencia bajo control. Si pretendes descifrar, clasificar, inspeccionar y aplicar políticas en tiempo de ejecución sin descargar estas tareas, acabarás sacrificando la seguridad en favor del rendimiento un viernes por la noche y fingiendo el lunes que fue una decisión meditada.
- Trata el contexto como una cadena de suministro. Estandariza cómo se compone, etiquétalo, valídalo antes de usarlo y registra su trazabilidad. MCP ayuda, pero solo si se combina con mecanismos de observabilidad y aplicación de políticas capaces de detectar y detener el uso indebido del contexto.
La conclusión más importante de nuestra investigación más reciente es, sencillamente, que la inferencia es ahora una carga de trabajo de primer nivel. Se ejecuta sobre la misma infraestructura que sustenta todo lo demás, pero conlleva nuevos riesgos que sus «reflejos de API» no cubren por completo.
Haz que la infraestructura sea más inteligente, traslada el trabajo pesado a las DPU y controla el contexto, no solo la llamada. Los equipos que lo hagan lanzarán productos más rápido y dormirán más tranquilos. Los demás aprenderán por las malas lo que significa la resiliencia.
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 claves para la entrega de aplicaciones de IA: requisitos de las aplicaciones a medida
La IA convierte lo «personalizado» de caso excepcional en opción predeterminada: las solicitudes pasan a ser cadenas componibles (selección de modelos, recuperación, políticas y herramientas), por lo que la entrega debe adaptarse a cada solicitud, no a cada aplicación.
Las 10 principales amenazas para la entrega de aplicaciones de IA: observabilidad incompleta
La IA no escalará por sí sola. Sin un plano de control unificado que elimine las barreras entre herramientas y responsabilidades, la inferencia se convierte en la capa más frágil y que más coordinación requiere.
Las 10 principales amenazas en la entrega de aplicaciones de IA: prácticas de DNS deficientes
Para los sistemas de inferencia y los sistemas agénticos, la resiliencia del DNS es fundamental para la disponibilidad y el rendimiento: una resolución deficiente provoca errores de enrutamiento, picos de latencia e interrupciones del servicio en distintas regiones.
Comportamiento y límites: el cambio hacia la seguridad agéntica
Los agentes generan secuencias emergentes y sin límites en las que el riesgo se acumula con el tiempo. La seguridad debe pasar de validar solicitudes individuales a supervisar continuamente el comportamiento en flujos de varios pasos que evolucionan con el tiempo.
La IA está impulsando la aparición de nuevos tipos de tráfico
La adopción de la IA está dando lugar a nuevos tipos de tráfico de primer nivel: solicitudes de inferencia, tráfico de automatización generado por máquinas y tráfico de telemetría de gran volumen que alimenta los bucles de control.
La compresión ya no es una cuestión de velocidad, sino del coste de pensar
En la era de la IA, la compresión reduce el coste de pensar, no solo el ancho de banda. Descubre cómo la compresión de prompts, resultados y modelos permite controlar los gastos de inferencia de la IA.