Oltre Turing
Un sistema informativo contemporaneo - un ERP integrato con moduli di analytics, una cartella clinica elettronica connessa a pipeline di apprendimento automatico, un dispositivo medico indossabile che trasmette biosegnali verso un modello predittivo cloud - produce, a regime, milioni di record al giorno. Ciascun record è, formalmente, un dato. Ma ciascun dato, nel momento in cui si riferisce a una persona identificata o identificabile, costituisce - nella terminologia dell'art. 4(1) del Regolamento UE 2016/679 - un dato personale: informazione relativa a un soggetto.
Lo spostamento categoriale è sottile ma decisivo. Il dato è un artefatto ingegneristico - struttura, schema, tipo, vincolo. Il soggetto è una categoria giuridica e ontologica - titolare di diritti, dignità, integrità psico-fisica. L'ingegneria dei sistemi informativi contemporanea vive interamente dentro questa tensione: ogni pipeline che trasforma il primo nel secondo - o il secondo nel primo - è una scelta progettuale con conseguenze tecniche, giuridiche ed etiche misurabili.
Questo capitolo traccia l'architettura di tale tensione dal punto di vista dell'ingegnere che progetta, valida e governa sistemi informativi ad alta intensità di dati personali. Non è un commento giuridico al GDPR o all'AI Act - è una lettura ingegneristica dei requisiti non funzionali che tali normative impongono, e delle architetture di riferimento che ne discendono.
§1. Il dato come artefatto ingegneristico
Nella letteratura classica dei Big Data - da Laney (2001) in poi - il dato è caratterizzato dalle cosiddette 5V: Volume, Velocità, Varietà, Veracità, Valore. Si tratta di proprietà estrinseche - descrivono il dato come flusso da governare. L'ingegneria del dato moderna - data engineering stricto sensu - articola questa gestione lungo una pipeline canonica: ingestione (batch o streaming), pulizia e deduplicazione, trasformazione (ETL o ELT), archiviazione (data warehouse, data lake, lakehouse), servizio (query engine, feature store), consumo analitico o algoritmico.
A ciascuno stadio della pipeline corrispondono metriche ingegneristiche verificabili: latenza end-to-end, throughput, tasso di errore, completezza, consistenza referenziale, drift rispetto al training distribution. Discipline consolidate - data quality management (ISO 8000), data governance (DAMA-DMBOK), MLOps - codificano best practice per mantenere queste metriche entro soglie definite.
Fin qui il dato è, a tutti gli effetti, un artefatto ingegneristico neutro: una stringa, un tensore, una riga in una tabella relazionale, un documento JSON. La sua natura cambia radicalmente nel momento in cui entra in contatto con un identificativo diretto o indiretto riferibile a una persona fisica. Quel contatto - che nel linguaggio ingegneristico è un semplice join tra due tabelle - è, nel linguaggio giuridico, l'evento costitutivo del trattamento di dati personali (art. 4(2) GDPR). Due linguaggi diversi per la stessa operazione tecnica. Ed è proprio questa simmetria asimmetrica che l'ingegnere deve imparare a gestire.
§2. Il soggetto come categoria giuridica-tecnica
Il GDPR introduce la figura del data subject - l'interessato, la persona fisica cui i dati si riferiscono. Non è una categoria filosofica: è una classe di requisiti ingegneristici. All'interessato il regolamento riconosce diritti (accesso, rettifica, cancellazione, portabilità, opposizione, limitazione) che diventano, nella progettazione di un sistema informativo, funzionalità obbligatorie. Un CRM non conforme al diritto all'oblio non è un CRM difettoso dal punto di vista di una feature opzionale: è un sistema strutturalmente non deployabile in giurisdizione europea.
La distinzione tecnicamente più rilevante è quella tra anonimizzazione e pseudonimizzazione (considerando 26 e art. 4(5) GDPR). La prima rende il soggetto non identificabile in modo irreversibile - e il dato esce dall'ambito applicativo del regolamento. La seconda sostituisce gli identificativi diretti con token reversibili - e il dato resta personale, benché protetto. Confondere le due è un errore architetturale frequente e costoso.
La letteratura della privacy-preserving computation ha prodotto tecniche con garanzie formali misurabili. La k-anonymity (Sweeney, 2002) richiede che ogni record sia indistinguibile da almeno k-1 altri rispetto agli attributi quasi-identificativi. Le raffinazioni successive - l-diversity, t-closeness - rispondono a tipologie note di attacco. La differential privacy (Dwork, 2006) fornisce una garanzia parametrica più forte: un meccanismo ε-differenzialmente privato assicura che la presenza o assenza di un singolo record influenzi l'output del sistema entro un fattore moltiplicativo di e^ε. Il parametro ε è negoziabile ingegneristicamente - valori più piccoli significano più privacy e meno utilità - ma la garanzia è matematica, non euristica.
A queste si affiancano tecniche architetturali: federated learning (il modello si sposta verso i dati, non i dati verso il modello), secure multi-party computation, homomorphic encryption. Ciascuna ha costi computazionali e compromessi precisi. Il punto metodologico è netto: la tutela del soggetto è un requisito di progetto quantificabile, non un vincolo vago da soddisfare a valle. È, in senso proprio, un vincolo di sistema - iscritto nella specifica fin dalla fase di requirements engineering.
§3. Profilazione algoritmica e sistemi ad alto rischio
L'introduzione di modelli di apprendimento automatico nei sistemi informativi - classificatori, raccomandatori, sistemi di supporto decisionale clinico, motori di credit scoring, dispositivi medici AI-enabled - trasforma l'equazione. Al trattamento del dato si aggiunge la profilazione (art. 4(4) GDPR) e, potenzialmente, la decisione automatizzata (art. 22). Non è più solo questione di conservare e proteggere: è questione di inferire, prevedere, classificare, decidere.
Il Regolamento UE 2024/1689 - il cosiddetto AI Act, entrato in vigore il 1° agosto 2024 - introduce una stratificazione basata sul rischio (risk-based approach). L'art. 6 e l'Annex III individuano sistemi ad alto rischio in aree quali: dispositivi medici e diagnostica (in combinato disposto con il Regolamento UE 2017/745 - MDR), istruzione e valutazione degli studenti, selezione del personale, credit scoring, applicazioni in ambito law enforcement e gestione dei flussi migratori, infrastrutture critiche. Per tali sistemi il regolamento prescrive requisiti tecnici cogenti: risk management system (art. 9), governance dei dati di training (art. 10), documentazione tecnica (art. 11), registro degli eventi - logging - (art. 12), trasparenza verso l'utilizzatore (art. 13), sorveglianza umana (art. 14), accuratezza-robustezza-cybersicurezza (art. 15).
La sovrapposizione con il Regolamento 2017/745 sui dispositivi medici è particolarmente densa: un Software as a Medical Device (SaMD) basato su ML per, ad esempio, la classificazione di immagini diagnostiche, ricade simultaneamente sotto MDR (marcatura CE, classe di rischio, clinical evaluation) e sotto AI Act (sistema ad alto rischio ai sensi dell'art. 6(1)). L'ingegnere di sistema deve orchestrare conformità multipla: ISO 13485 per il sistema di gestione qualità, ISO 14971 per il risk management, IEC 62304 per il ciclo di vita del software di dispositivo medico, e - specificamente per l'AI - la ISO/IEC 42001 (AI management system, 2023) e la ISO/IEC 23894 (AI risk management, 2023).
Queste non sono cornici astratte. Sono - letteralmente - checklist di deliverable ingegneristici: risk assessment documents, data management plans, model cards, system cards, post-market surveillance plans. Ciascun documento ha una struttura formale, un revisore identificato, un ciclo di aggiornamento. L'AI Act trasforma l'ingegneria dell'AI da disciplina sperimentale in ingegneria regolata - con tutto ciò che questo comporta in termini di maturità di processo, tracciabilità, accountability.
§4. Architetture di sorveglianza umana e spiegabilità
L'art. 14 dell'AI Act - human oversight - è forse la prescrizione più rilevante dal punto di vista architetturale. Impone che i sistemi ad alto rischio siano progettati e sviluppati in modo tale da poter essere effettivamente supervisionati da persone fisiche durante il loro utilizzo. Tradotta in ingegneria, la prescrizione distingue almeno tre topologie di controllo umano.
Il human-in-the-loop prevede un operatore umano che convalida ciascuna decisione prima dell'esecuzione: è il modello più stringente, applicabile dove l'errore ha conseguenze irreversibili (interventi chirurgici robot-assistiti, decisioni sulla libertà personale). Il human-on-the-loop prevede un operatore che monitora il sistema e può intervenire - ma non convalida ogni singolo output: è il modello tipico dei sistemi di supporto decisionale a regime. Il human-in-command prevede che l'autorità umana sia strutturale - regole di ingaggio, poteri di disattivazione, definizione dei perimetri operativi - anche quando non c'è intervento puntuale.
La scelta tra le tre topologie non è puramente normativa: è dimensionamento di sistema. Incide su latenza ammissibile, throughput sostenibile, costo operativo, interfaccia utente, formazione dell'operatore, specifiche di interruttibilità. Un sistema human-in-the-loop che richiede conferma su 10.000 predizioni al minuto è un errore di progetto. Un sistema human-on-the-loop che emette decisioni critiche senza tracciamento per audit è un errore di compliance.
La sorveglianza umana richiede inoltre che il modello sia spiegabile nei limiti imposti dal compito. L'Explainable AI (XAI) - come campo di ricerca e come requisito prescrittivo dell'AI Act - non è più opzionale. Tecniche mature (SHAP, LIME, counterfactual explanations, attention visualization) sono ormai componenti standard delle pipeline di ML production. Il punto ingegneristico è che la spiegabilità non è una proprietà del modello, ma una proprietà del sistema: dipende dall'interfaccia, dall'utente target, dal contesto d'uso, dal carico cognitivo tollerabile. Un'explanation accurata ma illeggibile per l'operatore è inutile tanto quanto un'explanation sbagliata.
Da qui la prassi - che il capitolo sulla pipeline e la governance approfondisce sul piano documentale - delle model cards (Mitchell et al., 2019) e dei datasheets for datasets (Gebru et al., 2021): documenti strutturati che descrivono, per ciascun modello o dataset, condizioni d'uso previste, metriche di performance disaggregate per sottopopolazioni, limitazioni note, rischi residui. Non sono più esercizi accademici - l'AI Act art. 13 li richiama implicitamente tra le istruzioni per l'uso obbligatorie.
§5. Il resto irriducibile
Nessuna architettura di sorveglianza, nessuna garanzia differenziale, nessuna model card esaurisce il soggetto. Questo non è un limite del progetto - è il progetto stesso. Ogni modello ha un coverage gap: una zona del dominio operativo in cui le sue prestazioni non sono state misurate o non sono caratterizzate con sufficiente confidenza statistica. Ogni soggetto, davanti a un sistema, è - almeno in parte - out-of-distribution rispetto al dataset di training. La singolarità del caso individuale eccede strutturalmente la generalizzazione del modello.
L'ingegneria matura non cerca di chiudere questo gap: lo dichiara. Lo misura - dove possibile - con tecniche di uncertainty quantification (calibrazione bayesiana, ensemble disagreement, conformal prediction). Lo segnala all'operatore umano come zona di rischio. Lo inscrive nei protocolli di fallback: cosa fa il sistema quando il suo livello di confidenza scende sotto soglia? Ritorna all'operatore umano, emette un warning, attiva un percorso alternativo. Queste sono decisioni architetturali concrete, non dichiarazioni di principio.
Il punto metodologico può essere formulato così: la dignità del soggetto è un invariante di progetto. Non è una proprietà da dimostrare a posteriori, non è un vincolo da soddisfare nel modo più economico possibile, non è un adempimento burocratico. È una condizione sulla quale il sistema deve essere costruito fin dal primo commit - con lo stesso rigore con cui si progetta l'alta disponibilità, la consistenza transazionale, la sicurezza crittografica. In questo senso, il GDPR parla appropriatamente di privacy by design (art. 25): la tutela del soggetto è architettura, non configurazione.
Un sistema informativo progettato con questa consapevolezza non rinuncia alla potenza analitica - la rende collocabile. Sa dove opera bene, dove opera male, dove deve fermarsi. Sa che un soggetto non è la somma dei suoi record, così come un sistema non è la somma dei suoi servizi. Questa coscienza ingegneristica dei propri bordi non è una limitazione della tecnica: è il punto in cui la tecnica raggiunge la propria maturità.
Il dato si può modellare. Il soggetto si può servire. Non sono, e non saranno mai, la stessa cosa. Il sistema informativo che riconosce questa distinzione non è meno potente - è meglio progettato. E un'ingegneria che non dimentica questa distinzione non è meno tecnica - è più completa. È la traduzione ingegneristica di una verità più antica dei database, che le tradizioni di questo libro custodiscono da millenni: nessuna quantità di dati esaurisce un volto.