La ruta de inferencia es la ruta del tráfico: dónde debe residir la seguridad de la IA

Abbas KudratiCISO de campo para APCJ | F5

En una entrada anterior del blog, sostuve que, frente a un modelo de clase Mythos, el lugar donde se intercepta un ataque importa más que si se detecta o no, y que la ruta del tráfico es el único punto de control que un adversario con capacidad de razonamiento no puede eludir. Esta entrada traslada ese argumento al interior de la empresa: qué circula realmente por esa ruta cuando una organización pone la IA a trabajar y por qué la respuesta cambia nuestra forma de diseñar la seguridad.

Hace unos meses, asistí a un debate sobre IA empresarial que comenzó como suelen hacerlo la mayoría. ¿Qué modelo deberíamos utilizar? ¿Deberíamos ejecutarlo nosotros mismos o recurrir a uno público? ¿Cómo podemos mejorar la precisión y reducir las alucinaciones? Todas eran buenas preguntas. Pero nadie preguntó qué ocurre después de elegir el modelo.

Esto es lo que ocurre. Un usuario envía una instrucción. Una aplicación la recibe, comprueba quién es el usuario, obtiene contexto de un repositorio de documentos o una base de datos y llama a varias API internas. Un agente puede decidir que se necesita una herramienta. La solicitud completa llega al modelo, que genera tokens. Esos tokens pueden constituir una respuesta. También pueden ser la instrucción que desencadene la siguiente llamada a una API, el siguiente flujo de trabajo o un cambio en un sistema de registro.

Visto así, el modelo es un componente de una cadena mucho más larga. Esa cadena es lo que denomino la ruta de inferencia, y la observación en la que se basa esta publicación es sencilla: La ruta de inferencia es la ruta del tráfico.

Qué es realmente la ruta de inferencia

El entrenamiento enseña a un modelo. La inferencia es el momento en que el modelo entrenado se pone a trabajar. Cuando un empleado pide a un asistente empresarial que «resuma los últimos resultados y redacte un correo electrónico para el equipo directivo», la solicitud sigue un recorrido similar a este:

Usuario → Aplicación → Identidad → Contexto y recuperación → API → Agente → Modelo → Herramientas → Modelo → Respuesta → Usuario

Cada salto de ese recorrido constituye tráfico de red y de aplicaciones. Tiene puntos de conexión, latencia, decisiones de enrutamiento y una identidad asociada. Transporta datos, consume presupuesto y, cada vez más, conlleva la autoridad para realizar acciones.

Mi compañera Lori MacVittie planteó una cuestión relacionada a principios de este año: la inferencia es un comportamiento en tiempo de ejecución en producción y funciona como una capa de aplicación, con usuarios, patrones de tráfico, sensibilidad a la latencia, modos de fallo, restricciones de costes y riesgos de seguridad. Kunal Anand, director de Producto de F5, describe el mismo recorrido como una nueva cadena de suministro de valor, desde el prompt hasta la entrada, pasando por los flujos de trabajo y la inferencia, y de vuelta al usuario. Una vez que se acepta este planteamiento, la conversación sobre seguridad debe evolucionar en consonancia. Mani Ganesan, vicepresidente de Gestión de Productos de Seguridad de IA de F5, analiza lo que este cambio supone para la superficie de ataque en su reciente artículo: «Tu IA es ahora una superficie de ataque. ¿Estás preparado para protegerla?»

Cuatro supuestos que conviene dejar atrás

A medida que los CISO refuerzan la seguridad de la IA, estas son cuatro suposiciones que todos debemos dejar atrás:

• «Todo gira en torno al modelo». El modelo acapara la atención porque es la parte visible. Sin embargo, el prompt puede contener datos sensibles, el proceso de recuperación puede extraer registros confidenciales, el agente puede disponer de credenciales de API y la herramienta a la que llama puede tener permisos para escribir en una base de datos. Proteger únicamente el modelo es como reforzar una base de datos e ignorar la aplicación y las API que se comunican con ella. La superficie de ataque abarca todo el recorrido.
• «Pasar de la fase piloto a producción es un ejercicio de escalado». Un proyecto piloto suele tener un modelo, unos pocos usuarios, una aplicación y un acceso aprobado manualmente. El entorno de producción no se parece en nada a eso. Informe sobre el estado de la estrategia de aplicaciones de F5 de 2026 reveló que las organizaciones coordinan una media de siete modelos de IA; el 77 % afirma que la inferencia, y no el entrenamiento, es ahora su principal actividad de IA, y el 52 % encadena u orquesta varios modelos. No se trata de la misma arquitectura con más usuarios, sino de una arquitectura diferente, y el modelo de seguridad debe evolucionar con ella.
• «La velocidad, la seguridad y la gobernanza son capas independientes». Pensemos en una instrucción que contenga información personal. En algún punto entre el usuario y el modelo, esa solicitud debe inspeccionarse, anonimizarse cuando así lo exijan las políticas, dirigirse a un modelo aprobado, supervisarse y registrarse con fines de auditoría, todo ello mientras está en tránsito. El mismo punto de decisión que se pregunta «¿Adónde va esta solicitud?» ahora también debe responder «¿Debería ir allí?». Se trata de una única decisión de procesamiento del tráfico, no de tres funciones añadidas por separado.
• «Podemos integrar herramientas específicas». Sin duda, una organización puede montar todo el conjunto: puerta de enlace de API, WAF, DLP, IAM, mecanismos de protección de IA, una puerta de enlace de modelos, observabilidad, SIEM, controles de agentes y seguridad de MCP. Ninguna de estas herramientas es mala. El problema está en los puntos de conexión entre ellas. Imaginemos una solicitud que atraviesa seis puntos de control, cada uno con su propio motor de políticas y contexto de identidad. ¿Quién sabe que el usuario que escribió el prompt es la misma identidad que ahora invoca la herramienta? ¿Quién puede ver que la llamada a la API, la llamada al modelo y la llamada a la herramienta forman parte de una única transacción? ¿Quién puede aplicar una política coherente durante todo el recorrido y demostrar después qué ocurrió?

En mi anterior artículo señalé que los puntos de conexión son el primer lugar en el que busca un adversario capaz de razonar. Lo mismo ocurre con un agente bienintencionado que simplemente se desvía de las políticas establecidas.

Una vez que la inferencia se trata como tráfico, la propia ruta se convierte en el lugar natural para aplicar controles de identidad, políticas, protección de datos y control de agentes, tanto a la entrada como a la salida.

Cuando el tráfico empieza a transmitir intención

La IA añade nuevas etapas a la conocida secuencia de solicitud, enrutamiento, políticas y respuesta: contexto, recuperación, orquestación e invocación de herramientas. Pero el cambio más profundo radica en lo que transporta el tráfico. El tráfico convencional transporta datos. El tráfico de inferencia transporta intención, contexto y decisiones.

Esto cobra especial importancia con los agentes. Un asistente que responde a una pregunta es una cosa. Un agente capaz de leer registros de clientes, abrir incidencias, enviar correos electrónicos, ejecutar código, modificar la infraestructura o emitir una orden de pago es algo completamente distinto. La ruta de inferencia se convierte en una ruta de acción, y el impacto potencial de una mala decisión deja de limitarse al ámbito informativo.

La transacción de inferencia es la nueva unidad de seguridad

La seguridad tradicional se centra en los usuarios, los dispositivos, las aplicaciones, las API, las cargas de trabajo y los datos. El modelo de confianza cero nos enseñó a preguntar no solo «¿Quién eres?», sino también «¿A qué intentas acceder?». Los sistemas de IA exigen una tercera pregunta: «¿Qué le estás pidiendo a la IA que haga, con qué datos, a través de qué modelo y qué acciones podría desencadenar esta interacción?»

Responder a esa pregunta requiere un contexto que ningún control existente posee por sí solo. Pensemos en un usuario autenticado de un copiloto financiero cuya solicitud extrae datos financieros confidenciales, los introduce en un modelo externo, los transfiere a un agente financiero y termina con una llamada a la API del ERP para crear una orden de pago. La identidad del usuario por sí sola no basta para tomar esa decisión. Debe tenerse en cuenta toda la transacción.

Por eso están convergiendo la identidad, la seguridad de las aplicaciones, la seguridad de las API, la seguridad de la IA y la gestión del tráfico. La unidad en torno a la que convergen es la transacción de inferencia: identidad más instrucción más contexto más modelo más datos más herramientas más resultado más acción. Es un objeto mucho más rico que una solicitud HTTP.

Una vez que se empieza a pensar en términos de transacciones, la seguridad deja de ser un punto de control y se convierte en un proceso continuo. Antes de la inferencia, las preguntas son quién realiza la solicitud, qué datos proporciona, si el prompt es malicioso y qué modelo debe recibirlo.

Durante la inferencia, las preguntas son si la solicitud se ajusta a las políticas y al presupuesto, y si un agente está intentando realizar una llamada a una herramienta para la que nunca recibió autorización. Después de la inferencia, son si es seguro devolver la respuesta, si esta desencadenó alguna acción y qué debe registrarse. Cada decisión debe tomarse allí por donde fluye el tráfico, porque es el único lugar donde se dispone de todo el contexto a la vez.

Qué significa esto para los CISO

Ya hemos visto este patrón antes. Los monolitos dieron paso a las aplicaciones distribuidas, el modelo cliente-servidor evolucionó hacia las API y los microservicios, y la seguridad perimetral cedió terreno a los controles basados en la identidad y con reconocimiento de las aplicaciones. En cada ocasión, la infraestructura encargada de gestionar y proteger el tráfico adquirió una importancia estratégica. La inferencia es la siguiente etapa de ese ciclo.

Así pues, la pregunta que debe plantear a su equipo de arquitectura no es solo dónde se alojan sus modelos. Pregunte por dónde circula el tráfico de inferencia, qué transporta, a qué puede acceder, qué decisiones toma y qué acciones puede desencadenar. A continuación, plantee la pregunta más difícil: ¿dónde podemos aplicar políticas a todo ello sin ralentizar la aplicación?

Porque, en la era de la IA, es posible que el perímetro de seguridad más importante ya no esté en torno al modelo, sino en la ruta de entrada y salida de este.

Para obtener más información sobre el enfoque de F5, visita la página de F5 AI Gateway. No olvides leer también mi anterior entrada del blog: «Detener la IA de frontera en la red: por qué el control en línea es una ventaja fundamental frente a los modelos de clase Mythos.»

Sobre el autor

Abbas KudratiCISO de campo para APCJ | F5

Más artículos de Abbas Kudrati