Cómo revisar certificados y documentos de proveedores con IA antes de homologarlos

Un proveedor envía por correo un certificado actualizado. Compras lo guarda, calidad necesita verificar su alcance y producción sigue viendo una versión anterior. La fecha de caducidad no es el único problema: el documento debe corresponder al proveedor, al centro y al material que se pretende aprobar.

La IA puede ayudar a clasificar adjuntos, extraer datos de documentos con formatos distintos y preparar una lista de pendientes. Homologar sigue siendo una decisión del responsable que conoce los requisitos y las excepciones aceptables. Este artículo trata la revisión previa a esa decisión. El seguimiento posterior de vencimientos necesita su propio flujo de tareas y comunicaciones.

Empezar por una matriz de requisitos

La empresa necesita definir qué documentos exige para cada tipo de proveedor. Los requisitos de un fabricante de componentes, un transportista y un laboratorio no tienen por qué coincidir. Puede haber condiciones adicionales por producto, centro, país o cliente final.

Una matriz mínima asocia tipo de proveedor → requisito → alcance → vigencia → responsable que valida. Sin ella, el sistema solo puede decir «he encontrado un PDF», pero no si es suficiente. También debe quedar claro cuándo un requisito admite una declaración, un documento alternativo o una excepción aprobada.

Elemento	Pregunta de revisión	Posible salida
Identidad	¿El titular coincide con la entidad contratada?	Coincide, discrepancia o pendiente
Alcance	¿Cubre el producto, servicio o centro relevante?	Evidencia localizada o revisión técnica
Vigencia	¿Es válido para la fecha y el uso previstos?	Vigente, vencido o fecha no localizada
Versión	¿Sustituye un documento anterior?	Nueva versión vinculada al historial

La tabla representa un diseño propuesto, no una lista universal de documentación obligatoria. Cada organización debe adaptarla a su procedimiento.

Qué puede leer la IA y qué no puede concluir

Los proveedores envían PDFs digitales, escaneos, enlaces y adjuntos reenviados. Un servicio de lectura documental puede recuperar texto y campos. Un modelo puede proponer la clase de documento y localizar titular, fechas, código, producto o centro. Microsoft Document Intelligence distingue clasificación de documentos y extracción de campos. Eso ayuda a construir el expediente, pero no acredita que el documento sea auténtico ni que su alcance cumpla el requisito.

Conviene guardar el archivo original y la página de la que procede cada dato relevante. Si el nombre de la empresa aparece en la portada y el alcance en un anexo, la revisión debe mostrar ambos. Una puntuación de confianza de lectura no equivale a una aprobación de calidad.

Los documentos dudosos van a una cola de revisión con motivo. «Fecha ilegible», «titular distinto» y «alcance no localizado» requieren acciones distintas. Si la IA inventa un valor ausente para completar el formulario, el expediente parecerá completo justo cuando debería detenerse.

Un expediente hipotético con dos centros

Supongamos que Proveedor Alfa suministra componentes desde los centros A y B. El certificado recibido menciona a Alfa y caduca dentro de ocho meses, pero el anexo solo incluye el centro A. El pedido previsto saldría del centro B. Es un escenario ficticio.

La extracción de nombre y fecha sería correcta. La conclusión «proveedor válido» sería incorrecta para ese pedido. El resultado útil diría que el certificado está vigente, pero no acredita el centro B, y pediría el anexo correspondiente o una revisión de calidad. Compras ve el documento y puede escribir al proveedor con una petición concreta.

Si después llega el anexo correcto, no se borra el certificado anterior. Se vinculan ambos al mismo requisito y se registra cuándo quedó completo el expediente. La aprobación debe señalar quién la dio y para qué alcance.

Del buzón al sistema de proveedores

El flujo recibe correos desde cuentas autorizadas, identifica proveedor y solicitud, clasifica adjuntos y comprueba duplicados. La identidad no debería depender únicamente del nombre mostrado en el remitente. Un documento enviado por un intermediario puede ser válido. Necesita asociación explícita al proveedor adecuado.

Después extrae campos, aplica la matriz de requisitos y crea tareas para lo que falta. El sistema de compras o de calidad conserva el estado final. Si tiene API o importación, la integración debe confirmar que guardó el resultado. Si no la tiene, el piloto puede entregar un expediente revisable sin automatizar escrituras.

La API de correo de Microsoft Graph expone mensajes y datos de conversación útiles para conectar un buzón autorizado. La arquitectura concreta dependerá del correo y del sistema de proveedores de la empresa.

Controlar permisos y cambios de alcance

Los documentos de un proveedor pueden incluir datos que compras necesita consultar y otros destinados solo a calidad o al área jurídica. El expediente debe respetar esos permisos al mostrar originales, extracciones y comentarios. Enviar todo el PDF a un servicio externo de IA tampoco debería ser una decisión implícita: antes se comprueba qué datos se procesan, dónde y bajo qué condiciones de conservación.

Si cambia el producto suministrado, el centro de fabricación o la entidad contratada, el estado «homologado» puede necesitar revisión aunque el certificado siga vigente. Por eso la aprobación debe registrar para qué alcance se concedió. La automatización puede detectar un cambio en una ficha o en un documento nuevo y abrir la tarea, pero el responsable determina su efecto.

Un detalle operativo importante es separar la clasificación del archivo de la verificación de su contenido. Un PDF puede parecer un certificado por su encabezado y, sin embargo, pertenecer a otro proveedor. Otro puede ser una carta que confirma una renovación aún no emitida. Los dos pueden entrar en la misma bandeja, pero no cubren el requisito del mismo modo.

Crear un expediente que siga al proveedor y al material

En una homologación, la unidad de trabajo no siempre es «el proveedor» en abstracto. Puede ser una combinación de sociedad, centro, familia de producto y servicio. Si un proveedor fabrica en dos plantas, una certificación asociada a la planta A no acredita automáticamente la B. El expediente debe representar esas relaciones antes de que la IA clasifique documentos.

Un modelo de datos sencillo puede contener proveedor, entidades legales, centros, materiales o servicios autorizados, requisitos aplicables y documentos que los cubren. Una misma evidencia puede satisfacer más de un requisito si el equipo lo permite, pero el vínculo debe ser explícito. También se registran aprobaciones, excepciones y fechas de revisión. Esta estructura puede vivir en el sistema actual. No implica comprar una plataforma nueva.

En la entrada documental, cada archivo recibe identidad propia y se vincula a la conversación o portal por el que llegó. El nombre de fichero «certificado_final_2.pdf» no es una versión fiable. Hay que mirar emisor, código, periodo de vigencia y alcance, y después pedir a un revisor que confirme la sustitución cuando la relación no sea inequívoca. Si el proveedor envía un archivo idéntico dos veces, el sistema puede reconocer el duplicado sin crear dos aprobaciones.

La necesidad de estructura se ve en las búsquedas posteriores. Compras puede preguntar «¿qué proveedores aprobados pueden suministrar esta referencia en octubre?». Calidad puede necesitar saber qué pedidos activos dependen de un documento próximo a vencer. Si los documentos solo están en una carpeta y la aprobación no indica alcance, ninguna extracción de IA responderá con seguridad.

Revisar el documento en capas

Primero se comprueba que el archivo se puede abrir y que corresponde a una clase conocida. Después se extraen campos: titular, emisor, código, fechas, productos, instalaciones y anexos. Finalmente se aplican las reglas de homologación. Separar esas capas evita que un fallo de OCR parezca un incumplimiento del proveedor o que un documento bien leído se apruebe por error.

El revisor necesita ver qué dato procede de qué página. En certificados largos, el título suele estar al principio y las exclusiones en un anexo. Extraer solo portada y fecha produce una falsa seguridad. La muestra de prueba debe incluir anexos, sellos, páginas escaneadas y documentos con nombres de sociedades parecidos. Si falta una página, el estado correcto es «incompleto», aunque los campos visibles sean válidos.

Hay límites que la extracción no resuelve. La autenticidad de un documento o la validez de un emisor pueden requerir comprobaciones externas o un procedimiento propio. Si la empresa realiza esa verificación, debe integrarse como una tarea separada, no como una promesa genérica del modelo. La IA puede facilitar la búsqueda del código o del emisor. No sustituye el control que exige el proceso.

También conviene registrar cambios en requisitos. Si un cliente final pide una evidencia adicional para un material, el sistema debe mostrar qué proveedores quedan afectados. Una aprobación antigua no debería seguir apareciendo como completa sin revisar la nueva exigencia. El expediente necesita versión de la matriz de requisitos, además de versión de los documentos.

Un segundo caso: certificado vigente, material fuera de alcance

Imaginemos otra situación hipotética. Un proveedor de envases tiene un certificado vigente para envases de plástico destinados a uso industrial. Compras quiere adquirir un formato para una aplicación que requiere una especificación distinta. El nombre del proveedor coincide y el documento no está caducado. Aun así, no se puede concluir que el nuevo material esté cubierto.

Una revisión útil mostraría que el titular coincide y el certificado está vigente. También señalaría que el alcance de la página 3 no menciona la aplicación solicitada y que calidad debe confirmarla. Si el modelo no puede interpretar el anexo con suficiente seguridad, debe presentar el texto original para revisión. El objetivo no es redactar una conclusión elegante, sino evitar que una condición importante desaparezca entre campos extraídos.

Este tipo de caso cambia cómo se evalúa un piloto. No basta con medir cuántas fechas y nombres se extrajeron correctamente. Hay que comprobar cuántos expedientes se habrían aprobado indebidamente y cuántos se habrían bloqueado sin motivo. Los falsos positivos y falsos negativos tienen costes distintos. El equipo debe decidir cuál tolera y qué revisión añade en cada caso.

Un flujo de aprobación que no se confunda con una carpeta compartida

Un estado «pendiente de revisión» necesita un responsable y una siguiente acción. Si compras clasifica el documento pero calidad debe evaluar su alcance, la tarea se asigna allí con el original y los campos propuestos. Si calidad lo rechaza, registra un motivo concreto que compras pueda trasladar al proveedor. Una aprobación queda asociada a quien decidió, fecha, alcance y evidencias utilizadas.

El sistema puede preparar una solicitud de corrección a partir del motivo, pero no enviarla automáticamente si contiene una interpretación técnica que el revisor no ha confirmado. Cuando el proveedor responde, la nueva entrada se vincula al mismo requisito y el expediente vuelve a la fase adecuada. No hay que empezar una homologación completa si solo falta un anexo, salvo que las reglas de la empresa lo exijan.

La integración con ERP o portal de proveedores debe mantener un único estado operativo. Si el documento está aprobado en un repositorio y el ERP sigue bloqueando al proveedor, la tarea no está terminada. El flujo debe confirmar la actualización y mostrar fallos de sincronización. Esto es especialmente importante cuando una aprobación desbloquea pedidos o recepción de material.

Medir el proceso completo

Un piloto razonable escoge una clase de proveedor con requisitos bien definidos. La muestra debe contener certificados válidos y vencidos, distintos titulares, anexos, escaneos difíciles, correcciones y archivos irrelevantes. Calidad marca de antemano el resultado esperado.

Mediría tiempo desde recepción hasta expediente completo, documentos mal clasificados, aprobaciones corregidas y solicitudes repetidas al proveedor. La métrica decisiva no es cuántos PDFs leyó el sistema, sino si disminuye el trabajo de seguimiento sin aumentar aprobaciones incorrectas. La decisión de homologación debe seguir siendo explicable por las evidencias que la sustentan.

Antes de considerar listo el piloto, pediría a dos revisores que estudien una muestra de expedientes difíciles sin ver la propuesta del sistema. Sus desacuerdos muestran qué reglas de homologación aún están implícitas. No tiene sentido exigir a la IA una respuesta inequívoca cuando el propio procedimiento no define cómo tratar un alcance ambiguo.

Después compararía la propuesta automática con la resolución acordada, separando errores de lectura, de asociación y de criterio. Esa clasificación evita ajustar un modelo para resolver un problema que en realidad depende de datos de proveedor desactualizados. El siguiente paso de implantación se elige a partir de esos errores, no de una única tasa global de acierto.