On-premise, privado o cloud fundacional: el criterio no es técnico, es de confianza
Tres modelos de despliegue, un mismo criterio: sensibilidad del dato, necesidad de trazabilidad, stack corporativo y velocidad de adopción. Cómo elegimos en cada caso.
This content is currently available in Spanish only.
Una de las primeras preguntas en cualquier conversación inicial con un cliente es dónde corre el modelo. La respuesta correcta casi nunca es la que parece. No depende del tamaño del cliente ni de la criticidad genérica del sector; depende de cuatro variables muy concretas.
Las cuatro variables que sí pesan
Sensibilidad del dato. No todos los datos del cliente son iguales. Documentación pública del producto puede ir a cloud fundacional. Datos de cliente, posiciones, salarios o información clínica no. Esa diferencia se hace por proceso, no por compañía.
Necesidad de trazabilidad. En entornos regulados (banca, salud, real estate con valoraciones), hay que poder reconstruir cada decisión. Eso empuja hacia privado/dedicado o corporativo, donde la auditoría es propietaria.
Stack corporativo. Si el cliente ya vive en M365 y tiene Copilot y Purview funcionando, forzar un cloud distinto es fricción gratuita. El despliegue corporativo sobre la base existente acorta meses.
Velocidad de adopción. Un piloto rápido para validar valor antes de invertir en arquitectura privada es legítimo. Lo malo es confundir el piloto con el destino: hay que diseñar la migración desde el día uno.
Cómo lo decidimos en aiRoss
| Modelo | Cuándo | Pros | Contras | | --- | --- | --- | --- | | Fundacional cloud | Pilotos rápidos, datos no sensibles | Velocidad, coste bajo, mejores modelos | Menor control, datos atraviesan terceros | | Privado / dedicado | Procesos críticos, datos confidenciales | Aislamiento, trazabilidad, latencia | Mayor coste, más operación | | Corporativo (M365 / on-prem) | Cliente con stack consolidado | Integración nativa, gobernanza única | Limitado a capacidades del stack |
La pregunta no es "¿on-prem o cloud?". Es "¿qué nivel de aislamiento exige este dato concreto para este proceso concreto?".
El error más común que vemos es elegir modelo de despliegue por política general en lugar de por proceso. Eso lleva a sobre-invertir en infraestructura para casos que no la necesitan, o a comprometer datos críticos por velocidad de demo.