L'AI che legge le perizie delle aste giudiziarie
Una pipeline serverless legge le perizie delle aste giudiziarie, ne estrae 37 campi e calcola il ROI su più scenari.
- Anno
- 2025
- Cliente
- Operatore immobiliare specializzato in aste giudiziarie
Un immobile all'asta si valuta con numeri che il portale del Ministero non pubblica. La scheda online dice dove si trova e quanto parte la base; per sapere se conviene servono la superficie commerciale e quella calpestabile, il piano, i dati catastali e la rendita, la condizione dell'immobile e dello stabile, le quote di proprietà, gli abusi e le eventuali sanatorie, le ipoteche e i pignoramenti a carico della procedura, il valore e il costo di ripristino stimati dal consulente del giudice.
Tutto questo esiste in un posto solo: la perizia allegata, un PDF con una mediana di 24 pagine, che in qualche caso arriva a 881. Su un bacino di circa 14.000 aste attive contemporaneamente, leggerle a mano significa scegliere in anticipo quali guardare, cioè decidere senza sapere.
Il primo ostacolo è che la materia prima è sporca. Il 26% delle aste non ha nessuna perizia allegata: il portale le pubblica lo stesso, e per quelle non c'è estrazione che tenga. Il 27,5% delle perizie che ci sono è una scansione pura, senza uno strato di testo: prima di leggerla bisogna riconoscerla, e lì entra Textract. Il resto sono documenti scritti da persone diverse con criteri diversi, dove lo stesso dato cambia nome, posizione e formato da un tribunale all'altro.

Una catena di prompt specializzati
L'estrazione non è una domanda sola a un modello. È una catena: prima un classificatore stabilisce se la perizia riguarda un lotto unico, un multibene o un multilotto, e in quale delle sei tipologie ricade, perché da quella risposta dipende quale superficie vada letta e dove. Solo dopo si attivano i prompt giusti per quel caso, circa 37 specializzati invece di uno generico che deve indovinare tutto. Ogni valore torna con un punteggio di confidenza accanto, non solo con il numero: chi legge sa quali campi può prendere così e quali vanno verificati.
I prompt e i modelli si modificano dall'interfaccia. Chi conosce il dominio, e cioè chi sa come è scritta una perizia, può correggere un prompt o assegnare un modello diverso a un singolo campo dal pannello, senza aprire una richiesta allo sviluppo e senza aspettare un rilascio. È la differenza fra un sistema che migliora ogni giorno e uno che migliora quando c'è tempo.
Cosa si può regolare e cosa no
Le assunzioni di business sono configurazione: l'overhead aziendale, la durata stimata di una ristrutturazione, le soglie oltre cui conviene frazionare si cambiano a caldo, perché cambiano con il mercato e con l'azienda. Quello che è fissato dalla legge, cioè le aliquote dell'imposta di registro, l'IVA e i moltiplicatori IMU, resta deliberatamente nel codice. La distinzione serve perché nessuno, dal pannello, possa modificare una norma.
Un parametro di business si cambia in un pomeriggio. Un'aliquota no, e il software deve saperlo.

Con i campi estratti e le assunzioni al loro posto, il sistema sceglie da solo gli scenari da calcolare: nuova costruzione, ristrutturazione, frazionamento, sanatoria. La scelta segue la tabella decisionale del cliente a partire da categoria catastale, stato dell'immobile e superficie, così il confronto fra due aste è un confronto fra scenari omogenei e non fra due letture diverse dello stesso problema.
Rileggere la stessa perizia 28 volte
Una catena di prompt specializzati ha un costo che si misura: la stessa perizia viene riletta circa 28 volte dai vari passaggi. Per questo il costo dei modelli è tracciato per singola estrazione, con i prezzi aggiornati automaticamente ogni settimana, e il caching dei prompt è esplicito invece che sperato. Su un sistema così la leva non è la tariffa per token: è quante volte eviti di far rileggere le stesse pagine.
Quello che cambia, alla fine, non è la velocità di lettura di una perizia: è che non serve più sceglierne una. Il perimetro dell'analisi smette di essere quanto tempo ha una persona e torna a essere quante aste ci sono.
DEEP DIVE TECNICO
Pipeline serverless su AWS: Lambda per i singoli passi, Step Functions per orchestrare l'estrazione, Textract per l'OCR con SNS e SQS a gestire il completamento asincrono dei job, S3 per i documenti e Secrets Manager per le chiavi. Il codice è TypeScript da un capo all'altro in un monorepo pnpm con sei servizi più il codice condiviso, con Zod a validare ogni confine e ts-pattern per la logica a casi, che qui è indispensabile: le tipologie di lotto sono sei e sbagliarne una significa leggere la superficie sbagliata. I dati stanno su PostgreSQL con Drizzle ORM, 15 tabelle e 65 migrazioni versionate. Il pannello di controllo è in Next.js 15 e React 19 su Vercel, con shadcn/Radix e Tailwind. I modelli linguistici passano da un gateway agnostico rispetto al fornitore: il modello è configurazione, non una decisione presa in fase di build, e si cambia per singolo prompt senza rilasciare niente.
Stack: AWS Lambda, Step Functions, Textract, SQS, S3, TypeScript, pnpm monorepo, Zod, ts-pattern, PostgreSQL, Drizzle ORM, Next.js 15, React 19, Vercel, LLM gateway
DEEP DIVE TECNICO
Pipeline serverless su AWS: Lambda per i singoli passi, Step Functions per orchestrare l'estrazione, Textract per l'OCR con SNS e SQS a gestire il completamento asincrono dei job, S3 per i documenti e Secrets Manager per le chiavi. Il codice è TypeScript da un capo all'altro in un monorepo pnpm con sei servizi più il codice condiviso, con Zod a validare ogni confine e ts-pattern per la logica a casi, che qui è indispensabile: le tipologie di lotto sono sei e sbagliarne una significa leggere la superficie sbagliata. I dati stanno su PostgreSQL con Drizzle ORM, 15 tabelle e 65 migrazioni versionate. Il pannello di controllo è in Next.js 15 e React 19 su Vercel, con shadcn/Radix e Tailwind. I modelli linguistici passano da un gateway agnostico rispetto al fornitore: il modello è configurazione, non una decisione presa in fase di build, e si cambia per singolo prompt senza rilasciare niente.
Stack: AWS Lambda, Step Functions, Textract, SQS, S3, TypeScript, pnpm monorepo, Zod, ts-pattern, PostgreSQL, Drizzle ORM, Next.js 15, React 19, Vercel, LLM gateway
- Anno
- 2025
- Cliente
- Operatore immobiliare specializzato in aste giudiziarie
Hai un progetto simile in mente?
Raccontaci cosa vuoi costruire: ti aiutiamo a capire il percorso più veloce.






