Nel gestionale della tua azienda ci sono campi con nomi come FLG_C3, e cosa ci sia scritto dentro lo sanno in due persone.
Finché a leggerli sono quelle due persone, funziona. Il conto arriva quando davanti a quei campi ci metti un agente, o quando devi dire quali dati personali tratti e dove stanno.
Il campo che sanno leggere in due
I nomi illeggibili sono il sedimento di quindici anni di lavoro, e si formano sempre allo stesso modo.
Il campo è nato nel 2011 con una personalizzazione chiesta al fornitore, che l'ha chiamato come gli è venuto. Poi il processo è cambiato e quel campo è stato riusato per un'altra cosa, senza rinominarlo, perché rinominarlo significava rifare le stampe. Il consulente che l'aveva aggiunto non lavora più lì. Resta il capo ufficio, che sa che quando c'è la spunta la pratica va in un modo e quando non c'è va in un altro.
Quella conoscenza non è nel database. È nella testa di due persone, e il database contiene solo la sua conseguenza.
È lo stesso problema che si presenta sui documenti, dove la versione buona la conosce chi era alla riunione: se ti interessa quel lato, l'abbiamo raccontato in tre controlli da fare sui documenti prima dell'AI. Qui parliamo dei dati strutturati, cioè delle tabelle e dei campi, dove il problema è più scomodo per un motivo: un documento almeno si legge, un campo che si chiama FLG_C3 no.
Trent'anni di lavoro, al ritmo di una colonna al minuto
Lo stesso problema, in grande, lo hanno descritto tre ricercatori di Apple — Kostia Kudriavtsev, Parvez Rafi e Sha Sundaram — in un articolo pubblicato su arXiv il 9 settembre 2026. Descrive Glyph, un sistema che documenta e classifica automaticamente le colonne di un catalogo dati aziendale.
Prima dei numeri, cosa sono: è un preprint, cioè un articolo pubblicato senza revisione fra pari, e le misure le hanno fatte gli autori sul proprio sistema. Vanno letti così. L'affiliazione è dichiarata, gli indirizzi di posta sono tutti e tre di Apple, ma il catalogo che descrivono è quello di una sola organizzazione, che l'articolo non nomina.
Quel catalogo ha circa 3,4 milioni di colonne su circa 98.000 tabelle, distribuite su quattro linee di business e tre tecnologie di archiviazione diverse. Il numero che rende la cosa concreta è un altro: anche a un ritmo ottimistico di una colonna al minuto, documentare a mano quel catalogo richiederebbe circa trent'anni di lavoro di una persona esperta — e nel frattempo il catalogo cambia più in fretta di quanto qualunque squadra riesca a stargli dietro.
Glyph è fatto di due agenti. Il Descriptor risponde alla domanda «cosa significa questa colonna» e ne scrive la descrizione in parole normali. Il Tagger risponde alla domanda «che categoria di dato contiene» e le assegna una o più etichette prese da un elenco governato.
Nessuna delle due parti è una tecnica nuova, e gli autori lo scrivono: il contributo è la composizione. È la stessa cosa che serve in un'azienda da trenta persone, con due differenze di scala e zero differenze di sostanza.
Documentare un campo senza leggerne i valori
La scelta più esportabile del lavoro è anche la più controintuitiva. Per capire cosa contiene una colonna, Glyph non la apre.
Il Descriptor legge il codice sorgente che quella colonna la riempie, cercandolo da solo nel GitHub aziendale: decide quali ricerche fare, legge il contesto intorno a ogni risultato e ricostruisce il significato del campo da lì. Nell'articolo la frase è netta: «the evidence is code, not data — the Descriptor never reads column values», cioè la prova è il codice, non i dati, e il Descriptor non legge mai i valori delle colonne.
La ragione è pratica. Gli autori spiegano che per i dati più delicati leggere i valori per classificarli è proprio l'operazione che le regole interne vietano finché una classificazione non esiste: serve la classificazione per avere il permesso di guardare, e serve guardare per fare la classificazione. Lavorando su codice e metadati il sistema gira anche sulle tabelle i cui valori non potrebbe leggere.
In una PMI il GitHub aziendale non c'è, e il paragone va fatto sul contenuto. La documentazione di un campo si ricostruisce a partire da chi lo scrive: la maschera che lo compila, la procedura che dice quando spuntarlo, la stampa che lo usa, la persona che lo riempie tutti i giorni. È materiale che si può guardare senza aprire una sola riga dell'anagrafica clienti.
Ed è la differenza che decide chi può fare il lavoro. Se documentare i campi richiede di leggere i dati dentro, il lavoro lo può fare solo chi ha accesso a quei dati — cioè quasi nessuno, e comunque non un consulente esterno. Se richiede di leggere quello che li produce, lo può fare chi conosce il processo.
Dieci millesimi: quanto vale davvero la parte intelligente
Il Tagger fa girare tre strategie in parallelo. Una ragiona sulla descrizione della colonna, una applica regole scritte a mano sui nomi dei campi, una confronta il nome completo della colonna con un archivio di assegnazioni passate già verificate da persone. Le tre classifiche vengono poi fuse insieme.
Gli autori misurano il risultato con un indice chiamato F₂, che pesa il doppio la capacità di non lasciarsi sfuggire una colonna sensibile rispetto a quella di non esagerare con le etichette. È la scelta giusta per il problema: una colonna sensibile lasciata senza etichetta si scopre dopo un incidente, un'etichetta di troppo la cancella un revisore in dieci secondi.
Sugli stessi quattro file di valutazione, raggruppati in tre insiemi, i risultati complessivi sono questi:
- le sole regole scritte a mano: F₂ 0,050, praticamente niente, perché scattano solo sui nomi che qualcuno aveva previsto;
- la sola strategia che ragiona sulla descrizione: 0,238 in 47,3 secondi di latenza mediana, e vale solo per le colonne che una descrizione ce l'hanno già;
- il solo confronto con le assegnazioni passate: 0,880, in 40,4 secondi;
- tutte e tre fuse insieme: 0,890, in 57,8 secondi.
Dieci millesimi. Tutta la macchina a tre strategie, con la fusione e il modello che rilegge e riordina, aggiunge dieci millesimi a quello che fa da solo il pezzo più noioso del sistema: un archivio di decisioni che dei revisori umani avevano già preso, cercato per somiglianza. E li aggiunge costando diciassette secondi in più a richiesta, il 43% di latenza.
Quel 0,880 non è memoria: le tabelle su cui il sistema è misurato — 1.905 — sono tutte fuori dall'archivio su cui ha imparato, che ne contiene 15.205. Nessuna delle colonne valutate era già stata vista.
Il confronto cambia a seconda di come pesi gli errori, e gli autori lo dicono: con F₂ vince la fusione, con l'indice più comune, F₁, i due valori sono 0,912 per il solo archivio e 0,897 per la fusione e li considerano pari, e con un indice che premia la precisione passa avanti la strategia singola. La conclusione la scrivono loro: «The operative deployment choice is therefore metadata-only versus full fusion», la scelta vera è fra il solo archivio e tutta la macchina.
La lezione per chi valuta un fornitore non è che la parte intelligente sia inutile. È che la parte intelligente è una fetta più piccola di quanto la si racconti, e quella che porta il risultato è l'archivio delle decisioni già prese. Quell'archivio, in azienda, o c'è o non c'è. E se c'è, di solito non è in un sistema: è in un foglio Excel di qualcuno.
Da sei su dieci a quasi dieci su dieci
La seconda cosa che si porta via da questo lavoro è un numero raro: quanto migliora un sistema quando le correzioni delle persone gli rientrano dentro.
Glyph è in produzione dietro il processo di governo dei dati: le sue proposte non si applicano da sole, le giudica un data steward, cioè la persona responsabile di quel gruppo di dati. Ogni coppia colonna-etichetta accettata o rifiutata viene riscritta in un archivio, e ogni settimana da quell'archivio si riaddestra la parte che cerca per somiglianza.
In sei settimane consecutive di esercizio, su circa 24.000 coppie giudicate, la quota di proposte accettate è passata dal 63,3% al 99,8%.
Gli autori mettono due paletti a quel numero, e sono paletti che tolgono, non che aggiungono. Nello stesso periodo il volume delle decisioni è cresciuto di 21 volte e si è allargata la platea delle colonne sotto esame: la crescita la riportano come un'associazione, non come un effetto dimostrato. E il tasso di accettazione misura soltanto quante delle etichette proposte erano giuste, perché un revisore vede solo quello che il sistema ha emesso: sulle colonne sensibili che il sistema non ha segnalato affatto, quel numero è cieco.
Con quei paletti, resta la cosa che serve sapere: il ciclo di correzione funziona se le correzioni tornano indietro. Nei progetti che vediamo partire, il pezzo che manca quasi sempre è questo. Il revisore corregge, la correzione finisce in un foglio o in una mail, e il sistema la settimana dopo ripropone lo stesso errore. Con quel disegno non si parte da sei su dieci per arrivare a dieci: si resta a sei per sempre.
Le 275 voci che nessun fornitore scrive al posto tuo
Le etichette che il Tagger assegna vengono da un elenco governato di 275 voci, raggruppate in categorie e ordinate per livello di sensibilità. È un dizionario aziendale che dice quali categorie di dato esistono in quell'azienda e quanto ciascuna è delicata. Nell'articolo i nomi delle etichette sono di esempio: i codici veri sono riservati. Una voce sola — il dato interno non sensibile — copre circa il 72% delle colonne.
Quelle 275 voci sono la parte che Apple ha e una PMI no. E sono esattamente la parte che non si compra.
Quello che si compra esiste, e funziona in un altro modo. Prendi OpenMetadata, un catalogo dati open source: la sua classificazione automatica dei dati personali applica due sole etichette, sensibile e non sensibile, e le decide in due modi — controllando i nomi delle colonne contro un elenco di espressioni regolari, e prelevando righe di esempio dalla tabella per passarle a un riconoscitore di entità. Cioè leggendo i valori. È il metodo che gli autori di Glyph attribuiscono anche agli strumenti commerciali di classificazione, e va detto che lo scrivono per marcare la distanza dal proprio.
Il limite di quel metodo si vede su un caso solo. Un campo si chiama NOTE, sta nell'anagrafica clienti, e dentro qualcuno ha scritto a mano perché quel cliente ha bisogno di consegne al piano. Un riconoscitore di formati ci vede testo libero. Una persona che conosce il processo ci vede un dato sulla salute.
Dividere la linea è semplice. Trasformare i nomi delle colonne in descrizioni leggibili, cercare per somiglianza, proporre etichette: si compra, e migliora ogni anno. Decidere quali categorie di dato esistono nella tua azienda, quali sono delicate e perché, non lo sa nessun fornitore. Anche in Noeva la parte che recupera il contesto prima che un agente lavori è una funzione del prodotto; sapere cosa c'è dentro quel contesto resta un lavoro dell'azienda.
Il registro che devi tenere comunque
C'è una ragione per fare questo lavoro anche senza nessun agente in vista, e sta nell'articolo 30 del GDPR, il registro delle attività di trattamento.
Fra le informazioni che quel registro deve contenere, la lettera c) chiede «una descrizione delle categorie di interessati e delle categorie di dati personali». Tradotto: di chi sono i dati che tratti, e di che tipo sono. Che è la stessa domanda con cui comincia questo articolo, scritta in linguaggio giuridico.
Qui va disinnescata la scorciatoia che si sente più spesso: «tanto sotto i 250 dipendenti siamo esenti». Il paragrafo 5 dell'articolo 30 dice questo:
Gli obblighi di cui ai paragrafi 1 e 2 non si applicano alle imprese o organizzazioni con meno di 250 dipendenti, a meno che il trattamento che esse effettuano possa presentare un rischio per i diritti e le libertà dell'interessato, il trattamento non sia occasionale o includa il trattamento di categorie particolari di dati di cui all'articolo 9, paragrafo 1, o i dati personali relativi a condanne penali e a reati di cui all'articolo 10.
Le condizioni dopo il «a meno che» si leggono come alternative: ne basta una per far cadere l'esenzione. E la seconda — che il trattamento «non sia occasionale» — è quella che la fa cadere quasi sempre. Le buste paga si fanno tutti i mesi, l'anagrafica clienti si aggiorna tutti i giorni, il gestionale gira tutto l'anno. Niente di tutto questo è occasionale.
Quindi il registro, nella quasi totalità delle aziende che hanno un gestionale, va tenuto. E un registro che elenca le categorie di dati personali trattati, mentre nel database ci sono campi che nessuno sa più descrivere, è un documento che descrive qualcosa di diverso dall'azienda vera.
Prima di collegare l'agente al gestionale
Il lavoro di catalogare i campi non ha scadenza e non ha un budget dedicato. Per questo non lo fa nessuno, finché qualcosa non lo rende urgente.
Le cose che lo rendono urgente sono due, e stanno arrivando insieme. La prima è il registro dei trattamenti. La seconda è il momento in cui a quei campi si affaccia un agente: che li legga per rispondere a una domanda o che ci scriva dentro passando dalle maschere, farà quello che c'è scritto nel campo, non quello che sa il capo ufficio.
Si comincia dalle tabelle che un agente toccherebbe davvero — nei progetti che vediamo partire sono cinque o sei, non novantottomila — e si scrive accanto a ogni campo cosa contiene e se dentro ci finiscono dati personali. La descrizione si ricava da chi quel campo lo riempie, senza aprire i dati. Quando qualcuno corregge una di quelle righe, la correzione va nel file, non in una mail.
È lo stesso mestiere che Apple fa su 3,4 milioni di colonne con due agenti e un dizionario da 275 voci. A trenta dipendenti si fa con un foglio di calcolo e due pomeriggi, e la parte che conta — decidere cosa significa quel campo — non cambia.
Quante delle tabelle che un agente leggerebbe domani hanno un campo che sai descrivere solo chiedendolo a una persona?