Self-host vs. nube: ¿qué solución para banca o sanidad?
El debate “nube u on-premise” lleva activo desde 2010. En los sectores ordinarios la nube ha ganado de forma definitiva: en 2026 sería difícil encontrar una agencia de marketing o un e-commerce que opere sus propios servidores. En sectores regulados (banca, seguros, hospitales, contratación pública), sin embargo, la pregunta sigue viva y por buenos motivos. En este artículo repasaremos el estado actual de la regulación, haremos una comparativa de TCO y mostraremos cuándo conviene realmente el self-host, cuándo la nube y cuándo el híbrido.
Contexto regulatorio: DORA, NIS2, RGPD y normativa sectorial
2026 ha traído al espacio europeo la consolidación de la regulación. Bancos y aseguradoras se rigen por DORA (Digital Operational Resilience Act), las infraestructuras críticas por NIS2, todo el ecosistema de la UE por el RGPD y el Reglamento de IA. Para sanidad se han añadido normas locales del Ministerio de Sanidad y guías sectoriales del Banco de España (BdE) para fintech.
DORA, desde enero de 2025, exige a las entidades financieras un control completo sobre la cadena de suministro TIC. Cualquier proveedor de nube que trate “funciones importantes” debe tener un contrato explícito con derechos de auditoría, plan de salida y resiliencia demostrada frente a caídas. El BdE comprueba periódicamente que el banco pueda demostrar en tiempo real dónde están sus datos, quién ha tenido acceso y cómo se afrontaría una caída de 48 horas del proveedor.
NIS2, desde octubre de 2024, amplía las obligaciones a grandes centros sanitarios, suministradoras de agua, energía y administración pública. Lo clave: respuesta a incidentes en 24 horas, notificación en 72 horas y MFA obligatoria para cuentas de administrador.
RGPD regula la protección de los datos personales. Para los datos sanitarios (art. 9) y la biometría se aplican reglas más estrictas, incluida la obligación de EIPD (Evaluación de Impacto en Protección de Datos) antes del despliegue.
Consejo: Antes de decidir entre nube y self-host, pida al departamento de cumplimiento o al asesor legal una lista escrita de los requisitos regulatorios que su solución TI debe cumplir. Sin esa lista, decidirá por intuición y no por hechos.
La nube: qué significa realmente en un entorno regulado
En el lenguaje cotidiano “nube” significa “en algún lugar de internet”. En el mundo regulado es más matizado. Distinguimos cuatro variantes:
Nube pública: AWS, Azure, Google Cloud. Su aplicación se ejecuta junto a otras miles. Para sectores regulados es aceptable solo en regiones de la UE y al cumplir todas las SCC (Standard Contractual Clauses), las soluciones frente al CLOUD Act y, idealmente, en variantes “sovereign cloud” (Azure EU Data Boundary, AWS European Sovereign Cloud).
Nube privada: infraestructura dedicada en un proveedor cloud, pero solo para usted. Más cara, pero con control total sobre la segmentación de red. Mucho más fácil de defender ante el regulador.
Sovereign cloud: nube bajo jurisdicción UE/ES, sin posibilidad de acceso por parte de autoridades extranjeras (CLOUD Act immune). En España disponible, por ejemplo, a través de proveedores como Telefónica Tech Sovereign Cloud u OVHcloud.
SaaS a nivel de aplicación: Modulario, Salesforce Financial Cloud, Epic (sanidad). El proveedor gestiona infra y aplicación. Es lo más fácil de adoptar, pero exige una cuidadosa due diligence del proveedor.
Para banca y sanidad en 2026 la nube pública es admisible, pero solo a través de la variante sovereign o regional europea con SCC RGPD claras. BBVA, Santander, CaixaBank y Sabadell tienen hoy partes de su infraestructura en Azure UE, pero nunca en regiones de EE. UU.
Self-host: control al precio de la complejidad
Self-host (on-premise) significa que opera la infraestructura usted mismo: sus servidores, su almacén de datos, su equipo, su riesgo. En 2026 el self-host sigue siendo relevante en tres escenarios:
- Reglas sectoriales estrictas. Por ejemplo, determinadas instituciones militares o estratégicamente sensibles donde el regulador exige explícitamente un despliegue air-gapped.
- Volúmenes enormes de datos. Si genera 50 TB de logs al día, la nube le arruina financieramente; un SAN/NAS propio tiene sentido económico.
- Sistemas legacy especializados. Núcleos de banca en mainframe que no se ofrecen en la nube y cuya migración costaría cientos de millones.
Fuera de estos tres escenarios, el self-host en 2026 es difícilmente defendible financiera y operativamente. Razones:
- Escasez crónica de SRE y especialistas en seguridad. Un senior sysadmin con certificaciones y 5 años de experiencia cuesta en España en torno a 4.500 EUR mensuales brutos, y son pocos. Un proveedor de nube tiene miles.
- Operación 24/7. La aplicación bancaria debe estar operativa el 99,99 % del tiempo. Mantenerlo con equipo propio implica un mínimo de 4 personas en rotación: 200.000 EUR anuales en salarios.
- Patching y parches zero-day. En 2025 se publicaron 45.000 CVE. El tiempo de reacción en self-host se mide en días; en un buen proveedor cloud, en horas.
Consejo: El self-host que “parece barato” suele esconder tres partidas: refrigeración, conexión redundante y especialistas de seguridad en rotación 24/7. Si su modelo de TCO no las contempla, la comparación con la nube no es justa.
Comparativa de TCO: cifras reales de 2025
Hemos preparado un modelo de TCO a 5 años para una entidad bancaria regional mediana (capacidad para 50.000 clientes, 250 usuarios internos, 1 TB de datos al mes, requisito de 99,99 % de uptime).
Escenario A: self-host on-premise
| Concepto | Año 1 | Años siguientes |
|---|---|---|
| Hardware (servidores, SAN, red) | 180.000 EUR | Renovación 20 % anual |
| Licencias SO, base de datos, copias | 45.000 EUR | 35.000 EUR/año |
| Centro de datos + refrigeración | 24.000 EUR | 24.000 EUR/año |
| Personal (4 personas, 24/7) | 220.000 EUR | 230.000 EUR/año |
| Auditorías de seguridad | 30.000 EUR | 20.000 EUR/año |
| Certificaciones (ISO 27001) | 50.000 EUR | 15.000 EUR/año |
| Total año 1 | 549.000 EUR | |
| Media anual (5 años) | ~360.000 EUR |
Escenario B: sovereign cloud UE con aplicación SaaS
| Concepto | Año 1 | Años siguientes |
|---|---|---|
| Licencias SaaS (250 usuarios) | 90.000 EUR | 95.000 EUR/año |
| Infra cloud adicional (storage, backup) | 24.000 EUR | 26.000 EUR/año |
| Integraciones y desarrollo propio | 60.000 EUR | 30.000 EUR/año |
| Personal (2 personas, administración) | 130.000 EUR | 135.000 EUR/año |
| Auditorías de seguridad | 20.000 EUR | 15.000 EUR/año |
| Total año 1 | 324.000 EUR | |
| Media anual (5 años) | ~215.000 EUR |
Ahorro de la nube frente al self-host: ~40 % a 5 años, suponiendo que se elija la variante sovereign UE con cumplimiento completo.
Las cifras valen para una entidad mediana. Para una microfintech con 5 empleados, la nube es 10:1 más ventajosa. Para un gran banco global con DC propio y equipo ya construido, el self-host puede ser un 10-15 % más ventajoso.
Data residency y soberanía: la pregunta más importante
¿Dónde se encuentran físicamente sus datos? Es la pregunta a la que un banco y una organización sanitaria deben responder por escrito antes de cada contrato. En España hay tres niveles:
- Datos en ES: ideal para sistemas críticos de la Administración Pública y sanidad. Proveedores: Telefónica Tech Sovereign Cloud, IBM Cloud España, ciertos centros de datos autonómicos.
- Datos en la UE: aceptable para banca si el proveedor garantiza data residency y es CLOUD Act immune. Proveedores: Azure EU Data Boundary, AWS Frankfurt/Dublin con European Sovereign Cloud, OVHcloud.
- Datos fuera de la UE: admisible solo para funciones no críticas con anonimización completa y SCC.
La infraestructura de Modulario está alojada principalmente en Azure Europe West (Ámsterdam) con réplica de respaldo en Azure Europe North (Dublín), ambas bajo EU Data Boundary. Para clientes de sectores regulados ofrecemos también despliegue en sovereign cloud español.
Sanidad: particularidades que no puede pasar por alto
En sanidad, la nube tiene dos barreras principales: el escepticismo histórico y las normas locales concretas. El sector sanitario requiere:
- Cifrado AES-256 en reposo y en tránsito.
- Trazabilidad de auditoría end-to-end: cada acceso a la historia clínica debe quedar registrado, quién, cuándo y por qué motivo.
- Integración con aseguradoras sanitarias y servicios de salud autonómicos vía interfaz HL7/FHIR.
- Operación con certificado profesional sanitario para el inicio de sesión.
Los SaaS modernos para sanidad (sistemas de información hospitalarios, software ambulatorio) en 2026 ofrecen todos estos requisitos out-of-the-box. El self-host requiere un proveedor que entienda las particularidades o un equipo propio, lo que para hospitales pequeños no es realista.
Consejo: Al elegir un SaaS para clínica o consultorio, no se conforme con declaraciones de marketing. Pida documentación del último test de penetración y copia de la EIPD. Si el proveedor no las tiene, es una señal de alarma.
Sector financiero: DORA en la práctica
El sector financiero debe cumplir DORA desde enero de 2025 y el proveedor cloud está vinculado a un contrato controlado por el BdE. Mínimo que el contrato debe contener:
- Rights to audit: el banco puede auditar al proveedor en cualquier momento (típicamente vía un tercero como KPMG o PwC).
- Exit strategy: plan detallado para que el banco abandone al proveedor en 90 días sin pérdida de datos.
- Notificación de incidentes: el proveedor notifica al banco en 2 horas un incidente grave.
- Garantía de localización de datos: los datos permanecen en regiones concretas.
- Transparencia de subcontratistas: el banco ve la cadena de subproveedores y puede vetarlos.
Los proveedores cloud que no puedan ofrecer esto no son aceptables para un banco. Modulario, AWS UE, Azure UE y proveedores locales seleccionados cumplen estos requisitos.
Escenario híbrido: la respuesta más frecuente
En la práctica, la mayoría de bancos y organizaciones sanitarias acaba en el híbrido. Los sistemas core críticos (core banking, historia clínica) en sovereign cloud u on-premise; el resto de sistemas (correo, ERP, RR. HH., marketing) en nube pública con data residency en la UE.
Para una pyme fintech suele compensar la nube pública UE desde el primer día. Para un banco mediano será natural el híbrido: el core banking permanece en el DC existente, pero todo lo demás (CRM, RR. HH., ERP, documentos) se migra a la nube. El ahorro suele ser del 30-45 % a 5 años manteniendo el cumplimiento completo de DORA.
Árbol de decisión: 5 pasos
Si está decidiendo qué camino tomar, siga estos cinco pasos:
- Identifique la criticidad del sistema. ¿Es core (pagos, historia clínica) o de apoyo (RR. HH., marketing)?
- Pregunte al regulador. ¿Tiene del BdE/Ministerio de Sanidad/AEPD una opinión por escrito o un reglamento sectorial vinculante?
- Mapee los datos. ¿Dónde están los datos personales? ¿Son sanitarios o biométricos (art. 9 RGPD)?
- Construya un modelo de TCO a 5 años. Incluya nóminas del equipo, auditorías y certificaciones.
- Considere el híbrido. En la mayoría de casos es el óptimo.
Conclusión: 2026 es para la nube, pero con condiciones
En el entorno regulado de 2026, la nube hace tiempo que dejó de ser “una extranjeridad peligrosa”. Al contrario, con la elección adecuada (sovereign UE, proveedor DORA-compliant, inmunidad al CLOUD Act), la nube es más segura que la mayoría de despliegues on-premise, precisamente porque los proveedores invierten en seguridad órdenes de magnitud por encima de lo que se puede permitir un banco mediano.
El self-host conserva su lugar donde el regulador exige directamente despliegue air-gapped o donde el volumen de datos hace antieconómica la nube. En el resto de casos, la nube, sobre todo en formato híbrido, es la elección racional.
Si pertenece a un sector regulado y quiere que evaluemos su situación, escríbanos. Le prepararemos un informe escrito con árbol de decisión, modelo TCO y arquitectura recomendada concreta para su caso. La consulta dura 60 minutos y es gratuita: usted sale con un camino claro.