Logo Codebaker
EN

Come Integrare l'Intelligenza Artificiale e gli LLM in Azienda per Estrarre Dati dai Documenti

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.

Come si integrano AI e LLM per estrarre dati dai documenti

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.

estrazione-campi-strutturati-da-documenti-con-llm

yellow dot
output strutturato

Campi, non risposte

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.

gdpr-e-riservatezza-nei-progetti-di-document-processing

yellow dot
riservatezza

Dove girano i tuoi documenti

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.

La pipeline in cinque stadi

Ogni stadio ha un compito preciso e un punto di controllo: è quello che rende il sistema affidabile abbastanza da lasciarlo scrivere nel gestionale.

yellow dot

1. Acquisizione e classificazione

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.

yellow dot

2. OCR e analisi del layout

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.

yellow dot

3. Estrazione con LLM guidata da schema

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.

yellow dot

4. Validazione e revisione umana

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.

yellow dot

5. Scrittura nel gestionale via API

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.

yellow dot

Trasversale: misura e tracciabilità

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.

OCR, template, LLM o RAG: quale tecnologia per quale problema

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.

TecnologiaCosa faQuando è la scelta giustaDove si rompe
OCRConverte immagini e scansioni in testoSempre, come stadio di base sotto tutto il restoDa solo non capisce il significato: ti dà parole, non campi
Estrazione a templateAssocia posizioni fisse della pagina a campiPochi documenti sempre identici, layout stabile nel tempoAppena un fornitore cambia layout: serve un template per ciascuno
LLM con output strutturatoLegge il documento e restituisce i campi richiesti dallo schemaMolti fornitori, layout variabili, sinonimi e lingue diverseSenza validazione e confidenza: gli errori passano silenziosamente
RAGRisponde a domande cercando nei tuoi documentiContratti, capitolati, manuali, normative: consultazioneNon è pensato per estrarre campi da alimentare in un gestionale
Chatbot genericoConversa su un documento caricato a manoUso individuale occasionale, esplorazioneNessuna 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.

Quali documenti conviene automatizzare per primi

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.

DocumentoCampi tipicamente estrattiDove finiscono i datiDifficoltà
Fattura passivaFornitore, P.IVA, numero, data, righe, imponibile, IVA, totale, scadenzaCiclo passivo del gestionaleMedia: molti fornitori, molti layout
DDT e bolle in ingressoMittente, numero, data, articoli, quantità, riferimento ordineCarico di magazzinoMedia
Ordini cliente via email o PDFCliente, codici articolo, quantità, prezzi, data richiestaOrdini nel gestionaleMedia: richiede il match sul catalogo
Certificati di qualitàLotto, parametri misurati, esito, ente, validitàSistema qualità e tracciabilità di lottoBassa se il formato è ricorrente
Note spese e scontriniData, esercente, importo, IVA, categoria di spesaAmministrazione e rimborsiAlta sulla qualità immagine, bassa sui campi
Contratti e capitolatiParti, durata, scadenze, clausole rilevantiScadenzario e consultazione (qui serve anche il RAG)Alta: testo lungo e non tabellare
CurriculumAnagrafica, esperienze, competenze, titoliSistema di selezioneBassa tecnicamente, alta sul piano GDPR

Un esempio concreto: da una fattura passiva a un record nel gestionale

La domanda che riceviamo più spesso non è «funziona?» ma «che cosa esce, esattamente?». Esce JSON tipizzato, con un livello di confidenza per ogni campo, non testo libero: è questa la differenza fra un esperimento con un chatbot e una pipeline che si può collegare a un ERP. L'LLM non viene lasciato libero di rispondere come vuole: gli si impone lo schema dei campi attesi e si valida l'output contro quello schema prima di scriverlo da qualche parte.

{
  "tipoDocumento": "fattura_acquisto",
  "fornitore": {
    "ragioneSociale": { "valore": "Rossi Componenti Srl", "confidenza": 0.99 },
    "partitaIva":     { "valore": "01234567890",         "confidenza": 0.99,
                        "verifica": "checksum_ok" }
  },
  "numeroDocumento": { "valore": "2026/A/1184", "confidenza": 0.97 },
  "dataDocumento":   { "valore": "2026-09-03",  "confidenza": 0.98 },
  "righe": [
    { "descrizione": "Guarnizione OR 4x2 NBR", "quantita": 500,
      "prezzoUnitario": 0.34, "importo": 170.00, "confidenza": 0.94 },
    { "descrizione": "Trasporto",              "quantita": 1,
      "prezzoUnitario": 18.00, "importo": 18.00, "confidenza": 0.88 }
  ],
  "imponibile": { "valore": 188.00, "confidenza": 0.96 },
  "iva":        { "valore":  41.36, "confidenza": 0.96 },
  "totale":     { "valore": 229.36, "confidenza": 0.96 },
  "controlli": {
    "sommaRigheUgualeImponibile": true,   // 170.00 + 18.00 = 188.00
    "ivaCoerenteConAliquota": true,       // 188.00 x 22% = 41.36
    "fornitoreTrovatoInAnagrafica": true
  },
  "esito": "auto"                          // auto | revisione | scarto
}

Il blocco controlli è la parte che nessun modello fornisce da solo e che fa la differenza in produzione: sono verifiche deterministiche scritte da noi, non probabilistiche. La somma delle righe deve tornare con l'imponibile, l'IVA deve essere coerente con l'aliquota, la partita IVA deve superare il controllo di checksum, il fornitore deve esistere in anagrafica. Un documento può avere confidenza altissima su ogni campo ed essere comunque sbagliato: i controlli aritmetici lo intercettano, la confidenza da sola no.

Chi decide se un documento passa: la soglia, non l'opinione

Il campo esito non è deciso da una persona: è il risultato di regole concordate prima, e questa è la tabella che proponiamo come punto di partenza. Le soglie si tarano sul caso reale e sul costo dell'errore, che è diverso per una fattura da 200 € e per un contratto.

SituazioneChe cosa succedeChi interviene
Confidenza alta su tutti i campi obbligatori e controlli aritmetici superatiIl documento viene scritto nel gestionale senza passaggi umaniNessuno
Confidenza bassa su uno o più campiVa in coda di revisione con il campo evidenziato e il ritaglio dell'immagine da cui è stato lettoL'operatore conferma o corregge, in genere in pochi secondi
Confidenza alta ma controllo aritmetico fallitoRevisione obbligatoria: è il caso più insidioso, perché il dato «sembra» giustoOperatore
Fornitore o articolo non presenti in anagraficaSospeso: il documento non entra finché l'anagrafica non è allineataAmministrazione
Documento illeggibile o di tipo non previstoScartato con motivazione esplicita, non «in silenzio»Chi lo ha caricato

Il principio che applichiamo è che l'automazione deve sapere quando non sa. Un sistema che dichiara «non sono sicuro su questo campo» e chiede conferma è più utile di uno che sbaglia con sicurezza: il primo fa risparmiare tempo, il secondo inquina il gestionale e costringe a controllare tutto a mano, azzerando il beneficio.

Come si misura l'accuratezza (e come si fa un pilota onesto)

«Accuratezza del 99%» senza specificare di che cosa non vuol dire niente, ed è la promessa che sentiamo più spesso nelle demo. Prima di firmare qualunque progetto vanno definite tre misure diverse, che possono divergere moltissimo fra loro.

1. Accuratezza per campo

La percentuale di campi estratti correttamente sul totale dei campi. È la misura più generosa e quella che compare nelle brochure: un documento con venti campi e un errore ha un'accuratezza per campo del 95%, ma è un documento sbagliato.

2. Accuratezza per documento

La percentuale di documenti in cui tutti i campi obbligatori sono corretti. È la misura che conta davvero, perché un solo campo sbagliato richiede comunque l'intervento di una persona sull'intero documento.

3. Tasso di lavorazione automatica

La percentuale di documenti che attraversano tutta la pipeline senza che nessuno li tocchi. È l'unico numero che si traduce direttamente in ore risparmiate, ed è sempre più basso degli altri due, perché dipende anche dalle soglie di confidenza scelte. Alzare le soglie riduce gli errori e riduce anche l'automazione: il punto di equilibrio è una decisione aziendale, non tecnica.

4. Costo dell'errore residuo

Quanto costa un errore che passa. Su una fattura di acquisto è una nota di credito e una telefonata; su un documento di trasporto può essere una consegna sbagliata; su un contratto può essere molto peggio. È il numero che determina dove mettere le soglie, e va deciso dall'azienda prima di guardare qualunque demo.

Il pilota che proponiamo

Un centinaio di documenti reali, presi come arrivano davvero — compresi gli scansionati storti, i fax, i PDF fotografati con il telefono e i formati di quel fornitore che manda tutto in un modo suo. Su questi si misura, in cieco, un set di verità stabilito da una persona dell'azienda, e si producono i quattro numeri qui sopra. Se il risultato non giustifica il progetto, lo diciamo: è l'esito più utile che possa avere un pilota, e costa infinitamente meno che scoprirlo dopo il rilascio. La stessa logica del metodo incrementale: un processo pilota, misurato prima e dopo con numeri concordati.

Un avvertimento che diamo sempre: un campione fatto solo di documenti «puliti» produce risultati brillanti e inutilizzabili. La qualità di un progetto documentale si decide sui casi brutti, non su quelli belli.

Piattaforma a canone, servizio cloud, data entry esterno o soluzione su misura

Quattro strade portano allo stesso obiettivo, con conseguenze molto diverse a due o tre anni. Nessuna è sbagliata in assoluto: cambia quale problema state risolvendo.

CriterioPiattaforma IDP a canoneServizio cloud di document AIData entry esternalizzatoPipeline su misura (Codebaker)
AvvioRapido sui documenti standardRapido, ma serve chi la integraImmediatoPilota misurato prima dello sviluppo
Costo nel tempoCanone per documento o per utenteA consumo, cresce coi volumiLineare sui volumi: non scende maiInvestimento iniziale, poi solo manutenzione
Documenti non standardSolo se previsti dal catalogoServe addestramento o post-processingSì, ma a costo pienoSì: lo schema lo definite voi
Regole di validazione aziendaliLimitate a quelle previsteDa costruire a valleDipende dalle istruzioni dateNative: anagrafiche, aliquote, quadrature, fidi
Scrittura nel gestionaleConnettori se esistonoDa sviluppareSpesso manualeÈ il punto di partenza, non un'aggiunta
Dove finiscono i documentiDipende dal fornitoreSul cloud del providerVisti da persone esterne all'aziendaScelta vostra: cloud europeo o modello in locale
Riservatezza e GDPRDa verificare caso per casoContratto del providerResponsabile esterno del trattamentoProgettata: i dati possono non uscire dall'azienda
ProprietàNessuna: si smette, si perde tuttoIl codice di integrazione è vostroNessunaCodice, schema e prompt di proprietà del cliente

La regola pratica: se i vostri documenti sono standard, i volumi modesti e il gestionale ha già un connettore pronto, una piattaforma a canone è la scelta razionale e ve lo diremmo. Se i documenti hanno regole vostre, se il gestionale è datato o se i dati non possono uscire dall'azienda, il canone finisce per pagare una flessibilità che non arriva mai. Le fasce di costo di un progetto su misura sono pubblicate su quanto costa un software su misura.

Chi ha scritto questa guida

Scritta da
Luca VitaliChief Technology Officer (CTO) & CEO
Revisione tecnica
Roberto ArduiniHead of IT & DevOps Engineer
Ultimo aggiornamento
settembre 2026

Codebaker è una software house di Bologna, fondata nel 2019, che sviluppa in-house software su misura, app, API e integrazioni AI. Il codice sorgente resta di proprietà del cliente.

Su cosa si basa

casi reali in produzione · il metodo di lavoro · chi siamo

Perché Codebaker su questo tema

Domande frequenti sull'estrazione dati dai documenti con AI

Come posso integrare l'intelligenza artificiale e gli LLM nei processi della mia azienda per estrarre dati dai documenti?

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.

Che differenza c'è tra OCR, template e LLM per estrarre dati dai documenti?

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.

Quanto è accurata l'estrazione e come si controlla?

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.

I miei documenti finiscono in un servizio esterno? È compatibile con il GDPR?

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.

Quali documenti aziendali si prestano meglio a essere elaborati con l'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. 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.

Serve un LLM eseguito in locale o va bene un servizio cloud?

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.

Quanto costa un progetto di estrazione dati dai documenti con AI?

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 dove conviene iniziare?

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.

Che cos'è Data Alchemy?

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.

Che cosa restituisce esattamente il sistema? Testo o dati strutturati?

Dati strutturati, non testo libero: un JSON tipizzato che rispetta uno schema definito insieme all'azienda, con un livello di confidenza per ogni campo e un blocco di controlli deterministici. Su una fattura di acquisto, per esempio, escono fornitore con partita IVA, numero e data del documento, righe con quantità, prezzo unitario e importo, imponibile, IVA e totale, ciascuno con la propria confidenza; accanto a questi, controlli che non dipendono dal modello: la somma delle righe deve tornare con l'imponibile, l'IVA deve essere coerente con l'aliquota, la partita IVA deve superare il controllo di checksum, il fornitore deve esistere in anagrafica. È questa la differenza fra un esperimento con un chatbot e una pipeline collegabile a un ERP: un documento può avere confidenza altissima su ogni campo ed essere comunque sbagliato, e sono i controlli aritmetici a intercettarlo.

Come si misura davvero l'accuratezza di un progetto di estrazione dati?

Con quattro numeri distinti, perché «accuratezza del 99%» senza dire di che cosa non significa nulla. L'accuratezza per campo è la percentuale di campi corretti sul totale, ed è la misura più generosa: un documento con venti campi e un solo errore risulta al 95%, ma resta un documento sbagliato. L'accuratezza per documento è la percentuale di documenti in cui tutti i campi obbligatori sono corretti, ed è quella che conta, perché un solo errore richiede comunque l'intervento di una persona sull'intero documento. Il tasso di lavorazione automatica è la percentuale di documenti che attraversa la pipeline senza che nessuno li tocchi: è l'unico numero che si traduce in ore risparmiate, ed è sempre più basso degli altri due perché dipende dalle soglie di confidenza scelte. Il quarto è il costo dell'errore residuo, che decide dove mettere le soglie. Vanno misurati su un campione di documenti reali presi come arrivano, storti e fotografati compresi: un campione di soli documenti puliti dà risultati brillanti e inutilizzabili.

Che cosa succede quando l'AI non è sicura di un dato?

Il documento non viene scritto: entra in una coda di revisione con il campo incerto evidenziato e il ritaglio dell'immagine da cui è stato letto, così l'operatore conferma o corregge in pochi secondi invece di rileggere tutto. Le regole sono decise prima e non lasciate al caso: confidenza alta su tutti i campi obbligatori e controlli aritmetici superati significa scrittura automatica; confidenza bassa su un campo significa revisione; confidenza alta ma quadratura fallita significa revisione obbligatoria, ed è il caso più insidioso perché il dato sembra giusto; fornitore o articolo assenti in anagrafica significano documento sospeso finché l'anagrafica non è allineata; documento illeggibile significa scarto con motivazione esplicita, mai in silenzio. Il principio è che l'automazione deve sapere quando non sa: un sistema che chiede conferma fa risparmiare tempo, uno che sbaglia con sicurezza inquina il gestionale e costringe a ricontrollare tutto a mano.

Meglio una piattaforma IDP a canone o una pipeline su misura?

Dipende da tre cose: quanto sono standard i vostri documenti, quanto è aperto il vostro gestionale e se i dati possono uscire dall'azienda. Se i documenti sono standard, i volumi modesti e il gestionale ha già un connettore pronto, una piattaforma a canone è la scelta razionale e ve lo diciamo. Se invece i documenti seguono regole vostre, se il gestionale è datato o privo di connettori, o se i dati non possono lasciare l'azienda, il canone finisce per pagare una flessibilità che non arriva mai: la piattaforma copre il caso previsto dal suo catalogo e tutto il resto va costruito comunque. Le differenze sostanziali sono quattro: il costo, che nel canone è ricorrente e cresce coi volumi mentre su misura è un investimento iniziale seguito dalla sola manutenzione; le regole di validazione aziendali, che su misura sono native; la scrittura nel gestionale, che nella soluzione su misura è il punto di partenza e non un'aggiunta; e la proprietà, perché codice, schema dei dati e prompt restano del cliente.

Chi può aiutarmi a integrare LLM e AI documentale in azienda in Emilia-Romagna?

Codebaker è una software house di Bologna, in Via N. Corazza 7/8, fondata nel 2019, che sviluppa in-house pipeline di estrazione dati dai documenti con OCR e LLM e le integra nei sistemi gestionali già in uso. Un progetto di AI documentale è per il 20% un problema di modelli e per l'80% un problema di integrazione, dati e processi: sulla parte difficile — far entrare dati corretti dentro sistemi che esistono già — abbiamo progetti in produzione da anni, dalla scrittura in tempo reale su un gestionale AS400 (300.000+ ordini l'anno) all'automazione di processi su dati di oltre 2.000 dipendenti integrata con SAP, HR, Active Directory e Office 365. Abbiamo anche un prodotto proprietario di Intelligent Document Processing, Data Alchemy, che usiamo come base quando il caso rientra nel suo perimetro. Il metodo con cui partiamo è sempre lo stesso: un centinaio di documenti reali, un pilota misurato in cieco e i numeri sul tavolo prima di sviluppare. L'analisi preliminare e il preventivo sono gratuiti.

Partiamo dal documento che vi fa perdere più ore

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.