Cuando una empresa confía en la inteligencia artificial para procesar datos financieros, la tentación de delegar la validación es enorme. Pero quien ha construido sistemas de extracción con modelos de lenguaje sabe que el verdadero desafío no está en obtener el 99% de acierto, sino en detectar ese 1% que parece correcto y no lo es. En Q2BSTUDIO, donde desarrollamos aplicaciones a medida para sectores críticos, aprendimos que el eslabón más débil de cualquier pipeline de IA no es el modelo, sino la ausencia de un mecanismo de verificación determinista. Este artículo explora por qué un extractor de documentos financieros que no se verifica a sí mismo es más peligroso que uno que falla estrepitosamente, y cómo un enfoque basado en señales redundantes —como los saldos de cuenta— puede transformar la fiabilidad de los sistemas que manejan números reales.
La belleza de un extractor que emplea visión por computadora y modelos de lenguaje radica en su capacidad para interpretar diseños complejos: tablas irregulares, formatos de fecha cambiantes, monedas extranjeras. Sin embargo, ningún modelo —por avanzado que sea— puede garantizar que cada dígito extraído coincida con el original. Un error de un solo carácter, como leer 1.240,50 en lugar de 1.340,50, pasa desapercibido en cualquier proceso manual o automatizado que no cruce datos de forma redundante. Ese error, después de semanas, desajusta una conciliación bancaria por cien euros, y nadie sabe por qué. La raíz del problema es que una mentira plausible —un valor que encaja en la suma total, que ordena bien, que se importa sin errores— es mucho más peligrosa que un error evidente. Porque un error lo corriges; una mentira plausible la integras.
En Q2BSTUDIO, al diseñar sistemas de IA para automatización financiera, aplicamos un principio fundamental: la verificación debe ser independiente del modelo. No podemos pedirle al mismo modelo que extrajo los datos que los valide; necesitamos una fuente de verdad externa. En el caso de los extractos bancarios, esa fuente está incrustada en el propio documento: el saldo corriente que aparece junto a cada transacción. Esa columna de saldo no es un adorno; es una señal de control que el banco te ofrece sin coste. Si extraemos correctamente tanto el importe como el saldo de cada fila, entonces la relación entre filas consecutivas debe cumplir una identidad simple: el saldo de la fila más antigua más el importe de la fila más nueva debe igualar el saldo de la fila más nueva. Esto se cumple si el banco imprime los movimientos en orden descendente (más reciente primero). Si el orden es ascendente, la identidad cambia de signo, pero el principio es el mismo: la cadena de saldos debe cerrar.
Este enfoque de reconciliación matemática es el corazón de un sistema que construimos para convertir PDF bancarios en hojas de cálculo. No confiamos en el modelo; confiamos en la aritmética. Cada par de filas adyacentes se compara con una tolerancia de un céntimo (para absorber ruido de punto flotante). Si la fracción de pares que cierran es superior a 0,99, consideramos la extracción verificada. Si no, la salida se etiqueta como 'NO VERIFICADA' y se acompaña de un mensaje claro en el archivo descargado, en el nombre del fichero y en la respuesta de la API. De esta forma, el usuario siempre sabe si los números han pasado por un control determinista o si son simplemente el resultado de una inferencia probabilística.
Hay dos giros que hacen este sistema robusto frente a la diversidad de formatos bancarios. El primero es que los bancos no se ponen de acuerdo en la dirección temporal: algunos imprimen los movimientos más recientes primero (como los bancos nórdicos) y otros los más antiguos primero (como la mayoría de bancos estadounidenses). En lugar de detectar heurísticamente el orden, podemos puntuar la extracción en ambos sentidos y quedarnos con el que obtenga mejor puntuación. Una extracción incorrecta no obtendrá una puntuación alta en ningún orden, porque los números erróneos no encajan en ninguna cadena consistente. El segundo giro es que muchos extractos —especialmente los de dos columnas del Reino Unido o los agrupados por día— solo imprimen el saldo en la última fila de cada día, dejando la mayoría de filas sin saldo. En esos casos, no podemos hacer la verificación fila a fila, pero sí podemos acumular los importes entre dos saldos impresos consecutivos y comprobar que la suma coincide con la diferencia entre esos saldos. Este método localiza el error en un segmento concreto, lo que es más potente que simplemente verificar que el saldo inicial más los totales de débitos y créditos coinciden con el saldo final.
La parte que más me importa es que la puerta de verificación se niega a bendecir lo que no puede verificar. Un error sutil en una implementación ingenua es devolver una puntuación perfecta (1.0) cuando no hay suficientes filas con saldo para comprobar. Eso significaría que una extracción vacía, o una donde el modelo no devolvió ningún saldo, pasaría el control. Es exactamente lo contrario de lo que necesitamos: un resultado no verificable no es un resultado verificado. Por eso, la condición de paso exige que al menos se haya comprobado un par (total > 0) y que la puntuación supere el umbral. Si no se puede verificar, la etiqueta de 'NO VERIFICADO' sigue a los datos a todas partes.
Este enfoque tiene implicaciones profundas para cualquier negocio que maneje datos financieros. En Q2BSTUDIO, integramos este tipo de comprobaciones en nuestros proyectos de cloud AWS/Azure y BI / Power BI, donde la integridad de los datos es tan importante como su disponibilidad. Por ejemplo, cuando construimos cuadros de mando en Power BI a partir de datos bancarios extraídos mediante IA, la reconciliación se convierte en un paso de gobernanza automático: si el extracto no se verifica, el panel se genera con una advertencia visible. De igual modo, en entornos de banca y fintech donde la ciberseguridad es prioritaria, un sistema que nunca está 'confiadamente equivocado' reduce el riesgo de decisiones basadas en datos manipulados o mal interpretados.
Más allá de la extracción bancaria, el principio es aplicable a cualquier dominio donde exista una señal redundante. Las facturas llevan la relación entre línea, impuestos y total; los libros contables tienen partidas dobles; los inventarios tienen existencias iniciales y finales. Esa redundancia es un cheque gratuito y determinista que podemos envolver alrededor de modelos probabilísticos. Permite hacer una promesa que la mayoría de las herramientas de IA no pueden hacer: si no estoy seguro, lo diré, en lugar de adivinar.
La herramienta que hemos desarrollado como demostración de este concepto (disponible como banco de pruebas en nuestro laboratorio de desarrollo) acepta PDF de cualquier banco, extrae transacciones con un modelo de lenguaje visual y aplica la reconciliación. En pruebas con un extracto real de 16 páginas y 742 transacciones, la puntuación fue de 740/741 pares correctos (0,9986). Nada se envía por debajo de 0,99. Ese número no es una etiqueta de marketing: es una medición recalculada en cada conversión. Es la diferencia entre un sistema que 'adivina' y uno que 'verifica'.
En resumen, si estás poniendo un LLM cerca de números con los que la gente va a actuar, busca la señal redundante que ya está en tus datos de entrada. Los extractos bancarios llevan saldos; las facturas llevan totales; los libros contables llevan asientos dobles. Esa redundancia te permite construir una compuerta de verificación determinista alrededor de un modelo probabilístico. Y esa compuerta te permite hacer lo que pocas aplicaciones de IA pueden: si no estoy seguro, te lo advierto, en lugar de arriesgarme a que tomes una decisión basada en un número falso.
