I timori legati alla violazione della privacy o alla compromissione di asset aziendali basati sui dati rischiano di fare perdere a individui ed aziende molte delle opportunità della data-driven economy. 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.
Esempi e applicazioni pratiche
Comprendere le logiche e l’impatto della combinazione di OPAL, contratto-codice e fiducia KPI non è semplice. Ulteriori esempi pratici possono aiutare a visualizzare i nuovi processi di interazione programmatica e percepirne il valore aggiunto:
| Esempio: subscription personalizzata di prodotto sulla base delle transazioni bancarie (es: carta di credito). Attraverso un servizio digitale dedicato, un utente potrebbe ottenere un programma di subscription prodotto (es: libri) personalizzato in base a contenuto, tempo e luogo degli acquisti effettuati con carta di credito. Il servizio di subscription sarà collegato con i dati bancari dell’utente attraverso contratto-codice, quindi non conferendo accesso diretto agli stessi e mantenendo il massimo livello di privacy. |
| Esempio: trasporto pubblico e personalizzazione. Uno studente che utilizza i mezzi di trasporto in modo flessibile, può muoversi con velocità delegando logistica e pagamenti ad un servizio digitale dedicato, ottimizzando anche i costi. Per fare questo, attraverso l’app del servizio, lo studente sottoscrive 3 contratti-codice primari, a loro volta collegati a bundle di contratti accessori ed impostazioni:
|
| Esempio: fornitura di energia elettrica. L’azienda che sottoscrive un contratto-codice di fornitura di energia elettrica ottiene contestualmente la proposta di bundle “Ottimizza e Risparmia”. Attraverso questo bundle di contratti-codice, l’azienda può ottenre un pricing personalizzato sulla base di:
Tutte le elaborazioni di cui sopra senza cedere alcun dato alla società esterna, ma utilizzando le potenzialità del framework OPAL opportunamente implementato. |
Confronto con altri modelli
Diversamente da altre soluzioni già in fase di implementazione (Hawthorne, Engel e Norta)[2], il modello proposto non utilizza la tecnologia come strumento per garantire il valore su una piattaforma di “data exchange”, ma cerca invece una configurazione tecnologica che
- elimini la necessità stessa di scambiare il dato,
- predisponga uno strumento economico di “elabo-relazione” fra soggetti
- abiliti consapevolezza e controllo sull’uso del dato.
Si tratta di ricercare un diverso approccio alla soluzione del problema, non semplicemente una soluzione tecnica alternativa.
Il modello proposto rappresenta una soluzione di data ownership orientata alla massima semplicità, decisamente focalizzata sull’eliminazione del data sharing e sulla definizione di elabo-relazioni. Il contratto-codice è quindi una cosa diversa da una regola di accesso al dato, poiché l’accesso al dato non è più di fatto previsto. In questo senso, il modello proposto si differenzia da quello descritto dal progetto DECODE[3], le cui basi tecnologiche sono costituite da blockchain e crittografia attribute-based, con l’obiettivo di abilitare la creazione di “smart rules” per l’accesso al dato.
Relativamente ai “data commons”, il modello proposto non ha l’obiettivo di crearli direttamente, ma di abilitarli come conseguenza di un ecosistema data-driven efficace e profittevole, sostenuto da interoperabilità ed incentivi economici.
Infine, il modello proposto desidera caratterizzarsi per costi e complessità di implementazione relativamente contenuti.
Considerazioni sull’ownership
L’ownership piena è per gli utenti presupposto di partecipazione all’economia data-driven con un rischio misurabile, controllato e azionato con consapevolezza e responsabilità. Non è una partita a poker, è imprenditorialità personale e aziendale in un contesto dove i dati sono capitale che va investito progettandone i benefici e, soprattutto, monitorandone i fondamentali di impiego. Non è una sfida alle grandi piattaforme di servizio esistenti, ma al contrario è il tentativo di fare insieme ad esse un passo in avanti nella direzione di una maggiore consapevolezza dell’uso dei dati.
La logica di gestione delle elabo-relazioni senza data sharing può sembrare impraticabile su ampia scala, ma non lo è. L’impatto di questo nuovo approccio è trasversale a mondo consumer e business e coinvolge anche la sfera dei policy makers e dei developers in qualità di soggetti che “programmano” l’economia digitale.
Considerazioni per l’individuo, consumer e cittadino
Aderire alla data-driven economy con consapevolezza e responsabilità è un atto di cittadinanza digitale. Partecipare alla vita economica e sociale attraverso i dati deve essere una scelta autonoma e vantaggiosa, libera da asimmetria informativa, controllabile e personalizzabile. Gli strumenti tecnologici, economici ed organizzativi per rendere tutto ciò possibile ci sono. Il compito di policy makers, aziende e developers è quello di renderli disponibili, ma altrettanto importante è la volontà delle persone, cittadini e consumers, di utilizzarli individualmente producendo come effetto anche un’utilità collettiva.
Opportunità
- La partecipazione responsabile è potere: in un futuro dove dati e comportamenti sono risorsa abbondante, ognuno deve chiedersi come organizzare co-creazione di valore attraverso gli strumenti digitali; il rischio è non partecipare, rimanendo progressivamente esclusi dai benefici dell’economia del dato.
- Il futuro è di chi lo vuole “programmare”: elabo-relazionarsi con l’ecosistema digitale è il primo passo per “hackerare la città” (Ratti e Claudel 2017)[4] e contribuire alla sua evoluzione; nessuno è escluso dalla rivoluzione dell’economia data-driven: uno studente di scuola primaria può competere con un imprenditore adulto se padroneggia la sintassi del contratto-codice; acquisire competenze digitali non è utile solo per comprendere e capire il cambiamento, ma soprattutto per agirlo di persona.
Considerazioni per il business
Il dato può sviluppare stato patrimoniale e conto economico con rischio misurabile. Blindarlo nei server aziendali non è una scelta strategica, ma solo un rimedio temporaneo di fronte all’incertezza. Rimuovere quest’incertezza è un dovere di chi guida l’azienda attraverso i modelli di business e l’infrastruttura digitale. Nell’economia data-driven, l’azienda non è più definita dai confini fisici o di mercato, ma diventa “platfirm” (Accoto 2018)[5], ovvero tutt’uno con la dimensione del suo ecosistema digitale.
Opportunità
- La fine della black box come cassaforte del valore competitivo: le architetture digitali odierne non permettono al mercato di utilizzare il dato in modo consapevole e controllabile. È dovere del business cambiare modello di gestione del dato, rimuovere alla radice il “peccato originale” del data sharing e adottare gli strumenti del contratto-codice e della fiducia KPI. Questo comporta un cambiamento che è possibile e che è vantaggio competitivo.
- Attivare il dato per creare valore di conto economico: il cambio di approccio che il business può offrire al mercato è al tempo stesso un beneficio quando l’azienda diventa cliente. Se il dato è protetto by protocol è più facile attivarlo per produrre valore senza il timore di rivelare segreto industriale. Se questa attivazione avviene attraverso il contratto-codice, il valore può esse creato con grande velocità ed integrato nei cruscotti gestionali aziendali real-time. Questo approccio può essere molto utile anche in contesto consortile, laddove il contributo in dati di ciascun soggetto consorziato debba essere valorizzato e protetto al tempo stesso.
- Dimensionare e progettare il cambiamento: il cambio di approccio non deve essere visto come uno tsunami, ma come una marea. Rivoluzionare architetture di business ed informatiche dalla sera alla mattina non solo è impossibile, ma può essere destabilizzante. Una roadmap graduale e razionale è possibile.
- Dal data center ai data borders: il potenziale dell’azienda e del business è proporzionale alla quantità di dati che può raggiungere ed alla capacità di convertire i dati in informazioni utili a sé ed all’ecosistema in cui è inserita. Non ha più senso parlare di possesso del dato, dato che il possesso è limitato ai dati che riguardano un soggetto, ma non le sue relazioni ed il suo contesto. Il data center non rappresenta più il centro del mondo digitale. Il nuovo orizzonte dove tracciare la bottom line di conto economico è il “data border”, ovvero il confine esterno delle proprie relazioni digitali, il territorio di interazione e conversazione. Presidiare il data border presuppone il punto di osservazione più alto possibile, che non è la scrivania ricavata nel bunker raffreddato dove tipicamente alloggiare i server.
Considerazioni per i policy-makers
Serve un nuovo sistema di incentivi all’adozione di OPAL, contratto-codice e fiducia KPI. L’adesione degli individui e delle aziende ai nuovi modelli della società digitale può portare grandi benefici collettivi, ma difficilmente avverrà spontaneamente. Il cambiamento necessario comporta una revisione significativa di mindset, skill e architetture digitali.
Opportunità
- Incentivare il rinnovamento delle piattaforme digitali, per rendere tecnicamente disponibili gli strumenti necessari per modulare domanda ed offerta attraverso i contratti-codice;
- Stimolare la costituzione di ecosistemi di servizio, API ed alleanze fra algoritmi, oltre che partnership fra aziende;
- Attivare programmi di partecipazione e collaborazione trasversali a business, consumers e developers. Hackaton e programmi di open innovation hanno dimostrato una notevole capacita di generare innovazione incrementale e radicale.
- Rendere l’interoperabilità del dato una condizione per l’accesso a benefici individuali e aziendali, stimolando un concetto chiave: dal momento che un dato è creato e disponibile al data owner, più viene utilizzato è più crea valore. Il concetto di PIL pro-capite deve affiancarsi al PIL pro-dato.
- Misurare le esternalità: l’economia digitale produce esternalità positive e misurarle può rendere più facile prendere decisioni oggi ed in futuro. Se l’elaborazione del dato è tracciabile, misurare i suoi effetti è possibile e doveroso. Questo vale anche per le esternalità negative, per assicurarsi che il bilancio dell’economia data driven sia sempre positivo.
Considerazioni per le comunità di developers
Il codice è il linguaggio delle macchine che può diventare il linguaggio della società. Per questo, esso non deve più rimanere circoscritto ad una comunità specialistica, ma deve essere una parte del mindset e delle skill collettive. Ciò non significa che tutti debbano saper programmare, ma che conoscere limiti e potenzialità del codice è fattore abilitante per concepire buona innovazione. Le comunità di developers devono avere un ruolo attivo nel promuovere la cultura digitale ed i capisaldi del codice e dell’algoritmo. La nuova educazione civica ed imprenditoriale richiede di conoscere il codice.
Opportunità
- Diffondere la cultura del codice e dell’algoritmo: stimolare il non-developer a capire le potenzialità del codice, per facilitare creatività ed innovazione digitale. I nuovi strumenti del developer sono telecamera e microfono, per aiutare manager, funzionari pubblici e cittadini a capire il potenziale offerto dal contratto-codice.
- Progettare sostenibilità ed interoperabilita come condizioni di esistenza: realizzare un prodotto deve trascendere le funzioni richieste dal cliente. Se il cliente non richiede interoperabilità, essa va comunque “seminata” nel codice con best practice e predisposizione. Il developer deve vedere oltre la richiesta di oggi, per rendere le piattaforme compatibili con il domani. È un dovere etico come per il medico, il cui giuramento ad Ippocrate non consente di somministrare una cura sbagliata solo perché il paziente la richiede.
Vai alla terza e ultima parte:
OPAL e Contratto-Codice: proprietà ed estensioni tecnologiche del modello
Il testo completo della pubblicazione:
_______________________________________________________________
- Hardjono T., Pentland A. (2017) “Open Algorithms for Identity Federation.”https://arxiv.org/pdf/1705.10880.pdf ↑
- Hawthorne D., Engel S. L., Norta A. “A Data-Ownership Assuring Blockchain Wallet For Privacy-Protected Data Exchange”https://datawallet.com/pdf/datawallet_whitepaper.pdf ↑
- DECODE project, https://decodeproject.eu/ ↑
- Ratti C., Claudel M. (2017) “La città di domani”, Einaudi ↑
- Accoto C. (2018) “From firm to Platfirm” https://cosimoaccoto.com/2018/06/17/from-firm-to-platfirm-accoto-2018/ ↑
