Si tu empresa maneja historiales clínicos, contratos jurídicos, expedientes fiscales o cualquier dato regulado, la pregunta ya no es "¿podemos usar IA?", sino "¿podemos usarla sin que un solo token salga de la UE?". En 2026, la respuesta es sí, y no requiere construir un data center propio: basta con un servidor bien dimensionado, modelos open-weight maduros y una arquitectura sensata. Esta es la guía técnica que necesitas si eres CTO, arquitecto o DPO y tienes que decidir si tu próxima integración de IA va a una API americana o a un rack en Madrid, Frankfurt o Asturias.
Por qué la soberanía de datos ya no es opcional
Tres factores convergen en 2026 para que el despliegue on-premise haya pasado de "exótico" a "predeterminado en sectores regulados":
RGPD y Schrems II/III. En 2020 el TJUE invalidó el Privacy Shield (Schrems II). En julio de 2023 la Comisión Europea aprobó el EU-U.S. Data Privacy Framework como sucesor, pero esa decisión está recurrida ante el TJUE (caso pendiente conocido como Schrems III), por lo que la base jurídica de transferencias a EE.UU. sigue sin estar zanjada. Si tu DPO tiene que firmar una transferencia internacional cada vez que un usuario consulta el chatbot, el coste de cumplimiento se come el ahorro de la API.
El AI Act europeo. Aplicable desde febrero 2025 (prohibiciones), agosto 2025 (modelos de propósito general), y agosto 2026 (sistemas de alto riesgo del Anexo III), clasifica los sistemas de IA por riesgo. Para sistemas de alto riesgo (RR.HH., crédito, sanidad, educación, justicia) impone trazabilidad, supervisión humana, gestión de datos y registro técnico. Demostrar que controlas el modelo, los pesos, el pipeline y los logs es trivial cuando corre en tu hardware; complicado cuando depende de una API que cambia versión sin avisar.
Sectores regulados con normativa específica. Sanidad (Ley 41/2002, criterios AEPD para datos de salud), abogacía (secreto profesional ex art. 542.3 LOPJ), banca (DORA, EBA Guidelines), administración pública (ENS Alto). Todos imponen restricciones explícitas o implícitas que hacen inviable enviar el dato sensible a un proveedor cloud no europeo.
A esto se suma un factor comercial: en las RFPs corporativas de 2026 aparece "¿procesa el sistema datos fuera de la UE?" como criterio eliminatorio. Responder "no, todo se queda en nuestro servidor" se ha convertido en argumento de venta.
El estado del arte de los LLMs open-weight en 2026
Lo que ha cambiado el panorama es que ya no es 2023. Los modelos open-weight que puedes descargar y servir en tu infraestructura son lo bastante buenos para la inmensa mayoría de casos empresariales. La brecha frente a los modelos propietarios punteros existe, pero se ha estrechado en las tareas que importan: extracción estructurada, RAG sobre documentación, redacción asistida, clasificación, resumen.
Las familias relevantes:
- Llama 4 (Meta). Cuarta generación con arquitectura mixture-of-experts en toda la familia, incluido Llama 4 Scout (la variante más compacta, pero igualmente MoE). Licencia comercial permitida con condiciones; revisa los términos.
- Llama 3.x (Meta). La referencia para producción conservadora. Llama 3.1 8B es el caballo de batalla para empezar: cabe con margen razonable en una GPU de gama media para contextos cortos. Llama 3.3 70B compite con modelos cerrados en muchas tareas y corre en una sola H100 con cuantización Q4 (4 bits).
- Mistral Small y Mistral Medium. Mistral, empresa francesa: proximidad regulatoria europea y excelente relación calidad/parámetros.
- Qwen 2.5 (Alibaba). Familia muy completa (de 0.5B a 72B), fuerte en multilingüe y código. Comunidad activa.
- DeepSeek V3. MoE con activación esparsa: solo una fracción de parámetros se activa por token, lo que reduce cómputo y latencia. Pero la VRAM total no baja: los pesos de todos los expertos deben residir en memoria igualmente. Usado para razonamiento.
- Phi (Microsoft). Modelos pequeños para tareas específicas. Phi-3.5 y Phi-4 corren incluso en CPU o edge.
Para embeddings (lo necesitarás para RAG) están maduros BGE, e5-multilingual y las variantes multilingüe de Qwen-Embed. Todos se sirven con la misma infraestructura que el LLM.
Arquitectura típica de una IA on-premise empresarial
El stack que recomendamos en Lin-ia tiene cuatro capas. Ninguna es exótica; piezas estándar combinadas con criterio.
Capa 1: servidor de inferencia LLM. Las opciones serias en 2026 son vLLM (alto throughput, batching dinámico, paged attention, ideal para producción con concurrencia), TGI (Hugging Face Text Generation Inference; excelente soporte de modelos HF, métricas nativas y streaming) y llama.cpp (eficiente en CPU/GPU consumer, soporte gguf, ideal para hardware modesto o edge). Ollama es un wrapper sobre llama.cpp cómodo para prototipos, pero en producción seria con varios usuarios concurrentes vLLM o TGI ganan sin discusión. Los tres exponen una API compatible con OpenAI: puedes apuntar tu código existente sin reescribir nada.
Capa 2: vector database. Necesaria para RAG (Retrieval Augmented Generation), que es lo que querrás el 80% de las veces:
- PGVector, extensión de PostgreSQL. Si ya tienes Postgres, esta es la opción evidente: una sola base de datos para metadatos, embeddings y transaccional. Hasta varios millones de vectores rinde de sobra.
- Qdrant, en Rust, alto rendimiento, filtrado avanzado por payload. La opción potente con decenas de millones de vectores o filtros complejos.
- Chroma, ligera, fácil de empotrar. Buena para POCs; en producción seria suele migrarse.
- Weaviate si necesitas búsqueda híbrida (BM25 + vectorial) lista de fábrica.
Capa 3: capa API y orquestación. Aquí viven la lógica de negocio, control de acceso, rate limiting, auditoría y el pipeline RAG (chunking, recuperación, re-ranking, prompt assembly). FastAPI en Python es el estándar: ligero, async, tipado con Pydantic, OpenAPI automático. LlamaIndex y LangChain ofrecen abstracciones para RAG; LlamaIndex suele ser más limpio para RAG puro, LangChain más extenso para agentes y flujos complejos. Observación honesta: ambos rompen APIs con frecuencia; en proyectos críticos preferimos componer con sus piezas (loaders, splitters, retrievers) sin atarnos al framework completo.
Capa 4: frontend o integración. Una UI en React si es conversacional, o un consumidor de la API interna si se integra en ERP, CRM o gestor documental. Un beneficio operativo: la latencia de red es despreciable cuando el LLM está en el mismo rack.
Encima de las cuatro capas: observabilidad y trazabilidad. Logs estructurados, métricas Prometheus, tracing OpenTelemetry. El AI Act exige registros técnicos durante años para sistemas de alto riesgo; planifícalo desde el día uno.
Hardware real, sin hype
Aquí es donde más mentiras circulan. Vamos a ser concretos sin inventar números: lo importante es que entiendas el orden de magnitud y dónde están los puntos de inflexión.
La regla de oro para estimar VRAM de un modelo denso es: parámetros × bytes-por-parámetro + overhead de KV cache y activaciones. En FP16 cada parámetro ocupa 2 bytes; en INT8 un byte; en cuantizaciones de 4 bits (Q4) aproximadamente medio byte. Por eso, un modelo de 8B parámetros en Q4 cabe con margen razonable en una GPU de 8 GB para contextos cortos y un 70B en Q4 ronda los 40 GB de pesos (sin contar KV cache de contextos largos).
| Modelo | Cuantización | VRAM aproximada (solo pesos) | Hardware típico |
|---|---|---|---|
| Phi-3.5 / Llama 3.1 8B | Q4 | en torno a 5-6 GB | RTX 4060 / 4070 |
| Llama 3.1 8B | FP16 | en torno a 16 GB | RTX 4090 / RTX 5080 |
| Mistral Small / 24B | Q4 | en torno a 14-16 GB | RTX 4090 / RTX 5090 |
| Llama 3.3 70B | Q4 | en torno a 40 GB | H100 80 GB / 2× RTX 5090 |
| Llama 3.3 70B | FP16 | superior a 140 GB | 2× H100 / clúster |
| DeepSeek V3 (MoE) | Q4 | ≥ 350 GB (todos los expertos en VRAM); requiere clúster multi-GPU | clúster multi-GPU |
Tres puntos que el hype suele esconder:
- El KV cache crece con el contexto. Con ventanas de 32k–128k tokens en producción, el KV cache suma varios GB por petición concurrente. El throughput con muchos usuarios simultáneos cae rápido si no lo dimensionas.
- Throughput real vs batch size. Una GPU sirviendo a un único usuario es más rápida por petición pero desperdicia silicio. vLLM con batching dinámico aprovecha la GPU con concurrencia: ahí empieza a tener sentido la economía.
- Latencia first-token. En interfaz conversacional el time-to-first-token importa más que el throughput agregado. Modelos pequeños bien optimizados dan respuestas más fluidas que modelos enormes mal servidos.
Para una pyme que arranca, una caja con una RTX 5090 sirviendo Llama 3.1 8B o Mistral Small cubre varias decenas de usuarios concurrentes con calidad muy aceptable para RAG, clasificación, extracción y redacción asistida. Cuando el caso exige modelos del rango 70B, hablamos de inversión en H100 o cluster, y entra la conversación real de "¿compensa frente a una API?".
Cloud vs on-premise: comparativa cualitativa honesta
| Dimensión | Cloud (API propietaria, p. ej. GPT-5, Claude) | On-premise (LLM local) |
|---|---|---|
| Privacidad | Datos salen de tu perímetro; depende de DPA y jurisdicción | Datos nunca salen del rack; control total |
| Cumplimiento RGPD/AI Act | Cargas legales adicionales (TIA, SCC, evaluaciones) | Más simple si la infra está en la UE |
| Coste con uso bajo o variable | Pay-per-token, escalable a cero | Hardware infrautilizado |
| Coste con uso alto y estable | Crece linealmente con tokens | Amortización del hardware en el tiempo |
| Latencia | Dominada por la red intercontinental | Dominada por la GPU local (suele ser menor) |
| Mantenimiento | Cero: el proveedor opera | Tu equipo opera, parchea, monitoriza |
| Calidad punta | Modelos cerrados frontera (GPT-5, Claude) suelen estar por delante | Open-weight cubre la mayoría de casos, no todos |
| Versionado | Cambia bajo tu pies; depreciaciones | Tú decides cuándo actualizar |
| Vendor lock-in | Alto | Mínimo (estándares abiertos) |
La conclusión sensata no es "uno u otro": es arquitectura híbrida con criterio. Datos sensibles y carga predecible al modelo local; tareas no sensibles que requieren máxima calidad o capacidades exclusivas (multimodal avanzado, razonamiento de frontera) a la API cuando proceda, con anonimización previa.
Cuándo compensa on-premise y cuándo no
Compensa cuando se cumplen varios de estos puntos:
- Procesas datos personales sensibles, secretos profesionales o clasificados.
- Operas en sector regulado donde la transferencia internacional añade cargas operativas significativas.
- Tienes carga predecible y sostenida (chatbots internos, RAG sobre documentación corporativa, clasificación de tickets, extracción de datos en flujo continuo).
- Tu equipo tiene capacidad DevOps real (no necesariamente un MLOps senior, pero alguien que sepa Docker, monitorización y mantener un servicio Linux con GPU).
- Tu modelo de negocio se beneficia de poder afirmar contractualmente que el dato no sale de la UE.
No compensa cuando:
- Tu volumen de uso es bajo o muy errático: un par de consultas al día no justifican el hardware.
- No tienes ningún perfil técnico que mantenga la infraestructura. La IA on-premise no es "instalar y olvidar"; necesita actualizaciones de seguridad, monitorización y actualizaciones del modelo.
- Tu caso de uso requiere objetivamente capacidades de los modelos frontera (razonamiento muy complejo, agentes con tool-use sofisticado, multimodal de alta calidad). En 2026 GPT-5, Claude 4.x y los demás modelos frontera siguen estando por delante en estos terrenos. Forzar Llama 3.3 70B donde necesitas un modelo frontera es ahorrar en lo que no se debe.
- Estás en fase de validación de hipótesis. Antes de comprar GPU, valida si la IA aporta valor real con una API. Tenemos artículo dedicado: validar caso de uso de IA en 4 semanas.
Cómo empezar sin sobreinvertir: la senda MVP
El error más caro que vemos: empresas que compran un servidor con dos H100 antes de saber si la IA va a usarse. La senda sensata tiene tres etapas.
Etapa 1: prueba de concepto. Servidor con una RTX 4090 o 5090, Llama 3.1 8B cuantizado, vLLM, PGVector sobre el Postgres que ya tienes. En una semana de trabajo enfocado tienes un RAG funcional sobre tu documentación interna y puedes medir si lo que devuelve es útil. Coste: una caja, no un cluster.
Etapa 2: piloto controlado. Limitas a un grupo de usuarios reales (un departamento, un caso concreto). Mides tres cosas: adopción, calidad percibida (con feedback estructurado) y ahorro de tiempo medible. Si los tres números pintan bien, hay caso de inversión.
Etapa 3: escalado. Ahora sí se justifica subir de modelo (Mistral Small, Llama 70B), añadir GPU, montar HA si el caso es crítico, y refinar el pipeline RAG (re-ranking, hybrid search, eval automatizada). Tu equipo ya sabe cuál es el cuello de botella real y la inversión va dirigida.
Operacional. La actualización de modelos open-weight es continua. Diseña tu capa API para que el modelo concreto sea un detalle intercambiable: contratos de entrada/salida estables, evaluaciones automatizadas contra cualquier modelo candidato, y feature flags para A/B entre producción y candidato.
El elefante en la habitación: seguridad operacional
On-premise no es automáticamente seguro. Hemos visto APIs de LLM expuestas en internet sin autenticación, repos vectoriales con toda la documentación interna accesible y prompts mal saneados que filtran información entre usuarios. Tres reglas mínimas:
- Aislamiento de red. El servidor de inferencia no necesita acceso saliente a internet. Whitelist para clientes internos. Si hay frontend público, va detrás de la capa API, nunca habla directo al motor.
- Aislamiento por tenant. En multitenant, el filtrado de RAG por tenant ID se aplica antes del retriever, en la base vectorial. Confiar en que el LLM "respete el contexto" es invitar a un incidente.
- Logs y auditoría. Inputs y outputs se registran (con cuidado de minimización) para supervisión humana y demostración de cumplimiento.
Cierre: la decisión es de arquitectura, no ideológica
La IA on-premise en 2026 no es postura ideológica ni lujo. Es una decisión de arquitectura que se toma cuando el balance entre soberanía de datos, cumplimiento, coste a medio plazo y calidad disponible inclina la balanza. Para un asesor fiscal con miles de expedientes confidenciales, una clínica con historiales o un bufete con secreto profesional, el cálculo casi siempre da on-premise. Para una startup B2C con tracción incierta, casi siempre da API. Para muchos casos en medio, da arquitectura híbrida con criterio.
Lo que ha cambiado es que la opción on-premise ya no exige montar un equipo de ML interno: con los stacks abiertos maduros (vLLM, LlamaIndex, PGVector, Qdrant) y los modelos open-weight actuales, un equipo de software competente monta un sistema productivo en semanas.
Si estás en el punto de decidir y quieres una segunda opinión informada antes de comprometer presupuesto, en Lin-ia diseñamos e implementamos arquitecturas IA on-premise para empresas españolas. Hablamos primero del caso de uso y después del hardware, no al revés. Escríbenos y montamos una sesión técnica.
Lecturas relacionadas: agentes de IA autónomos en 2026, AI Act europeo: checklist y software a medida vs SaaS vs low-code.