Seguridad de los LLM autoalojados: on-premise no significa seguro por defecto

Las empresas están trasladando sus cargas de trabajo de IA a entornos on-premise por buenas razones: residencia de datos, cumplimiento del RGPD y SOC 2, y control de costes a gran escala. Ejecutar un modelo de pesos abiertos dentro de tu propio perímetro significa que los prompts y los pesos ajustados nunca salen de tu infraestructura. Pero detrás de esa decisión se esconde una suposición peligrosa: «funciona en nuestros servidores, así que es seguro». No lo es. El autoalojamiento elimina un riesgo — que un tercero vea tus datos — y te traslada toda la responsabilidad de todo lo que un proveedor de API gestionada asumía en silencio: seguridad de los endpoints, verificación de artefactos, aislamiento y aplicación de parches. Esta es la superficie de ataque real.

175.000 servidores de inferencia expuestos

En septiembre de 2025, Cisco Talos encontró más de 1100 instancias de Ollama en internet público sin ninguna autenticación. A principios de 2026, los escaneos de SentinelLABS y Censys contabilizaron aproximadamente 175.000 hosts de Ollama accesibles públicamente en 130 países, además de endpoints de vLLM y LiteLLM sin protección. La causa raíz: las herramientas populares de autoalojamiento se diseñaron pensando en la comodidad del desarrollador. La API REST de Ollama se distribuye sin ninguna autenticación integrada. Basta un binding a 0.0.0.0 o un grupo de seguridad en la nube demasiado permisivo para que toda la API quede abierta. Los atacantes escanean activamente en su busca — operaciones documentadas de «LLMjacking» localizan instancias abiertas y revenden el acceso en mercados clandestinos. Un endpoint abierto le da a un atacante cómputo de GPU gratuito, la capacidad de extraer tus modelos ajustados (que son tus datos), visibilidad de los prompts de sistema y las configuraciones de RAG, y un punto de apoyo dentro de tu red.

CVEs en la pila de inferencia

La capa de servicio es software joven, construido pensando ante todo en el rendimiento. El historial hasta ahora:

• Probllama (2024) — ejecución remota de código (RCE) en Ollama
• CVE-2025-47277 — la capa de inferencia distribuida de vLLM invocaba pickle.loads() sobre datos procedentes de un socket de red: un caso de manual de RCE
• Bleeding Llama, CVE-2026-7482 — tres llamadas de API sin autenticar filtraban prompts de sistema, sesiones, claves de API y credenciales de base de datos de Ollama. El parche existió durante meses antes de que se asignara la CVE — los escáneres y las herramientas de cumplimiento estuvieron ciegos todo ese tiempo

La lección: un servidor de inferencia es un servicio de red en producción y necesita la misma disciplina de parcheo que tu base de datos. Sigue directamente las versiones upstream — depender solo de los feeds de CVE te fallará. Existe además un riesgo propio de la IA: los motores de servicio agrupan solicitudes en pools de memoria de GPU y cachés KV compartidos. Un proceso comprometido puede filtrar fragmentos de conversaciones de otros usuarios, y los controladores de GPU privilegiados dejan a un contenedor comprometido a un solo paso del host.

Los pesos de los modelos son artefactos ejecutables

Los equipos aplican seguridad de cadena de suministro al código, pero descargan pesos de modelos desde hubs públicos sin verificación alguna. Dos modos de fallo: Serialización maliciosa. Los formatos de modelo basados en pickle pueden ejecutar código arbitrario al cargarse. En 2026 no hay ninguna razón para cargar en producción algo que no sea safetensors. Envenenamiento de modelos. Pesos que se comportan con normalidad en los benchmarks pero que han sido ajustados para filtrar datos o seguir instrucciones ocultas bajo condiciones específicas. Sin fallos, sin entradas en el registro. La solución es la higiene clásica de cadena de suministro: solo fuentes de confianza, artefactos anclados a hashes verificados, firmas de modelo cuando estén disponibles, y modelos internos ajustados tratados como la propiedad intelectual más valiosa de la empresa.

A la inyección de prompts no le importa dónde se ejecuta el modelo

Las instrucciones maliciosas incrustadas en documentos, correos electrónicos o páginas web funcionan de forma idéntica contra modelos autoalojados y modelos en la nube. Y el autoalojamiento a menudo lo empeora: los modelos de pesos abiertos tienen un entrenamiento de seguridad más débil, los equipos desactivan las salvaguardas «porque total, es interno», y el modelo on-premise suele tener acceso mucho más privilegiado — bases de datos, APIs internas, herramientas del sistema de archivos — del que jamás tendría un modelo en la nube. El OWASP Top 10 para aplicaciones LLM es el marco de referencia adecuado. Lo esencial: acceso a herramientas bajo el principio de mínimo privilegio, tratar la salida del modelo como entrada no confiable, ejecución de código en sandbox y filtrado de tráfico de salida en los workers de inferencia.

Base de hardening

El mínimo exigible para producción:

• Red: binding a localhost o subredes privadas; todo el acceso a través de un proxy inverso autenticado o una puerta de enlace LLM; filtrado de salida activado por defecto
• Plataforma: contenedores sin privilegios de root, capacidades mínimas, parcheo que sigue de cerca las versiones upstream
• Artefactos: solo safetensors, anclados a hashes, almacenamiento con control de acceso para los pesos ajustados
• Aplicación: revisión conforme al OWASP LLM Top 10, validación de salidas, registro completo de la inferencia en tu SIEM

Nada de esto es exótico — es la misma disciplina que ya aplicas a las bases de datos, extendida a una nueva carga de trabajo que la mayoría de los equipos despliega hoy con la postura de seguridad de un proyecto personal de fin de semana.

Conclusión

«On-premise» es una propiedad de residencia de datos, no de seguridad. Los 175.000 servidores de inferencia expuestos no son un fallo de herramientas — son un fallo de mentalidad: infraestructura de IA desplegada como una aplicación de escritorio cuando debía tratarse como una base de datos en producción. En NextVector construimos infraestructura backend y blockchain donde la seguridad es un requisito de diseño, no una idea de último momento — y la misma disciplina se aplica directamente a la IA. ¿Estás planificando un despliegue de IA on-premise? Contáctanos.