Vuelve el on-premise: esta vez, por soberanía

En octubre del año pasado, el CEO de Airbnb dijo algo que no debería haber sido controvertido, pero lo fue.

Dijo que la compañía dependía en gran medida del modelo Qwen de Alibaba. Dijo que era bueno, rápido y barato. También dijo que Airbnb usaba los últimos modelos de OpenAI, pero que normalmente no los empleaba tanto en producción.

Una gran empresa estadounidense, ejecutando en silencio parte de su carga de trabajo sobre un modelo chino.

Seis meses después, el Comité de Seguridad Nacional de la Cámara de Representantes envió a Airbnb una carta formal solicitando una justificación de seguridad nacional.

Vista desde fuera, parecía una historia sobre geopolítica.

Por debajo, era algo más práctico.

Era una cuestión de coste. Era una cuestión de control. Y era una decisión que muchas empresas ya están tomando, la describan así o no.

El mercado ya no elige solo entre herramientas. Elige entre bloques de infraestructura.

Está el bloque estadounidense. Está el bloque chino. Y está el bloque europeo.

Cada uno viene con un precio distinto, una exposición legal distinta y un nivel de control distinto.

Por eso vuelve el on-premise.

No porque las empresas quieran regresar a la vieja sala de servidores. No porque la nube haya dejado de funcionar. Y no porque toda carga de trabajo deba volver a las instalaciones propias.

El on-premise vuelve porque la soberanía se ha convertido en un requisito de negocio real.

El bloque estadounidense: capacidad con dependencia

La mayoría de las empresas eligen el bloque estadounidense por defecto, sin pensarlo demasiado.

OpenAI, Anthropic, Google, Microsoft Copilot. Son los nombres que la mayoría de los compradores ya conocen. Están integrados en el correo electrónico, el software de productividad, las herramientas de desarrollo y los flujos de trabajo empresariales.

Este bloque lidera en capacidad. No por un margen abrumador, pero sí de forma medible.

Una evaluación independiente del Centro de Estándares e Innovación en IA de Estados Unidos, parte del NIST, determinó que el modelo V4 Pro de DeepSeek iba unos ocho meses por detrás de la capacidad de frontera.

Ese dato ofrece un marco útil. La brecha es real. Pero no es infinita.

El bloque estadounidense también tiene una filosofía arquitectónica clara. En la frontera, es cerrado.

A los modelos más potentes se suele acceder mediante una API. Se alquila el acceso. No se es propietario de los pesos. No se ejecuta el sistema de forma independiente. Se construye sobre los servidores de otra empresa.

Eso tiene ventajas. Es sencillo empezar. Da acceso a capacidad puntera. Evita el trabajo operativo de alojar el sistema.

Pero también significa que el proveedor mantiene el control del interruptor.

Puede cambiar los precios. Puede descatalogar una versión. Puede restringir un caso de uso. Puede retirar el acceso. Su producto puede residir en la infraestructura del proveedor, pero la capa de control es de ellos.

Esto importa poco cuando la carga de trabajo es experimental.

Importa mucho más cuando la carga de trabajo se vuelve operativa.

En cuanto una empresa coloca la atención al cliente, el trabajo interno de conocimiento, los procesos de cumplimiento normativo, los flujos de trabajo de programación o los pipelines de datos regulados sobre un proveedor externo cerrado, la relación cambia. Ya no es una simple compra de software. Se convierte en dependencia de infraestructura.

El bloque estadounidense es también el más caro de los tres. Los principales modelos estadounidenses pueden costar entre cinco y diez veces más por token de salida que alternativas chinas comparables. En el ejemplo de Airbnb, la diferencia era aún más marcada: Qwen a unos $1,80 por millón de tokens de salida frente a GPT-5.5 a $30 por millón de tokens de salida.

Eso es una proporción de 16:1.

A pequeña escala, esto puede no importar. A escala empresarial, cambia el presupuesto.

Para las empresas europeas, hay otra cuestión: la jurisdicción.

La Cloud Act permite a las autoridades estadounidenses, con una orden judicial, obligar a las empresas con sede en Estados Unidos a entregar los datos que poseen, sin importar dónde estén físicamente almacenados.

Para muchas empresas, eso es aceptable.

Para el sector sanitario, el financiero, los contratistas del sector público o las empresas que gestionan datos europeos regulados, es un problema de compras. La pregunta no es solo dónde se almacenan los datos. La pregunta es quién puede obligar a acceder a ellos.

Ahí es donde vuelve a surgir la conversación sobre el on-premise.

El bloque chino: más barato, abierto y políticamente expuesto

El caso de Airbnb parecía político visto desde fuera. Pero la razón por la que Airbnb usaba Qwen era, sobre todo, económica.

La cuenta es sencilla. Qwen cuesta unos $0,30 por millón de tokens de entrada y $1,80 por millón de tokens de salida. GPT-5.5 cuesta $5 por millón de tokens de entrada y $30 por millón de tokens de salida.

Para una empresa que ejecuta grandes volúmenes de inferencia, esa diferencia no es marginal.

Determina si una capacidad puede incorporarse a cada interacción con el cliente o solo utilizarse en casos seleccionados.

Airbnb no es el único ejemplo.

El modelo Composer 2 de Cursor cuenta una historia parecida. Cursor lo lanzó sin mencionar inicialmente el modelo subyacente. Los desarrolladores encontraron después referencias internas que revelaban una base Kimi K2.5 de Moonshot, un laboratorio chino. El cofundador de Cursor reconoció más tarde que había sido un error no mencionar desde el principio la base Kimi.

Eso importa porque Cursor lo utiliza una gran parte de las empresas del Fortune 500.

Dicho de otro modo, muchas empresas podrían estar ya usando modelos chinos de forma indirecta, a través de productos construidos sobre ellos.

El bloque chino tiene un argumento económico sólido. Es más barato. Mejora rápidamente. A menudo ofrece pesos abiertos. Esos pesos se pueden descargar y ejecutar dentro de la infraestructura propia de una empresa.

Esa es una diferencia importante.

Con una API, el proveedor conserva el control del interruptor. Con pesos abiertos, el comprador puede tomar el control después del lanzamiento. El modelo se puede alojar internamente. Se puede aislar del proveedor público. Puede seguir funcionando incluso si el laboratorio original cambia de estrategia.

Por eso los modelos chinos resultan atractivos para las cargas de trabajo sensibles al coste.

Pero los inconvenientes son reales.

Cuando una empresa utiliza un modelo chino a través de una API pública, el tráfico se enruta hacia China y se aplican las leyes de datos chinas. Muchos usuarios empresariales evitan esto ejecutando pesos abiertos en su propia infraestructura. Eso elimina la exposición directa de datos, pero también implica que la empresa debe encargarse del alojamiento, la operación y el despliegue.

También hay escrutinio geopolítico.

La carta a Airbnb demuestra que incluso las empresas de consumo pueden atraer atención política cuando la escala es lo bastante visible. Para defensa, administración pública, sanidad y otros sectores regulados, el escrutinio puede ser más severo.

El bloque chino no es, por tanto, una respuesta sencilla.

Puede ser la opción creíble más barata. Puede dar a las empresas más control arquitectónico gracias a los pesos abiertos. Pero también conlleva riesgo político y de compras, especialmente para empresas que operan en varias jurisdicciones.

El bloque europeo: ni el más fuerte, ni el más barato, pero alineado

El bloque europeo existe porque los otros dos no resuelven todos los problemas.

El bloque estadounidense aporta capacidad, pero viene con alcance legal estadounidense y dependencia de una infraestructura cerrada.

El bloque chino aporta coste y pesos abiertos, pero viene con exposición geopolítica y preocupaciones sobre los datos en las API públicas.

Para algunas empresas, ninguno de los dos es aceptable.

Ahí es donde el bloque europeo cobra relevancia.

El ecosistema europeo es más pequeño. Francia tiene a Mistral. Alemania tiene a Aleph Alpha y Black Forest Labs. Hay otros actores más pequeños repartidos por el continente. Pero Mistral es el centro de gravedad.

Mistral no es el líder en capacidad. No es el líder en coste.

Su valor es la soberanía.

En términos prácticos, la soberanía significa que los datos se pueden procesar bajo el derecho europeo y almacenar en infraestructura europea. Eso importa a las empresas que gestionan datos de clientes de la UE, que operan en varias jurisdicciones o que quieren opciones que no dependan por completo de proveedores estadounidenses o chinos.

Entre los socios de Mistral están el Ministerio de las Fuerzas Armadas francés, BNP Paribas, ASML, SAP y otros. Sus ingresos crecieron de unos $20 millones a principios de 2025 a $400 millones en febrero de este año.

Ese crecimiento no se debe a que Europa haya superado de repente el gasto de Estados Unidos.

Se debe a que ciertos compradores necesitan alineación jurisdiccional.

Mistral también está invirtiendo en infraestructura, incluidas GPU Nvidia GB300 cerca de París, un centro de datos en Suecia y una alianza con SAP para integrar sistemas soberanos en los servicios de las administraciones públicas europeas.

Este es un juego distinto.

El bloque estadounidense vende capacidad de frontera.

El bloque chino vende eficiencia de coste y acceso abierto.

El bloque europeo vende alineación regulatoria y elección jurisdiccional.

Para una empresa española, un banco, un grupo hospitalario, un proveedor del sector público o una empresa industrial con datos sensibles, esa distinción importa.

La cuestión no es si los proveedores europeos son siempre los más potentes. No lo son.

La cuestión es si la carga de trabajo puede depender, legal, comercial y estratégicamente, de una infraestructura fuera del control europeo.

Por qué vuelve el on-premise

Durante años, el on-premise se trató como la respuesta antigua.

La nube era más sencilla. La nube permitía empezar más rápido. La nube convertía el gasto de capital en gasto operativo. La nube reducía la necesidad de poseer y mantener infraestructura.

Esa lógica sigue siendo válida para muchas cargas de trabajo.

Pero la infraestructura de modelos cambia el cálculo.

Cuando el uso escala de forma lineal con los tokens, el coste se convierte en un problema estructural. Cuando los datos están regulados, la jurisdicción se convierte en un problema estructural. Cuando una empresa depende de un modelo externo cerrado, la arquitectura se convierte en un problema estructural.

El on-premise regresa porque responde a una pregunta distinta.

No: “¿Podemos evitar la nube?”

Sino: “¿Qué cargas de trabajo necesitamos controlar?”

Esa distinción importa.

El on-premise no necesita sustituir a todos los servicios en la nube. No necesita convertirse en una opción universal por defecto. Tiene sentido allí donde el control importa más que la comodidad.

Los casos más claros son los datos regulados, la inferencia de alto volumen, el conocimiento interno sensible, los datos de clientes y las cargas de trabajo en las que la dependencia de un proveedor crearía un riesgo de negocio.

Aquí es también donde encaja la nube soberana.

Para muchas empresas, la decisión no es binaria. No es nube pública frente a sala de servidores. Es un espectro: API externa, nube soberana, nube privada, despliegue on-premise o arquitectura híbrida.

El cambio importante es que las empresas ya no pueden tratar la infraestructura como algo invisible.

El modelo, la ubicación del alojamiento, la jurisdicción legal del proveedor y la capacidad de operar de forma independiente importan todos ellos.

Las seis preguntas que deben hacerse los compradores

Un marco práctico ayuda aquí, porque aleja la conversación de los eslóganes.

Las preguntas son sencillas.

¿Cuánto importa realmente la máxima capacidad para esta carga de trabajo?

Si el trabajo requiere rendimiento de frontera, el bloque estadounidense puede ser difícil de evitar. Pero para la atención al cliente, la automatización interna, el procesamiento de documentos u otros casos de uso operativos de alto volumen, la brecha de capacidad puede importar menos que el coste y el control.

¿Cuán sensible es la carga de trabajo al precio por token?

A bajo volumen, las diferencias de precio pueden pasar inadvertidas. A gran volumen, deciden si el sistema puede desplegarse ampliamente o solo de forma selectiva.

¿Pesos abiertos o pesos cerrados?

El acceso cerrado es más fácil para empezar, pero el proveedor mantiene el control del interruptor. Los pesos abiertos requieren alojamiento, pero dan al comprador más control.

¿Dónde pueden residir legalmente los datos?

Esto no es opcional para los sectores regulados. Los proveedores estadounidenses traen alcance legal de EE. UU. Las API públicas chinas traen exposición a la legislación china. La infraestructura europea da alineación jurisdiccional.

¿Cuán expuesta está la cadena de suministro?

Todos los bloques dependen en gran medida de chips avanzados fabricados por TSMC. Alojar los modelos internamente no elimina todo el riesgo de la cadena de suministro, pero da a las empresas más control sobre la capacidad de cómputo que ya operan.

¿Seguirá siendo el mismo proveedor dentro de tres a cinco años?

Los laboratorios pueden ser adquiridos. La dirección estratégica puede cambiar. Una empresa europea puede acabar integrada en un bloque estadounidense. Un proveedor que hoy parece alineado puede no serlo durante la vida de un contrato largo.

Estas no son preguntas teóricas.

Son preguntas de compras. Preguntas de riesgo. Preguntas de presupuesto. Preguntas de consejo de administración.

La verdadera razón por la que importa la soberanía

La soberanía se suele plantear como una idea política.

Para las empresas, es algo más concreto.

Significa saber dónde se ejecuta la carga de trabajo. Significa saber qué ley se aplica. Significa saber quién puede obligar a acceder a los datos. Significa tener opciones si un proveedor cambia los precios, restringe el acceso o cambia de estrategia.

Por eso vuelve el on-premise.

No porque la nube haya fallado.

Porque la siguiente capa de infraestructura empresarial es demasiado importante como para dejarla por completo fuera del control de la empresa.

Las empresas que entiendan esto pronto no se limitarán a preguntar cuál es el mejor modelo.

Se preguntarán qué arquitectura les da el equilibrio adecuado de capacidad, coste, jurisdicción, resiliencia de la cadena de suministro y propiedad.

Para muchas empresas europeas, la respuesta no será un único bloque.

Será una combinación controlada.

Algunas cargas de trabajo podrán seguir con proveedores estadounidenses. Otras podrán usar modelos de pesos abiertos más baratos. Otras necesitarán infraestructura soberana europea. Otras necesitarán ejecutarse on-premise.

La cuestión no es rechazar un bloque y elegir otro a ciegas.

La cuestión es tomar la decisión de forma deliberada.

El on-premise vuelve porque la propiedad de la infraestructura vuelve a importar.

Y esta vez, es por soberanía.

Cómo podemos ayudar

Decidir qué cargas de trabajo deben permanecer on-premise empieza por saber por dónde circulan realmente sus datos hoy. Nuestra Hoja de Ruta de Automatización, gratuita, mapea sus flujos de datos y los candidatos a automatización, e indica para cada uno si la arquitectura adecuada es la nube, un modelo híbrido o el on-premise, junto con el razonamiento jurisdiccional que lo sustenta.

Para las cargas de trabajo que necesitan ejecutarse bajo su propio control:

• TrustCore — preguntas y respuestas sobre documentos en el propio dispositivo, con citas verificadas. Sin SaaS, sin salida de datos.
• MedCore IA Privada — infraestructura de IA privada y on-premise diseñada para datos sanitarios regulados.
• TrustAuto — automatización de procesos que se ejecuta en su propia infraestructura, con acceso delimitado y registro de auditoría completo.

Sin compromiso. Sin llamada comercial previa.

Solicite su Hoja de Ruta de Automatización gratuita →