El procesamiento inteligente de documentos (IDP, por sus siglas en inglés) convierte facturas, albaranes, contratos y formularios en datos estructurados y validados que tus sistemas usan sin que nadie los teclee. Combina reconocimiento de texto, clasificación, extracción de campos, validaciones de negocio y revisión humana en un mismo flujo. El valor no está en leer el documento, sino en que el dato correcto llegue al ERP con trazabilidad.
En nuestra guía de RPA frente a automatización con IA presentamos el IDP como un caso de automatización inteligente. Aquí vamos más allá: en qué se diferencian el OCR, el IDP con plantillas y la extracción con modelos de lenguaje, qué debe hacer cada paso del flujo, cómo medir la precisión y cómo decidir entre comprar un producto o desarrollarlo.
Qué es el procesamiento inteligente de documentos
No hay una definición legal única, pero las referencias principales coinciden en lo esencial:
- AWS lo describe como la automatización de la grabación manual de datos desde documentos en papel o imágenes de documentos a formato digital, para integrarlos en otros procesos de negocio.
- IBM lo describe como la extracción de datos críticos para el negocio: clasificar los documentos por tipo, sacar los campos clave y dar formato al resultado (a menudo JSON) para los procesos siguientes.
Las dos definiciones acaban en el mismo punto: el dato tiene que alimentar otro proceso. El IDP es un problema de integración, no solo de lectura.
OCR, IDP y extracción con LLM: diferencias
Son capas distintas.
| OCR | IDP con plantillas | Extracción con LLM | |
|---|---|---|---|
| Qué produce | Texto plano a partir de una imagen | Campos con nombre en formatos conocidos | Campos con nombre en cualquier formato, más la clasificación |
| Cómo encuentra un campo | No lo hace: solo lee caracteres | Posición, anclas y reglas por plantilla | Por el significado del contenido |
| Proveedor con formato nuevo | No aplica | Necesita otra plantilla | Suele funcionar sin cambios |
| Fallo típico | Caracteres mal leídos en escaneos malos | Se rompe si cambia la maquetación | Devuelve un valor verosímil pero incorrecto |
| Mejor para | Hacer buscables los escaneos | Mucho volumen de pocos formularios fijos | Muchos formatos, texto libre, contratos |
El OCR (reconocimiento óptico de caracteres) convierte imágenes de texto en texto legible por una máquina. IBM señala que necesita preprocesado, como enderezar escaneos torcidos, y que tiene problemas con fuentes irregulares, baja resolución y fotos de móvil con mala luz. El OCR sabe que en la página pone “1.234,50”, pero no que es el total de la factura.
El IDP con plantillas añade reglas sobre el OCR: el total está debajo de la palabra “Total”, abajo a la derecha. Es preciso y barato por página mientras el formato no cambia.
La extracción con LLM usa un modelo de lenguaje, a veces uno que lee la imagen directamente, para encontrar cada campo por su significado. Funciona con formatos nuevos y con documentos largos como los contratos. Su punto débil es el contrario al de las plantillas: casi nunca falla de forma visible, pero puede devolver un dato incorrecto con total seguridad. Por eso las validaciones y la revisión humana forman parte del diseño, no son un añadido.
En la práctica, la automatización de documentos actual combina las tres: OCR para los escaneos, plantillas o reglas donde el formato es estable y un modelo para el resto.
El flujo de IDP paso a paso
1. Captura
Los documentos llegan por correo, portal de subida, escáner, portal de proveedor o API. La captura debe guardar el archivo original, registrar su origen y fecha, y detectar duplicados (la misma factura enviada dos veces es un error frecuente). La calidad de imagen que entra aquí limita todos los pasos siguientes.
2. Clasificación
El sistema decide qué es cada documento: factura, factura rectificativa, albarán, contrato, documento de identidad. También separa los PDF con varios documentos, por ejemplo diez facturas escaneadas en un solo archivo. Una clase equivocada envía el documento al esquema de extracción equivocado, así que la clasificación necesita su propio umbral de confianza.
3. Extracción
Cada tipo de documento tiene un esquema: los campos que hay que extraer, su formato y cuáles son obligatorios. En una factura, eso es proveedor, NIF, número, fecha, base imponible, tipos de IVA, total y líneas. La extracción de datos de facturas falla sobre todo en las líneas y las tablas.
4. Validación
Los datos extraídos se comprueban con reglas y con los datos que ya tienes:
- Aritmética. Las líneas suman la base y la base más el IVA da el total.
- Datos maestros. El NIF del proveedor existe en el ERP y la cuenta bancaria coincide con la registrada.
- Cruce de documentos. La factura cuadra con el pedido y con el albarán.
- Formato y rango. Las fechas son razonables y el tipo de IVA es uno de los vigentes.
Las validaciones detectan muchos errores del modelo sin que una persona mire nada.
5. Revisión humana
Los casos con poca confianza o que no superan las validaciones van a una bandeja de revisión. La persona ve el documento junto a los campos extraídos, los corrige y aprueba. Las correcciones se registran y sirven como datos de prueba. La revisión debe ser significativa: quien revisa necesita tiempo, contexto y autoridad para rechazar.
6. Exportación al ERP
Los datos aprobados se guardan en el sistema de destino por su API, con idempotencia para que un reintento no cree un registro duplicado. Si no hay API, con una importación de ficheros o, como último recurso, con un robot RPA. Cómo diseñar estas conexiones, los reintentos y la monitorización lo explicamos en integración de sistemas ERP y CRM.
Documentos típicos y qué los complica
| Documento | Datos clave | Dificultad principal |
|---|---|---|
| Facturas recibidas | Proveedor, NIF, importes, impuestos, líneas | Muchos formatos, líneas de detalle, rectificativas |
| Albaranes | Artículos, cantidades, referencia del pedido | Anotaciones a mano, firmas, escaneos malos |
| Contratos | Partes, fechas, importes, cláusulas de renovación y rescisión | Texto largo, cláusulas que remiten a otras |
| Formularios y solicitudes | Datos del solicitante, casillas, anexos | Letra manuscrita, formularios incompletos, datos personales |
Las facturas suelen ser el primer proyecto porque tienen volumen y el resultado se comprueba fácil. Las facturas electrónicas estructuradas (XML) no necesitan IDP: se leen directamente. En España, las próximas obligaciones de factura electrónica llevarán parte de la facturación B2B a formatos estructurados, como explicamos en la guía de integración.
El IDP extrae campos para que un sistema los guarde. Si lo que quieres es responder preguntas sobre un conjunto de documentos, eso es RAG sobre los documentos de la empresa, otra arquitectura.
Cómo medir la precisión
Un “99 % de precisión” de un proveedor no dice nada hasta que sabes qué se ha contado. Mídelo con tus documentos:
- Crea un conjunto de referencia. Toma unos cientos de documentos reales, repartidos por tipos y proveedores, y anota a mano el valor correcto de cada campo.
- Mide por campo, no por documento. La precisión por campo te dice dónde están los errores: el total puede estar bien y las líneas no.
- Mide la precisión por documento. El porcentaje de documentos con todos los campos obligatorios correctos. Esto decide si un documento puede saltarse la revisión.
- Sigue la tasa de proceso directo. El porcentaje de documentos que superan las validaciones y los umbrales y llegan al ERP sin que nadie los toque.
- Mide los errores residuales. Los errores que llegan al ERP después de las validaciones y la revisión. Es el número que cuesta dinero.
- Comprueba la calibración de la confianza. Si el sistema indica confianza alta, esos casos deben estar bien de verdad. Revisa una muestra con regularidad.
Separa los resultados por tipo de documento y por proveedor: una media esconde al proveedor que falla siempre. Repite la evaluación con cada cambio de modelo, instrucciones o reglas.
Comprar o desarrollar a medida
| Opción | Encaja cuando | Vigila |
|---|---|---|
| Producto de IDP del mercado | Documentos estándar, ERP estándar, existe un conector listo | Precio por página con tu volumen, límites en validaciones propias, dónde se tratan los datos |
| APIs de documentos en la nube (Amazon Textract, Google Document AI, Azure AI Document Intelligence) | Tienes equipo de desarrollo y quieres piezas base | Sigues teniendo que construir validación, revisión, exportación y monitorización |
| Flujo a medida | Tipos de documento propios, reglas de negocio complejas, un sistema propio o sectorial como destino | El mantenimiento y la evaluación son tuyos |
Lo que suele determinar el coste: número de tipos de documento y de formatos, extracción de líneas, reglas de validación, interfaz de revisión, cómo se accede al sistema de destino y consumo del modelo o de licencias por página. Pide presupuesto con una muestra de tus documentos, no con un número genérico de páginas.
RGPD y Reglamento de IA
Los documentos están llenos de datos personales: nombres, NIF, firmas, cuentas bancarias. Según el artículo 5 del RGPD, extrae solo los campos que necesitas y fija un plazo de conservación para los originales. Si un proveedor en la nube trata los documentos, actúa como encargado del tratamiento: necesitas un contrato del artículo 28 y saber dónde se procesan los datos.
En el Reglamento de IA, la extracción de datos de documentos suele ser de riesgo mínimo, salvo que su resultado decida sobre personas, por ejemplo en crédito o en selección de personal. En obligaciones del AI Act para empresas tienes la lista de comprobación por caso de uso y la obligación de alfabetización en IA.
Errores frecuentes
- Empezar por el documento más difícil. Empieza por un tipo con volumen y fácil de comprobar.
- No tener conjunto de referencia. Sin él, nadie sabe si un cambio ha mejorado algo.
- Fiarse de la confianza que indica el sistema. Contrástala con resultados reales.
- Descuidar la interfaz de revisión. Si revisar es lento, la bandeja crece y la gente aprueba sin mirar.
- Dejar la exportación para el final. La conexión con el ERP suele llevar más tiempo que la extracción.
Qué hemos construido en LCApps
En LCApps hacemos extracción de datos de documentos: procesamos documentación con IA, extraemos la información relevante del expediente y la volcamos directamente en él, con revisión humana donde el dato es crítico. Diseñamos estos proyectos respetando el RGPD y el Reglamento de IA de la UE.
Preguntas frecuentes
¿El IDP es lo mismo que el OCR?
No. El OCR convierte una imagen en texto. El IDP usa ese texto, o la propia imagen, para clasificar el documento, extraer campos con nombre, validarlos y enviarlos a un sistema.
¿Un LLM sustituye a una plataforma de IDP?
Un modelo puede hacer el paso de extracción. La captura, la validación, la revisión, la exportación y la monitorización siguen siendo necesarias, y son la mayor parte del trabajo.
¿Cuántos documentos necesito para empezar?
Los suficientes para crear un conjunto de referencia que cubra tus tipos de documento principales y tus proveedores más grandes. Empieza por un tipo y amplía el conjunto a medida que añades más.
Conclusión
El procesamiento inteligente de documentos es un flujo, no un modelo: captura, clasificación, extracción, validación, revisión humana y exportación. Mídelo con tus documentos, campo a campo, y júzgalo por los errores que llegan al ERP.
Si tienes un flujo de documentos que todavía depende de grabar datos a mano, cuéntanos qué proceso quieres mejorar y te ayudamos a acotar un piloto.