Privacy e segregation in Accordo: gli 8 confini scritti

In breve. Sulla privacy Accordo non ha niente da vendere e lo scrive: il catalogo data governance registra 8 job e 8 non supportati. Niente consenso, niente opt-out trasversale, niente accesso del soggetto, niente retention eseguita, niente RBAC. È mia l'interpretazione che li rende utili lo stesso: un confine scritto prima delle feature è ciò che impedisce di promettere ciò che non c'è. La mappa è nell'hub data governance, la meccanica esistente in data operations.

Il soggetto: consenso, opt-out, accesso

Tre job dicono la stessa assenza da tre lati. Il job JTBD-DG-01, registrare consenso e base giuridica: non supportato, nessuna primitiva di consenso. Onorare un opt-out su tutti i percorsi di uscita: non supportato, niente percorsi di uscita e niente lista di soppressione. Esportare tutto ciò che si detiene su un soggetto: non supportato, nessun percorso di accesso del soggetto. Non sono tre sfumature: sono tre primitive che non esistono, e senza la prima le altre due non avrebbero dove appoggiarsi.

Il tempo: retention, cancellazione, prova

Il disegno più duro del tracciato è il job JTBD-DG-04: anonimizzare o cancellare un soggetto preservando evidence immutabili. Le evidence commerciali sono deliberatamente immutabili, la fondazione non anonimizza e non cancella niente, il collegamento canonico non cancella niente, e governare un finding registra una decisione tenendo finding ed evidence. L'unico fatto collegato è negativo e stretto: nessun payload grezzo del provider viene trattenuto da un import — meno di ciò che la riga chiede, non un passo verso di essa.

Applicare una retention policy e provare che è girata: non supportato — policy e esecuzione che produce evidence non implementate, e job durevoli generici più richieste schedulate non le forniscono. Provare che una cancellazione è completata: non supportato, dipende dalla riga sopra. Il tempo nei dati ha due facce — trattenere per regola e cancellare per richiesta — ed entrambe mancano.

La segregation: ruoli e provider

Il job JTBD-DG-07, restringere i campi sensibili per ruolo: non supportato, serve RBAC. Ispezionare cosa è stato condiviso con quale provider: non supportato, il tracciato registra solo provenienza in ingresso. Sono i due confini di segregation: dentro, chi può vedere cosa; fuori, cosa è uscito verso chi. Dentro manca il meccanismo dei ruoli; fuori manca il registro, e la provenienza in ingresso non lo sostituisce — sapere da dove un dato è venuto non dice dove è andato.

Fatti e limiti, separati

Fatti: 8 job di governance, 8 non supportati; nessuna primitiva di consenso, nessuna lista di soppressione, nessun percorso di accesso; evidence commerciali immutabili con finding che si governano senza cancellarsi; nessun payload grezzo trattenuto dagli import; provenienza solo in ingresso; RBAC assente. Ogni stato si muove solo quando un test lo prova.

Limiti: questo articolo descrive vincoli, non capacità — non c'è niente da attivare, configurare o comprare; la segregation esiste solo come requisito scritto; la pagina dei job descrive il repository a un commit, non una roadmap. Un confine onesto non è quasi una feature: è il motivo per cui le feature promesse altrove restano credibili.

Domande frequenti

A cosa serve pubblicare ciò che non esiste?

A rendere controllabili le promesse: con otto righe scritte, ogni claim di un altro articolo si verifica contro di esse. Se un giorno un testo dirà che Accordo segrega per ruolo, questa pagina dirà se è vero.

Perché l'immutabilità blocca la cancellazione?

Perché le evidence commerciali sono immutabili per disegno — una prova riscrivibile non è prova — e cancellare un soggetto senza romperle è il disegno più duro del tracciato. La fondazione non ci prova nemmeno: anonimizza e cancella niente.

La provenienza in ingresso non basta per gli audit?

No. Dice da dove un dato è venuto, non dove è andato né chi l'ha visto: per l'audit serve anche il registro delle condivisioni, che non esiste, e la segregation per ruolo, che richiede RBAC.