AI vs OCR per l'Automazione dei Documenti Aziendali: Il Confronto Definitivo
L'OCR esiste da 30 anni. L'AI document understanding è esplosa negli ultimi 3. Qual è la differenza reale? Quando ha senso usare l'una o l'altra? E perché molti sistemi "AI" sono in realtà ancora OCR con qualche regola in più?
Come funziona l'OCR tradizionale
L'OCR (Optical Character Recognition) è una tecnologia di riconoscimento del testo. Preso un'immagine, identifica i caratteri e li trascrive in testo. Il processo tipico:
- Pre-processing immagine (binarizzazione, deskewing, denoising)
- Segmentazione: identificazione di righe e caratteri
- Riconoscimento carattere per carattere (LSTM o CNN)
- Post-processing: correzione spell, formazione parole
- Output: testo grezzo senza struttura semantica
Il problema fondamentale è nell'ultimo punto: l'OCR produce testo, non comprensione. Sa che il documento contiene "150,00" ma non sa se è il totale, l'imponibile, l'IVA, o la quantità di un articolo.
Per estrarre dati strutturati con l'OCR, serve uno strato aggiuntivo di regole: "il campo totale si trova sempre in basso a destra", "l'IVA è sempre preceduta dalla parola 'IVA'". Queste regole funzionano bene per template fissi, ma si rompono non appena cambia il layout.
Come funziona un Vision Language Model
Un VLM come Qwen 2.5-VL non "legge" il documento carattere per carattere. Lo vede come lo vede un umano: come un'immagine con struttura visiva, colori, disposizione degli elementi, relazioni spaziali tra i campi.
Il processo:
- Il documento viene convertito in immagine
- L'immagine viene codificata in token visivi (patch dell'immagine)
- Il modello integra la comprensione visiva con la conoscenza linguistica
- Riceve un prompt: "Estrai il totale imponibile, l'IVA, il totale della fattura"
- Produce un JSON strutturato basato sulla comprensione del documento
Il VLM sa che "150,00" accanto a "22%" e preceduto da "IVA" è l'importo dell'IVA. Sa perché ha imparato da milioni di documenti finanziari come è strutturata una fattura. Non ha bisogno di regole esplicite per ogni template.
Confronto su 16 criteri
| Criterio | OCR + Regole | AI (VLM) |
|---|---|---|
| Layout variabile (stesso tipo doc) | ❌ Fragile | ✅ Robusto |
| Nuovo fornitore con layout diverso | ❌ Richiede nuove regole | ✅ Funziona subito |
| Scansioni di bassa qualità | ⚠️ Problematico | ⚠️ Degrada ma funziona |
| Documenti multi-lingua | ❌ Richiede modello specifico | ✅ Nativamente multilingue |
| Tabelle complesse | ❌ Molto difficile | ✅ Gestito bene |
| Testo scritto a mano | ❌ Quasi impossibile | ⚠️ Dipende dalla qualità |
| Comprensione contesto semantico | ❌ Zero | ✅ Alta |
| Velocità elaborazione | ✅ Molto veloce (<1s) | ⚠️ 5-25 secondi |
| Costo infrastruttura | ✅ Basso (CPU) | ⚠️ GPU richiesta |
| Manutenzione template | ❌ Alta (ogni nuovo layout) | ✅ Quasi nulla |
| Nuovo tipo documento | ❌ Settimane di sviluppo | ✅ Ore (modifica prompt) |
| Classificazione documento | ❌ Regole separate | ✅ Integrata |
| Explainability | ✅ Alta (regole trasparenti) | ⚠️ Black box |
| Privacy (on-premise) | ✅ Sì (Tesseract) | ✅ Sì (modelli open) |
| Accuratezza fatture IT standard | ⚠️ 85-92% (layout fisso) | ✅ 94-98% |
| Scalabilità senza manutenzione | ❌ Lineare con numero fornitori | ✅ Costante |
Benchmark su documenti italiani reali
Test condotti su 500 documenti aziendali italiani (fatture, DDT, ordini), dataset misto qualità alta/bassa:
| Scenario documento | Tesseract OCR + Regex | Qwen 2.5-VL 7B |
|---|---|---|
| Fattura digitale, layout standard | 91% | 97% |
| Fattura digitale, layout variabile | 63% | 95% |
| Fattura scansionata, alta qualità | 84% | 93% |
| Fattura scansionata, bassa qualità | 51% | 82% |
| DDT con tabelle complesse | 58% | 91% |
| Nuovo fornitore mai visto | 22% | 94% |
Il dato più significativo è la riga "Nuovo fornitore mai visto": l'OCR con regole statiche crolla al 22% perché le regole erano state create per i layout dei fornitori esistenti. Il VLM mantiene il 94% perché ha imparato a leggere le fatture in generale, non solo quelle di specifici fornitori.
La trappola della manutenzione OCR
Il costo nascosto dell'OCR con regole è la manutenzione. Ogni volta che:
- Un fornitore cambia il software gestionale e il layout della fattura
- Arriva un nuovo fornitore con un layout diverso
- Un fornitore inizia a inviare PDF firmati digitalmente con layer aggiuntivi
- Cambia la normativa FatturaPA e il formato dell'XML
...qualcuno deve aggiornare le regole. In un'azienda con 50 fornitori attivi, questo può essere un lavoro a tempo pieno.
Con un sistema AI, l'aggiornamento delle regole diventa rarissimo: il modello gestisce autonomamente la variabilità dei layout.
Quando l'OCR è ancora la scelta giusta
L'OCR non è morto. Ci sono scenari in cui è ancora la scelta migliore:
- Documenti con layout fisso e immutabile: Moduli standardizzati con posizioni fisse dei campi. Es. modulo F24, modello 730, bollettini postali. Qui le regole OCR funzionano perfettamente e costano meno.
- Volumi molto alti con latenza critica: Se hai bisogno di elaborare 100.000 documenti/ora in real-time, l'OCR è 50-100x più veloce dell'AI. Per batch notturni con latenza non critica, l'AI è preferibile.
- Budget hardware limitato: L'OCR gira su CPU standard. Il VLM ha bisogno di GPU. Per PMI molto piccole con volume <50 doc/mese, l'OCR può ancora essere conveniente.
- Documenti già strutturati: Se il documento è già un XML (es. FatturaPA XML) o un CSV, non serve né OCR né AI — si parsa direttamente il file strutturato.
💡 L'approccio ibrido
Molti sistemi moderni usano un approccio ibrido: OCR per l'estrazione del testo grezzo (veloce, economico) + AI per la comprensione semantica e la strutturazione dei dati. L'OCR fornisce una "pre-lettura" che aiuta l'AI a focalizzarsi sulle zone rilevanti del documento.
DataUnchain usa Vision AI puro per massimizzare l'accuratezza su qualsiasi layout di documento.
Scopri l'architettura →