Cosa Conserva Rexfin, Cosa Elimina, e Come Funziona Davvero la Cancellazione

«Per quanto tempo conservate i nostri dati, e potete davvero cancellarli quando ce ne andiamo?» è una delle prime domande che una revisione di sicurezza pone, ed è una domanda giusta. La maggior parte dei fornitori risponde con un documento di policy. Rexfin risponde con un meccanismo, perché la versione onesta di «lo cancelliamo» deve reggere il confronto con un sistema che mantiene anche una traccia di audit a prova di manomissione di ogni numero verificato che ha mai prodotto.

Non tutto ciò che è nella piattaforma è lo stesso tipo di dato

La prima cosa che fa Rexfin è smettere di trattare tutto il materiale memorizzato come un unico blocco indistinto. Ogni documento, cifra estratta, risposta in cache, e record di audit porta una classificazione di sensibilità, ereditata dal deal a cui appartiene e affinata per singolo artefatto dove necessario. Quella classificazione non è decorativa: determina quali sedi di elaborazione e quali fornitori di modelli sono anche solo idonei a toccare i dati, un collegamento descritto più nel dettaglio in come Rexfin governa quali fornitori LLM possono vedere i tuoi dati. Un artefatto senza classificazione risolvibile viene impostato di default sul livello più restrittivo, mai su quello più permissivo, e declassare una classificazione richiede un’azione esplicita e tracciata: non puoi silenziosamente riclassificare qualcosa come meno sensibile.

La classificazione divide anche i dati in due cicli di vita rilevanti per la conservazione: i dati effettivi durevoli, le cifre estratte e le pagine sorgente che costituiscono l’evidenza dietro ogni numero, e gli artefatti derivati transitori, risposte in cache, scenari di simulazione what-if, indici di retrieval. La prima categoria è ciò su cui poggia il valore del prodotto. La seconda è ricalcolabile, e conservarla indefinitamente è un rischio senza alcun vantaggio.

Finestre di conservazione, e un’esenzione per blocco legale

Gli artefatti transitori hanno una finestra di conservazione, impostata per tipo di artefatto e per classificazione: una risposta in cache di livello riservato può scadere più rapidamente di una a sensibilità inferiore. Un job pianificato elimina ciò che ha superato la propria finestra, e lo fa senza toccare gli atomi durevoli da cui è stato derivato: se una risposta in cache scompare, Rexfin la ricalcola semplicemente la volta successiva che qualcuno la richiede, invece di generare un errore. È lo scambio che questo design fa deliberatamente: puoi minimizzare in modo aggressivo l’impronta sensibile proprio perché gli atomi sottostanti e il verificatore possono sempre riprodurre qualunque cosa venga eliminata.

Un deal sotto blocco legale è completamente esente da tutto questo. Applicare un blocco è un’azione tracciata e deliberata, e una volta impostato, nulla in quel deal viene eliminato o cancellato indipendentemente dall’età, finché il blocco non viene rilasciato. Questa è la valvola di sicurezza che impedisce alla minimizzazione automatica dei dati di distruggere prove che una controversia o un ente regolatore ha congelato.

Cancellare un deal, e dimostrare di averlo fatto

Quando un cliente termina il rapporto, o un interessato esercita un diritto alla cancellazione, Rexfin esegue una cancellazione mirata: ogni riga e file associato a quel deal, documenti, atomi estratti, celle del modello, esportazioni, risposte in cache, viene rimosso, e nulla appartenente a un deal diverso viene toccato. L’output non è semplicemente “fatto”: è un manifest firmato che elenca cosa è stato eliminato, da chi, su quale base, che il responsabile della protezione dei dati di un cliente può conservare come prova che la cancellazione è effettivamente avvenuta, invece di un ticket di supporto che dice “gestito”.

La parte davvero difficile: cancellare da un registro append-only

Ecco la tensione che vale la pena affrontare con onestà. Il log di audit delle risposte di Rexfin è deliberatamente append-only e a prova di manomissione, ed è proprio questo che rende una risposta verificata controllabile in autonomia mesi dopo. Ma un registro append-only e una richiesta di diritto alla cancellazione tirano in direzioni opposte: non puoi sia conservare ogni verdetto per sempre sia onorare una richiesta di cancellazione.

La soluzione è la crypto-erasure. Il payload di ogni record di audit è cifrato sotto una propria chiave. Per cancellarlo, Rexfin distrugge quella chiave: il testo cifrato diventa permanentemente illeggibile, mentre l’hash del record resta nella catena a prova di manomissione. La radice pubblicata continua a verificarsi, e l’assenza del contenuto di quel record è dimostrabile invece di essere una lacuna silenziosa che sembrerebbe manomissione. La cancellazione non riscrive la storia: rende un payload specifico permanentemente irrecuperabile lasciando comunque la prova che qualcosa esisteva in quel punto ed è stato cancellato legittimamente.

Cosa questo non dichiara

Rexfin non sta rivendicando una certificazione qui: l’inquadramento onesto è che questi controlli sono progettati per soddisfare le aspettative di limitazione della conservazione e di cancellazione che compaiono nei framework di protezione dei dati GCC e nelle clausole di offboarding aziendale in generale. Le finestre di conservazione sono configurazione, non una promessa in una presentazione, e l’ambito è deliberatamente ristretto: una cancellazione tocca sempre e solo i dati di un tenant, verificato da test che seminano due deal e confermano che la cancellazione di uno lascia l’altro intatto byte per byte.

Se vuoi vedere come questo si inserisce nell’approccio più ampio della piattaforma per mantenere il sistema stesso difendibile dopo un’interruzione o un ripristino andato male, è trattato in affidabilità e disaster recovery. Per il quadro completo di come è costruito Rexfin, parti dall’hub Dentro la piattaforma Rexfin.