Oltre Turing
Introduzione
Un sistema di Customer Relationship Management non registra clienti: produce profili. La distinzione non è retorica, è architetturale. Nel modello entità-relazione che fonda qualunque CRM, un cliente è una riga in una tabella anagrafica - un identificatore, alcuni attributi, un insieme di transazioni collegate. Un profilo è qualcosa di diverso: è il risultato di una catena di elaborazione che aggrega quell'anagrafica con il tracciamento comportamentale, la arricchisce con attributi derivati, vi applica modelli statistici e ne ricava una rappresentazione predittiva del soggetto. Il record è ciò che il cliente ha dichiarato; il profilo è ciò che il sistema ha inferito su di lui.
Questa serie ha più volte individuato una soglia: il punto in cui un artefatto tecnico smette di essere strumento neutro e diventa decisione su una persona. Nel CRM quella soglia ha una collocazione precisa nel grafo di elaborazione del dato. Non coincide con la raccolta, né con l'archiviazione: coincide con il momento in cui un attributo inferito viene retroazionato sul cliente sotto forma di azione automatizzata - un prezzo, un'offerta, un diniego. Identificare quella soglia, strumentarla e renderla sorvegliabile è, prima ancora che un obbligo giuridico, un problema di ingegneria dei sistemi informativi.
Il Regolamento (UE) 2016/679 (GDPR) e il Regolamento (UE) 2024/1689 (AI Act) non sono, in questa prospettiva, vincoli esterni che si aggiungono a un sistema già progettato. Sono requisiti non funzionali da incorporare nell'architettura fin dalla fase di disegno - compliance by design, nello stesso senso in cui si progetta per la sicurezza o per la scalabilità. I cinque stadi che seguono ricostruiscono la pipeline del profilo come una sequenza di componenti, e per ciascuno individuano il requisito di progetto corrispondente.
1. Identità: la risoluzione del soggetto
Prima di poter profilare un cliente, un sistema deve stabilire che due record si riferiscono allo stesso soggetto. È il problema della entity resolution: riconciliare identità frammentate fra canali, dispositivi e sorgenti dati eterogenee. La letteratura informatica lo tratta come problema di record linkage probabilistico (Fellegi-Sunter, 1969), oggi affrontato con tecniche di blocking, similarità di stringa e classificatori supervisionati che stimano la probabilità che due record costituiscano una corrispondenza.
L'esito ingegneristico desiderato è il golden record del Master Data Management: una rappresentazione unica e autorevole del cliente, prodotta da regole di sopravvivenza degli attributi (survivorship) che dirimono i conflitti fra sorgenti. Qui nasce il primo requisito di progetto. La risoluzione probabilistica è, per definizione, fallibile: produce falsi accoppiamenti (record di due persone fusi in un profilo) e falsi non-accoppiamenti (una persona scissa in due profili). Ogni errore di entity resolution si propaga a valle e contamina ogni inferenza successiva.
Il principio di esattezza sancito dall'articolo 5, paragrafo 1, lettera d) del GDPR - i dati personali devono essere «esatti e, se necessario, aggiornati» - diventa quindi una specifica di qualità del dato misurabile: precision e recall della procedura di matching, tasso di golden record contestati, latenza di propagazione delle correzioni. Un'architettura corretta espone la confidenza del matching come metadato di prima classe e mantiene la tracciabilità della provenienza (data lineage) di ogni attributo del golden record, condizione necessaria perché una rettifica ex articolo 16 GDPR sia tecnicamente eseguibile.
2. Categoria: la segmentazione del comportamento
Stabilita l'identità, il sistema colloca il soggetto in classi. La segmentazione è l'operazione canonica del marketing analitico: clustering non supervisionato (k-means, modelli a mistura gaussiana), scoring RFM (Recency, Frequency, Monetary), costruzione di audience look-alike per estensione statistica a partire da un seme di clienti noti. Il prodotto è una categorizzazione: ogni cliente eredita le proprietà attese della classe cui è assegnato.
Sul piano ingegneristico due rischi sono noti e documentati. Il primo è il bias: un modello di clustering addestrato su dati storici riproduce e amplifica le asimmetrie presenti nei dati; la composizione delle classi non è neutra rispetto a variabili protette, anche quando queste non sono usate esplicitamente, perché vengono ricostruite per correlazione da variabili apparentemente innocue (codice di avviamento postale, dispositivo, orario di navigazione). Il secondo è l'opacità: i confini fra segmenti, e le ragioni dell'assegnazione, sono spesso non ispezionabili, in tensione con qualunque requisito di spiegabilità.
L'AI Act introduce qui un confine netto. L'articolo 5 vieta talune pratiche a prescindere dal settore: i sistemi che sfruttano le vulnerabilità di gruppi specifici o che impiegano tecniche manipolative al di sotto della soglia di consapevolezza per distorcerne il comportamento sono inammissibili. La categorizzazione, di per sé lecita e utile, attraversa la soglia del divieto quando smette di descrivere un segmento e comincia a sfruttarne le fragilità. La differenza, per il progettista, è tra un sistema che ottimizza la pertinenza di una comunicazione e un sistema che ottimizza la riduzione della resistenza del destinatario.
3. Predizione: dal segmento al punteggio
La segmentazione descrive il presente; la predizione anticipa il futuro. È lo stadio in cui il CRM contemporaneo concentra il proprio valore: modelli di propensity (probabilità di acquisto di un prodotto), di churn (probabilità di abbandono), stima del Customer Lifetime Value, sistemi di raccomandazione che ordinano l'offerta in funzione del comportamento atteso. Sono problemi di apprendimento supervisionato e di filtraggio collaborativo, valutati con metriche standard - AUC-ROC, precision@k, lift - che misurano l'accuratezza ma non, di per sé, la legittimità dell'uso.
È qui che il profilo acquista efficacia normativa, perché il punteggio predittivo diventa premessa di una decisione. L'articolo 22 del GDPR riconosce all'interessato il diritto di non essere sottoposto a una decisione basata unicamente sul trattamento automatizzato che produca effetti giuridici o incida significativamente sulla sua persona. La Corte di Giustizia dell'Unione Europea, nella sentenza C-634/21 (SCHUFA, 7 dicembre 2023), ha chiarito che la stessa generazione di uno scoring di credito, quando il punteggio orienta in modo determinante la decisione del terzo, costituisce «decisione automatizzata» ai sensi dell'articolo 22, anche se l'atto finale è formalmente adottato da un altro soggetto.
La conseguenza progettuale è precisa: un motore di scoring non può essere trattato come una scatola nera il cui output viene consumato a valle. Deve essere costruito per la model governance - versionamento del modello e dei dati di addestramento, registrazione delle feature utilizzate, capacità di produrre una motivazione comprensibile della singola predizione (logica sottostante, ai sensi degli articoli 13-15 GDPR). Quando il dominio applicativo rientra fra quelli ad alto rischio dell'Allegato III dell'AI Act - segnatamente l'accesso a servizi essenziali e la valutazione del merito creditizio - al requisito di trasparenza si sommano gli obblighi di gestione del rischio, qualità dei dati e documentazione tecnica degli articoli 9-15.
4. Azione: la chiusura dell'anello
Un profilo che non genera azione è un costo senza ritorno. Lo stadio dell'azione chiude l'anello di retroazione: next-best-offer, dynamic pricing, personalizzazione dell'interfaccia, sperimentazione continua tramite test A/B che ottimizzano in tempo reale il tasso di conversione. È l'ingegneria del comportamento applicata: il sistema non si limita a prevedere il cliente, agisce su di lui e misura la risposta per ricalibrare la prossima azione.
Proprio perché agisce, questo stadio è il più esposto. Il Regolamento (UE) 2022/2065 (Digital Services Act), all'articolo 25, vieta ai gestori di interfacce online di progettarle in modo da ingannare o manipolare i destinatari, ovvero da distorcerne o ostacolarne la capacità di decidere - i cosiddetti dark patterns. Le Linee Guida 03/2022 dell'EDPB ne offrono una tassonomia operativa direttamente leggibile come anti-pattern di progettazione dell'interazione: scarsità artificiale, ostacoli alla disiscrizione, gerarchie visive che pre-orientano la scelta. Per il progettista di sistemi sono difetti documentati, non scelte estetiche.
Il requisito ingegneristico dominante diventa qui l'auditabilità. Ogni azione automatizzata erogata al cliente - quale offerta, a quale prezzo, in base a quale segmento e a quale punteggio - deve lasciare una traccia immutabile e ricostruibile. Senza un sistema di logging strutturato dell'azione, nessuna delle garanzie degli stadi precedenti è verificabile a posteriori: la trasparenza dichiarata a monte resta indimostrabile a valle, e l'organizzazione perde la capacità tecnica di rispondere a una contestazione o a un'istanza di accesso.
5. Il resto del cliente: la soglia tra decisione automatica e decisione assistita
I cinque stadi convergono su una distinzione che è, insieme, tecnica e regolatoria: tra decisione automatica e decisione assistita. Una decisione è automatica quando l'output del modello si traduce in effetto sul cliente senza intervento umano sostantivo. È assistita quando un operatore valuta, può ribaltare e si assume la responsabilità dell'esito. La distinzione non è dichiarativa: dipende dall'architettura del punto di controllo.
L'articolo 14 dell'AI Act, sulla sorveglianza umana, e l'articolo 22, paragrafo 3, del GDPR, sul diritto a ottenere l'intervento umano, individuano lo stesso componente di sistema: un human-in-the-loop che sia effettivo e non cerimoniale. La differenza fra le due forme è interamente di progettazione. Un sistema che presenta all'operatore la sola raccomandazione del modello, con un pulsante di conferma e nessuna informazione sul margine di incertezza, produce un avallo automatico travestito da supervisione. Un sistema progettato per la sorveglianza sostantiva espone la confidenza della predizione, rende visibili i fattori che l'hanno determinata, fissa una soglia di confidenza al di sotto della quale l'escalation all'operatore è obbligatoria e prevede un percorso di fallback sicuro quando il modello opera fuori dal proprio dominio di validità.
La soglia di confidenza è la traduzione ingegneristica esatta dell'invariante che attraversa questa serie: un sistema deve sapere quando non sa, e fermarsi. Nel CRM ciò significa che il profilo non è una sentenza ma un segnale: una stima con un'incertezza associata, che oltre un certo grado di ambiguità non autorizza l'azione automatica ma la subordina al giudizio umano. Progettare quella soglia - sceglierne il valore, strumentarla, monitorarne la deriva nel tempo (model drift) - è il punto in cui l'ingegneria dei sistemi di elaborazione delle informazioni incontra il diritto e ne fa un requisito misurabile. Il cliente resta una persona, e non il suo profilo, esattamente nella misura in cui quella soglia è progettata per ricordarlo al sistema. Anche nel più commerciale dei territori vale la regola che attraversa questo libro: la persona precede la sua funzione - il cliente esiste, il profilo funziona.