In breve
In ogni azienda arrivano PDF (bolle, fatture, attestati, ricevute) che qualcuno deve leggere e copiare in un gestionale. Lavoro ripetitivo, soggetto a errori. Noi abbiamo costruito un sistema che fa il “primo passaggio” da solo: il PDF arriva, l’IA legge i dati, li manda al gestionale già strutturati, e un operatore deve solo verificare. Tutto in casa, senza che nessun PDF esca dall’azienda: i dati dei clienti restano protetti. Sui PDF testuali (generati da computer) il modello non sbaglia perché classifica dati già scritti, non li interpreta. Sui PDF immagine (scansioni, foto) può sbagliare con scansioni storte o layout anomali. La validazione umana resta sempre necessaria: non è automazione magica. Lo stiamo testando in produzione su MIRMI, il nostro gestionale per studi RSPP/sicurezza.
In ogni azienda arrivano documenti che devono finire nel gestionale: bolle di consegna, fatture passive, ordini, ricevute, attestati. Qualcuno li apre, li legge, e copia i dati in un form a mano. Lo facciamo ogni giorno, e ogni volta che lo facciamo perdiamo tempo, sbagliamo qualche dato, e ci chiediamo perché non si possa automatizzare.
L’OCR esiste da decenni, l’IA generativa da qualche anno, eppure tradurre un PDF “vivo” in dati strutturati pronti per il gestionale non è così semplice. Abbiamo provato a metterci mano. La domanda di partenza: cosa serve davvero per leggere documenti automaticamente in casa, dentro un’azienda piccola, senza mandare nulla nel cloud?
Cosa abbiamo costruito
Il flusso, raccontato dall’inizio: il PDF arriva (caricato dall’utente, pescato da una cartella, ricevuto via e-mail) e finisce in una coda di lavorazione su n8n, l’orchestratore di workflow open-source che abbiamo descritto nell’articolo sul nostro server IA.
Da lì il workflow distingue due casi:
- PDF testuale (generato da computer, contiene testo estraibile): il sistema legge i dati direttamente dal PDF, e l’LLM ha il compito limitato di classificarli, decidere “questa stringa è il codice fiscale, questa è la data, questa è il titolo del corso”. Non interpreta, abbina. Su questo task il modello difficilmente sbaglia.
- PDF immagine (scansione, fotografia, PDF “appiattito”): qui entra in gioco il modello multimodale, che “vede” il documento e ricostruisce i campi dall’immagine. Più sfidante, più soggetto a errori.
In entrambi i casi il blocco di dati esce da n8n come JSON e va al gestionale tramite la sua API REST. Il gestionale lo memorizza in un’area di staging e mostra una schermata di validazione umana: l’operatore vede il PDF accanto ai campi pre-compilati, conferma o corregge, e solo allora il record entra definitivamente.
Il punto chiave è quest’ultimo step. Niente passa nel database del gestionale senza un occhio umano sopra. Il modello assiste, non sostituisce.
Tutto gira in casa. Niente PDF mandato a servizi cloud, niente dati che escono dall’azienda. Con questa architettura il problema del trasferimento dei dati a un fornitore IA esterno è eliminato alla fonte: non c’è un DPA da negoziare con un provider perché i dati non escono dall’azienda. Restano gli altri profili GDPR ordinari (base giuridica del trattamento, eventuale DPIA se il trattamento la richiede), che vanno valutati come per qualunque trattamento interno.
Come si comporta
Restiamo concreti, raccontando quello che abbiamo misurato sul caso che conosciamo meglio.
Il primo case d’uso reale è MIRMI Attestati: estrazione dati da attestati di formazione PDF, integrata nel gestionale MIRMI per studi RSPP/sicurezza. Uno studio medio gestisce circa 200 attestati l’anno per cliente. Inserimento manuale = qualche minuto a documento + errori di trascrizione (soprattutto sui codici fiscali) + il fastidio di un lavoro ripetitivo.
Accuracy. Abbiamo testato finora una trentina di attestati in formato PDF testuale. Sui campi anagrafici (nome, cognome, codice fiscale, data) il modello non ha mai sbagliato. La ragione è strutturale: il PDF testuale espone già i dati, e l’LLM si limita a classificarli, non li interpreta. Per come è costruito il sistema, su questo tipo di documenti gli errori sono sostanzialmente esclusi.
Discorso diverso per i PDF immagine (scansioni, foto): qui il modello multimodale deve riconoscere visivamente i caratteri prima di classificarli. Su questa fascia ci aspettiamo accuracy più bassa, in particolare con scansioni storte, layout anomali, firme che coprono i campi. Quando arriveranno volumi più grandi e documenti più sporchi vedremo i numeri.
Tempi: ~100 documenti al giorno col nostro server. È asincrono: non serve nessuno seduto davanti che aspetta. L’operatore carica i PDF, va a fare altro, e quando torna trova la coda da validare.
Il bilancio: per i documenti “tipici” l’inserimento da manuale a guidato + validazione passa da ~3 minuti a ~30 secondi a documento.
Quello che NON va
Sarebbe disonesto fermarsi al “funziona”. Due limiti da conoscere prima.
1. La validazione umana non è opzionale. Anche con accuracy alta sui documenti tipici, non c’è automazione totale. Una scrittura sbagliata nel gestionale che entra senza un occhio sopra può diventare un grattacapo (CF errato in anagrafica, data sbagliata su una scadenza). L’operatore che valida è una salvaguardia, non una cerimonia. Chi promette estrazione completamente automatica sta vendendo un rischio nascosto.
2. Il throughput è dimensionato sull’azienda piccola. Con il nostro server gestiamo ~100 documenti al giorno. Per processare migliaia di documenti al giorno basta aumentare le caratteristiche del server (più RAM, più potenza GPU, hardware dedicato). Il pattern resta lo stesso, scala col dimensionamento.
Una nota di onestà: il modello locale è meno potente dei modelli cloud più grandi. Su documenti complessi un GPT-5 multimodale o un Claude Opus 4.7 probabilmente farebbero meglio. Ma i loro dati uscirebbero dall’azienda: trade-off di sovranità contro qualità, dove abbiamo scelto la sovranità.
Dove l’abbiamo applicato
Il primo caso in produzione (per ora in test su un campione limitato) è MIRMI Attestati. Il pattern però è generale: dovunque ci siano documenti ricorrenti che qualcuno legge a mano e copia in un sistema, c’è spazio per applicarlo.
Esempi che stiamo valutando per il prossimo periodo:
- Fatture passive: lettura della testata (fornitore, data, totale), riconciliazione col gestionale.
- Bolle di consegna / DDT: estrazione anagrafica fornitore + righe della bolla.
- Ricevute spese e scontrini: per registrazione note spese dei collaboratori.
Non sono ancora in produzione: sono caselle aperte sulla nostra lista. Il pattern è lo stesso: PDF → estrazione → JSON → API gestionale → validazione umana.
Quello che cambia da un use case all’altro non è l’architettura, sono i campi che il modello deve riconoscere e come glielo si dice. Settimane di lavoro per ogni nuovo use case, non mesi.
Perché lo raccontiamo
Non è un manuale. Lo raccontiamo perché diversi nostri clienti ci stanno chiedendo come stiamo affrontando l’IA in azienda: cosa abbiamo costruito, cosa funziona, cosa no. Le risposte che diamo a voce le abbiamo messe in altri articoli qui sul lab:
- Il nostro server IA in casa, senza pretese: hardware, stack, limiti reali del setup su cui gira tutto questo.
- n8n + e-mail aziendali: lo stesso pattern (workflow + LLM locale) applicato alla classificazione automatica della posta.
- GDPR e servizi IA blasonati: perché ChatGPT, Copilot e gli altri pongono domande di trattamento dati da chiarire prima di firmare.
Progetto in test su MIRMI Attestati, primi risultati positivi, pattern replicabile su altri documenti ricorrenti. Se queste informazioni ti risulteranno utili, avremo fatto bingo.
Domande frequenti
Si possono leggere automaticamente i dati da PDF e inserirli in un gestionale?
Sì, il pattern è “PDF → estrazione via LLM → JSON → API gestionale → validazione umana”. Funziona molto bene su PDF testuali (generati da computer); su PDF immagine (scansioni, foto) la qualità di estrazione cala con scansioni storte o layout anomali.
L’IA può sbagliare nel leggere un codice fiscale o una data da PDF?
Su PDF testuali il rischio è basso, perché il modello classifica dati già presenti nel file (non deve interpretarli). Su PDF immagine può sbagliare se la scansione è poco leggibile. Per questo è essenziale la validazione umana finale prima della scrittura nel gestionale.
È necessaria la convalida umana o l’IA può inserire i dati direttamente?
La convalida umana è essenziale. Anche con accuracy alta, una scrittura sbagliata nel gestionale può produrre danni difficili da correggere (CF errato in anagrafica, data errata su scadenza). Il pattern corretto è “IA assiste, umano controlla”.
Quanti documenti al giorno può processare un server IA in azienda?
Con un setup mini-PC AI di fascia bassa-media gestiamo ~100 PDF al giorno. Il throughput scala col dimensionamento dell’hardware (più RAM, più potenza GPU): per processare migliaia di documenti al giorno serve hardware superiore.
Serve un sistema diverso per ogni tipo di documento (fattura, bolla, attestato)?
No, l’architettura resta la stessa (PDF → LLM → JSON → API). Cambiano i campi che il modello deve riconoscere e il prompt che lo guida. Settimane di lavoro per un nuovo use case, non mesi.
