Il timore di subire conseguenze negative dalla condivisione dei dati pone dei limiti alla partecipazione di individui ed aziende alla data-driven economy. In questo momento, avere una relazione digitale significa nella maggior parte dei casi cedere dati a soggetti che li utilizzano in modalità “black box”, descritta da una policy non verificabile né monitorabile o personalizzabile. La soluzione a questo problema è un modello alternativo di data ownership basato su una piattaforma neutrale (“trusted middleware”) che coordina 3 strumenti:
- OPen ALgorithms (Hardjono e Pentland 2017)[1]: lo strumento tecnologico che abilita co-creazione di valore dai dati senza necessità di data sharing (protezione by design);
- Contratto-Codice: lo strumento economico-organizzativo che specifica i parametri ed il processo di elaborazione dei dati in modalità machine-readable;
- Fiducia KPI: lo strumento decisionale che supera la policy e permette di gestire i dati e le elaborazioni in modo consapevole e personalizzato.
Figura 1: Elabo-relazione, OPAL, contratto-codice e fiducia KPI.
Il “peccato originale” del data sharing
L’attuale logica di adesione al servizio digitale prevede una relazione basata sul conferimento di dati da parte del “data owner” al “data user”. Questo rapporto, necessario per eseguire un contratto di servizio, prevede l’accettazione di una policy che descrive l’utilizzo dei dati da parte del sistema del data user, spesso di fatto una “black box” non monitorabile. Con questo modello di ownership non è possibile avere un effettivo controllo di come i dati vengono utilizzati, né poterne personalizzare l’elaborazione. La policy è uno switch on/off sbilanciato verso il data user, un atto di fede one-time i cui effetti non sono valutabili dal data owner né al momento del click sul bottone ACCETTA, né in un secondo momento. Le conseguenze di questa situazione si osservano sempre più spesso:
- per l’individuo: la mancanza di consapevolezza e personalizzazione sull’uso dei dati genera percezione di rischio di compromissione della privacy e, secondariamente, frustrazione per una non equa suddivisione del valore generato dai dati stessi;
- per l’azienda: l’eventualità che la condivisione dei dati porti ad una compromissione di valore di stato patrimoniale, alla perdita di competitività o ancora peggio alla rivelazione di segreto industriale, è limite e freno oggettivo all’uso del dato.
Quante opportunità si stanno perdendo a causa di questa situazione? Quale è il rischio che, sperimentata direttamente una compromissione di privacy o asset, individui ed aziende si rifugino nel rifiuto della condivisione del dato? Auto-escludersi dall’economia digitale non può essere l’unica soluzione.
Dalla fiducia “by policy” alla fiducia “by protocol”
Un’alternativa è possibile. Immaginare un’economia data-driven dove i dati non vengono condivisi può sembrare paradossale, ma non lo è. Un nuovo modello di data ownership che permetta di pro-azionare i dati senza condividerli è tecnologicamente possibile grazie al framework OPen ALgorithms (OPAL). Il suo funzionamento è semplice e innovativo: un soggetto (per esempio un’azienda) può richiedere alla piattaforma OPAL di eseguire un determinato algoritmo su dati relativi ad un utente, ottenendo il risultato dell’elaborazione senza avere accesso diretto ai dati. Con OPAL quindi “è il codice ad andare verso i dati, non viceversa”.
Tuttavia, sulla strada verso un modello di ownership più performante, la sfida principale da affrontare non è tecnologica, ma economico-organizzativa. È necessario definire prima possibile gli strumenti per gestire le relazioni data-driven con consapevolezza ad elevata intensità e frequenza, trasformando la fiducia “by policy” (un atto di fede one-time) in fiducia “by protocol” (un atto di fiducia responsabile espresso e modulato in real-time tramite software).
Lo strumento tecnologico: il framework OPAL
Risolvere il problema del data sharing richiede un’inversione dell’approccio classico ovvero, come si è già detto, “portare il codice ai dati”. Per fare questo, OPAL prevede un “trusted middleware“ la cui esistenza implica una revisione dei processi di elaborazione e gestione del dato, ma che non comporta per forza un impatto negativo sulla capacità di estrarne valore.
Se il risultato di un algoritmo può essere un’azione eseguita per conto del data user (es: inviare un’email), oppure un output in forma standardizzata (es: il vettore di appartenenza ad una serie di categorie predefinite), non ci sono limiti alle potenzialità del nuovo modello. I dettagli tecnici non saranno oggetto di questo documento, tuttavia si consideri che è possibile emulare gli effetti della disponibilità oggettiva del dato attraverso un efficace sistema di identificazione e tracking delle “inform-azioni”. C’è una differenza minima tra conoscere il numero di volo di un passeggero ed avere un protocollo efficiente di notifica e tracking dei vari stati del sistema utente-volo-servizio ai fini dell’erogazione del servizio stesso. C’è invece una differenza radicale sotto il profilo della data protection: nel secondo caso, l’utente accede ad un servizio (verosimilmente pagando una tariffa in moneta o comportamenti) senza cedere dati il cui valore potrebbe essere compromesso.
Figura 2: Confronto fra i due modelli.
Ecco risolto il problema del data sharing: utilizzando la logica OPAL è finalmente possibile condividere il valore estratto dal dato (informazione o azione) senza condividere il dato stesso, eliminando quindi il “peccato originale”. La protezione del dato “by protocol” condiziona perciò positivamente la pro-azione del dato, facendola diventare una scelta consapevole e redditizia, avviando un circolo che è virtuoso per tutti.
Il senso di urgenza per l’avvio di questo circolo virtuoso nasce da un bisogno profondo: la data-driven economy deve fondarsi infatti su un rapporto più trasparente fra owner e user, su un patto esplicito espresso con il formalismo tipico dei contratti e con la sintassi esemplare del codice. Uno strumento di co-creazione valore personalizzabile e monitorabile in real-time, che traduca parametri economici e fiduciari in una disposizione di calcolo machine-readable. Serve quindi uno strumento per definire precisamente il cosa-come-perché dell’elaborazione e questo strumento è il “contratto-codice”.
Lo strumento economico-organizzativo: il contratto-codice
Il contratto digitale descrive l’uso dei dati, siano essi già esistenti, conferiti o inferiti, oppure la creazione di nuovi. Il contratto è “protection by protocol, non by policy”, perché specifica l’algoritmo contrattuale ed i dati di input/output, ma non il loro contenuto. I dati rimangono nella piattaforma, che li elabora per conto del richiedente (user) e su autorizzazione del proprietario (owner) in un ambiente protetto, una specie di container logistico sicuro e finalizzato all’uso, non un caveau blindato ed inaccessibile.
Si possono distinguere 2 tipi principali di contratti-codice:
- i contratti “peer-to-peer”, che definiscono elaborazioni all’interno di una relazione di servizio e sono direttamente proposti dal data user al data owner in modalità push;
- i contratti “broadcasted”, pubblicati su un marketplace e sottoscrivibili dai data owner interessati con un semplice “click to subscribe”;
- Fee di elaborazione, ovvero il corrispettivo destinato alla piattaforma per l’elaborazione dell’algoritmo e la restituzione dell’inform-azione in forma di output;
- Valore contrattuale, che il data user propone al data owner come beneficio in cambio della sottoscrizione del contratto-codice;
- Premio di interoperabilità, in altre parole l’incentivo affinché il dato possa essere utilizzato per elaborazioni di ecosistema (rappresenta la possibilita dell’ecosistema di incentivare la circolazione del dato);
- Premio di esclusività, ossia l’incentivo a fornire accesso al dato alla sola parte che lo ha creato/inferito e rappresenta la possibilità per il data user di investire in competitività attraverso dati di suo esclusivo utilizzo (benché detenuti dalla piattaforma e attivamente gestiti dal data owner);
- Validità del contratto, che può essere definita con date, numero di elaborazioni o altra metrica riconosciuta dalle parti;
- Fee di rescissione, come valore che una parte riconosce all’altra in caso di revoca unilaterale dell’autorizzazione all’elaborazione; la rescissione bilaterale di un contratto è un ulteriore contratto che bilancia la fee di rescissione.
Figura 3: Parametri economici del contratto-codice.
Lo strumento decisionale: la fiducia KPI
Grazie al contratto-codice e ad OPAL, l’utilizzo dei dati è perfettamente tracciabile e la fiducia verso l’utilizzatore dei dati diventa una variabile di governo puntuale delle relazioni, in real-time. L’autorizzazione in forma di costante Sì/No, espressa attraverso un atto di fede one-time (la policy), diventa una variabile dinamica con un’intensità 0-100, costantemente aggiornata da uno stack eseguibile di regole e feedback gestito dal protocollo.
Figura 4: La fiducia dalla policy al protocollo (KPI).
È la versione software della fiducia consapevole, non diversa da quella che determina la qualità e la quantità delle relazioni fra gli individui. Grazie alla fiducia KPI, la propensione del data owner a proseguire una “elabo-relazione” con il data owner dipende dal rispetto del contratto-codice. Il valore contrattuale si è realizzato? Il risultato è gradito? Recepire i feedback relativi successivi all’esecuzione del contratto-codice può essere anche più facile di quel che sembra:
Vai alla seconda parte:
Il testo completo della pubblicazione:
__________________________________________________________
- Hardjono T., Pentland A. (2017) “Open Algorithms for Identity Federation.”https://arxiv.org/pdf/1705.10880.pdf ↑
