El que ningú obre, s'esborra: Purview, l'últim accés i els 93 dies per adonar-te'n

Pensa en el fitxer del teu SharePoint que fa més temps que ningú no obre. L'escriptura del local. El plànol as-built de la instal·lació. L'informe pericial d'aquell litigi. El certificat de la màquina que va comprar el teu antecessor. Ara pensa quin de tots et farà falta algun dia, i amb quina urgència. És probable que sigui el mateix. A mitjan agost Microsoft acaba de desplegar la possibilitat d'esborrar automàticament exactament aquest fitxer, amb l'argument que així el Copilot respondrà millor. No l'esborra tot sol —algú ho ha de configurar—, però el botó hi serà, i serà molt fàcil de prémer.

Què arriba exactament, i què no

L'avís és al centre de missatges de Microsoft 365 amb la referència MC999442, i es titula «Retenció basada en l'últim accés per a fitxers de l'OneDrive i el SharePoint». La vista prèvia va arrencar a finals de juny del 2026 i la disponibilitat general a finals de juliol; Microsoft espera completar-les totes dues a mitjan agost. En cristià: a partir d'ara, a més de poder retenir o esborrar per data de creació, de modificació o d'etiquetatge, es pot fer per «no l'ha obert ningú de la teva organització des de fa X». De moment aplica a tipus de fitxer de Microsoft 365; la resta de formats, diu l'avís, en un desplegament futur.

Abans de continuar, la part honesta, perquè si la saltem la resta de l'article és alarmisme: això no esborra res tot sol. El mateix avís diu que el desplegament és automàtic i que no requereix cap acció de l'administrador; el que arriba és l'opció al desplegable, no una política activa. Si ningú no crea una política de retenció amb acció d'eliminar sobre aquesta condició, al teu tenant no desapareixerà ni un sol fitxer. La nostra preocupació no és el desplegament. És la facilitat del gest i la qualitat de l'argument amb què es demanarà.

Perquè l'argument ve escrit al mateix avís: la funció «ajudarà a eliminar dades obsoletes, cosa que millorarà la qualitat i la rellevància de les respostes del Microsoft 365 Copilot». És un motiu tècnicament raonable —un índex ple de brossa degrada qualsevol sistema de recuperació— i alhora és el primer cop que veiem una funció d'esborrat al Microsoft 365 justificada per la qualitat de les respostes d'una IA. Convé notar-ho, perquè canvia qui demana el botó: la persona que vol que el Copilot respongui millor no és la mateixa que necessitarà el fitxer del 2021 el 2029, i cap de les dues és la que signa el qüestionari de compliment del client gran.

El disparador ja no és una propietat del fitxer

Aquí hi ha, per a nosaltres, el que és realment interessant, i no ho hem vist explicat enlloc. Data de creació i data de modificació són propietats del document: les va escriure algú que hi va fer alguna cosa deliberadament. «Últim accés» no és una propietat del document; és una mesura del comportament de la teva organització. Un fitxer no es torna vell perquè ningú no el miri, igual que un extintor no caduca perquè ningú no l'utilitzi.

I la conseqüència és incòmoda, perquè per a tota una família de documents la relació entre freqüència d'accés i valor és inversa. Els contractes signats, les escriptures, els certificats de conformitat, els plànols definitius, els informes d'auditoria, les actes: s'obren un cop quan se signen i no es tornen a tocar fins que hi ha un problema. Que ningú no els hagi obert en tres anys no vol dir que sobrin; vol dir que en tres anys no hi ha hagut cap inspecció, cap reclamació i cap litigi. És una bona notícia sobre l'empresa, no un veredicte sobre el fitxer.

I ningú no ha dit encara què compta com a «obrir»

Aquesta és la pregunta que decideix si la funció és útil o perillosa, i a dia d'avui no té resposta pública. Ni l'avís del centre de missatges ni la pàgina de Microsoft Learn sobre retenció per al SharePoint i l'OneDrive defineixen quin esdeveniment actualitza aquesta data d'últim accés. La segona esmenta els inicis de retenció per creació, modificació, etiquetatge i esdeveniment, i de la nova condició encara no en diu res. És un Ctrl+F: comprova-ho tu mateix abans de creure'ns.

No ens inventarem la resposta. Deixarem escrites les quatre preguntes la resposta de les quals canvia completament el resultat, perquè són les que faríem a Microsoft abans de configurar res:

Fixa't que els dos errors possibles apunten en direccions oposades i tots dos són dolents. Si gairebé tot compta com a accés, muntes una política de neteja que no neteja i et quedes tan ample. Si gairebé res no compta, esborres documents vius que simplement es consulten poc. Configurar un esborrat irreversible sobre un senyal que no està documentat és exactament la mena de decisió que després no es pot defensar per escrit, i per escrit és com es responen les auditories.

93 dies, i són dies de silenci

La mecànica de l'esborrat sí que està documentada, i convé tenir-la clara perquè marca el teu únic marge real. Quan una política de només eliminació compleix el termini, un procés periòdic —que pot trigar fins a set dies a executar-se— mou el document a la paperera de primera fase. Si algú la buida, passa a la de segona. Un termini de 93 dies abraça totes dues, i en acabar el document s'esborra permanentment sigui on sigui. Aquest número és la teva finestra de recuperació completa: no la del contracte del Microsoft 365, no la de la teva política de retenció. Noranta-tres dies.

I ara la part que ens sembla la més important de tot l'article. Aquests 93 dies transcorren en silenci, per construcció. Qualsevol altra pèrdua de dades té un senyal de detecció: algú obre una incidència perquè no troba alguna cosa. Aquí la política esborra, amb precisió quirúrgica, justament els fitxers que ningú no mira. Ningú no els trobarà a faltar, perquè «ningú no els mira» era el criteri de selecció. No hi haurà tiquet. No hi haurà trucada. Per rematar-ho, la documentació de Microsoft és explícita que la paperera no està indexada i per tant no s'hi pot cercar, de manera que una cerca d'eDiscovery no en troba el contingut per posar-hi una retenció. Ni cercant no apareix. Traduït a un pla de treball: la detecció d'aquesta fallada no pot ser reactiva, ha d'estar al calendari abans que el problema existeixi.

Els tres salvavides que la gent es pensa que té

Quan plantegem això en una reunió, la resposta sol ser una d'aquestes tres. Cap no aguanta.

Ho vam escriure fa poc arran d'un cas moltíssim més greu i el fons és el mateix: quan el sistema esborra i la còpia se'n va amb ell, la dada no torna. Allà l'esborrat va ser accidental i aquí és una funció que fa la seva feina, però la dada desapareguda no distingeix entre les dues coses.

Microsoft ven l'airbag a part, i aquesta és la dada

Fa anys que repetim que el Microsoft 365 no fa les teves còpies de seguretat i fa anys que veiem cares d'escepticisme. La discussió es va acabar fa temps i no cal que la guanyem nosaltres: Microsoft té un producte anomenat Microsoft 365 Backup, de pagament per ús, amb preu de tarifa de 0,15 dòlars per GB i mes de contingut protegit. Aquesta llista de preus és la resposta oficial a la pregunta. Si la plataforma ja guardés les teves dades a prova d'errors, no hi hauria un comptador de gigues al costat.

Dit això, i encara que en aquest paràgraf ens estiguem disparant al peu: una còpia no arregla el que es va esborrar abans que la còpia existís. La documentació és clara que el contingut eliminat caduca de les còpies quan venç el període de retenció de la còpia —l'exemple que dona Microsoft són 365 dies des que es pren—. Contractar el backup al setembre no torna el que una política es va endur a l'agost, i tres-cents seixanta-cinc dies de punts de restauració són bastant menys que els anys que una política d'últim accés maneja com si res. No som resellers de cap plataforma concreta —recomanem segons el cas i no segons la comissió—, així que tampoc no et direm que aquesta sigui l'única opció: hi ha eines de tercers i hi ha tenants petits on el compte surt diferent. El que sí que et direm és que la protecció de la dada al Microsoft 365 és una decisió que es pren, no una casella que vingui marcada.

I un detall de tarifació que convé tenir al cap si algú farà números: l'import es calcula sobre el contingut protegit més el contingut eliminat que es reté a la paperera de segona fase. L'exemple oficial de Microsoft és un lloc d'1 GB amb 0,5 GB a la segona paperera i una bústia d'1 GB amb 1 GB d'arxiu: es facturen 3,5 GB. És a dir, que els mesos següents a una gran neteja continuaràs pagant pel que vas esborrar fins que caduqui de la còpia. És coherent i està ben explicat; simplement no és el que la gent assumeix quan calcula l'estalvi d'esborrar.

Esborrar no és l'única palanca perquè el Copilot respongui millor

Si el problema que vols resoldre és que el Copilot tregui coses estranyes d'un racó del SharePoint, hi ha una eina que fa justament això sense destruir res. Es diu Restricted Content Discovery i és un ajust per lloc: el contingut deixa d'aparèixer a la cerca de tota l'organització i a les respostes del Copilot, i desapareixen del lloc els punts d'entrada d'IA —el botó del Copilot, els menús d'accions d'IA, la creació de pàgines amb IA—. La documentació insisteix en dues coses que ens semblen decisives: no canvia els permisos, qui tenia accés continua entrant i treballant com sempre, i no treu el contingut de l'índex de cerca, de manera que l'eDiscovery i l'etiquetatge automàtic del Purview continuen funcionant. És la diferència entre abaixar la persiana i llençar l'arxivador.

# Treure un lloc de l'abast del Copilot i de la cerca global, sense esborrar res
Set-SPOSite -Identity <url-del-sitio> -RestrictContentOrgWideSearch $true

# Comprovar l'estat d'un lloc
Get-SPOSite -Identity <url-del-sitio> | Select RestrictContentOrgWideSearch

# El que sí que convé mesurar abans d'una neteja: la paperera que l'usuari NO veu
Get-PnPRecycleBinItem -SecondStage

Amb les seves lletres petites, que també són a la documentació i que preferim dir nosaltres: requereix llicència de Microsoft 365 Copilot i SharePoint Advanced Management, no es pot aplicar a l'OneDrive, la mateixa pàgina avisa que abusar-ne redueix el contingut disponible i empitjora la rellevància de les respostes, i en llocs de més de 500.000 elements el canvi pot trigar més d'una setmana a reflectir-se. Però és reversible, i aquesta paraula val molt aquí.

Com ho faríem nosaltres

No és un decàleg. Són cinc decisions en l'ordre en què les prendríem, i la primera és la que més gent es salta.

1. Primer mira, després esborra. La pregunta no és «quant temps deixem?», és «què s'enduria això exactament?». Les polítiques d'aplicació automàtica d'etiquetes admeten mode de simulació quan la condició són tipus d'informació confidencial o una consulta de paraules clau i propietats: t'ensenya sobre quins fitxers aterraria l'etiqueta abans que hi aterri. Amb un matís que convé no confondre, perquè és fàcil: la simulació et diu l'abast, no què acabarà esborrant el rellotge de l'últim accés. Tot i així és moltíssim més del que sap qui activa directament.
2. Revisió de disposició en lloc d'esborrat automàtic per a tot el que és legal, contractual, financer i de documentació tècnica: en vèncer el termini decideix un humà i no un temporitzador. Costa una signatura cada X mesos i converteix una pèrdua silenciosa en una decisió amb nom i cognoms. I atenció al detall que decideix el disseny sencer: l'avís diu que la nova condició es pot aplicar amb una política o amb una etiqueta de retenció, i la revisió de disposició només existeix amb etiqueta: la documentació ho diu amb totes les lletres, no està disponible per a una directiva de retenció. El mode de simulació tampoc no el tenen les polítiques de retenció —és cosa de les polítiques d'aplicació automàtica d'etiquetes— i encara així Microsoft només l'ofereix per a condicions concretes; si la nova condició d'últim accés entra en aquesta llista, encara no ho diu ningú. Aniríem per etiquetes pel primer, que sí que està escrit, i comprovaríem el segon a l'assistent abans de prometre res a ningú.
3. No comencis per tot el tenant. Tria un lloc on el cost d'equivocar-se sigui baix —material de màrqueting antic, esborranys, plantilles— i deixa fora des del primer dia les col·leccions de contractes, plànols, qualitat i expedients de personal. Ampliar l'abast després és fàcil. Recuperar no.
4. Deixa escrit què significa «accés» al teu tenant, amb la resposta que et doni Microsoft o amb la prova que facis tu. Si no pots escriure-ho, no pots explicar-ho a un auditor, i si no pots explicar-ho a un auditor, no ho activis sobre dades que aquest auditor et pot demanar.
5. Decideix la còpia abans, no el dia 94. Si la resposta a «i si això s'endú alguna cosa que calia?» és la paperera, aleshores el teu pla de recuperació dura noranta-tres dies i no ho sabies. El mateix que dèiem de restaurar i recuperar en un incident de ransomware: una còpia que no has provat a restaurar no compta com a còpia.

El que sí i el que no sabem

La funció no és dolenta i no farem veure el contrari. El problema que resol és real: hi ha tenants amb anys de sediment on ningú no sap ja què hi ha, i aquest sediment no només costa emmagatzematge, també amplia la superfície de qualsevol cosa que llegeixi documents, el Copilot inclòs. La farem servir. Quantes empreses espanyoles l'activaran en mode eliminar aquesta tardor, ni idea: no ho hem mesurat i no ens ho inventarem. I continuem sense saber què compta com a accés.

L'única cosa que sí que direm, amb tota la intenció, és el que no faríem: activar això en mode eliminar, sobre tot el tenant, a mitjan agost, que és just quan acaba el desplegament i just quan mitja plantilla és fora. Un mes en què gairebé ningú no obre gairebé res és el pitjor moment imaginable per estrenar una funció que mesura precisament això. Si l'has de tocar a l'agost, toca'l amb etiqueta i revisió de disposició, i en simulació si l'assistent te l'ofereix. Al setembre hi haurà temps, i hi haurà gent per preguntar-li si de debò no necessita aquell fitxer. Si vols, aquesta conversa la tenim amb tu, i també la de quants anys has de guardar cada cosa, que és la que gairebé ningú no ha tingut i la que de debò decideix el termini.

Per cert, si estàs repassant el tenant aquests dies, això es fa bé d'una asseguda amb l'altre repàs pendent: el de les aplicacions connectades que tenen permís permanent sobre els teus documents. Una pregunta és què s'esborra tot sol i l'altra és qui ho llegeix sense demanar permís; totes dues es contesten mirant el mateix SharePoint.

Fonts (verificades): l'anunci de la funció, les dates de vista prèvia i disponibilitat general, la limitació inicial a tipus de fitxer de Microsoft 365, el «no requereix acció de l'administrador» i la frase sobre la qualitat de les respostes del Copilot provenen del missatge MC999442 del centre de missatges de Microsoft 365. La mecànica d'esborrat —el treball periòdic de fins a set dies, el recorregut per la paperera de primera i segona fase, els 93 dies que abracen totes dues, que la de segona fase no és visible per als usuaris finals, que la paperera no està indexada i que per tant una cerca d'eDiscovery no en troba el contingut, el mínim de 500 versions principals per defecte, que en eliminar el document s'esborren alhora totes les versions que no són a la biblioteca de conservació de documents,— surt de «Més informació sobre la retenció per al SharePoint i l'OneDrive» de Microsoft Learn. El preu de tarifa de 0,15 $/GB/mes, la caducitat del contingut eliminat en vèncer el període de retenció de la còpia (365 dies a l'exemple de Microsoft) el càlcul de 3,5 GB facturables de l'exemple oficial i l'ordre Get-PnPRecycleBinItem -SecondStage del bloc de codi, de «Model de preus del Microsoft 365 Backup». El que fa referència al Restricted Content Discovery —que no canvia els permisos, que no treu el contingut de l'índex de cerca i que l'eDiscovery i l'etiquetatge automàtic continuen funcionant, que no es pot aplicar a l'OneDrive, el requisit de llicència de Copilot i SharePoint Advanced Management, l'avís sobre l'excés d'ús, les dues ordres Set-SPOSite i Get-SPOSite del bloc de codi i el termini de més d'una setmana en llocs de més de 500.000 elements—, de «Restringir la detecció de llocs i contingut del SharePoint». Que la revisió de disposició és exclusiva de les etiquetes està dit amb totes les lletres a «Eliminació de contingut»: «activar una revisió de disposició al final del període de retenció és una opció de configuració disponible únicament amb una etiqueta de retenció. La revisió de disposició no està disponible per a una directiva de retenció». Que el mode de simulació és de les polítiques d'aplicació automàtica d'etiquetes, i només amb condicions d'informació confidencial o consulta de paraules clau i propietats, surt d'«Aplicar automàticament una etiqueta de retenció». Que ni l'avís ni la pàgina de retenció defineixen què compta com a últim accés és una comprovació nostra sobre aquests mateixos documents el 2 d'agost del 2026; si Microsoft ho publica després, aquesta part de l'article caduca i ens n'alegrarem. Són criteri i opinió nostres, no de les fonts: que l'últim accés mesura comportament i no una propietat del document, la relació inversa entre freqüència d'accés i valor a la documentació legal, l'argument de la fallada silenciosa, les cinc decisions i el que no faríem a l'agost.