Cualquier empresa manufacturera de tamaño medio en SK/UE procesa decenas o cientos de documentos en papel o escaneados al día: facturas de proveedores, pedidos de clientes, albaranes, declaraciones aduaneras, planos técnicos acotados. Y en la mayoría de los casos, en algún lugar hay un empleado que transcribe manualmente los valores al ERP, al SAP o a Excel. No es un problema que las empresas ignoren — es un problema que hasta ahora no les resultaba rentable resolver de otra manera.
En 2026 eso ha cambiado. Los sistemas modernos de inteligencia documental — combinación de OCR (reconocimiento óptico de caracteres), modelos vision-language y lógica de validación — son capaces de procesar documentos estructurados y semiestructurados con una precisión que la transcripción manual no alcanza. Este artículo explica dónde merece la pena aplicar esta tecnología, cómo es un despliegue real y cuáles son los límites que ningún material de marketing menciona.
Por qué el OCR clásico no es suficiente
Cuando la mayoría de la gente oye «OCR», piensa en Tesseract o Adobe Acrobat — herramientas que convierten texto escaneado en texto editable. Para casos sencillos es suficiente. Para documentos industriales, no.
Los problemas aparecen en varios niveles a la vez:
- El escaneo borroso o torcido de una factura enviada por fax hace treinta años desestabiliza el OCR clásico mucho más que un modelo VLM moderno.
- Las tablas, las cotas y los esquemas son un punto ciego para el OCR basado en texto: se obtienen los caracteres correctos, pero se pierde la estructura de la que depende el significado.
- La variabilidad de formatos: cada proveedor tiene su propia plantilla de factura. Las soluciones OCR clásicas lo resuelven con reglas de extracción configuradas para cada plantilla — lo que, con decenas de proveedores, implica decenas de plantillas y mantenimiento permanente.
- El sentido contextual: el número «1500» en la esquina inferior derecha de una página puede ser el número de página, el número de pedido o el importe en euros — sin contexto, el OCR clásico no puede distinguirlo.
Los modelos VLM modernos (vision-language model, por ejemplo Qwen2.5-VL) resuelven este problema de otra manera: no solo leen caracteres, comprenden la disposición del documento y su contexto. Es un salto cualitativo, no meramente evolutivo.
Cómo es un pipeline de inteligencia documental
Un pipeline industrial real para el procesamiento de documentos consta de varias capas. Cada una de ellas puede ser un punto de fallo si se subestima.
1. Ingesta y normalización
El documento llega como PDF escaneado, fotografía desde el móvil, email con adjunto o salida EDI de un sistema heredado. El primer paso es la conversión a un formato interno unificado — con metadatos (origen, fecha de recepción, tipo de documento).
Aquí se esconde un problema oculto: en fotografías tomadas en campo, la calidad de la entrada es extremadamente variable. Imágenes borrosas, con sombras, dobladas — el VLM lo gestiona mejor que el OCR clásico, pero no infinitamente mejor. La calidad de la entrada sigue limitando la calidad de la salida.
2. Clasificación del documento
Antes de iniciar la extracción, el sistema debe saber qué está procesando. Una factura, un pedido, un albarán y un plano técnico requieren esquemas de extracción distintos. Un clasificador (ya sea un modelo ligero o lógica de reglas sobre la estructura del documento) asigna el documento a la categoría correcta.
3. Extracción estructurada
El núcleo del pipeline: se extraen valores del documento según un esquema predefinido. Para una factura, estos son habitualmente:
- Número de factura, fecha de emisión, fecha de vencimiento
- CIF/NIF del proveedor y del cliente
- Líneas de pedido (descripción, cantidad, unidad, precio sin IVA, IVA, precio con IVA)
- Importe total, número de cuenta bancaria, referencia de pago
Los modelos VLM hacen esto directamente — reciben como entrada la imagen o el PDF y devuelven un JSON según el esquema indicado. La salida corresponde al concepto de structured outputs y JSON mode — el modelo produce únicamente JSON válido con los campos definidos.
Para los planos técnicos la situación es más exigente: las cotas, las tolerancias y las especificaciones de materiales están distribuidas en el contexto geométrico del esquema. Los modelos VLM-72B han avanzado notablemente en este aspecto, pero para documentos técnicos de precisión se recomienda contar con un humano en el bucle para la verificación final de los valores críticos.
4. Validación y verificación cruzada
Los valores extraídos se someten a varias capas de validación:
- Consistencia matemática: la suma de las líneas debe coincidir con el importe total; el IVA debe corresponder al tipo indicado.
- Validación de referencias: el número de pedido que figura en la factura debe existir en el ERP; el CIF del proveedor debe estar en la base de datos de proveedores aprobados.
- Validación de rangos: el importe de la factura dentro del rango habitual para ese proveedor (las anomalías van a revisión manual).
Esta capa de validación es fundamental. En la práctica hemos visto casos en los que el modelo extrajo correctamente los números del documento, pero el importe de la factura no coincidía con la suma de las líneas — el error estaba en el documento original, no en la extracción. Sin validación, el ERP contendría datos inconsistentes.
5. Integración en el ERP y el workflow
Los registros validados se transfieren al ERP vía API. Los documentos con baja confianza (el modelo no está seguro del valor) o con validación fallida van a una cola de revisión manual — con el campo concreto en el que hay un problema claramente señalado.
Este es el enfoque correcto: no automatización total, sino automatización asistida con un human-in-the-loop claro allí donde existe incertidumbre.
Dónde merece la pena automatizar y dónde no
No todos los tipos de documentos son igual de adecuados para la automatización. A partir de despliegues reales podemos afirmar:
Muy adecuados: - Facturas de proveedores recurrentes (el sistema «aprende» el formato) - Formularios de pedido estandarizados (propios y de socios comerciales) - Albaranes con códigos de barras o QR (enfoque híbrido OCR + código de barras) - Certificados de materiales con estructura definida
Adecuados con reservas: - Facturas de nuevos proveedores (el primer procesamiento requiere mayor supervisión) - Pedidos recibidos por email en texto plano o HTML — aquí un LLM sobre el cuerpo del email puede funcionar mejor que el OCR sobre una imagen - Fichas técnicas con tablas de parámetros
Menos adecuados sin una solución específica: - Documentos escritos a mano, faxes antiguos de baja calidad - Planos técnicos con esquemas geométricos complejos y tolerancias — la extracción funciona, pero requiere verificación - Contratos y documentos jurídicos con estructura compleja (aquí es más valioso un LLM sobre documentación industrial que un pipeline OCR puro)
Decisiones técnicas — cloud vs. on-prem
La mayoría de las empresas con las que trabajamos se enfrenta a la misma pregunta: ¿API en la nube o instalación propia?
API cloud (Azure AI Document Intelligence, Google Document AI, AWS Textract): - Arranque rápido, sin infraestructura propia - Modelo de pago por página — con volúmenes elevados (decenas de miles de documentos al mes) los costes pueden ser significativos - Las facturas y los pedidos contienen datos sensibles para el negocio — en sectores regulados o con política interna de GDPR, la nube es problemática
VLM on-prem (p. ej. Qwen2.5-VL-72B cuantizado):
- Control total sobre los datos — sin egress
- Requisitos elevados de VRAM: un modelo de 72B requiere una configuración multi-GPU (del orden de 40+ GB de VRAM para la inferencia)
- Inversión inicial en hardware y, a partir de ahí, coste marginal prácticamente nulo al escalar el volumen
Para la mayoría de las empresas industriales de la UE, el argumento on-prem es sólido si se dispone de volumen suficiente (del orden de miles de documentos al mes). Para volúmenes menores o para un arranque rápido, la API cloud puede ser un trampolín razonable con un plan de migración.
Integración con salidas estructuradas y ERP
El detalle crítico en este pipeline es la fiabilidad del formato de salida del LLM. Un modelo que una vez devuelve JSON limpio y otra vez devuelve el JSON envuelto en un bloque markdown resulta inutilizable para una integración automatizada.
Los modelos modernos soportan constrained decoding — el modelo genera tokens de acuerdo con un esquema JSON definido, por lo que físicamente no puede devolver un JSON inválido. Esto es una necesidad, no una opción, para despliegues en producción. Más información en el artículo Structured outputs y JSON mode.
Para la integración con el ERP rige la siguiente regla: nunca escribir directamente al ERP desde el modelo de IA. El patrón estándar es:
- 1.La IA extrae y valida → resultado a la tabla de staging
- 2.Las reglas de validación (script o workflow engine) comprueban la consistencia
- 3.Si todo es correcto → importación automática al ERP; si hay incertidumbre → cola para revisión humana
- 4.El revisor humano ve el documento, los valores extraídos y el campo concreto con el problema
Este patrón preserva la auditabilidad e impide que se dañen silenciosamente los datos del ERP.
Planos y documentación técnica
Los planos técnicos constituyen una categoría aparte — DXF, PDF con geometría, esquemas de conexiones. El OCR tradicional es aquí prácticamente inutilizable, porque la mayor parte de la información reside en las relaciones entre los elementos gráficos, no en el texto en sí.
Los modelos VLM modernos son capaces de extraer de un plano técnico: - Cotas y tolerancias (con una precisión que depende de la calidad de la entrada) - Descripción de materiales y acabados superficiales - Números de pieza y revisiones
Dónde sigue siendo necesaria la supervisión humana: tolerancias de seguridad críticas, esquemas de instalación eléctrica para entornos ATEX, documentos para procesos de certificación. En este ámbito, la IA actúa como asistente, no como decisor autónomo — de manera similar a como ocurre con el AI Copilot para operadores, donde el modelo reduce la carga de trabajo pero no sustituye la responsabilidad.
Errores frecuentes en el despliegue
Para cerrar la parte técnica — los problemas que observamos repetidamente:
«Lo desplegamos y nos olvidamos» — un pipeline de inteligencia documental necesita monitorización. Un nuevo proveedor con una plantilla de factura inusual hará bajar el confidence score y enviará el documento a la cola manual; eso está bien, pero la cola debe vigilarse.
Subestimar la variabilidad — en el piloto se prueban 50 facturas de 5 proveedores. En producción hay 500 proveedores, algunos de los cuales cambian sus plantillas sin previo aviso. Hay que probar con una muestra diversa, no con casos «limpios».
Confidence scores sin calibración — el modelo indica una certeza de extracción, pero estos scores están calibrados sobre los datos de entrenamiento, no sobre los documentos propios. Durante las primeras semanas en producción, conviene observar dónde el modelo declara estar «seguro» y dónde se equivocó — y ajustar en consecuencia los umbrales para la revisión manual.
Ignorar los casos extremos — ¿qué ocurre si llega una factura en alemán? ¿O un documento con dos facturas en un mismo PDF? Estos casos hay que definirlos e implementarlos explícitamente, no confiar en que el modelo los resolverá por sí solo.
Preguntas frecuentes
¿Qué precisión alcanzan los sistemas modernos de extracción de facturas?
Para facturas estructuradas de proveedores recurrentes, los pipelines VLM modernos alcanzan en la práctica una precisión del 95–99 % en los campos clave (número de factura, importe, fecha). Para formatos nuevos o no estándar, la precisión es menor — de ahí la importancia crítica de la capa de validación y la cola de revisión manual. Los números de los materiales de marketing (99,9 %) provienen habitualmente de pruebas controladas, no de despliegues reales en producción con toda la variabilidad de entradas.
¿Se necesita GPU para la inteligencia documental?
Para las API cloud, no — se paga por llamadas a la API. Para despliegues on-prem con modelos VLM (70B+), sí — se necesitan del orden de 40+ GB de VRAM para latencias de inferencia razonables. Los modelos más pequeños (7–14B) caben en una RTX 4090 (24 GB de VRAM con cuantización), pero con menor precisión en documentos técnicos complejos. Para facturas y pedidos, un modelo de 7B ofrece buen rendimiento.
¿Podemos conectar esto a nuestro SAP / Pohoda / otro ERP existente?
Sí — el pipeline de inteligencia documental produce JSON estructurado que puede importarse vía API del ERP o a través de interfaces de integración estándar (REST, IDOC para SAP, importación CSV para sistemas más sencillos). La integración en sí no es el problema; el trabajo más importante está en definir la lógica de staging y las reglas de validación específicas para los procesos de negocio propios.
¿Qué ocurre con los documentos en distintos idiomas (alemán, polaco)?
Los modelos VLM modernos son multilingües y gestionan la mayoría de los idiomas europeos sin configuración especial. Las reglas de validación (p. ej. formato de CIF, IBAN) deben configurarse por país. Si se procesan grandes volúmenes de un país concreto, conviene verificar la precisión sobre muestras reales — el rendimiento no siempre es uniforme entre idiomas.
¿Cuánto tiempo lleva la implementación?
Un piloto sencillo sobre un tipo de documento (p. ej. facturas de los 20 principales proveedores) puede ponerse en marcha en 4–6 semanas. Un despliegue completo en producción con integración en el ERP, monitorización y cobertura de todos los tipos de documentos se sitúa en el rango de 3–6 meses, según la complejidad del entorno y el número de puntos de integración.
*MP Industrial Solutions ayuda a las empresas a pasar de la transcripción manual de documentos a un flujo automatizado y verificable — desde el piloto sobre un tipo de factura hasta el despliegue en producción con integración en el ERP. Si está abordando la inteligencia documental o está valorando por dónde empezar, estaremos encantados de analizar su caso concreto.*