AI digital forensics – Quando l’AI mente bene: anti-forensics, auditabilità e prova digitale

Intervento di Cosimo de Pinto, informatico forense, socio e membro del board IISFA, socio ONIF, certificato CIFI, perito e consulente tecnico presso il Tribunale Ordinario di Roma.

14ª Cyber Crime Conference, Roma, 6-7 maggio 2026.

Aprire una relazione tecnica con una risposta plausibile generata da un sistema di intelligenza artificiale è oggi alla portata di qualsiasi consulente. Difenderla in aula, sotto un controesame condotto sulla riproducibilità del risultato, è tutta un’altra storia. È da questa frattura, prima documentale che filosofica, che Cosimo de Pinto ha costruito il proprio intervento “Quando l’AI mente bene: anti-forensics, auditabilità e prova digitale” alla 14ª edizione della Cyber Crime Conference, con una precisazione iniziale di metodo:

«Questo non è un talk su quanto l’AI sia intelligente; è un talk su quanto noi rischiamo di sembrare poco intelligenti se la usiamo male in tribunale».

Il perimetro è quello della digital forensics applicata a un paradigma probabilistico, dove la velocità di elaborazione dei modelli incontra le esigenze rigorose della prova: tracciabilità integrale, ripetibilità, controperizia.

AI digital forensics: una incompatibilità strutturale

La tensione fra digital forensics e intelligenza artificiale generativa non nasce da una questione concettuale, ma da una incompatibilità strutturale fra due paradigmi di lavoro. La forensics vive di catena di custodia e ripetibilità: ogni passaggio deve essere documentato, verificabile, riproducibile in sede di controperizia. La GenAI, all’opposto, vive di probabilità e contesto: i risultati dipendono da parametri stocastici e dal contesto fornito al momento dell’inferenza.

L’unico ponte stabile fra i due mondi, secondo de Pinto, è il logging strutturato. È lo strumento che rende compatibile un sistema probabilistico con le esigenze di una prova che, per essere tale, richiede riproducibilità e tracciabilità.

La domanda secca con cui il relatore ha aperto il confronto con la platea coglie esattamente il punto:

«Se l’AI mi dà una risposta plausibile, posso usarla in una relazione tecnica?».

La risposta è il filo conduttore dell’intero intervento: una risposta plausibile non è ancora una risposta difendibile.

Il paradosso forense: ciò che l’AI promette, ciò che il tribunale richiede

Il paradosso si articola su tre piani. L’AI promette velocità di elaborazione su volumi massicci di dati, correlazione automatica fra artefatti digitali eterogenei, individuazione di pattern invisibili all’analista umano, riduzione del tempo di risposta nelle indagini urgenti. Il tribunale, di contro, richiede ricostruibilità integrale del percorso analitico, verificabilità indipendente da parte della difesa, conformità a standard probatori consolidati, una catena di custodia documentata.

Il problema centrale, ha sottolineato de Pinto, è che un output brillante prodotto da una black box non è una prova: è un indizio operativo. Un responso non auditabile, per quanto statisticamente accurato, non regge all’esame del contraddittorio in sede giudiziaria.

Indizio o prova digitale? La triangolazione come spartiacque

La differenza fra indizio e prova si gioca tutta sulla possibilità di triangolazione. Tre esempi rendono concreto il concetto:

• un tool AI segnala una corrispondenza fra due pattern di log;
• un Large Language Model riassume 40.000 chat e indica tre conversazioni sospette;
• una classificazione AI coincide con hash, log indipendenti e verifica tradizionale.

I primi due sono indizi operativi. Il terzo comincia ad avvicinarsi al terreno della prova, proprio perché entra in gioco la triangolazione con fonti indipendenti.

L’indizio orienta l’indagine, suggerisce direzioni, apre piste investigative, supporta l’analista nel triage: in questo ruolo l’AI è eccellente, capace di identificare pattern, correlare eventi, suggerire pivot investigativi con una velocità e una scala impossibili per l’analista umano. La prova, invece, deve reggere la contestazione, la ripetizione, la controperizia, ed essere verificabile da terzi con metodi indipendenti. «AI says so» non supera il controesame.

Il relatore ha invitato a immaginare la scena in aula: «Arrivo e dico: il sistema AI ha rilevato questa correlazione. Il difensore non mi chiederà quale software ha contribuito; mi chiederà una cosa sola: mi dimostri come ci è arrivato. E se non ho log, versione, input, parametri e replicabilità, in quel momento non ho una prova: ho un’opinione ben confezionata».

Auditabilità: i sei anelli della catena

Il principio cardine del diritto processuale è che in giudizio conta come si è arrivati alla conclusione, non quanto sia convincente il risultato. Un classificatore che raggiunge il 98% di accuratezza su un dataset di test è scientificamente impressionante, ma se non è possibile spiegare passo dopo passo, in linguaggio comprensibile per un giudice e per la difesa, perché ha prodotto quel risultato specifico su quello specifico artefatto digitale, il suo output rimane giuridicamente inutilizzabile come prova autonoma.

La risposta operativa è l’auditabilità, intesa come catena di trasformazioni documentata e verificabile. Non si tratta di comprendere i pesi neurali interni del modello, ma di ricostruire ogni passaggio del processo che ha condotto all’output. L’AI non è una scatola nera né una forza imperscrutabile: è un processo ingegneristico tracciabile, fatto di trasformazioni sequenziali e documentabili. Ogni passaggio, dall’input grezzo all’output finale, lascia una traccia misurabile.

La catena di auditabilità si compone di sei anelli: identità, provenienza, trasformazioni, parametri, log di inferenza, output duale. Se ne manca uno, non si ha più una prova robusta: si ha solo una speranza ben confezionata.

Anello 1, identità del modello

Vanno documentati il nome del modello, la versione esatta (major, minor, patch release), build e commit hash, provider, data di rilascio. Modelli con lo stesso nome ma versioni diverse producono output sistematicamente differenti, e senza l’esatta identificazione della build utilizzata al momento dell’inferenza la riproduzione del risultato in sede di controperizia è impossibile.

Anello 2, provenienza dell’input

Ogni dato fornito al sistema AI deve essere accompagnato dalla documentazione della sua origine e da un hash crittografico di integrità, tipicamente SHA-256, che attesti l’immutabilità del file fra il momento della raccolta e il momento dell’analisi. La regola d’oro è netta: l’input non verificato invalida l’output a prescindere dalla qualità dell’analisi.

Anelli 3 e 4, trasformazioni e parametri

Ogni operazione di normalizzazione, tokenizzazione, pulizia o trasformazione del dato grezzo va registrata con precisione. Anche una minima normalizzazione (la conversione delle maiuscole, la rimozione di spazi, la codifica dei caratteri) altera il contesto semantico dell’input e, di conseguenza, il risultato finale del modello. Sul versante dei parametri, il sistema AI non ragiona nel vuoto: viene istruito attraverso un prompt template e governato da parametri numerici precisi (temperatura, Top-p e altri iperparametri di campionamento). Il tribunale non vuole sapere soltanto cosa ha detto l’AI, ma come è stata istruita per dirlo.

Anelli 5 e 6, log di inferenza e output duale

I log dell’esecuzione, con timestamp UTC, identificativo della sessione, utilizzo delle risorse computazionali e traccia delle chiamate API, sono la prova che l’inferenza è avvenuta nelle condizioni dichiarate. In loro assenza, la risposta alla domanda della difesa «può riprodurre il risultato?» sarà inevitabilmente no.

L’output duale è il principio per cui il responso grezzo della macchina e l’interpretazione dell’analista umano devono essere documentati separatamente e custoditi come entità distinte. Confonderli significa contaminare la prova: il perito firma la propria analisi, la macchina attesta il proprio risultato, e nessuno dei due può parlare per l’altro.

Quando il contesto diventa campo di battaglia

Per mostrare quanto il framing incida sull’interpretazione, de Pinto ha proposto due versioni dello stesso fatto:

• versione A: «L’AI ha rilevato una sequenza anomala compatibile con condotta malevola»;
• versione B: «L’AI ha lavorato su dati incompleti, senza piena tracciabilità, e ha restituito un’anomalia che deve ancora essere verificata».

La versione A evoca urgenza, rischio, azione immediata. La versione B invita alla cautela, al dubbio, alla verifica. Eppure nessuna delle due mente: entrambe descrivono lo stesso dato grezzo, lo stesso output della macchina. Chi sceglie le parole sceglie la reazione; chi inquadra il contesto guida la conclusione. Non è retorica: è un problema di digital forensics.

Le tre aree di rischio anti-forensics

Area 1, manipolazione dell’evidenza digitale

La prima e più insidiosa categoria di rischio riguarda l’alterazione deliberata dei dati che alimentano i sistemi AI forensi. A differenza delle manipolazioni tradizionali, queste tecniche sono progettate per essere invisibili agli strumenti automatizzati.

Rientrano in questa area il data shaping (alterazione sottile e statistica di pixel, metadati, timestamp e valori numerici sotto la soglia di rilevamento degli strumenti di integrità), il log crafting (creazione di log di sistema fasulli ma formalmente corretti), la noise removal & PRNU manipulation (rimozione selettiva delle firme digitali dei sensori fotografici, ossia Photo Response Non-Uniformity, che priva i sistemi AI dell’attribution del punto di acquisizione) e il content-aware fill e inpainting (editing invisibile di immagini e video tramite algoritmi generativi avanzati).

Area 2, Adversarial Machine Learning

Categorie ormai consolidate nella sicurezza AI, codificate dal NIST AI 100-1 Artificial Intelligence Risk Management Framework e parte integrante del risk management dei sistemi intelligenti. Si distinguono i seguenti attacchi:

• Evasion Attack: modifiche minime e impercettibili agli input (singoli pixel in un’immagine, caratteri invisibili in un documento di testo) che inducono il modello a produrre classificazioni errate con alta confidenza. Una perturbazione L∞ può cambiare ogni pixel di una quantità quasi impercettibile per l’occhio umano ma sufficiente a far variare l’output del classificatore.
• Poisoning Attack: avvelenamento sistematico del dataset di addestramento tramite l’iniezione di esempi malevoli appositamente costruiti. Particolarmente insidioso, perché l’attacco avviene prima dell’uso operativo. È un punto rilevante, ha osservato de Pinto, anche per chi scarica modelli locali e ne configura l’uso interno: nessuno garantisce che il modello scaricato sia privo di effetti collaterali.
• Backdoor Attack: un trigger specifico (una sequenza di caratteri, un pattern visivo, una combinazione di input) ribalta il comportamento del modello in modo prevedibile per l’attaccante ma invisibile per l’analista.

Area 3, compromissione del workflow forense

Questa terza area non attacca il modello in modo diretto, ma agisce sull’ecosistema che lo circonda: interfacce di interazione, canali di approvvigionamento, logica decisionale.

Le tipologie principali sono il prompt injection (manipolazione di Large Language Model tramite istruzioni nascoste nei dati analizzati, che reindirizzano il comportamento del modello, ad esempio per minimizzare elementi incriminanti), il supply chain attack (distribuzione di modelli pre-compromessi attraverso repository pubblici, marketplace o aggiornamenti software apparentemente legittimi) e il model extraction (furto della logica decisionale di un modello forense proprietario tramite query sistematiche all’API esposta, per identificare gli input che producono falsi negativi). OWASP classifica prompt injection e supply chain fra i primi rischi per i sistemi LLM nella propria Top 10.

Cinque red flag, dieci secondi

«Il sistema produce un risultato con confidenza 99,8%. Non abbiamo i log completi. Lo stesso input, ripetuto tre volte, dà due output leggermente diversi. Il vendor assicura che il modello è affidabile». In meno di dieci secondi, ha osservato de Pinto, sono già state attivate tre delle cinque red flag canoniche: overconfidence, non determinismo, assenza di logging. Quando si accumulano, il problema cessa di essere tecnico e diventa processuale.

Le cinque red flag a colpo d’occhio sono:

1. Non determinismo. Lo stesso input produce output diversi in esecuzioni successive, in assenza di aggiornamenti documentati. La riproducibilità è un requisito fondamentale della prova scientifica: un sistema che non produce lo stesso output sugli stessi dati non soddisfa il criterio di verificabilità indipendente. La variabilità può essere sintomo di seed casuali non fissati, di risorse computazionali variabili o, nel caso peggiore, di manipolazione attiva.
2. Overconfidence. Score di confidenza estremamente elevati (99,7% e oltre) su dati intrinsecamente ambigui, degradati o parziali. I modelli ben calibrati riflettono nell’incertezza dell’output l’incertezza intrinseca dell’input; una confidenza artificialmente gonfiata (miscalibration) è spesso indicatore di overfitting, di un dominio di applicazione fuori distribuzione rispetto al training set o di un attacco adversarial Le metriche di calibrazione (ECE, Brier score) sono lo strumento di verifica.
3. Correlazioni spurie. Il modello fonda le proprie decisioni su caratteristiche dell’input che non hanno relazione causale con la conclusione predetta (spurious correlations o shortcut learning). Un classificatore di malware che funziona soltanto perché i campioni malevoli nel training set erano compressi con un algoritmo specifico è fragile e manipolabile. Le tecniche XAI (SHAP, LIME, Grad-CAM) servono proprio a identificare le feature più influenti sulle predizioni.
4. Assenza di logging. Il sistema non produce, o produce in modo incompleto, log dettagliati di ogni operazione. L’art. 12 dell’AI Act europeo impone esplicitamente il logging automatico per i sistemi AI ad alto rischio. Un’analisi forense condotta con un sistema privo di logging adeguato è, per definizione, non verificabile.
5. Impossibilità di triangolazione. La più critica. Se l’AI è l’unica fonte a supporto di una conclusione investigativa, quella conclusione non è una prova: è un’ipotesi non verificata. «L’ha detto l’AI» non basta in tribunale, dove un’analisi non triangolata con altre prove (testimoniali, documentali, scientifiche) non regge al vaglio del contraddittorio.

Il threat model: cosa attacca davvero l’anti-forensics

L’anti-forensics non attacca il modello AI in modo diretto, ha sintetizzato de Pinto, ma attacca ciò che il modello vede: i dati (evidenze alterate, log manipolati, artefatti falsificati), il tempo (incoerenze temporali, timestamp manipolati), il contesto (framing dell’input che orienta l’inferenza).

I modelli AI sono sensibili a scorciatoie e pattern statistici: apprendono correlazioni, non causalità. Questo li rende sistematicamente vulnerabili a chi conosce i pattern che il modello ha imparato a seguire. La conseguenza è diretta: alterare il contesto altera la conclusione. Non serve compromettere il modello; spesso basta cambiare ciò che il modello vede e come lo vede. È il principio che motiva l’intero framework di auditabilità: se non si controlla l’input, non ci si può fidare dell’output.

Le classi di impatto anti-forense si raccolgono in tre famiglie: manipolazione dell’evidenza (data shaping e log shaping, mimicry per camuffare il comportamento, timeline poisoning), adversarial machine learning (evasion, poisoning, backdoor), attacco al workflow su LLM e toolchain (prompt injection, insecure output handling, supply chain attack).

Il Forensic AI Readiness Pack

I sei requisiti minimi per rendere un sistema AI difendibile in tribunale costituiscono, secondo de Pinto, la soglia di conformità metodologica al di sotto della quale l’impiego di strumenti AI in contesti forensi con rilevanza probatoria diventa rischioso. Ogni requisito è ancorato a standard normativi o tecnici riconosciuti a livello internazionale.

1. Logging automatico. Copertura dell’intero lifecycle (acquisizione input, pre-processing, inferenza, post-processing, azioni dell’operatore). Contenuto minimo del log: timestamp UTC ad alta precisione, identificatore univoco dell’operazione (UUID), hash SHA-256 dell’input, versione esatta del modello con hash, parametri di configurazione attivi, output completo, identità dell’operatore autenticato. I log vanno scritti su storage append-only con firma digitale progressiva (log chaining) per garantirne l’immutabilità. È l’obbligo previsto dall’art. 12 dell’AI Act per i sistemi ad alto rischio.
2. Versioning rigoroso. Hash crittografico di ogni artefatto (modello, dataset, script di pre e post-processing, file di configurazione, librerie), chain of custody digitale formale di ogni accesso o trasferimento, tracciabilità completa degli aggiornamenti. Un’analisi condotta con la versione 1.2 di un modello non può essere dichiarata equivalente a una condotta con la versione 1.3 senza documentazione esplicita della compatibilità.
3. Preservazione dell’evidenza. Snapshot completo dell’ambiente di esecuzione tramite container image (Docker) o virtual machine snapshot prima di ogni analisi con rilevanza probatoria; archiviazione separata degli input originali su supporto write-once verificato, con hash calcolato prima di qualsiasi operazione; metadati contestuali completi (chi, quando, dove, perché, con quali strumenti).
4. Explainability (XAI). Tecniche SHAP (Shapley Values, basate sulla teoria dei giochi cooperativi), LIME (Local Interpretable Model-agnostic Explanations), attention maps e Grad-CAM per modelli transformer o convoluzionali. La validazione human-in-the-loop resta indispensabile: nessuna tecnica XAI sostituisce il giudizio esperto umano, e le decisioni critiche (identificazione di autore, attribuzione di malware, datazione di artefatti) richiedono validazione umana esplicita e documentata.
5. Triangolazione delle fonti. Conferma con fonti indipendenti che non condividono le stesse potenziali vulnerabilità (log di server di terze parti, testimonianze, dati provenienti da sistemi fisici distinti come router, switch o sistemi di accesso, evidenze analogiche). Validazione incrociata con tool forensi tradizionali certificati: quando AI e tool tradizionali concordano, la confidenza nell’analisi aumenta in modo significativo; quando divergono, la discrepanza è informativa e va indagata. La regola assoluta è non basare mai una conclusione probatoria sulla sola AI.
6. Conformità normativa. Il quadro applicabile varia in funzione del caso d’uso, della finalità perseguita e del ruolo assunto dal soggetto coinvolto (provider, deployer, importatore, distributore o altro operatore). Il Regolamento UE 2024/1689, c.d. AI Act, adotta un modello regolatorio basato sul rischio e qualifica come sistemi di IA ad alto rischio non qualsiasi sistema impiegato in ambito investigativo o di law enforcement, bensì specifiche categorie di sistemi indicate nell’Allegato III, punto 6, ove il relativo utilizzo sia consentito dal diritto dell’Unione o dal diritto nazionale applicabile.Per tali sistemi, secondo il regime delineato dal Regolamento e ferme le pertinenti decorrenze applicative, rilevano obblighi particolarmente incisivi: la registrazione automatica degli eventi e la tracciabilità del funzionamento del sistema ai sensi dell’art. 12; la predisposizione di misure di supervisione umana effettive, proporzionate al rischio, al livello di autonomia e al contesto d’uso, ai sensi dell’art. 14; il conseguimento di livelli adeguati di accuratezza, robustezza e cybersecurity lungo il ciclo di vita, con dichiarazione nelle istruzioni d’uso dei livelli di accuratezza e delle relative metriche, ai sensi dell’art. 15; l’espletamento delle pertinenti procedure di valutazione della conformità di cui all’art. 43.

Con specifico riferimento ai sistemi ad alto rischio di cui all’Allegato III, punti da 2 a 8, la procedura ordinaria di valutazione della conformità è quella basata sul controllo interno di cui all’Allegato VI, salvi i diversi regimi previsti per i sistemi rientranti nella normativa di armonizzazione dell’Unione o per ipotesi specifiche disciplinate dal Regolamento. Rilevano inoltre gli obblighi di registrazione nel database UE previsti dagli artt. 49 e 71, con la precisazione che, per taluni sistemi ad alto rischio impiegati in materia di law enforcement, migrazione, asilo e gestione delle frontiere, la registrazione avviene in una sezione sicura e non pubblica del database, accessibile alla Commissione e alle autorità nazionali competenti.

Il regime sanzionatorio dell’art. 99 prevede sanzioni amministrative fino a 35 milioni di euro o al 7% del fatturato mondiale annuo dell’esercizio precedente per le violazioni più gravi, in particolare per l’inosservanza dei divieti di cui all’art. 5; fino a 15 milioni di euro o al 3% per altre violazioni qualificate degli obblighi previsti dal Regolamento; fino a 7,5 milioni di euro o all’1% del fatturato mondiale annuo dell’esercizio precedente per la fornitura di informazioni inesatte, incomplete o fuorvianti agli organismi notificati o alle autorità nazionali competenti in risposta a una richiesta. Per i provider di modelli di IA per finalità generali, l’art. 101 prevede sanzioni fino a 15 milioni di euro o al 3% del fatturato mondiale annuo.

Sul versante della protezione dei dati personali, occorre distinguere in via preliminare l’ambito applicativo del GDPR da quello della normativa speciale prevista per i trattamenti svolti dalle autorità competenti per finalità di prevenzione, indagine, accertamento o perseguimento di reati, o esecuzione di sanzioni penali, per i quali rilevano la Direttiva UE 2016/680 e, nell’ordinamento italiano, il D.lgs. 51/2018. Nei casi soggetti al GDPR assumono particolare rilievo l’art. 22, in materia di decisioni basate unicamente su trattamento automatizzato, compresa la profilazione, idonee a produrre effetti giuridici o a incidere in modo analogo significativamente sull’interessato.

Gli artt. 13, 14 e 15, nella parte in cui impongono, ove ricorrano processi decisionali automatizzati rilevanti, la comunicazione di informazioni significative sulla logica utilizzata, nonché sull’importanza e sulle conseguenze previste del trattamento; l’art. 25, relativo alla protezione dei dati fin dalla progettazione e per impostazione predefinita; l’art. 35, che impone la valutazione d’impatto sulla protezione dei dati quando il trattamento, specie se fondato su nuove tecnologie, sia suscettibile di presentare un rischio elevato per i diritti e le libertà delle persone fisiche.

Sul versante tecnico-metodologico costituiscono riferimenti pertinenti la ISO/IEC 27037:2012, per l’identificazione, raccolta, acquisizione e preservazione dell’evidenza digitale; la ISO/IEC 27042:2015, per l’analisi e l’interpretazione dell’evidenza digitale; la ISO/IEC 23894:2023, per la gestione del rischio nei sistemi di intelligenza artificiale; il NIST AI Risk Management Framework, quale quadro volontario di riferimento per la governance, la mappatura, la misurazione e la gestione dei rischi associati ai sistemi AI.

I takeaway: quattro principi

L’AI è uno strumento potente, ma la prova digitale vive di tracciabilità. Senza un percorso ricostruibile non esiste prova: esiste solo un’ipotesi computazionale. Quattro principi sintetizzano la posizione del relatore.

• Velocità non è verità. Un output prodotto in millisecondi che non può essere spiegato, replicato e verificato vale meno di un’analisi tradizionale condotta con rigore metodologico.
• Black box uguale rischio legale. Ogni componente del sistema che non può essere aperto, esaminato e spiegato è un potenziale punto di attacco in sede di contraddittorio. La difesa ha tutto l’interesse, e il diritto, a smontare ciò che non si può spiegare.
• Metodologia prima di tutto. La scelta degli strumenti viene dopo la definizione del metodo. Prima si stabiliscono catena di custodia, regime di logging e strategia di triangolazione; poi si selezionano i tool AI che soddisfano questi requisiti, mai il contrario.
• Il futuro è ibrido. AI e metodologie forensi tradizionali non sono in competizione: sono complementari. Il modello di eccellenza è quello in cui l’AI amplifica le capacità dell’analista umano senza sostituirne il giudizio critico, la responsabilità professionale e la capacità di spiegazione in sede giudiziaria.

I limiti dichiarati

Dichiarare i limiti del proprio strumento non indebolisce la posizione del professionista: la rafforza. In giudizio la prudenza metodologica è credibilità. Tre limiti, per de Pinto, vanno sempre esplicitati:

• l’AI non sostituisce l’accertamento tecnico, è uno strumento di supporto all’analista; le conclusioni devono essere fondate su artefatti verificabili e il professionista resta responsabile;
• l’AI non è attendibile senza log completi e riproducibilità: un output privo di documentazione può orientare l’indagine come intelligence operativa, ma non reggere la contestazione in sede processuale;
• l’AI può essere ingannata: la vulnerabilità agli attacchi adversarial, al prompt injection, alla manipolazione del contesto è strutturale, non contingente. Non è un bug da correggere, è una caratteristica del paradigma probabilistico che richiede mitigazione metodologica permanente.

L’immagine finale proposta dal relatore è secca: l’AI non è un testimone, è un utensile, e gli utensili vanno validati. «Se non posso interrogare l’AI con log, versioni e replicazione, non è prova: è un opinionista molto eloquente». Logging, versioning, evidence handling conforme a ISO/IEC 27037, robustezza testata con prove di ripetibilità sistematiche, triangolazione con artefatti indipendenti: sono i cinque elementi che trasformano l’AI da strumento opaco a strumento difendibile. «Non è ideologia, è metodologia».

Una chiusura sull’uso reale degli strumenti

Nella parte finale dell’intervento, de Pinto ha bilanciato il quadro critico con un’osservazione operativa: la mole di dati nelle indagini contemporanee rende oggi difficile condurre analisi dettagliate come quelle del passato, e l’AI può rappresentare un aiuto reale. Molti professionisti già impiegano motori di AI integrati in software forensi (alcune suite commerciali offrono motori conversazionali interni), in cui i dati non escono dalla struttura di analisi e possono essere interrogati con efficienza significativa. È possibile interrogare con un prompt 40.000 chat e trovare riferimenti utili in tempi un tempo impensabili.

«Ben venga l’AI», ha concluso de Pinto, «se ci aiuta a trovare la verità processuale all’interno dei procedimenti». A condizione, beninteso, di non confondere mai una risposta plausibile con una risposta difendibile.