IA soberana y despliegue de LLM on-premise en España
[ En corto ]
Una IA soberana es la que se ejecuta en infraestructura controlada por la propia organización, con modelos abiertos desplegados on-premise en lugar de servicios de terceros. Es el único camino que elimina la transferencia internacional de datos en vez de gestionarla. El proyecto se decide en tres frentes: qué modelo abierto y con qué licencia, qué hardware y qué cuantización lo sostienen, y cómo se integra con autenticación, registro y control de acceso.
Cuándo tiene sentido y cuándo no
On-premise no es mejor por defecto. Es la única opción que elimina la transferencia internacional en lugar de gestionarla, y eso pesa mucho en unos proyectos y nada en otros.
Te compensa si
- Tratas información cuya salida hacia un tercero es un problema legal, no solo una preocupación.
- Tienes un volumen sostenido de uso alto: el punto de equilibrio frente a una API depende del volumen sostenido, no del pico.
- Necesitas que el modelo trabaje con documentación interna sin que esa documentación salga de tu infraestructura.
- Operas en sector público o en un sistema bajo ENS, donde el control del dato es parte de lo que se audita.
- Quieres adaptar un modelo a tu dominio y conservar el resultado como activo propio.
Probablemente no te compensa si
- Tu uso es ocasional o exploratorio: por debajo de cierto volumen, la API es más barata y mucho más rápida de poner en marcha.
- No tienes quien opere la infraestructura después: un modelo desplegado y desatendido se degrada como cualquier otro sistema.
- Lo que necesitas es la máxima capacidad disponible en cada momento: los modelos abiertos que caben en hardware propio no siempre igualan al mayor modelo comercial del trimestre.
Cómo se despliega, en seis pasos
La parte difícil casi nunca es levantar el modelo. Es operarlo con las garantías de un sistema corporativo: quién entra, qué pregunta y qué queda registrado.
Definir el caso de uso y su tolerancia al error
El caso de uso determina el tamaño de modelo necesario, y el tamaño determina el hardware y el coste. Empezar por «queremos un LLM propio» sin un caso concreto lleva a dimensionar por el peor escenario imaginable y a un presupuesto que no se aprueba.
Elegir modelo y licencia
No todas las licencias de los modelos llamados abiertos permiten uso comercial sin condiciones. La elección se hace mirando a la vez la calidad en español, el tamaño y lo que la licencia permite hacer con el modelo adaptado.
Decidir hardware y cuantización
La cuantización es lo que hace que un modelo quepa en el hardware disponible, a cambio de algo de calidad. Es una decisión medible: se prueba el modelo cuantizado contra el caso de uso real antes de comprar nada, no después.
Montar la capa de servicio
Autenticación, control de acceso por usuario o por grupo, cuotas y registro de cada petición. Es lo que convierte un modelo corriendo en un servidor en un sistema corporativo del que se puede responder ante una auditoría.
Integrar con los sistemas existentes
La integración con gestión documental, ERP o CRM es donde el proyecto empieza a producir valor, y también donde aparecen los permisos: lo que el modelo puede leer tiene que depender de quién pregunta, no de qué se indexó.
Medir y mantener
Calidad de las respuestas frente al caso de uso, coste real por consulta y uso efectivo. Sin medición no hay forma de saber si compensa frente a la alternativa en nube, que es exactamente la pregunta que hará dirección al año siguiente.
Lo que casi nadie te cuenta
Comparar coste de API contra coste de hardware
La comparación honesta incluye la operación: quién actualiza, quién vigila, quién responde cuando falla un domingo. Muchos cálculos que hacen ganar al on-premise dejan fuera justo la partida que lo encarece.
Creer que «modelo abierto» significa «sin condiciones»
Las licencias varían mucho y algunas restringen el uso comercial o imponen obligaciones sobre el modelo derivado. Es una comprobación de media hora que evita descubrirlo cuando el proyecto ya está en producción.
Dimensionar por el pico y no por el uso sostenido
El punto de equilibrio frente a una API depende del volumen sostenido de tokens. Dimensionar para el peor día del año deja hardware caro parado el resto del tiempo.
Indexar sin permisos y arreglarlo después
Si el índice no lleva los permisos del origen, filtrar la respuesta al final no basta: el sistema ya ha decidido qué recuperar. Esto se diseña al principio o se rehace entero.
Confundir soberanía con residencia de datos
Que el dato se procese en un centro europeo no es lo mismo que que el proveedor no pueda acceder a él. Solo el despliegue en infraestructura propia elimina la transferencia; el resto la gestiona con garantías de distinto peso.
Los cuatro caminos, y qué soberanía da cada uno
«IA soberana» se usa para cosas muy distintas. Estos son los cuatro caminos reales, ordenados de más a menos control, con lo que cada uno resuelve de verdad.
| Camino | Dónde se procesa | Transferencia internacional | Cuándo tiene sentido |
|---|---|---|---|
| Modelo abierto en infraestructura propia | En tus servidores, bajo tu control. | Eliminada: el dato no sale. | Confidencialidad exigible por ley o por contrato, y volumen sostenido alto. |
| Modelo abierto en nube europea | En un proveedor de nube con región europea. | Gestionada: el dato sale de tu red pero no de la UE. | Quieres control del modelo sin operar hardware propio. |
| Proveedor europeo de modelos | En la infraestructura del proveedor, dentro de la UE. | Gestionada, con el proveedor como encargado del tratamiento. | Prima la rapidez de puesta en marcha sobre el control del modelo. |
| Proveedor estadounidense con garantías | En la infraestructura del proveedor, con residencia contratada. | Gestionada mediante garantías contractuales del capítulo V del RGPD. | El caso de uso no trata información sensible y prima la capacidad. |
Cómo lo abordamos en Montevive
Probamos antes de dimensionar
El modelo cuantizado se evalúa contra el caso de uso real antes de decidir hardware. Es la única forma de saber si el tamaño que cabe en el presupuesto resuelve el problema, y evita el proyecto que compra primero y descubre después que necesitaba el doble.
Trabajamos sobre modelos abiertos, también los de aquí
Publicamos trabajo técnico propio sobre ALIA, la familia de modelos abiertos impulsada por el Gobierno de España y desarrollada en el Barcelona Supercomputing Center: su tokenizador y la eficiencia del español, la cuantización y la construcción de agentes conectados a sistemas de gestión.
La capa de servicio es parte del proyecto, no un extra
Autenticación, control de acceso, cuotas y registro entran desde el principio. Un modelo sin esa capa no es un sistema corporativo: es un servicio interno del que no se puede responder cuando alguien pregunta qué se consultó y quién lo hizo.
Lo que nos preguntan sobre la IA soberana
Las preguntas que nos llegan antes de empezar, respondidas sin rodeos.
Tres decisiones marcan el proyecto: qué modelo abierto se usa y con qué licencia; qué hardware y qué cuantización lo sostienen dentro del presupuesto; y cómo se integra con los sistemas existentes mediante una capa de servicio con autenticación, registro y control de acceso. La parte difícil casi nunca es levantar el modelo, sino operarlo con las garantías de un sistema corporativo.
ALIA es la familia de modelos de lenguaje abiertos impulsada por el Gobierno de España y desarrollada en el Barcelona Supercomputing Center, entrenada con un peso alto del español y de las lenguas cooficiales. Su interés para una empresa está en que puede desplegarse en infraestructura propia y adaptarse sin enviar datos a terceros. [Enlazar aquí los artículos propios sobre función calling, tokenizador y cuantización.]
Cuatro caminos, con distinto grado de soberanía: modelos abiertos desplegados en infraestructura propia; modelos abiertos en nube europea; proveedores europeos de modelos con procesamiento en la UE; y proveedores estadounidenses con garantías contractuales y residencia de datos en Europa. Solo el primero elimina la transferencia internacional; los demás la gestionan.
Depende del tamaño del modelo y de la cuantización elegida, y esa relación es justo lo que casi nadie publica en español. [Insertar la tabla propia modelo abierto → VRAM necesaria por nivel de cuantización, con la nota metodológica de cómo se midió. Es el bloque con más probabilidad de ser citado de toda la página.]
El punto de equilibrio depende del volumen sostenido de tokens, no del pico. Por debajo de cierto uso, la API sale más barata y más rápida de poner en marcha. A partir de ahí pesan la amortización del hardware, el coste de operación y, sobre todo, los requisitos de confidencialidad: hay proyectos donde on-premise no es una decisión de coste sino de viabilidad legal.
El riesgo que no ves, y la oportunidad que aún no aprovechas
Respondemos en menos de 24 horas.
Pide tu diagnóstico
Responderemos en menos de 24h.