Cómo automatizar documentos con inteligencia artificial sin perder el control

Lo que se demuestra y lo que se opera

Casi todas las demostraciones de procesamiento de documentos con inteligencia artificial son la misma escena: alguien sube una factura, aparecen los campos rellenos, la sala asiente. Y es verdad — esa parte funciona razonablemente bien hoy, mejor que hace tres años, y no hace falta un equipo grande para montarla.

El problema aparece en el documento número cuatrocientos. El que llega escaneado torcido, con un sello encima del importe. El que trae dos números que podrían ser el total. El que viene en un formato que el proveedor cambió el mes pasado sin avisar. El sistema no se cae: rellena los campos igual, con la misma cara de seguridad, y ese dato entra en contabilidad como cualquier otro.

Ahí está la diferencia entre una demo y un sistema. No en el modelo de extracción, sino en todo lo que hay alrededor para que un error se detecte, se dirija a alguien y no se propague. Lo que sigue es la arquitectura que usamos para eso, etapa por etapa, con los controles que cada una necesita.

La cadena real: seis etapas

Conviene ver el sistema completo antes de discutir modelos, porque la mayoría de las decisiones importantes no son de modelo.

Cadena de procesamiento documental

• Captura
• Clasificación
• Extracción
• Validación
• Excepción
• Sistema destino

• Señal de riesgo por campo
• Trazabilidad al origen
• Permisos heredados
• Idempotencia

Las cuatro propiedades de abajo tienen que sobrevivir las seis etapas. Si se pierden en la tercera, las tres últimas trabajan a ciegas.

Captura. De dónde entran los documentos: un buzón de correo, una carpeta compartida, un portal, un escáner, una API. Es la etapa más aburrida y la que más incidencias genera a largo plazo, porque cambia sin que nadie lo comunique.

Clasificación. Qué es este documento. Factura, albarán, contrato, nómina, documento que no nos corresponde. Separar la clasificación de la extracción parece una complicación innecesaria al principio; deja de parecerlo el día que hay que añadir un tipo nuevo.

Extracción. Convertir el documento en campos estructurados. Aquí conviven dos cosas distintas que a menudo se confunden: el OCR clásico, que convierte píxeles en texto, y la extracción semántica, que decide qué trozo de ese texto es «el importe total». Un PDF nativo ya trae el texto y no necesita OCR; un escaneo sí, y la calidad del OCR pone el techo de todo lo que venga después.

Validación. ¿Es plausible lo extraído? Aquí entran las reglas que el negocio ya conoce: que las líneas sumen el total, que el NIF tenga formato válido, que el proveedor exista, que la fecha no sea futura.

Excepción. Qué hacemos con lo que no pasa validación o llega marcado como de riesgo alto. Es una etapa, no un mensaje de error.

Sistema destino. El ERP, el gestor documental, la base de datos. Donde el dato se vuelve real y donde deshacer las cosas empieza a costar dinero.

Dónde falla cada etapa, y con qué se contiene

Esta es la tabla que rellenamos antes de escribir código. Cada fila es una conversación que es mucho más barata tener ahora que en producción.

Etapa	Cómo falla en la práctica	Control que la contiene	Señal de que está fallando
Captura	Formatos nuevos, adjuntos comprimidos, correos reenviados con el documento dentro de otro, duplicados del mismo documento por dos canales	Registro de entrada con huella del fichero, deduplicación explícita, cuarentena para lo que no se sabe abrir	Suben los documentos «no procesables»; el mismo documento aparece dos veces con distinto identificador
Clasificación	Documentos híbridos (una factura con un albarán detrás), tipos que no existían cuando se diseñó	Clase «desconocido» de primera clase, con destino propio; nunca una clase por defecto silenciosa	Crece la clase mayoritaria mientras las minoritarias se vacían
Extracción (OCR)	Escaneos girados, baja resolución, sellos y firmas sobre el texto, tablas a varias páginas	Comprobación de calidad de imagen antes de extraer; reintento con otra estrategia; rechazo explícito	Si tu OCR publica una puntuación por página o por palabra, su media cayendo por remitente o por canal; si no la publica, la subida de rechazos y reintentos
Extracción (semántica)	El campo correcto existe pero se coge otro: el subtotal en vez del total, la fecha de vencimiento en vez de la de emisión	Señal de riesgo por campo (no por documento) y anclaje del valor a su posición en el original; comprobaciones deterministas donde las haya	Sube la tasa de corrección humana en un campo concreto
Validación	Reglas que solo miran formato y no coherencia; reglas que nadie mantiene cuando cambia el negocio	Reglas de negocio con dueño y fecha de revisión; comprobaciones cruzadas contra maestros reales	Documentos que pasan validación y luego se corrigen aguas abajo
Excepción	Cola sin dueño, sin prioridad y sin tiempo asignado; se aprueba en bloque para vaciarla	Capacidad dimensionada, prioridad por impacto, motivo visible junto al documento original	La cola crece de forma sostenida, o se vacía sospechosamente rápido
Sistema destino	El mismo documento se registra dos veces; una corrección posterior no se propaga	Idempotencia por huella del documento, escritura reversible, registro de qué versión escribió qué	Descuadres detectados por contabilidad y no por el sistema

Dos observaciones sobre esta tabla.

La primera: la mayoría de estas filas no se arreglan con un modelo mejor, sino con diseño. Un modelo mejor sí ayuda en la fila de extracción —a veces mucho, sobre documentos difíciles—, pero no toca las otras seis. Un sistema con extracción mediana y controles serios se puede operar; uno con extracción excelente y sin controles produce errores silenciosos que alguien descubre en el cierre de mes.

La segunda: la columna de la derecha es la que hay que instrumentar el primer día. Si no puedes ver esas señales, no sabes si el sistema está sano; sabes que nadie se ha quejado todavía, que es otra cosa.

Riesgo por campo: el control que decide si el sistema es operable

La decisión de arquitectura que más nos ha cambiado el resultado de un sistema documental es esta: cada campo extraído viaja con una señal de riesgo propia y con un puntero a dónde salió del original.

Por campo, no por documento. Un documento puede estar perfectamente leído en nueve campos y ser una lotería en el décimo, y si solo tienes un número agregado para todo el documento, ese décimo campo pasa desapercibido.

Ahora, la parte incómoda: esa señal de riesgo no siempre existe, y cuando existe no siempre significa lo que parece. Conviene distinguir tres cosas:

• Puntuación del proveedor o del modelo. Muchos servicios de extracción devuelven un número por campo, y muchos otros no devuelven nada, o solo lo devuelven para el OCR y no para la interpretación. Cuando lo hay, es una puntuación interna del sistema — no es automáticamente la probabilidad de que el valor sea correcto. Puede estar bien ordenada (los valores con menos puntuación fallan más) y aun así estar mal calibrada (un 0,9 no significa «acierta el 90 % de las veces»).
• Calibración contra ejemplos reales. Antes de usar esa puntuación como umbral hay que comprobar qué predice, con documentos tuyos etiquetados por personas: agrupar por tramos de puntuación y medir la tasa de error real en cada tramo. Si el orden se sostiene, sirve para priorizar; si además está calibrada, sirve para fijar umbrales con sentido. Y hay que repetirlo cuando cambie el modelo o el proveedor, porque la escala no se conserva.
• Señal de riesgo derivada, cuando no hay puntuación fiable. Se puede construir una propia, y a menudo es lo más honesto: coherencia aritmética, contraste contra maestros (¿existe este proveedor?, ¿coincide el IBAN registrado?), acuerdo entre dos estrategias de extracción distintas, formato esperado, plausibilidad del rango, presencia del valor en la zona del documento donde debería estar. Un campo que falla dos de estas comprobaciones es de alto riesgo, exista o no un número del proveedor.

Con cualquiera de esas señales —proveedor calibrado o derivada— se puede construir la política de decisión, que es una tabla de negocio, no técnica:

Tipo de campo	Ejemplo	Qué pasa con riesgo bajo	Qué pasa con riesgo alto
Crítico e irreversible	Importe a pagar, IBAN de destino	Sigue, pero queda registrado y es reversible	Para. Siempre revisión humana, sin excepción por volumen
Crítico y corregible	Fecha de vencimiento, número de pedido	Sigue	Revisión humana o segunda estrategia de extracción
Contextual	Nombre comercial del proveedor, referencia interna	Sigue	Sigue marcado como incompleto; se completa después
Informativo	Notas, texto libre del pie	Sigue	Sigue vacío; no bloquea nada

Un matiz que evita un error caro: para los campos críticos e irreversibles, las comprobaciones deterministas de negocio no son el plan B de la puntuación, son el control principal. Que las líneas sumen el total, que el IBAN coincida con el que ese proveedor tiene registrado y que el documento no sea un duplicado son verificaciones que no dependen de ningún modelo, no se descalibran y siguen valiendo el día que cambies de proveedor. La señal de riesgo decide qué mirar primero; la validación determinista decide qué puede pasar.

La conversación que hay que provocar con esta tabla no es «¿qué umbral ponemos?». Es quién decide el umbral y qué está dispuesto a asumir. Un umbral es una decisión de negocio disfrazada de parámetro técnico: subirlo manda más trabajo a las personas y baja el riesgo; bajarlo hace lo contrario. Que lo firme quien responde por el error, no quien configura el sistema. El marco de impacto y reversibilidad para colocar a la persona en el sitio correcto está en dónde tiene sentido la revisión humana.

Y el puntero al original importa tanto como el número. Cuando alguien revisa una excepción, la diferencia entre «revisa este importe» y «revisa este importe, sale de aquí, en esta página, en esta zona del documento» es la diferencia entre veinte segundos y tres minutos por caso. A volumen, eso decide si el proceso es sostenible.

Las excepciones no son el plan B

El error de diseño más frecuente que vemos: se construye la ruta feliz con detalle y las excepciones se resuelven con una bandeja de correo y buena voluntad.

Un camino de excepción diseñado tiene cinco cosas, y todas se deciden antes de arrancar:

• Un motivo legible. No «error de validación», sino «el total no cuadra con la suma de líneas: 1.240,00 frente a 1.204,00». La persona tiene que entender el problema sin abrir el código.
• El documento original al lado. Con la zona relevante señalada. Sin esto, revisar es reconstruir.
• Un dueño y una prioridad. Por tipo de excepción, no una cola indiferenciada. Las excepciones de importe no compiten con las de referencia interna.
• Capacidad dimensionada. Si el sistema genera más excepciones de las que el equipo puede atender en su jornada, la cola se aprueba en bloque y la revisión desaparece aunque siga en el diagrama. Esto es una estimación que hay que hacer con números propios antes de empezar, no un descubrimiento para el segundo mes.
• Retorno al flujo. Lo corregido vuelve al proceso normal y se guarda como caso de entrenamiento o de regresión. Una corrección que solo arregla un documento es trabajo perdido; una corrección que además mejora el sistema es inversión.

Hay un indicador que merece la pena vigilar desde el principio: la tasa de excepción por tipo de documento y por remitente. Cuando sube en un remitente concreto, lo primero que conviene descartar es que alguien haya cambiado una plantilla; en nuestra experiencia es la causa más frecuente. Es la alerta más útil y la más barata de instrumentar.

Metadatos: lo que hay que guardar por documento

Un sistema documental que no puede reconstruir cómo llegó a un dato no es auditable, y sin eso la primera discrepancia seria se convierte en una investigación manual. Lo mínimo, por documento y por campo:

• Origen y huella. De dónde entró, cuándo, y una huella del fichero para detectar duplicados y para probar que el original no cambió.
• Versión de todo lo que decidió. Qué versión del clasificador, del extractor y del conjunto de reglas produjo este resultado. Sin esto no se puede responder «¿por qué en marzo salía bien?».
• Riesgo y procedencia por campo. El valor, la señal de riesgo con la que salió, de dónde viene esa señal (puntuación del proveedor o comprobación propia) y la posición en el original.
• Intervenciones humanas. Qué se corrigió, quién y cuándo. Esta es la información más valiosa del sistema entero, y la que más veces se pierde.
• Permisos heredados. Quién puede ver este documento y sus datos extraídos. Los permisos del origen tienen que viajar con el documento; si el sistema documental es más permisivo que la carpeta de la que vino, acabas de crear una fuga silenciosa.
• Retención. Cuánto se guarda y cuándo se borra. Los documentos empresariales suelen traer obligaciones de conservación y de eliminación; ese calendario es una decisión de tu empresa y de sus asesores, pero el sistema tiene que poder ejecutarlo.

Ese registro es también lo que convierte un archivo de documentos en algo consultable después. Cómo se organiza esa capa —dueños, caducidad, alcance— lo tratamos en cómo convertir la documentación interna en conocimiento utilizable.

Checklist antes de dejarlo procesar solo

• Existe una línea base medida del proceso manual: cuántos documentos, cuánto se tarda por documento y con qué tasa de error real.
• Cada campo tiene una clasificación de criticidad y una política escrita de qué pasa cuando su riesgo es alto.
• Está documentado de dónde sale la señal de riesgo de cada campo: puntuación del proveedor, comprobación determinista propia o ambas.
• Si se usa la puntuación del proveedor como umbral, se ha validado contra documentos propios etiquetados, y hay una fecha para repetir esa validación al cambiar de modelo.
• Los campos críticos e irreversibles tienen al menos una comprobación determinista de negocio que no depende de ningún modelo.
• Los umbrales están firmados por quien responde del error, no fijados por defecto.
• Cada valor extraído es rastreable hasta su posición en el documento original.
• Existe una clase «desconocido» con destino propio; ninguna clasificación cae en un valor por defecto silencioso.
• La escritura en el sistema destino es idempotente y reversible, con huella del documento como clave.
• El camino de excepción tiene motivo legible, dueño, prioridad y capacidad estimada con números propios.
• Las correcciones humanas se guardan como conjunto de regresión versionado.
• Los permisos del origen viajan con el documento y con sus datos extraídos.
• Hay alertas sobre la tasa de excepción por remitente y sobre el deterioro de las señales de riesgo que sí se estén midiendo.
• Está definido qué hace el sistema si el proveedor de extracción no responde, y se ha probado con el proveedor caído.
• Hay criterio escrito de vuelta atrás y una persona con autoridad para ejecutarlo.

La primera casilla es la que más se salta y la que más cara sale. Sin línea base no hay forma honesta de decir si el sistema mejoró algo: solo de decir que ahora hay un sistema. Cómo se construye esa comparación está en cómo probar una automatización antes de llevarla a producción.

Cómo sale a producción

Igual que cualquier automatización que decide sobre algo real, y por las mismas razones: en sombra primero —el sistema procesa y no escribe nada, se compara con lo que hizo la persona—, después sobre una porción acotada con revisión reforzada, y solo entonces al alcance completo.

Con documentos hay un matiz propio: la etapa en sombra es especialmente barata y especialmente informativa, porque los documentos ya existen. Se puede procesar un histórico de meses en unos días y comparar contra los datos que ya están en el ERP. Es la única forma honesta de conocer el comportamiento real del sistema con tus documentos, no con los del folleto de nadie.

Lo que esto no resuelve

No arregla un proceso mal definido. Si hoy dos personas del equipo rellenan el mismo campo de forma distinta, automatizarlo solo hace que la inconsistencia ocurra más rápido y con menos testigos.

No sustituye la revisión legal o de cumplimiento cuando el documento la requiere —conservación, protección de datos, validez de la firma—; esa evaluación es de tu empresa y de sus asesores.

Y no elimina el error. Lo hace visible, acotado y reversible, que es lo único que un sistema documental honesto puede prometer.

Siguiente paso

Si lo que hay que construir es el sistema —captura, extracción, excepciones y la interfaz de revisión que lo hace sostenible—, ese trabajo es Productos digitales. Si la duda es todavía qué parte del proceso documental merece automatizarse y con qué controles, empieza por Transformación con IA. Cuéntanos tu reto.