Una base de hardening para LLMs autoalojados: del endpoint expuesto a un nivel listo para producción

En Seguridad de los LLM autoalojados analizamos por qué la IA on-premise no es segura por defecto — 175.000 servidores de inferencia expuestos en internet público lo demostraron mejor que cualquier argumento. Este artículo es la continuación práctica: una base de referencia capa por capa para llevar un despliegue autoalojado de "funciona en la máquina con GPU" a algo que dejarías cerca de datos de producción.

El modelo mental es simple: un servidor de inferencia es un servicio de red de producción. Todo lo que ya haces para una base de datos aplica aquí — más algunas capas específicas de IA que la mayoría de los equipos se saltan.

Capa 1: Red — nada escucha en internet

El fallo más común es también el más barato de corregir. Ollama, vLLM y motores similares se distribuyen sin autenticación; su única protección real es no ser alcanzables.

• Vincula el motor a localhost o a una interfaz privada — nunca a 0.0.0.0 en una máquina expuesta públicamente. En Ollama eso significa dejar OLLAMA_HOST en su valor por defecto 127.0.0.1:11434 y resistir la tentación del "arreglo rápido" que lo abre.
• Bloquea el puerto de inferencia (11434 en Ollama, 8000 en vLLM por defecto) a nivel de firewall y de grupos de seguridad en la nube. Ábrelo solo a tu reverse proxy o a una subred específica de confianza.
• Coloca a cada consumidor detrás de un punto de entrada autenticado. La versión ligera es nginx o Caddy exigiendo claves de API o mTLS delante de un motor vinculado a localhost:

server {
    listen 443 ssl;
    server_name llm.internal.example.com;

    location / {
        if ($http_authorization != "Bearer ${LLM_API_KEY}") {
            return 401;
        }
        proxy_pass http://127.0.0.1:11434;
    }
}

La versión más pesada — que vale la pena una vez que varios equipos comparten el despliegue — es un gateway de LLM dedicado que añade claves por consumidor, límites de tasa, presupuestos y logs de auditoría en un solo lugar.

• Segmenta el stack de IA en su propia zona de red con listas de permitidos explícitas en ambas direcciones. Y, de forma crítica: filtra el egress. Un worker de inferencia casi nunca necesita acceso saliente a internet. El egress default-deny es el control más barato que tienes tanto contra la exfiltración de datos como contra los callbacks de modelos envenenados — y convierte muchas vulnerabilidades "críticas" en no-eventos.

Capa 2: Plataforma — contener el radio de impacto

Las cargas de trabajo de GPU tientan a los equipos hacia contenedores --privileged y procesos root. Eso es exactamente al revés: los drivers de GPU ya dan a este software un alcance inusual sobre el host, así que el contenedor a su alrededor debería ser lo más ajustado posible.

• Ejecuta el motor como usuario no-root, elimina todas las capabilities que no necesites y monta el directorio del modelo en modo solo lectura. Concede acceso a la GPU explícitamente (--gpus, device plugins) — nunca mediante modo privileged.
• Fija las versiones de todo el stack: motor, runtime de CUDA, drivers, imagen base. Los despliegues reproducibles son un control de seguridad, no solo una comodidad operativa.
• Aplica parches según los releases upstream, no según los feeds de CVE. El caso Bleeding Llama (CVE-2026-7482) mostró una corrección publicada meses antes de que existiera el CVE — quien esperaba las alertas del escáner permaneció vulnerable todo ese tiempo con dashboards en verde. Suscríbete a los feeds de releases de tu motor y actualiza según un calendario.
• En infraestructura compartida, recuerda que los motores de serving agrupan usuarios a través de memoria de GPU y cachés KV compartidas. Si los tenants deben estar fuertemente aislados, aíslalos a nivel de instancia — procesos de motor o nodos separados — no solo a nivel de API.

Capa 3: Artefactos del modelo — verifica lo que cargas

Los pesos son artefactos ejecutables y merecen el mismo tratamiento de cadena de suministro que las imágenes de contenedor.

• Solo safetensors. Los formatos basados en pickle (.bin, .pt) pueden ejecutar código al cargarse; en 2026 no hay justificación de producción para usarlos.
• Fija cada modelo a un hash criptográfico y verifícalo en el momento del despliegue, igual que un digest de imagen. Descarga de repositorios oficiales del publisher, no de re-subidas de la comunidad, y verifica firmas donde el publisher las proporcione.
• Trata los modelos internos ajustados (fine-tuned) como propiedad intelectual de máximo valor: almacenamiento con control de acceso, cifrado en reposo, logs de auditoría en cada lectura. Si tu modelo fue ajustado con datos propietarios, el modelo es los datos.

Capa 4: Aplicación — asume que el modelo será manipulado

Todo lo anterior asegura la infraestructura. El comportamiento del modelo es una superficie de ataque separada — la cubrimos en profundidad en Prompt Injection — y la base aquí trata de limitar lo que un modelo manipulado puede hacer:

• Herramientas de mínimo privilegio: solo lectura donde sea posible, sin credenciales de producción al alcance del agente.
• Trata la salida del modelo como entrada no confiable — validada antes de que toque una shell, SQL o una API downstream.
• Ejecución en sandbox y con egress restringido para cualquier código generado por el modelo.
• Confirmación humana para acciones irreversibles.
• Registro completo de prompts y llamadas a herramientas en tu SIEM. Los logs de inferencia son telemetría de seguridad: los intentos de injection, el sondeo y el uso anómalo de herramientas deberían disparar alertas, no aparecer en una revisión posterior al incidente.

La checklist de una página

Red: binding a localhost · puertos de inferencia protegidos por firewall · proxy o gateway autenticado · segmentación · egress default-deny. Plataforma: contenedores no-root · sin modo privileged · versiones fijadas · parcheo basado en releases · aislamiento de tenants a nivel de instancia. Artefactos: solo safetensors · fijados por hash · fuentes de confianza · firmados cuando estén disponibles · pesos fine-tuned como IP protegida. Aplicación: herramientas de mínimo privilegio · salidas validadas · ejecución en sandbox · humano en el loop para acciones irreversibles · telemetría de inferencia en el SIEM.

Nada de esto requiere herramientas exóticas — un reverse proxy, un firewall, un runtime de contenedores y disciplina cubren la mayor parte. La diferencia entre una caja de Ollama expuesta y un despliegue de nivel producción se mide en días de trabajo, no en meses. Lo que sí requiere es la decisión de tratar la infraestructura de IA como lo que realmente es: un servicio de producción con acceso a tus datos más sensibles.

En NextVector construimos infraestructura de backend, blockchain e IA donde la seguridad es una restricción de diseño desde el primer día. ¿Estás planificando un despliegue de LLM on-premise? Contáctanos.