La perizia tecnica nei contenziosi ICT: perché la prova deve reggere il contraddittorio

Il contenzioso che ruota attorno ai progetti software e alle trasformazioni digitali è in crescita costante. Sistemi ERP che non entrano mai davvero in produzione, integrazioni che falliscono, contratti di sviluppo che si interrompono a metà, livelli di servizio contestati. Ogni volta che una di queste vicende arriva davanti a un giudice, il procedimento si regge su un elemento che raramente riceve l'attenzione che merita: la perizia tecnica.

Le parti hanno diritto a una consulenza tecnica. Non hanno automaticamente diritto a una consulenza tecnica che regga il contraddittorio. La differenza tra le due cose decide spesso l'esito della causa, e la distanza tra il livello richiesto e il livello medio osservabile nei procedimenti italiani è il problema che questo testo affronta.

La tesi è semplice. La perizia in materia ICT soffre di una carenza di metodo, non di competenza. Esistono in Italia molti tecnici capaci. Esistono molti meno periti che applicano alla materia informatica il rigore metodologico che in altre discipline tecniche è considerato il minimo sindacale. Colmare questa distanza non richiede nuove leggi. Richiede l'adozione di principi metodologici che in campi come la metrologia sono codificati da decenni.

Perché la perizia ICT è spesso inadeguata

Le ragioni dell'inadeguatezza non sono individuali. Non si tratta di periti incapaci, ma di tre carenze strutturali che il sistema non ha ancora affrontato.

La prima è la confusione tra competenza tecnica e competenza peritale. Essere uno sviluppatore esperto, un buon system integrator o un project manager navigato non qualifica di per sé come perito. La perizia richiede un metodo aggiuntivo rispetto alla competenza di dominio: la capacità di ricostruire i fatti in modo tracciabile, di distinguere ciò che è accertato da ciò che è inferito, di dichiarare l'incertezza residua, di tradurre il dato tecnico in un linguaggio che il giudice possa valutare. La maggior parte dei consulenti tecnici nominati in materia ICT proviene dal mondo operativo senza aver mai affrontato in modo strutturato la metodologia peritale. Sa fare il software. Non sempre sa fare la perizia sul software.

La seconda è l'assenza di standard condivisi. In metrologia esistono norme precise che stabiliscono come si esegue una misura, come si documenta la catena di riferibilità, come si dichiara l'incertezza estesa. Un perito che valuta una grandezza fisica ha riferimenti certi a cui ancorare il proprio lavoro, e un altro perito che esamina lo stesso caso parte dagli stessi riferimenti. Nell'informatica forense questo esiste in parte per l'acquisizione della prova digitale, ma non esiste un equivalente per la valutazione di un progetto software fallito. Ogni perito ricostruisce il proprio metodo da zero, con il risultato che due perizie su casi tecnicamente simili possono seguire approcci incoerenti e arrivare a conclusioni non comparabili.

La terza è il linguaggio. Una perizia che descrive le cause del fallimento di un sistema gestionale ricorrendo a termini tecnici non spiegati non serve a chi deve decidere. Il problema non è la competenza del giudice, che non ha l'obbligo di essere un ingegnere. Il problema è che il perito non ha completato il proprio lavoro, che include la traduzione del contenuto tecnico in un ragionamento comprensibile e verificabile da un non specialista. Una perizia che il giudice non può seguire senza diventare informatico è una perizia mal fatta, per quanto tecnicamente accurata sia nel merito.

Queste tre carenze hanno un effetto comune. Producono perizie che si prestano alla contestazione. La parte soccombente trova facilmente argomenti per attaccare una consulenza che non ha dichiarato il proprio metodo, che non ha tracciato le proprie fonti, che non ha distinto i fatti dalle ipotesi. E un procedimento in cui la perizia viene smontata in sede di osservazioni dei consulenti di parte è un procedimento che si allunga, che genera supplementi di consulenza, che costa tempo e denaro a tutti.

Cosa dovrebbe contenere una perizia ICT seria

La proposta metodologica si articola in cinque elementi che ogni consulenza tecnica in materia ICT dovrebbe dichiarare esplicitamente. Non sono adempimenti formali. Sono le condizioni perché una perizia sia difendibile nel contraddittorio.

Il primo elemento è la definizione precisa del perimetro dell'incarico e delle domande a cui la perizia risponde. Il quesito posto dal giudice definisce il campo, ma il perito ha il dovere di interpretarlo con rigore e di dichiarare come lo ha inteso. Molte consulenze rispondono a domande che nessuno ha formulato e trascurano aspetti che il quesito implicava. La perizia deve aprire stabilendo con chiarezza cosa è stato chiesto, come la domanda è stata interpretata, e quali aspetti restano fuori dal perimetro. Questo protegge il perito e orienta il giudice.

Il secondo elemento è la metodologia di ricostruzione documentale. In un contenzioso su un progetto software, i fatti vivono nei documenti: contratto, capitolato tecnico, verbali di stato avanzamento lavori, corrispondenza tra le parti, log di sistema, registri delle anomalie, codice sorgente nelle sue versioni successive. Il perito deve dichiarare come ha acquisito questi materiali, da chi, in quale formato, con quale garanzia di integrità. Un log prodotto unilateralmente da una delle parti, senza una procedura di acquisizione che ne garantisca l'autenticità e l'immodificabilità, non ha lo stesso valore di un dato acquisito con catena di custodia documentata. La differenza va dichiarata, non lasciata implicita.

Il terzo elemento è la gerarchia delle fonti. Quando le fonti sono in contraddizione, e nei contenziosi ICT lo sono quasi sempre, il perito deve dichiarare quale peso ha attribuito a ciascuna e perché. Il contratto e il capitolato tecnico hanno valore diverso da una email informale. Un verbale firmato da entrambe le parti ha valore diverso da una dichiarazione resa in sede di contenzioso. Il codice effettivamente in produzione ha valore diverso dalle intenzioni dichiarate nella documentazione di progetto. La perizia deve esplicitare questa gerarchia, perché è su di essa che si fonda ogni conclusione successiva.

Il quarto elemento è la distinzione tra fatto accertato, inferenza ragionevole e ipotesi. Sono tre livelli di certezza diversi, e la perizia deve tenerli separati in modo visibile nel testo. Affermare che un sistema presentava un determinato difetto perché è documentato in un registro anomalie firmato è un fatto accertato. Affermare che quel difetto ha causato il ritardo complessivo del progetto è un'inferenza, ragionevole o meno a seconda degli elementi a supporto. Affermare che senza quel difetto il progetto sarebbe stato consegnato nei tempi è un'ipotesi controfattuale, che va dichiarata come tale. Una perizia che presenta inferenze e ipotesi con lo stesso grado di certezza dei fatti accertati è una perizia che inganna il lettore, anche involontariamente, ed è facilmente attaccabile.

Il quinto elemento è la dichiarazione dell'incertezza residua. Ogni consulenza seria deve indicare cosa non è stato possibile accertare e perché. I dati mancanti, i documenti non reperibili, le ricostruzioni che restano parziali. In metrologia una misura senza la sua incertezza è considerata una mezza verità, perché il valore da solo non dice quanto ci si possa fidare di esso. Lo stesso principio si applica alla perizia. Una consulenza che non dichiara alcuna incertezza non è una consulenza più solida delle altre. È una consulenza che non ha applicato il rigore necessario, o che lo nasconde.

Questi cinque elementi, presi insieme, definiscono una perizia che il giudice può seguire, che i consulenti di parte possono verificare nel metodo anche quando ne contestano le conclusioni, e che regge il contraddittorio perché non lascia zone d'ombra su come si è arrivati alle conclusioni.

Il nodo a monte: il criterio di accettazione

C'è però un limite a ciò che il metodo peritale può risolvere. In una parte consistente dei contenziosi su software enterprise, la perizia si trova a rispondere a una domanda che il contratto non ha mai reso rispondibile.

Il capitolato tecnico elenca cosa il sistema deve fare. Quasi mai definisce come si stabilisce che il sistema è stato consegnato conforme. Manca, in altri termini, il criterio di accettazione.

In assenza di quel criterio scritto, il collaudo diventa opinabile e la controversia strutturalmente irrisolvibile sul piano documentale. Il committente sostiene che il sistema non funziona come atteso. Il fornitore sostiene di aver consegnato quanto pattuito. Entrambi hanno ragione, perché il metro non è mai stato concordato. Il perito si trova a dover ricostruire un criterio che non esiste, e ogni ricostruzione è per definizione contestabile.

Un criterio di accettazione utilizzabile in giudizio contiene quattro elementi. Le funzioni oggetto di verifica, elencate e non richiamate per rinvio a documenti che nessuno ha allegato. Le condizioni operative in cui la verifica avviene, cioè volumi di dati, utenze concorrenti, dati reali o di test. La soglia che separa l'anomalia bloccante da quella minore, definita prima e non negoziata dopo, perché è quella classificazione a stabilire chi è inadempiente. E infine chi firma, entro quale termine, e cosa accade se il termine scade senza firma.

Quando il criterio manca, il perito ha comunque un dovere: ricostruire quello desumibile dalla documentazione, dalla corrispondenza e dalla prassi seguita dalle parti, dichiarando con precisione che si tratta di una ricostruzione e non di un dato contrattuale. È un lavoro legittimo e spesso decisivo, ma va etichettato per quello che è, altrimenti si trasforma nella creazione postuma di un obbligo che nessuno aveva assunto.

A valle del criterio c'è il documento che lo applica, ed è il verbale di collaudo. Per avere valore probatorio dovrebbe richiamare i criteri di accettazione pattuiti anziché genericamente il capitolato, elencare puntualmente le anomalie rilevate con la loro classificazione, e riportare riserve specifiche che indichino quale difetto contestano e in quale funzione.

La prassi diffusa è invece il collaudo firmato con riserva generica. Una riserva che non dice cosa contesta non protegge chi la appone e non avverte la controparte: in sede di contraddittorio pesa poco più di una firma liscia.

Va poi considerata l'accettazione tacita, che è il vero rischio del committente. Quando il sistema viene messo in produzione e utilizzato, quel comportamento concreto pesa più della riserva scritta. La perizia deve ricostruire cosa è stato effettivamente utilizzato, da quando, e con quale intensità, perché è su quel comportamento che il giudice misurerà la coerenza fra ciò che la parte ha dichiarato e ciò che ha fatto.

Il caso tipico: un progetto ERP in contenzioso

La dinamica si ripete con regolarità sufficiente da poterla descrivere in termini generali, senza riferimento ad alcun caso specifico.

Un'azienda commissiona a un fornitore l'implementazione di un sistema gestionale integrato. Il contratto rimanda a un capitolato tecnico che elenca le funzionalità attese. Il progetto parte, accumula ritardi, attraversa una serie di rinvii della data di entrata in produzione. A un certo punto il cliente sospende i pagamenti. Il fornitore contesta la sospensione e a sua volta rallenta o interrompe le attività. Il rapporto si rompe. Entrambe le parti si ritengono creditrici e danneggiate. Si arriva in giudizio.

Il giudice nomina un consulente tecnico d'ufficio e gli pone tre domande, nella sostanza ricorrenti. Il sistema è stato consegnato in conformità a quanto pattuito nel capitolato. A chi sono imputabili i ritardi accumulati. Quale sia l'entità del danno economico, se sussistente.

Su ciascuna di queste domande la differenza tra una perizia rigorosa e una perizia debole è netta.

Sulla conformità, la perizia debole confronta genericamente il sistema realizzato con il capitolato e dichiara una percentuale di completamento, come se la conformità fosse una grandezza continua. La perizia rigorosa stabilisce prima di tutto cosa il capitolato definisce come consegna conforme, e qui emerge quasi sempre il nodo descritto nella sezione precedente. In assenza di un criterio scritto, la perizia rigorosa lo dichiara, ricostruisce quale criterio fosse implicito o desumibile dalla prassi, e valuta la conformità rispetto a quel criterio dichiarando l'incertezza che deriva dalla sua natura ricostruita.

Sull'imputazione dei ritardi, la perizia debole attribuisce la responsabilità alla parte che appare più in difetto dalla lettura complessiva del fascicolo. La perizia rigorosa ricostruisce la cronologia documentata degli eventi e distingue i ritardi imputabili al fornitore da quelli imputabili al committente, che nei progetti ICT sono più frequenti di quanto la narrazione delle parti lasci intendere: dati non forniti, specifiche non validate nei tempi, personale non reso disponibile per le sessioni di test, decisioni rinviate.

Questa ricostruzione richiede di incrociare fonti diverse e di dichiarare dove la documentazione consente una conclusione certa e dove consente solo un'inferenza. In particolare, richiede di cercare quattro documenti che raramente si trovano completi: i verbali del comitato di progetto che riportano le decisioni prese e non solo l'elenco dei presenti, il registro delle change request con esito e firma di chi ha approvato, i log di rilascio in produzione con l'autorizzazione tracciata, e la corrispondenza sulle escalation, che è cosa diversa dalla corrispondenza operativa quotidiana.

Qui emerge il punto centrale del caso. La domanda su chi ha sbagliato cosa è quasi sempre una domanda di governance travestita da domanda tecnica. Chi decideva le priorità di sviluppo, chi approvava le varianti di scope, chi aveva l'ultima parola sul rilascio in produzione: nei progetti che falliscono questa catena decisionale esiste nei fatti ma quasi mai a verbale. Il perito che ricostruisce solo gli aspetti tecnici fa metà del lavoro. L'altra metà è stabilire chi doveva decidere cosa, e quando quella decisione è mancata o è arrivata fuori tempo. Responsabilità tecnica e responsabilità di governance vanno tenute distinte nella relazione, perché confonderle è il modo più rapido per rendere le conclusioni contestabili.

Un caso particolare, e frequentissimo, riguarda le varianti non formalizzate. Lo scope si allarga in riunione, il fornitore esegue per mantenere il rapporto, il committente considera la modifica compresa nel corrispettivo, e nessuno mette nulla a verbale perché in quel momento la relazione funziona e formalizzare sembra un atto ostile. Poi il rapporto si rompe, e quella modifica diventa il centro della causa. Il perito ricostruisce lo scope reale incrociando la corrispondenza, dove la richiesta compare quasi sempre anche se in forma informale, i rilasci effettivi negli ambienti di test e produzione, che mostrano cosa è stato davvero sviluppato e quando, e le stime intermedie, che rivelano se il fornitore avesse valutato la modifica come attività extra senza dichiararlo formalmente.

La quantificazione del danno

La terza domanda è quella su cui le perizie si dividono di più, ed è anche quella che decide l'esito economico della causa.

Stabilire che un progetto è fallito è la parte relativamente semplice. Quantificare il danno richiede di distinguere voci che hanno regimi probatori diversi e che non possono essere sommate come se avessero lo stesso grado di certezza.

I costi sostenuti sono documentabili, ma non tutto ciò che è stato speso costituisce danno. La parte di lavoro effettivamente utilizzabile, o riutilizzabile con il fornitore successivo, va scorporata, e quasi mai lo è nelle richieste di parte.

Il costo di ripristino e di migrazione verso un fornitore terzo è la voce più frequentemente trascurata e spesso la più consistente, perché include la riscrittura di ciò che non è portabile, il recupero dei dati dal sistema abbandonato e il tempo necessario perché il nuovo fornitore raggiunga il punto in cui il precedente si era fermato.

Il danno da mancata disponibilità del sistema richiede di dimostrare cosa l'organizzazione avrebbe fatto con il sistema funzionante, e si colloca a un livello di certezza inferiore rispetto alle due voci precedenti.

Il lucro cessante è ipotetico per definizione. Va argomentato con serietà, ma va tenuto separato dalle altre voci e presentato per quello che è, non sommato in una cifra unica che ne appiattisce la natura.

Il principio metodologico è lo stesso che regge tutto il resto: ogni voce deve dichiarare il proprio metodo di stima. Una perizia che presenta un importo complessivo senza esplicitare come è stato costruito consegna alla controparte il modo più semplice di contestare l'intero, attaccando la voce più debole e trascinando con sé le altre.

Resta una questione su cui la prassi non è consolidata, e che vale la pena segnalare come tale: se il costo del personale interno del committente distolto dal progetto fallito costituisca danno risarcibile o costo fisso che l'azienda avrebbe sostenuto comunque. La risposta cambia a seconda della ricostruzione, e il perito onesto dichiara quale ha adottato e perché.

La frontiera: sistemi automatizzati e intelligenza artificiale

Una nuova categoria di contenzioso si profila all'orizzonte, e merita una riflessione anche se la giurisprudenza è ancora agli inizi. Quando il sistema che ha prodotto un risultato contestato non è un software deterministico ma un sistema decisionale automatizzato, o un modello di intelligenza artificiale, la perizia incontra problemi nuovi.

Il primo problema è la ricostruibilità. Un software tradizionale, a parità di input, produce lo stesso output, e il suo comportamento è in linea di principio ispezionabile nel codice. Un sistema basato su modelli addestrati non offre la stessa trasparenza. Ricostruire perché il sistema ha prodotto una determinata decisione richiede accesso non solo al modello ma ai dati di addestramento e alla configurazione vigente al momento dei fatti, elementi che spesso non sono conservati con criteri compatibili con un uso probatorio. In alcuni casi una ricostruzione completa non è possibile, e il perito deve saperlo dichiarare invece di produrre una certezza apparente.

Il secondo problema è la catena di responsabilità. Quando un sistema automatizzato produce una decisione dannosa, la responsabilità tecnica si distribuisce tra chi ha sviluppato il modello, chi lo ha addestrato, chi ha fornito i dati di addestramento, chi lo ha integrato e chi lo ha utilizzato senza comprenderne i limiti. Ricostruire questa catena è un esercizio peritale nuovo, che richiede di estendere i principi metodologici tradizionali a un contesto in cui l'opacità del sistema è una caratteristica intrinseca e non un difetto di documentazione.

Il terzo problema è la spiegabilità in sede giudiziale. Il concetto tecnico di spiegabilità di un modello non coincide con ciò che serve a un giudice per decidere. Tradurre l'uno nell'altro è una sfida metodologica che la perizia dei prossimi anni dovrà affrontare, e che oggi non ha ancora soluzioni consolidate né procedure standardizzate.

Resta poi una questione di equilibrio probatorio che il quadro normativo in costruzione dovrà affrontare: se in questi casi l'onere di rendere il sistema ispezionabile debba ricadere su chi lo ha fornito. È una scelta che sposterebbe in modo significativo il baricentro del contenzioso, e non è ancora stata compiuta.

Non si tratta di avere risposte definitive. Si tratta di riconoscere che questi problemi esistono già, e che il perito competente è chi li affronta con metodo dichiarato anziché ignorarli.

Tre principi minimi

La proposta non è una norma né uno standard formale. È l'adozione volontaria di tre principi minimi, mutuati dalle discipline tecniche dove il rigore peritale è maturo, applicati alla materia ICT.

Tracciabilità della ricostruzione documentale. Ogni conclusione deve poter essere ricondotta alle fonti da cui deriva, con dichiarazione di come quelle fonti sono state acquisite e di quale peso è stato loro attribuito.

Dichiarazione esplicita dei livelli di certezza. Fatto accertato, inferenza e ipotesi vanno tenuti distinti e visibili, e l'incertezza residua va dichiarata invece di essere nascosta.

Linguaggio traducibile. Il contenuto tecnico va reso comprensibile e verificabile da chi deve decidere, senza perdere rigore e senza richiedere al giudice di diventare uno specialista.

Chi applica questi principi produce una perizia difendibile. Chi non li applica produce una perizia contestabile, e il sistema giudiziario merita il primo tipo di lavoro, non il secondo.

Per chi assiste una parte, questi tre principi offrono anche uno strumento pratico di valutazione. Una relazione peritale che non dichiara il perimetro, non traccia le fonti, non distingue i livelli di certezza e non ammette alcuna incertezza residua non va contestata nelle conclusioni: va contestata nel metodo. Sono osservazioni di natura diversa. Le prime chiedono al giudice di scegliere fra due opinioni tecniche. Le seconde gli mostrano che una delle due non ha fondamento verificabile, ed è su quel terreno che il contraddittorio tecnico produce effetti reali.

Il contraddittorio tecnico è un diritto delle parti. La qualità della perizia è la condizione perché quel diritto sia reale.