Data governance nel CRM: igiene, operazioni e confini

In breve. La data governance di Accordo sta in tre strati, ed è mia l'interpretazione che li ordina così: l'igiene, che è provata; le operazioni, che sono mezze supportate; i confini privacy, che non sono supportati e restano scritti come vincoli. Questo hub tiene insieme i tre pezzi — igiene dati: niente AI senza dati puliti, data operations tra fatti e limiti, privacy e segregation: i confini scritti — e il pezzo dei record da cui tutto parte, da archivio contatti a customer hub. Qui solo la mappa; i fatti stanno negli articoli.

Lo strato provato: l'igiene

Prima di ogni intelligenza viene l'igiene, e qui Accordo ha meccanica verificata: retry che apre un successore invece di resuscitare la riga morta, dedupe deterministica per chiave, matching che decide sempre allo stesso modo, ricevute per ogni riga importata. La disciplina completa è nell'articolo sull'igiene dati: non è pulizia, è contratto — ogni dato ha una semantica di fallimento e una provenienza.

Lo strato parziale: le operazioni

Sopra l'igiene stanno le operazioni quotidiane sui dati: importare, deduplicare, unire, esportare, aggiornare in massa, rileggere la storia di un record. Il catalogo data operations di Accordo registra 9 job, 6 parzialmente supportati e 3 non supportati: import bounded con ricevute ma senza CSV, matching deterministico ma solo in import, merge logico ma non fisico, export con bound ma non sui record commerciali. Il giro completo è in data operations tra fatti e limiti.

Lo strato assente: i confini privacy

Il terzo strato è quello che manca, ed è il motivo per cui esiste questo hub: il catalogo data governance di Accordo registra 8 job e 8 non supportati — niente consenso, niente opt-out, niente accesso del soggetto, niente retention eseguita, niente RBAC. Il disegno più duro è anonimizzare senza rompere l'immutabilità delle evidence commerciali. I confini scritti uno per uno sono in privacy e segregation: i confini scritti.

Fatti e limiti, separati

Fatti: catalogo data operations con 9 job, 6 parzialmente supportati e 3 non supportati; catalogo data governance con 8 job, 8 non supportati; igiene con retry con successore, dedupe per chiave, matching deterministico e ricevute per riga; tutti gli stati misurati sul repository a un commit dato, con la regola che una riga esce dal non supportato solo quando un test la prova.

Limiti: la fondazione customer completa ha la PR aperta e non mergiata, quindi non è live; nessun job di governance è usabile; tre job operativi mancano del tutto — viste salvate, ricerca globale, note e allegati. Una mappa onesta non misura quanto il disegno regga in produzione: misura cosa esiste, cosa è a metà e cosa non c'è.

Domande frequenti

Perché un hub su tre strati di cui uno manca?

Perché lo strato mancante è il vincolo che governa gli altri due: sapere che il consenso e la segregation non esistono decide cosa si può promettere con igiene e operazioni. Un hub senza il terzo strato sarebbe marketing.

Da dove si parte a leggere il cluster?

Dall'igiene dati, che è lo strato provato; poi le operazioni, poi i confini. Ognuno rimanda agli altri due e al catalogo job corrispondente.

Gli stati del catalogo valgono per il mio deploy?

No. Gli stati descrivono il repository a un commit, e il framework non spedisce autenticazione: ogni deploy deve fornire il suo verificatore. La pagina dei job lo scrive in chiaro, io lo ripeto qui.