Per comprendere il potenziale a tutto tondo del modello di data ownership basato su una piattaforma neutrale (“trusted middleware”) che coordina i 3 strumenti OPen ALgorithms, Contratto-Codice e Fiducia KPI, è fondamentale una breve panoramica anche degli aspetti più strettamente tecnologici.
Per passare ad uno stato di implementazione, il modello deve poter contare su un insieme di proprietà tecnologiche aggiuntive. Vediamole più nel dettaglio
Personalizzazione degli algoritmi
Il framework OPAL ipotizza unicamente algoritmi pre-verificati ed approvati. Il presente modello invece prevede tre diversi tipi di algoritmi:
- Vetted Algorithms: come ipotizzati nel modello OPAL originale, adatti alla massima semplicità e velocità di esecuzione;
- Semi-vetted Algorithms: composti da sequenze di algoritmi vetted;
- Custom Algorithms: composti da codice scritto ad-hoc, che la piattaforma può simulare al data owner per permettere la comprensione dell’output indipendentemente dalla sua capacità di ispezionare il codice, eliminando l’offuscamento come metodo di creazione di asimmetria.
In quest’ultimo tipo di algoritmi, il modello si può adattare a qualsiasi tipo di elaborazione, anche senza l’obbligo di una certificazione preventiva; si creano così tre binari paralleli, ciascuno con una specificità. Una parte del business troverà conveniente utilizzare algoritmi vetted, se compatibili con il proprio obiettivo, poiché la probabilità e la velocità di approvazione da parte dal data owner sarà tendenzialmente più alta rispetto ad un algoritmo custom. Esempi di algoritmi vetted possono essere: analisi di testo, analisi di immagini, invio di comunicazioni via email e creazione di dati “custom” nel portafoglio dati gestito dall’owner (es: un servizio di streaming musicale ritiene che un certo utente apprezzi la musica dei Beatles, quindi inferisce il relativo dato sulla piattaforma e non nel proprio sistema). Al tempo stesso, il processo più esigente potrà proporre le elaborazioni personalizzate di cui ha bisogno, senza altri limiti se non le potenzialità del codice stesso e della sua sintassi. Starà all’utente analizzare l’algoritmo, con il supporto della piattaforma che potrà simularne il comportamento e facilitarne la comprensione.
Coesistenza con il modello classico del data sharing
Il modello basato su OPAL e contratto-codice può coesistere con la logica tradizionale del data sharing. Non è detto infatti che tutti i dati debbano risiedere fuori dal sistema del data user, anche per evitare di sovradimensionare o sovraccaricare la piattaforma di middleware. In questo caso la criticità maggiore è stabilire quale sia la linea di demarcazione fra un dato da proteggere by design ed un dato che può essere condiviso. Questo è un tema con risvolti etici e filosofici che trascendono gli obiettivi di questo documento.
| Esempio: piattaforma di ownership mista. Si consideri un servizio di activity tracking sportivo (l’esempio, mutatis mutandis, vale anche in ambito aziendale per il tracking dei processi produttivi). L’utente potrà contare su protezione by design per i propri dati anagrafici e KPI di performance, KPI comportamentali e cronologia di localizzazione. I dati puntuali di ogni attività (ad eccezione della localizzazione puntuale), nonché le relazioni fra i vari utenti e tutti i dati necessari ad erogare il servizio attraverso app potranno risiedere sul sistema del servizio, fintanto che non produrranno dati “ad elevato criterio di protezione”. |
Interfaccia di gestione della “fiducia KPI”
Nell’ambiente delegato all’elaborazione dei contratti-codice, la fiducia KPI è un vettore la cui dimensione è la somma del numero di contratti e di controparti contrattuali. Il contenuto di ciascuna componente del vettore è un indicatore normalizzato su scala 0-100 che rappresenta la predisposizione del data owner ad autorizzare la prossima esecuzione di uno specifico contratto-codice o bundle. Quando la piattaforma di middleware riceve la richiesta di esecuzione di un contratto, essa verifica che il valore di fiducia KPI sia uguale o superiore al valore trigger definito dal data owner attraverso interfaccia grafica o programmatica (API).
Marketplace contratti
La piattaforma di gestione dei contratti-codice non è concettualmente diversa da un firewall, che porta un beneficio una volta impostato correttamente. Dato che la maggior parte degli individui, indipendentemente dal ruolo business o consumer, non ha tempo e capacità per impostare il proprio cruscotto di autorizzazione e subscription ai contratti, dovranno esistere dei metodi per applicare istantaneamente dei bundle:
- Bundle di contratti: è un insieme di contratti-codice che può essere proposto da una piattaforma di servizio oppure da un qualsiasi utente o ente di ecosistema. Il bundle di contratti semplifica la scelta di sottoscrizione sostituendo la decisione con la fiducia verso l’autore del bundle.
| Esempio: il bundle di contratti della pubblica amministrazione. Il cittadino che volesse interagire in modalità programmatica con la PA, avrà a disposizione uno o più bundle, sottoscrivibili via mobile app, per specifiche attività:
|
- Bundle di Set-up: è un insieme di impostazioni di gestione della fiducia che tipicamente ottimizza la gestione dei contratti-codice per particolari categorie di utenti e data owner.
Esempio: bundle di impostazione per le relazioni con la propria banca.All’atto della sottoscrizione di una carta di credito, la banca sottoporrà al cliente via banking dashboard un bundle di impostazioni per la sottoscrizione automatica dei contratti-codice per la gestione della carta stessa. Non sarà il cliente a doversi preoccupare di capire cosa attivare e dove, ma sarà la banca a proporre di sottoscrivere il bundle con una notifica push. In questo modo il cliente attiverà una serie di servizi utili per la gestione, front-end e back-end, della carta di credito, potendo monitorare l’utilizzo dei dati e agire successivamente personalizzando il bundle se necessario.
Marketing pipeline
L’opt-in/out da in contratto-codice a seguito della modifica della fiducia KPI può avere conseguenze sul servizio. Per evitare scelte automatiche non consapevoli oppure scelte consapevoli le cui conseguenze non siano chiare, la piattaforma deve fornire al data user gli strumenti (via API) per interagire con il data owner prima che la scelta sia definitiva.
| Esempio: evitare un opt-out indesiderato. Si immagini un utente che, sottoscrivendo un bundle di pre-set su contratti-codice assicurativi, così facendo indirettamente modificasse il livello trigger di fiducia per la gestione della carta di credito. Il rischio sarebbe quello di trovarsi improvvisamente nell’impossibilità di effettuare transazioni. In questo caso opportune logiche di intelligenza artificiale devono rileveranno l’elevata frequenza del servizio che verrebbe disabilitato e, attraverso una notifica immediata, chiedere all’utente conferma sulle impostazioni, eventualmente suggerendo un’alternativa. |
User friendliness
Il contratto-codice è per sua natura strumento di libertà e non è un peso che diventa insostenibile. All’aumentare del grado di ownership però il modello può creare un nuovo carico di lavoro e attenzione per l’utente. Questo è un passaggio obbligato, un’inevitabile conseguenza della conquista di libertà che implica una responsabilità che va gestita. Tuttavia, questa gestione può essere semplificata e resa accettabile. Grazie alla tecnologia, la gestione di un contratto può essere supportata, se non addirittura automatizzata, attraverso regole (anche disponibili in bundle) la cui adozione può essere spontanea, stimolata da altri soggetti attraverso marketplace oppure da Intelligenza Artificiale.
Crittografia
L’uso di chiavi crittografiche asimmetriche è incluso nel modello by design, per garantire identità di data owner e user, oltre che per firmare o criptare i dati quando necessario.
Fuzzyness
“Se la natura avesse utilizzato un algoritmo predittivo per impedire una mutazione casuale nella replica del DNA, il nostro pianeta probabilmente sarebbe ancora in uno stato monocellulare, molto ottimizzato” (Ratti e Helbing 2018)[1]. Il rischio di radicalizzazione derivante da algoritmi centralizzati è serissimo e già visibile nelle piattaforme di servizio che facciano uso intensivo di personalizzazione data-driven. Per dotare il modello di anticorpi verso la radicalizzazione da big data, il protocollo deve prevedere la possibilità di inserire un livello di fuzzyness nell’output dell’elaborazione (es: un algoritmo delegato alle previsioni d’acquisto di libri, potrebbe deliberatamente inserire proposte casuali e valutare a posteriori, dopo migliaia di conversioni, l’eventuale emersione di pattern di acquisto non prevedibili su base storica). Questo ingrediente imprevedibile, fondamentale per un’evoluzione sana e sostenibile dell’intelligenza applicata al servizio, deve però essere dosato con cura dalle parti poiché può anche produrre importanti effetti collaterali. Considerando tecnologie automatizzate di elaborazione dei dati attraverso machine learning, la trasformazione di un dato addizionato di errore sistematico in un bias altrettanto sistematico è un rischio concreto (Benedetti in Pizzetti 2017)[2]. Ciò detto, la vita è straordinaria perché espone continuamente a situazioni la cui prevedibilità sarebbe stata bassa ed il cui impatto invece è potenzialmente altissimo. La maturità dell’economia data-driven passa anche dall’incorporare e gestire una certa dose di imprevedibilità come valore aggiunto, non come difetto.
Decentrabilità
In questo modello la decentralizzazione è un’opzione, non un requisito. Non è necessario decentralizzare la piattaforma o appellarsi alla tecnologia blockchain per avere un trusted middleware che gestisca i contratti-codice con sufficiente livello di garanzia. Una piattaforma che operi con i criteri di OPAL attraverso contratti-codice può anche operare con una logica tradizionale, utilizzando la tecnologia blockchain solo nei casi in cui sia necessaria (es: una piattaforma che operi da registro pubblico di proprietà di beni, potrebbe utilizzare la tecnologia blockchain limitatamente ai beni immobili, affidandosi alla firma digitale per certificare transazioni di beni mobili a più basso valore).
Elaborazione “on the edge”
Uno dei fattori critici di successo della piattaforma è garantire velocità di elaborazione ed economicità su ampia scala. Per raggiungere questo elevato livello di performance garantendo le proprietà del modello di ownership proposto, una delle opportunità è localizzare l’elaborazione fuori dalla piattaforma (es: un’app di servizio che debba continuamente elaborare le stesse informazioni, potrebbe implementare un SDK localmente, ricevendo dalla piattaforma i dati e mantenendoli protetti in un apposito sandbox).
Ispezionabilità
La piattaforma e le parti sono da ritenere responsabili per gli effetti dell’uso del dato, anche se non sono in grado di spiegare completamente in che modo esso si sia prodotto. Per questo motivo gli algoritmi devo essere ispezionabili e la piattaforma deve avere le proprietà definite dalla World Wide Web Foundation, 2017[3].
Il testo completo della pubblicazione:
___________________________________________________________________
Riferimenti.
- Ratti C., Helbing D. (2018) “The hidden danger of big data.” http://senseable.mit.edu/papers/pdf/20180605_RattiHelbing_Hiddendanger_Springer.pdf ↑
- Benedetti D., in Pizzetti F. (2017) “Intelligenza artificiale, protezione dei dati personali e regolazione”, Giappichelli ↑
- World Wide Web Foundation (2017) “Algorithmic Accountability”https://webfoundation.org/docs/2017/07/Algorithms_Report_WF.pdf ↑
