Automatización documental por sector: qué se productiza para todos y qué exige configuración
Aduanera del Estrecho, S.L. es un agente de aduanas de 34 empleados en Algeciras que despacha entre 1.100 y 1.400 expedientes al mes. Cada expediente lleva de siete a doce documentos: factura comercial, packing list, CMR, DUA, certificado de origen, ficha técnica, autorización sanitaria si toca, análisis de laboratorio si toca. En 2024 el equipo administrativo tardaba una media de 23 minutos por expediente solo en leer, extraer datos y meterlos en el ERP. Hicieron números: 460 horas al mes solo en teclado.
Contrataron un proveedor de "automatización documental" que les prometió reducir un 80% ese tiempo con un modelo entrenado en 2.000 documentos. A los seis meses habían automatizado bien la extracción de facturas y CMR, pero los DUA seguían pasando por manos humanas porque el modelo no sabía qué hacer con las partidas TARIC de nueve dígitos, ni con los códigos de régimen aduanero, ni con las diferencias entre un DUA de importación y uno de tránsito comunitario. El proveedor decía que "solo había que reentrenar". El director de operaciones decía que "solo había que devolver el dinero".
El problema no era el modelo. El problema era pensar que un sistema documental se productiza entero.
No.
En automatización documental hay tres capas que sí se productizan y funcionan igual para casi cualquier cliente: la extracción base, la clasificación por tipo y la indexación. Y hay tres capas que exigen configuración por cliente sí o sí: el vocabulario, las reglas de validación y los flujos de aprobación. Confundirlas es lo que hace fracasar la mayoría de los proyectos de IDP (Intelligent Document Processing) que arrancan cada año en pymes españolas de servicios.
Este post separa las seis capas. Sin vender producto. Sin promesas de "reducción del 90%". Con nombres concretos de qué hace cada pieza y qué hay que preguntar antes de firmar el contrato.
OCR, extracción, clasificación e indexación: cuatro cosas distintas
Aquí empieza el lío. El vendedor medio de software documental usa las cuatro palabras como sinónimos y luego el cliente descubre que le han vendido una y necesitaba las cuatro.
OCR (Optical Character Recognition). Convierte una imagen o PDF escaneado en texto plano. Nada más. Un OCR bueno reconoce 99,5% de los caracteres en documentos limpios y baja al 92-94% en documentos con ruido, sellos superpuestos o firmas manuscritas encima. Un OCR no entiende qué es una factura ni dónde está el NIF. Solo lee.
Extracción con esquema. Toma el texto que sale del OCR y le aplica un modelo que sabe qué campos buscar. Ejemplo: dado el texto de una factura, devuelve emisor, NIF, fecha, base imponible, IVA, total y líneas de detalle. La extracción funciona con dos técnicas: reglas basadas en posición o expresiones regulares (buenas para formatos estables) y modelos de visión más lenguaje entrenados en documentos similares (buenos para formatos variables). Un IDP serio combina ambas.
Clasificación semántica. Antes de extraer, el sistema tiene que saber qué tipo de documento está mirando. ¿Es una factura, un albarán, un contrato, un certificado? La clasificación devuelve una etiqueta y una probabilidad. En documentos financieros estándar ronda el 97-99% de acierto. En documentos técnicos o sectoriales sin entrenamiento específico baja al 70-80%.
Indexación. Guarda el documento en un repositorio con metadatos estructurados para que se pueda buscar y recuperar después. Los metadatos vienen de la extracción (fecha, importe, proveedor) y de la clasificación (tipo). La indexación es la capa más aburrida y la que más ROI da a los tres años, cuando el equipo de auditoría pide en 30 segundos algo que antes tardaba tres días en aparecer.
Traducción: OCR lee, clasificación etiqueta, extracción llena campos, indexación archiva. Un proyecto que solo compra OCR no tiene automatización, tiene lectura. Un proyecto que solo compra extracción sin clasificación va a devolver campos mezclados de documentos distintos. Un proyecto sin indexación gana tiempo en seis meses y pierde información en dos años.
Qué se productiza igual para todos los clientes
Estas tres capas ya vienen resueltas de fábrica en cualquier motor serio del mercado (AWS Textract, Google Document AI, Azure Form Recognizer, ABBYY, Rossum, Docsumo, y en la práctica también en frameworks open source como LayoutLM o Donut). No tiene sentido reinventarlas por cliente.
Extracción de campos genéricos en documentos comunes. Fecha, importe, NIF/CIF, IBAN, dirección postal, número de factura, número de expediente. En facturas españolas estándar, los motores comerciales llegan al 96-98% de precisión sin ningún entrenamiento adicional. Reentrenar para subir del 96 al 97,5 cuesta más que aceptar la revisión manual del 2-4% que falla.
Clasificación por tipo estándar. Factura, albarán, contrato, DNI, pasaporte, extracto bancario, nómina. Los motores vienen con clasificadores preentrenados en decenas de miles de ejemplos. Para una pyme que trabaja con estos tipos, no hay que hacer nada específico.
Indexación con metadatos básicos. Guardar el documento con fecha, tipo, emisor y un ID único. Cualquier gestor documental razonable (Alfresco, Nuxeo, M-Files, incluso SharePoint bien configurado) hace esto sin desarrollo específico.
Regla: si tu proveedor te cobra desarrollo a medida para leer facturas españolas, extraer NIF y guardarlas en un repositorio con fecha e importe, te está cobrando por algo que ya existe. Estás pagando integración, no producto.
Contexto: el precio de mercado para automatizar la entrada de facturas de proveedor en una pyme que procesa entre 500 y 2.000 al mes está publicado por empresas como Cero Ideas y Davisa en rangos que no requieren desarrollo específico. Si el presupuesto que te pasan multiplica ese rango por tres, pide desglose y compara.
Qué exige configuración por cliente, siempre
Aquí es donde se juegan los proyectos. Estas tres capas no se productizan porque dependen del negocio concreto, del sector y hasta del equipo que va a usar el sistema.
Vocabulario. Cada sector tiene sus propios términos, códigos, siglas y jerga. Un centro de salud rural que recibe 300 informes de radiología al mes necesita que el sistema entienda CIE-10, códigos de procedimiento y nombres de equipos médicos específicos. Una consultoría administrativo que gestiona certificados urbanísticos necesita códigos de calificación de suelo del PGOU concreto del ayuntamiento donde opera. Una fintech de nóminas necesita códigos de conceptos salariales que varían por convenio colectivo. Un motor genérico no sabe nada de esto por diseño. Alguien tiene que enseñárselo. Y ese alguien no es el proveedor solo, es el proveedor con el cliente sentado al lado durante semanas.
Reglas de validación. El sistema puede extraer un campo perfectamente y aun así ese campo estar mal para tu negocio. Ejemplo real: Aduanera del Estrecho extrae el peso bruto de una factura comercial. El OCR lo lee bien. El campo está bien. Pero el peso bruto de la factura tiene que coincidir con el peso bruto del CMR con un margen de tolerancia del 2%, y si no coincide, no se puede presentar el DUA. Esa regla no la sabe ningún motor de mercado. La configura el cliente.
Flujos de aprobación. Qué documento va a qué persona, con qué SLA, con qué escalado si no responde en X horas. Una gestoría con 200 clientes tiene una jerarquía. Un hospital tiene otra. Una empresa de logística tiene otra. Los flujos no son técnica de IA, son procesos de negocio, y siguen exigiendo entrevista con jefes de departamento, mapa BPMN y ajuste iterativo durante los primeros tres meses.
Traducción: paga producto para las tres primeras capas y paga configuración para las tres siguientes. Si el proveedor te vende todo como "producto" y te presenta un precio cerrado sin diagnóstico, es que aún no sabe lo que va a hacer y te lo va a facturar como cambios.
Revisión humana: la puerta de calidad que casi todos saltan
En un proyecto de automatización documental serio, el flujo no es "el sistema extrae y guarda". El flujo es "el sistema extrae, marca su nivel de confianza y solo pasa a producción lo que supera un umbral. El resto va a revisión humana antes de subirse".
Este patrón se llama human in the loop y no es opcional. Es la única forma de mantener calidad por encima del 99% en producción sin dinamitar el ROI.
Cómo funciona en la práctica. Cada campo extraído lleva asociada una probabilidad de acierto entre 0 y 1. Se define un umbral, por ejemplo 0,92. Los campos por encima del umbral se aceptan automáticamente. Los que están por debajo entran en una cola de revisión donde una persona ve el documento original, el valor extraído, y confirma o corrige.
Qué se gana. Trazabilidad de qué se ha revisado y qué no. Datos etiquetados por humanos que sirven para reentrenar y subir la precisión con el tiempo. Errores detectados antes de contaminar el ERP o el CRM.
Qué se pierde si se salta. Errores silenciosos que aparecen tres meses después en una auditoría, cuando el jefe de contabilidad descubre que 47 facturas tienen el importe cambiado por un dígito porque el OCR confundió un 3 con un 8 en documentos con sello superpuesto. Duele, pero es información.
Un proyecto sin revisión humana no es más automatizado. Es más rápido en fallar sin que nadie se entere.
En Aduanera del Estrecho, cuando rediseñaron el flujo pusieron el umbral en 0,90 para campos no críticos (fecha, importe) y en 0,98 para campos críticos (TARIC, régimen aduanero, país de origen). El resultado: el 68% de los documentos pasa sin tocar, el 32% entra en revisión, y el equipo administrativo pasó de 460 horas al mes a 140 horas al mes. Un 70% de reducción, medido en horas, sostenido a los 18 meses.
Precisión y recall: las dos métricas que tienen que ir al contrato
La mayoría de los contratos de automatización documental hablan de "precisión superior al 95%" y punto. Ese contrato está mal escrito. La precisión sola miente. Hay que pactar precisión y recall por tipo de documento y por campo crítico.
Precisión. De todo lo que el sistema ha extraído, qué porcentaje es correcto. Un sistema con 99% de precisión pero que solo se atreve a extraer el 40% de los documentos y devuelve el resto como "no puedo" no te sirve para automatizar. Te sirve para saber cuándo pedir ayuda.
Recall. De todo lo que había que extraer, qué porcentaje se ha extraído. Un sistema con 99% de recall que devuelve todos los campos pero se inventa el 15% no te sirve tampoco. Te sirve para meter basura rápido.
Regla: pacta precisión y recall por campo. Y pacta que se midan sobre un conjunto de test que tú entregas, no sobre uno que elige el proveedor.
Ejemplo de cláusula útil en un contrato con un proveedor de IDP para una gestoría que procesa 3.000 facturas al mes:
El sistema debe alcanzar, en el conjunto de test proporcionado por el CLIENTE (250 facturas anonimizadas representativas del volumen mensual), precisión mínima del 98% y recall mínimo del 95% en los campos NIF, fecha, base imponible, IVA y total. En caso contrario, el CLIENTE puede rescindir sin penalización durante los primeros 90 días de operación.
Ese párrafo cambia por completo el proyecto. El proveedor deja de vender humo y empieza a preguntar por los datos reales antes de firmar. Es exactamente lo que quieres que pase.
F1 score. Media armónica de precisión y recall. Es la métrica única que suele aparecer en papers y en herramientas de benchmarking. Si tu proveedor te da solo F1, pide el desglose. F1 de 0,96 puede ser 98% precisión y 94% recall (bueno) o 92% precisión y 100% recall (peligroso, mucho falso positivo).
Cuándo un diccionario resuelve mejor que un modelo
Este apartado es el que menos aparece en las propuestas comerciales y el que más dinero ahorra. Hay problemas de extracción documental que no requieren un modelo entrenado. Requieren un diccionario y una regla.
Códigos cerrados. Si el campo a extraer es un código de una lista finita y conocida (TARIC, CNAE, CPV, IBAN de un banco español, provincia por código postal), no entrenes un modelo. Extrae el texto, aplica un patrón regex y valida contra el diccionario. Es más rápido, más barato, y tiene 100% de precisión si el texto está bien leído.
Nombres de proveedores frecuentes. Si tu empresa tiene 200 proveedores fijos que representan el 90% de las facturas, no entrenes un modelo que "identifique el emisor". Mantén una tabla de proveedores con NIF, nombre y variantes de escritura del nombre (con y sin acentos, con y sin S.L., abreviaturas). El sistema busca coincidencia en la tabla antes de recurrir al modelo. Cubres el 90% con una tabla que se mantiene sola. Solo el 10% restante entra en el modelo.
Formatos regulados. DNI, NIE, IBAN, número de la Seguridad Social, matrícula de vehículo, matrícula sanitaria (por ejemplo, los números que empiezan por rangos 01000-52999 para colegiados médicos según provincia). Todo esto tiene formato oficial documentado. Un regex bien hecho lo valida al 100%. Un modelo entrenado en documentos con estos campos suele bajar al 96-97% y añade coste de mantenimiento. No compensa.
Sinónimos por vocabulario. Si en tus documentos "pza.", "unidad" y "ud." significan lo mismo, mantén una tabla de sinónimos. No entrenes un modelo para que aprenda que son equivalentes. La tabla se edita en cinco minutos por el equipo de operaciones. El modelo tarda semanas en reentrenar y aprender lo mismo.
Traducción: no todo problema documental es un problema de IA. La mitad son problemas de tabla, regex y disciplina. Si un consultor te vende IA para lo que resuelve un diccionario, cámbialo.
Errores frecuentes en proyectos documentales
Error 1: Entrenar el modelo con documentos "limpios" que la empresa proporciona. Síntoma: en piloto funciona al 98%, en producción baja al 82%. Solución: entrena y evalúa siempre con muestras reales aleatorias de al menos 30 días de operación, incluyendo los peores documentos (fotos desde el móvil, PDFs escaneados torcidos, faxes viejos, documentos con anotaciones a mano). Si el proveedor no acepta trabajar con esos, no tienes proyecto, tienes demo.
Error 2: Pactar solo precisión sin recall. Síntoma: el sistema no falla, pero cubre solo el 40% de los documentos y el equipo sigue tocando el 60%. Solución: pactar ambas métricas por campo crítico y umbral mínimo para automatización sin revisión.
Error 3: No definir umbral de confianza y flujo de revisión. Síntoma: campos con confianza del 55% entran directos al ERP con el mismo peso que campos con confianza del 99%. A los tres meses hay ruido masivo en los datos. Solución: definir umbral por campo, cola de revisión, y KPI mensual de "documentos revisados sobre total procesado".
Error 4: Meter clasificación semántica pesada donde un diccionario resuelve. Síntoma: el proyecto se alarga tres meses de más y el proveedor cobra "consultoría de datos" para etiquetar lo que ya viene etiquetado en un maestro del ERP. Solución: auditar primero qué campos son cerrados y resolverlos con tablas antes de tocar modelos.
Error 5: No pactar propiedad del modelo reentrenado. Síntoma: llevas 18 meses etiquetando datos con tu equipo, el proveedor tiene un modelo excelente entrenado con tu esfuerzo, y cuando quieres cambiar de proveedor el modelo se queda con él. Solución: cláusula explícita de propiedad de datos etiquetados y de los pesos del modelo si aplica, con derecho a exportar en formato estándar (por ejemplo, COCO o JSON con esquema documentado).
Las tres decisiones de arquitectura que casi todos equivocan
Cuando un proyecto documental fracasa a los 12 meses, en la mayoría de casos el diagnóstico se resume en tres decisiones mal tomadas al principio. Se toman rápido, con presión comercial, y luego cuestan un rediseño completo.
Decisión 1: motor comercial cerrado o motor abierto con integración propia. Comercial (Textract, Document AI, Rossum) es rápido de arrancar, pero te ata a su precio por página y a sus límites de personalización. Abierto (Donut, LayoutLM, Nougat, PaddleOCR) requiere más ingeniería inicial pero baja el coste marginal a casi cero y te permite reentrenar sin permisos de nadie. Regla: si vas a procesar menos de 50.000 páginas al año, comercial. Por encima, evalúa abierto en serio.
Decisión 2: reprocesado en lotes o streaming. El reprocesado significa que los documentos se acumulan en un buzón y se procesan en tandas cada X horas. El streaming significa que cada documento se procesa en cuanto llega. El reprocesado es más simple, más barato, y suficiente para el 90% de los casos operativos (contabilidad, RRHH, contratos). El streaming solo tiene sentido cuando hay un SLA de negocio que exige respuesta en minutos (atención al cliente, incidencias en tiempo real). Muchos proyectos arrancan con streaming por moda técnica y pagan el triple sin necesidad.
Decisión 3: dónde vive el dato extraído. En el gestor documental, en el ERP, en una base de datos aparte o en los tres a la vez. Elegir "los tres a la vez" es lo que suena razonable en reunión y lo que garantiza inconsistencias en año 2, cuando el mismo campo tiene tres valores distintos en tres sistemas y nadie sabe cuál es la fuente de verdad. Regla: define fuente única de verdad por campo antes de conectar sistemas. Y documenta esa decisión con nombre y firma, para que en dos años alguien pueda encontrarla.
Preguntas frecuentes
¿Qué se puede automatizar de verdad en la gestión documental de una empresa?
La extracción de campos genéricos en documentos estándar (facturas, contratos, albaranes, DNI, extractos bancarios) se automatiza al 95-98% sin desarrollo específico usando motores comerciales o abiertos. La clasificación por tipo de documento se automatiza al 97-99% en categorías comunes. La indexación con metadatos básicos se automatiza al 100%. Lo que no se automatiza al 100% es la validación contra reglas de negocio, el vocabulario específico del sector y los flujos de aprobación jerárquicos, que exigen configuración por cliente y revisión humana como puerta de calidad.
¿Qué diferencia hay entre OCR, extracción y clasificación de documentos?
OCR convierte una imagen o PDF en texto plano. No entiende qué es cada cosa. Clasificación etiqueta el documento por tipo (factura, contrato, DNI) para que el resto del pipeline sepa qué hacer con él. Extracción toma el texto y devuelve campos estructurados según un esquema definido (emisor, fecha, importe, líneas de detalle). Son tres etapas encadenadas, no sinónimos. Un sistema puede tener OCR perfecto y extracción mala si el modelo de extracción no está entrenado en tu tipo de documento.
¿Cómo se aborda un proyecto de automatización documental sin caer en la plantilla?
En tres pasos. Primero, auditoría de tipología documental con muestras reales de 30 días, no las que elige el proveedor. Segundo, separación explícita de qué se productiza y qué se configura, con precio distinto para cada bloque. Tercero, contrato con métricas de precisión y recall por campo crítico, medidas sobre un conjunto de test que aporta el cliente, con derecho de rescisión si no se cumplen en los primeros 90 días. Cualquier propuesta sin estos tres pasos es plantilla, aunque cambien el logotipo.
¿Qué parte de un flujo documental sigue necesitando persona?
Tres partes. La revisión humana de campos por debajo del umbral de confianza (entre el 20% y el 40% del volumen en proyectos maduros). La resolución de excepciones que las reglas de validación marcan como conflictivas (documentos duplicados, incoherencias entre campos, sellos y firmas que requieren interpretación). La aprobación jerárquica de documentos con impacto legal o financiero superior a un umbral definido por el negocio. Automatizar la extracción no elimina el trabajo humano, lo desplaza a las excepciones y a la calidad.
¿Cuánto tiempo tarda en amortizarse un proyecto de IDP en una pyme?
Depende del volumen. En una pyme que procesa entre 1.000 y 3.000 documentos al mes con equipo administrativo dedicado, el punto de equilibrio suele estar entre los 8 y los 14 meses si el proyecto está bien acotado. Si el proyecto incluye "consultoría estratégica", "transformación digital" o "revisión de procesos completa" en el mismo presupuesto, la amortización se va más allá de los 24 meses y el ROI queda diluido en trabajo que no era automatización.
¿Qué formatos de documento son más difíciles de automatizar?
Los tres formatos que más ruido dan en producción son los faxes escaneados con sellos superpuestos sobre los campos clave, los PDFs generados por escaneo desde móvil con perspectiva y sombras, y los documentos con anotaciones manuscritas encima de texto impreso. En estos casos la precisión de OCR cae al 85-90% y hay que combinar preprocesado de imagen (deskew, denoise, sharpening) con revisión humana obligatoria para los campos críticos. No hay motor mágico que resuelva estos casos al 99%. Quien te lo prometa no ha entrado nunca en un archivo real.
Cierre
Aduanera del Estrecho no automatizó porque encontrara la herramienta perfecta. Automatizó porque separó las seis capas, entendió qué compraba de fábrica y qué tenía que configurar, pactó métricas medibles con el proveedor y mantuvo revisión humana como puerta de calidad. Pasó de 460 horas al mes a 140 en año y medio. No es magia. Es disciplina de proyecto.
La mayoría de proyectos documentales que fracasan lo hacen por comprar "todo integrado" cuando la realidad es que la mitad es producto y la mitad es configuración. Si el proveedor no te separa ambas cosas en la propuesta, pídelo por escrito. Y si no puede, cambia de proveedor.
Si quieres revisar tu volumen documental, identificar qué capas se productizan en tu caso y cuáles exigen configuración, y salir con un mapa realista de lo que puedes automatizar en 90 días, reserva una sesión de 30 minutos o mira la página de automatización documental para empresas para ver cómo se aborda cada sector.
Próximos artículos de la serie cuerpos verticales por sector:
- Automatización de tesorería y conciliación bancaria: qué se productiza y qué toca a medida
- Automatización de contratación pública: verticalidad real frente a pintura vertical
- Automatización sanitaria: por qué el vocabulario clínico se paga aparte
Lecturas relacionadas:
