IA para órdenes de compra: del PDF al dato validado

Decidir qué debe entregar la extracción

Para automatizar la lectura de órdenes de compra, proponemos evaluar tres resultados: que los campos correspondan al documento, que cumplan las reglas del proceso y que las excepciones lleguen a una persona responsable. Un piloto útil debería mostrar el recorrido desde el PDF recibido hasta el registro aceptado, incluyendo los casos que necesitan corrección.

La documentación de Google Cloud describe extractores personalizados que combinan alternativas basadas en modelos generativos, modelos personalizados y plantillas. La elección depende, entre otros factores, de cuánto cambia la estructura de los documentos. Esa variedad permite plantear una evaluación con archivos propios, sin dar por hecho que una misma configuración resolverá todas las órdenes. Google Cloud, Custom extractor overview.

En esta guía trabajaremos con una comercializadora chilena hipotética que recibe pedidos de distintos compradores. El objetivo es preparar registros para su sistema de ventas. Los ejemplos son propuestas de evaluación; no describen una implementación ni resultados de clientes de Digital Dev.

Definir campos que el equipo comercial pueda revisar

Antes de configurar el extractor, sugerimos acordar una ficha con número de orden, comprador, moneda, dirección de entrega y líneas de producto. Para cada campo, el equipo debería indicar qué significa, cuándo es obligatorio y cómo reconocer un valor ausente. En las líneas conviene separar código, cantidad y unidad: doce cajas y doce unidades pueden requerir tratamientos distintos.

También proponemos conservar el texto original junto al valor preparado para el sistema. Una fecha ambigua o un separador decimal inesperado debe quedar visible para revisión. En una empresa que trabaja con órdenes nacionales e internacionales, la moneda merece un campo propio: el símbolo monetario aislado puede dejar dudas. Si la orden contiene dos direcciones, el equipo debe definir cuál corresponde al despacho y qué hacer cuando esa distinción no está clara.

Usar la confianza para orientar la revisión

Microsoft Document Intelligence devuelve estimaciones de confianza para distintos resultados, incluidos campos y palabras, aunque no todos los campos las entregan. Su documentación contempla usar esas puntuaciones para decidir qué predicciones requieren revisión humana. También distingue la confianza de una celda de la de la fila o tabla que la contiene. Microsoft, interpretación de precisión y confianza.

Nuestra recomendación es observar los errores de cada campo antes de elegir un umbral. Una puntuación alta sobre el número leído no confirma que esa orden siga vigente, que el comprador esté habilitado o que el código exista en el catálogo. Para el piloto, separaríamos tres estados: dato extraído, dato contrastado y registro aceptado. Así queda claro qué comprobación falta cuando un documento se detiene.

Medir los aciertos y también los datos que faltan

Google Document AI evalúa predicciones contra anotaciones de referencia en documentos de prueba. La precisión mide qué proporción de lo extraído coincide con esa referencia; la exhaustividad, o recall, mide qué proporción de lo esperado se recuperó correctamente. La evaluación puede revisarse por campo. Google Cloud, evaluación de resultados.

Como ejemplo ficticio simplificado, supongamos cien documentos con un número de orden esperado en cada uno. El sistema devuelve noventa números y ochenta y uno son correctos. La precisión es 81/90, equivalente al 90%; la exhaustividad es 81/100, equivalente al 81%. Esa diferencia revela que observar únicamente las respuestas entregadas deja fuera parte del problema. Las cifras ilustran el cálculo y no representan el desempeño de un producto.

Para nuestra comercializadora, armaríamos una muestra con formatos frecuentes, escaneos legibles, tablas extensas y documentos incompletos. Reservaríamos parte para la evaluación final, sin usarla para ajustar el extractor. El responsable comercial debe confirmar los valores de referencia antes de comparar resultados; una etiqueta equivocada también puede distorsionar la evaluación.

Comprobar las reglas antes de escribir en el sistema

Proponemos cuatro comprobaciones para el registro candidato: que el comprador corresponda al maestro comercial, que cada código tenga una equivalencia acordada en el catálogo, que cantidades y unidades sean interpretables y que la combinación de comprador y número de orden no esté ya registrada. Son reglas propuestas para este ejemplo; su alcance debe ajustarse a cómo trabaja cada empresa.

Cuando algo falla, la pantalla de revisión debería mostrar el documento, el campo observado y el motivo del bloqueo. Por ejemplo: código extraído sin equivalencia en catálogo. La persona puede corregir la lectura, resolver la equivalencia o devolver la solicitud para aclaración, dejando constancia de la decisión. Inferir un código parecido sin autorización convertiría una duda de lectura en una decisión comercial.

Evaluar el proceso que queda después de la IA

El cierre del piloto debería incluir registros aceptados, errores detectados después de aceptar, tiempo dedicado a corregir y motivos de devolución. Sugerimos revisar una muestra de los casos que avanzaron automáticamente, además de las excepciones visibles. El trabajo de revisión y las integraciones forman parte del costo por tarea resuelta, por lo que deben entrar en la comparación con el proceso actual.

Para comenzar, la comercializadora podría generar borradores de pedidos que una persona confirme antes de incorporarlos al sistema. Ampliar la automatización requeriría evidencia sobre los campos críticos y una forma de detener el flujo si aparecen errores. Esa es una conversación concreta para un proyecto de IA aplicada a empresas: qué registro se necesita, qué controles lo habilitan y quién responde por las excepciones.