Una browser farm e un motore a regole multi-LLM per la due diligence documentale

Contesto

La società svolge attività di due diligence su aziende e sulle persone dietro di esse. Le prove vivono nei documenti — visure, registri, report — sparsi su portali web che si aspettano un browser vero e autenticato, non un'API. Gli analisti aprivano ogni fonte a mano, scaricavano PDF e fogli di calcolo e copiavano i fatti rilevanti in una checklist. Hanno portato l'intera automazione a DigitalBorders: raccogliere i documenti, estrarre i fatti e lasciare che una persona revisioni invece di trascrivere.

Problema

La parte difficile non era il singolo documento — era arrivarci e leggerli su larga scala, con ogni fatto tracciabile.

• Le fonti non hanno API. I dati stanno dietro portali interattivi, spesso dietro un login. Raggiungerli significa guidare una sessione di browser reale, non chiamare un endpoint.
• Un solo browser non basta. Un'esecuzione reale richiede molte sessioni in parallelo, ognuna isolata, ognuna con i propri download tenuti separati dagli altri.
• Un documento non è una risposta. Un PDF di 40 pagine non è un fatto. La società ha bisogno di valori specifici, ognuno ricondotto alla fonte esatta da cui proviene e verificato rispetto alle proprie regole.
• Nessun singolo modello è affidabile da solo. Un'estrazione che un modello sbaglia, un altro la azzecca. La pipeline deve instradare tra più modelli e far emergere i disaccordi invece di nasconderli.

Approccio

Abbiamo seguito l'intera catena — l'infrastruttura dei browser, il motore di estrazione e la dashboard in cui lavorano gli analisti.

Il livello di raccolta è una farm di istanze reali di Google Chrome in esecuzione dentro container Neko, ciascuna che espone il Chrome DevTools Protocol attraverso un proxy, così la nostra automazione la guida con Puppeteer via CDP. Ogni sessione riceve un profilo di browser isolato e una cartella di download dedicata; un file server applica una policy rigida — solo i tipi di documento che ci aspettiamo (PDF, fogli di calcolo, Word), tenuti per sessione e ripuliti al termine — così un'esecuzione non può accumulare spazzatura in silenzio.

I documenti confluiscono in un motore a regole che esegue l'estrazione su più LLM instradati tramite OpenRouter, così ogni regola può usare il modello che la gestisce meglio e le risposte in conflitto vengono intercettate invece di essere accettate alla cieca. Ogni fatto estratto è legato al documento di origine da cui proviene.

Gli analisti lavorano in una dashboard Next.js basata su Convex, con accesso per ruoli: configurano le regole, seguono le esecuzioni in corso e revisionano i fatti estratti. Un solo team ha seguito la browser farm, il motore di estrazione e la dashboard, così i confini tra loro si allineavano invece di essere negoziati tra fornitori diversi.

Risultato

Un'esecuzione ora avvia i browser che raccolgono le fonti, il motore a regole estrae e verifica ogni fatto rispetto alle regole della società, e i risultati arrivano nella dashboard dove un analista li revisiona — legge e valuta, invece di raccogliere e copiare. Poiché la farm guida Chrome reale, raggiunge fonti che un approccio solo-API semplicemente non può, e poiché ogni fatto porta con sé la propria fonte, la società può garantire per ciò che la pipeline restituisce.