Ciclo di vita dematerializzato dei contratti pubblici: l’archivio destrutturato al veglione di San Silvestro

Il 31 dicembre 2025 l’Agenzia per l’Italia Digitale (AgID) ha approvato l’aggiornamento delle Regole tecniche sulla piattaforme di approvvigionamento digitale, elemento centrale per la cosiddetta “dematerializzazione del ciclo di vita dei contratti pubblici”, previsto dal decreto legislativo n. 36 del 2023 (il Codice dei contratti pubblici).

Un fine anno frenetico e convulso in casa AgID, per dare attuazione alle novità introdotte dal cosiddetto “correttivo al codice di contratti pubblici” (anch’esso del 31 dicembre, ma del 2024) e con la consueta spada di Damocle delle milestone PNRR che incombe sulla testa dei funzionari, principalmente quelli dell’AgID ma anche quelli degli altri enti di cui è necessaria l’intesa quado di parla di contratti pubblici dematerializzati: ANAC, DTD e ANC^[1]Autorità nazionale anticorruzione, Dipartimento per la trasformazione digitale e Agenzia per la cybersicurezza nazionale.. Questo almeno si percepisce dal burocratese della determina di approvazione delle regole (la n. 267 del 31 dicembre 2025). Ecco la timeline riscostruita:

• 12 dicembre 2025: l’AgID condivide con il DTD, l’ACN e l’ANAC lo schema delle regole tecniche;
• 18 dicembre 2025: il DTD dà il suo ok;
• 23 dicembre 2025: l’ACN dà il suo ok, chiedendo maggior allineamento con il quadro normativo europeo arricchito dalla direttiva NIS2;
• 23 dicembre 2025: anche l’ANAC dà il suo ok, ma lo subordina a numerose proposte di modifica;
• 24 dicembre 2025: l’AgID mette tutto insieme in un testo armonizzato che condivide con tutti i soggetti interessati;
• 30 dicembre 2025: l’ANAC avanza ancora delle richieste di modifica, fra cui l’obbligo di versare il registro di sistema in conservazione ogni 24 ore;
• 30 dicembre 2025: l’AgID confeziona il testo definitivo;
• 31 dicembre 2025: poco prima delle nove del mattino, ultima firma sulla determina di approvazione e pubblicazione sul sito dell’ANAC. La IX rata del PNRR è salva e pure il veglione.

Novità da una lettura selettiva

Mi sono ripromesso di leggere tutto attentamente, ma intanto sono andato a colpo sicuro a fare qualche confronto con la versione precedente, soprattutto per gli aspetti archivistici, cioè quelli che attengono a formazione, gestione e conservazione dei documenti che in qualche modo passano dalle piattaforme di approvvigionamento digitale (PAD). E-procurement e relative piattaforme sono temi che ho già affrontato su queste pagine.

La lettura selettiva ha evidenziato alcuni punti di interesse, alcuni dei quali, lo anticipo, hanno, da un certo punto di vista, una portata rivoluzionaria. Li elenco (seguono poi considerazioni diffusa su ciascuno):

• compaiono per i gestori delle piattaforme specifici obblighi di conservazione per il registro di sistema;
• prosegue la destrutturazione dell’archivio classicamente inteso;
• il fascicolo di gara sta nella PAD (elenco dei documenti che ci vanno, inversione a U rispetto a chi decide il piano di fascicolazione);
• la PAD è fonte autoritativa per l’autenticità dei documenti (servizio senza autenticazione per verificare se un documento è stato trattato dalla PAD);
• compare una categoria ulteriore di requisiti, i criteri di certificazione di classe 4 (procedure end-to-end), che riguarda il “test sul campo” di scenari d’uso reali che attraversano i requisiti delle altre classi e verificano la coerenza delle operazioni condotte dalla PAD (principalmente, sempre per ciò che riguarda direttamente l’interoperabilità con le banche dati centrali).

Come già segnalato da alcuni commenti alle nuove regole, in ambito apparentemente extra-archivistico fa il suo ingresso anche l’immancabile intelligenza artificiale, con proposte di uso concreto (con questioni di compliance e valutazione e classificzione del rischio tutte demandate agli enti).

Guida alla lettura dei requisiti

Nella prima versione delle regole, il documento principale (regole tecniche) elenca, numera e descrive il dettaglio dei requisiti della PAD (detti anche “criteri di certificazione”). L’allegato 2 era ed è una checklist (lista di riscontro) che ripercorre quei requisiti e fornisce i controlli da eseguire e superare per certificare una PAD. Nella nuova versione la descrizione del requisito è rimandata direttamente alla checklist, nel documento principale c’è solo l’elenco numerato e il “nome” dei requisiti, ancora distinti nelle categorie:

• requisiti derivanti da obblighi di transizione digitale (richiami al rispetto generale di altre norme);
• requisiti in materia di sicurezza delle informazioni (richiami al rispetto generale di altre norme);
• requisiti funzionali;
  • requisiti generali (Classe 1);
  • requisiti generali (Classe 2);
  • requisiti di interoperabilità (Classe 3);
  • (novità) requisiti di esecuzione di procedure end-to-end (Classe 4).

L’allegato 2 si conclude poi con una nuova sezione dedicata all’elenco dei documenti che ci si attende di trovare nel fascicolo di gara.

Conservazione a norma del registro di sistema

Rispetto alla versione precedente compare per la prima volta un obbligo di conservazione digitale (a norma) in capo al Gestore della PAD^[2]Il gestore della PAD è il soggetto che la fa funzionare e la mette a disposizione delle amministrazioni (ragionevolmente dopo averla anche progettata e realizzata dal punto di vista informatico). … Continue reading. L’obbligo riguarda l’invio giornaliero (ogni 24 ore) del registro di sistema della PAD:

Requisito	Ver. 2.0
[3.3.2.5-9]	Il Registro di sistema deve essere conservato a norma almeno ogni 24 ore anche al fine di garantire l’opponibilità verso terzi.

Il requisito è inserito nella famiglia [3.3.2.5] di caratteristiche che riguardano l'”Apertura e conservazione del fascicolo di gara in modalità digitale” e non nella [3.3.1.3] che riguarda il tracciamento degli eventi nel registro e le caratteristiche del registro stesso.

Potrei sbagliare, ma, nella versione 1.0 delle specifiche, l’obbligo di conservazione riguarda solo il fascicolo di gara ed è tutto in capo alla stazione appaltante (l’amministrazione che usa la piattaforma) e questo resta immutata nella nuova versione:

Requisito	Ver. 1.0	Ver. 2.0
[3.3.2.5-1]	La piattaforma deve predisporre le informazioni necessarie per la conservazione a norma del fascicolo di gara secondo le Linee Guida sulla formazione, gestione e conservazione dei documenti informatici e i relativi allegati.	La piattaforma deve predisporre le informazioni necessarie per la conservazione a norma del fascicolo di gara secondo le Linee Guida sulla formazione, gestione e conservazione dei documenti informatici e i relativi allegati.

Il requisito prevedeva e prevede che le PAD “predispongono le informazioni necessarie” per l’invio in conservazione”. Tale invio in conservazione non può che essere a cura dell’amministrazione, visto che i documenti e i fascicoli sono prodotti (o ricevuti) dall’amministrazione e non dal gestore della piattaforma, che non avrebbe titolo alcuno a versarli autonomamente in conservazione (al più su mandato o, meglio, accordo di servizio, dell’amministrazione).

Secondo il requisito [3.3.1.3-4] sulla tracciabilità degli eventi, anch’esso invariato, fra i documenti presenti nel fascicolo di gara è presente anche l’estratto del registro di sistema con le attività tracciate per la specifica procedura, ma la frequenza di estrazione è rimessa alla discrezione del Gestore ed, eventualmente, agli accordi contrattuali. Non esisteva un obbligo di conservazione del Registro di sistema in quanto tale. Infatti:

Requisito	Ver. 1.0	Ver. 2.0
[3.3.1.3-3]	La piattaforma deve garantire l’inalterabilità del Registro di sistema e la possibilità di verifica della sua integrità	La piattaforma deve garantire l’inalterabilità del Registro di sistema e la possibilità di verifica della sua integrità
[3.3.1.3-4]	La piattaforma deve produrre estratti del Registro di sistema con le informazioni raccolte per ogni singola procedura ed allegare tale estratto al relativo fascicolo di gara. La Piattaforma deve realizzare estratti del Registro relativi ad un periodo temporale determinabile dal Gestore del Sistema, ed eventualmente disciplinato nell’accordo contrattuale di cui al paragrafo 5.1.	La piattaforma deve produrre estratti del Registro di sistema con le informazioni raccolte per ogni singola procedura ed allegare tale estratto al relativo fascicolo di gara. La piattaforma deve realizzare estratti del Registro relativi ad un periodo temporale determinabile dal Gestore del Sistema, ed eventualmente disciplinato nell’accordo contrattuale di cui al paragrafo 6.1.
[3.3.1.3-5]	Le piattaforme devono avere la capacità di mantenere per due anni le informazioni presenti nel Registro di sistema, salvo differenti accordi con la SA presenti nell’accordo contrattuale di cui al paragrafo 5.1.	Le piattaforme devono mantenere integralmente per due anni il Registro di sistema, salvo la conservazione degli estratti di cui al requisito [3.3.1.3-4] che segue le regole di conservazione del fascicolo di gara ed eventuali ulteriori estensioni concordate con la SA e presenti nell’accordo contrattuale di cui al paragrafo 6.1 delle Regole tecniche.

Il nuovo requisito [3.3.2.5-8], invece, oltre a indicare una frequenza frequenza di invio in conservazione perentoria, parla proprio di registro di sistema tout-court e non si può che intendere il registro di tutte le operazioni che, a livello informatico, avvengono sulla PAD e di cui le regole tecniche impongono il tracciamento. Il registro è, dunque, il garante tecnologico dell’autorevolezza e dell’autenticità di dati e documenti prodotti e scambiati tramite la PAD, già che questa di fatto si configura come un ambiente chiuso e autosufficiente per garantire effetti giuridici validi e autenticità in senso lato a quanto avviene al suo interno. Per esempio, la PAD supera totalmente PEC e SERCQ per certezza e opponibilità a terzi delle comunicazioni.

Le nuove regole tecniche, quindi, specificano ulteriormente come garantire l’affidabilità del registro: ai generici richiami a strumenti che garantiscano l’inalterabilità (tutti da inventare a cura del gestore), si aggiunge un chiarissimo obbligo di invio in conservazione ogni 24 ore. Certo, vale la pena rimarcare come l’obbligo inserito fra quelli relativi alla tenuta del fascicolo di gara può ingenerare qualche dubbio: non è che per caso ci si riferisce all’estratto del registro? Inserirlo nella famiglia di requisiti [3.3.1.3] sulla tracciabilità sarebbe stato più chiaro.

Conseguentemente è il gestore della PAD che deve attivare un rapporto di servizio con un conservatore qualificato presente nell’elenco AgID, per completare e consolidare l’affidabilità della piattaforma. In fin dei conti, è il gestore che produce il registro e, correttamente, spetta a lui la conservazione.

Considerazioni ulteriori

Se, effettivamente, i gestori non hanno già rapporti attivi con conservatori digitali e le piattaforme non sono messe in comunicazione con un sistema di comunicazione a norma, la novità potrebbe essere molto impattante (ci sono 180 giorni per adeguarsi) e, anche, costituire un nuovo fronte di impegno per gli amici conservatori.

Poiché, come appare anche da altre osservazioni che seguono, l’intenzione è rendere la PAD un archivio pubblico autorevole, l’invio in conservazione del Registro di sistema sembra l’operazione minima da cui partire per raggiungere lo scopo.

La PAD così pensata, consente anche di osservare dal vivo una realizzazione concreta di documento informatico formato come “memorizzazione su supporto informatico in formato digitale delle informazioni risultanti da transazioni o processi informatici“^[3]Linee guida sul documento informatico, par. 2.1.1, lett. c).. Il registro di sistema della PAD, qualcosa volendo assimilabile a un log, pare esserne un fulgido esempio. Nel passaggio dalla teoria alla pratica, immagino però che ci sia da lavorare un bel po’, in particolare sulla forma e il formato del registro stesso. Le regole tecniche, infatti, danno prescrizioni generali sui contenuti identificativi dei record del registro (famiglia di requisiti [3.3.1.3]) e sugli eventi da tracciare (famiglia di requisiti [3.3.2.4-10], per esempio, ma un po’ ovunque), non scendono nel dettaglio del formato da utilizzare né sul livello di autocontenimento od esplicitezza del registro stesso. Prossimo step, forse, definire uno schema standard per i registri di sistema?

Destrutturazione dell’archivio

Un aspetto che emergeva già dalle precedenti regole tecniche è la volontà, forse non eccessivamente esplicita, di rendere le PAD un sistema documentale autonomo e autorevole, indipendente dagli archivi (sistemi documentali) degli enti che le usano.

In questa direzione andava la scelta di formare il fascicolo di gara nella PAD, addirittura prevedendo la funzione per recuperare e inserire nel fascicolo la documentazione che – caso residuale – non transita dalla PAD. Nella stessa direzione anche la costituzione di un sistema di recapito di comunicazione tutto contenuto nella PAD (con qualche cortocircuito, come sottolineato nel post Communication breakdown: il caso delle piattaforme di approvvigionamento digitale) o, tornando ai documenti, la previsione di associare ai documenti tutti i metadati previsti dall’allegato 5 alle linee guida sul documento informatico, “ad eccezione “con l’esclusione dei metadati che dipendono dal piano di classificazione e relativo piano delle aggregazioni documentale adottato dalla Stazione Appaltante” ([3.3.2.5-2]).

Per alcuni osservatori, la mancata menzione del “protocollo informatico” delle amministrazioni appaltanti, nonostante la reiterata menzione delle linee guida su formazione, gestione e conservazione del documento informatico, è una svista, per altri, semplicemente, le regole di gestione documentale restano valide e vanno integrate. Non è in realtà escluso che il fatto di menzionare più esplicitamente solo i sistemi di conservazione, sia un tentativo – sic stantibus rebus non pienamente conforme all’attuale oanorama normativo – proprio di rendere la PAD un sistema documentale con dignità propria, che prescinde dal sistema di gestione documentale di chi lo usa (anche se questi ha la titolarità dei procedimenti e, conseguentemente, dei documenti che vi si producono).

Le modifiche ai requisiti che riguardano gli aspetti documentali sembrano confermare questo orientamento dell’Agenzia per l’Italia Digitale, che continua a non essere particolarmente esplicito tanto da portarsi a chiedere se il drastico cambio di paradigma sia anche consapevole.

Formazione e acquisizione di documenti nativi digitali

Contemporaneamente alla spinta destrutturante dell’archivio come complesso^[4]O universitas rerum, se ci vogliamo dare un tono. Ma sì, diamocelo…, le regole tecniche rafforzano anche i requisiti che riguardano la formazione o l’acquisizione di documenti, ponendo nuovi e apprezzabili paletti, fra cui la preferenza assoluta per la redazione di documenti strutturati redatti a partire dai dati presenti in piattaforma e il rifiuto di acquisire documenti informatici provenienti da originale analogico^[5]O “scansioni”, se vogliamo essere più terra-terra. Ma sì, siamolo… (requisito, [3.3.2.1-1.1]).

I principali requisiti per i documenti sono i seguenti:

Requisito	Ver. 1.0	Ver. 2.0
[3.3.2.1-1]	La piattaforma deve garantire la redazione o acquisizione degli atti in formato nativo digitale in tutte le attività del ciclo di vita del contratto previste nel Quadro sinottico, nel rispetto del paragrafo 2.1.1 (formazione del documento informatico) delle Linee Guida sulla formazione, gestione e conservazione dei documenti informatici [LG_DOC_INF], dell’allegato 2 di tali linee guida in relazione ai formati e dell’allegato 5 relativamente ai metadati.	Redazione o acquisizione degli atti in formato nativo digitale (aggregatore di requisiti)
[3.3.2.1-1.1]		La piattaforma deve garantire la “redazione” o “acquisizione degli atti” in formato nativo digitale in tutte le attività del ciclo di vita del contratto nel rispetto del paragrafo 2.1.1 (Formazione del documento informatico) delle Linee Guida sulla formazione, gestione e conservazione dei documenti informatici [LG_DOC_INF], dell’allegato 2 di tali linee guida in relazione ai formati e dell’allegato 5 relativamente ai metadati. Nel caso di “redazione” di atti in formato nativo digitale la piattaforma deve generare documenti strutturati a partire dai dati acquisiti. Nel caso di “acquisizione di atti” in formato nativo digitale generati al di fuori della piattaforma, la stessa deve acquisire i metadati caratterizzanti l’atto in modalità automatica. Per tali atti si intende quelli generati attraverso altri sistemi gestionali ovvero, ove previsto, attraverso i metodi e gli strumenti di gestione informativa digitale delle costruzioni di cui all’art. 43 del Codice. La piattaforma non deve chiedere l’inserimento manuale di informazioni già disponibili. La piattaforma non deve supportare l’acquisizione di atti provenienti da originale analogico.
[3.3.2.1-1.2]		Per ogni atto redatto o acquisito con le modalità indicate nel requisito [3.3.2.1-1.1], la piattaforma deve effettuare una registrazione sul Registro di sistema conformemente a quanto previsto nel [3.3.2.5-8].

Il fascicolo di gara e i metadati di documenti e fascicolo

Anche la lettura comparata dei requisiti che riguardano il fascicolo di gara conferma l’intenzione di rendere la PAD l’archivio delle amministrazioni per quanto riguarda le procedure disciplinate dal Codice dei contratti.

Requisito	Ver. 1.0	Ver. 2.0
[3.3.1.4-1.2]	La piattaforma deve conservare nel fascicolo di gara ogni comunicazione.	invariato
[3.3.1.4-2]	La piattaforma deve consentire alle stazioni appaltanti di inserire nel fascicolo di gara eventuali comunicazioni tra OE e SA avvenute su canali di comunicazione diversi dalla piattaforma, tra cui la mail e la posta certificata, tracciando l’operazione nel Registro di sistema.	invariato
[3.3.1.4-3]	La piattaforma deve dichiarare esplicitamente a tutti gli utenti coinvolti dove avvengono le comunicazioni che hanno rilevanza in relazione alla procedura e richiedere i consensi necessari.	invariato
[3.3.1.4-4]	La piattaforma può prevedere ulteriori meccanismi di notifica indicando in modo chiaro quale sia il canale che produce gli effetti di comunicazione.	invariato
[3.3.2.5]
[3.3.2.5-1]	La piattaforma deve predisporre le informazioni necessarie per la conservazione a norma del fascicolo di gara secondo le Linee Guida sulla formazione, gestione e conservazione dei documenti informatici e i relativi allegati.	invariato
[3.3.2.5-2]	La piattaforma deve predisporre i metadati obbligatori per la documentazione di gara in conformità con l’allegato 5 «Metadati» delle citate Linee Guida, con l’esclusione dei metadati che dipendono dal piano di classificazione e relativo piano di organizzazione delle aggregazioni documentali adottato dalla Stazione Appaltante ai sensi dell’articolo 64 del D.P.R. 28 dicembre 2000, n. 445 Testo Unico sulla documentazione amministrativa.	La piattaforma deve predisporre i metadati obbligatori per ogni documento trattato e per il fascicolo di gara in conformità con l’allegato 5 «Metadati» delle Linee Guida sulla formazione, gestione e conservazione dei documenti informatici [LG_DOC_INF] e fornisce alla Stazione appaltante la documentazione necessaria per la redazione o l’aggiornamento del piano di classificazione e relativo piano di organizzazione delle aggregazioni documentali adottato dalla Stazione Appaltante ai sensi dell’articolo 64 del D.P.R. 28 dicembre 2000, n. 445 Testo Unico sulla documentazione amministrativa.
[3.3.2.5-3]	Per consentire alla Stazione Appaltante di identificare correttamente i documenti e le aggregazioni coerentemente col proprio piano di organizzazione delle aggregazioni documentali, la piattaforma deve acquisire i codici univoci d’identificazione relativi al fascicolo di gara, ottenuti tramite l’interazione coi servizi infrastrutturali di cui al requisito [3.4-5], in particolare [3.4-5.1], che costituiscono identificatori persistenti ai sensi delle Linee Guida di cui al requisito [3.2-2.1]:	Per consentire alla Stazione Appaltante di identificare correttamente i documenti e le aggregazioni coerentemente col proprio piano di organizzazione delle aggregazioni documentali, la piattaforma deve generare per ogni documento l’elemento IdDoc e acquisire i codici univoci d’identificazione relativi al fascicolo di gara, ottenuti tramite l’interazione coi servizi infrastrutturali di cui al requisito [3.3.3.1], in particolare [3.3.3.2-1], che costituiscono identificatori persistenti ai sensi delle Linee Guida di cui al requisito [3.3.2.5-1]:
[3.3.2.5-3.1]	idAppalto (o equivalente pro tempore previsto dalla PCP ANAC)	idAppalto
[3.3.2.5-3.2]	CIG	invariato
[3.3.2.5-4]	La piattaforma deve consentire la generazione, la visualizzazione e l’esportazione del Fascicolo in qualunque momento del ciclo di vita del contratto, con le limitazioni indicate in riferimento al paragrafo 3.3.2.2 “c) Accesso elettronico alla documentazione di gara”.	invariato (sostanzialmente)
[3.3.2.5-5]	La piattaforma deve consentire l’inserimento e l’estrazione nel fascicolo di documenti o insiemi di documenti che sono stati formati esternamente alla piattaforma.	invariato (vedere anche [3.3.2.1-1.1] e [3.3.2.1-1.2]).
[3.3.2.5-6]	La piattaforma può rendere disponibili interfacce API per le funzioni previste ai requisiti [3.3.2.5-4], ferme restando le limitazioni ivi indicate e il rispetto dei requisiti di accesso (par 3.3.1.1) e profilazione (par. 3.3.1.2).	invariato (sostanzialmente)
[3.3.2.5-7]	La piattaforma deve consentire la cancellazione del fascicolo di gara a seguito di richiesta del RUP. Tale funzione deve prevedere un meccanismo di controllo forte. Esempio: la conferma sia da parte del RUP che dell’ADS o ruolo del Gestore espressamente delegato per questa funzione.	invariato, a parte l’eliminazione di “o ruolo del Gestore espressamente delegato per questa funzione”.
[3.3.2.5-8]	Gli eventi di cui ai punti [3.3.2.5-4], [3.3.2.5-5], [3.3.2.5-6] e [3.3.2.5-7] devono essere tracciati nel Registro di sistema.	Gli eventi di cui ai punti [3.3.2.5-3], [3.3.2.5-4], [3.3.2.5-5], [3.3.2.5-6] e [3.3.2.5-7] devono essere tracciati nel Registro di sistema che deve includere gli elementi di identificazione per il documento o il fascicolo, disponibili in base all’evento cui si riferisce, in particolare: l’impronta del documento (come presente nell’elemento IdDoc) e il CIG.

Le modifiche rispetto alla versione 1.0 sono numericamente poche, ma decisamente impattanti.

La precedente versione imponeva ([3.3.2.5-2]) di dotare la documentazione di tutti i metadati previsti dalle Linee guida (allegato 5) ad eccezione di quelli legati alla classificazione e alle aggregazioni, perché, evidentemente legati a scelte archivistiche delle singole amministrazioni che non si possono riversare nella PAD multi-ente. Tuttavia, per consentire alle amministrazioni di classificare e aggregare la documentazione, la PAD associa al fascicolo di gara un identificativo univoco (idAppalto o CIG). In questo modo, a quanto si riesce a immaginare, l’amministrazione dovrebbe essere in grado di inserire nel proprio repertorio, all’opportuno indice di classificazione, il fascicolo di gara e indicare che il fascicolo vero e proprio è archiviato e consultabile nella PAD.

La nuova versione ribalta decisamente la questione. Con il nuovo requisito [3.3.2.5-2] la PAD associa alla documentazione tutti i metadati (classificazione e aggregazione inclusa) e lo fa, evidentemente, sulla base di un piano di classificazione e un piano delle aggregazioni proprio che poi, addirittura, “impone” alle amministrazioni che devono recepirlo nei propri strumenti archivistici.

Quest’ultima è una questione per niente di poco conto. Di fatto, viene meno l’autonomia degli enti nell’organizzare la propria documentazione? E’ la PAD che organizza sulla base delle scelte del suo gestore e l’amministrazione si adegua.

La checklist del fascicolo

Per completare l’opera di trasferimento dell’archivio nella PAD, l’allegato 2 delle regole tecniche si chiude con l’elencazione puntuale dei documenti da inserire nel fascicolo di gara.

All’elenco manca l’estratto del registro di sistema, previsto invece dal requisito [3.3.1.3-5] come da inserire nel fascicolo di gara. Ciononostante, sono presenti una cinquantina di documenti, relativi a e suddivisi per fasi di programmazione, indizione (che include l’aggiudicazione/affidamento) ed esecuzione che, a loro volta, potrebbero individuare dei tradizionali sottofascicoli del fascicolo.

Molti dei documenti sono chiaramente formati fuori dalla PAD e, come specificato nei requisiti sull’acquisizione dei documenti e comunicazioni ([3.3.2.5-5] e [3.3.1.4-2] rispettivamente), questi devono essere acquisiti nella documentazione accolta nella PAD e nel fascicolo di gara.

Attenzione, però: per il requisito [3.3.2.1-1.1], “nel caso di acquisizione di atti in formato nativo digitale generati al di fuori della piattaforma, la stessa deve acquisire i metadati caratterizzanti l’atto in modalità automatica.”. Il passaggio fa riferimento a documenti prodotti sia da generici gestionali dell’amministrazione sia dai sistemi BIM.

Non un lavoro da poco per le PAD. Con queste indicazioni non si può certo risolvere la questione con un “scarica il file dal protocollo o dal gestionale degli atti o dal BIM e fai upload nella PAD”. Incredibilmente, quei collegamenti interoperabili per trasferire automaticamente documenti e metadati che non si sono previsti in origine per spostare i documenti dalla PAD al SGID sono adesso da implementare per garantire il trasferimento nel verso opposto.

Verifica del trattamento di un documento

Le regole tecniche prevedono un nuovo requisito, nella famiglia dei requisiti relativi a “Redazione o acquisizione di atti in formato nativo digitale”.

Requisito

Ver. 2.0

[3.3.2.1-1.3]

Per ogni atto redatto o acquisito con le modalità indicate nel requisito [3.3.2.1 – 1.1], la piattaforma deve rendere disponibile un servizio pubblico, privo di autenticazione, che consenta di attestare se un documento è stato oggetto di trattamento da parte della PAD. Il servizio si deve basare unicamente sull’impronta del documento sottoposto a verifica. Ogni richiesta è tracciata nel Registro di sistema dove sono riportati il richiedente e l’impronta del documento richiesto.

Il servizio definito dal requisito sembra essere finalizzato alla verifica dell’autenticità di un documento, per esempio nei casi in cui un documento di gara è oggetto di accesso agli atti o, per qualche altro motivo, fuoriesce (sotto forma di file) dalla PAD.

Il servizio, così come raccontato, sembra riguardare solo la componente “file” del documento informatico, mentre molti dei requisiti delle regole tecniche insistono sulla necessità di associare ai documenti i metadati, come se questi completassero significato e valore dei documenti stessi. Come verificare allora l’autenticità o l’integrità dei metadati? Oppure non ce n’è bisogno? Forse no, in effetti: dall’impronta del documento trattato nella PAD, infatti, si risale al documento e, dal documento, agli eventi che lo riguardano presenti nel registro di sistema che dovrebbero consentire di ricavare ex novo i metadati (chi ha prodotto il documento, quando, come è arrivato alla piattaforma ecc.).

Di fatto, comunque, il requisito [3.3.2.1-1.3] conferisce all’ambiente PAD le caratteristiche proprie dell’archivio pubblico, cioè la capacità – riferita al gestore della piattaforma – di validare l’autenticità di un documento, poiché suo custode. Una scelta ai limiti del destabilizzante, se si pensa alla leggerezza con cui, solitamente, altri sistemi informatici analoghi alle PAD in uso in altri ambiti amministrativi, trattano i documenti.

Destrutturazione: un bene o un male?

Le scelte, più o meno consapevoli di chi ha redatto la versione 2.0 delle regole tecniche sulle PAD, spostano di un bel po’ gli equilibri e i punti fermi dell’archivistica e vanno a disegnare un sistema documentale nazionale in cui sembra venire meno il legame fra soggetto produttore e archivio. La PAD, infatti, si presenta quasi come l’archivio “condominiale” di un gruppo di soggetti produttori che condivida la stessa piattaforma di approvvigionamento, un archivio specializzato nella documentazione di una specifica materia, la contrattualistica pubblica (intesa come acquisizione di lavori, servizi o beni).

La questione, in sé, non è né un bene né un male, perché dipende sempre tutto dal disegno complessivo. Certo, la prima impressione è molto simile a quella di chi si trova di fronte a una tazzina di caffè, due lingue di gatto, una cucchiaiata di mascarpone e una fetta di uovo sodo e si sente dire che ha di fronte un “tiramisù destrutturato”. Eppure, chef stellati e pasticceri d’avanguardia hanno fatto la loro fortuna su simili reinterpretazioni dei classici. Non potrebbe essere lo stesso per l’archivio?

Sarebbe interessante conoscere il punto di vista di Francesco Bonaini e Pellegrino Artusi (chissà se si sono mai incontrati nella Firenze di metà Ottocento) sulle sorti riservate a fondi archivistici e dolci della tradizione, ma è ovviamente impossibile. Non resta che accontentarsi, per ora, di quello meno suggestivo dell’archivistadigitale…

Di fronte al nuovo indirizzo archivistico che emerge dall’impostazione delle regole tecniche, la reazione è duplice. Da una parte, si riesce ad accettare, a livello concettuale, che si segreghi l’archivio della contrattualistica pubblica anche perché, parallelamente, si rafforza la qualità dei documenti prodotti o acquisiti da una PAD. Dall’altra parte, resta molto difficile conciliare quest’impostazione con il regime complessivo attuale della gestione documentale, come dipinto da dpr 445/2000, codice dell’amministrazione digitale, linee guida e pure da varia letteratura tecnica, che mette il sistema di gestione informatica dei documenti (e, quindi, l’archivio dell’ente) al centro.

Che ci sia, contestualmente, da cambiare qualcosa nella cornice di regole? Si è detto e ripetuto che i procedimenti di procurement (con o senza e- davanti) sono di competenza della pubblica amministrazione che opera come stazione appaltante e che quindi ricade sotto la sua responsabilità anche la tenuta dei documenti. Se si decide che questi stanno nella PAD, anche quelli non prodotti o acquisiti direttamente dalla PAD, va bene, ma qualche domanda bisogna farsela:

• per i principi dettati dallo stesso codice dei contratti pubblici che introduce le PAD, il rapporto contrattuale di servizio fra amministrazione e gestore della piattaforma non è eterno. Anzi, potenzialmente, con orizzonte di pochi anni, l’amministrazione interrompe il rapporto con un gestore per poi riprenderlo con un altro: di conseguenza, l’archivio delle procedure di affidamento si forma, da un periodo all’altro, in luoghi diversi. Poco male, ma come ricostruiamo in quale PAD andare a ricercare la documentazione?
• Anche le PAD come manufatto, poi, non sono eterne. Un gestore potrebbe darsi ad altro e dismettere la sua piattaforma. Quale la sorte dei documenti? Sono in un sistema di conservazione? Quale? Perché, per come è organizzato adesso, sembra che in conservazione i documenti di gara li mandi la singola amministrazione, limitatamente ai propri, e non il gestore della PAD, comprendendoli tutti. E, di nuovo, nel caso, in qualche sistema di conservazione si cerca?
• In generale, se qualcuno vuole fare un accesso agli atti (o una ricerca storica), non è tentato di rivolgersi all’amministrazione che ha bandito la procedura di affidamento?

Così, impulsivamente, verrebbe da proporre un ulteriore cambio radicale: imporre ai gestori della piattaforma di conservare non solo il registro di sistema ma tutti i documenti trattati dalla PAD (inclusi quelli formati e comunicati esternamente). In più, sarebbe da imporre non solo l’obbligo di conservare, ma anche di farlo tutti presso lo stesso conservatore: per esempio, l’Archivio centrale dello Stato, oppure in un sistema di conservazione sotto il controllo dell’ANAC. Si avrebbe così l’archivio statale delle procedure di affidamento di tutta l’amministrazione italiana. Suona un po’ come un ritorno allo stato centralizzante con gusto archivistico peroniano, ma sarebbe probabilmente un disegno in cui le PAD così documentalmente allestite troverebbero una collocazione sensata.

Ghost track di conclusione: “mandatorio” non è una parola italiana

“Mandatorio” non è una parola italiana. Senz’altro lo diventerà, ma per adesso non lo è e non lo dico solo io. Facendo riferimento a risorse online:

• vocabolario Treccani: https://www.treccani.it/enciclopedia/ricerca/mandatorio/?search=mandatorio – incredibilmente rimanda al lemma “tubercolosi” nell’enciclopedia;
• vocabolario Garzanti: https://www.garzantilinguistica.it/it/nessun-risultato/mandatorio.

Mandatory esiste, invece, in inglese: https://www.wordreference.com/definition/mandatory. Stando al dizionario monolingua inglese WordReference, deriva dal latino tardo che, evidentemente, in alcuni casi influenza più le lingue anglosassoni che le neolatine.

La versione inglese-italiano di WordReference propone di tradurre mandatory con “obbligatorio“, “imperativo“. O al limite come “mandatario” (colui che ha ricevuto un mandato), passando all’area semantica giuridica del rapporto di mandato, con mandante e mandatario. Evidentemente in italiano il latino tardo è stato usato in quest’area semantica qui, mentre per il linguaggio comune si è ritenuto sufficiente usare parole come “obbligatorio”, “imperativo”, “tassativo”, “necessario”, “immancabile” ecc.

Inoltre, stona l’accostamento di “mandatorio” e “ove presente“. Nella tabella “checklist del fascicolo di gara” (paragrafo 2.5 dell’allegato 2), “ove” che è una roba ottocentesca^[6]”Lo stesso che dove, di cui è forma più letteraria”, per il vocabolario Treccani si alterna al citato anglismo “mandatorio” (sotto il cappello della “checklist”, per di più). Capisco che uno ha i riferimenti culturali che si merita, ma di nuovo torna in mente una battuta di “Smetto quando voglio” e il fascino di “quando il ceppo anglosassone va a contaminare la lingua vernacolare”…

Foto di Moira Nazzari da Pixabay