IA on-premise vs cloud vs API: dónde alojar la IA de tu empresa según soberanía del dato y RGPD (2026)

Decidir dónde alojar la IA de tu empresa —API pública, cloud privada u on-premise— parece una decisión técnica y en realidad es estratégica. Y se toma mal casi siempre: por miedo, por una frase que alguien soltó en un comité (“si usamos la API, nuestros datos entrenan a OpenAI”), o por copiar lo que hizo una multinacional con un problema que tú no tienes. Se paga caro en las dos direcciones: proyectos de IA on-premise de seis cifras que se resolvían con una API y un contrato bien firmado, o datos sensibles saliendo por donde no debían porque nadie leyó dónde se procesaban de verdad.

En Everglow entramos como implantadora de IA en empresas, y esta conversación aparece en casi todos los proyectos con empresas medianas y grandes españolas. Este post es el marco exacto que usamos para decidirlo sin dogmas: qué opciones hay de verdad, qué exige el RGPD (y qué te estás inventando), cuánto cuesta cada camino en 2026 y cómo elegir según tu caso, no según el susto del comité.

Qué estás decidiendo en realidad (y qué no)

Hay dos decisiones que la gente mezcla y no son la misma:

• Qué modelo usas: GPT, Claude, Gemini, Llama, Mistral. Esa elección tiene su propio criterio y la tratamos aparte.
• Dónde vive y se procesa tu dato cuando ese modelo trabaja. Eso es lo de hoy.

Puedes usar el mismo Llama de 70B en una API pública, en tu propia nube privada dentro de AWS o Azure, o en un servidor bajo tu control físico. El modelo es idéntico. Lo que cambia es quién toca el dato, dónde se procesa y quién responde ante la ley. Esa es la decisión real, y por eso no se resuelve mirando benchmarks de modelos.

Las tres (y media) opciones reales

En 2026, cuando bajas al terreno, solo hay estos caminos:

1. API pública gestionada (OpenAI, Anthropic, Google). Mandas el dato, ellos infieren, te devuelven el resultado. Máxima velocidad de implantación, cero infraestructura, la mejor relación calidad/precio del mercado.
2. Cloud privada, dato en tu tenant (Azure OpenAI, AWS Bedrock, Google Vertex). El modelo corre dentro de tu suscripción cloud, con zonas de datos y residencia configurables. Control alto sin comprar una sola GPU.
3. On-premise / self-hosted. Modelos open source (Llama, Mistral, Qwen) sobre hardware tuyo o nube dedicada bajo tu control. Máximo control y máxima responsabilidad: infraestructura, equipo y factura incluidos.
4. (La media) Sovereign cloud. Para requisitos extremos de soberanía existe desde el 15 de enero de 2026 la AWS European Sovereign Cloud, operada por personal de la UE. Es la excepción, no el punto de partida.

La mayoría de empresas cree que su decisión está entre la 1 y la 3. Casi siempre la respuesta correcta está en la 1 o la 2.

El mito que te está costando dinero

“Si usamos la API, nuestros datos entrenan al modelo y acaban en cualquier sitio.” Es la frase que dispara la mitad de los proyectos on-premise innecesarios. Y, tal cual se dice, es falsa.

Los datos que envías por la API —no por el chat de consumo, que es otra cosa— no se usan para entrenar el modelo por defecto, ni en OpenAI ni en Anthropic. La retención es corta y solo para detección de abuso: Anthropic la bajó a 7 días en septiembre de 2025 y OpenAI mantiene unos 30. Y si tu caso lo exige, existen acuerdos de Zero Data Retention (ZDR) para empresa, bajo los cuales el proveedor no almacena entrada ni salida más allá de procesar la petición.

Usar la API de un proveedor serio con un contrato de encargado del tratamiento y, si hace falta, ZDR, no es “mandar tus datos a que entrenen a la competencia”. Es contratar un encargado del tratamiento, exactamente igual que cuando pusiste tu correo en Microsoft 365 o tu CRM en Salesforce.

El chat público y gratuito sí puede usar tus conversaciones. Por eso el problema real casi nunca es “la API”: es tu plantilla pegando datos de clientes en el ChatGPT gratis desde el móvil. Eso se arregla con una política de uso y cuentas de empresa, no con un cluster de GPUs.

Soberanía del dato y RGPD: qué exige de verdad la ley

Aquí se separan los que han leído el RGPD de los que lo citan de oídas. Tres cosas conviene tenerlas claras antes de gastar un euro:

• Residencia del dato no es lo mismo que lugar de procesamiento. Que tus datos estén “almacenados en la UE” no significa que el modelo se ejecute en la UE. Son dos garantías distintas y hay que pedir ambas por escrito. Azure lo separa con sus Data Zones: la EU Data Zone confina el procesamiento al perímetro de datos europeo (Alemania, Francia, España, Italia, Países Bajos, Suecia, entre otros). AWS Bedrock permite inferencia in-region o cross-region dentro de la UE, con regiones en Fráncfort, Irlanda y París.
• El RGPD no prohíbe la nube ni obliga al on-premise. Permite el tratamiento con garantías (cláusulas contractuales tipo, marcos de transferencia). Lo que exige es que sepas dónde está el dato, con qué base legal y bajo qué encargado. On-premise no es un requisito legal: es una opción entre varias.
• Tu sector puede pedir más que el RGPD. Sanidad, banca, seguros o defensa a veces imponen residencia estricta o soberanía reforzada por contrato o por regulador. Para esos casos está la sovereign cloud. Pero es una minoría de los casos de uso, no el 90% restante.

La pregunta útil no es “¿es seguro?”, que siempre se puede responder con más miedo. Es “¿qué me obliga por escrito mi regulador o mi cliente?”. Todo lo demás es preferencia, y las preferencias no justifican seis cifras.

Cuánto cuesta cada opción (números reales 2026)

El coste es donde el on-premise por miedo se derrumba. Órdenes de magnitud a mediados de 2026:

• API pública: pagas por token, sin infraestructura ni equipo de MLOps. Para la mayoría de casos de empresa —copilotos internos, RAG sobre documentación, automatizaciones de back office— hablamos de decenas o pocos cientos de euros al mes por caso de uso.
• Cloud privada (Azure OpenAI / Bedrock): inferencia gestionada, algo más cara que la API pura, más el coste de tu equipo cloud. Control alto y sin comprar hardware. El punto dulce para empresas con exigencias de residencia.
• On-premise / self-hosted: aquí aparece la factura de verdad. Un modelo de 70B necesita del orden de 4 GPUs H100 (unos 200 GB de VRAM). Alquiladas en cloud, entre 8 y 16 $/hora; compradas, entre 25.000 y 35.000 € por tarjeta —seis cifras solo de entrada— más energía, refrigeración y un equipo que lo mantenga 24/7.

El self-hosting solo sale a cuenta con volumen sostenido muy alto (millones de tokens al día). Por debajo de eso, montar tu propio cluster es pagar por un seguro que no necesitas y contratar a un equipo para vigilarlo.

Cómo decidir: cinco preguntas, en este orden

No empieces por la arquitectura. Empieza por estas cinco preguntas y la arquitectura se decide sola:

1. ¿Qué dato toca el sistema de verdad? Si no hay datos personales ni secretos industriales, casi cualquier opción vale: empieza por la más barata y rápida.
2. ¿Qué te exige tu sector, por escrito? No lo que “sería más seguro”. Lo que un regulador o un cliente te obliga en un contrato firmado.
3. ¿Te basta con residencia UE y un buen contrato de tratamiento? Para el 80% de las empresas, sí: API o cloud privada con data zone europea y ZDR si aplica.
4. ¿Tienes volumen y equipo para operar on-premise? Sin MLOps propio ni volumen sostenido, montar on-premise es comprarte un problema, no resolver uno.
5. ¿El coste extra compra un riesgo real o solo tranquilidad? Pagar seis cifras por dormir mejor, sin una obligación legal detrás, es una mala decisión de negocio disfrazada de prudencia.

El error más caro que vemos

El patrón se repite: dirección se asusta con un titular, alguien propone “hagámoslo todo on-premise para tener el control”, y seis meses después hay un cluster infrautilizado, un proyecto parado y un caso de uso que se resolvía con una API y un anexo de RGPD. En Everglow lo vemos cada trimestre. El miedo es caro. La ignorancia del RGPD, también.

El movimiento inteligente casi siempre es el mismo: empieza por la opción más simple que cumple tu marco legal real, mide, y sube de nivel de control solo cuando un requisito concreto —no un miedo— lo justifique. Casi ninguna empresa mediana española necesita on-premise para su primer, segundo o tercer caso de uso de IA. Necesita empezar bien, con el dato controlado y el contrato firmado.

Cómo lo abordamos en Everglow

En Everglow somos implantadora de IA para empresas: entramos, auditamos qué dato toca cada caso de uso, mapeamos tu obligación legal real —RGPD y sector— y diseñamos la arquitectura de menor coste y menor riesgo que cumple. No la que más impresiona en el comité. A veces es una API con ZDR. A veces es Azure con data zone europea. Y a veces, cuando de verdad toca, es on-premise. Pero lo decidimos con datos, no con miedo, y nos quedamos a medir que funcione en producción, no solo en la demo.

Si estás en esa decisión —o ya montaste algo y sospechas que lo sobredimensionaste—, hablamos. Cuéntanos tu caso en contacto y te decimos, sin humo, qué opción tiene sentido para tu dato, tu sector y tu presupuesto.