Chi automatizza il controllo di fascicoli di documenti ricorrenti comincia quasi sempre dalla parte sbagliata: prima del modello viene l'elenco di cosa serve.
Quell'elenco esiste in ogni azienda. Quasi sempre vive dentro un documento lungo, e a leggerlo è una persona. Prima di scegliere un modello conviene farsi un'altra domanda: le regole non vanno nel prompt, vanno in una tabella.
Il fascicolo che qualcuno controlla a mano
Il lavoro ha sempre la stessa forma. Arriva un cliente nuovo, un fornitore nuovo, una pratica nuova. Qualcuno stabilisce quali documenti servono in quel caso, li chiede, li guarda uno per uno, ne estrae i dati che contano e li confronta con quello che la regola pretende.
Cambia il settore, non la forma. Lo studio che deve costituire il fascicolo di un nuovo cliente. L'ufficio acquisti che qualifica un fornitore. Chi prepara una pratica di finanziamento, un fascicolo di omologazione, la documentazione per una gara.
Il costo di quel lavoro sta quasi tutto nel primo passaggio, quello che sembra il più banale: stabilire cosa serve. Perché la risposta dipende da chi è il cliente, da dove ha sede, da che cosa gli si vende — e la regola che lo dice sta in un documento che nessuno legge per intero tutte le volte.
Il prompt — l'istruzione che si dà al modello — sembra il posto naturale dove mettere quella regola. È il posto peggiore: ogni requisito nuovo diventa una riscrittura, e nessuno sa più quale versione dell'istruzione ha prodotto il controllo di sei mesi fa.
Un prototipo di banca, e chi l'ha scritto
Il 21 settembre 2026 è uscito su arXiv un paper che questa divisione del lavoro la mette in chiaro: Spectra: A Rules-Driven LLM Pipeline for Automated KYC Document Processing, di Miray Wahib, Ethan Tran, Rea Mourad, Mira Muti e Nikita Dvornik.
Prima del contenuto, la provenienza. L'affiliazione dichiarata è Royal Bank of Canada, e una nota in prima pagina precisa che il lavoro è stato svolto nell'ambito del programma RBC Amplify: stando alla pagina di RBC, è un programma estivo di innovazione in cui si lavora in squadre di quattro su un problema proposto da un dirigente dell'azienda. Tre dei cinque indirizzi email degli autori sono della McGill University, uno è personale, uno solo è di RBC. È un preprint su arXiv: non è passato dalla revisione di una rivista, e non descrive un sistema in produzione in banca.
Quindi: un prototipo interno scritto in gran parte da universitari, su un problema vero di una banca. Quello che vale non sono i risultati, come si vede più avanti. È come hanno spezzato il lavoro.
Il problema che affrontano è l'apertura di un rapporto con un cliente istituzionale nei mercati finanziari — quello che in inglese si chiama Know Your Client e che in Italia sta sotto il nome di adeguata verifica della clientela. Nella loro descrizione, un singolo caso richiede di classificare più di venti documenti contro una tassonomia di oltre cinquanta tipi, e di validarli incrociando documenti di policy da quattrocento pagine per capire quali regole si applicano a quella combinazione di tipo di soggetto, giurisdizione e prodotto.
Cosa decide la tabella e cosa decide il modello
La scelta di fondo di Spectra è che la policy di conformità non è un testo da dare in pasto a un modello. È un database interrogabile: un PostgreSQL con una tabella dei tipi di documento accettati, una dei campi da estrarre con il loro formato atteso, una dei requisiti per giurisdizione, tipo di soggetto e prodotto, e una delle esenzioni, cioè le condizioni che aggiungono o tolgono un requisito in base a un dato già estratto.
Da lì esce la cosa che conta: dato un cliente con la sua giurisdizione, il suo tipo di soggetto e il suo prodotto, il sistema interroga il database e produce l'elenco esatto dei documenti richiesti. Senza nessuna chiamata a un modello.
Il resto della lavorazione passa da sei stadi in fila, ognuno un servizio separato con ingressi e uscite definiti:
- pulizia del file — controllo del tipo reale del file, limite di dimensione, estrazione del testo, con l'OCR — il riconoscimento dei caratteri — quando il documento è una scansione;
- ricerca di istruzioni nascoste nel documento;
- classificazione — di che tipo di documento si tratta, scelto dentro l'elenco dei candidati ammessi per quel caso;
- schema di estrazione — quali campi vanno tirati fuori da quel tipo di documento per quel requisito;
- estrazione dei valori, ognuno con la sua confidenza e il punto del documento da cui viene;
- validazione contro le regole, con esito, citazione della clausola e motivazione.
Lo stadio 4 non richiede nessuna chiamata a un modello: è una query al database, e gli autori lo segnalano esplicitamente. Lo stesso tipo di documento, usato per soddisfare requisiti diversi, produce schemi di estrazione diversi — una delibera del consiglio serve per i firmatari autorizzati oppure per l'approvazione del consiglio, e i campi da estrarre cambiano di conseguenza.
Al modello restano tre compiti, tutti stretti e tutti verificabili: riconosci questo documento dentro un elenco chiuso, estrai questi campi, confronta questo valore con questa clausola. Nessuno dei tre richiede che il modello si ricordi la policy, perché la policy gli arriva già filtrata, un pezzo alla volta.
La conseguenza pratica è quella che gli autori mettono nella sezione sulla scalabilità: aggiungere un requisito normativo nuovo significa aggiungere righe a una tabella, non riaddestrare un modello e non riscrivere un'istruzione. Ed è anche il motivo per cui ogni controllo risale a una clausola precisa: chi rivede il fascicolo vede la regola applicata, non il ragionamento di un modello.
La norma è già scritta come una tabella
Il motivo per cui questo schema funziona sull'antiriciclaggio è che la norma ha già quella forma. Basta aprirla.
Il Regolamento (UE) 2024/1624 all'articolo 22 elenca le informazioni minime da raccogliere per identificare il cliente, e le organizza per tipo di soggetto. Per una persona fisica: «tutti i nomi e i cognomi», «luogo e data di nascita completa», cittadinanze e numero di identificazione nazionale, la residenza abituale. Per un soggetto giuridico: «forma giuridica e nome del soggetto giuridico», l'indirizzo della sede legale e il paese di creazione, i nomi dei rappresentanti legali, il numero di registrazione. Per il trustee di un trust, un elenco ancora diverso. E una quarta lettera per «le altre organizzazioni dotate di capacità giuridica a norma del diritto nazionale».
Quattro tipi di soggetto, quattro elenchi di campi. È una tabella, già scritta nel testo di legge.
L'articolo 19 dice quando scatta l'obbligo: quando si instaura un rapporto d'affari, e per le operazioni occasionali «il cui valore è pari ad almeno 10 000 EUR, o al controvalore in moneta nazionale», anche se l'importo è raggiunto con più operazioni collegate.
E l'articolo 3 dice a chi si applica: oltre a banche ed enti finanziari, ci sono revisori, contabili esterni, consulenti tributari, notai e avvocati per certe operazioni, agenti immobiliari, chi commercia pietre e metalli preziosi, chi commercia beni di valore elevato, e chi commercia beni culturali — gallerie d'arte e case d'asta comprese — per operazioni di almeno 10.000 euro.
Sul «perché adesso» c'è una data precisa. L'articolo 90 stabilisce che il regolamento «si applica a decorrere dal 10 luglio 2027», con un rinvio al 10 luglio 2029 per due sole categorie: agenti calcistici e società calcistiche professionistiche. Chi rientra in quell'elenco ha meno di dieci mesi per decidere se quel controllo lo farà ancora leggendo un documento.
Il meccanismo, però, vale ben oltre l'antiriciclaggio. Un capitolato di gara, una pratica di finanziamento agevolato, un fascicolo di qualifica fornitore hanno la stessa struttura — un elenco di documenti che dipende da poche variabili, campi da estrarre, condizioni da verificare. L'adeguata verifica è solo il caso in cui la regola è già scritta da qualcun altro in forma tabellare, e quindi si vede meglio.
I tre numeri del paper, con il loro denominatore
Il riassunto del paper mette in vetrina tre numeri. Presi così, dicono molto meno di quello che sembra.
100% di accuratezza nella classificazione. Il campione è di 21 documenti veri, distribuiti su 9 tipi (tabella 1). Tutti e 21 classificati correttamente, con una confidenza media del 99,3% e 11,6 secondi a documento. L'81% è stato classificato con confidenza 100%, il restante 19% al 95%.
89,4% di accuratezza nell'estrazione. Qui il campione sono 15 documenti sintetici, cioè costruiti per la prova, con 141 valori annotati a mano su 27 tipi di campo (paragrafi 3.1 e 3.3). Il dettaglio per tipo di documento dice dove si rompe: le delibere societarie si fermano al 50% di accuratezza su 6 campi, i depositi presso le autorità di vigilanza al 69,7% su 33, e il campo sui poteri di firma sbaglia tutte e tre le volte in cui compare.
96% di riduzione del lavoro di revisione. È il numero più citabile e il più fragile: gli autori lo presentano come il risultato di un singolo caso di prova controllato, in cui le voci da rivedere a mano passano da 206 a 8. È una prova, non un rilascio in produzione, e il paper non dice su quale fascicolo sia stata fatta.
Cosa non torna, e cosa gli autori dicono da soli
Il riassunto del paper scrive che la valutazione è avvenuta su documenti KYC reali e attribuisce a quella valutazione entrambe le accuratezze. Il paragrafo 3.1 dice che l'estrazione è stata valutata su 15 documenti sintetici, e anche l'elenco dei contributi nell'introduzione distingue correttamente le due cose. Il corpo del paper è preciso; il riassunto, che è la parte che quasi tutti leggono, mette insieme due campioni diversi.
Poi c'è una domanda che nel testo resta senza risposta. La regola di revisione approva da sola solo i dati estratti con confidenza al 100% e manda a una persona tutto il resto. Ma la confidenza media dichiarata in estrazione è 43,3% (tabella 2). Come questo si concili con un passaggio da 206 voci a 8 il paper non lo spiega: potrebbero essere casi di prova diversi, ma non è scritto.
I limiti li dichiarano loro, nel paragrafo sulla classificazione, e sono tre: il campione è piccolo, tutti i documenti erano PDF relativamente puliti senza problemi seri di riconoscimento dei caratteri, e il filtro sull'elenco dei candidati riduce la difficoltà del compito. Il secondo punto è esattamente il primo dei tre controlli sui documenti aziendali: su una scansione storta, o su una tabella con celle unite, la prima parte della catena si comporta in un altro modo.
L'intelligenza del sistema, infine, è comprata: classificazione ed estrazione passano da LlamaCloud, un servizio gestito di terzi, mentre validazione e ricerca di istruzioni nascoste usano due modelli di OpenAI. Il pezzo di proprietà, in Spectra, è il database delle regole. Che è poi il punto.
Un documento che arriva da fuori non è un input fidato
Uno stadio di quella catena è il meno battuto del paper, e si porta via in un pomeriggio.
Lo stadio 2 cerca nel documento appena caricato istruzioni scritte per manipolare il modello. Gli autori usano due controlli: un confronto con frasi d'attacco note — l'esempio che fanno è «ignora tutte le istruzioni» — e un classificatore che prova a riconoscere i casi meno espliciti. Un documento segnalato prosegue comunque nella catena, ma viene messo sotto gli occhi di chi controlla la sicurezza.
Il principio si trasferisce ovunque. Una visura, un curriculum, una fattura di un fornitore, un capitolato sono file che arrivano da fuori e che nessuno in azienda ha scritto. Se finiscono dentro un sistema che legge e poi agisce, sono a tutti gli effetti un ingresso non fidato, come lo sarebbe un modulo compilato su un sito.
Come capire se le tue regole sono interrogabili
La verifica si fa senza comprare niente e senza un progetto. Prendi il fascicolo che in azienda si ripete più spesso e rispondi a quattro domande.
Da cosa dipende l'elenco dei documenti? Scrivi le variabili: tipo di cliente, paese, prodotto, importo, forma giuridica. Se sono tre o quattro, l'elenco è una query. Se la risposta è «dipende, chiedi a chi lo fa da dieci anni», il primo lavoro da fare è scrivere quella tabella, e la scelta del modello viene molto dopo.
Dov'è scritta la regola adesso? Un PDF, un allegato di una circolare, una casella di posta, la testa di una persona. Finché sta lì, ogni automazione la copierà dentro un'istruzione, e ogni aggiornamento della regola sarà una riscrittura che nessuno ricorda di fare.
Per ogni documento, quali campi servono davvero? Quelli che soddisfano quel requisito, che di solito sono molti meno di quelli che il documento contiene. Nel paper, uno dei tre modi di guasto è proprio l'estrazione in eccesso — il modello riempie campi presenti nel documento ma non richiesti dallo schema, perché nulla gli dice dove fermarsi.
Quale controllo dice a quale clausola si riferisce? Se un esito non cita la regola che lo ha prodotto, chi rivede deve rifare il ragionamento da capo, e il vantaggio è già perso.
Se queste quattro risposte esistono, hai anche la descrizione del processo che serve quando si sceglie quale processo automatizzare. Se mancano, hai trovato il primo lavoro da fare, e per farlo non serve alcuna AI.
Prima del modello, la tabella
Spectra è un prototipo di un programma estivo, misurato su 21 documenti veri e 15 costruiti per l'occasione. Come prova che la cosa funzioni, non basta, e gli autori non fingono il contrario.
Come schema, invece, regge, e regge perché la parte che decide cosa serve non passa da un modello. Il database dice quali documenti servono per quel cliente, in quella giurisdizione, per quel prodotto. Il modello riconosce, estrae, confronta — tre compiti su cui si può misurare quanto sbaglia. Chi rivede vede la clausola accanto all'esito. E il giorno in cui la regola cambia, cambia una riga.
Il costo di partenza non è tecnologico. È il tempo che serve a mettere per iscritto, in forma di tabella, una regola che oggi esiste come prosa e come esperienza. Quel tempo va speso comunque: un'automazione costruita sopra una regola non scritta eredita l'ambiguità e la nasconde.
Le regole non vanno nel prompt, vanno in una tabella.
Nel controllo che la tua azienda ripete più spesso, chi sa dire quali documenti servono, oltre alla persona che lo fa da sempre?