La mayoría de las demos de IA empiezan con un documento fácil de leer, un pedido fácil de clasificar y un resultado que encaja sin esfuerzo en el paso siguiente.

El trabajo real no suele colaborar de esa manera.

Una orden de compra llega sin el identificador del proveedor. La dirección corresponde a una subsidiaria, pero el contrato está a nombre de la empresa matriz. Una página usa cajas y otra, unidades. El total parece válido hasta que una nota escrita a mano cambia la fecha de entrega. Para las personas que hacen el trabajo, ninguno de estos detalles es raro. Son, sencillamente, los casos que nunca entran en la demo.

Los equipos suelen llamarlos casos límite. El nombre los vuelve periféricos, como si el producto principal existiera en un centro limpio y todo lo desordenado pudiera resolverse más adelante. En el software operativo suele ocurrir lo contrario. Los casos normales avanzan rápido. En las excepciones, las personas invierten tiempo, aplican criterio y deciden si volverán a confiar en el sistema.

Un modelo de extracción puede rendir bien y dejar atrás un producto deficiente. Supongamos que procesa sin problemas 95 facturas comunes y luego encuentra cinco con referencias ausentes o montos en conflicto. Si esas cinco caen en una cola genérica de errores, alguien tendrá que reconstruir lo ocurrido desde cero. La automatización ahorró tiempo en el trabajo fácil y devolvió el trabajo difícil sin contexto.

No es un detalle menor de interfaz. Es el producto mostrando qué entiende por trabajo.

Un camino de excepción útil conserva el material original, la interpretación del modelo, el motivo de la detención y la decisión que debe tomar la persona revisora. Tiene que mostrar el desacuerdo en lugar de esconderlo dentro de un puntaje de confianza. Una vez resuelto el problema, el proceso debería continuar desde ese punto. Obligar a reiniciar el caso completo convierte el escalamiento en retrabajo.

El diseño también necesita distinguir situaciones. Un dato ausente no es igual a un dato contradictorio. Una fuente ilegible no es lo mismo que un valor que viola una regla del negocio. Una predicción de baja confianza puede ser aceptable para una etiqueta interna e inadmisible para una instrucción de pago. Si cada problema termina en una sola bandeja llamada “requiere revisión”, el sistema trasladó la tarea de clasificación al usuario.

Ahí el conocimiento del dominio deja de ser una frase abstracta. Las personas que operan el proceso ya saben qué excepciones son rutinarias, cuáles pueden esperar y cuáles obligan a detenerse. Saben qué evidencia resuelve una disputa y quién está autorizado a decidir. Capturar esos patrones produce un sistema mejor que otra conversación genérica sobre la inteligencia del modelo.

También cambia lo que conviene medir. El procesamiento sin intervención es útil, pero no muestra si el trabajo restante se volvió manejable. ¿Cuánto espera una excepción? ¿La persona entiende el problema sin abrir otros tres sistemas? ¿Cuántas veces un caso resuelto vuelve a la cola? ¿La corrección ayuda al siguiente caso parecido o la misma confusión se repite?

Estas preguntas exponen una trampa habitual. El equipo optimiza el porcentaje de casos resueltos sin una persona y trata cada traspaso como un fracaso. Así aparece la presión por automatizar decisiones realmente ambiguas. Un escalamiento bien diseñado no es automatización fallida. Es el sistema reconociendo el límite de su autoridad y entregando a la persona lo necesario para avanzar.

No existe una interfaz universal para las excepciones. Un analista de cumplimiento necesita una superficie de revisión distinta de la de un operador de depósito. Uno puede requerir citas e historial de políticas; el otro, una foto, una cantidad y una acción siguiente clara. El diseño debe seguir el trabajo con suficiente detalle para que la excepción siga dentro del flujo y no se convierta en una salida.

El camino ideal todavía importa porque demuestra que la maquinaria básica funciona. Pero dice muy poco sobre la capacidad del producto para sobrevivir al contacto con la realidad cotidiana.

La excepción es donde el producto demuestra que entiende el trabajo.