È arrivata la fattura del fornitore Rossi Componenti. Puoi processarla?
AGENTE · DOCUMENT EXTRACTOR
Le informazioni estratte dai documenti in forma strutturata, pronte per il sistema.
Document Extractor legge documenti complessi che arrivano in azienda — contratti firmati, fatture, certificati, documenti regolatori, perizie — ed estrae le informazioni rilevanti in forma strutturata. I dati pronti finiscono nel sistema gestionale, nel CRM, nell'archivio documentale senza data entry manuale.
Document Extractor al lavoro.
Fattura attiva riconosciuta. Fornitore Rossi Componenti Srl (P.IVA in anagrafica). Imponibile €12.450 · IVA 22% · totale €15.189. IBAN formalmente corretto. Tutte le validazioni superate, dati passati al gestionale.
Una voce di fatturazione è nuova rispetto alla baseline del fornitore ("Consulenza tecnica straordinaria"). Ho messo in evidenza la riga per verifica prima della liquidazione.
Perché esiste.
L'azienda mid-large riceve ogni giorno documenti complessi: contratti firmati, fatture in arrivo, certificati di conformità, perizie tecniche, documenti regolatori. Ciascuno contiene informazioni che servono nei sistemi a valle. La data entry manuale è ancora lo standard: prende tempo, genera errori, scala male.
Come lavora ogni giorno.
Document Extractor si attiva all'arrivo del documento (upload webhook, scan da sportello, canale configurato). Riconosce il tipo, estrae le informazioni rilevanti in forma strutturata, valida i dati contro le regole configurate (partita IVA valida, numerico positivo, formato data corretto), passa i dati strutturati al sistema a valle via API.
La decisione resta al team.
Per documenti standard validati l'agente procede autonomamente. Per documenti con anomalie — campi mancanti, valori fuori range, formati non riconosciuti — segnala all'operatore con il punto specifico da rivedere. Meglio una segnalazione in più che un dato sbagliato nel sistema.
Per chi è utile e dove si applica.
Responsabile operations
Recupera il tempo della data entry manuale del proprio team. La capacità si dimensiona sul volume reale dei documenti, non sulle ore disponibili degli addetti. I picchi di fine mese o di chiusura trimestrale non si trasformano più in code arretrate.
DAU · #SAD-2024-877 Reg. 952/2013
Codice merce 8703.23
Origine DE · UE
ICS2 · pre-arrival trasmesso
AEO record aggiornato
Addetto alla validazione
Si concentra sui casi che richiedono giudizio — documento con campi mancanti, valori fuori range, fornitore nuovo non in anagrafica — invece di trascrivere dati già presenti nel documento. Il lavoro torna a essere qualificato.
Proposta n. 2024-081 In revisione
Disclosure mancante
art. 21 TUF · strumento finanziario regolato
Alt. 1 …nel rispetto dell'art. 21 TUF e delle disposizioni Consob vigenti.
Alt. 2 …con disclosure completa allegata al documento di offerta.
Traccia audit registrata · 14:31
Responsabile amministrativo o compliance
Vede ridursi gli errori sistemici di trascrizione: importi errati, classificazioni sbagliate, riferimenti normativi mancanti. La traccia dei documenti processati è ispezionabile a fine periodo per audit interno.
fnol.receive 09:14:22 ALLOW
triage.classify 09:14:25 ALLOW
idd.check 09:14:31 WARN
liquidation.propose 09:15:02 ALLOW
SELECT * FROM audit_log WHERE claim_id = '2024-0847'
Un esempio concreto.
Una fattura del fornitore X arriva nel sistema.
Per un'azienda B2B mid-market con 800 fatture in arrivo al mese, l'integrazione con il canale di ricezione e il sistema gestionale fatture è realizzata in fase di delivery. Una fattura del fornitore X arriva nel sistema configurato per l'azienda. L'agente si attiva, riconosce il tipo di documento (fattura attiva).
I dati strutturati passano al gestionale via API.
L'agente estrae i dati: fornitore (partita IVA validata contro anagrafica), data emissione, scadenza pagamento a 60 giorni, voci di fatturazione, imponibile €12.450, IVA 22%, totale €15.189, IBAN (validato come IBAN italiano formalmente corretto). I dati strutturati vengono passati al sistema gestionale fatture via API. La fattura viene marcata come "ricevuta, validata, in attesa di liquidazione".
Per il 95% standard il flusso si chiude in secondi.
Per il 95% delle fatture standard del fornitore noto, il flusso si chiude in pochi secondi senza intervento manuale. Il 5% con anomalie — importo significativamente sopra la media del fornitore, voce nuova, anagrafica cambiata — arriva al responsabile per validazione con il punto specifico in evidenza. L'evento resta nel registro audit, leggibile con client SQL standard.
Configurazione e risorse tecniche.
Le regole di Document Extractor sono dichiarative. Il team operations o compliance del cliente definisce in formato leggibile la tassonomia dei documenti, gli schemi di estrazione per ciascun tipo, le regole di validazione (range numerici, formati attesi, anagrafiche di riferimento), le regole di routing al sistema a valle. Le regole vivono nel repository del cliente, versionate, validate all'avvio dell'agente. Per documenti scansionati o PDF complessi, l'integrazione con servizio OCR esterno (Microsoft Document Intelligence, Google Document AI o equivalenti) si realizza in fase di delivery dal team Exelab.
- Linguaggio
- TypeScript (Node.js)
- Modello LLM
- a scelta del cliente: Anthropic, OpenAI, Mistral, modelli open source ospitati internamente, AWS Bedrock per modello privato
- Controlli built-in usati
- pii-detector, credential-detector, tool-param-validator, message-length-limit
- Canali nativi
- HTTP OpenAI-compatible (webhook upload), Telegram, Slack, WhatsApp
- Email aziendale come canale di ricezione
- integrazione realizzata in fase di delivery
- OCR e parsing PDF complessi
- servizio esterno (Microsoft Document Intelligence, Google Document AI o equivalenti) configurato in fase di delivery — non è capability built-in del runtime
- Integrazione sistema gestionale a valle
- adapter dedicato realizzato in fase di delivery
- Memoria
- persistente per istanza, pgvector + PostgreSQL FTS sui pattern dei documenti del cliente
- Registro
- immutabile, interrogabile con client SQL standard
Domande frequenti sull'agente.
Per documenti scansionati o PDF complessi, il flusso tipico prevede un servizio OCR esterno — Microsoft Document Intelligence, Google Document AI o servizi proprietari — configurato in fase di delivery. L'OCR non è capability built-in del runtime. Il pattern è OCR esterno + estrazione strutturata dell'agente sulle informazioni testo risultanti.
Ogni estrazione è validata contro le regole configurate dal team. Quando un valore non supera la validazione (partita IVA non riconosciuta, importo fuori range, formato data errato), l'agente non procede autonomamente: segnala l'anomalia all'operatore con il punto specifico in evidenza. Il principio applicato è conservativo: meglio una segnalazione in più che un dato sbagliato nel sistema.
I tipi supportati dipendono dalle regole dichiarative configurate dal team del cliente in fase di delivery. La logica di estrazione è generica — il modello LLM legge testo strutturato e applica regole di parsing. Pattern già collaudati includono fatture italiane, contratti standard, certificati ISO, perizie assicurative.
Il pattern tipico per Document Extractor è 8-14 settimane. Discovery 2 settimane, configurazione regole di estrazione per i tipi di documento principali 3-5 settimane, integrazione OCR (se richiesto) e sistema gestionale a valle 3-5 settimane, hand-off 1-2 settimane. La durata dipende dal numero di tipi di documento coperti.
Da una conversazione di 30 minuti alla squadra in produzione.
Una conversazione di 30-45 minuti per capire come Document Extractor si configurerebbe sul caso del cliente. Quali tipi di documento, quale volume, quale sistema a valle.