Cookie free: nessun "biscotto" per spiare i lettori

Oggetto immodificabile nel protocollo informatico?

Il Testo unico sulla documentazione amministrativa prescrive l'immodificabilità di poche informazioni del protocollo. Le regole tecniche introducono la forzatura della "rinnovazione" in caso di errore. Questo comporta qualche incertezza.

Infatti, nel DPR 445/2000 sono descritte come immodificabili pochissime informazioni, tra cui il corrispondente (mittente o destinatario) e l'oggetto del documento. Le regole tecniche, invece, operano una forzatura, introducendo il concetto di "rinnovazione" in caso di errore. Ma allora, le informazioni immodificabili sono modificabili? Cosa si manda in conservazione? Siamo sicuri che tutto ciò che risulta informaticamente possibile lo sia anche giuridicamente? 

Data certa e provenienza certa, laddove certa assume il significato di cert(ificat)a. A questo serve - essenzialmente - la registrazione di protocollo nella propria funzionalità minima. Non a caso, da oltre due secoli, l'operazione è immodificabile.
Ciò avviene a tutela di terzi ma anche, in particolare, del pubblico ufficiale che agisce con una scrittura all'interno di un atto pubblico di fede privilegiata con funzione certativo-notarile qual è, appunto, il registro di protocollo.

In questo senso, l'immodificabilità è il primo e fondante requisito della forza probatoria delle registrazioni.
Di contro, quale affidabilità potrebbe avere una registrazione soggetta a potenziale modifica? Per questa ragione, la principale norma vigente in materia definisce come immodificabili le informazioni della registratura, come espressamente e inequivocabilmente disciplinato dal DPR 28 dicembre 2000, n. 445, art. 53, comma 1, che riprende in toto, implementandolo, quanto già disciplinato dall'art. 5 del DPR 428/1998:

1. La registrazione di protocollo per ogni documento ricevuto o spedito dalle pubbliche amministrazioni è effettuata mediante la memorizzazione delle seguenti informazioni:
a) numero di protocollo del documento generato automaticamente dal sistema e registrato in forma non modificabile;
b) data di registrazione di protocollo assegnata automaticamente dal sistema e registrata in forma non modificabile;
c) mittente per i documenti ricevuti o, in alternativa, il destinatario o i destinatari per i documenti spediti, registrati in forma non modificabile;
d) oggetto del documento, registrato in forma non modificabile;
e) data e protocollo del documento ricevuto, se disponibili;
f) l'impronta del documento informatico, se trasmesso per via telematica, costituita dalla sequenza di simboli binari in grado di identificarne univocamente il contenuto, registrata in forma non modificabile.

Il legislatore ha, però, introdotto la possibilità di una modifica delle informazioni registrate mediante rinnovazione. Si tratta di un aggiornamento del campo corrispondente (mittente o destinatario) e del campo oggetto. A ben vedere, però, si tratta di una modifica.
Infatti, con le regole tecniche prima contenute nel cessato DPCM 31 ottobre 2000 e poi replicate nel vigente DPCM 3 dicembre 2013 sul protocollo informatico, all'art. 8, comma 2, è stato disposto che:

2. L'annullamento anche di un solo campo delle altre informazioni registrate in forma immodificabile, necessario per correggere errori intercorsi in sede di immissione di dati delle altre informazioni, deve comportare la rinnovazione del campo stesso con i dati corretti e la contestuale memorizzazione, in modo permanente, del valore precedentemente attribuito unitamente alla data, l'ora e all'autore della modifica. La disposizione di cui al primo periodo si applica per lo stesso campo, od ogni altro, risultato successivamente errato.

Nel concreto, secondo la regolamentazione tecnica del DPCM sopra menzionato, sembrerebbe possibile superare l'ostacolo dell'immodificabilità prevista dal DPR con un'acrobazia lessicale. Ciò avviene semplicemente mantenendo traccia delle modifiche intervenute. Modifiche, appunto, indipendentemente dal nominalismo.

Nella prassi quotidiana, molti applicativi in uso nelle amministrazioni pubbliche e altrettanti modelli organizzativi consentono questo tipo di operazione in maniera eterogenea. Chi nell'arco delle 24 ore dalla registrazione, chi senza limiti di tempo, chi una volta soltanto, chi solo all'autore della registrazione, chi solo all'amministratore di sistema o al responsabile della gestione documentale.

Altri applicativi, invece, mantengono ferma la disposizione primaria inerente all'immodificabilità dei campi e consentono - ispirandosi alla legge notarile - soltanto annotazioni di carattere integrativo o, se necessario e come previsto dalla normativa vigente, l'annullamento della registrazione (DPR 445/2000, art. 54).

Il problema è che la presenza di un protocollista rigoroso e attento a non permettere modificazioni a un atto pubblico in contesti di sciatteria boiardica è percepita come mancanza di flessibilità, stante l'apertura del legislatore di tipo "rinnovativo". Di certo non innovativo, semmai regressivo rispetto a una funzione delicatissima per le evidenze documentali pubbliche.

L'interpretazione dei dirigenti più smart e degli informatici più open è in certi casi estensiva: si può cambiare l'oggetto o il mittente, modificando cioè persona fisica o azione giuridica. In sostanza, ciò significa cambiare completamente lo scenario probatorio della registrazione di protocollo, con conseguenti ricadute sul piano della certezza giuridica che la registrazione deve assicurare.

Si tratta di un'operazione inammissibile, contraria al buon senso e alle più elementari regole della trasparenza amministrativa. In definitiva, è possibile (anche ai fini dell'efficacia della ricerca) rinnovare in un limitatissimo numero di casi e non certamente cambiare il destinatario o modificare tutto il campo oggetto.

Ho conosciuto almeno due tipi di obiezione a un approccio rigoroso, quando quest'ultimo è chiamato a seguire i dettami dell'archivistica, della diplomatica e dell'informatica giuridica:
1. l'informatico dirà che l'evoluzione della tecnologia digitale permette di modificare la registrazione avendo cura di mantenere traccia di chi, come e quando, tant'è che la rinnovazione non confligge con l'immodificabilità;
2. il dirigente dirà che nell'era del digitale è permesso sbagliare, visto che esiste la possibilità di integrare, cancellare e correggere le registrazioni di protocollo.

La chiamano flessibilità, ma il vero nome è mancanza di rigore. Riguardo alla prima obiezione è facile ribadire, ancora una volta, che non tutto ciò che è informaticamente possibile lo è anche giuridicamente. Anzi, proprio la consapevolezza che una registrazione di protocollo possa essere rinnovata con relativa facilità, consente di favorire la superficialità e la mancanza di cura nell'effettuare le registrazioni di protocollo. Tanto poi, eventualmente, si può rinnovare.

Viene così meno anche l'amor proprio e l'orgoglio di essere funzionari pubblici in una delicatissima funzione notarile. Ci sono molti rischi e sussistono diversi problemi. Il primo risulta di natura giuridica ed è l'antinomia tra le due norme, l'art. 8 del DPCM è in contrasto palese con l'art. 53 del DPR, che il buon senso non dovrebbe risolvere con i criteri ermeneutici ordinari, in questo caso con il criterio cronologico o gerarchico.

In realtà, posto che il dettato tecnico limita la possibilità di modifiche "per correggere errori intercorsi in sede di immissione di dati", si potrebbe distinguere come possibile rinnovazione in caso di normali errori di ortografia, refusi e poco altro.
In caso di errori più gravi, infatti, il legislatore ha correttamente previsto l'annullamento della registrazione.

Si tratta, dunque, di un provvedimento e come tale deve essere adeguatamente motivato ed espressamente autorizzato. Quest'ultimo aspetto non è sottovalutabile, tant'è che una procedura corretta, adeguatamente descritta nel Manuale di gestione, dovrebbe prevedere una richiesta di annullamento motivata dal responsabile del procedimento o dal dirigente competente e una autorizzazione all'annullamento in capo al Responsabile o al Coordinatore della gestione documentale.

Lo impongono ragioni di trasparenza e il rispetto del principio di buon andamento e di imparzialità dell'attività amministrativa. Il tutto deve avvenire mediante un motore di flusso all'interno dell'applicativo, senza produzione di documenti protocollati o repertoriati, ma sfruttando le potenzialità in uso nel registro di protocollo stesso tramite campi immodificabili.

Non sono ammesse motivazioni del tipo "Come richiesto dal dirigente", "A causa di un errore", "Lettera non più spedita per cambio di idea", etc. Mi riprometto di ritornare su questo tema, anche per aggiornare il Protochorror di Aurora: riscontriamo nella prassi motivazioni ai confini della realtà¹.

Ai rilievi che tutto è tracciato, che tutto è sotto controllo, si può agevolmente rispondere che lo è in un determinato momento e con un determinato fornitore. Per fortuna esiste il registro giornaliero di protocollo e, soprattutto, il registro annuale che dovrebbero tenere traccia di tutto. Ciò significa che al conservatore digitale deve pervenire la sequenza completa di modifiche e che queste devono essere persistenti a lungo termine.

Siamo sicuri che ciò avvenga per tutti? Il rischio delle migrazioni e delle conversioni al cambio di sistema aumenta in maniera esponenziale questo tipo di preoccupazioni.

In caso di accesso, l'ostensibilità deve necessariamente riguardare la sequenza di modifiche intercorse, non soltanto l'ultima versione. Si accede, dunque, anche all'eventuale serie di rinnovazioni, al fine di garantire la trasparenza amministrativa. La casistica, pertanto, deve essere puntualmente descritta nel Manuale di gestione. La registratura, infatti, è una delicata funzione certativo-notarile, che non può essere piegata a "superiori esigenze organizzative".

1. Il progetto Aurora, ovvero: Come si descrive un oggetto e un corrispondente in un equilibrio tra analisi e sintesi è scaricabile dal sito di Procedamus: http://www.procedamus.it/materiali.html 

* Direttore generale dell'Università degli Studi dell'Insubria.