Per què no confio en el meu extractor d'IA: verificar cada número

Descobreix com garantir la precisió de l'extracció de dades financeres amb IA usant la reconciliació de saldos. No confiïs, verifica.

miércoles, 29 de julio de 2026 • 6 min de lectura • Equip Q2BSTUDIO

Verificación de extractos bancarios con IA: el método de reconciliación

Quan una empresa confia en la intel·ligència artificial per processar dades financeres, la temptació de delegar la validació és enorme. Però qui ha construït sistemes d'extracció amb models de llenguatge sap que el veritable repte no és obtenir el 99% d'encert, sinó detectar aquell 1% que sembla correcte i no ho és. A Q2BSTUDIO, on desenvolupem aplicacions a mida per a sectors crítics, vam aprendre que l'enllaç més feble de qualsevol pipeline d'IA no és el model, sinó l'absència d'un mecanisme de verificació determinista. Aquest article explora per què un extractor de documents financers que no es verifica a si mateix és més perillós que un que falla estrepitosament, i com un enfocament basat en senyals redundants —com els saldos de compte— pot transformar la fiabilitat dels sistemes que manegen números reals.

La bellesa d'un extractor que empra visió per computador i models de llenguatge rau en la seva capacitat per interpretar dissenys complexos: taules irregulars, formats de data canviants, monedes estrangeres. No obstant, cap model —per avançat que sigui— pot garantir que cada dígit extret coincideixi amb l'original. Un error d'un sol caràcter, com llegir 1.240,50 en lloc d'1.340,50, passa desapercebut en qualsevol procés manual o automatitzat que no creui dades de forma redundant. Aquest error, després de setmanes, desajusta una conciliació bancària per cent euros, i ningú sap per què. L'arrel del problema és que una mentida plausible —un valor que encaixa en la suma total, que ordena bé, que s'importa sense errors— és molt més perillosa que un error evident. Perquè un error el corregeixes; una mentida plausible la integres.

A Q2BSTUDIO, en dissenyar sistemes d'IA per a automatització financera, apliquem un principi fonamental: la verificació ha de ser independent del model. No podem demanar al mateix model que va extreure les dades que les validi; necessitem una font de veritat externa. En el cas dels extractes bancaris, aquesta font està incrustada al propi document: el saldo corrent que apareix al costat de cada transacció. Aquesta columna de saldo no és un adorn; és un senyal de control que el banc t'ofereix sense cost. Si extraiem correctament tant l'import com el saldo de cada fila, llavors la relació entre files consecutives ha de complir una identitat simple: el saldo de la fila més antiga més l'import de la fila més nova ha de ser igual al saldo de la fila més nova. Això es compleix si el banc imprimeix els moviments en ordre descendent (més recent primer). Si l'ordre és ascendent, la identitat canvia de signe, però el principi és el mateix: la cadena de saldos ha de tancar.

Aquest enfocament de reconciliació matemàtica és el cor d'un sistema que vam construir per convertir PDF bancaris en fulls de càlcul. No confiem en el model; confiem en l'aritmètica. Cada parell de files adjacents es compara amb una tolerància d'un cèntim (per absorbir soroll de coma flotant). Si la fracció de parells que tanquen és superior a 0,99, considerem l'extracció verificada. Si no, la sortida s'etiqueta com a 'NO VERIFICADA' i s'acompanya d'un missatge clar al fitxer descarregat, al nom del fitxer i a la resposta de l'API. D'aquesta manera, l'usuari sempre sap si els números han passat per un control determinista o si són simplement el resultat d'una inferència probabilística.

Hi ha dos girs que fan aquest sistema robust davant la diversitat de formats bancaris. El primer és que els bancs no es posen d'acord en la direcció temporal: alguns imprimeixen els moviments més recents primer (com els bancs nòrdics) i altres els més antics primer (com la majoria de bancs estatunidencs). En lloc de detectar heurísticament l'ordre, podem puntuar l'extracció en ambdós sentits i quedar-nos amb el que obtingui millor puntuació. Una extracció incorrecta no obtindrà una puntuació alta en cap ordre, perquè els números erronis no encaixen en cap cadena consistent. El segon gir és que molts extractes —especialment els de dues columnes del Regne Unit o els agrupats per dia— només imprimeixen el saldo a l'última fila de cada dia, deixant la majoria de files sense saldo. En aquests casos, no podem fer la verificació fila a fila, però sí que podem acumular els imports entre dos saldos impresos consecutius i comprovar que la suma coincideix amb la diferència entre aquests saldos. Aquest mètode localitza l'error en un segment concret, cosa que és més potent que simplement verificar que el saldo inicial més els totals de dèbits i crèdits coincideixen amb el saldo final.

La part que m'importa més és que la porta de verificació es nega a beneir allò que no pot verificar. Un error subtil en una implementació ingènua és retornar una puntuació perfecta (1.0) quan no hi ha prou files amb saldo per comprovar. Això significaria que una extracció buida, o una on el model no va retornar cap saldo, passaria el control. És exactament el contrari del que necessitem: un resultat no verificable no és un resultat verificat. Per això, la condició de pas exigeix que almenys s'hagi comprovat un parell (total > 0) i que la puntuació superi el llindar. Si no es pot verificar, l'etiqueta de 'NO VERIFICADA' segueix les dades a tot arreu.

Aquest enfocament té implicacions profundes per a qualsevol negoci que manegi dades financeres. A Q2BSTUDIO, integrem aquest tipus de comprovacions als nostres projectes de cloud AWS/Azure i BI / Power BI, on la integritat de les dades és tan important com la seva disponibilitat. Per exemple, quan construïm quadres de comandament a Power BI a partir de dades bancàries extretes mitjançant IA, la reconciliació es converteix en un pas de governança automàtic: si l'extracte no es verifica, el panell es genera amb un avís visible. De la mateixa manera, en entorns de banca i fintech on la ciberseguretat és prioritària, un sistema que mai està 'confiadament equivocat' redueix el risc de decisions basades en dades manipulades o mal interpretades.

Més enllà de l'extracció bancària, el principi és aplicable a qualsevol domini on hi hagi un senyal redundant. Les factures porten la relació entre línia, impostos i total; els llibres comptables tenen partides dobles; els inventaris tenen existències inicials i finals. Aquesta redundància és un xec gratuït i determinista que podem embolicar al voltant de models probabilístics. Permet fer una promesa que la majoria d'eines d'IA no poden fer: si no estic segur, ho diré, en lloc d'endevinar.

L'eina que hem desenvolupat com a demostració d'aquest concepte (disponible al nostre laboratori de desenvolupament) accepta PDF de qualsevol banc, extreu transaccions amb un model de llenguatge visual i aplica la reconciliació. En proves amb un extracte real de 16 pàgines i 742 transaccions, la puntuació va ser de 740/741 parells correctes (0,9986). Res s'envia per sota de 0,99. Aquest número no és una etiqueta de màrqueting: és un mesurament recalculat a cada conversió. És la diferència entre un sistema que 'endevina' i un que 'verifica'.

En resum, si estàs posant un LLM a prop de números amb els quals la gent actuarà, busca el senyal redundant que ja està a les teves dades d'entrada. Els extractes bancaris porten saldos; les factures porten totals; els llibres comptables porten assentaments dobles. Aquesta redundància et permet construir una porta de verificació determinista al voltant d'un model probabilístic. I aquesta porta et permet fer allò que poques aplicacions d'IA poden: si no estic segur, t'ho adverteixo, en lloc d'arriscar-me a que prenguis una decisió basada en un número fals.

UNA PAUSA?

Juga una estona abans de marxar

ELS NOSTRES SERVEIS

Com et podem ajudar

Tens un projecte en ment?

Explica'ns la teva visió i la convertim en una solució de programari. Sigui quin sigui l'abast, fem realitat la teva idea.