Document AI: quando le API dei modelli generalisti non bastano

Oggi creare un prototipo per estrarre dati da PDF, scansioni o immagini utilizzando l'intelligenza artificiale è relativamente semplice.

Con le API di modelli generalisti come OpenAI, Anthropic, Google o altri provider è possibile inviare, ad esempio, una fattura, specificare quali informazioni recuperare e ottenere rapidamente un output strutturato:

• numero della fattura;
• ragione sociale del fornitore;
• data;
• imponibile;
• IVA;
• totale;
• IBAN;
• valuta.

Su un numero limitato di documenti, e soprattutto quando i file sono abbastanza omogenei, i risultati possono essere molto convincenti.

La demo funziona.
L'output JSON arriva correttamente.
I dati sembrano precisi.

A quel punto è naturale pensare che il progetto di automazione dell'estrazione documentale sia quasi concluso.

In realtà è proprio in quel momento che inizia la parte più complessa.

Perché esiste una grande differenza tra far leggere un documento a un modello AI e costruire un processo di Document AI affidabile, controllabile e utilizzabile ogni giorno in produzione.

Dal prototipo di estrazione dati alla produzione

Durante una Proof of Concept, il flusso può essere estremamente semplice.

Il team seleziona alcuni documenti, prepara un prompt, definisce lo schema dell'output e verifica manualmente i risultati.

Questo approccio permette di sperimentare rapidamente e rappresenta uno dei grandi vantaggi dei modelli AI generalisti.

Il problema emerge quando il sistema deve iniziare a elaborare documenti reali ogni giorno.

Non più dieci fatture selezionate manualmente, ma migliaia o centinaia di migliaia di file provenienti da clienti, fornitori, intermediari o sistemi differenti.

A quel punto entrano in gioco variabili molto più difficili da controllare:

• PDF nativi e documenti scansionati;
• fotografie scattate con smartphone;
• immagini inclinate o sfocate;
• layout differenti;
• documenti multipagina;
• tabelle che continuano su più pagine;
• campi assenti;
• valori poco leggibili;
• informazioni contraddittorie;
• nuove versioni dello stesso documento;
• nuove tipologie documentali mai viste prima.

Una fattura di un fornitore può essere completamente diversa da quella di un altro.

Una busta paga può cambiare struttura in base al software utilizzato.

Una bolletta luce o gas può presentare POD, PDR, consumi e dati contrattuali in posizioni differenti.

Un documento d'identità fotografato da smartphone può essere parzialmente coperto, inclinato o illuminato male.

Il sistema deve continuare a funzionare anche in questi casi.

Ed è qui che l'estrazione tramite una semplice chiamata API non è più sufficiente.

Una risposta plausibile non è ancora un dato affidabile

I modelli AI generalisti sono estremamente efficaci nel comprendere il contenuto di un documento.

Ma in un processo aziendale non basta ottenere una risposta plausibile.

Serve ottenere un dato utilizzabile.

Supponiamo, ad esempio, che da una fattura venga estratto:

Totale: 12.450 €

Per una persona che sta semplicemente leggendo il documento, questa informazione può essere sufficiente.

Un sistema contabile deve invece rispondere a molte altre domande.

Quel valore rappresenta davvero il totale finale?

La valuta è effettivamente EUR?

Il separatore decimale è stato interpretato correttamente?

Imponibile, IVA e totale sono coerenti?

Il documento è realmente una fattura oppure è una nota di credito?

Sono presenti più totali all'interno della pagina?

Esistono valori simili che il modello potrebbe aver confuso?

Se il dato non supera questi controlli, il sistema deve sapere come comportarsi.

In altre parole:

estrarre un valore dal documento non significa ancora aver prodotto un dato affidabile per un processo aziendale.

Prima di essere inviato a un ERP, CRM, gestionale o motore decisionale, il risultato deve essere strutturato, normalizzato, validato e verificato.

Il modello AI è soltanto una parte della soluzione

In un sistema di Document AI enterprise, il modello utilizzato per interpretare il documento è soltanto uno dei componenti della pipeline.

Un processo completo può includere diverse fasi.

1. Acquisizione del documento

I file possono arrivare da:

• portali web;
• app mobile;
• email;
• API;
• sistemi gestionali;
• CRM;
• workflow interni;
• piattaforme di onboarding.

Il sistema deve acquisirli, controllarne il formato e prepararli all'elaborazione.

2. Classificazione automatica

Prima di estrarre i dati è spesso necessario capire quale documento è stato ricevuto.

Per esempio:

• carta d'identità;
• passaporto;
• busta paga;
• CU;
• fattura;
• bolletta energia;
• contratto;
• polizza assicurativa.

La classificazione determina quale pipeline utilizzare e quali informazioni cercare.

3. Estrazione dei dati

A questo punto intervengono OCR, modelli multimodali, VLM e altre tecnologie di Document AI.

Il sistema individua e struttura le informazioni richieste.

4. Normalizzazione

Il dato estratto deve essere trasformato in un formato coerente.

Una data come:

12 agosto 2026

può diventare:

2026-08-12

Allo stesso modo possono essere normalizzati importi, indirizzi, codici fiscali, IBAN, numeri di documento e altri valori.

5. Validazione

Questa è una delle differenze principali tra una semplice estrazione AI e una piattaforma dedicata.

Sul dato possono essere applicate:

• regole di business;
• controlli sintattici;
• verifiche matematiche;
• controlli incrociati;
• verifiche di coerenza tra più campi;
• controlli rispetto a dati già presenti nei sistemi aziendali.

Un codice fiscale, ad esempio, può essere verificato formalmente.

Un totale di fattura può essere confrontato con imponibile e IVA.

Un IBAN può essere sottoposto a controlli strutturali.

6. Gestione delle eccezioni

Non tutti i documenti possono essere elaborati automaticamente.

Quando un valore è ambiguo oppure una validazione fallisce, il sistema deve poter indirizzare il documento verso una verifica manuale.

È il principio del human-in-the-loop.

L'operatore interviene soltanto sui casi che richiedono realmente attenzione, mentre la maggior parte dei documenti continua a essere elaborata automaticamente.

7. Integrazione

Il dato finale deve essere trasferito verso i sistemi aziendali.

Per esempio:

• ERP;
• CRM;
• software assicurativi;
• piattaforme di credito;
• sistemi di onboarding;
• software amministrativi;
• data warehouse.

Il sistema deve inoltre gestire timeout, errori, duplicati e tentativi di reinvio.

8. Monitoraggio

Infine è necessario sapere cosa sta succedendo in produzione.

Per esempio:

• quanti documenti vengono elaborati;
• quali tipologie generano più errori;
• quali campi richiedono più revisioni;
• quanto tempo richiede l'elaborazione;
• quanti documenti finiscono in verifica manuale.

Senza monitoraggio, un deterioramento della qualità può passare inosservato per settimane.

Il problema degli errori su grandi volumi

Nei prototipi gli errori sporadici possono sembrare poco rilevanti.

Su larga scala diventano invece un problema operativo.

Immaginiamo un sistema che elabori 100.000 documenti al mese.

Anche una percentuale apparentemente ridotta di casi problematici può tradursi in centinaia o migliaia di documenti da verificare.

E non tutti gli errori hanno lo stesso peso.

Interpretare male un campo descrittivo può avere conseguenze limitate.

Estrarre erroneamente:

• un importo;
• un IBAN;
• un codice fiscale;
• un POD;
• un PDR;
• una data di scadenza;
• un numero di documento;

può invece influire direttamente su un processo operativo.

Per questo una soluzione produttiva deve essere progettata partendo da un presupposto fondamentale:

il modello può sbagliare.

L'obiettivo non è quindi eliminare completamente ogni errore, ma costruire un sistema capace di riconoscerlo, intercettarlo e gestirlo.

L'accuratezza deve essere misurata sui singoli campi

Chiedersi semplicemente:

“Il modello riesce a leggere questo PDF?”

non è sufficiente.

La qualità di un sistema di estrazione dati documentale dovrebbe essere valutata campo per campo.

Per esempio, su una bolletta energetica può essere utile misurare separatamente l'accuratezza di:

• POD;
• PDR;
• codice fiscale;
• indirizzo di fornitura;
• intestatario;
• potenza impegnata;
• consumi;
• numero cliente.

Un sistema potrebbe ottenere un'accuratezza media elevata ma avere prestazioni inferiori proprio su uno dei campi più importanti per il processo.

La valutazione deve quindi essere effettuata sui documenti realmente ricevuti dall'azienda, non soltanto su file selezionati per una demo.

Dataset di test e regression testing

C'è inoltre un altro elemento spesso sottovalutato.

I sistemi AI cambiano.

Può cambiare:

• il modello;
• la versione del modello;
• il prompt;
• la pipeline OCR;
• una configurazione;
• una regola di validazione;
• il preprocessing delle immagini.

Una modifica può migliorare alcuni documenti e peggiorarne altri.

Per questo una piattaforma Document AI deve poter disporre di dataset di test rappresentativi e procedure di regression testing.

Prima di introdurre una nuova configurazione in produzione è necessario verificare che la modifica non riduca la qualità sui casi già gestiti correttamente.

Il versionamento diventa quindi parte integrante del processo.

Il costo non è soltanto quello delle API

Quando si confronta una soluzione costruita internamente con una piattaforma Document AI, uno degli errori più comuni consiste nel considerare soltanto il costo delle chiamate al modello.

Il costo di inferenza è certamente una variabile importante.

Ma il Total Cost of Ownership comprende molto altro.

Bisogna sviluppare e mantenere:

• acquisizione dei documenti;
• preprocessing;
• classificazione;
• estrazione;
• validazioni;
• gestione degli errori;
• interfacce di revisione;
• logging;
• monitoraggio;
• integrazioni;
• sistemi di retry;
• dataset di test;
• regression testing;
• procedure di aggiornamento.

A questo si aggiunge il tempo dei team tecnici necessario per identificare anomalie e mantenere affidabile il sistema.

La domanda corretta quindi non è soltanto:

“Quanto costa elaborare una pagina con l'API?”

ma:

“Quanto costa mantenere affidabile l'intero processo documentale?”

Governance e controllo del dato

La questione diventa ancora più importante quando vengono elaborati documenti contenenti dati personali o informazioni aziendali sensibili.

Pensiamo a:

• documenti d'identità;
• passaporti;
• buste paga;
• contratti;
• documentazione finanziaria;
• pratiche assicurative;
• documentazione sanitaria.

In questi scenari la qualità dell'estrazione rappresenta soltanto una parte del problema.

L'azienda deve poter controllare aspetti come:

• accesso ai documenti;
• autorizzazioni degli utenti;
• audit trail;
• segregazione degli ambienti;
• conservazione dei dati;
• localizzazione dei dati;
• logging delle operazioni.

Le caratteristiche specifiche dipendono naturalmente dal provider, dal servizio utilizzato, dalla configurazione scelta e dagli accordi contrattuali.

Ma in un progetto enterprise questi aspetti devono essere analizzati insieme alla qualità del modello.

API generaliste o piattaforma Document AI?

La risposta non è necessariamente scegliere una tecnologia ed escludere l'altra.

Le API dei modelli generalisti sono estremamente flessibili.

Sono particolarmente utili quando bisogna:

• comprendere un documento;
• riassumere un contratto;
• individuare una clausola;
• confrontare documenti;
• rispondere a domande sul contenuto;
• interpretare testo non strutturato;
• sperimentare rapidamente nuovi casi d'uso.

Quando invece l'obiettivo è trasformare documenti in dati strutturati utilizzati automaticamente da un processo aziendale, le esigenze cambiano.

È qui che entra in gioco l'Intelligent Document Processing (IDP).

Una piattaforma verticale di Document AI è progettata non soltanto per capire un documento, ma per governare l'intero ciclo di elaborazione.

Il ruolo di myBiros

In myBiros, il valore non risiede semplicemente nel modello utilizzato per estrarre una determinata informazione.

La piattaforma combina differenti componenti all'interno di un processo progettato per l'elaborazione documentale:

• tecnologie OCR e AI per documenti complessi;
• gestione di layout differenti;
• estrazione da tabelle e documenti multipagina;
• classificazione documentale;
• strutturazione e normalizzazione dei dati;
• workflow di validazione;
• regole di business;
• gestione delle eccezioni;
• revisione human-in-the-loop;
• integrazione tramite API con i sistemi aziendali;
• strumenti di controllo e governance del dato.

L'obiettivo non è semplicemente leggere un documento.

È trasformare quel documento in dati affidabili e utilizzabili automaticamente dal processo aziendale.

Modelli generalisti e Document AI possono convivere

Le due tecnologie non devono necessariamente essere considerate concorrenti.

In molti progetti possono essere utilizzate insieme.

Una piattaforma specializzata può occuparsi delle attività ripetitive e strutturate:

documento → classificazione → estrazione → validazione → dato strutturato → sistema aziendale

Un modello generalista può invece intervenire sulle attività che richiedono maggiore flessibilità.

Per esempio può:

• generare una sintesi del documento;
• spiegare un'anomalia a un operatore;
• confrontare due contratti;
• interpretare contenuti non standardizzati;
• supportare la revisione di casi complessi.

Il modello diventa quindi uno dei componenti della soluzione.

La piattaforma si occupa di governarlo all'interno di un processo controllato.

Dal “document understanding” al processo documentale

L'evoluzione più importante avviene proprio qui.

Un prototipo dimostra che l'AI è capace di comprendere il documento.

Un sistema di Document AI deve dimostrare qualcosa di diverso:

che quella capacità può essere utilizzata in modo affidabile ogni giorno all'interno di un processo aziendale.

La differenza non è soltanto tecnologica.

È soprattutto architetturale e operativa.

Significa passare da:

“Il modello riesce a trovare questo dato?”

a:

“Possiamo utilizzare automaticamente questo dato all'interno del nostro processo?”

È questa la distanza tra una demo convincente e un sistema realmente pronto per la produzione.

Conclusioni

Le API di OpenAI, Anthropic, Google e degli altri modelli generalisti hanno reso molto più semplice sperimentare con i documenti.

Sono strumenti estremamente potenti e possono rappresentare un componente importante di molti sistemi Document AI.

Ma quando un'azienda deve elaborare documenti in modo continuativo, integrare i risultati nei propri sistemi e mantenere sotto controllo qualità, eccezioni e governance, il modello da solo non rappresenta l'intera soluzione.

Servono pipeline, validazioni, monitoraggio, integrazioni e procedure per gestire i casi in cui l'AI non produce il risultato atteso.

È su questo livello che una piattaforma verticale di Intelligent Document Processing crea valore.

Non semplicemente trasformando un PDF in una risposta.

Ma trasformando documenti reali in dati strutturati, verificati e pronti per alimentare processi aziendali reali.

Vuoi capire come automatizzare l'estrazione dei dati dai documenti della tua azienda?

Scopri come myBiros può integrarsi nei tuoi processi di acquisizione, controllo ed elaborazione documentale.

Contattaci o richiedi una demo gratuita

‍

FAQ

Le API di OpenAI possono estrarre dati da PDF e documenti?

Sì. I modelli multimodali possono essere utilizzati per interpretare documenti e restituire informazioni strutturate. In un processo aziendale su larga scala, però, all'estrazione devono essere affiancati controlli, validazioni, gestione delle eccezioni, monitoraggio e integrazioni.

Qual è la differenza tra un LLM e una piattaforma Document AI?

Un LLM è un modello capace di interpretare e generare informazioni. Una piattaforma Document AI integra invece modelli, OCR, classificazione, estrazione, validazioni, workflow e sistemi di controllo per trasformare i documenti in dati utilizzabili nei processi aziendali.

Che cos'è l'Intelligent Document Processing?

L'Intelligent Document Processing, o IDP, è l'utilizzo combinato di OCR, intelligenza artificiale, machine learning e workflow software per classificare documenti, estrarre informazioni, validarle e trasferirle automaticamente verso altri sistemi.

Quando conviene utilizzare una soluzione Document AI dedicata?

Una piattaforma dedicata diventa particolarmente utile quando vengono elaborati grandi volumi di documenti, esistono molti layout differenti, i dati devono essere validati oppure devono alimentare automaticamente ERP, CRM e altri processi aziendali.

Modelli generalisti e piattaforme IDP possono essere utilizzati insieme?

Sì. Una piattaforma IDP può gestire l'elaborazione strutturata, le validazioni e le integrazioni, mentre un modello generalista può essere utilizzato per sintesi, interpretazione di casi complessi, confronto di documenti o supporto agli operatori.

‍

‍