Data model Fondo di Garanzia per le PMI
Dal CSV grezzo al cubo analitico: architettura, scelte e utilizzo
Paolo Volterra 
Il Fondo di Garanzia per le PMI pubblica i microdati delle operazioni garantite come open data: 14 colonne, un file per mese, dal 2012 a oggi. I file sono già essenziali — il problema è la scala: 100+ file, 4,5 milioni di righe, oltre 3 GB di testo non interrogabile interattivamente. A questo si aggiunge un mismatch di granularità: il CSV è atomico (una riga = una pratica), ma le domande di business intelligence sono sempre aggregate. Il documento mostra come costruire un data model OLAP su questi dati — CSV → parquet (191 MB) → cubo analitico (5 MB) — con riduzioni di latenza da minuti a millisecondi. Sono trattati lo stack di trasformazione, le scelte di modellazione, le anomalie nei dati e il trattamento del codice fiscale (GDPR).
Fondo di Garanzia, PMI, data model, OLAP, ATECO, parquet, DuckDB, fdgq
Versione citabile su Zenodo, con il PDF: doi.org/10.5281/zenodo.20751283.
1 La fonte: i microdati MCC
Il Fondo di Garanzia per le PMI (FdG), gestito da Mediocredito Centrale per conto del MIMIT, pubblica periodicamente i microdati delle operazioni deliberate. Ogni file copre un trimestre o un mese e riporta le garanzie concesse a imprese e professionisti.
1.1 Struttura del CSV originale
I file sono pubblicati come open data sul portale del Fondo di Garanzia, in formato CSV con separatore ;. Ogni file copre un mese e contiene 14 colonne con nomi in italiano:
| # | Colonna CSV | Campo parquet |
|---|---|---|
| 1 | Ragione sociale e forma giuridica dell’impresa | impresa |
| 2 | Codice fiscale dell’impresa | CF |
| 3 | Tipologia di intervento | intervento |
| 4 | Importo massimo garantito (euro) | garantito |
| 5 | Riserva / Sezione speciale | riserva |
| 6 | Data di delibera di concessione della garanzia | delibera |
| 7 | Importo del finanziamento | finanziamento |
| 8 | Codice ATECO dell’attività dell’impresa | ATECO |
| 9 | Anno di riferimento della classificazione ATECO | — (ignorato: usare YEAR(delibera)) |
| 10 | Settore economico | settore |
| 11 | Regione di utilizzo | regione |
| 12 | Provincia (sigla) di utilizzo | prov |
| 13 | Comune di utilizzo | comune |
| 14 | Tipo di processo | processo |
Il formato è già essenziale: nessuna colonna operativa interna, nessun dato ridondante. Il problema non è la struttura del singolo file, ma la scala dell’archivio: dal 2012 a oggi i file mensili accumulano oltre 4,5 milioni di operazioni in più di 100 file.
Dimensioni tipiche:
| Periodo | Righe | Dimensione CSV |
|---|---|---|
| Trimestre normale | ~100.000 | ~50 MB |
| Trimestre COVID (picco) | ~250.000 | ~130 MB |
| Totale corpus 2012–2026 | ~4,5 M | > 3 GB |
1.2 Perché il CSV non basta
I file CSV presentano tre problemi strutturali per l’uso analitico:
- Dimensione: oltre 3 GB totali — non caricabili in RAM su un laptop standard senza campionamento.
- Lentezza: ogni query richiede la scansione completa e il parsing testuale riga per riga. Su 4,5 milioni di righe distribuite in 100+ file, una semplice aggregazione per regione richiede minuti.
- Assenza di tipi: in CSV tutto è testo. Date, importi e codici ATECO devono essere convertiti a ogni lettura, con rischio di errori silenti.
Il formato parquet risolve tutti e tre i problemi:
| Proprietà | CSV | Parquet |
|---|---|---|
| Compressione | nessuna | columnar + snappy (~8–10×) |
| Tipi | stringa | nativi (date, float, varchar) |
| Lettura parziale | no — scan completo | sì — colonne e row groups |
| Dimensione corpus | > 3 GB | 191 MB (109 file) |
| Query aggregazione | minuti | < 1 secondo (DuckDB) |
La conversione rinomina le 14 colonne in nomi brevi (snake_case) adatti all’uso analitico, ignorando la colonna “Anno di riferimento ATECO” (sostituita da YEAR(delibera)).
2 Lo stack: tre livelli di accesso
Il corpus FdG richiede due trasformazioni prima di diventare utilizzabile per la BI. La prima — da CSV a parquet — risolve il problema di scala e performance (3 GB → 191 MB, query da minuti a secondi). La seconda — da parquet a cubo — risolve il problema di granularità: il CSV registra ogni pratica individualmente, ma le domande BI sono sempre aggregate; pre-aggregare porta 4,45 milioni di righe atomiche a 475mila celle, con latenze nell’ordine dei millisecondi. Il risultato è uno stack a tre livelli:
CSV open data FdG (14 col, > 3 GB)
↓ conversione parquet
Parquet normalizz. (14 col, 191 MB, 109 file)
↓ fdgq CLI ↓ build_cube.py
CLI fdgq (query live) Cubo analitico (aggregato)
per domande ad hoc per BI e dashboard2.1 Livello 1 — Parquet normalizzati
109 file parquet (uno per trimestre/mese), conservati in una cartella locale. Contengono le 14 colonne del CSV open data rinominate in snake_case, con tipi corretti (date, float, varchar).
| Campo | Tipo | Contenuto |
|---|---|---|
delibera |
TIMESTAMP | Data di delibera della garanzia |
garantito |
DOUBLE | Importo garantito (€) |
finanziamento |
DOUBLE | Importo del finanziamento sottostante (€) |
ATECO |
VARCHAR | Codice attività 6 digit (DDGGSS) |
regione, prov, comune |
VARCHAR | Localizzazione impresa |
intervento |
VARCHAR | Tipo garanzia (3 valori) |
processo |
VARCHAR | Procedura valutativa (20 valori) |
riserva |
VARCHAR | Sezione del Fondo (88 valori) |
settore |
VARCHAR | Macro-settore (compilato dall’intermediario) |
impresa |
VARCHAR | Denominazione + forma giuridica |
CF |
VARCHAR | Codice fiscale impresa |
2.2 Livello 2 — CLI fdgq
fdgq è un CLI bash deterministico sopra DuckDB che interroga i parquet in tempo reale. È pensato per domande ad hoc e per l’integrazione con sistemi automatizzati (output --json).
# Operazioni per natura giuridica nel 2024
fdgq agg 2024 ng
# Top 10 province per garantito (2023)
fdgq rank prov 10 "EXTRACT(YEAR FROM delibera)=2023"
# Trend mensile ultimi 24 mesi
fdgq trend month 24
# Confronto Sicilia vs Italia (2025)
fdgq vs-it 2025 regione "Sicilia"
# Output JSON per integrazione
fdgq --json rank ng 10Le dimensioni disponibili in fdgq includono la natura giuridica (ng), il codice CCIAA estratto dal CF (cod_cf), la sezione ATECO a lettera (sezione, da A-Agricoltura a U-Org. Internazionali) e la divisione a 2 digit (ATECO). Queste dimensioni sono calcolate al volo — non esistono come colonne nei parquet.
2.3 Livello 3 — Cubo analitico (fdg_cube.parquet)
Il cubo pre-aggrega 4,45 milioni di operazioni in 475.516 celle, riducendo il file a 5,1 MB. Il vantaggio non è solo la dimensione: la granularità del cubo corrisponde esattamente alla granularità delle domande BI tipiche — nessuna riga “sprecata” in aggregazioni al momento della query. È il livello adatto per dashboard BI, report parametrici e visualizzazioni.
3 Il data model: struttura del cubo
3.1 Concetto
Dato grezzo: 4.450.355 righe → ogni riga = una pratica deliberata
↓ GROUP BY 7 dimensioni (filtro: garantito numerico)
Cubo: 475.516 righe → ogni riga = una cella analiticaOgni cella del cubo risponde implicitamente a domande del tipo: “quante SRL nel commercio al dettaglio (div=47), in Lombardia, con Garanzia Diretta, via procedura Semplificata, nel Q3 2024?”
3.2 Dimensioni
| Dimensione | Derivazione | Valori unici |
|---|---|---|
anno |
YEAR(delibera) |
14 (2012–2026) |
trimestre |
QUARTER(delibera) |
4 |
regione |
colonna diretta | 22 |
div2 |
LEFT(ATECO, 2) |
87 |
intervento |
colonna diretta | 3 |
processo |
colonna diretta | 20 |
ng |
CASE su impresa normalizzato |
18 |
Celle teoriche: 14 × 4 × 22 × 87 × 3 × 20 × 18 ≈ 115 milioni. Celle effettive: 475.516 — sparsità ~99,6%, normale per dati territoriali/settoriali.
3.3 Natura giuridica (ng)
La natura giuridica è estratta dal campo impresa, che nel dataset contiene la denominazione dell’azienda seguita dalla forma giuridica dopo una virgola (es. "FLORA S.R.L., Soc a responsabilità limitata"). La logica di normalizzazione — identica a quella usata da fdgq — applica UPPER, rimozione accenti e apostrofi, poi un matching esatto su 18 categorie canoniche:
| Codice | Forma giuridica | Quota |
|---|---|---|
SRL |
Società a responsabilità limitata | ~45% |
IMPRESA IND. |
Impresa individuale / Persona fisica | ~26% |
SNC |
Società in nome collettivo | ~9% |
SAS |
Società in accomandita semplice | ~7% |
SPA |
Società per azioni | ~2,5% |
COOP |
Cooperative (varie forme) | ~1,4% |
SRLS |
SRL semplificata | — |
PROFESSIONISTA |
Studi professionali, professionisti | — |
CONSORZIO, RETE, STP, ENTE, ENTE PUB., ESTERO, ALTRO |
— | — |
3.4 Misure
| Misura | Aggregazione | Unità |
|---|---|---|
n_operazioni |
COUNT(*) | numero pratiche |
n_imprese |
COUNT(DISTINCT CF) | imprese distinte |
garantito_mln |
SUM(garantito) / 1.000.000 | milioni € |
finanziamento_mln |
SUM(finanziamento) / 1.000.000 | milioni € |
importo_medio |
AVG(garantito) | € |
copertura_media |
AVG(garantito / finanziamento) | rapporto 0–1 |
La misura n_imprese (imprese distinte) affianca n_operazioni perché la stessa impresa può avere più operazioni garantite: la media è 2,5 operazioni per impresa nel corpus completo.
3.5 Il codice fiscale: uso e tutela GDPR
Il CF è presente nei parquet grezzi ed è usato per due scopi nel data model:
- Conteggio imprese distinte:
COUNT(DISTINCT CF)→ misuran_imprese - Identificazione tipo soggetto: CF a 11 digit numerici = persona giuridica; CF a 16 caratteri alfanumerici = persona fisica (ditta individuale, professionista)
Nel cubo aggregato il CF non compare mai come colonna esposta. I CF a 16 caratteri sono dati personali (GDPR) riferiti a persone fisiche; la loro scomparsa nell’aggregazione rende il cubo condivisibile senza vincoli di trattamento dei dati personali.
In fdgq, la dimensione cod_cf estrae le cifre 8–10 del CF societario (codice CCIAA della provincia di registrazione) o le cifre 12–15 del CF personale (comune di nascita in codice Belfiore) — mai il CF completo.
4 Scelte metodologiche
4.1 div2 invece di settore
Il campo settore (5 valori: Commercio, Industria, Servizi, Agricoltura) è compilato dall’intermediario segnalante, non derivato automaticamente dall’ATECO. Lo stesso codice ATECO può quindi comparire assegnato a settori diversi a seconda della banca o del confidi. Per questa ragione si usa div2 = LEFT(ATECO, 2) — la divisione ATECO a 2 digit — che è deterministica e coerente.
4.2 Anno da delibera, non dal campo anno
Il campo anno presente nei parquet contiene valori anomali non riconducibili all’anno di delibera (es. 1991, 2002, 2025 su un numero ridotto di record). L’anno è sempre derivato da YEAR(delibera).
5 Anomalie nei dati
5.1 copertura_media > 1
La copertura garantita non può superare il 100% del finanziamento. Alcune celle mostrano copertura_media > 1, con valori estremi fino a 2.857. Le cause probabili sono errori di imputazione nella colonna finanziamento (valori a zero o quasi zero nel dato grezzo). Per analisi che richiedono questa misura, filtrare copertura_media <= 1.0.
5.2 Picco COVID Q2 2020
Le celle con il maggior numero di operazioni si concentrano in Q2 2020 (aprile–giugno), effetto del DL 23/2020 (Decreto Liquidità) che ha sospeso i requisiti di valutazione del merito di credito e aperto la Garanzia Diretta al 100% per le PMI. Il segnale è chiarissimo: Lombardia, Campania, Puglia, Lazio nel commercio al dettaglio (div=47) e nella ristorazione (div=56).
6 Utilizzo del cubo
Il cubo è distribuito come OUT/fdg_cube.parquet (5,0 MB).
6.1 Caricamento
import pandas as pd
cubo = pd.read_parquet("OUT/fdg_cube.parquet")
print(cubo.shape) # (475516, 13)
print(cubo.columns.tolist())
# ['anno','trimestre','regione','div2','intervento','processo','ng',
# 'n_operazioni','n_imprese','garantito_mln','finanziamento_mln',
# 'importo_medio','copertura_media']6.2 Query con DuckDB
import duckdb
# Operazioni e garantito per regione nel 2024
duckdb.query("""
SELECT regione,
SUM(n_operazioni) AS operazioni,
SUM(n_imprese) AS imprese,
ROUND(SUM(garantito_mln), 1) AS garantito_mln
FROM 'OUT/fdg_cube.parquet'
WHERE anno = 2024
GROUP BY regione
ORDER BY garantito_mln DESC
""").df()# Natura giuridica: quota garantito e operazioni (2020–2024)
duckdb.query("""
SELECT ng,
SUM(n_operazioni) AS operazioni,
ROUND(SUM(garantito_mln), 1) AS garantito_mln,
ROUND(AVG(importo_medio)) AS importo_medio_eu
FROM 'OUT/fdg_cube.parquet'
WHERE anno BETWEEN 2020 AND 2024
GROUP BY ng
ORDER BY garantito_mln DESC
""").df()# Trend trimestrale del garantito totale
duckdb.query("""
SELECT anno, trimestre,
SUM(n_operazioni) AS operazioni,
ROUND(SUM(garantito_mln), 1) AS garantito_mln
FROM 'OUT/fdg_cube.parquet'
GROUP BY 1, 2
ORDER BY 1, 2
""").df()# Top-10 divisioni ATECO per garantito, solo SRL (2023)
duckdb.query("""
SELECT div2,
SUM(n_operazioni) AS operazioni,
ROUND(SUM(garantito_mln), 1) AS garantito_mln
FROM 'OUT/fdg_cube.parquet'
WHERE anno = 2023 AND ng = 'SRL'
GROUP BY div2
ORDER BY garantito_mln DESC
LIMIT 10
""").df()6.3 Filtri comuni
# Solo Microcredito
micro = cubo[cubo['processo'] == 'Microcredito']
# Solo Sud
sud = ['Campania','Puglia','Calabria','Sicilia','Basilicata','Molise','Sardegna','Abruzzo']
cubo_sud = cubo[cubo['regione'].isin(sud)]
# Solo persone fisiche (ditte individuali + professionisti)
fisiche = cubo[cubo['ng'].isin(['IMPRESA IND.', 'PROFESSIONISTA'])]
# Esclude celle con copertura anomala
cubo_clean = cubo[cubo['copertura_media'] <= 1.0]6.4 Variabili derivate al volo
Tre categorizzazioni utili calcolabili dopo il caricamento, senza aumentare le dimensioni del cubo.
Fascia garantito — basata sul p50 (25k €) e su soglie regolamentari FdG:
import pandas as pd
cubo['fascia_garantito'] = pd.cut(
cubo['importo_medio'],
bins=[0, 25_000, 100_000, 500_000, 1_500_000, float('inf')],
labels=['Micro (≤25k)', 'Piccola (25–100k)', 'Media (100–500k)',
'Grande (500k–1,5M)', 'Molto grande (>1,5M)']
)| Fascia | Range | % operazioni | Riferimento |
|---|---|---|---|
| Micro | ≤ 25.000 € | ~50% | p50; soglia storica Microcredito |
| Piccola | 25.001–100.000 € | ~25% | p50–p75 |
| Media | 100.001–500.000 € | ~20% | p75–p95 |
| Grande | 500.001–1.500.000 € | ~4% | p95–p99 |
| Molto grande | > 1.500.000 € | ~1% | oltre p99 |
Fascia finanziamento — stessa struttura, shift proporzionale (p50 a 30k €):
cubo['fascia_finanziamento'] = pd.cut(
cubo['finanziamento_mln'] * 1e6 / cubo['n_operazioni'], # importo medio
bins=[0, 30_000, 100_000, 500_000, 1_500_000, float('inf')],
labels=['Micro (≤30k)', 'Piccola (30–100k)', 'Media (100–500k)',
'Grande (500k–1,5M)', 'Molto grande (>1,5M)']
)Fascia copertura — percentuale di garanzia sul finanziamento:
cubo_c = cubo[cubo['copertura_media'] <= 1.0].copy()
cubo_c['fascia_copertura'] = pd.cut(
cubo_c['copertura_media'],
bins=[0, 0.50, 0.80, 0.90, 1.001],
labels=['Bassa (≤50%)', 'Standard (50–80%)', 'Alta (80–90%)', 'Massima (>90%)']
)| Fascia copertura | Range | Contesto |
|---|---|---|
| Bassa | ≤ 50% | Controgaranzia, operazioni parziali |
| Standard | 50–80% | Garanzia ordinaria (limite normativo 80%) |
| Alta | 80–90% | Regimi agevolati, startup, Sud |
| Massima | > 90% | COVID DL 23/2020 (100%), sezioni speciali |
Esempio di analisi combinata:
# Distribuzione copertura per tipo di intervento (2023)
(cubo_c[cubo_c['anno'] == 2023]
.assign(fascia_cop=lambda d: pd.cut(d['copertura_media'],
bins=[0, .50, .80, .90, 1.001],
labels=['≤50%','50–80%','80–90%','>90%']))
.groupby(['intervento','fascia_cop'])['n_operazioni']
.sum()
.unstack(fill_value=0)
)6.5 Utilizzo con Excel via Power Query
Il cubo parquet è leggibile direttamente in Excel 365 / 2019+ tramite Power Query, senza conversioni intermedie:
Dati → Recupera dati → Da file → Da parquet
→ seleziona fdg_cube.parquet → CaricaLe 475.516 righe del cubo entrano in memoria in pochi secondi. Da lì è possibile costruire pivot table normali sul dato già aggregato — senza dover gestire i 4,5 milioni di righe originali.
In alternativa, conversione esplicita a Excel via Python:
import pandas as pd
cubo = pd.read_parquet("OUT/fdg_cube.parquet")
cubo.to_excel("OUT/fdg_cube.xlsx", index=False) # ~8 MBIl file .xlsx risultante è più pesante (8–10 MB) e le pivot su 475k righe sono più lente rispetto al parquet via Power Query. Per usi analitici continuativi, Power Query è la scelta consigliata.
6.6 Query live con fdgq (parquet grezzi)
Per domande che richiedono la grana atomica o dimensioni non nel cubo (es. sezione ATECO A–U, comune, cod_cf):
# Distribuzione per sezione ATECO (A=Agricoltura, C=Manifattura, G=Commercio…)
fdgq rank sezione 21 "EXTRACT(YEAR FROM delibera)=2024"
# Operazioni Microcredito per comune in Sicilia
fdgq rank comune 20 "processo='Microcredito' AND regione='Sicilia'"
# Output JSON per integrazione pipeline
fdgq --json agg 2024 ng6.7 Aggiornamento del cubo
Il cubo si rigenera eseguendo build_cube.py ogni volta che vengono aggiunti nuovi file parquet alla cartella sorgente. Il tempo di esecuzione su 4,5 milioni di righe è inferiore a 30 secondi.
python build_cube.py7 Statistiche descrittive
Il corpus copre 4.450.292 operazioni deliberate dal 2012 al 2026 (dati parziali per l’anno corrente), per un totale di 403,8 miliardi di euro garantiti.
7.1 Evoluzione temporale
Il dato più rilevante nell’intera serie storica è il picco del 2020, innescato dal DL 23/2020 (Decreto Liquidità), che ha aperto la Garanzia Diretta al 100% senza valutazione del merito di credito e ha introdotto la procedura semplificata per le PMI. Nel solo 2020 si concentrano il 35% di tutte le operazioni dell’intera serie storica e il 26% del garantito cumulato. L’analisi delle garanzie emergenziali nel periodo 2020–2022 è discussa in dettaglio in Garanzie Pubbliche al Credito e Sostegno alle PMI (2026).
| Anno | Operazioni | Garantito (Mld €) | Note |
|---|---|---|---|
| 2012 | 34.005 | 2,4 | serie storica disponibile dal Q4 |
| 2015 | 102.443 | 10,3 | crescita strutturale |
| 2018 | 129.394 | 13,9 | picco pre-COVID |
| 2019 | 121.928 | 13,2 | |
| 2020 | 1.571.514 | 104,6 | DL 23/2020 |
| 2021 | 991.537 | 66,9 | progressiva normalizzazione |
| 2022 | 279.743 | 42,0 | fine misure emergenziali |
| 2023 | 244.269 | 36,2 | |
| 2024 | 230.648 | 30,4 | |
| 2025 | 247.808 | 31,9 | |
| 2026 | 103.489 | 13,1 | parziale (dati al Q2) |
7.2 Distribuzione geografica
Le prime quattro regioni coprono il 45% delle operazioni. Il Sud — Campania, Sicilia, Puglia, Calabria, Basilicata, Molise, Sardegna, Abruzzo — pesa complessivamente per il 30% delle operazioni, ma con un garantito medio per operazione più elevato della media nazionale, effetto delle sezioni speciali riservate al Mezzogiorno.
| Regione | Operazioni | % sul tot. | Garantito (Mld €) |
|---|---|---|---|
| Lombardia | 775.405 | 17,4% | 83,0 |
| Veneto | 492.611 | 11,1% | 49,0 |
| Emilia Romagna | 377.845 | 8,5% | 35,1 |
| Toscana | 377.244 | 8,5% | 27,5 |
| Lazio | 375.203 | 8,4% | 32,3 |
| Campania | 345.951 | 7,8% | 36,2 |
7.3 Natura giuridica
Le SRL concentrano quasi la metà delle operazioni e i due terzi del garantito — un effetto dimensionale: le SRL hanno taglio medio molto più elevato delle imprese individuali. SPA e cooperative, pur minoritarie per numero, hanno taglio medio tra i più alti.
| Forma giuridica | Operazioni | % op. | Garantito (Mln €) | % gar. |
|---|---|---|---|---|
| SRL | 2.069.838 | 46,5% | 271.031 | 67,1% |
| Impresa individuale | 1.240.798 | 27,9% | 30.661 | 7,6% |
| SNC | 401.112 | 9,0% | 17.872 | 4,4% |
| SAS | 304.706 | 6,8% | 14.415 | 3,6% |
| SRLS | 148.682 | 3,3% | 5.600 | 1,4% |
| SPA | 111.595 | 2,5% | 48.715 | 12,1% |
| Cooperativa | 78.057 | 1,8% | 9.202 | 2,3% |
| Professionista | 45.456 | 1,0% | 1.293 | 0,3% |
7.4 Tipo di intervento
Il 99,9% del volume passa per la Garanzia Diretta — MCC garantisce direttamente l’operazione verso la banca. La Controgaranzia (12,6% in numero) riguarda operazioni già garantite da Confidi, su cui il Fondo offre una garanzia di secondo livello.
| Intervento | Operazioni | % | Garantito (Mld €) |
|---|---|---|---|
| Garanzia Diretta | 3.887.323 | 87,3% | 374,7 |
| Controgaranzia | 562.169 | 12,6% | 29,0 |
| Cogaranzia | 800 | < 0,1% | 0,02 |
8 Riepilogo
| CSV grezzo | Parquet | Cubo | |
|---|---|---|---|
| Formato | CSV ; |
parquet (snappy) | parquet (zstd) |
| File | ~100 file | 109 file | 1 file |
| Righe | 4.450.355 | 4.450.355 | 475.516 |
| Dimensione | > 3 GB | 191 MB | 5,1 MB |
| Fattore riduzione | — | 16× | 870× |
| Query aggregazione | minuti | < 1 s (DuckDB) | < 50 ms |
| Dati individuali esposti | sì (CF, denominazione) | sì | no |
| Pronto per BI/dashboard | no | no | sì |
9 GDPR e aggregazione: impossibilità del reverse engineering
Il cubo aggregato è GDPR-safe per costruzione. Le dimensioni scelte non contengono identificatori diretti o indiretti degli individui: è strutturalmente impossibile risalire al soggetto originale.
9.1 Perché il reverse engineering è impossibile
Il cubo espone: anno · trimestre · regione · div2 · intervento · processo · ng · misure aggregate.
Non espone mai: CF, denominazione impresa, comune, codice operazione.
Anche nella cella più granulare con n_operazioni = 1, l’informazione disponibile è soltanto: “esiste una SRL nel commercio all’ingrosso in Puglia, Q1 2023, via Garanzia Diretta, procedura Semplificata” — nessun identificatore, nessuna persona fisica o giuridica riconducibile.
9.2 Base normativa
GDPR Reg. UE 2016/679, Considerando 26:
“I principi di protezione dei dati non dovrebbero applicarsi a informazioni anonime, ossia informazioni che non si riferiscono a una persona fisica identificata o identificabile o a dati personali resi sufficientemente anonimi da impedire o da non consentire più l’identificazione dell’interessato.”
L’aggregazione per celle dimensionali con soppressione degli identificatori rientra in questa definizione quando: (1) il dato originale non è ricostruibile dalle celle, e (2) le dimensioni non sono esse stesse identificatori (regione + settore ≠ CF).
9.3 Caveat: K-anonimità
Le celle con n_operazioni = 1 non violano il GDPR — non espongono il CF — ma sono statisticamente fragili. Un osservatore con conoscenza del mercato potrebbe inferire l’impresa per esclusione, non dal cubo, ma dal contesto esterno. La prassi consolidata (Istat, Eurostat) è sopprimere o raggruppare celle con n < 3 o n < 5 prima della pubblicazione esterna.
9.4 Conseguenze operative
Il cubo fdg_cube.parquet può essere:
- Condiviso via email, cloud, git
- Pubblicato come open data o allegato a report
- Integrato in dashboard accessibili a terzi
- Usato senza dichiarazione di trattamento dati personali
Il dato grezzo (parquet sorgente con CF di persone fisiche e denominazioni) rimane invece soggetto a GDPR e non può essere distribuito liberamente.
Trasparenza sull’uso dell’intelligenza artificiale
L’uso di strumenti di intelligenza artificiale generativa è dichiarato esplicitamente in quanto parte del processo di lavoro seguito nella redazione del presente documento. Tali strumenti sono stati impiegati a supporto della lettura, della sintesi, della riorganizzazione argomentativa e della revisione testuale, sempre nell’ambito di un processo pienamente controllato dall’autore.
La responsabilità per le fonti utilizzate, le analisi condotte, le verifiche effettuate, le interpretazioni proposte e le conclusioni formulate resta interamente in capo all’autore.
L’intelligenza artificiale è stata utilizzata come ambiente di supporto cognitivo ed editoriale, non come fonte primaria, autore autonomo o sostituto del giudizio critico.