Delimitar el caso documental y sus clases

«Automatizar documentos» todavía no describe un sistema. Una factura, un contrato, un formulario de alta y un expediente pueden llegar todos en PDF y, sin embargo, exigir datos, controles, responsables y destinos completamente distintos. El punto de partida no es el formato del archivo ni el proveedor de OCR: es la decisión o el trabajo que debe realizarse después de recibir el documento.

Esta lección convierte un conjunto difuso de archivos en un caso documental evaluable. El objetivo es saber qué entra, qué representa cada pieza, qué clases importan, qué información necesita el proceso y qué queda expresamente fuera del primer alcance.

Distingue archivo, documento, paquete y caso

Un error frecuente consiste en asumir que un archivo equivale a un documento. En la práctica pueden existir varias relaciones:

• un PDF puede contener factura, albarán y anexo;
• una factura puede llegar dividida en varias imágenes;
• varios documentos pueden pertenecer a un mismo expediente;
• un mismo documento puede recibirse dos veces por canales diferentes;
• una versión corregida puede sustituir a otra sin que debas perder el historial.

Conviene distinguir cuatro niveles. El archivo físico es el objeto recibido. El documento lógico es la pieza que tiene sentido empresarial. El paquete o expediente agrupa documentos relacionados. El caso de proceso es la unidad cuyo estado debe seguir el workflow.

Esta separación determina qué debes dividir, relacionar, deduplicar y conservar. También evita que la lógica técnica dependa accidentalmente de cómo el remitente decidió empaquetar los archivos.

Parte del resultado operativo

Para cada clase documental pregunta qué ocurre si el procesamiento es correcto. No basta con «extraer datos». El resultado puede ser registrar una factura en el ERP, crear un expediente, verificar que una solicitud está completa, archivar una evidencia o preparar información para una revisión.

Documenta por clase:

1. qué decisión o acción consume el resultado;
2. qué campos son realmente necesarios;
3. qué sistema recibe esos campos;
4. qué comprobaciones deben superarse;
5. qué consecuencia tiene un error;
6. qué evidencia debe conservarse;
7. quién resuelve una excepción.

Si un campo no participa en ninguna decisión, registro, búsqueda o obligación operativa, cuestiona por qué debe extraerse. «Por si acaso» aumenta coste, exposición de datos y superficie de error.

Observa canales y variantes reales

Revisa documentos recientes y registra cómo llegan: correo, portal, carpeta compartida, escáner, API, formulario o carga manual. Para cada grupo observa formato, número de páginas, idioma, orientación, texto digital o imagen, tablas, manuscritos, sellos, anexos, duplicados y calidad de captura.

No uses el formato como clase. PDF, JPG o DOCX describen un contenedor. Una clase operativa debe cambiar el tratamiento: factura, albarán, contrato, identificación, solicitud, certificado o desconocido.

Tampoco presupongas que todos los documentos de una clase comparten plantilla. La variabilidad puede venir del emisor, la época, el canal o la generación manual. Esa diversidad será importante al construir la muestra de evaluación.

Diseña una taxonomía que conduzca a acciones

Una taxonomía útil no intenta describir todo el universo documental. Intenta separar rutas de procesamiento.

Si dos clases utilizan el mismo esquema, las mismas validaciones y el mismo destino, quizá puedan agruparse. Si una diferencia cambia el riesgo, la extracción o la ruta de aprobación, entonces merece una clase propia.

Incluye además estados de salida que eviten forzar una respuesta:

• desconocido: no existe evidencia suficiente para una clase conocida;
• ilegible: la calidad no permite continuar con fiabilidad;
• paquete_mixto: el archivo contiene varias piezas y debe dividirse;
• fuera_de_alcance: se reconoce el tipo, pero el piloto no lo procesa.

Estas categorías no son fracasos. Son mecanismos de control. Un clasificador que siempre elige una clase conocida puede parecer más «completo» y al mismo tiempo ser más peligroso.

Distingue las etapas del pipeline

Un sistema documental suele combinar varias capacidades:

recepción → control de entrada → lectura/OCR → división → clasificación → extracción → normalización → validación → revisión → escritura → archivo

No todas necesitan IA. La recepción, los identificadores, las reglas de formato o ciertos cruces suelen ser deterministas. OCR se ocupa de convertir contenido visual en una representación legible por máquina. La clasificación decide una ruta. La extracción obtiene datos concretos. Las reglas y sistemas de referencia determinan si esos datos pueden utilizarse.

Separar etapas permite medir dónde falla realmente el sistema y sustituir un componente sin rehacer todo el flujo.

Ejemplo: documentación de proveedores

Supongamos que un buzón recibe facturas, albaranes y certificados. La factura alimenta contabilidad; el albarán se cruza con recepción; el certificado se archiva con una fecha de vigencia. Un único prompt que «extraiga lo importante» mezcla tres contratos de datos y tres consecuencias distintas.

Un primer alcance podría procesar facturas y albaranes de los emisores más frecuentes. Los certificados se clasifican y archivan, pero su contenido no se extrae. Los desconocidos pasan a revisión. Así se obtiene valor sin fingir que el sistema entiende cualquier documento que pueda llegar.

Ejercicio: inventario del caso documental

Selecciona un proceso real y crea una tabla con, al menos:

• unidad de caso;
• archivo/documento/expediente;
• clase;
• canal;
• formato y calidad;
• variantes conocidas;
• resultado operativo;
• campos necesarios;
• sistema consumidor;
• validaciones;
• consecuencia del error;
• responsable de excepción;
• dentro/fuera de alcance.

Después revisa la tabla con operaciones y con quien mantenga los sistemas destino. El inventario está listo cuando ambos entienden qué rutas existen sin tener que interpretar nombres ambiguos.

Resultado de la lección

Debes terminar con un caso delimitado, una taxonomía operativa y un alcance explícito. Todavía no has elegido OCR, modelo ni proveedor. Has definido algo más importante: qué documentos pretende resolver el sistema, qué debe producir y qué ocurre cuando no puede continuar. La siguiente lección convertirá ese alcance en una muestra con la que medir cualquier alternativa de forma reproducible.