
Con una pipeline in cinque stadi: acquisizione → OCR e layout → estrazione LLM guidata da schema → validazione con revisione umana sui casi incerti → scrittura automatica nel gestionale via API. Non caricando i PDF in un chatbot.
Si integra costruendo una pipeline di Intelligent Document Processing in cinque stadi: acquisizione e classificazione dei documenti; OCR con analisi del layout; estrazione dei campi con un LLM guidato da uno schema, che restituisce dati strutturati e non testo libero; validazione con punteggi di confidenza, controlli aritmetici e revisione umana sui soli casi incerti; scrittura automatica dei dati nel gestionale o nell'ERP via API. È il quinto stadio a produrre il risparmio: un dato estratto ma non scritto nei sistemi ha solo spostato il lavoro manuale, non lo ha eliminato.
La parte controintuitiva è che il modello linguistico è il pezzo meno critico dell'insieme. I progetti che falliscono non falliscono perché l'LLM legge male: falliscono perché nessuno ha definito cosa fare quando la confidenza è bassa, perché i dati estratti restano in un file invece di entrare nel gestionale, o perché la questione della riservatezza dei documenti è stata affrontata a progetto finito. Codebaker, software house di Bologna fondata nel 2019, progetta queste pipeline partendo dai vincoli — volumi, riservatezza, sistemi da alimentare — e sviluppa il prodotto proprietario Data Alchemy, dedicato proprio all'Intelligent Document Processing con LLM.


La differenza fra un esperimento e un sistema di produzione sta tutta qui. Chiedere a un modello «qual è il totale di questa fattura?» produce una risposta in linguaggio naturale, che va poi interpretata da qualcuno e che cambia forma ogni volta. Chiedere invece al modello di restituire un oggetto strutturato con campi definiti in anticipo — numero documento, data, partita IVA del fornitore, righe con quantità e prezzo, imponibile, IVA, totale — produce un dato che un altro software può consumare senza ambiguità. Lo schema fa anche da rete: se un campo obbligatorio manca o ha il tipo sbagliato, l'anomalia emerge subito, prima di arrivare al gestionale. È la stessa disciplina con cui progettiamo le API, applicata all'output di un modello linguistico: si decide il contratto dati prima, e il modello lo rispetta.


I documenti che un'azienda vorrebbe processare automaticamente sono spesso i più sensibili: contratti, fatture con dati di clienti e fornitori, certificati, curriculum, documenti coperti da segreto industriale. La domanda «dove finiscono questi file» va quindi posta all'inizio, perché condiziona l'architettura e non si può rimediare dopo. Le strade sono tre: modelli eseguiti su infrastruttura in cloud europeo con contratti che escludono l'uso dei dati per l'addestramento; modelli eseguiti in locale su hardware aziendale, così i documenti non escono mai dal perimetro; oppure un'architettura mista che invia all'esterno solo ciò che non è sensibile. Progettiamo GDPR by design: minimizzazione di ciò che viene inviato, cancellazione dei file temporanei, log di chi ha visto cosa e opzione di esecuzione locale quando la sensibilità lo richiede.
Ogni stadio ha un compito preciso e un punto di controllo: è quello che rende il sistema affidabile abbastanza da lasciarlo scrivere nel gestionale.

I documenti arrivano da una casella di posta dedicata, da uno scanner, da un'area di caricamento o da un flusso già esistente, e vengono classificati per tipologia: fattura, DDT, ordine, certificato. Nessuno deve cambiare il modo in cui li riceve.

Il documento diventa testo con le coordinate di ogni elemento, così tabelle, colonne e righe restano leggibili come struttura e non come parole sparse. È lo stadio che determina la qualità di tutto ciò che segue.

Al modello si chiede un output strutturato con campi definiti in anticipo, non un testo libero. Così «Tot. imponibile» e «Imponibile totale» finiscono nello stesso campo, senza dover creare un template per ogni fornitore.

Punteggi di confidenza per campo, controlli aritmetici (le righe sommano al totale, l'IVA torna) e riconciliazione con le anagrafiche. Solo i documenti sotto soglia finiscono in una coda di revisione: gli altri passano.

I dati validati entrano nel gestionale, nell'ERP o nel sistema documentale attraverso API, con il documento originale archiviato e collegato al record. È lo stadio che trasforma l'estrazione in tempo risparmiato.

Ogni documento elaborato lascia una traccia: cosa è stato estratto, con quale confidenza, chi ha corretto cosa. È ciò che permette di misurare l'accuratezza nel tempo e di rispondere a un'ispezione o a una contestazione.
Lo stadio 5 si appoggia alle stesse competenze di integrazione fra gestionale e altri software via API: è il motivo per cui un progetto di AI documentale riesce o fallisce più per l'integrazione che per il modello.
Sono spesso confuse fra loro, ma risolvono problemi diversi. Scegliere quella sbagliata è il modo più rapido per spendere bene dei soldi su un problema che non avevi.
| Tecnologia | Cosa fa | Quando è la scelta giusta | Dove si rompe |
|---|---|---|---|
| OCR | Converte immagini e scansioni in testo | Sempre, come stadio di base sotto tutto il resto | Da solo non capisce il significato: ti dà parole, non campi |
| Estrazione a template | Associa posizioni fisse della pagina a campi | Pochi documenti sempre identici, layout stabile nel tempo | Appena un fornitore cambia layout: serve un template per ciascuno |
| LLM con output strutturato | Legge il documento e restituisce i campi richiesti dallo schema | Molti fornitori, layout variabili, sinonimi e lingue diverse | Senza validazione e confidenza: gli errori passano silenziosamente |
| RAG | Risponde a domande cercando nei tuoi documenti | Contratti, capitolati, manuali, normative: consultazione | Non è pensato per estrarre campi da alimentare in un gestionale |
| Chatbot generico | Conversa su un documento caricato a mano | Uso individuale occasionale, esplorazione | Nessuna automazione, nessuna tracciabilità, nessuna scrittura nei sistemi |
In una pipeline di produzione OCR e LLM lavorano insieme, i template restano riservati ai pochi documenti davvero stabili e il RAG viene aggiunto quando serve consultare, non estrarre. Il quadro completo sull'uso dell'AI in azienda è nella pagina intelligenza artificiale per aziende e nella consulenza AI.
I candidati migliori hanno tre caratteristiche: alto volume, struttura ricorrente ma non identica, e un dato che oggi qualcuno ribatte a mano in un sistema.
| Documento | Campi tipicamente estratti | Dove finiscono i dati | Difficoltà |
|---|---|---|---|
| Fattura passiva | Fornitore, P.IVA, numero, data, righe, imponibile, IVA, totale, scadenza | Ciclo passivo del gestionale | Media: molti fornitori, molti layout |
| DDT e bolle in ingresso | Mittente, numero, data, articoli, quantità, riferimento ordine | Carico di magazzino | Media |
| Ordini cliente via email o PDF | Cliente, codici articolo, quantità, prezzi, data richiesta | Ordini nel gestionale | Media: richiede il match sul catalogo |
| Certificati di qualità | Lotto, parametri misurati, esito, ente, validità | Sistema qualità e tracciabilità di lotto | Bassa se il formato è ricorrente |
| Note spese e scontrini | Data, esercente, importo, IVA, categoria di spesa | Amministrazione e rimborsi | Alta sulla qualità immagine, bassa sui campi |
| Contratti e capitolati | Parti, durata, scadenze, clausole rilevanti | Scadenzario e consultazione (qui serve anche il RAG) | Alta: testo lungo e non tabellare |
| Curriculum | Anagrafica, esperienze, competenze, titoli | Sistema di selezione | Bassa tecnicamente, alta sul piano GDPR |
Un progetto di AI documentale è per il 20% un problema di modelli e per l'80% un problema di integrazione, dati e processi: le tre cose che facciamo da sempre. Siamo una software house di Bologna fondata nel 2019, con progetti in produzione da anni proprio sulla parte difficile, cioè far entrare dati corretti dentro sistemi che esistono già.
Software proprietario di Intelligent Document Processing: estrae dati strutturati dai documenti aziendali combinando OCR e LLM. Quando il tuo caso rientra nel suo perimetro, si parte da qui invece che da zero.
Lo stadio più difficile di una pipeline documentale è l'ultimo. Qui alimentiamo un gestionale AS400 in tempo reale: 300.000+ ordini l'anno, 5.000+ clienti al giorno.
Automazione di processi su dati di oltre 2.000 dipendenti, integrata con SAP, HR, Active Directory e Office 365: -95% di attività manuali di onboarding IT.
Il nostro sistema di autenticazione con crittografia distribuita e conformità GDPR nativa, lanciato nel 2024: la stessa attenzione ai dati che portiamo nei progetti documentali.
Approfondimenti utili prima di decidere: quale hardware serve per far girare LLM in locale, ChatGPT in azienda e sicurezza dei dati e sicurezza dei dati nei progetti AI.
Si integra costruendo una pipeline di Intelligent Document Processing in cinque stadi, non caricando i PDF in un chatbot. Primo stadio, acquisizione: i documenti arrivano da una casella di posta, da uno scanner o da un'area di caricamento e vengono classificati per tipologia. Secondo, OCR e analisi del layout: il documento diventa testo con le coordinate di ogni elemento, così tabelle e colonne restano leggibili. Terzo, estrazione con LLM guidata da uno schema: al modello si chiede di restituire un output strutturato con campi definiti in anticipo (numero documento, data, partita IVA, righe, imponibile), non un testo libero. Quarto, validazione: ogni campo riceve un punteggio di confidenza, si applicano i controlli aritmetici e la riconciliazione con le anagrafiche, e solo i documenti incerti finiscono in una coda di revisione umana. Quinto, scrittura: i dati validati entrano nel gestionale o nell'ERP via API, con il documento originale archiviato e collegato. È il quinto stadio a produrre il risparmio: un dato estratto ma non scritto nei sistemi ha solo spostato il lavoro manuale.
L'OCR converte un'immagine in testo, ma non sa cosa significa: da solo non ti dà il totale della fattura, ti dà tutte le parole della pagina. I sistemi a template associano posizioni fisse a campi: funzionano molto bene su documenti sempre identici e si rompono appena un fornitore cambia layout, il che nelle aziende con centinaia di fornitori è la norma. Gli LLM leggono il documento come farebbe una persona: capiscono che «Tot. imponibile» e «Imponibile totale» sono la stessa cosa e trovano il dato anche se ha cambiato posizione, senza bisogno di un template per ogni fornitore. Il RAG è un'altra cosa ancora: non serve a estrarre campi da un documento ma a rispondere a domande sulla base di una raccolta documentale, ed è la scelta giusta per contratti, capitolati e manuali. Nella pratica una pipeline solida usa OCR e LLM insieme, e riserva i template ai pochi documenti davvero stabili.
L'accuratezza va misurata, non promessa: il numero corretto dipende dal tipo di documento, dalla qualità delle scansioni e da quanti fornitori diversi ci sono, e chiunque dichiari una percentuale prima di aver visto i tuoi documenti sta tirando a indovinare. Il metodo serio è costruire un insieme di documenti di riferimento già verificati a mano, misurare l'estrazione su quelli campo per campo e ripetere la misura a ogni modifica. In produzione l'accuratezza si governa con quattro meccanismi: punteggi di confidenza per campo, controlli aritmetici (le righe devono sommare al totale, l'IVA deve tornare), riconciliazione con le anagrafiche esistenti e una coda di revisione umana per i soli documenti sotto soglia. L'obiettivo non è l'infallibilità del modello, è che nessun errore arrivi nei sistemi senza essere intercettato.
Dipende da come è progettata la soluzione, ed è una decisione da prendere all'inizio e non alla fine. Le opzioni sono tre: modelli eseguiti su infrastruttura in cloud europeo con contratti che escludono l'uso dei dati per l'addestramento; modelli eseguiti in locale, su hardware dell'azienda, così i documenti non escono mai dal perimetro aziendale; oppure un'architettura mista che manda al modello esterno solo i documenti non sensibili. Progettiamo le soluzioni GDPR by design: minimizzazione dei dati inviati, cancellazione dei documenti temporanei, tracciabilità di chi ha visto cosa e possibilità di eseguire tutto in locale quando la sensibilità lo richiede. Se tratti dati particolari o documenti coperti da segreto industriale, l'esecuzione locale è la strada da valutare per prima.
I candidati migliori hanno tre caratteristiche: alto volume, struttura ricorrente ma non identica, e un dato che oggi qualcuno ribatte a mano in un sistema. In pratica: fatture passive da fornitori diversi, documenti di trasporto e bolle in ingresso, ordini cliente ricevuti via email o PDF, conferme d'ordine, certificati di qualità e schede tecniche, documenti di trasporto doganali, note spese e curriculum. Sono tutti casi in cui il lavoro non è intellettuale ma di trascrizione, e in cui l'errore umano da stanchezza è più probabile di quello del modello. Non ha invece senso partire da documenti rari o da quelli in cui la decisione è più importante del dato: lì l'AI può aiutare a leggere, non a decidere.
Dipende da riservatezza, volumi e costi. Il cloud conviene quando i documenti non sono particolarmente sensibili e i volumi sono variabili: non c'è hardware da comprare e si paga a consumo. L'esecuzione locale conviene quando i documenti non possono uscire dall'azienda per ragioni di riservatezza o contrattuali, quando i volumi sono alti e costanti (a quel punto l'hardware si ammortizza) o quando serve la garanzia che nessun dato venga usato per addestrare modelli di terzi. Abbiamo scritto una guida dedicata all'hardware necessario per far girare LLM in locale, con le configurazioni realistiche per un'azienda.
Un progetto pilota su una singola tipologia documentale, con integrazione semplice verso il gestionale, rientra tipicamente nella fascia 5.000-15.000 €; una soluzione su più tipologie documentali con validazione, interfaccia di revisione e integrazione completa si colloca nella fascia 15.000-50.000 €; le piattaforme documentali articolate su più flussi e sedi superano i 50.000 €. A questo si aggiunge il costo di esecuzione dei modelli, a consumo nel cloud o come hardware se si sceglie l'esecuzione locale. Il conto che conta però è un altro: quante ore alla settimana la tua azienda spende oggi a ribattere dati da documenti, e quanto vale eliminarne la maggior parte.
Da una sola tipologia documentale ad alto volume, misurando prima quanto tempo costa oggi. Il percorso che consigliamo è: scegliere il documento più frequente (spesso la fattura passiva o il DDT in ingresso), raccogliere un centinaio di esemplari reali comprensivi dei casi brutti, definire i campi da estrarre e le regole di validazione, misurare l'accuratezza su quell'insieme e solo allora collegare la scrittura automatica nel gestionale. Un pilota così è circoscritto, misurabile e non richiede di cambiare nulla nel modo in cui l'azienda lavora: gli operatori smettono semplicemente di digitare e iniziano a validare le eccezioni.
Data Alchemy è il prodotto proprietario di Codebaker per l'Intelligent Document Processing: estrae dati strutturati dai documenti aziendali combinando OCR e LLM e restituisce output pronto per essere scritto nei sistemi gestionali. Nasce dall'esperienza sui progetti dei clienti e viene usato come base quando la soluzione richiesta rientra nel suo perimetro, riducendo tempi e costi rispetto a uno sviluppo da zero; quando invece il flusso documentale è particolare, sviluppiamo una pipeline su misura. In entrambi i casi restano validi i nostri principi: dati trattati GDPR by design e integrazione con i sistemi che l'azienda già usa.
Dicci quale documento arriva più spesso in azienda e chi lo ribatte a mano oggi. Con un centinaio di esemplari reali possiamo misurare l'accuratezza sul tuo caso concreto e dirti cosa è automatizzabile davvero, prima che tu spenda un euro. L'analisi preliminare e il preventivo sono gratuiti.