Una società tecnologica italiana ha sviluppato una piattaforma web che consente a professionisti, imprenditori e aziende di creare il proprio Digital Twin: una copia digitale conversazionale che, a partire dalla conoscenza fornita dalla persona e dalle capacità dei modelli di intelligenza artificiale generativa, dialoga in testo e in video con i visitatori, con il volto e la voce della persona rappresentata.
Il Twin non si limita a rispondere: attraverso abilità agentiche genera documenti e preventivi, raccoglie e qualifica contatti, fissa appuntamenti e guida percorsi di apprendimento. Completano il prodotto un livello social, con pagine pubbliche, directory, feed e un sistema a crediti che consente al proprietario di monetizzare le proprie competenze.
Il team di BSD si è concentrato inizialmente su alcune domande fondanti, che avrebbero orientato l’intera progettazione.
Il progetto è stato sfidante: il valore del prodotto coincide infatti con il suo rischio principale. Quanto più il Twin somiglia alla persona che lo ha creato, grazie ai dati raccolti (volto, voce, biografia, opinioni, competenze), tanto più risulta credibile per chi lo interroga. Questo perché diventa in tutto e per tutto paragonabile alla persona reale.
-
01Che cosa replica esattamente il Twin della persona? Aspetto, voce, modo di esprimersi, opinioni, competenze?
-
02Chi può creare il Twin di chi, e che cosa impedisce di costruire la copia digitale di un'altra persona?
-
03Come si distingue ciò che il Twin conosce perché appartiene al bagaglio di conoscenze della persona stessa da ciò che invece apprende all’interno della piattaforma grazie all’IA?
-
04Le conversazioni con gli utenti possono modificare nel tempo ciò che il Twin conosce, ricorda o deduce?
-
05Quali azioni può compiere il Twin in autonomia, e con quali effetti su persone terze?
Le principali sfide in tema di privacy, sicurezza e intelligenza artificiale.
-
01IdentitàIl primo era il rischio di appropriazione dell'identità: nella versione iniziale del prodotto, la verifica documentale confrontava il nome dichiarato, non il volto, e un utente verificato avrebbe potuto costruire un Twin con il volto e la voce di un'altra persona.
-
02ConfusioneIl secondo era il rischio di “confusione” fra la persona reale e il sistema IA: il visitatore poteva credere di dialogare con la persona reale, quando in realtà stava parlando con la sua copia digitale.
-
03I guardrailsIl terzo era il rischio legato a guardrails affidati a istruzioni prompt-based e non a vincoli architetturali: l’aggiramento delle istruzioni da parte del Twin avrebbe potuto generare comportamenti difficilmente prevedibili.
Le 3 scelte di design della piattaforma.
-
01Nessun accountL'utente accede tramite QR code e inserisce solo i dati necessari per verificare il proprio soggiorno: nome, cognome, numero stanza e date di check-in/check-out. Questi dati non servono a costruire un profilo. Servono a generare un authentication token temporaneo, legato alla prenotazione, valido su un solo dispositivo e destinato a scadere al check-out.
-
02Inserire una validazione della strutturaIl token non diventa pienamente operativo senza verifica. Se la struttura valida i dati entro 48 ore, l'accesso resta attivo fino al check-out. Se la validazione non avviene o fallisce, i dati vengono cancellati.
-
03Chat de-identificate + privacy layerDurante il soggiorno, le conversazioni sono de-identificate: la struttura visualizza gli interlocutori solo come “User” e “Chatbot”. Dopo il check-out, un privacy layer rileva e maschera eventuali dati personali presenti nelle conversazioni, consentendo la conservazione solo in forma anonimizzata per finalità statistiche.
-
04Il ciclo di vita del datoAlla fine dello sviluppo, i dati dell’utente avevano un ciclo di vita ben definito essendo trattati per una finalità specifica, in un tempo limitato, e poi eliminati o trasformati in dati anonimi per finalità di training. QR code → dati minimi → token → validazione 48h → accesso temporaneo → chat de-identificate → privacy layer → dati anonimizzati
Solo con un intervento nelle prime fasi di design si è potuti orientare il progetto verso una direzione corretta che unisse le finalità imprenditoriali della start-up con le esigenze degli albergatori e gli obblighi di conformità normativa.Privacy by Design è la traduzione in misure e controlli di principi che il GDPR ha definito e che devono essere applicati in scenari sempre più complessi con l’avvento dell’IA.
La lezione del progetto
BSD in Action – prima costruire una rappresentazione condivisa del prodotto, poi applicarvi i framework di analisi
Il nostro primo passo non è stato quello di guardare con timore a questo progetto così ambizioso.
È stato quello di analizzarlo per capirne i rischi inerenti, ma con l’intento di trovare le soluzioni privacy by design più adatte.
Per farlo sono servite, nell’ordine: una demo completa del percorso dell’utente, quattro sessioni di audit di 4 ore ciascuna con il team di sviluppo. In questo modo abbiamo costruito un vero e proprio modello delle minacce (Threat Modeling) che ci ha permesso di ricostruire in modo scientifico gli scenari di rischio e i possibili impatti.
Da lì abbiamo definito le priorità di intervento e i controlli di privacy by design adeguati al rischio indicato.
-
01SYSTEM DISCOVERYFotografia del prodotto e diagramma dei flussiAbbiamo ricostruito il prodotto dalla registrazione alla cancellazione del Twin: 29 casi d'uso, 14 entità esterne, 10 processi, 7 archivi di dati e 36 flussi. Abbiamo distinto quattro livelli che nei prodotti di IA generativa sono spesso confusi (addestramento del modello, conoscenza del Twin, memoria conversazionale, profilo e inferenze sull'utente) e separato la conoscenza che deriva dalla persona da quella aggiunta dalla piattaforma. La fotografia del prodotto, validata dal cliente dopo una sessione di allineamento con i tecnici, è divenuta il riferimento unico dell'intera analisi: ogni minaccia, ogni controllo e ogni trattamento rinviano a uno dei 36 flussi identificati.
-
02THREAT MODELLINGIdentificazione sistematica delle minacceAbbiamo applicato il framework STRIDE, per le minacce alla sicurezza, e LINDDUN, per le minacce alla privacy, con la sua estensione dedicata all'IA generativa. Per le componenti di intelligenza artificiale abbiamo integrato OWASP Top 10 for LLM Applications e OWASP Agentic AI Threats and Mitigations; per le azioni del Twin, il riferimento architetturale SARC sulla governance degli agenti. Il risultato è un registro di 97 minacce, ciascuna ricondotta al caso d'uso e al flusso da cui origina: dalla fuga del prompt di sistema all'iniezione indiretta di istruzioni tramite siti e documenti caricati, dalla costruzione di un Twin con l'identità di un terzo alla diffusione di contenuti sintetici come autentici.
-
03RISK ASSESSMENTDal danno alla persona al rischio residuoOgni minaccia è stata ricondotta al danno che produce secondo la tassonomia di Solove e valutata con i quattro fattori del modello di Cronk (opportunità, motivazione dell'attore, gravità secondo il criterio di consapevolezza, beneficio e consenso, conseguenze tangibili) su scale numeriche esplicite. I controlli sono stati selezionati dal nostro catalogo interno (che alimentiamo con l’esperienza acquisita), ordinato secondo le otto strategie di privacy design di Hoepman, e il rischio è stato ricalcolato assumendone l'attuazione Per ogni minaccia che resta a rischio alto abbiamo indicato al cliente le possibili decisioni di design, con alternative motivate.
-
04AI GOVERNANCETrasparenza e azioni agenticheAbbiamo tradotto l'art. 50 dell'AI Act in requisiti di prodotto: dichiarazione di interazione con un sistema di IA generata dal sistema e persistente, istruzione per cui il Twin non può presentarsi come la persona reale ma come “copia digitale”, marcatura di origine dei contenuti sintetici secondo lo standard C2PA. Per le abilità agentiche abbiamo definito vincoli infrastrutturali, conferma umana per determinati atti e un registro delle operazioni per tenere traccia di ogni azione.
-
05COMPLIANCE GDPRDal registro delle minacce al set documentaleIl registro delle minacce è stata la base del set documentale. I registri dei trattamenti del titolare e del responsabile descrivono il prodotto, con i controlli attuati, e chiariscono un passaggio di ruolo decisivo: quando il Twin di un professionista raccoglie contatti, richieste di preventivo e appuntamenti per conto del proprietario, il professionista è titolare e la piattaforma agisce come responsabile del trattamento. Le informative sono state redatte per ciascuna categoria di interessati, comprese le persone rappresentate e i terzi citati dal Twin (art. 14 GDPR), e stratificate in un primo livello con testi brevi che appaiono all’interno dell’interfaccia utente quando il dato viene richiesto.
Cosa abbiamo prodotto concretamente.
-
Deliverable 01Fotografia del prodottoModello del sistema validato dal cliente: perimetro della prima versione pubblica, casi d'uso, attori, inventario dei dati e degli archivi, catena dei fornitori e diagramma dei flussi.
-
Deliverable 02Registro delle minacce97 minacce, ciascuna con scenario, attore, soggetto a rischio, danno secondo la tassonomia di Solove, fattori di rischio, controlli esistenti e raccomandati, rischio inerente e residuo
-
Deliverable 03Report Privacy & AI by DesignExecutive summary con le otto raccomandazioni cardine e il punto di vista di BSD, analisi per area funzionale, matrici del rischio inerente e residuo, decisioni rimesse al cliente e presupposti per la valutazione d'impatto e per la conformità all'AI Act.
-
Deliverable 04Piano dei controlli per priorità56 controlli da attuare prima del lancio e i successivi, a tre e sei mesi, ciascuno con responsabile, evidenza attesa e riferimento normativo e tecnico.
-
Deliverable 05Registri dei trattamentiRegistro del titolare e registro del responsabile, con basi giuridiche, termini di conservazione, destinatari e misure per ciascun trattamento.
-
Deliverable 06Informative privacyInformative per proprietari del Twin, visitatori, persone rappresentate e terzi.
-
Deliverable 07Dichiarazioni in prodotto e consensi+50 testi di primo livello da far apparire nel corso della registrazione, della creazione del Twin e durante le conversazioni (consensi, avvisi, dichiarazioni di interazione con l'IA).