Según el propio contrato de uso de Microsoft —el texto que toda empresa acepta al contratar Microsoft 365 (el antiguo Office 365)—, la compañía recomienda, en más de una cláusula, que el cliente "haga copia de seguridad con regularidad" del contenido que guarda en los servicios. La recomendación aparece justamente en los apartados sobre interrupciones del servicio y sobre el cierre de cuenta: en ambos casos, el texto advierte que Microsoft podría no poder devolver lo que se perdió.

Esto no es letra pequeña escondida. Es la misma lógica que Microsoft describe en su propia documentación técnica sobre la división de responsabilidades en la nube: en cualquier servicio en la nube —incluida una aplicación lista para usar, como Microsoft 365—, el proveedor se ocupa de la infraestructura y del funcionamiento de la plataforma, pero el dato que pasa por ella sigue siendo responsabilidad de quien lo generó. El backup, el control de acceso y la recuperación quedan del lado de quien contrató el servicio, incluso con todo alojado en la nube.

Para quien decide el presupuesto de TI, la distinción importa porque cambia la pregunta correcta. No es "¿Microsoft 365 es confiable?" —lo es—. La pregunta es otra: si un correo, una carpeta o una conversación del equipo desaparece por error, ¿hay alguien guardando una copia fuera del propio servicio, y esa copia ya fue probada?

Dónde termina la garantía de la nube

Para todo servicio en la nube —desde un servidor alquilado hasta una aplicación lista para usar como Microsoft 365—, Microsoft mantiene una tabla pública de división de responsabilidades. Es clara en un punto que vale para cualquiera de los formatos: el dato de la empresa, las configuraciones y las cuentas de usuario siguen siendo responsabilidad de quien contrató el servicio, nunca de Microsoft. Ni siquiera en la aplicación lista para usar —la más "cuidada" de los tres formatos— esa línea cambia de lado.

Lo que Microsoft sí garantiza, y cumple bien, es la infraestructura: los centros de datos en funcionamiento, la réplica de los datos entre distintos servidores, la aplicación siempre disponible. La réplica, sin embargo, no es una copia de seguridad: es el mismo dato, espejado. Si un archivo se borra o se corrompe, la réplica se borra y se corrompe junto con él, porque su trabajo es mantener los servidores idénticos entre sí, no guardar una versión de ayer para poder recuperarla.

Por eso el propio contrato de Microsoft 365 recomienda, en más de un apartado, que el cliente mantenga su propia copia regular de lo que guarda ahí, y advierte que, sin ella, un contenido perdido puede no volver.

En la práctica, eso tiene un plazo corto. En Exchange Online, el correo de Microsoft 365, un elemento borrado queda recuperable por defecto durante 14 días; un administrador puede extender ese plazo, pero hasta un tope de 30 días. Pasado ese período, el elemento sale de la carpeta de recuperación y no vuelve. Treinta días es bastante menos de la mitad del tiempo que separó, en el caso del inicio de este artículo, el borrado del día en que el director se dio cuenta.

El hábito que la nube no corrige

El hábito que la nube no corrige

El comportamiento más común frente a esto es confiar en que "estar en la nube" ya resuelve el problema, y tratar a Microsoft 365 como si ya fuera un backup, porque los archivos se sincronizan solos entre la computadora y OneDrive o SharePoint.

La sincronización tiene el mismo límite que la réplica: copia el cambio, no decide si el cambio fue un acierto o un error. Si un archivo se borra, queda cifrado por un secuestro de datos o se sobrescribe por error en una hoja de cálculo compartida, la sincronización lleva ese estado a todos los lugares conectados, incluida la nube.

Otro hábito común es dejar el tema sin dueño: nadie volvió a leer el contrato de servicio, nadie probó una recuperación, y la primera vez que la empresa descubre el plazo de retención es justo cuando lo necesita, y ese plazo ya pasó. En ese momento, la salida suele ser abrir un ticket con el propio soporte de Microsoft y esperar una respuesta, sin garantía de que el dato todavía exista para ser devuelto.

Lo que tiene que existir en la práctica

Un entorno de Microsoft 365 realmente protegido tiene mecanismos concretos, no la suposición de que "la nube ya se encarga de eso".

Una copia guardada fuera de Microsoft 365. Ni la papelera ni el historial de versiones del propio servicio: una copia independiente, en un lugar que sigue en pie aunque la cuenta, el correo o el archivo original desaparezcan.

Cobertura de cada parte del entorno, no solo de la bandeja de entrada. El correo, los archivos en OneDrive y SharePoint, y lo que se intercambia en Teams tienen plazos de descarte distintos entre sí: la copia necesita alcanzarlos a todos, no solo lo más visible en el día a día.

Un plazo de retención mayor que el plazo de descarte automático del servicio. Si Microsoft 365 borra en semanas, la copia independiente debe guardar por meses: esa diferencia es justo la que cubre el caso de que alguien note el error tarde.

Simulacros periódicos de recuperación, y no solo la copia corriendo en segundo plano: probar de tanto en tanto si un archivo concreto vuelve, y en cuánto tiempo, es la única forma de saber si la copia funciona antes del día en que realmente hace falta.

Restauración que no dependa de abrir un ticket con el fabricante. Quien administra la copia puede devolver el elemento por su cuenta, sin entrar en la fila de soporte de un proveedor que atiende a todo el mundo.

Así es como trabaja Skills IT: copias automatizadas y cifradas del entorno Microsoft 365, con un plazo de retención definido en el contrato y simulacros periódicos de recuperación.

Lo que cambia en el día a día de la empresa

Lo que cambia en el día a día de la empresa

La primera ganancia es la más simple de explicar: un error de un empleado —borrar la carpeta equivocada, sobrescribir la hoja de cálculo equivocada— deja de ser un problema sin vuelta atrás. Se convierte en una solicitud de restauración que se resuelve en poco tiempo, sin reconstruir el trabajo de memoria ni pedirle al cliente que reenvíe lo que ya se había acordado.

La segunda es la separación entre el ataque y el daño. Un secuestro de datos que cifra archivos en OneDrive o SharePoint sincroniza ese desorden hacia la nube junto con todo lo demás: sin una copia guardada fuera de ese ciclo, no queda una versión limpia para recuperar. Con ella, la empresa vuelve a una versión anterior al ataque, en lugar de negociar con quien secuestró los archivos.

La tercera es presupuestaria: el costo de mantener la copia es previsible y pequeño frente al costo de recrear contratos, registros de clientes o meses de historial de correo perdido, sin contar el tiempo del equipo parado mientras nadie sabe si eso va a volver.

Gartner proyectó, en agosto de 2024, que solo el 15% de las empresas trataba el backup de aplicaciones usadas directamente desde la nube —la categoría a la que pertenece Microsoft 365— como una prioridad crítica ese año, y que esa cifra debería llegar al 75% en 2028. En la práctica, eso quiere decir que la mayoría de las empresas todavía trata el tema como algo para resolver más adelante. La cuenta aparece justo cuando ese "más adelante" llega demasiado tarde.

Cuatro preguntas para llevar a la próxima reunión

Antes de asumir que Microsoft 365 ya está cubierto, vale la pena responder estas cuatro preguntas junto con quien se ocupa de la TI de la empresa:

  1. ¿Dónde está la copia de los datos de Microsoft 365 de la empresa, y quién la administra? Si la respuesta es "de eso se encarga Microsoft", vale la pena releer el propio contrato de servicio antes de la reunión.
  2. ¿Durante cuántos días sigue siendo recuperable un correo o archivo borrado? Pasado ese plazo, el elemento sale incluso de la carpeta de recuperación del propio servicio, no solo de la computadora del empleado.
  3. ¿Cuándo fue la última vez que alguien probó restaurar un archivo de verdad? Una copia que nunca se probó es una suposición, no una garantía.
  4. Si alguien borra una carpeta entera hoy, ¿quién la restaura y en cuánto tiempo? Si la respuesta es "abrir un ticket y esperar", ese es el punto que hay que resolver primero.