Piensa en el fichero de tu SharePoint que lleva más tiempo sin que nadie lo abra. La escritura del local. El plano as-built de la instalación. El informe pericial de aquel litigio. El certificado de la máquina que compró tu antecesor. Ahora piensa cuál de todos ellos te va a hacer falta algún día, y con qué urgencia. Es probable que sea el mismo. A mediados de agosto Microsoft termina de desplegar la posibilidad de borrar automáticamente exactamente ese fichero, con el argumento de que así Copilot responderá mejor. No lo borra solo —alguien tiene que configurarlo—, pero el botón va a estar ahí, y va a ser muy fácil de pulsar.
Qué llega exactamente, y qué no
El aviso está en el centro de mensajes de Microsoft 365 con la referencia MC999442, y se titula «Retención basada en el último acceso para ficheros de OneDrive y SharePoint». La vista previa arrancó a finales de junio de 2026 y la disponibilidad general a finales de julio; Microsoft espera completar ambas a mediados de agosto. En cristiano: a partir de ahora, además de poder retener o borrar por fecha de creación, de modificación o de etiquetado, se puede hacer por «no lo ha abierto nadie de tu organización desde hace X». De momento aplica a tipos de fichero de Microsoft 365; el resto de formatos, dice el aviso, en un despliegue futuro.
Antes de seguir, la parte honesta, porque si la saltamos el resto del artículo es alarmismo: esto no borra nada por sí solo. El propio aviso dice que el despliegue es automático y que no requiere ninguna acción del administrador; lo que llega es la opción en el desplegable, no una política activa. Si nadie crea una política de retención con acción de eliminar sobre esa condición, en tu tenant no desaparecerá un solo fichero. Nuestra preocupación no es el despliegue. Es la facilidad del gesto y la calidad del argumento con el que se va a pedir.
Porque el argumento viene escrito en el propio aviso: la función «ayudará a eliminar datos obsoletos, lo que mejorará la calidad y la relevancia de las respuestas de Microsoft 365 Copilot». Es un motivo técnicamente razonable —un índice lleno de basura degrada cualquier sistema de recuperación— y a la vez es la primera vez que vemos una función de borrado en Microsoft 365 justificada por la calidad de las respuestas de una IA. Conviene notarlo, porque cambia quién pide el botón: la persona que quiere que Copilot responda mejor no es la misma que necesitará el fichero de 2021 en 2029, y ninguna de las dos es la que firma el cuestionario de cumplimiento del cliente grande.
El disparador ya no es una propiedad del fichero
Aquí está, para nosotros, lo interesante de verdad, y no lo hemos visto contado en ningún sitio. Fecha de creación y fecha de modificación son propiedades del documento: las escribió alguien que hizo algo con él deliberadamente. «Último acceso» no es una propiedad del documento; es una medida del comportamiento de tu organización. Un fichero no se vuelve viejo porque nadie lo mire, igual que un extintor no caduca porque nadie lo use.
Y la consecuencia es incómoda, porque para toda una familia de documentos la relación entre frecuencia de acceso y valor es inversa. Los contratos firmados, las escrituras, los certificados de conformidad, los planos definitivos, los informes de auditoría, las actas: se abren una vez cuando se firman y no se vuelven a tocar hasta que hay un problema. Que nadie los haya abierto en tres años no significa que sobren; significa que en tres años no ha habido ninguna inspección, ninguna reclamación y ningún litigio. Es una buena noticia sobre la empresa, no un veredicto sobre el fichero.
Y nadie ha dicho todavía qué cuenta como «abrir»
Esta es la pregunta que decide si la función es útil o peligrosa, y a día de hoy no tiene respuesta pública. Ni el aviso del centro de mensajes ni la página de Microsoft Learn sobre retención para SharePoint y OneDrive definen qué evento actualiza esa fecha de último acceso. La segunda menciona los inicios de retención por creación, modificación, etiquetado y evento, y de la nueva condición todavía no dice nada. Es un Ctrl+F: compruébalo tú mismo antes de creernos.
No vamos a inventarnos la respuesta. Vamos a dejar escritas las cuatro preguntas cuya respuesta cambia por completo el resultado, porque son las que le haríamos a Microsoft antes de configurar nada:
- ¿Cuenta como acceso lo que hace el cliente de sincronización de OneDrive cuando pone al día una carpeta en el portátil de alguien?
- ¿Y una herramienta que recorre todo el tenant —un antivirus, una migración, una copia de seguridad de un tercero, una exportación de eDiscovery—? Si cuenta, el reloj no llega nunca a cero y la política no borra nada: falsa tranquilidad.
- ¿Cuenta que Copilot lea el fichero para fundamentar una respuesta? Tiene su gracia: sería una función pensada para mejorar a Copilot cuyo reloj reinicia el propio Copilot.
- Y la que más nos importa: para un fichero que existía antes de que la función llegara, ¿desde cuándo se cuenta? Si no hay histórico previo, ¿el reloj arranca hoy o se hereda una fecha que nadie sabe cómo se calculó?
Fíjate en que los dos errores posibles apuntan en direcciones opuestas y los dos son malos. Si casi todo cuenta como acceso, montas una política de limpieza que no limpia y te quedas tan ancho. Si casi nada cuenta, borras documentos vivos que simplemente se consultan poco. Configurar un borrado irreversible sobre una señal que no está documentada es exactamente el tipo de decisión que luego no se puede defender por escrito, y por escrito es como se responden las auditorías.
93 días, y son días de silencio
La mecánica del borrado sí está documentada, y conviene tenerla clara porque marca tu único margen real. Cuando una política de solo eliminación cumple su plazo, un proceso periódico —que puede tardar hasta siete días en ejecutarse— mueve el documento a la papelera de primera fase. Si alguien la vacía, pasa a la de segunda. Un plazo de 93 días abarca las dos, y al terminar el documento se borra permanentemente esté donde esté. Ese número es tu ventana de recuperación completa: no la del contrato de Microsoft 365, no la de tu política de retención. Noventa y tres días.
Y ahora la parte que nos parece la más importante de todo el artículo. Esos 93 días transcurren en silencio, por construcción. Cualquier otra pérdida de datos tiene una señal de detección: alguien abre una incidencia porque no encuentra algo. Aquí la política borra, con precisión quirúrgica, justamente los ficheros que nadie mira. Nadie va a echarlos de menos, porque «nadie los mira» era el criterio de selección. No habrá ticket. No habrá llamada. Para rematarlo, la documentación de Microsoft es explícita en que la papelera no está indexada y por tanto no se puede buscar en ella, de modo que una búsqueda de eDiscovery no encuentra su contenido para ponerle una retención. Ni siquiera buscando aparece. Traducido a un plan de trabajo: la detección de este fallo no puede ser reactiva, tiene que estar en el calendario antes de que el problema exista.
Los tres salvavidas que la gente cree tener
Cuando planteamos esto en una reunión, la respuesta suele ser una de estas tres. Ninguna aguanta.
«Está la papelera». Está, y dura 93 días contados desde un momento que no vas a notar. El fichero se queda en la papelera de primera fase, que el usuario sí ve —el usuario de un sitio en el que, por definición, no entra nadie—; y si alguien la vacía pasa a la de segunda, que ya no ven los usuarios y de la que solo restaura un administrador de la colección de sitios. En los dos casos es una red de tres meses a la que hay que ir a mirar, y nadie va a ir.
«Está el historial de versiones». SharePoint guarda por defecto un mínimo de 500 versiones principales, sí, y es una función excelente para el error de «he sobrescrito el documento». Pero la documentación no deja lugar a dudas: cuando la acción de retención es eliminar el documento, todas las versiones que no estén en la biblioteca de conservación de documentos se borran a la vez, siguiendo a la versión actual. Protege de editar mal, no de borrar.
«Tenemos política de retención». Esa es precisamente la que borra. Una política de retención responde a «cuánto tiempo debe existir esto»; un backup responde a «cómo recupero esto si el sistema hace lo que le dije que hiciera». Son herramientas distintas, con dueños distintos y con modos de fallo distintos. Cuando la única respuesta a «¿y si nos equivocamos?» es «pues está la papelera», lo que hay es una política de retención haciendo de backup.
Lo escribimos hace poco a cuenta de un caso muchísimo más grave y el fondo es el mismo: cuando el sistema borra y la copia se va con él, el dato no vuelve. Allí el borrado fue accidental y aquí es una función que hace su trabajo, pero el dato desaparecido no distingue entre las dos cosas.
Microsoft vende el airbag aparte, y ese es el dato
Llevamos años repitiendo que Microsoft 365 no hace tus copias de seguridad y llevamos años viendo caras de escepticismo. La discusión se acabó hace tiempo y no hace falta que la ganemos nosotros: Microsoft tiene un producto llamado Microsoft 365 Backup, de pago por uso, con precio de tarifa de 0,15 dólares por GB y mes de contenido protegido. Esa lista de precios es la respuesta oficial a la pregunta. Si la plataforma ya guardase tus datos a prueba de errores, no habría un contador de gigas al lado.
Dicho lo cual, y aunque en este párrafo nos estemos disparando al pie: una copia no arregla lo que se borró antes de que la copia existiera. La documentación es clara en que el contenido eliminado caduca de las copias cuando vence el periodo de retención de la copia —el ejemplo que da Microsoft son 365 días desde que se toma—. Contratar el backup en septiembre no devuelve lo que una política se llevó en agosto, y trescientos sesenta y cinco días de puntos de restauración son bastante menos que los años que una política de último acceso maneja como si nada. No somos resellers de ninguna plataforma concreta —recomendamos según el caso y no según la comisión—, así que tampoco te diremos que esa sea la única opción: hay herramientas de terceros y hay tenants pequeños donde la cuenta sale distinta. Lo que sí vamos a decirte es que la protección del dato en Microsoft 365 es una decisión que se toma, no una casilla que venga marcada.
Y un detalle de tarificación que conviene tener en la cabeza si alguien va a hacer números: el importe se calcula sobre el contenido protegido más el contenido eliminado que se retiene en la papelera de segunda fase. El ejemplo oficial de Microsoft es un sitio de 1 GB con 0,5 GB en la segunda papelera y un buzón de 1 GB con 1 GB de archivo: se facturan 3,5 GB. Es decir, que en los meses siguientes a una gran limpieza seguirás pagando por lo que borraste hasta que caduque de la copia. Es coherente y está bien explicado; simplemente no es lo que la gente asume al calcular el ahorro de borrar.
Borrar no es la única palanca para que Copilot responda mejor
Si el problema que quieres resolver es que Copilot saque cosas raras de un rincón del SharePoint, hay una herramienta que hace justo eso sin destruir nada. Se llama Restricted Content Discovery y es un ajuste por sitio: el contenido deja de aparecer en la búsqueda de toda la organización y en las respuestas de Copilot, y desaparecen del sitio los puntos de entrada de IA —el botón de Copilot, los menús de acciones de IA, la creación de páginas con IA—. La documentación insiste en dos cosas que nos parecen decisivas: no cambia los permisos, quien tenía acceso sigue entrando y trabajando como siempre, y no saca el contenido del índice de búsqueda, así que eDiscovery y el etiquetado automático de Purview siguen funcionando. Es la diferencia entre bajar la persiana y tirar el archivador.
# Sacar un sitio del alcance de Copilot y de la búsqueda global, sin borrar nada
Set-SPOSite -Identity <url-del-sitio> -RestrictContentOrgWideSearch $true
# Comprobar el estado de un sitio
Get-SPOSite -Identity <url-del-sitio> | Select RestrictContentOrgWideSearch
# Lo que sí conviene medir antes de una limpieza: la papelera que el usuario NO ve
Get-PnPRecycleBinItem -SecondStage
Con sus letras pequeñas, que también están en la documentación y que preferimos decir nosotros: requiere licencia de Microsoft 365 Copilot y SharePoint Advanced Management, no se puede aplicar a OneDrive, la propia página avisa de que abusar de ello reduce el contenido disponible y empeora la relevancia de las respuestas, y en sitios de más de 500.000 elementos el cambio puede tardar más de una semana en reflejarse. Pero es reversible, y esa palabra vale mucho aquí.
Cómo lo haríamos nosotros
No es un decálogo. Son cinco decisiones en el orden en que las tomaríamos, y la primera es la que más gente se salta.
- Primero mira, luego borra. La pregunta no es «¿cuánto tiempo dejamos?», es «¿qué se llevaría esto exactamente?». Las políticas de aplicación automática de etiquetas admiten modo de simulación cuando la condición son tipos de información confidencial o una consulta de palabras clave y propiedades: te enseña sobre qué ficheros aterrizaría la etiqueta antes de que aterrice. Con un matiz que conviene no confundir, porque es fácil: la simulación te dice el alcance, no qué acabará borrando el reloj del último acceso. Aun así es muchísimo más de lo que sabe quien activa directamente.
- Revisión de disposición en vez de borrado automático para todo lo legal, contractual, financiero y de documentación técnica: al vencer el plazo decide un humano y no un temporizador. Cuesta una firma cada X meses y convierte una pérdida silenciosa en una decisión con nombre y apellidos. Y ojo al detalle que decide el diseño entero: el aviso dice que la nueva condición se puede aplicar con una política o con una etiqueta de retención, y la revisión de disposición solo existe con etiqueta: la documentación lo dice con todas las letras, no está disponible para una directiva de retención. El modo de simulación tampoco lo tienen las políticas de retención —es cosa de las políticas de aplicación automática de etiquetas— y aun ahí Microsoft solo lo ofrece para condiciones concretas; si la nueva condición de último acceso entra en esa lista, todavía no lo dice nadie. Iríamos por etiquetas por lo primero, que sí está escrito, y comprobaríamos lo segundo en el asistente antes de prometerle nada a nadie.
- No empieces por todo el tenant. Elige un sitio donde el coste de equivocarse sea bajo —material de marketing antiguo, borradores, plantillas— y deja fuera desde el primer día las colecciones de contratos, planos, calidad y expedientes de personal. Ampliar el alcance después es fácil. Recuperar no.
- Deja escrito qué significa «acceso» en tu tenant, con la respuesta que te dé Microsoft o con la prueba que hagas tú. Si no puedes escribirlo, no puedes explicárselo a un auditor, y si no puedes explicárselo a un auditor, no lo actives sobre datos que ese auditor puede pedirte.
- Decide la copia antes, no el día 94. Si la respuesta a «¿y si esto se lleva algo que hacía falta?» es la papelera, entonces tu plan de recuperación dura noventa y tres días y no lo sabías. Lo mismo que decíamos del restaurar y recuperar en un incidente de ransomware: una copia que no has probado a restaurar no cuenta como copia.
Lo que sí y lo que no sabemos
La función no es mala y no vamos a fingir lo contrario. El problema que resuelve es real: hay tenants con años de sedimento donde nadie sabe ya qué hay, y ese sedimento no solo cuesta almacenamiento, también amplía la superficie de cualquier cosa que lea documentos, Copilot incluido. La usaremos. Cuántas empresas españolas van a activarla en modo eliminar este otoño, ni idea: no lo hemos medido y no nos lo vamos a inventar. Y seguimos sin saber qué cuenta como acceso.
Lo único que sí diremos, con toda la intención, es lo que no haríamos: activar esto en modo eliminar, sobre todo el tenant, a mediados de agosto, que es justo cuando termina el despliegue y justo cuando media plantilla está fuera. Un mes en el que casi nadie abre casi nada es el peor momento imaginable para estrenar una función que mide precisamente eso. Si tienes que tocarlo en agosto, tócalo con etiqueta y revisión de disposición, y en simulación si el asistente te la ofrece. En septiembre habrá tiempo, y habrá gente para preguntarle si de verdad no necesita ese fichero. Si quieres, esa conversación la tenemos contigo, y también la de cuántos años tienes que guardar cada cosa, que es la que casi nadie ha tenido y la que de verdad decide el plazo.
Por cierto, si estás repasando el tenant estos días, esto se hace bien de una sentada con el otro repaso pendiente: el de las aplicaciones conectadas que tienen permiso permanente sobre tus documentos. Una pregunta es qué se borra solo y la otra es quién lo lee sin pedir permiso; las dos se contestan mirando el mismo SharePoint.
Fuentes (verificadas): el anuncio de la función, sus fechas de vista previa y disponibilidad general, la limitación inicial a tipos de fichero de Microsoft 365, el «no requiere acción del administrador» y la frase sobre la calidad de las respuestas de Copilot proceden del mensaje MC999442 del centro de mensajes de Microsoft 365. La mecánica de borrado —el trabajo periódico de hasta siete días, el recorrido por la papelera de primera y segunda fase, los 93 días que abarcan ambas, que la de segunda fase no es visible para los usuarios finales, que la papelera no está indexada y que por tanto una búsqueda de eDiscovery no encuentra su contenido, el mínimo de 500 versiones principales por defecto, que al eliminar el documento se borran a la vez todas las versiones que no están en la biblioteca de conservación de documentos,— sale de «Más información sobre la retención para SharePoint y OneDrive» de Microsoft Learn. El precio de tarifa de 0,15 $/GB/mes, la caducidad del contenido eliminado al vencer el periodo de retención de la copia (365 días en el ejemplo de Microsoft) el cálculo de 3,5 GB facturables del ejemplo oficial y el comando Get-PnPRecycleBinItem -SecondStage del bloque de código, de «Modelo de precios de Microsoft 365 Backup». Lo relativo a Restricted Content Discovery —que no cambia los permisos, que no saca el contenido del índice de búsqueda y que eDiscovery y el etiquetado automático siguen funcionando, que no se puede aplicar a OneDrive, el requisito de licencia de Copilot y SharePoint Advanced Management, el aviso sobre el exceso de uso, los dos comandos Set-SPOSite y Get-SPOSite del bloque de código y el plazo de más de una semana en sitios de más de 500.000 elementos—, de «Restringir la detección de sitios y contenido de SharePoint». Que la revisión de disposición es exclusiva de las etiquetas está dicho con todas las letras en «Eliminación de contenido»: «activar una revisión de disposición al final del periodo de retención es una opción de configuración disponible únicamente con una etiqueta de retención. La revisión de disposición no está disponible para una directiva de retención». Que el modo de simulación es de las políticas de aplicación automática de etiquetas, y solo con condiciones de información confidencial o consulta de palabras clave y propiedades, sale de «Aplicar automáticamente una etiqueta de retención». Que ni el aviso ni la página de retención definen qué cuenta como último acceso es una comprobación nuestra sobre esos mismos documentos el 2 de agosto de 2026; si Microsoft lo publica después, esta parte del artículo caduca y nos alegraremos. Son criterio y opinión nuestros, no de las fuentes: que el último acceso mide comportamiento y no una propiedad del documento, la relación inversa entre frecuencia de acceso y valor en la documentación legal, el argumento del fallo silencioso, las cinco decisiones y lo que no haríamos en agosto.
¿Cuánto duraría en tu empresa un fichero borrado por error?
Repasamos contigo qué retiene y qué borra tu tenant hoy, qué pasa el día 94 y si lo que tienes es una copia o solo una papelera. Recomendando según el caso, no según la comisión.
Hablar con everyWAN