La mayoría de las plataformas SaaS son multi-tenant: sirven a varios clientes desde una infraestructura común. Existen tres grandes modelos: base única mutualizada (todos los clientes en una misma base, separados por un identificador), base dedicada por cliente (cada institución tiene su propia base) y sharded (una mezcla). La base mutualizada es el estándar del mercado, económica y segura cuando está bien diseñada. La base dedicada ofrece un aislamiento físico que simplifica la exportación, la supresión en bloque, la copia de seguridad y la localización — lo que la convierte en una ventaja para el RGPD y la soberanía. La elección no es «seguro / no seguro» sino «¿qué garantía puede probar a su DPO?». La pregunta correcta a cualquier editor: «¿mis datos de antiguos alumnos están en la misma base que los de otras escuelas?».
Primero: ¿qué es la multi-tenencia (multi-tenancy)?
Casi todas las plataformas alumni son software SaaS multi-tenant: un mismo servicio aloja los datos de numerosos clientes (los «tenants», aquí las instituciones). Es lo que hace que el SaaS sea económico — el editor comparte la infraestructura en lugar de instalar un servidor en cada cliente. Así que la pregunta no es «multi-tenant o no», sino cómo se almacenan y se separan de los demás los datos de cada institución. Los proveedores cloud documentan estos modelos con precisión; aquí utilizamos la taxonomía de referencia de Microsoft Azure.
Los tres modelos de arquitectura, explicados de forma sencilla
| Modelo | Cómo funciona | Aislamiento | Perfil |
|---|---|---|---|
| Base única mutualizada (single multi-tenant DB) | Todas las escuelas en la misma base, separadas por un tenant ID en columna. | Lógico (asegurado por el código) | La más económica, la más extendida |
| Base dedicada por cliente (database-per-tenant) | Cada escuela tiene su propia base de datos, gestionadas de forma centralizada. | Físico (bases separadas) | Aislamiento fuerte, operación más costosa |
| Sharded (híbrido) | Varias bases, cada una agrupando un subconjunto de clientes. | Variable | El más flexible a gran escala |
Ninguno de estos modelos es «bueno» o «malo» en abstracto: responden a compromisos diferentes entre coste, simplicidad de explotación y nivel de aislamiento. Lo que cambia es lo que usted puede garantizar y probar.
Lo que la arquitectura cambia concretamente para una escuela
Cuatro consecuencias muy concretas, de interés directo para una dirección informática y un DPO:
- Aislamiento. Con una base dedicada, los datos de una escuela viven en una base distinta: un incidente de aplicación en otro perímetro queda, por construcción, fuera del suyo. Con una base mutualizada, el aislamiento depende del rigor de la compartimentación a nivel de aplicación (control de acceso a nivel de fila, pruebas).
- Derecho de supresión (art. 17 del RGPD). El derecho de supresión obliga a poder suprimir datos en plazos cortos. En una base dedicada, suprimir o anonimizar todo el perímetro de una institución se hace en bloque y de forma verificable.
- Exportación y reversibilidad. Recuperar todos sus datos al final de un contrato es más sencillo cuando están en una base que solo es suya. La reversibilidad — no quedar prisionero de un formato propietario — se contractualiza más fácilmente.
- Localización (residencia de los datos). Garantizar que los datos permanecen alojados en Francia o en Europa es más directo cuando la base de una institución es una entidad identificable, no una fracción de un gran conjunto compartido.
«Base mutualizada = riesgo»? No, y aquí está el matiz
Sería deshonesto decir que una base mutualizada es peligrosa. Es un estándar de la industria, utilizado por innumerables servicios que usted emplea cada día, y es perfectamente segura cuando está correctamente diseñada: compartimentación a nivel de aplicación, control de acceso a nivel de fila, revisiones de código y pruebas. Desconfíe de cualquier argumentario que pretenda lo contrario.
La verdadera diferencia está en otra parte: es la naturaleza de la garantía de aislamiento. En una base dedicada, el aislamiento es físico — fácil de explicar y de probar a una comisión, un DPO o una dirección informática. En una base mutualizada, es lógico — real, pero depende de la calidad y del mantenimiento del código. Para una institución pública sujeta a exigencias de soberanía, esta diferencia de «demostrabilidad» pesa a menudo en la decisión.
La pregunta correcta a su editor
No necesita ser ingeniero para decidir. Una sola pregunta hace la criba:
«¿Los datos de mi institución están en la misma base de datos que los de sus otros clientes? Y si me voy, ¿pueden exportarme y luego suprimir todo mi perímetro, de forma verificable?»
Hágala a cada solución que compare, y anote la precisión de la respuesta. Es también uno de los criterios de la guía para elegir un software alumni, junto con la transparencia de precios y el alojamiento.
El enfoque de Terrilink
Terrilink ha optado por la base de datos dedicada por institución: cada escuela dispone de su propia base aislada, alojada en Francia. En concreto, sus datos de antiguos alumnos son identificables, exportables íntegramente y suprimibles en bloque — la soberanía se vuelve verificable, no solo declarativa. Es una opción asumida, más exigente de operar, pero coherente con las expectativas de las instituciones acreditadas. El detalle está en la página software alumni para escuelas acreditadas, y la dimensión de conformidad en la guía RGPD.
En resumen
Mutualizada o dedicada, la cuestión no es saber cuál es «segura» — ambas pueden serlo — sino qué garantía puede probar. Si su institución está sujeta a exigencias de soberanía, de acreditación o de localización de los datos, la base dedicada simplifica el aislamiento, la supresión RGPD, la exportación y la reversibilidad. En todos los casos, exija una respuesta clara de su editor sobre dónde viven sus datos — y sobre su capacidad de recuperarlos y suprimirlos. Es el reflejo de soberanía más útil, y solo cuesta una pregunta.