Una ingeniería técnica prescribió hace tres años una plataforma SaaS GMAO+GIS a un operador industrial privado con cartera de infraestructura distribuida. El proveedor tiene producto sólido y trayectoria estable; los tres años transcurridos no han producido incidencias relevantes. En una revisión rutinaria del departamento de sistemas del cliente, el responsable de IT plantea al proveedor una pregunta que no había hecho antes: cómo accede el cliente a su propio backup. El proveedor responde con corrección técnica que existe una política de restauración bajo demanda y que en caso de incidente ellos pueden recuperar los datos hasta el último punto de sincronización horaria. La segunda pregunta del responsable de IT es la que descubre la asimetría: cómo puede el cliente recibir una copia periódica de su backup para custodiarla en su propio almacenamiento. El proveedor responde con honestidad que su oferta estándar no lo contempla, que se podría estudiar como servicio adicional y que en los tres años del contrato la cuestión no había surgido. La conversación entre operador e ingeniería vuelve a la mesa técnica: la asimetría no es maliciosa por parte del proveedor, es arquitectónica; y no se pactó en el pliego porque en el pliego no había cláusula que la contemplara.
El backup del cliente es el eslabón menos pactado del contrato de una plataforma técnica SaaS y, precisamente por eso, el que decide en la práctica quién controla los datos cuando el escenario cambia. Cambios de política comercial, adquisición del proveedor, disrupción operativa del proveedor, o simplemente decisión estratégica del cliente de trasladar datos a su propia infraestructura: en los cuatro casos, quien posee la copia decide el ritmo de la conversación. Una ingeniería técnica que prescribe una plataforma sin pactar el arreglo de backup deja al cliente con la peor posición negociadora de las cuatro posibles.
Los cuatro arreglos de backup ordenados por soberanía del cliente
El primer arreglo es el de backup solo en poder del proveedor. El proveedor guarda las copias en su propia infraestructura y ofrece restauración bajo demanda ante incidencias. El cliente no ve el backup, no lo audita, no lo custodia. Es el arreglo por defecto en muchas plataformas SaaS técnicas de mediana escala y el que menor soberanía otorga. Ante un escenario adverso, la única vía del cliente pasa por la voluntad y la capacidad operativa del proveedor.
El segundo arreglo añade visibilidad. El cliente accede al portal del proveedor y ve cuándo se hicieron las últimas copias, con qué tamaño y con qué integridad reportada. No accede al contenido de las copias, pero puede supervisarlas. Es una mejora sobre el primero, aunque en la práctica el ejercicio de supervisar sin poder actuar tiene un límite claro.
El tercer arreglo es la entrega periódica al cliente. El proveedor deposita una copia del backup, con frecuencia definida —semanal, mensual, en el ritmo pactado— y en formato estructurado, en un canal accesible al cliente. El cliente custodia la copia en su propia infraestructura y adquiere la capacidad de restaurarla, migrar a otra plataforma o simplemente auditarla sin depender de la ventana operativa del proveedor. Es un arreglo defensable y, para la mayoría de escenarios reales, suficiente.
El cuarto arreglo es el destino de backup en propiedad del cliente. La plataforma deposita el backup automáticamente en un bucket S3, GCS o Azure Blob que el cliente controla, con claves de acceso que residen en la nube del cliente. La operación es continua, no requiere entrega periódica, y el cliente tiene el backup a su alcance en todo momento. Es la máxima soberanía técnicamente posible bajo un modelo SaaS y la que un operador con orientación estratégica al dato debería aspirar a pactar.
Qué especificar en el pliego técnico
Una ingeniería que prescribe una plataforma técnica de larga duración debería incluir en el pliego una cláusula específica de backup con cinco elementos concretos. El arreglo elegido —de los cuatro anteriores— con preferencia por el tercero o el cuarto. La frecuencia: semanal como mínimo defendible para la mayor parte de los casos, diaria para operaciones críticas. El formato: no un dump propietario del proveedor sino un formato estructurado y documentado —típicamente SQL dump con esquema publicado o export multi-tabla en CSV— acompañado de las capas espaciales en formato OGC estándar. La retención sobre el lado del cliente: cuánto tiempo se conserva cada copia y bajo qué política de rotación. Y el alcance: qué datos incluye el backup —maestro de activos completo, adjuntos multimedia, histórico de órdenes de trabajo, configuración de la plataforma, telemetría acumulada— porque un backup que omite piezas relevantes no es un backup útil para restauración operativa.
La consecuencia modular
Cuando la plataforma está diseñada con arquitectura modular, cada módulo puede tener su propio arreglo de backup ajustado a su criticidad operativa. El inventario común puede ir con backup semanal a destino del cliente; el correctivo con captura firmada en campo puede ir con backup diario; las lecturas de sensor con backup por hora. El cliente afina su estrategia de backup a la naturaleza del dato en cada módulo y evita el arreglo monolítico que trata todos los datos con la misma frecuencia y el mismo destino independientemente de su valor operativo. Esta granularidad no es un lujo técnico: es la que permite que el coste de infraestructura de custodia sea proporcional al valor del dato, y no un mínimo común uniforme.
Cómo lo resolvemos en Maptainer
En Maptainer soportamos por diseño el arreglo de backup a destino del cliente con granularidad modular. Cada módulo activo en el despliegue del cliente puede configurarse con frecuencia, formato y destino específicos; los backups se depositan en almacenamiento del propio cliente mediante credenciales gestionadas por el cliente; y el fichero entregado incluye tanto el esquema estructurado como las capas espaciales en formato OGC. La consecuencia práctica es que el cliente puede, en cualquier momento del contrato, montar una copia funcional de sus datos en su propia infraestructura sin depender de nuestra ventana operativa. Ese es un compromiso técnico que la mayoría de plataformas comparables no incluyen en su oferta estándar y que un pliego de ingeniería serio puede exigir en sus criterios de admisión.
La cláusula corta que hace el trabajo largo
Una cláusula de backup bien redactada en un pliego de ingeniería resuelve el noventa por ciento del trabajo de mitigación del vendor lock-in que, sin ella, habría que hacer en el momento de la migración, con toda la carga de negociación bajo presión que ese momento conlleva. Los proveedores que pueden cumplir la cláusula entran en la lista corta; los que no pueden, quedan fuera antes de la primera reunión comercial. La cláusula es corta, es técnica, y produce un filtro que la conversación abstracta sobre soberanía de datos rara vez consigue. La ingeniería que la incorpora sistemáticamente al pliego construye reputación de prescriptor riguroso, y ese es un activo comercial que el cliente reconoce en el segundo proyecto sin necesidad de que la ingeniería lo defienda.