Fijar umbrales y diseñar la revisión humana

Aceptar automáticamente todo lo que devuelve el extractor convierte la incertidumbre del modelo en efectos de negocio. Revisarlo todo, en cambio, puede trasladar el trabajo manual a otra pantalla sin crear capacidad. La revisión humana debe diseñarse como una política de control, no como una red genérica que «arregla lo que falle».

El objetivo es decidir qué puede continuar, qué necesita confirmación y qué debe detenerse. Los umbrales son solo una de las señales posibles.

Empieza por la consecuencia del error

Clasifica campos y acciones por impacto. Un error descriptivo reversible no tiene el mismo coste que un importe, una identidad, una fecha crítica o una acción externa.

Para cada elemento pregunta:

• ¿puede detectarse después?;
• ¿puede revertirse?;
• ¿qué sistema quedaría afectado?;
• ¿qué coste tendría corregirlo?;
• ¿puede perjudicar a una persona o cliente?;
• ¿requiere una aprobación independientemente de la calidad de extracción?

No uses un único umbral de confianza para todo el documento. La sensibilidad cambia por campo, clase y acción.

Diseña reglas de enrutado combinadas

La política puede utilizar:

• calidad de imagen;
• clase y emisor;
• plantilla conocida o nueva;
• puntuación calibrada del extractor;
• validaciones superadas;
• discrepancias con fuentes externas;
• presencia de campos críticos;
• importe o impacto;
• combinación de varias señales.

Resultados posibles:

aceptar → revisar_campo → revisar_documento → solicitar_nueva_entrada → rechazar → escalar

AWS documenta flujos de revisión humana para Textract activados, entre otras condiciones, por puntuaciones de confianza o campos ausentes. Es un ejemplo de cómo una señal puede activar intervención. La política concreta de tu sistema debe validarse con tus errores y consecuencias.

Diseña una interfaz que reduzca trabajo

La persona revisora debería ver el original en la página relevante, el campo resaltado, el valor propuesto, las reglas fallidas y, si procede, la comparación externa. Pedirle que relea el documento completo y reintroduzca todos los datos destruye gran parte del beneficio.

Ofrece acciones estructuradas:

• confirmar;
• corregir;
• marcar ilegible;
• reclasificar;
• volver a separar;
• solicitar documento nuevo;
• escalar;
• rechazar.

Registra quién actuó, cuándo, valor anterior, valor corregido, motivo y versión del sistema. Esa información sirve para trazabilidad y para analizar patrones de fallo.

No conviertas cada corrección en entrenamiento automático. Las correcciones pueden contener errores humanos y requieren gobierno antes de reutilizarse como etiquetas.

Calibra sobre datos observados

Prueba diferentes políticas sobre el conjunto de validación. Para cada una mide:

• errores críticos aceptados automáticamente;
• cobertura automática;
• porcentaje enviado a revisión;
• tiempo medio de revisión;
• campos más corregidos;
• falsos avisos;
• casos que escaparon sin detectar.

Busca un equilibrio explícito. Reducir la cola no es un objetivo si aumenta errores relevantes. Aumentar precisión tampoco es suficiente si solo automatizas una fracción insignificante del volumen.

Bloquea la política candidata antes de utilizar el conjunto de prueba final. Si ajustas el umbral después de mirar cada error de prueba, deja de ser una evaluación independiente.

Supervisa la cola como parte del producto

Una cola de revisión tiene capacidad finita. Define responsables, prioridades, plazos y escalado. Mide por qué llegan los casos.

Si una plantilla concreta genera la mayoría de revisiones, quizá debas mejorar captura o extracción. Si una regla produce demasiados falsos positivos, corrígela. Si el 80 % de documentos necesita intervención, cuestiona si la automatización está resolviendo el problema adecuado.

La cola no debe esconder degradación. Es un sensor del sistema.

Ejemplo: factura de alto importe

Proveedor, número, moneda y total son campos críticos. Todos pasan validación y las puntuaciones son altas. Aun así, una factura por encima de cierto importe puede requerir aprobación humana por política de negocio.

Aquí la revisión no se activa por duda del extractor, sino por consecuencia. Separar ambos motivos permite medir calidad técnica sin confundirla con reglas de autorización.

Ejercicio: matriz de revisión

Crea una matriz con:

1. campo o decisión;
2. impacto del error;
3. señales utilizadas;
4. condición de aceptación;
5. condición de revisión;
6. ruta de rechazo o escalado;
7. información mostrada al revisor;
8. acciones permitidas;
9. evidencia guardada;
10. SLA o plazo;
11. criterio de recalibración.

Resultado de la lección

La revisión está bien diseñada cuando sabes por qué cada caso llega a una persona y qué decisión puede tomar esa persona. El siguiente paso es integrar esas rutas en un ciclo de vida que mantenga unidos original, derivados, datos, estado y sistemas destino sin crear duplicados ni perder trazabilidad.