Los modelos de pesos abiertos han superado un umbral de credibilidad. Llama, Mistral, DeepSeek y sus sucesores son ya candidatos serios para producción en empresas europeas reguladas, no solo curiosidades de investigación. El argumento es convincente: tú controlas los pesos, controlas el entorno de ejecución y eres dueño del pipeline de datos. Pero en el momento en que despliegas uno sobre infraestructura GPU compartida, se abre un conjunto de riesgos que la mayoría de los proveedores no tienen incentivo comercial para explicar con claridad. Este artículo se encarga de hacerlo.

La pregunta no es si el despliegue de modelos de pesos abiertos es intrínsecamente peligroso. No lo es. La pregunta es qué aspecto tiene el modelo de amenazas sobre hardware compartido, y cuándo ese modelo de amenazas exige algo más robusto.

Qué significa realmente «pesos abiertos»

Pesos abiertos significa que los parámetros numéricos de un modelo entrenado se publican de forma abierta. Puedes descargarlos, ejecutarlos y ajustarlos en tu propia infraestructura. Esa es la definición relevante para esta discusión. Una definición más estricta de «IA de código abierto», tal como la articula la Open Source Initiative, también exigiría publicar los datos de entrenamiento y el código de entrenamiento. La mayoría de los modelos de pesos abiertos actuales no alcanzan ese nivel porque los conjuntos de datos subyacentes son propietarios.

La consecuencia práctica es que obtienes plena autonomía en tiempo de ejecución sin transparencia total sobre cómo se construyó el modelo. Esa brecha importa para el riesgo de cadena de suministro, al que llegaremos en breve.

El problema a nivel de hardware en la inferencia GPU compartida

Cuando un contexto CUDA se destruye tras finalizar una solicitud en un pod de inferencia, las páginas de DRAM de la GPU que ocupaba no se ponen a cero antes de devolverse al asignador. Es una decisión deliberada de rendimiento, no un descuido. La consecuencia es que el siguiente contexto CUDA que reciba esas páginas puede leer lo que había antes: pesos del modelo, tensores de activación intermedios, entradas de KV-cache y tokens de prompt sin procesar.

En un clúster de inferencia compartido, eso no es una preocupación abstracta. Las plataformas de IA en la nube, incluidas AWS SageMaker multi-model endpoints, Azure Machine Learning managed inference y los node pools de GPU de GKE, implementan la separación de inquilinos a nivel de Kubernetes mientras comparten los drivers del kernel de GPU a nivel de nodo. Una única instancia de NVKM da servicio a todos los modelos en un nodo dado. Un atacante que controle el código de inferencia de un modelo puede intentar explotar NVKM contra ese kernel compartido. El aislamiento de inquilinos depende enteramente de la corrección del driver de NVIDIA, una dependencia muy significativa sobre la que basar tu garantía de aislamiento de datos.

Más allá de los residuos en memoria, la investigación publicada como NVBleed (arXiv:2503.17847) demostró que un atacante puede residir en una GPU diferente, o incluso en una instancia de VM separada, y aun así explotar canales de comunicación inter-GPU para extraer información de cargas de trabajo coubicadas. El ataque fue validado contra un proveedor de nube pública. No es una superficie de ataque teórica; es una demostrada.

La integridad del KV-cache es un vector relacionado y poco valorado. En entornos de servicio multitenant donde el prefix caching está habilitado, un inquilino coubicado puede corromper bloques de prefijo del KV-cache compartido mediante técnicas de bit-flip Rowhammer, haciendo que las respuestas del modelo de otros inquilinos se desvíen silenciosamente del comportamiento esperado. El adversario no necesita ningún privilegio de software más allá de lo que tiene un inquilino normal. Los pesos del modelo, el código de la aplicación y los inputs a nivel de API permanecen intactos y sin que nada delate el ataque.

La propiedad más peligrosa de la infraestructura GPU compartida no es que pueda ser vulnerada desde el exterior. Es que los inquilinos legítimos pueden convertirse en vectores de ataque entre sí sin que ninguna de las partes lo sepa.

Los canales laterales de temporización agravan esto. Los ataques de canal lateral sobre backends de inferencia LLM pueden inferir detalles sobre la carga de trabajo de un inquilino midiendo la contención de recursos o la latencia de planificación desde la posición de otro inquilino. Los entornos de alta seguridad pueden necesitar dedicar GPUs a un único inquilino a la vez, no como un lujo sino como la única mitigación fiable.

El riesgo de cadena de suministro específico de los modelos de pesos abiertos

La seguridad de los LLM autoalojados tiene una segunda dimensión que los debates sobre nube compartida suelen omitir: el propio archivo del modelo es una superficie de ataque. En febrero de 2024, investigadores de seguridad encontraron un modelo en Hugging Face que abría una reverse shell en el momento de cargarse. Los archivos pickle maliciosos en los hubs de modelos públicos son el caso más claro de compromiso de cadena de suministro, catalogado bajo LLM03:2025 en el OWASP Top 10 for LLM Applications.

Las backdoors son más sutiles y difíciles de detectar. Hubinger et al. en Anthropic (arXiv:2401.05566, 2024) entrenaron un modelo que escribía código seguro cuando el año era 2023 e insertaba código explotable cuando el año era 2024. La backdoor persistió a través del entrenamiento de seguridad. Por otro lado, Qi et al. (2024) demostraron que el alineamiento de seguridad puede deshacerse mediante fine-tuning con tan solo diez ejemplos diseñados de forma adversarial, a un coste inferior a 0,20 dólares. El UK AI Security Institute confirmó que las salvaguardas de seguridad pueden eliminarse con unas pocas decenas de ejemplos de entrenamiento en cuestión de minutos.

Las GPAI Guidelines de la Comisión Europea (2025) crean aquí un punto ciego involuntario: solo una modificación significativa de un modelo activa las obligaciones del proveedor para quien la realiza. Pero las modificaciones más peligrosas, las que eliminan las restricciones de seguridad, requieren recursos computacionales mínimos y quedan por debajo de cualquier umbral razonable de «modificación significativa». El marco regulatorio todavía no cubre la amenaza que más necesita abordar.

Cuándo el despliegue en tenant dedicado se vuelve innegociable

El problema de los residuos en memoria de GPU, el canal encubierto inter-GPU y el ataque a la integridad del KV-cache comparten una causa raíz común: el uso compartido de recursos. La única mitigación completa es dejar de compartir. Para cargas de trabajo que procesan datos personales bajo el RGPD, manejan información financiera material no pública u operan en contextos sanitarios o de defensa, el cálculo de riesgo se inclina firmemente hacia la infraestructura dedicada.

La computación confidencial ofrece una respuesta parcial a nivel de hardware. La H100 de NVIDIA (arquitectura Hopper) incorporó soporte de computación confidencial en julio de 2023, con disponibilidad general en 2024. La arquitectura Blackwell, anunciada en marzo de 2024, extiende estas protecciones al cifrado del tráfico inter-GPU para modelos distribuidos de gran tamaño. La publicación de infraestructura de OpenAI de mayo de 2024 listó la computación confidencial a nivel de acelerador como su primera categoría de infraestructura segura. Estas capacidades son reales y están mejorando, pero no están disponibles de forma universal en plataformas de inferencia multitenant compartidas, y no abordan la integridad de la cadena de suministro.

Para el aislamiento de datos de modelos de IA en producción, la lista de verificación práctica es la siguiente:

  • Verifica la procedencia del modelo antes de cargarlo: hash criptográfico contra una fuente de confianza conocida, no solo una coincidencia de nombre de archivo.
  • Ejecuta la inferencia en capacidad GPU dedicada, no en pools multitenant compartidos, para cualquier carga de trabajo que toque datos sensibles.
  • Deshabilita el prefix caching o aplica una partición estricta de caché por inquilino si la multitenencia es inevitable.
  • Trata el archivo del modelo como una dependencia dentro de tu política de cadena de suministro de software, con el mismo escrutinio que aplicas a las bibliotecas de terceros.
  • Audita las versiones del driver de GPU y aplica los parches de NVKM en el mismo ciclo que los CVE a nivel de sistema operativo.

Alcance de red y dónde se ejecuta realmente la inferencia

Una realidad operativa que se pierde en la conversación sobre seguridad: la latencia de la inferencia GPU está dominada por la distancia entre donde se ejecuta el modelo y donde se origina la solicitud. Los despliegues de LLM de código abierto on-premises resuelven el problema de aislamiento, pero pueden reintroducir latencia si el cómputo está lejos de tus usuarios o de tu pipeline de datos. Operamos 44 puntos de presencia en Europa y Oriente Medio, con peering directo a AWS, Azure, GCP, Oracle y Cloudflare en todos los sitios, lo que significa que las cargas de trabajo de inferencia ubicadas en nuestra infraestructura permanecen cerca de los datos que procesan y de las aplicaciones que los consumen, sin las penalizaciones de ida y vuelta que conlleva enrutar prompts sensibles por la internet pública hacia un endpoint compartido y lejano.

El modelo de pesos abiertos no es el riesgo. El entorno de ejecución compartido lo es. Saber distinguir uno del otro es el requisito previo para construir una arquitectura de inferencia de IA que una empresa regulada pueda realmente respaldar.