Hay una conversación que se repite con cierta frecuencia en sectores muy concretos — despachos jurídicos, gestión patrimonial, sector público, ciertos verticales de servicios financieros. Empieza siempre igual: el responsable de operaciones explica por qué su equipo comercial sigue trabajando con un Excel monstruoso y Drive compartido en lugar de un CRM serio. La respuesta corta es casi siempre la misma: "no podemos meter esto en Salesforce".
Lo interesante es que pocas veces es un argumento regulatorio puro. Es una combinación de regulación, lock-in del proveedor, falta de control sobre el ciclo de vida del dato y desconfianza razonable sobre dónde acaba la información del cliente cuando comparte infraestructura con otros cientos de empresas. Este artículo es sobre por qué eso ocurre, y qué hay en medio entre "SaaS multi-tenant" y "self-hosted antiguo".
El problema real con el SaaS multi-tenant
El argumento regulatorio (GDPR, ISO, sectoriales) es el visible. El que importa operativamente es otro. Cuando metes tus datos en un SaaS multi-tenant de gran escala:
- No controlas cuándo te actualizan. El proveedor decide cuándo cambia la UI, cuándo deprecia una API, cuándo migra una base de datos. Tu equipo se entera el lunes que el botón cambió de sitio.
- No controlas cuándo te miran. Audit logs sobre quién del propio proveedor accede a tu tenant son típicamente opacos. En sectores donde un dato del cliente exposed es un incidente reportable, esto es un problema serio.
- No controlas cuándo te sacan. Si el proveedor cambia precios, cambia términos o discontinúa una feature crítica, el coste de migrar de un SaaS multi-tenant maduro es asimétrico — exporte de datos limitado, formato propietario, integraciones que rehacer.
- Tus datos viven en una base de datos compartida con otros. Los proveedores serios lo hacen bien, pero "lo hacen bien" no es lo mismo que "no es posible que falle". Para una boutique de gestión patrimonial, la probabilidad importa menos que la magnitud del fallo.
Nada de esto es una crítica al modelo SaaS multi-tenant en abstracto. Para la mayoría de empresas funciona y es eficiente. Pero hay un subset de sectores donde el cálculo no sale.
El problema real con el self-hosted clásico
La reacción típica a lo anterior es: "pues nos lo montamos en nuestra propia infraestructura". Y aquí aparece el segundo callejón sin salida. El self-hosted clásico — un CRM open-source instalado en un servidor propio o un instance EC2 mantenida por el equipo de IT — tiene problemas distintos pero igual de serios:
- El ops cuesta más que el SaaS. Patching, backups, monitoring, escalado, upgrades. En cualquier organización donde IT no sea su core competence, esto sale caro y mal.
- Las features se quedan atrás. El equipo interno mantiene la instancia operativa pero no añade funcionalidad nueva al ritmo que lo hace el mercado. Tres años después tienes una versión muy desactualizada y un equipo cansado de mantenerla.
- Disaster recovery improvisado. ¿Qué pasa si el servidor cae el viernes a las 18:00? Si la respuesta es "depende de quién esté de guardia", la respuesta es: no hay DR.
- El stack tecnológico envejece. Lo que era un buen stack en 2018 hoy es deuda técnica acumulada. Nadie en el equipo quiere tocarlo.
Por eso el péndulo se mueve a SaaS multi-tenant. Y por eso vuelve a ser problema.
Instancia dedicada: el modelo intermedio
Hay una tercera opción que entre 2015 y 2020 era operativamente complicada y que hoy es claramente viable: el modelo de instancia dedicada. La idea es simple — cada cliente despliega su propia instancia del producto, con su propia base de datos, en infraestructura propia o controlada — pero el ciclo de vida del software lo gestiona el proveedor. Los releases, parches, mejoras de funcionalidad llegan a tu instancia como llegan al resto, pero los datos nunca salen de tu perímetro.
Operativamente esto significa:
- Base de datos propia. No hay tabla compartida con otros clientes. Backups, restore, audit son sobre tu BD exclusivamente.
- Infraestructura controlada. Despliegue en la cloud que tu departamento de IT ya acepta, o en infraestructura on-premise si el sector lo exige. El proveedor opera, pero la frontera de seguridad está clara.
- Mismo ciclo de releases que el resto. No es un fork — es la misma versión del producto que usan todos los clientes con instancia dedicada. No te quedas atrás en features.
- Audit logs propios. Quién accede, qué accede, cuándo. Trazable y exportable.
Esto es lo que un SaaS multi-tenant no puede ofrecer estructuralmente — y lo que un self-hosted clásico solo ofrece a cambio de un coste operativo desproporcionado.
Dónde esto importa de verdad
No todos los sectores necesitan este modelo. Los que típicamente sí:
- Despachos jurídicos. Confidencialidad cliente-abogado es un requisito legal, no una preferencia. Información en SaaS multi-tenant es siempre una conversación incómoda con clientes corporativos.
- Gestión patrimonial y banca privada. Cartera de clientes que en muchos casos exige confidencialidad por contrato. Régimen regulatorio que requiere control demostrable sobre dónde viven los datos.
- Sector público y empresas con contratos públicos. Régimen ENS, esquemas nacionales de ciberseguridad, requerimientos sectoriales sobre localización del dato.
- Servicios profesionales con clientes que firman NDAs por encima del normal. Si tus contratos B2B incluyen cláusulas de "los datos del cliente no podrán estar en infraestructura compartida", el modelo SaaS multi-tenant te bloquea de origen.
En todos estos casos, la pregunta no es "queremos privacidad". Es "queremos un CRM real, no Excel, pero los modelos clásicos nos bloquean por compliance o por contrato". La instancia dedicada es la respuesta operativa.
Lo que cambia y lo que no
Comparado con un SaaS multi-tenant clásico, el modelo de instancia dedicada cambia tres cosas operativas concretas:
- Onboarding más lento. Provisionar la instancia, conectar las fuentes de datos del cliente, validar el entorno toma días o semanas en lugar de minutos. No es para empresas que necesitan estar operativas mañana.
- Compromiso más largo. Una instancia dedicada implica una relación operativa más estrecha con el proveedor. Es el modelo natural para clientes que quieren un partner, no un proveedor de software intercambiable.
- Cumplimiento mucho más simple. GDPR, ENS, requisitos sectoriales, auditorías de cliente — todo es más limpio cuando los datos están en infraestructura controlada y trazable.
Y lo que no cambia: la experiencia del equipo comercial usándolo. La UI, el pipeline, el copilot, las integraciones — todo igual. Solo cambia dónde viven los datos.
Minerva sigue exactamente este modelo: una instancia dedicada por cliente, con su propia base de datos y su propio entorno. Si tu sector te bloquea para usar un SaaS multi-tenant clásico y aún así necesitas un CRM serio, hablemos — discutimos los requisitos concretos de tu entorno y validamos si encaja.