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: basta con un servidor bien dimensionado, modelos open-weight maduros y una arquitectura sensata. Esta es la guía 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.
Si Schrems III invalida el Data Privacy Framework, las empresas que apoyaron su cumplimiento en transferencias a EE.UU. tendrán que rehacer su análisis legal a contrarreloj. La opción on-premise inmuniza el caso de uso frente a ese riesgo regulatorio sobrevenido.
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 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 "¿procesa el sistema datos fuera de la UE?" aparece 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
Ya no es 2023: los modelos open-weight son lo bastante buenos para la mayoría de casos empresariales. La brecha frente a los 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. Licencia comercial permitida con condiciones.
- Llama 3.x (Meta). La referencia para producción conservadora. Llama 3.1 8B es el caballo de batalla para empezar; Llama 3.3 70B compite con modelos cerrados y corre en una sola H100 con Q4.
- Mistral Small y Mistral Medium. Empresa francesa: proximidad regulatoria europea y excelente relación calidad/parámetros.
- Qwen 2.5 (Alibaba). Familia muy completa (0.5B a 72B), fuerte en multilingüe y código.
- DeepSeek V3. MoE con activación esparsa: solo una fracción de parámetros se activa por token, pero la VRAM total no baja porque todos los expertos deben residir en memoria. 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 (necesarios 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 y streaming) y llama.cpp (eficiente en CPU/GPU consumer, soporte gguf, ideal para hardware modesto). Ollama es un wrapper cómodo para prototipos, pero en producción con varios usuarios concurrentes vLLM o TGI ganan sin discusión. Los tres exponen una API compatible con OpenAI: apuntas 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 lógica de negocio, control de acceso, rate limiting, auditoría y el pipeline RAG (chunking, recuperación, re-ranking, prompt assembly). FastAPI es el estándar: ligero, async, tipado con Pydantic, OpenAPI automático. LlamaIndex y LangChain ofrecen abstracciones para RAG; LlamaIndex es más limpio para RAG puro, LangChain más extenso para agentes. Ambos rompen APIs con frecuencia; en proyectos críticos preferimos componer con sus piezas sin atarnos al framework.
Capa 4: frontend o integración. UI en React si es conversacional, o consumidor de la API interna si se integra en ERP, CRM o gestor documental. 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 para estimar VRAM de un modelo denso: parámetros × bytes-por-parámetro + overhead de KV cache y activaciones. En FP16 cada parámetro ocupa 2 bytes; en INT8 uno; en Q4 (4 bits) aproximadamente medio. Un 8B en Q4 cabe en una GPU de 8 GB para contextos cortos; un 70B en Q4 ronda 40 GB (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 |
Para la mayoría de despliegues empresariales, la combinación pragmática es Llama 3.1 8B o Mistral Small en cuantización Q4 servidos con vLLM. Pierdes uno o dos puntos de calidad frente a FP16, pero ganas un factor 4× en VRAM y throughput. Solo subes a FP16 si la evaluación demuestra una caída inaceptable en tu caso concreto.
Tres puntos que el hype suele esconder:
- El KV cache crece con el contexto. Con ventanas de 32k–128k tokens en producción, 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.
- Latencia first-token. En interfaz conversacional el time-to-first-token importa más que el throughput agregado.
Para una pyme que arranca, una caja con RTX 5090 sirviendo Llama 3.1 8B o Mistral Small cubre varias decenas de usuarios concurrentes con calidad aceptable para RAG, clasificación, extracción y redacción asistida. Cuando el caso exige modelos del rango 70B, hablamos de 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) |
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".
- 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.
Regla práctica: on-premise compensa cuando concurren al menos dos de estas tres condiciones — datos sujetos a régimen especial (sanidad, banca, secreto profesional), carga sostenida de uso (no esporádica) y un equipo capaz de operar Linux con GPU. Si falta alguna, replantea antes de invertir en hardware.
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 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. Mides tres cosas: adopción, calidad percibida 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 es crítico y refinar el pipeline RAG (re-ranking, hybrid search, eval automatizada). El equipo ya sabe cuál es el cuello de botella real y la inversión va dirigida.
Diseña tu capa API para que el modelo concreto sea intercambiable: contratos de entrada/salida estables, evaluaciones automatizadas 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 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.
Lo que ha cambiado es que la opción on-premise ya no exige 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.
La decisión correcta casi nunca es 100% cloud o 100% on-premise: es arquitectura híbrida con criterio. Datos regulados y carga predecible al modelo local; tareas no sensibles que exijan calidad frontera, a la API con anonimización previa. Lo importante es que la elección sea consciente, no por inercia.
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.
