En los sectores regulados, la mayoría de las conversaciones sobre despliegue de IA acaban con la misma pregunta: «¿Y dónde estarán nuestros datos?» Cuando la hace el director médico, el compliance officer de un banco o el socio de un despacho, la pregunta no es retórica — detrás de una respuesta incorrecta hay una multa, la revocación de una licencia o responsabilidad penal.
Este artículo no trata de *si* ir on-premise — sobre eso escribimos en la comparativa de LLM locales frente a la nube. Este trata de *cómo* construir una infraestructura LLM on-premise que resista el escrutinio del regulador, la auditoría de TI y la operación diaria.
Por qué la nube no basta — aunque el proveedor prometa GDPR
Los proveedores cloud tienen certificaciones de seguridad excelentes. El problema no es su tecnología — el problema es la construcción jurídica y la arquitectura de los flujos de datos.
Cuando envías un prompt a una API externa, los datos abandonan físicamente tu infraestructura. Aunque el proveedor no persista tus solicitudes (y la mayoría de los tiers enterprise hoy afirman que no lo hacen), desde la perspectiva del GDPR art. 28 has establecido una relación de encargado del tratamiento de datos personales. Eso exige un contrato de tratamiento de datos (DPA) firmado, la verificación del tercero y un registro de actividades de tratamiento.
Para los centros sanitarios se añade la HIPAA en EE. UU. o la transposición local de las recomendaciones del EDPB en la UE. Para los bancos entra el ICT Risk de la EBA y el marco DORA. Para los despachos de abogados la pregunta es aún más directa: el secreto profesional no distingue entre papel y una API request.
El on-premise elimina el riesgo de data egress en principio. Ni un solo token de tus pacientes, clientes o transacciones abandona tu red. Es una diferencia que no depende del framing de marketing — es un hecho técnico auditable.
Dicho esto, seamos honestos: el on-premise por sí solo no equivale a compliance. El regulador quiere ver logs de auditoría, controles de acceso, cifrado de datos en reposo y en tránsito, un proceso documentado de respuesta a incidentes y un análisis de riesgos periódico. «Funciona en nuestro servidor» es el punto de partida, no la meta.
Qué debe contener la arquitectura LLM on-premise
Antes de elegir la GPU y el modelo, es necesario definir qué estás construyendo. Una arquitectura LLM on-premise funcional para sectores regulados tiene cinco capas:
1. Motor de serving y capa de inferencia
Para despliegues multiusuario en producción, hay dos frameworks principales relevantes:
- `vLLM` — estándar industrial para serving de alto throughput. La PagedAttention reduce drásticamente la fragmentación de la KV cache; el continuous batching elimina la espera por la solicitud más lenta del lote. El soporte de hardware más amplio (NVIDIA, AMD, Gaudi).
- `SGLang` — ventajoso en workloads RAG y diálogos multi-turno gracias a la RadixAttention, que cachea la KV cache de prefijos compartidos. En workloads con prefijos intensivos alcanza mayor throughput y menor latencia del primer token (TTFT) que vLLM.
Para experimentos de un único desarrollador y pilotos, Ollama es válido. Para un sistema en producción con decenas de usuarios concurrentes está infravalorado — internamente usa llama.cpp, que no está diseñado para solicitudes concurrentes, y la diferencia de throughput con múltiples peticiones en paralelo es sustancial.
2. Modelo — qué te puedes permitir y qué es capaz de hacer
La elección del modelo para on-premise es ante todo una cuestión de hardware. El volumen de VRAM determina qué puedes ejecutar.
Requisitos orientativos de VRAM para inferencia (para formatos habitualmente usados en on-premise):
- Modelo 7–9B: ~5–7 GB de VRAM con cuantización Q4_K_M, ~8–13 GB con Q8_0
- Modelo 13B: ~8 GB con Q4_K_M, ~14 GB con Q8_0
- Modelo 34B: ~17–20 GB con Q4_K_M, ~30–34 GB con Q8_0
- Modelo 70B: ~35–40 GB con Q4_K_M, ~70–75 GB con Q8_0
A esto se añade la KV cache — en contextos largos puede ser tan grande como los propios pesos del modelo. Para un despliegue en producción con varias solicitudes concurrentes y contextos de longitud media, cuenta con un margen significativo sobre la VRAM de los pesos.
De los modelos open-weight que tienen sentido para sectores regulados en 2026:
- Llama 4 Maverick y Scout (Meta, licencia propia) — arquitectura MoE, rendimiento sólido, contexto de 1M+. La licencia personalizada de Meta es suficiente para la mayoría de los despliegues internos enterprise.
- Familia Qwen 3 (Alibaba, Apache 2.0) — excelente rendimiento en tareas document-heavy, soporte multilingüe incluidos los idiomas europeos, licencia permisiva.
- Mistral Small (Apache 2.0) — proveedor europeo (ventaja para la argumentación GDPR), licencia permisiva. El modelo mayor Mistral Large tiene licencia propia de Mistral — para despliegue on-premise comercial es necesario verificarla.
- Phi-4 (Microsoft, MIT) — para casos de uso donde la capacidad de 7–14B parámetros es suficiente; bajos requisitos de hardware, buen seguimiento de instrucciones.
Para sectores regulados recomendamos modelos con licencia permisiva (Apache 2.0, MIT) — el uso comercial es inequívoco y la auditoría de licencias es directa.
3. Cuantización — una concesión habitualmente aceptable
La cuantización reduce el footprint de VRAM y aumenta el throughput a costa de una ligera pérdida de precisión. Para los sectores regulados la pregunta clave es: ¿qué concesión es aceptable para la tarea en cuestión?
Visión práctica de los formatos:
- Q8_0 (GGUF): conserva ~98–99 % de la calidad respecto a FP16, pérdida mínima. Para tareas críticas (análisis jurídico, documentación médica) es la opción segura.
- Q4_K_M (GGUF): ~92–95 % de calidad, requisitos de VRAM notablemente menores. El punto óptimo para la mayoría de los casos de uso documentales y RAG. La diferencia respecto a Q8 es difícilmente perceptible en conversación ordinaria.
- AWQ 4-bit: adecuado para GPU NVIDIA, mejor coherencia en salidas largas que GPTQ.
- Q2 e inferior: degradación significativa de la calidad — no recomendado para sectores regulados.
Nota importante: las diferencias de perplejidad entre Q4_K_M y BF16 se sitúan por debajo del 6 % en la mayoría de los benchmarks. Eso no significa que toda tarea sea igualmente resistente — el razonamiento multi-paso complejo y la extracción precisa de información estructurada pueden ser más sensibles. Antes de cualquier despliegue en producción, valida siempre el modelo con una muestra de datos reales de tu dominio.
4. Capa de datos y RAG
Para la mayoría de los casos de uso en sectores regulados el modelo solo no basta — necesitas conectarlo a documentación interna, normativa e historial de casos. Aquí es donde entra el RAG (Retrieval-Augmented Generation).
Componentes clave:
- Base de datos vectorial desplegada localmente:
Qdrant(open-source, backend en Rust, empresa europea GDPR-friendly),pgvector(extensión de PostgreSQL, sencillo si ya tienes PG) oMilvus. - Modelo de embeddings en local:
BGE-M3(BAAI) cubre varios idiomas europeos y tipos de retrieval en un único modelo. Funciona en local, sin cloud. - Chunking y metadatos: para historiales clínicos o documentos jurídicos, el chunking estructurado según unidades lógicas (artículo, párrafo, caso) es notablemente superior a la división naïve por N tokens.
El tamaño de la ventana de contexto de los modelos modernos (1M+ tokens) es tentador, pero no sustituye al RAG en un sistema en producción. La KV cache para un contexto de 1M ocupa decenas de GB de VRAM adicionales y la latencia del TTFT crece drásticamente. Para la mayoría de los casos de uso documentales, el enfoque híbrido (retrieval + contexto corto) es mejor tanto económicamente como en rendimiento.
5. Auditoría, controles de acceso y monitorización
Esta es la capa que los equipos técnicos postergan con más frecuencia — y precisamente en la que los reguladores insisten.
Requisitos mínimos para un LLM on-premise en entorno regulado:
- Logs de auditoría de cada solicitud: quién preguntó, cuándo, cuál fue el prompt (o su hash), cuál fue la salida (o su hash), qué versión del modelo respondió. Los logs deben ser tamper-evident (almacenamiento write-once o con firma).
- Control de acceso por roles: el médico ve los registros de sus pacientes, no los de todo el hospital. El endpoint LLM debe respetar las mismas reglas ACL que el resto del sistema.
- Cifrado en reposo y en tránsito: pesos del modelo, base de datos vectorial, logs — todo cifrado. TLS para todas las comunicaciones internas.
- Aislamiento de red: el servidor de inferencia LLM no debería tener acceso directo a internet. Air-gap o firewall de salida mínimo para el nodo de serving.
- Pinning de versión del modelo: en sectores regulados debes poder decir con qué modelo se tomó una decisión — incluso un año después. El versionado de pesos y la reproducibilidad determinista son requisitos de auditoría.
Hardware — qué necesitas realmente
El LLM on-premise no es una solución barata. Es una inversión que tiene sentido donde la alternativa (sobrecarga de compliance en cloud, seguro de riesgo de fuga, multa) resulta más cara.
Para orientarse en 2026:
- Entry level (modelo 7–13B, 1–5 usuarios concurrentes): una NVIDIA RTX 4090 (24 GB de VRAM) o A4000 (16 GB de VRAM). Para un 13B en Q4_K_M es suficiente; para un 13B en Q8_0 necesitas o bien dual-GPU o bien una 4090.
- Mid tier (modelo 34B o 70B en Q4_K_M, 5–20 usuarios concurrentes): dos A5000 (24 GB × 2 = 48 GB), una A6000 (48 GB) o la ruta consumer — dos RTX 4090 en tensor parallelism vía NVLink/PCIe.
- Production tier (70B en Q8_0 o superior, 20+ usuarios concurrentes): A100 80 GB o H100 80 GB. Con una H100 puedes servir cómodamente un 70B Q8_0 con latencia razonable.
- Alternativa Apple Silicon: M4 Ultra / M5 Ultra con memoria unificada de 128–192 GB es una opción on-premise viable para 70B FP16 donde la prioridad es una sala de servidores silenciosa y bajo consumo. El throughput es inferior al de la H100, pero para un despliegue interno con bajo concurrency puede ser suficiente.
No olvides la RAM del servidor — con CPU offloading (cuando la VRAM de la GPU no basta) parte del modelo se ejecuta en RAM. Para un despliegue en producción con offloading necesitas al menos 128 GB de RAM.
Lo que el LLM on-premise no es
Probablemente el error más frecuente en el proceso de decisión: el LLM on-premise no equivale automáticamente a compliance. Hemos visto organizaciones que instalaron Ollama en una workstation y afirmaban con convicción que eran GDPR compliant porque «la IA funciona en local».
La compliance es un proceso, no un estado de instalación. A la infraestructura on-premise debes añadir:
- Un análisis formal de riesgos y una DPIA (Data Protection Impact Assessment) si tratas datos personales sensibles
- Registros de actividades de tratamiento que incluyan el sistema LLM
- Reglas de retención — durante cuánto tiempo conservas los logs de auditoría y quién tiene acceso
- Un plan de respuesta a incidentes — si se produce una brecha de seguridad, qué ocurre con los logs y quién notifica al regulador
- Pruebas de penetración periódicas de los endpoints de inferencia
Los equipos técnicos que resuelven esto solos sin aportación jurídica suelen producir un sistema que funciona técnicamente pero falla en la auditoría de compliance por la documentación de procesos.
Comparativa: on-premise vs sovereign cloud vs cloud clásico
Para los sectores regulados existen en realidad tres variantes, no dos:
- Cloud API clásico (OpenAI, Anthropic, Google): la menor sobrecarga, el mayor rendimiento, pero el data egress es real. Adecuado para casos de uso donde no se trabaja con PII sensibles ni datos cubiertos por regulaciones sectoriales.
- Sovereign cloud / región UE (Azure OpenAI EU, Anthropic Sovereign EU, OVH AI): los datos permanecen en la UE, el proveedor está vinculado por contratos europeos, el precio es mayor. Para muchas organizaciones este es un mejor compromiso que el full on-premise — menor inversión en hardware, mayor rendimiento de los modelos, manteniendo el marco GDPR.
- Full on-premise / air-gap: sin data egress, control total, auditabilidad en el sentido más estricto. Requiere inversión en hardware, operación propia y stack de seguridad propio. La única opción para las regulaciones más estrictas (por ejemplo, procesadores de información clasificada, ciertos tipos de datos sanitarios).
Para la mayoría de las empresas SK/UE en sectores regulados, el sovereign cloud combinado con on-premise selectivo para los workloads más sensibles es el camino pragmático. No todas las tareas LLM deben ejecutarse on-premise — solo aquellas donde los datos lo exigen.
Guardrails y seguridad del modelo
El despliegue on-premise resuelve el data egress externo, pero no los riesgos internos. El modelo puede alucinar, producir contenido médico o jurídico engañoso o ser explotado mediante prompt injection.
Para los sectores regulados son imprescindibles:
- Validación de la salida: la salida del LLM debe pasar por una capa de validación antes de mostrarse o procesarse. Para salidas estructuradas (extracción de datos de documentos, clasificación) usa decodificación con restricciones (backend
XGrammarenvLLMoSGLang). - Human-in-the-loop para decisiones críticas: ningún modelo on-premise debería firmar automáticamente recomendaciones sanitarias, aprobar créditos ni generar documentos jurídicamente vinculantes sin revisión humana. Más sobre esto en el artículo sobre human-in-the-loop para agentes.
- Monitorización de salidas: seguimiento de rechazos, patrones inusuales en los prompts e intentos de extracción del prompt del sistema o del contexto.
Preguntas frecuentes
¿Es el LLM on-premise siempre más caro que el cloud?
Con un volumen bajo de llamadas (hasta unos pocos miles de solicitudes diarias) la API cloud es más barata — no necesitas invertir en GPU. Con un volumen alto las curvas se cruzan: un servidor GPU propio se amortiza típicamente en 1–2 años con una carga media. Para los sectores regulados, sin embargo, el coste no es el factor principal — la cuestión es qué puede permitirse tu organización desde el punto de vista del compliance.
¿Qué VRAM de GPU necesito para un uso empresarial habitual?
Para la mayoría de los casos de uso empresariales (análisis documental, copiloto interno, clasificación) un modelo 7–13B con cuantización Q4_K_M es suficiente. Para eso basta con una NVIDIA RTX 4090 (24 GB) o A5000 (24 GB). Si quieres un modelo mayor (34B o 70B) para análisis jurídicos o médicos más exigentes, cuenta con dual-GPU o una tarjeta profesional con 48–80 GB de VRAM.
¿Necesito ISO 27001 u otra certificación para que el LLM on-premise sea legal?
No directamente — ni el GDPR ni las regulaciones sectoriales exigen certificaciones concretas, pero sí exigen «medidas técnicas y organizativas adecuadas». ISO 27001 es la práctica que demuestra que has gestionado los riesgos de forma sistemática — simplifica notablemente la auditoría de compliance y cada vez más socios comerciales la exigen.
¿Puedo usar un modelo open-weight comercialmente sin riesgos legales?
Depende de la licencia. Apache 2.0 y MIT son plenamente utilizables con fines comerciales sin restricciones. La licencia Meta Llama permite el uso comercial, pero con más de 700 millones de usuarios activos requiere un permiso especial — en un despliegue interno enterprise esto no es relevante. Consulta siempre el texto vigente de la licencia al elegir el modelo.
¿Cómo me aseguro de que el modelo no retiene ni transfiere datos de la empresa?
En un despliegue local el modelo en sí no persiste datos — un LLM es un conjunto estático de pesos, no una base de datos. El riesgo está en las capas periféricas: logs del framework de serving, KV cache en disco (si está habilitada), ventana de contexto compartida entre sesiones con una configuración incorrecta. Asegúrate de que el motor de serving esté configurado sin compartir contexto entre sesiones, que los logs estén desactivados o cifrados y que el offload de la KV cache a disco esté deshabilitado o se realice en un volumen cifrado.
*Si estás valorando un LLM on-premise para sanidad, finanzas o derecho y no sabes por dónde empezar, estaremos encantados de analizar tu situación en concreto. Ayudamos con la selección de hardware, la arquitectura del serving stack y lo que deberás mostrar al equipo de compliance. Contáctanos y comenzamos con una evaluación de tus requisitos reales.*