Il D.lgs. 231/2001 ha introdotto nell’ordinamento italiano un principio tanto semplice quanto impegnativo: l’ente può essere chiamato a rispondere di reati commessi nel proprio interesse o vantaggio da amministratori, dirigenti o dipendenti, salvo dimostrare di aver adottato ed efficacemente attuato un Modello di organizzazione, gestione e controllo idoneo a prevenirli. La parola chiave, spesso trascurata nella prassi applicativa, è “efficacemente”: non basta l’esistenza del documento, occorre la sua concreta operatività[1].
Ed è proprio su questo terreno che si misura lo scarto tra teoria e pratica. In numerose imprese, anche di dimensioni significative, il Modello nasce da un progetto di adeguamento normativo, è approvato dal consiglio di amministrazione, distribuito ai dipendenti attraverso una comunicazione formale e poi, salvo eventi straordinari, aggiornato a distanza di anni. Nel frattempo, l’OdV esercita la propria funzione attraverso strumenti in larga parte manuali: verbali di riunione, interviste ai responsabili di funzione, controlli a campione su un sottoinsieme di operazioni, richieste di flussi informativi che dipendono dalla collaborazione spontanea delle strutture aziendali.
Questo approccio non è privo di ragioni storiche: il Modello nasce in un contesto normativo che non prevedeva strumenti digitali di controllo continuo, e per anni la giurisprudenza si è concentrata più sulla completezza del catalogo dei rischi-reato e dei protocolli che sulla loro effettiva tracciabilità operativa. Ma è un approccio che mostra crescenti limiti strutturali. Il controllo a campione, per definizione, non copre l’universo delle operazioni. Le interviste e i verbali sono difendibili in giudizio solo fino a un certo punto, perché documentano ciò che i soggetti intervistati dichiarano sia accaduto, non ciò che è effettivamente accaduto. E l’aggiornamento periodico, anziché continuo, lascia scoperti i periodi intermedi, proprio quelli in cui l’organizzazione cambia, i processi si evolvono, nascono nuove aree di rischio.
Il risultato è un paradosso non infrequente nella prassi degli accertamenti: imprese dotate di un Modello organizzativo formalmente completo, ricco di protocolli e procedure, che tuttavia non riescono a dimostrarne l’efficace attuazione nel momento in cui è richiesto, perché mancano evidenze oggettive e verificabili delle decisioni assunte, delle autorizzazioni concesse, dei controlli realmente eseguiti.
Indice degli argomenti
Dal documento all’infrastruttura: il nuovo baricentro della compliance 231
Il problema del Modello non è isolato. È la manifestazione, in un ambito specifico, di una tendenza più ampia che sta attraversando l’intera funzione compliance nelle imprese: lo spostamento da un modello documentale — fatto di policy, procedure, registri cartacei o digitalizzati ma comunque discreti — a un modello infrastrutturale, in cui la conformità non è più descritta da un testo ma incorporata nei sistemi che governano i processi aziendali.
Si tratta di una traiettoria che si osserva, con intensità diverse, in molti ambiti regolatori: nell’antiriciclaggio, dove i sistemi di monitoraggio transazionale sostituiscono progressivamente le verifiche manuali; nel whistleblowing, dove le piattaforme digitali garantiscono tracciabilità e riservatezza delle segnalazioni; nella rendicontazione di sostenibilità, dove la richiesta di dati granulari e verificabili spinge verso sistemi di raccolta strutturata piuttosto che verso report narrativi. In tutti questi casi il driver comune è lo stesso: la compliance smette di essere un esercizio di redazione documentale e diventa un problema di governo dei dati, della loro qualità, della loro tracciabilità, della loro integrità nel tempo.
In questo scenario la blockchain si candida a un ruolo specifico, che non deve essere confuso con l’entusiasmo generico spesso associato alla tecnologia. Il suo contributo non è l’innovazione in sé, ma la soluzione a un problema molto concreto: come garantire e preservare un dato nel tempo, rendendolo verificabile da soggetti terzi — un’autorità di vigilanza, un giudice, un revisore — senza dover riporre fiducia esclusiva in chi materialmente lo detiene e potrebbe, in astratto, alterarlo. È questa proprietà, e non la sua natura decentralizzata di per sé, a renderla rilevante per la compliance 231.
Blockchain e audit trail nel Modello 231
Applicata al Modello, la blockchain consente di trasformare un testo in un registro. Non si tratta di sostituire il documento — che resta necessario come cornice normativa, mappa dei rischi e catalogo dei protocolli — ma di affiancargli un layer di registrazione che documenti, in modo immutabile e verificabile, l’attuazione concreta di quei protocolli.
Cosa si registra, in concreto? Le decisioni sensibili assunte dagli organi sociali e dai soggetti apicali nelle aree a rischio-reato; le autorizzazioni concesse per operazioni che superano determinate soglie di rilevanza; gli accessi ai sistemi informativi che custodiscono dati critici, dalla contabilità ai sistemi di procurement; le operazioni che rientrano nelle categorie di rischio mappate dal Modello, dai pagamenti a fornitori alla gestione di rapporti con la pubblica amministrazione. Ogni evento è registrato con un timestamp certo e un hash che ne garantisce l’integrità: una volta scritto, il dato non può essere alterato retroattivamente senza che l’alterazione risulti evidente.
Questa proprietà cambia in modo sostanziale il valore probatorio del Modello. L’OdV non deve più fidarsi di ciò che gli è riferito essere accaduto, né limitarsi a un controllo a campione: può consultare un registro che, per costruzione tecnica, non consente riscritture silenziose del passato. In sede di accertamento, la differenza tra un verbale che attesta “è stato verificato che la procedura è stata rispettata” e un registro che dimostra, con evidenza tecnica non manipolabile, quando e da chi una determinata autorizzazione è stata concessa, non è marginale.
Vale la pena distinguere due concetti spesso sovrapposti nel dibattito pubblico: conservare un dato e garantirne l’integrità nel tempo. La conservazione digitale, anche quella a norma, risponde primariamente a esigenze di durabilità e leggibilità nel tempo del documento. La blockchain risponde a un’esigenza diversa e complementare: dimostrare che il dato conservato è esattamente quello generato al momento dell’evento, senza interventi successivi. È questa la funzione di “garanzia e preservazione” che rende la tecnologia particolarmente adatta a un contesto, come quello del Modello, in cui il valore del dato dipende in larga parte dalla sua non manipolabilità.
Smart contract nei protocolli 231: dalle regole scritte ai vincoli tecnici
Se la blockchain garantisce la tracciabilità di ciò che accade, gli smart contract intervengono su un piano diverso: codificano il protocollo di controllo interno stesso, trasformandolo da regola scritta, la cui osservanza dipende dalla disciplina individuale, a vincolo tecnico che condiziona l’esecuzione dell’operazione.
Più precisamente, lo smart contract è un programma che esegue automaticamente una regola al verificarsi di condizioni predeterminate. Nel contesto 231, la regola non nasce dal codice: deve essere previamente definita nel Modello e nei relativi protocolli, approvata dagli organi competenti e successivamente tradotta in condizioni verificabili dal sistema. Il codice costituisce quindi il livello esecutivo del presidio organizzativo, non la sua fonte normativa.
Quando le condizioni sono oggettive e traducibili in parametri informatici, il sistema può verificare in tempo reale la presenza delle autorizzazioni richieste, l’identità e i poteri dei soggetti coinvolti, il rispetto delle soglie economiche e la sequenza delle attività. Se una condizione non è soddisfatta, l’operazione può essere bloccata oppure indirizzata verso una procedura di eccezione soggetta a ulteriori controlli. Il presidio non opera più soltanto ex post, mediante la rilevazione della violazione, ma interviene nella fase stessa di esecuzione del processo.
Questa capacità resta tuttavia circoscritta al perimetro tecnico governato dal sistema. La sua efficacia dipende dall’affidabilità dei dati di ingresso, dalla corretta identificazione degli utenti, dalla custodia delle chiavi, dalla segregazione dei privilegi amministrativi e dalla conformità del codice al protocollo approvato. Sono quindi necessari audit del codice, versioning, tracciamento delle modifiche, procedure di emergenza e regole per la gestione delle eccezioni. Più che rendere una violazione assolutamente impossibile, lo smart contract può impedirne l’esecuzione ordinaria all’interno del processo digitalizzato e rendere immediatamente rilevabili i tentativi di aggiramento.
Esempi concreti
Alcuni esempi rendono immediata l’idea. Un protocollo che prevede la doppia firma obbligatoria per pagamenti sopra una determinata soglia può essere codificato in modo che l’operazione, tecnicamente, non possa essere eseguita finché non intervengono due autorizzazioni distinte e verificabili. I limiti di spesa per categoria — un classico presidio nelle aree a rischio corruzione o gestione dei rapporti con la pubblica amministrazione — possono essere incorporati come soglie che il sistema stesso impedisce di superare, anziché come regole affidate al controllo successivo. La segregazione degli accessi ai sistemi sensibili, principio cardine di molti protocolli 231 in materia di sicurezza informatica e gestione dei dati, può essere implementata come vincolo strutturale anziché come policy la cui violazione è rilevata, quando va bene, in sede di audit periodico.
Il cambiamento concettuale è significativo: si passa da un modello in cui la violazione è sanzionabile ex post a un modello in cui alcune tipologie di violazione sono rese tecnicamente impossibili ex ante. Questo non elimina, beninteso, il rischio di comportamenti elusivi — chi vuole aggirare un controllo trova spesso il modo di farlo, specie quando il controllo stesso può essere riconfigurato da chi ha privilegi amministrativi sul sistema — ma sposta significativamente l’asticella, restringendo lo spazio di manovra per le condotte più elementari e più frequenti nella casistica dei reati presupposto.
È bene essere chiari su un punto, per evitare un’enfasi eccessiva: gli smart contract sono efficaci per codificare regole oggettive, quantificabili, verificabili con criteri binari — una soglia superata o non superata, una doppia firma presente o assente. Sono invece uno strumento spuntato per le valutazioni che richiedono discrezionalità, giudizio di merito, bilanciamento di interessi: esattamente il tipo di valutazioni che il diritto penale, e la stessa disciplina 231, spesso richiedono. Su questo limite si tornerà più avanti.
AI e controlli preventivi nel Modello 231
Il terzo elemento dell’architettura proposta è l’intelligenza artificiale, e merita di essere isolato concettualmente dagli altri due perché svolge una funzione diversa. Se la blockchain garantisce l’integrità del dato e gli smart contract vincolano l’esecuzione delle operazioni, l’AI lavora sui flussi di dati così generati per individuare, in tempo reale, pattern che potrebbero segnalare un comportamento a rischio prima che si concretizzi in un reato presupposto.
Tre applicazioni meritano di essere richiamate in modo specifico, perché corrispondono ad altrettante esigenze operative dell’OdV.
Anomaly detection sui log transazionali
Modelli di apprendimento automatico, addestrati sui pattern ricorrenti delle operazioni aziendali registrate in blockchain, possono identificare deviazioni statisticamente significative rispetto al comportamento atteso: un fornitore che riceve pagamenti con una frequenza o un importo anomali rispetto allo storico, un dipendente che accede a sistemi sensibili al di fuori dei propri orari o delle proprie mansioni abituali, una sequenza di operazioni che, singolarmente lecite, assume un profilo di rischio se osservata nel suo insieme. Questi sistemi non sostituiscono il giudizio umano, ma restringono drasticamente l’universo di operazioni su cui concentrare l’attenzione, superando i limiti strutturali del controllo a campione.
Sistemi NLP per la revisione documentale
L’elaborazione del linguaggio naturale può essere applicata alla revisione automatica di contratti, lettere d’incarico, corrispondenza commerciale, per individuare clausole atipiche, formulazioni ambigue o riferimenti che ricorrono nella casistica dei reati presupposto — si pensi, a titolo di esempio, a clausole di intermediazione prive di causa economica chiara, spesso presenti nei fenomeni corruttivi, o a schemi contrattuali ricorrenti nelle frodi in danno dello Stato. Anche qui, la funzione è di segnalazione e prioritizzazione, non di sostituzione della valutazione legale.
Risk scoring continuo di fornitori e personale
Algoritmi di valutazione del rischio, alimentati da dati interni (storico delle transazioni, area organizzativa, esposizione alle aree sensibili del Modello) e da fonti esterne (informazioni camerali, precedenti giudiziari pubblici[2], indicatori reputazionali), possono attribuire un punteggio di rischio dinamico ai soggetti terzi e ai dipendenti esposti alle aree critiche, aggiornato in continuo anziché rivalutato a scadenze fisse, come avviene tipicamente nelle procedure di due diligence tradizionali.
In questo schema, l’AI diventa uno strumento operativo dell’OdV, non un’infrastruttura a supporto del business che l’OdV osserva dall’esterno. La differenza non è terminologica: significa che gli output dei sistemi di AI — alert, punteggi, segnalazioni — entrano direttamente nel perimetro delle evidenze che l’OdV utilizza per l’esercizio della propria funzione, con tutte le conseguenze che questo comporta in termini di responsabilità, tracciabilità delle logiche decisionali e necessità di validazione periodica dei modelli stessi.
OdV e Modello 231 digitale: nuove competenze e responsabilità
Un’architettura di questo tipo non è neutra rispetto al ruolo dell’OdV: lo trasforma. Da verificatore che opera per campionamento e interviste, l’OdV evolve verso un supervisore di sistema, chiamato a validare l’architettura tecnologica che genera le evidenze, a interpretare dashboard e segnalazioni algoritmiche, a stabilire soglie di allerta e criteri di escalation.
Questa evoluzione richiede competenze che, storicamente, non sono sempre state parte del profilo tipico dei componenti dell’OdV, spesso selezionati per competenze giuridiche, di risk management o di internal audit in senso tradizionale. Non si tratta di trasformare l’OdV in una funzione tecnica in senso stretto — la responsabilità di validare le logiche e i limiti dei modelli di AI può e deve essere condivisa con funzioni tecniche specializzate, interne o esterne — ma di sviluppare una capacità di lettura critica degli output algoritmici, di comprensione dei limiti statistici di questi strumenti, di consapevolezza dei rischi di falsi positivi e falsi negativi.
Proprio i falsi negativi meritano attenzione specifica, perché aprono una questione di responsabilità non banale: se un sistema di AI non intercetta un pattern che, con un controllo umano tradizionale, sarebbe stato individuato, l’affidamento sul sistema esonera l’OdV, o la aggrava per aver riposto fiducia eccessiva in uno strumento automatico? La risposta, con ogni probabilità, dipenderà dalla capacità dell’impresa di dimostrare di aver adottato un sistema di AI validato, testato, periodicamente ricalibrato — in sostanza, di aver esercitato una diligenza tecnica analoga a quella richiesta per i controlli tradizionali, spostata su un piano nuovo[3].
Emerge, in altre parole, un requisito ulteriore di idoneità del Modello: non solo l’adeguatezza dei protocolli di controllo, ma l’adeguatezza e l’auditabilità degli strumenti tecnologici che quei controlli attuano e monitorano.
Compliance digitale 231 tra GDPR, smart contract e valore probatorio
Un’architettura che integra blockchain, smart contract e AI nel Modello solleva questioni giuridiche che meritano un approfondimento dedicato, ma che è utile almeno enunciare in questa sede.
Immutabilità blockchain e protezione dei dati personali
Un registro blockchain che documenta accessi, operazioni e comportamenti di singoli dipendenti tratta, inevitabilmente, dati personali, talvolta appartenenti a categorie particolari. L’immutabilità che costituisce il pregio tecnico della tecnologia si scontra con i principi di minimizzazione, limitazione della conservazione e, in alcune configurazioni, con il diritto alla cancellazione previsto dal GDPR. Le soluzioni tecniche esistono — dalla registrazione on-chain di soli hash, con i dati sostanziali conservati off-chain e cancellabili, a schemi di blockchain permissioned con governance centralizzata sulla retention — ma richiedono una progettazione attenta fin dalla fase di disegno del sistema, secondo una logica di privacy by design che non può essere un ripensamento successivo[4].
I confini di ciò che uno smart contract può codificare
Come già osservato, gli smart contract funzionano bene per regole oggettive e quantificabili. Molte delle valutazioni richieste dal diritto penale e dalla stessa disciplina 231 — l’esistenza di un interesse o vantaggio dell’ente, l’elusione fraudolenta dei modelli di controllo, l’idoneità in concreto di un presidio rispetto a un rischio specifico — restano ancorate a un giudizio che nessuna codificazione tecnica può sostituire. L’illusione di una compliance “automatica al cento per cento” sarebbe, in questo senso, fuorviante e potenzialmente controproducente, se inducesse le imprese a ridurre il presidio umano nella convinzione che il sistema tecnico si autoregoli.
Il valore probatorio della blockchain in sede di accertamento
Sebbene l’immutabilità tecnica di un registro distribuito offra garanzie significative, il suo valore in un eventuale procedimento dipenderà anche da fattori che la tecnologia da sola non risolve: l’affidabilità del punto di immissione del dato (il cosiddetto problema dell’oracolo, ossia la garanzia che il dato inserito in blockchain corrisponda fedelmente all’evento reale), la configurazione della rete (pubblica, privata o permissioned, con implicazioni diverse sul grado di decentralizzazione e quindi di garanzia), e l’assenza, allo stato, di una disciplina processuale organica sul valore probatorio di questi registri, che rende necessaria una valutazione caso per caso da parte del giudice[5].
Verso un Modello 231 che genera, verifica e apprende la compliance
L’integrazione di blockchain, smart contract e intelligenza artificiale non trasforma il Modello in un sistema infallibile, né esonera le imprese dal presidio umano che resta, e resterà, il cuore di qualunque sistema di controllo interno credibile. Ciò che cambia è la natura stessa del Modello: da documento che descrive, sulla carta, un sistema di controllo interno, a infrastruttura che quel sistema lo implementa concretamente, ne verifica in continuo l’attuazione e, attraverso l’AI, ne affina progressivamente la capacità di individuare segnali deboli di rischio prima che si traducano in reato.
È una direzione che si inserisce coerentemente nella traiettoria più ampia lungo cui si sta muovendo l’intera funzione compliance, sempre più orientata verso piattaforme digitali capaci di garantire, insieme, tracciabilità, integrità e capacità predittiva. Per le imprese che vorranno intraprendere questo percorso, la sfida non sarà tanto tecnologica — le componenti tecniche esistono già, singolarmente mature — quanto organizzativa e giuridica: progettare un’architettura che rispetti i vincoli di protezione dei dati, che lasci all’OdV e al giudizio umano lo spazio insostituibile che nessun algoritmo può occupare, e che sia in grado di dimostrare, in sede di accertamento, non solo la propria esistenza formale ma la propria concreta ed efficace attuazione. Un Modello, in definitiva, che non si limita più a documentare la compliance, ma che la genera, la verifica e la apprende.
Note
[1] Più specificamente, il d.lgs. 231/2001 prevede la responsabilità dell’ente per i reati-presupposto commessi nel suo interesse o vantaggio da soggetti apicali o da persone sottoposte alla loro direzione o vigilanza. I criteri di imputazione e le condizioni di efficacia esimente del Modello non sono tuttavia identici: per i reati commessi dagli apicali opera il regime previsto dall’articolo 6; per quelli commessi dai sottoposti, l’articolo 7 collega la responsabilità dell’ente all’inosservanza degli obblighi di direzione o vigilanza. In entrambi i casi, il punto decisivo non è la mera esistenza del documento, ma la sua idoneità preventiva e la sua concreta ed efficace attuazione.↩
[2] Sistemi algoritmici possono integrare dati interni, quali lo storico delle transazioni e l’esposizione alle attività sensibili, con fonti esterne selezionate sulla base di criteri preventivamente definiti. Il punteggio deve avere funzione di segnalazione e prioritizzazione e non può sostituire la verifica umana o costituire, da solo, il fondamento di una decisione sfavorevole. L’utilizzo di dati relativi a condanne penali e reati richiede una specifica base normativa e garanzie adeguate: la semplice disponibilità pubblica dell’informazione non ne legittima automaticamente il trattamento. Nel caso dei dipendenti devono inoltre essere rispettati i principi di necessità, proporzionalità e trasparenza, la disciplina sul controllo dei lavoratori e, quando applicabili, gli obblighi previsti per i sistemi di AI ad alto rischio utilizzati per monitorare, valutare o assumere decisioni relative al rapporto di lavoro.↩
[3] Allo stato, le indicazioni giurisprudenziali specificamente riferite all’impiego dell’intelligenza artificiale da parte dell’OdV sono pressoché assenti. I principi generali consentono tuttavia di escludere che il ricorso all’AI trasferisca allo strumento la funzione di vigilanza o interrompa la catena della responsabilità umana. L’AI resta un mezzo istruttorio e di supporto: individua anomalie, ordina le informazioni e genera segnalazioni, ma la valutazione finale, la definizione delle priorità e le decisioni conseguenti restano affidate all’OdV.
In presenza di un falso negativo, la questione non sarebbe quindi se l’algoritmo abbia autonomamente “sbagliato”, ma se l’OdV abbia selezionato e utilizzato lo strumento con la diligenza richiesta dalla propria funzione. Rileverebbero, in particolare, la preventiva validazione del sistema, la comprensione dei suoi limiti, il controllo della qualità dei dati, il monitoraggio delle prestazioni, la periodica ricalibrazione e il mantenimento di verifiche umane o di altri controlli compensativi. Un affidamento acritico sugli output, l’assenza di verifiche oppure il mancato intervento davanti a segnali di malfunzionamento potrebbero concorrere a integrare un’ipotesi di omessa o insufficiente vigilanza.
Ciò non comporta una responsabilità personale automatica dei componenti dell’OdV per ogni errore del sistema. L’eventuale responsabilità civile o penale richiederebbe comunque l’accertamento degli specifici obblighi gravanti sul componente, della condotta colposa o dolosa e del relativo nesso causale. Resta però fermo il principio secondo cui la funzione di vigilanza non può essere delegata alla macchina.↩
[4] In questo contesto, privacy by design significa anzitutto verificare, prima della scelta tecnologica, se l’impiego della blockchain sia necessario e proporzionato rispetto alle finalità perseguite e se le stesse garanzie possano essere ottenute mediante strumenti meno rigidi. La valutazione deve precedere la progettazione della rete e riguardare finalità, basi giuridiche, categorie di dati, soggetti coinvolti, ruoli privacy, localizzazione dei nodi, tempi di conservazione e modalità di esercizio dei diritti degli interessati. Le risultanze devono confluire nella valutazione d’impatto sulla protezione dei dati quando il trattamento presenta un rischio elevato.
Le Guidelines dell’EDPB sul trattamento dei dati personali mediante tecnologie blockchain, adottate in versione finale il 7 luglio 2026, rafforzano questo approccio. In linea generale, i dati personali sostanziali, e a maggior ragione i dati appartenenti a categorie particolari o relativi a condanne e reati, non dovrebbero essere registrati direttamente on-chain. È preferibile conservarli in ambienti off-chain protetti e registrare sul ledger soltanto riferimenti o impegni crittografici strettamente necessari alla verifica dell’integrità.
La registrazione di un hash non determina, da sola, l’anonimizzazione del dato. Se l’hash, una chiave pubblica, un identificativo o un event log può essere collegato direttamente o indirettamente a una persona mediante mezzi ragionevolmente utilizzabili, esso resta un dato personale. Devono pertanto essere valutati la prevedibilità dei dati originari, l’utilizzo di segreti crittografici, la gestione e revoca delle chiavi, l’accessibilità delle informazioni e il rischio di ricostruzione o correlazione.
La progettazione deve infine prevedere sin dall’origine i meccanismi necessari per la rettifica, la cancellazione o l’effettiva indisponibilità dei dati off-chain, la limitazione degli accessi, la gestione della retention, la risposta agli incidenti e la documentazione delle responsabilità dei diversi partecipanti. Una blockchain permissioned può facilitare la governance e l’attribuzione dei ruoli, ma non rappresenta, di per sé, una garanzia di conformità al GDPR.↩
[5] Il valore probatorio della blockchain deve oggi essere esaminato anche alla luce del Regolamento eIDAS, come modificato dal Regolamento (UE) 2024/1183. Il nuovo quadro europeo prevede che un registro elettronico non possa essere privato di effetti giuridici o dell’ammissibilità come prova per il solo fatto di essere in forma elettronica o di non possedere i requisiti di un registro elettronico qualificato. Soltanto i dati contenuti in un registro elettronico qualificato beneficiano tuttavia della presunzione relativa alla loro integrità e al loro ordinamento cronologico unico e accurato.
Ne consegue che l’impiego di una blockchain aziendale può rafforzare significativamente l’audit trail, ma non attribuisce automaticamente alle registrazioni una presunzione legale di correttezza. Restano da dimostrare l’affidabilità della fonte del dato, l’identità di chi ha compiuto l’operazione, la custodia delle chiavi, la configurazione e la governance della rete, la continuità del sistema e la corretta conservazione delle evidenze. La blockchain può attestare che un determinato contenuto non è stato modificato dopo la registrazione; non prova, da sola, che quel contenuto fosse originariamente vero, completo o giuridicamente valido.↩
Partecipa alla community