AI forensic agent

Introduzione

Essere citati in un progetto tecnico non è mai un fatto banale. Lo è ancora meno quando la citazione non riguarda una frase isolata, ma un principio architetturale preciso.

Nel repository GitHub ForensicAgent di FBR65 — disponibile all’indirizzo https://github.com/FBR65/ForensicAgent — il team dichiara esplicitamente che la filosofia del progetto è adattata dall’articolo:

AI Forensic Agents: how a pipeline can read a case file, verify evidence, and help draft a Legal Document — Andrea Belvedere.

Il principio ripreso è quello centrale:

Do not generate text first — build an evidentiary foundation.

Tradotto: prima di chiedere a un modello linguistico di scrivere, bisogna costruire una base probatoria verificabile.

Questo è il punto più importante. L’articolo originale non proponeva un semplice chatbot legale. Proponeva una pipeline: lettura dei documenti, classificazione, estrazione dei fatti, collegamento alle prove, costruzione di un grafo, controlli deterministici, recupero di fonti e solo alla fine uso dell’LLM.

Il progetto ForensicAgent prende questa impostazione e prova a trasformarla in un sistema software generale, applicabile non solo ai fascicoli legali, ma anche a indagini cyber, frodi finanziarie, assicurazioni, fisco e altri scenari investigativi.

Questo articolo analizza cosa è rimasto dell’idea iniziale, cosa è cambiato, dove il progetto sembra migliorare l’impianto originale e dove invece resta ancora un prototipo.

L’idea originale: non un chatbot, ma una pipeline forense

L’articolo di Andrea Belvedere partiva da una critica molto chiara: nel lavoro legale e forense non basta prendere un fascicolo, mandarlo a un modello linguistico e sperare che la risposta sia corretta.

Quel metodo è fragile. Il modello può:

• confondere documenti diversi;
• sommare importi che non devono essere sommati;
• trattare una bozza come una prova;
• citare dati non presenti nel fascicolo;
• dedurre conclusioni non supportate dagli atti;
• inventare passaggi apparentemente plausibili.

Per evitare questo, l’articolo proponeva una pipeline in cui l’LLM non è il centro del sistema. È l’ultimo passaggio.

Prima vengono:

1. acquisizione dei documenti;
2. controllo della qualità di parsing e OCR;
3. classificazione dei documenti;
4. estrazione dei fatti rilevanti;
5. creazione di prove atomiche;
6. costruzione di un knowledge graph probatorio;
7. controllo degli importi;
8. verifica dei requisiti;
9. recupero di fonti legali o procedurali;
10. generazione controllata del testo;
11. verifica dell’output prodotto dall’LLM;
12. revisione professionale.

La formula era semplice ma forte:

Il modello non deve decidere cosa è vero. Deve lavorare dentro un perimetro già verificato.

Che cos’è ForensicAgent

ForensicAgent è un progetto Python che prova a rendere operativa questa idea.

Non si presenta come un generatore automatico di documenti, ma come una pipeline AI forense general-purpose. Il suo obiettivo è leggere documenti e artefatti, estrarre fatti, collegarli a prove, costruire un grafo del caso, eseguire controlli, recuperare conoscenza di dominio e produrre risposte o bozze controllate.

Il progetto dichiara di poter essere applicato a:

• fascicoli legali;
• incidenti cyber;
• frodi finanziarie;
• sinistri assicurativi;
• frodi fiscali;
• report medico-legali;
• altri contesti investigativi.

La tecnologia scelta include:

• Agno, come framework per agenti;
• SpaCy, in particolare il modello tedesco de_dep_news_trf;
• BM25, tramite rank-bm25, per indicizzazione e recupero keyword;
• Semantica, per ContextGraph, provenance, deduplicazione, conflict detection, Datalog reasoning e PROV-O export;
• LMDB, per lo storage volatile per sessione;
• firecrawl-anydoc, per convertire documenti in Markdown localmente, senza API key e senza servizio esterno;
• NetworkX, come grafo operativo in memoria.

Questa scelta tecnica mostra subito una differenza: l’articolo originale descriveva soprattutto l’architettura concettuale; ForensicAgent prova a metterla in codice.

Cosa ForensicAgent riprende quasi direttamente dall’articolo

La continuità tra l’articolo e il repository è molto evidente.

1. L’LLM è l’ultimo anello della catena

Il punto filosofico centrale è identico: non si parte generando testo. Si parte costruendo evidenza.

ForensicAgent esplicita che l’LLM è opzionale. Se non è configurata una API key, la pipeline può funzionare in modalità deterministica, basata su query al grafo e fatti confermati.

Questo è coerente con l’idea originale: il modello linguistico non deve essere indispensabile per stabilire la struttura del caso.

2. Le prove atomiche sono il cuore del sistema

Nell’articolo, ogni fatto doveva essere collegato a una prova atomica: un frammento preciso di documento, una frase, una riga, una porzione di testo.

ForensicAgent implementa proprio questa logica con oggetti come:

• Fact;
• Evidence;
• Source;
• Requirement;
• Finding;
• Amount.

Il percorso chiave rimane:

Requirement → Fact → Evidence → Source

Un requisito non è soddisfatto solo perché un campo è compilato. Deve esistere un percorso probatorio completo.

3. Separazione tra dati del caso e conoscenza generale

Un altro punto fondamentale dell’articolo era la separazione tra:

• dati riservati del fascicolo;
• conoscenza generale, normativa, procedurale o di dominio.

ForensicAgent riprende questa idea con due store distinti:

• Case Graph, volatile e per-sessione;
• Domain KB, persistente e riutilizzabile.

Questa separazione è decisiva. Un fascicolo non deve diventare memoria generale del sistema. I dati di un cliente non devono contaminare i casi futuri.

4. Controlli deterministici prima dell’LLM

L’articolo insisteva sul fatto che alcuni controlli non devono essere affidati alla “sensazione” del modello.

ForensicAgent implementa controlli su:

• presenza di prove;
• qualità del documento;
• regole di dominio;
• importi;
• conflitti;
• deduplicazioni;
• requisiti mancanti.

Questo è uno dei punti più fedeli al disegno originale.

5. Verifica dell’output dopo la generazione

Anche dopo la risposta dell’LLM, il sistema non si fida ciecamente.

ForensicAgent include un GroundingAgent che estrae claim sensibili dall’output — importi, date, codici fiscali, IBAN, IP, riferimenti giudiziari — e controlla se sono presenti tra i fatti confermati nel grafo.

Se non lo sono, l’output viene considerato non fondato.

Questo riprende un punto forte dell’articolo: l’agente non deve solo generare, deve anche controllare ciò che ha generato.

Cosa è cambiato rispetto all’articolo originale

La prima grande differenza è l’ambizione di generalizzazione.

L’articolo originale nasceva dentro un contesto soprattutto legale: fascicoli, documenti, passività, patrimonio, requisiti, bozza di atto, revisione professionale.

ForensicAgent allarga il campo. Non vuole essere solo un agente per documenti legali. Vuole essere una piattaforma forense generale.

Questo cambia molto.

Nel repository troviamo domini come:

• legal;
• cyber;
• financial;
• tax;
• general.

Esempio: in un caso cyber il fatto rilevante può essere un indirizzo IP collegato a una riga di log. In un caso fiscale può essere una partita, un conto, una fattura o una transazione. In un caso legale può essere un importo, una parte, un tribunale, una testimonianza o un atto.

Quindi il progetto prende la struttura concettuale dell’articolo e la trasforma in un modello più ampio:

non più solo “AI forensic agent per documenti legali”, ma “forensic agent pipeline per qualunque indagine documentale”.

È una trasformazione interessante, anche se comporta una perdita di profondità su alcuni aspetti strettamente legali.

Dove ForensicAgent migliora l’impianto iniziale

Ci sono diversi punti in cui il progetto GitHub aggiunge elementi concreti e, in alcuni casi, migliora la proposta iniziale rendendola più eseguibile.

1. Trasforma l’architettura in un progetto installabile

Il miglioramento più evidente è questo: l’idea diventa codice.

ForensicAgent ha:

• una struttura Python organizzata;
• un pyproject.toml;
• una CLI;
• test automatici;
• casi di esempio;
• configurazioni di dominio;
• una pipeline orchestrata da una classe principale, ForensicPipeline.

Questo passaggio è importante. Un’architettura teorica può essere elegante, ma un repository eseguibile costringe a prendere decisioni pratiche: quali oggetti creare, quali fasi separare, quali dati salvare, quali controlli implementare.

2. Introduce Semantica come infrastruttura del grafo

Uno dei punti più interessanti è l’integrazione con Semantica.

Semantica porta nel progetto funzioni che nell’articolo erano concettualmente previste, ma non legate a una libreria specifica:

• ContextGraph;
• ProvenanceManager;
• ConflictDetector;
• DuplicateDetector;
• EntityMerger;
• DatalogReasoner;
• RDF/PROV-O export.

Questo rafforza molto la parte di tracciabilità.

L’articolo parlava di audit e percorsi probatori. ForensicAgent aggiunge una possibile rappresentazione standardizzata della provenienza, arrivando fino all’esportazione PROV-O, utile in scenari dove serve auditabilità formale.

3. Aggiunge Datalog reasoning

Il ragionamento tramite regole Datalog è un’altra estensione interessante.

Invece di limitarsi a controlli procedurali scritti in codice, il progetto prevede regole dichiarative di dominio. Questo permette di dire, per esempio:

• un requisito è soddisfatto solo se esistono certi tipi di fatto;
• un fatto deve avere evidenza;
• certi valori devono rispettare una forma;
• alcune condizioni producono violazioni o warning.

È un miglioramento perché rende il sistema più vicino a una vera architettura forense: non solo testo e prompt, ma regole verificabili.

4. Migliora la parte di document ingestion locale

ForensicAgent usa firecrawl-anydoc per convertire documenti in Markdown localmente.

Questo è un punto di forza notevole, perché riduce la dipendenza da servizi esterni. Il repository dichiara supporto a formati come:

• PDF;
• DOC/DOCX;
• ODT;
• RTF;
• EPUB;
• PPT/PPTX;
• XLS/XLSX;
• CSV;
• TXT;
• LOG;
• immagini via OCR.

Questo è perfettamente coerente con l’idea di privacy dell’articolo originale: prima di mandare dati a un LLM, e possibilmente senza mandarli affatto, il sistema deve saper leggere localmente i documenti.

5. Aggiunge una modalità senza LLM

Questo è uno dei miglioramenti più intelligenti.

ForensicAgent può funzionare anche senza OPENAI_API_KEY. In quel caso non invoca il modello, ma usa la parte deterministica della pipeline.

Questo significa che il progetto non è costruito intorno al presupposto “senza LLM non funziona”. Al contrario: il grafo, i fatti, le prove, i controlli e una parte delle risposte possono esistere anche senza generazione linguistica.

È una scelta corretta per un sistema forense.

6. Aggiunge test e casi dimostrativi

Il README dichiara una suite di test abbastanza ampia:

• test sul grafo;
• test su BM25;
• test su estrazione e linking;
• test su conflitti;
• test su deduplicazione;
• test su Semantica;
• test su grounding;
• test end-to-end;
• test su casi real-data sintetici.

Sono presenti anche casi di esempio per domini legali, cyber, finanziari, assicurativi e fiscali.

Questo è importante perché sposta il progetto da “bella idea” a “sistema verificabile”. Anche se i test non dimostrano automaticamente qualità produttiva, indicano una direzione seria.

I principali punti di forza di ForensicAgent

Riassumendo, i punti di forza più evidenti sono questi.

Evidence-first reale

Il progetto non usa l’LLM come scorciatoia iniziale. Prima costruisce fonti, fatti, prove, requisiti e grafo.

Buona modularità

La divisione in agenti è chiara:

• ingestion;
• quality control;
• classification;
• keyword indexing;
• fact extraction;
• evidence linking;
• validation;
• retrieval;
• context building;
• assessment;
• grounding;
• reporting;
• review.

Questa modularità rende il sistema leggibile e migliorabile.

Separazione tra caso e conoscenza di dominio

La separazione tra grafo volatile del caso e knowledge base persistente è uno dei punti più solidi. È anche uno dei più importanti dal punto di vista privacy.

Output grounding

La verifica post-generazione è fondamentale. Anche se non copre tutto, la presenza di un GroundingAgent è un segnale architetturale corretto.

Supporto multi-dominio

Il passaggio da legal AI a forensic AI general-purpose è ambizioso. Permette di applicare lo stesso impianto a scenari diversi.

Provenance e audit

L’integrazione con Semantica e PROV-O rende più forte il tema della tracciabilità: non solo “questa risposta sembra corretta”, ma “questa risposta ha un percorso verso le fonti”.

Configurazione OpenAI-compatible

Il progetto permette di configurare endpoint compatibili OpenAI, quindi potenzialmente anche Ollama, LM Studio, vLLM o gateway privati. Questo è coerente con un approccio moderno: il modello deve essere sostituibile.

Dove il progetto è ancora migliorabile

È importante essere equilibrati: ForensicAgent è interessante, ma non va confuso con un prodotto forense maturo pronto per uso professionale senza ulteriori verifiche.

1. Classificazione ancora piuttosto euristica

La classificazione dei documenti sembra basarsi soprattutto su parole chiave e regole semplici.

Questo è utile per un prototipo, ma in un fascicolo reale i documenti sono spesso più ambigui. Una bozza può contenere parole da documento finale. Un report può citare dati primari. Un allegato può avere sezioni miste.

Qui servirebbe una classificazione più sofisticata e calibrata sui domini.

2. Estrazione basata su SpaCy e regex

SpaCy e le espressioni regolari sono strumenti efficaci per individuare elementi strutturati come importi, date, IBAN, indirizzi IP, email e identificativi.

Tuttavia, individuarli non significa comprenderne il significato nel contesto. In un’analisi forense, il sistema deve stabilire, per esempio:

• se un importo rappresenta un debito ancora attivo oppure già estinto;
• se indica il totale complessivo o una singola rata;
• se si tratta di una pretesa, una spesa, una stima o una soglia;
• se il dato è semplicemente dichiarato da una parte oppure verificato da un documento.

Il progetto affronta parzialmente questi aspetti, ma la capacità di interpretare il significato giuridico e investigativo delle informazioni deve ancora essere rafforzata.

3. Grounding utile ma parziale

Il GroundingAgent controlla soprattutto claim riconoscibili con pattern: importi, date, identificativi, IP, IBAN, riferimenti giudiziari.

È già molto meglio di niente. Però molte affermazioni rilevanti sono narrative:

• “il debitore ha agito in buona fede”;
• “la condotta appare fraudolenta”;
• “il danno è causalmente collegato all’evento”;
• “la fonte è sufficiente a provare il requisito”.

Queste frasi non sono sempre verificabili con un confronto testuale semplice. Serve un grounding più ricco, capace di controllare anche relazioni, causalità e qualificazioni.

4. Revisione professionale ancora più API che prodotto

Il progetto prevede un ReviewAgent, quindi l’idea della revisione umana è presente.

Tuttavia, dal repository emerge più una struttura backend/API che una vera esperienza completa per il professionista: non una UI matura di revisione, annotazione, accettazione e rifiuto dei dati.

Per un uso reale, questa parte sarebbe centrale.

5. Il dominio legale perde un po’ di profondità

L’articolo originale entrava molto nel merito della logica legale: differenza tra fonti primarie e derivate, somme improprie, bozze, piani, passività, requisiti, cautele di redazione.

ForensicAgent generalizza. Questo è un vantaggio, ma anche un compromesso: diventando general-purpose, rischia di perdere parte della finezza specifica del dominio legale.

Il confronto in sintesi

La cosa più interessante: hanno capito il punto

Il dato più rilevante non è che abbiano usato Agno, SpaCy, BM25 o Semantica.

Il dato più rilevante è che abbiano capito il punto architetturale dell’articolo:

un agente forense non deve essere un generatore di testo, ma una macchina di verifica prima della generazione.

Questa distinzione è enorme.

Molti sistemi AI per documenti continuano a funzionare così:

Documenti → prompt lungo → risposta del modello

ForensicAgent invece segue una logica più sana:

Documenti → fatti → prove → grafo → controlli → contesto → LLM → grounding → audit

È qui che si vede l’influenza dell’articolo originale.

È un miglioramento rispetto al progetto originale?

La risposta più corretta è: sì, in alcuni aspetti; no, in altri.

È un miglioramento perché:

• rende l’architettura eseguibile;
• aggiunge test;
• introduce Semantica;
• formalizza provenance e PROV-O;
• generalizza a più domini;
• consente modalità deterministica senza LLM;
• offre una CLI e casi di esempio;
• rende più concreta l’idea di grafo probatorio volatile.

Non è necessariamente un miglioramento perché:

• la profondità giuridica dell’articolo viene semplificata;
• alcune parti sono ancora euristiche;
• il grounding non copre tutte le affermazioni complesse;
• la revisione professionale non sembra ancora una vera esperienza di lavoro completa;
• il sistema resta un prototipo tecnico, non una soluzione professionale finita.

Quindi ForensicAgent non sostituisce la visione iniziale. La trasforma in una prima implementazione generalizzata.

Perché questa citazione è importante

Il fatto che il team abbia citato Andrea Belvedere non è solo una cortesia. È un segnale.

Significa che l’idea “evidence-first” sta diventando riconoscibile. Significa che qualcuno ha letto l’articolo non come opinione, ma come blueprint architetturale. Significa che la discussione sugli AI agent professionali si sta spostando dal prompt alla struttura.

Ed è proprio questo il punto.

Il futuro della legal AI e della forensic AI non sarà fatto da chatbot che scrivono documenti “plausibili”. Sarà fatto da pipeline che costruiscono basi verificabili, separano le fonti, tracciano la provenienza, bloccano errori e usano l’LLM solo dentro un perimetro controllato.

Conclusione

ForensicAgent è una lettura interessante perché mostra cosa succede quando un principio progettuale viene preso sul serio.

L’articolo originale diceva: non generate testo prima di avere costruito una base probatoria.

Il repository FBR65 prova a fare esattamente questo: acquisisce documenti, misura qualità, classifica, estrae fatti, crea prove atomiche, costruisce un grafo, valida, recupera conoscenza di dominio, usa l’LLM in modo controllato e verifica l’output.

Non è ancora un prodotto definitivo. Alcuni componenti sono euristici, alcune verifiche sono parziali e la parte di revisione professionale dovrà crescere. Ma l’impianto è corretto.

Il suo punto di forza non è promettere che l’AI possa sostituire il professionista. Il suo punto di forza è l’opposto: costruire una struttura in cui l’AI lavori sotto controllo, con prove, regole, audit e revisione.

In questo senso, ForensicAgent non è solo un progetto GitHub ispirato a un articolo. È una conferma pratica della tesi centrale:

la differenza tra un chatbot e un agente forense non è il modello linguistico. È la pipeline di verifica che sta prima e dopo il modello.