Los beneficios de la inteligencia artificial (IA) casi nunca aparecen en el balance de pérdidas y ganancias, normalmente por motivo de la arquitectura y no del modelo. Los equipos envían un proyecto piloto que funciona para, a continuación, ver cómo los beneficios se ven mermados por la latencia, por unos costes informáticos descontrolados y por incidentes de seguridad que nadie había contemplado en el presupuesto. El modelo funciona, pero el diseño de la infraestructura subyacente no se diseña con la idea de llevar la carga de trabajo a producción.
Akamai encargó dos estudios para realizar pruebas de presión en los casos en los que se produce esa situación. En El estado de la inferencia de IA 2026 se ha encuestado a 200 profesionales que realizan inferencia en producción, de los cuales tres cuartas partes eran ingenieros y arquitectos y, en su mayoría, se encargaban de la toma de decisiones de implementación. En Estudio de impacto en la seguridad de API de 2026 se ha encuestado a 1840 profesionales de la seguridad de seis sectores y de 10 países.
Conjuntamente, los dos informes apuntan a una conclusión: la mayoría de los equipos están usando una infraestructura diseñada para el entrenamiento que van ampliando para abarcar la inferencia, encontrándose problemas relacionados con el coste, la latencia y la exposición.
Estos problemas desaparecen cuando se producen tres situaciones:
Una arquitectura que se adapta a las condiciones en tiempo real.
Seguridad integrada en esa arquitectura en lugar de incorporada posteriormente.
Inferencia en una ubicación lo suficientemente cercana a los usuarios como para cumplir objetivos en tiempo real.
Ninguno de estos factores es novedoso por sí solo. El problema radica en considerarlos proyectos independientes al cargo de equipos diferenciados.
Vamos a empezar por la definición. La inferencia es el paso en tiempo real por el que un modelo entrenado recibe una entrada nueva y devuelve una salida. Cada llamada de inferencia se realiza como una llamada de API, por lo que el modelo y la API no son conceptos aislados. Comparten la misma ruta de solicitud, los mismos modos de fallo y la misma superficie de ataque. Ese hilo conductor está presente en ambas encuestas.
Aplicaciones donde la centralización no es realmente una buena opción
La inferencia centralizada aún tiene sus ámbitos de aplicación. En el entrenamiento, los trabajos por lotes y las cargas de trabajo tolerantes a la latencia, concentrar los recursos informáticos en unas pocas regiones grandes suele ser la opción adecuada. De hecho, Akamai ejecuta muchas cargas de trabajo de esa manera. Sin embargo, cuando hablamos de datos el tema es más acotado y útil: la centralización deja de ir bien con una clase específica y en aumento de cargas de trabajo, y son muchos los equipos que no han adaptado su arquitectura para ello.
El informe sobre el estado de la inferencia de IA ha revelado que el 75 % de las organizaciones han trasladado la IA generativa (GenAI) a la producción, si bien su infraestructura no ha evolucionado al mismo ritmo. Un porcentaje cada vez mayor de esas cargas de trabajo ahora están sujetas a requisitos de latencia complejos en tiempo real en los que un recorrido de ida y vuelta a una región distante no es adecuado. Además, el 60 % de los profesionales consideran que la proximidad a los usuarios y a los datos es un factor "importante" o "esencial".
Incluso en este caso, el 46 % siguen trabajando con la inferencia desde una sola región centralizada. Ahí radica la contradicción: no hablamos de que la centralización no funcione en ningún lugar, sino de que una parte cada vez mayor de la inferencia en producción debe realizarse más cerca del usuario de lo que permite una infraestructura centralizada.
Las primeras cargas de trabajo en dejar de ir bien son previsibles: puntuación sobre fraude en transacciones en vivo, agentes de voz, personalización en tiempo real y cualquier canal agéntico donde se encadenen varias llamadas a modelos antes de devolver una respuesta. Cada salto hereda la latencia del anterior. Si concentramos todo esto en una región, los retrasos en las colas se agravarán a medida que aumente el uso, añadiendo cientos de milisegundos exactamente cuando la carga de trabajo menos puede permitírselo.
Ese es el motivo por el que la verdadera cuestión no es si usar una infraestructura centralizada o distribuida como principio fundamental, sino más bien qué cargas de trabajo necesitan un centro de datos cercano y cuáles no. Los equipos que entienden esto responden de forma correcta a esa pregunta deliberadamente, carga de trabajo a carga de trabajo, en lugar de colocar de forma predeterminada todo en una región y tener que asumir el efecto en la latencia.
Arquitectura adaptable y coste oculto
Un retorno de la inversión (ROI) bajo suele ser una señal de que un equipo compensa desde el punto de vista operativo en lugar de desde el punto de vista arquitectónico. Lo que lo delata es la economía unitaria: el coste de una sola solicitud de inferencia, medido por token o por consulta. Si no sabe cuál es ese coste, no podrá reducirlo ni ver el momento en que se le descontrola.
La mayoría de los equipos no lo saben: el 77 % de las organizaciones carecen de una economía coherente a nivel de unidad que busca inferencias, lo que implica que la mayoría no pueden saber si una carga de trabajo determinada es cada vez más barata o más cara conforme va creciendo. Esa falta de visibilidad también supone una falta de seguridad. Un pico inexplicable en el consumo de tokens suele ser la primera señal de un ataque de denegación de cartera (DoW), en el que un atacante aumenta el volumen de inferencia con el objetivo concreto de que la factura aumente.
Cuando la arquitectura no puede adaptarse por sí sola, los ingenieros recurren a la intervención manual. Redirigen el tráfico manualmente cuando se producen picos en una región. Hacen que se ofrezca una respuesta de menor calidad para poder mantener vivo un servidor sometido a presión. Cuando la inferencia se ralentiza, el 51 % de los equipos vuelve a intentar usar el mismo modelo, lo que normalmente empeora la congestión en lugar de acabar con ella. A esto se le denomina triaje y no escala. Adaptar un sistema rígido supone más pérdidas para este.
La corrección se debe llevar a cabo de forma programática:
Etiquete cada solicitud de inferencia con metadatos de modelo y de token que se transmitan a la supervisión en tiempo real, de modo que aquel modelo que esté descontrolado se pueda detectar antes de que afecte al presupuesto.
Defina el comportamiento apertura y cierre ante fallos en el código, de modo que el sistema cambie a un resultado almacenado en caché o a un modelo local más pequeño cuando el principal no responda, sin tener que despertar a un ingeniero a las 2 de la mañana.
El 64 % de los profesionales ya consideran que el direccionamiento automatizado del tráfico es un requisito esencial, lo que indica hacia dónde se dirige el mercado.
La distribución es el clave del rendimiento
Cuando un ROI bajo se traduce en una latencia alta y una conversión baja, la ubicación geográfica suele ser la causa principal. La inferencia en tiempo real es intermitente y sensible a la latencia, e Internet junto con un centro de datos distante no pueden ofrecerla de manera fiable.
Los números no mienten. Si cuenta en total con 250 milisegundos y en el cálculo se tardan 100 ms y en la negociación con la API 50 ms, le quedarán 100 milisegundos para transmitir los datos. Cambie de continente y los milisegundos se habrán desvanecido antes de que el modelo empiece a trabajar.
Al colocar la inferencia en puntos de presencia (PoP) en distintas ubicaciones consigue que el trabajo duro se mantenga en la misma región en la que reside el usuario, evitando la congestión de Internet y eliminando el límite de velocidad característico de una infraestructura centralizada. La respuesta parece nativa porque, si hablamos en terminología de red, es local.
Cuando hablamos de temas como los agentes de IA, se habla de que hay que realizar unas seis interacciones antes de que se lleve a cabo realmente una tarea. Si el usuario está lo suficientemente lejos como para que una interacción tarde 100 milisegundos, usted tendrá 600 milisegundos justo ahí. Esto puede estar bien en el caso de algunas aplicaciones, pero actualmente hay muchas aplicaciones que se están creando en el Edge y que se ven afectadas por la latencia. En el sistema de IA integrado en su vehículo es muy importante que obtenga todos sus datos y la información transmitida en un tiempo mucho más reducido.
La distribución lleva a cabo otro proceso importante para la seguridad. Cuando la inferencia y la aplicación se producen en la misma ubicación, la red puede autenticar al usuario, inspeccionar la llamada a la API y ejecutar el modelo en un solo lugar. De esta forma se cierra el bucle en lugar de tener que enviar la solicitud a distintas zonas para que se compruebe en otro lugar.
La seguridad es una propiedad de la arquitectura, no una línea de trabajo diferenciada
Si no protege la inferencia, no podrá adaptarla al crecimiento. Si considera a la seguridad como un flujo de trabajo paralelo, notará las consecuencias en el rendimiento. Ambos estudios señalan que donde se produce el verdadero fallo no es en la topología, sino en unas API no seguras, no probadas e invisibles.
Los datos son contundentes: el 87 % de las organizaciones experimentaron un incidente de seguridad de API el año pasado, con una subida respecto al 76 % de 2022. Entre los equipos que sufrieron incidentes, los ataques a API vinculadas a la IA fueron el tipo de incidente de seguridad relacionado con API que más se mencionaba en el estudio, donde el 42 % informaba de ataques a API vinculadas a tecnologías de la IA.
El incidente medio ahora supone un coste de 700 000 USD al año, mientras que el cuartil superior de incidentes supone un coste superior a 1,8 millones de dólares. Las API vinculadas a la IA no representan un riesgo futuro; representan un riesgo actual.
No se puede defender aquello que no se ve
La visibilidad se mueve en la dirección incorrecta durante todo este proceso. Tan solo el 23 % de las empresas conocen cuáles de sus API devuelven datos confidenciales, lo que supone una reducción en comparación con el 40 % de 2022. No se puede proteger una infraestructura que no se puede ver, y la IA está haciendo que esa infraestructura crezca más rápido de la velocidad con que se puede rastrear con un inventario manual. Los copilots activan terminales que en ningún momento se someten a una revisión de seguridad. Las interfaces de lenguaje natural extraen los datos mediante una inyección de instrucciones trivial para un atacante que encuentre la ruta no protegida correcta.
Si adoptamos una perspectiva crítica, el punto de entrada no lo es todo. Un atacante que vulnere una sola API vulnerable intentará moverse lateralmente a los componentes donde se encuentra el verdadero valor: los almacenes de características que seleccionan los datos de la IA, así como los repositorios que contienen las ponderaciones y la lógica de los modelos.
La microsegmentación, la práctica de seguridad recomendada que aísla las distintas cargas de trabajo, es lo que contiene esa onda expansiva. La mayoría de las organizaciones no la han implementado, pero las que lo han hecho han contenido los ataques significativamente más rápido. La segmentación heredada basada en una red tiene fama de ser un actividad compleja, laboriosa e ineficaz. La microsegmentación moderna basada en IA aborda este problema, pero cuestiona los prejuicios arraigados. Si se integra esa segmentación en la misma red que ofrece la inferencia, se evitará el tener que decidir entre protección o rendimiento.
El patrón de implementación se basa en la identidad. Las organizaciones deben:
Definir el acceso por identidad de carga de trabajo en lugar de por dirección IP, para que un servicio de inferencia específico pueda llegar a un almacén de características específico y a nada más.
Ejecutar la detección continua de API para encontrar los terminales de prueba abandonados que sigan conectados a los datos de producción.
A continuación, la seguridad se convierte en una propiedad permanente de la estructura, en lugar de en una auditoría puntual que los desarrolladores evitan.
Un problema de doble vertiente
La cuestión más profunda que ambos estudios sacan a la luz es organizativa, no técnica. Los equipos colocan el tráfico y la seguridad en dos vías distintas, siendo la unión entre ellas el lugar donde las cosas fallan.
Esa unión se convierte en una brecha de confianza: el 40 % de los directivos hablan de pruebas de API avanzadas maduras, mientras que solo el 28 % de los equipos de operaciones de seguridad y desarrollo (DevSecOps) que realizan el trabajo están de acuerdo. Los directivos creen que el problema se ha resuelto, por lo que la base se mantiene con recursos insuficientes, mientras el gasto se traslada a herramientas adyacentes. La distancia entre lo que los directivos creen que está protegido y lo que realmente está protegido sigue aumentando.
Para reducirla, los equipos que gestionan el tráfico y los que protegen el tráfico deben trabajar en el mismo plano de control, o al menos, en uno convergente. Cuando la detección y la contención comparten ese plano, un patrón de solicitud anómalo, típico de inyección de instrucciones, o DoW, puede activar el aislamiento automatizado del terminal de inferencia afectado, sin que sea necesario que intervenga ninguna persona. Esta sincronización solo se consigue cuando la distribución y la seguridad no son sistemas independientes.
Cómo avanzar a partir de aquí
Dos capacidades son las que marcan la diferencia entre los equipos que avanzan frente a los que se quedan estancados:
Portabilidad. Los operadores consolidados tienen bastantes menos dependencias, ya que pueden mover las cargas de trabajo a distintas unidades de procesamiento gráficos (GPU) gestionadas, API alojadas y tiempos de ejecución sin servidor conforme cambien el coste y la capacidad.
Control del tiempo de ejecución. El control de las instrucciones maliciosas que entran y de las respuestas con filtración de datos que salen se aplica en la capa de red, en lugar de incorporarse a la aplicación.
Si se colocan en una única plataforma, donde la distribución, la seguridad y el direccionamiento del tráfico compartan un plano de control, el tener que renunciar a protección o a rendimiento desaparece. Podrá ver lo que se está ejecutando, dónde se ejecuta y si está siendo objeto de un ataque.
Este es el problema que Akamai ha estado resolviendo en cuanto a la distribución y a la seguridad del contenido, y ahora está resolviendo para la inferencia en la producción. La misma red global que coloca la inferencia cerca de los usuarios también se encarga de la seguridad de API, de la microsegmentación y de la protección ante ataques distribuidos de denegación de servicio (DDoS) relacionada. Ese enfoque es lo que permite que una red realice ambos trabajos a la vez.
Un ROI incierto en IA es un síntoma
La causa es una infraestructura que aún no ha logrado integrar una arquitectura, seguridad y distribución adaptables en una misma base. La brecha entre rendimiento y protección se está ampliando, pero no es estructural ni permanente. Esta brecha desaparece cuando los equipos que se encargan del tráfico son los equipos que lo protegen en una infraestructura creada para ofrecer inferencia en lugar de adaptarse a ella para tolerarla.
Más información
Para obtener más información, lea El estado de la inferencia de IA 2026 y el Estudio sobre el impacto de la seguridad de API.
Etiquetas
