Por Fran Navoz en Hosting, Nicalia, Productos y servicios
17 de agosto de 2026
En la era de la IA, el alojamiento ha dejado de ser un commodity. Cuando un proyecto pasa de la prueba de concepto a producción, tres factores deciden su viabilidad: la soberanía del dato, la seguridad jurídica frente a normativas como el EU AI Act, y el rendimiento real de la infraestructura (GPU y, sobre todo, almacenamiento). Esta guía aborda los tres con rigor técnico y jurídico, y con las fuentes verificadas para que puedas contrastar cada afirmación.
Aviso. Este artículo tiene carácter divulgativo y no constituye asesoramiento legal. Las obligaciones concretas del EU AI Act, el RGPD o el ENS dependen de cada caso; consulta con tu DPO o con asesoría jurídica especializada antes de tomar decisiones de cumplimiento.
El procesamiento secuencial de la CPU se ha quedado corto frente al procesamiento masivamente paralelo de las GPU. Pero hay un cuello de botella que casi nadie menciona: el almacenamiento. Mientras que el entrenamiento de un modelo demanda un throughput secuencial enorme (GB/s), la inferencia —el escenario habitual de un hosting en producción— exige lo contrario: muchísimas operaciones de entrada/salida por segundo (IOPS) y latencias por debajo del milisegundo.
Los discos SATA SSD, pensados para cargas web convencionales, no dan la talla ante la inferencia de modelos con miles de millones de parámetros. La respuesta es el almacenamiento NVMe, y cuando se necesita compartir ese almacenamiento entre nodos, NVMe over Fabrics (NVMe-oF), que mantiene la latencia en el orden de los microsegundos incluso sobre red. En un proyecto de IA, elegir bien el almacenamiento no es un detalle: es lo que separa un chatbot que responde al instante de uno que hace esperar al usuario.
El Reglamento Europeo de IA (Reglamento 2024/1689) es la primera norma integral del mundo sobre inteligencia artificial, y su régimen sancionador ya es aplicable. Aquí conviene precisar las cifras, porque circulan versiones infladas. Según el Artículo 99, las multas se estructuran en tres tramos, aplicándose siempre la cifra más alta entre el importe fijo y el porcentaje de la facturación mundial anual:
Precisión importante: la cifra máxima del reglamento es 35 M€ (no 40 M€), y ese tramo del 7 % se aplica a las prácticas prohibidas, no a cualquier incumplimiento. Para las pymes y startups, además, se aplica la cifra menor de las dos, no la mayor.
El punto que más afecta a quien despliega IA es el artículo 25, sobre responsabilidades a lo largo de la cadena de valor. Establece que un deployer (u otro tercero) pasa a ser considerado proveedor de un sistema de alto riesgo —y asume las obligaciones del artículo 16— en tres supuestos: si pone su nombre o marca sobre el sistema, si realiza una modificación sustancial de un sistema de alto riesgo ya comercializado, o si cambia su finalidad de forma que pase a ser de alto riesgo. En la práctica, un ajuste fino (fine-tuning) profundo de un modelo puede recalificarte como proveedor, con todo lo que eso implica en documentación técnica, gestión de riesgos y evaluación de conformidad.
Y aquí es donde la infraestructura importa: para conservar el control real sobre las versiones y los pesos (weights) de tu modelo —y poder demostrar qué se ha modificado y cuándo—, necesitas un entorno que gobiernes tú, no la “caja negra” de una nube ajena. Alojar modelos de pesos abiertos (open-weight) en servidores dedicados propios te da esa gobernanza.
El enfoque de Nicalia. Ejecutar tus modelos open-weight en servidores dedicados de Nicalia te da control total sobre los parámetros y las versiones, algo difícil de garantizar en el cloud público. Es la base para poder documentar tu cumplimiento del EU AI Act con trazabilidad, en lugar de depender de un proveedor que no controlas.
Existe un mito cómodo: “si mis datos están en un centro de datos europeo de AWS, Azure o Google, están bajo jurisdicción europea”. La realidad jurídica es más incómoda. La CLOUD Act estadounidense (2018) tiene alcance extraterritorial: faculta a las autoridades de EE. UU. a exigir datos a un proveedor estadounidense —o controlado por una matriz estadounidense— con independencia de dónde estén almacenados físicamente, incluidos los centros de datos europeos.
Esto entra en conflicto directo con el Artículo 48 del RGPD, según el cual una orden de una autoridad extranjera no es, por sí sola, base legal suficiente para transferir datos personales de la UE. El Comité Europeo de Protección de Datos (EDPB) y varias autoridades nacionales lo han señalado con claridad. La conclusión que repiten juristas y reguladores es la misma: lo determinante ya no es dónde reside el dato, sino quién controla la infraestructura y a qué jurisdicción está sometido ese operador. Un proveedor con soberanía 100 % española sitúa el dato bajo el marco exclusivo del RGPD, sin la exposición extraterritorial del cloud público estadounidense.
Si tu proyecto de IA presta servicios al sector público español —o aspira a contratar con él—, el Real Decreto 311/2022, que regula el Esquema Nacional de Seguridad (ENS), te afecta directamente. Conviene precisar su alcance: el ENS es obligatorio para el sector público y para los proveedores privados que le prestan servicios (no para cualquier empresa española por el mero hecho de operar en España).
El RD 311/2022 clasifica los sistemas en tres categorías —Básica, Media y Alta— según su impacto en las dimensiones de seguridad (autenticidad, confidencialidad, integridad, disponibilidad y trazabilidad). La exigencia de conformidad escala con la categoría:
| Categoría | Impacto | Conformidad |
|---|---|---|
| Básica | Limitado | Declaración de conformidad (autoevaluación) |
| Media | Significativo | Certificación por entidad acreditada (ENAC) + auditoría periódica |
| Alta | Grave / muy grave | Certificación externa con medidas reforzadas de trazabilidad y protección de registros |
Alcanzar estas exigencias es tanto un proceso organizativo (política de seguridad, auditoría, certificación) como técnico. En el plano técnico, tecnologías de aislamiento como CageFS de CloudLinux —que encierra a cada usuario en su propio sistema de archivos aislado— y la monitorización continua con Imunify360 ayudan a cubrir requisitos de segregación, registro de actividad y protección de los logs.
NOTA: La conformidad ENS certifica un sistema y una organización, no un producto aislado. Las herramientas anteriores apoyan los requisitos de trazabilidad e integridad de registros, pero la categoría Alta se acredita mediante auditoría y certificación externa, no por tener instalada una suite concreta.
Los endpoints de inferencia introducen amenazas nuevas —inyección de prompts, abuso de la API, ataques de saturación— que un plugin de seguridad a nivel de aplicación no está preparado para contener. La defensa debe operar por debajo, en el kernel y en el aislamiento entre inquilinos. El blindaje de CloudLinux con su tecnología LVE (Lightweight Virtual Environment) limita los recursos de cada cuenta para que un proceso de IA descontrolado no asfixie a los vecinos del servidor, mientras que el firewall inteligente de Imunify360 bloquea patrones de ataque antes de que lleguen a la capa de aplicación. Es la misma filosofía de defensa en profundidad que exige cualquier infraestructura seria: parar al atacante en el perímetro, no cuando ya está dentro.
En inferencia de modelos grandes, el silicio importa, y sobre todo importa la memoria. La NVIDIA H200 comparte la arquitectura Hopper de la H100, pero eleva la memoria a 141 GB de HBM3e (frente a los 80 GB de la H100) con un ancho de banda de 4,8 TB/s. Según los benchmarks oficiales de NVIDIA, eso se traduce en una inferencia hasta 1,9× más rápida en Llama 2 70B respecto a la H100 (con TensorRT-LLM en FP8); las pruebas independientes en producción sitúan la mejora real en torno a 1,4×–1,6×. La ventaja aparece en cargas limitadas por memoria: la H200 permite servir un modelo de 70B en una sola GPU donde la H100 necesitaría dos.
La siguiente generación, Blackwell (B200), da un salto tanto en cómputo como en memoria: 192 GB de HBM3e y en torno a 8 TB/s de ancho de banda. NVIDIA proyecta mejoras del orden de varias veces en el throughput de entrenamiento frente a Hopper. Conviene tomar estas cifras como lo que son —proyecciones del fabricante en condiciones controladas—, pendientes de que las validen benchmarks independientes como MLPerf.
Aquí está una de las optimizaciones más infravaloradas. En una arquitectura clásica, los datos que van del almacenamiento a la GPU dan un rodeo: pasan primero por la RAM del sistema a través de un bounce buffer gestionado por la CPU. Ese rodeo añade latencia y consume ciclos de CPU que podrían dedicarse a otra cosa.
La tecnología GPUDirect Storage (GDS) de NVIDIA elimina ese rodeo. Mediante acceso directo a memoria (DMA), los datos viajan directamente desde el almacenamiento NVMe (local o NVMe-oF) a la memoria VRAM de la GPU, sin pasar por la CPU ni por la RAM del sistema. Según la documentación oficial, esto aumenta el ancho de banda del sistema y reduce tanto la latencia como la carga de la CPU. El impacto es especialmente notable al cargar checkpoints y pesos de modelos grandes, aunque la mejora concreta depende mucho de la topología PCIe y del sistema de archivos, por lo que conviene medirla en cada caso.
Sobre el dimensionamiento de checkpoints. Al planificar el entrenamiento importa cuánto solapas el guardado de checkpoints con el cómputo: cuanto mayor sea ese solapamiento, menos tiempo de GPU (y presupuesto) se desperdicia esperando a que se escriban los datos. Es un principio de diseño a optimizar caso por caso, más que una fórmula única.
El futuro del comercio y la gestión web pasa por agentes de IA capaces de consultar y actuar sobre tus sistemas internos. El Model Context Protocol (MCP) es un estándar abierto —impulsado por Anthropic— que define cómo un asistente de IA (como Claude) se conecta de forma estructurada a fuentes de datos y herramientas externas: un ERP como Odoo o Sage, una base de datos, una API interna. La idea es exponer solo lo necesario a través de un puente controlado, en lugar de abrir el núcleo de tu web. Alojar tus sistemas en una infraestructura que soporte MCP permite integrar tus agentes con tu backend de gestión de forma ordenada y auditable.
| Aspecto | Cloud público (matriz de EE. UU.) | Infraestructura soberana en España |
|---|---|---|
| Jurisdicción del dato | Expuesta al CLOUD Act aunque el dato esté en la UE | Bajo marco exclusivo del RGPD |
| Control del modelo | “Caja negra”: versiones y pesos fuera de tu control | Gobernanza total sobre pesos y versiones (open-weight) |
| Cumplimiento ENS | Difícil de encajar para el sector público español | Preparada para los requisitos del RD 311/2022 |
| Latencia a usuarios en España | Depende de la región contratada | IP nacional y baja latencia local |
Un proyecto de IA en producción necesita las dos cosas a la vez: la potencia de cómputo y almacenamiento para que la inferencia sea rentable, y la seguridad jurídica para que no sea un riesgo. Elegir infraestructura soberana en España resuelve el flanco legal (RGPD sin exposición al CLOUD Act, base para el cumplimiento del EU AI Act y del ENS) mientras que una arquitectura de GPU moderna con NVMe de baja latencia y GPUDirect Storage resuelve el flanco técnico.
Si quieres dar el salto de la prueba de concepto a producción sobre una base soberana y de alto rendimiento, contacta con nuestro dept. de ventas
Fran Navoz
