Borrar por encima de la retención: tres firmas en Exchange, una en SharePoint

Hay una frase en la documentación de Priority Cleanup que no se lee casi en ningún otro sitio del ecosistema Microsoft 365: «items are permanently deleted and cannot be restored by users, by admins, or by Microsoft». Ni el usuario, ni el administrador, ni Microsoft. La función lleva desde mediados de agosto en vista previa para SharePoint y OneDrive y su despliegue general arranca a finales de este mes.

Lo que hace especial esa frase es el contraste con todo lo demás. En Microsoft 365 casi cualquier borrado tiene una ventana de vuelta atrás: papeleras de dos fases, elementos recuperables, bibliotecas de conservación. Nosotros mismos hemos escrito aquí sobre la carpeta de elementos recuperables de Exchange y su ventana por defecto, que es exactamente el sitio del que sale la mayoría de los correos que alguien creía perdidos. Priority Cleanup es la primera pieza del producto diseñada para que esa ventana no exista.

Administramos tenants de Microsoft 365 de clientes y nos toca responder de qué se puede recuperar y de qué no. Así que hemos leído las dos páginas de Microsoft Learn con calma, la de buzones y la de ficheros, y lo que nos ha llamado la atención no es la función. Es que no está gobernada igual en los dos sitios.

Para qué la hizo Microsoft (y no es lo que parece)

En buzones, los ejemplos que da Microsoft son los que uno esperaría: una petición de privacidad sobre alguien que ya no está en la empresa, o un derrame de datos —el correo con la información de una adquisición futura enviado a quien no tocaba— que hay que borrar aunque haya holds de eDiscovery abiertos.

En ficheros, no. El título literal de la página de SharePoint y OneDrive es «Override holds to clean up files for Copilot and reclaim storage». Saltarse los holds para limpiar lo que ve Copilot y recuperar almacenamiento. Y los dos casos de uso que enumera son igual de prosaicos: grabaciones y transcripciones de reuniones de Teams caducadas —«typically large and have little business value after 1-3 months», dice Microsoft— y el OneDrive de alguien que se ha ido y que no se puede borrar porque quedan ficheros en la Preservation Hold library con la retención sin vencer.

El problema que resuelve es real, y conviene decirlo antes de criticar nada. La retención de Microsoft 365 no tenía un «esto sí, y ya»: o esperabas a que venciera el periodo más largo, o levantabas el hold con todo lo que eso arrastra. Priority Cleanup es ese botón. Nuestra objeción no es que exista. Es a quién se le entrega y con cuántas firmas.

Tres firmas en Exchange, una en SharePoint

Es el mismo botón y el mismo motor —por dentro son etiquetas de retención con auto-aplicación—, pero el régimen de aprobación cambia según dónde viva el dato. Esta es la comparación, montada con la tabla que publican las dos páginas y con el texto de sus apartados de aprobadores:

La línea que nos parece la más importante de la tabla es la tercera, y viene textual de la documentación de ficheros: «Separate approval from a retention admin isn't required to override retention settings». En la mitad del tenant donde vive la mayor parte de los documentos de una empresa, saltarse una política de retención no necesita la firma de quien la puso.

Es defendible, por cierto, y no queremos venderlo como un descuido. El caso de uso de ficheros es tirar grabaciones de Teams del mes pasado, y montar tres aprobaciones para eso, en una política que Microsoft describe como continua, sería inviable. Nuestro criterio es otro: el control ha dejado de ser técnico y ahora es una lista de nombres, y esa lista hay que mirarla hoy, no el día que alguien la use.

Quién tiene el rol sin haberlo pedido

El rol que hace falta se llama Priority Cleanup Admin, y la documentación dice cómo se reparte: «This role is automatically added to the Organization Management role group but must be manually added to any other role group». Traducido: si no has tocado nada, ya lo tiene quien esté en Organization Management. En un tenant de una pyme eso suele ser el equipo de sistemas al completo, más algún consultor que entró un martes de hace dos años.

Y hay un detalle de la regla de dos personas que merece leerse despacio. En la página de buzones, sobre el primer aprobador: «This should be a different person to the user who created the priority cleanup policy, but isn't enforced». Debería ser otra persona, pero el producto no lo impone. En ficheros sí se impone, y de una forma más elegante: «The last person to edit the policy can't also turn it on». Dos criterios distintos para el mismo principio, dentro del mismo producto y de la misma pantalla de configuración.

Dicho lo cual, y para no dejar la impresión equivocada: en Exchange hacen falta tres roles distintos —priority cleanup admin, retention manager y eDiscovery admin—, así que si detrás hay tres personas de verdad, el control es bastante más fuerte que en ficheros aunque la regla de dos personas no esté forzada. El riesgo no es simétrico y por eso no vale una sola respuesta para los dos lados.

Lo que sí lo detiene

El interruptor se decide antes, no después

La función se puede apagar a nivel de inquilino, en Purview > Data Lifecycle Management > Priority cleanup settings, y el interruptor es único: apaga buzones y ficheros a la vez. La propia Microsoft lo sugiere para un perfil concreto de organización, y la frase vale la pena entera: «highly regulated organizations that use Preservation Lock might want the additional safeguard of turning off priority cleanup at the tenant level».

Ahora la parte que hay que leer dos veces. Si apagas el control con políticas ya creadas, la documentación es explícita: «Existing priority cleanup policies continue to function». Se pueden borrar, sí, pero no se pueden modificar y siguen funcionando. Y aún hay una vuelta más: «Although you can delete a priority cleanup policy, if the approval process for it is complete, items might still be permanently deleted». Borrar la política después de que las firmas estén puestas no necesariamente detiene el borrado.

Es un interruptor de antes. Igual que la auditoría, que según Microsoft tiene que estar activa al menos un día antes de crear y ejecutar la primera política, y que además hace falta para ver los resultados de la simulación. La documentación no dice qué pasa si no lo está: nosotros no encenderíamos nada sin comprobarlo antes.

Y cuando vayas a buscar ese rastro, los eventos no salen en el desplegable del portal —«these events don't have friendly names to select from the Microsoft Purview portal»—, así que hay que escribirlos a mano:

PriorityCleanupTagApplied     # el elemento entra en el circuito
PriorityCleanupDelete         # borrado de un elemento de buzón
PriorityCleanupFileRecycled   # borrado de un fichero de SharePoint u OneDrive

Dónde no nos cuadran las fuentes

Preferimos decirlo a taparlo. La página de Microsoft Learn afirma que «the feature itself is enabled by default at the tenant level». El aviso del centro de mensajes MC1261587 —publicado el 25 de marzo de 2026 y actualizado el 19 de agosto— dice lo contrario: que la capacidad «is not enabled by default and requires explicit admin configuration».

Nuestra lectura, y es lectura y no dato: las dos frases se sostienen a la vez si «enabled» se refiere al interruptor y «not enabled by default» al efecto. El control viene puesto, pero no se borra nada hasta que alguien crea una política, la enciende y otro firma. El propio aviso lo dice: «There is no change to user workflows unless an admin configures and applies a priority cleanup policy». Si tu lectura es otra, la comprobación son treinta segundos en el portal de tu inquilino, y esa vale más que la nuestra.

Hay un segundo hueco, y también lo dejamos abierto. El aviso del centro de mensajes anuncia para ficheros una opción de «Delete data permanently» cuyo resultado es que el contenido deja de ser localizable en la búsqueda de SharePoint, en Copilot y en eDiscovery. La página de Learn que hemos leído describe el camino con papelera de segunda fase. No hemos encontrado en Learn la descripción de esa opción nueva, así que no afirmamos cómo se comporta. Lo miraremos cuando la documentación se ponga al día.

Y tu copia, ¿te salva de esto?

Es la cuarta vez este verano que este blog acaba en el mismo sitio, y lo decimos en voz alta antes de repetirlo: una política de retención no es una copia de seguridad, la copia que ofrece Microsoft nunca sale de Microsoft y archivar tampoco es copiar. Priority Cleanup añade un caso que ninguna de esas dos piezas cubría: un borrado legítimo, aprobado y auditado, hecho desde dentro por gente con permiso. No es ransomware ni es un error de plataforma. Es un procedimiento correcto ejecutado con la consulta KeyQL mal escrita, o con el ámbito más ancho de la cuenta.

Una copia fuera del inquilino te devuelve el fichero solo si se cumplen dos condiciones. Que estuviera copiado antes del borrado, que es obvia. Y que la retención de tu copia no purgue lo que desaparece del origen, que no lo es en absoluto. Hay productos de copia para Microsoft 365 que sincronizan borrados: si el elemento se va del origen, se va de la copia al vencer un plazo corto. Esa cláusula es la que decide si tienes una copia o un espejo, y es la pregunta que hacemos siempre cuando montamos copia de Microsoft 365 para alguien.

Cinco cosas que haríamos esta semana

Una entrada nueva en el inventario

Aquí no hay ningún fallo. Priority Cleanup hace exactamente lo que su documentación dice que hace, resuelve un problema que existía y trae más salvaguardas de las que suele traer un borrado en Microsoft 365. Lo que cambia es otra cosa: la lista de quién puede hacer desaparecer un dato de tu empresa tiene desde este mes una entrada más en SharePoint y OneDrive, y esa entrada solo necesita una firma.

El fallo es inevitable; la avería es una decisión de diseño. Esta vez ni siquiera hay fallo: hay una capacidad nueva y una decisión pendiente sobre quién la tiene. Nosotros esto lo revisamos como parte del trabajo de Microsoft 365 y de cumplimiento y continuidad, junto con la pregunta que va detrás y que casi nunca se hace a tiempo: si mañana desaparece, ¿de dónde vuelve?

Fuentes (verificadas el 3 de septiembre de 2026): frase sobre el borrado irreversible, tres aprobaciones siempre exigidas, roles de aprobador, regla de dos personas no forzada, excepción de registros y de los review sets, aviso sobre Preservation Lock, comportamiento al apagar el interruptor, requisito de auditoría y eventos de log — Microsoft Learn, «Use priority cleanup to expedite the permanent deletion of sensitive information from mailboxes». Título de la página de ficheros, casos de uso de Teams y de la Preservation Hold library, aprobación única, simulación obligatoria, papelera de segunda fase y regla del último editor — Microsoft Learn, «Override holds to clean up files for Copilot and reclaim storage». Fechas de vista previa y disponibilidad general, opción «Delete data permanently» y frase sobre la activación — aviso del centro de mensajes de Microsoft 365 MC1261587, publicado el 25-mar-2026 y actualizado el 19-ago-2026 (visible desde el inquilino). La página de buzones de Learn está marcada como función en vista previa y sujeta a cambios; la de SharePoint y OneDrive no lleva ese aviso.