La ruta de excepción: lo que decide si una automatización con IA sirve

Hemos escrito aquí sobre automatizar con IA las ofertas comerciales, las respuestas a RFPs, las cuentas por pagar, el soporte B2B y los siniestros. Las cinco piezas resuelven la parte humana con una línea parecida: «validando lo sensible con una persona», «control humano en las excepciones».

La frase es correcta y no dice casi nada. No dice quién es esa persona, qué recibe, cuánto tiempo tiene para resolverlo, qué pasa si la cola crece, ni —sobre todo— qué ocurre con el caso que el agente resolvió mal sin marcarlo como dudoso, que es el que nunca llega a esa persona.

Esta pieza es la que faltaba debajo de esa línea. La tesis cabe en una frase: un proceso automatizado no se juzga por su tasa de acierto, sino por su ruta de excepción. La tasa de acierto describe el camino feliz. La ruta de excepción decide si el proceso aguanta el primer mes en producción, si la gente lo adopta y si alguien puede explicar lo que hizo cuando un cliente pregunte.

Cuatro casillas, y el cuadro de mando enseña dos

Cada caso que entra en un proceso automatizado acaba en una de cuatro casillas. El sistema lo resuelve solo o lo manda a una persona; y en cada caso, esa decisión era la buena o no lo era.

La casilla peligrosa es invisible por construcción. Un error que el sistema no marca no genera ningún evento: no hay nada que contar, así que no aparece en ninguna métrica que cuente eventos. Lo único que lo hace visible es ir a buscarlo, y volveremos a eso más abajo.

Las dos casillas de la fila de arriba tiran en sentidos opuestos, y ahí está el diseño entero. Escalar más reduce el error silencioso, pero llena la cola de ruido. Y el ruido no es sólo un coste de horas: una persona que aprueba cuarenta casos seguidos que estaban bien aprende a aprobar el cuadragésimo primero sin leerlo. El ruido acaba fabricando errores silenciosos dentro de la propia ruta de excepción.

La tasa de acierto depende de cuánto dejas pasar

Hay una idea de aprendizaje automático con más de medio siglo que casi nunca llega a las propuestas comerciales: la de la opción de rechazo, o clasificación selectiva. Un sistema que puede abstenerse elige, en cada caso, entre contestar o no contestar, y su error se mide sólo sobre lo que contesta.

Yonatan Geifman y Ran El-Yaniv lo formularon para redes neuronales profundas en NeurIPS 2017: el riesgo de un clasificador selectivo «se puede intercambiar por cobertura», y su rendimiento se describe con una curva de riesgo frente a cobertura, no con un número. Su ejemplo: un error del 2% en ImageNet (top-5) garantizado con probabilidad del 99,9%… contestando sólo en casi el 60% de los casos.

La consecuencia es directa: cualquier tasa de acierto es un punto de una curva. Un porcentaje de acierto que no dice sobre qué porcentaje de casos se calcula es medio número.

Un ejemplo con cifras supuestas (el cálculo es nuestro). Dos propuestas para el mismo proceso, con 2.000 casos al mes:

• Propuesta A: resuelve sola el 95% y se equivoca en el 4% de lo que resuelve. Deja 100 excepciones y 76 errores silenciosos al mes.
• Propuesta B: resuelve sola el 80% y se equivoca en el 1%. Deja 400 excepciones y 16 errores silenciosos al mes.

En la presentación gana A: automatiza más. Cuál es mejor depende de dos cosas que no están en ninguna de las cifras: cuánto cuesta un error silencioso en ese proceso —no es lo mismo una etiqueta mal puesta que un pago duplicado— y si tenéis capacidad para atender bien 400 excepciones al mes. Esas dos preguntas son la ruta de excepción. Sin contestarlas, se elige el punto de la curva que queda mejor en una diapositiva.

La confianza del modelo no es un buen disparador

La respuesta intuitiva a «qué casos escalamos» es «los que el modelo no tenga claros». Tiene dos problemas, y el segundo es más importante que el primero.

El primero es la calibración. En el informe técnico de GPT-4, el modelo preentrenado estaba muy bien calibrado —su confianza coincidía con la probabilidad de acertar— y tras el post-entrenamiento la calibración empeoró: en un subconjunto de MMLU, el error de calibración pasó de 0,007 a 0,074, y el pie de figura dice que el post-entrenamiento «perjudica la calibración de forma significativa». Es un modelo concreto, de 2023, medido con probabilidades internas sobre preguntas tipo test, no con la confianza que el modelo verbaliza «del 1 al 10». Lo que sí enseña es que la calibración hay que medirla por modelo y por tarea, no suponerla. Desde septiembre de 2026 hay un modelo entrenado precisamente para eso; lo analizamos en la pieza sobre Jev.

El segundo problema no lo arregla un modelo mejor calibrado: la confianza mide la duda del modelo, no la consecuencia del caso. Un 97% de confianza sobre una factura de 200 euros y sobre una de 200.000 no son el mismo caso, y el modelo no lo sabrá si no se lo dice el proceso.

Los disparadores que funcionan mejor son los que el modelo no controla:

En cuentas por pagar el primer disparador está resuelto desde hace décadas, y por eso es de los procesos más agradecidos de automatizar. El tercero es la cuarta pregunta de la frontera del ERP vista desde el otro lado: cuando el sistema está equivocado, lo único que lo delata es que otra fuente diga algo distinto.

Poner a una persona no arregla nada por sí solo

Hasta aquí, el diseño parece consistir en elegir bien qué se escala. Falta la parte incómoda: lo que pasa cuando el caso llega a la persona.

En octubre de 2024, Michelle Vaccaro, Abdullah Almaatouq y Thomas Malone publicaron en Nature Human Behaviour un metaanálisis preregistrado de 106 experimentos y 370 tamaños de efecto, todos publicados entre enero de 2020 y junio de 2023, que medían tres cosas a la vez: el rendimiento de la persona sola, el de la IA sola y el de la combinación. El resultado central es que, de media, la combinación rindió peor que el mejor de los dos por separado (g de Hedges = −0,23).

Tiene matices que importan. La combinación sí mejoró a la persona sola; lo que no hizo, de media, fue superar a la IA sola cuando la IA era mejor. Las pérdidas se concentraron en tareas de decisión —elegir entre opciones cerradas— y las ganancias, en tareas de creación de contenido. Y el hallazgo más útil para diseñar una ruta de excepción: cuando la persona era mejor que la IA en esa tarea, la combinación ganaba; cuando la IA era mejor, perdía.

Más del 95% de los sistemas estudiados seguían el mismo patrón: la IA propone y la persona decide. Es el diseño «humano en las excepciones» del principio, el habitual en el sector y también en nuestras propias piezas. Mostrar niveles de confianza o explicaciones no cambió el rendimiento de forma significativa. Los autores apuntan que habría ido mejor repartir la tarea según quién es mejor en cada parte, pero sólo tres experimentos lo probaron y el resultado no fue significativo: es una hipótesis razonable, no una conclusión.

La lectura práctica: la ruta de excepción no consiste en poner a una persona detrás del modelo, sino en mandarle los casos en los que ella es mejor que el modelo. Lo que el modelo acierta más que el revisor no debería llegar a la cola; lo que llega debería llegar a alguien que sepa más que el sistema sobre ese tipo de caso.

Lisanne Bainbridge lo vio en 1983, estudiando plantas de proceso y cabinas de avión, en cinco páginas tituladas Ironies of Automation. Su segunda ironía es exacta para la IA: el diseñador que intenta eliminar al operador «le deja las tareas que no sabe cómo automatizar», un conjunto arbitrario de tareas en cuyo apoyo quizá se ha pensado poco. Las demás siguen vigentes: recuperar con soltura lo que se sabe depende de usarlo a menudo; nadie mantiene la atención más de una media hora sobre algo en lo que casi nunca pasa nada, así que las anomalías raras las tiene que vigilar una alarma; y, la última, los sistemas automatizados con más éxito, los que casi nunca piden intervención manual, pueden ser los que exigen más formación de quien interviene.

Traducido a una cola de excepciones: cuanto mejor funciona la automatización, más raras y más difíciles son las excepciones, y menos práctica tiene quien las resuelve. Una excepción no es un caso medio que el agente no quiso hacer: es, por construcción, de los más difíciles del proceso. Lo prudente es presupuestar que tarda más que la media manual de antes y que pide más criterio, no menos.

Qué recibe la persona, y en qué orden

El paquete con el que llega una excepción decide la calidad de la respuesta, y hay dos estudios que conviene conocer antes de diseñarlo.

El primero, de Gagan Bansal y siete coautores de la Universidad de Washington y Microsoft Research (CHI 2021), probó si las explicaciones de la IA mejoraban a equipos humano-IA en tres conjuntos de datos, con una IA de precisión comparable a la de las personas. No los mejoraron: aumentaron la probabilidad de que la persona aceptara la recomendación, fuera correcta o no.

El segundo, de Zana Buçinca, Maja Barbara Malaya y Krzysztof Gajos (CSCW 2021), probó tres formas de obligar a pensar: enseñar la sugerencia de la IA sólo si la persona la pide, hacer que decida primero y vea la sugerencia después, o hacerla esperar treinta segundos. Las tres redujeron la sobreconfianza frente a mostrar la sugerencia con su explicación, aunque no la eliminaron ni mejoraron de forma significativa el resultado del equipo. Y los diseños que más la redujeron fueron los que menos gustaron. Eran 199 personas, una tarea de nutrición y una IA simulada: no es un protocolo de empresa, pero apunta en una dirección clara.

De ahí salen cinco decisiones de diseño para el paquete de excepción:

1. Por qué ha llegado. La regla concreta que saltó —«el importe no casa con el pedido 4471»—, no «confianza baja». Sin motivo, la persona tiene que redescubrir el problema, y con prisa no lo hará.
2. Los datos de origen, no sólo el resumen. El documento, el registro, el hilo. Un resumen del agente es una conclusión, y quien revisa una conclusión la acepta con más facilidad que quien revisa los hechos.
3. La propuesta del agente, en el orden correcto. Para las excepciones en las que la persona es la experta, primero la evidencia y después, a petición, lo que propone el agente. Para las de mucho volumen y poca consecuencia, la propuesta a la vista. No es un dogma: es elegir según qué casilla de Vaccaro ocupa ese tipo de caso.
4. Qué se puede hacer con ella. Aprobar, corregir, devolver con una instrucción o escalar a otro nivel. Y la corrección capturada de forma estructurada, porque es el dato más valioso que produce el proceso.
5. El plazo. Cuánto puede esperar ese caso antes de que el proceso se atasque o el cliente lo note, visible para quien lo recibe.

Quién y cuándo: la cola también es un sistema

«Las excepciones van al equipo de administración» no es una ruta, es una dirección de correo. La ruta tiene un dueño por tipo de excepción, con nombre y con autoridad para cambiar la decisión, porque la excepción de proveedor nuevo y la de importe disputado no las resuelve la misma persona ni con el mismo criterio.

El plazo sale del proceso, no del acuerdo de nivel de servicio de otro equipo: si una factura tiene que estar contabilizada antes del cierre o una reclamación contestada en un plazo legal, la excepción hereda ese reloj.

Y la capacidad se calcula, no se supone. Siguiendo con la propuesta B de antes (400 excepciones al mes, cálculo nuestro): a 15 minutos por excepción son 100 horas al mes, algo más de media persona a jornada completa. Si las excepciones son, como decía Bainbridge, los casos difíciles y cada una lleva 25 minutos, son unas 167 horas: una persona entera. El caso de negocio que promete liberar un puesto y crea otro de excepciones no está mal, pero está incompleto, y conviene que lo diga el proyecto antes de que lo descubra el equipo.

Cuando la cola crece más deprisa que la capacidad, pasa siempre lo mismo: quien revisa acelera, y revisar deprisa es aprobar. Por eso la métrica que mejor describe la salud de la ruta no es el tiempo en cola sino la tasa de enmienda: qué porcentaje de las excepciones termina con la persona cambiando lo que proponía el agente. Si durante meses está cerca de cero, sólo hay dos explicaciones, y las dos son malas: o se está escalando lo que no hacía falta, o se está firmando sin mirar.

El caso que no llega nunca a la cola

Queda la casilla de abajo a la izquierda. Uno de los casos públicos más citados es pequeño en dinero y enorme en lección.

En noviembre de 2022, tras la muerte de su abuela, Jake Moffatt preguntó al chatbot de la web de Air Canada por las tarifas por duelo. El chatbot le dijo que podía volar ya y pedir la tarifa reducida después, dentro de los 90 días siguientes a la emisión del billete. La página de la propia aerolínea decía lo contrario: la política no se aplicaba a solicitudes posteriores al viaje. Moffatt voló, pidió el reembolso y pasó tres meses cruzando correos, hasta que en febrero de 2023 envió la captura de la conversación. Air Canada admitió entonces que el chatbot había dado «palabras engañosas» y dijo que había tomado nota para poder actualizarlo.

Un año después, el Civil Resolution Tribunal de la Columbia Británica le dio la razón. Según la resolución, Air Canada venía a sostener que el chatbot era «una entidad legal separada, responsable de sus propios actos»; el tribunal lo llamó «una alegación notable» y escribió que debería ser obvio para la aerolínea «que es responsable de toda la información de su web», venga de una página estática o de un chatbot. La condena fue de 812,02 dólares canadienses.

La cifra es anecdótica. Lo que no lo es: el error no lo encontró la empresa. Lo sacó a la luz el cliente, y la aerolínea lo reconoció tres meses después, cuando insistió con la captura. La resolución no entra en qué tecnología había debajo, y para la lección da igual. Ésa es la ruta de excepción por defecto de cualquier sistema que no busca sus propios errores silenciosos: el cliente, el auditor o el cierre. Un soporte automatizado bien hecho sabe decir «no lo sé»; este caso enseña qué pasa con lo que el agente no sabía que no sabía.

Para encontrar esos casos antes que el cliente hay tres herramientas, y ninguna es cara:

• Muestreo aleatorio de lo que el sistema resolvió solo. Una muestra fija cada semana, revisada por alguien que decide antes de ver lo que hizo el agente: es el diseño de «decidir primero» del estudio de Buçinca, aplicado a la auditoría.
• Señales que llegan después. Reaperturas, abonos, reclamaciones, correcciones manuales en el ERP sobre registros que escribió el agente. Cada una es un error silencioso que ya se hizo visible; basta con cruzarlas.
• Cada error encontrado, convertido en un caso del conjunto de evaluación. Es la regla que desarrollamos en la pieza sobre el golden set: un incidente que no acaba convertido en caso de prueba es un incidente que se puede repetir sin que nadie se entere.

Sobre el tamaño de la muestra hay una cuenta que conviene hacer antes de celebrar nada (aritmética nuestra, con una aproximación estadística conocida). Si se revisan n casos y no aparece ningún error, la tasa real todavía compatible con ese resultado, con un 95% de confianza, es de aproximadamente 3 entre n. Cincuenta casos limpios siguen siendo compatibles con un 6% de error silencioso; para descartar un 1% hacen falta unos 300. El tamaño de la muestra no es una cuestión de esfuerzo: es decidir qué tasa de error queréis poder descartar.

La ley ya distingue entre revisar y firmar

Nada de lo anterior es sólo buena práctica. Dos textos europeos lo dicen con palabras que conviene leer enteras.

El artículo 14 del Reglamento Europeo de IA exige que los sistemas de alto riesgo se puedan supervisar de forma efectiva, y concreta qué significa: entre otras cosas, que quienes supervisan sean «conscientes de la posible tendencia a confiar automáticamente o en exceso en los resultados de salida» —el reglamento lo llama literalmente «sesgo de automatización»— y que puedan decidir, en cualquier situación concreta, «no utilizar el sistema de IA de alto riesgo o descartar, invalidar o revertir los resultados de salida». Sólo obliga a los sistemas de alto riesgo, y su calendario se ha movido; lo repasamos al hablar de siniestros.

El otro texto es más antiguo y más directo. Las directrices del Grupo de Trabajo del Artículo 29 —el predecesor del Comité Europeo de Protección de Datos— que interpretan el artículo 22 del RGPD dicen que el responsable «no puede obviar las disposiciones del artículo 22 inventándose una participación humana», y que para contar como tal la supervisión tiene que ser «significativa, en vez de ser únicamente un gesto simbólico», hecha «por parte de una persona autorizada y competente para modificar la decisión» que tenga «en cuenta todos los datos pertinentes». Se refiere a decisiones sobre personas con efectos jurídicos o igual de significativos —una reclamación, un crédito, una contratación—, no a la factura de un proveedor.

Aunque vuestro proceso no esté en ninguno de los dos casos, esas frases son la mejor definición disponible de una ruta de excepción que funciona: alguien con autoridad para cambiar la decisión, con todos los datos delante, consciente de la tendencia a aceptar lo que propone la máquina y con posibilidad real de descartarlo. Una cola donde se aprueba el cien por cien en veinte segundos no cumple ninguna de las cuatro condiciones, y la tasa de enmienda es justo la prueba de que la supervisión no es simbólica. Cómo se construye eso desde el diseño lo tratamos en compliance-first: agentes que pasan auditoría.

Dos informes para el mismo comité

Todo lo anterior acaba cambiando una cosa muy concreta: lo que se enseña cuando alguien pregunta si la automatización funciona.

El informe de la derecha es más feo y más largo, y tiene una ventaja que el de la izquierda no tendrá nunca: aguanta la primera pregunta incómoda. Cuando un cliente reclame, cuando un auditor pregunte o cuando alguien del comité quiera ampliar el alcance, la respuesta honesta no es un porcentaje. Es: sabemos qué resuelve solo y con qué error, qué nos llega, quién lo recibe, cuánto tarda, cuántas veces la persona cambia lo que proponía el sistema y cuántos errores se nos escapan — y cómo lo sabemos.

Si faltan las dos últimas, la tasa de acierto es una opinión con decimales.

Preguntas frecuentes

¿Qué es la ruta de excepción de un proceso automatizado?

Es lo que ocurre con los casos que el sistema no debe resolver solo: qué los detecta, a quién llegan, con qué información, en qué plazo y qué puede hacer esa persona con ellos. Incluye la parte que casi nadie diseña: cómo se encuentran los casos que el agente resolvió mal sin marcarlos. Un proceso sin ruta de excepción diseñada tiene una igualmente, sólo que por defecto: el cliente, el auditor o el cierre contable.

¿Qué porcentaje de casos debería ir a una persona?

No hay una cifra correcta: cuanto más se escala, menos se equivoca el sistema sobre lo que resuelve solo, y la literatura sobre clasificación selectiva lo describe como una curva de riesgo frente a cobertura. El punto de la curva se elige con dos datos que no están en ninguna tasa de acierto: cuánto cuesta un error silencioso en ese proceso y cuántas excepciones al mes puede atender bien vuestro equipo.

¿Puedo usar la confianza que da el modelo para decidir qué se escala?

Como una señal entre varias, no como la única. En el informe técnico de GPT-4, el post-entrenamiento empeoró de forma significativa la calibración del modelo: el error de calibración pasó de 0,007 a 0,074 en un subconjunto de MMLU. Y aun bien calibrada, la confianza mide la duda del modelo, no la consecuencia del caso. Son más fiables los disparadores que el modelo no controla: reglas de negocio, umbrales por importe, desacuerdo entre fuentes y casos nuevos.

¿Revisar con una persona lo que propone la IA no garantiza la calidad?

No por sí solo. Un metaanálisis de 106 experimentos publicado en Nature Human Behaviour en 2024 encontró que, de media, la combinación de humano e IA rinde peor que el mejor de los dos por separado, y que gana cuando la persona es mejor que el modelo en esa tarea. Además, las explicaciones de la IA aumentan la aceptación de su propuesta, sea correcta o no. La revisión funciona cuando llega a quien sabe más que el modelo, con los datos de origen y con tiempo para pensar.

¿Cómo se mide el error que nadie ve?

Con un muestreo aleatorio de lo que el sistema resolvió solo, revisado por alguien que decide antes de ver la respuesta del agente; con las señales que llegan después, como reaperturas, abonos o reclamaciones; y convirtiendo cada error encontrado en un caso de evaluación. El tamaño importa: 50 casos revisados sin ningún error siguen siendo compatibles con una tasa real de hasta un 6%, y para descartar un 1% hacen falta unos 300.

¿La supervisión humana es obligatoria?

El artículo 14 del Reglamento Europeo de IA la exige a los sistemas de alto riesgo, y pide expresamente que quien supervisa sea consciente del sesgo de automatización y pueda descartar o revertir la salida. Cuando una decisión totalmente automatizada tiene efectos jurídicos o significativos sobre una persona entra además el artículo 22 del RGPD, cuyas directrices aclaran que un gesto simbólico no cuenta como participación humana. Aunque vuestro proceso no esté en esos casos, es la mejor definición disponible de supervisar de verdad.

Fuentes citadas

• Vaccaro, M., Almaatouq, A. y Malone, T. — When combinations of humans and AI are useful: A systematic review and meta-analysis (Nature Human Behaviour 8, 2293–2303, publicado el 28 de octubre de 2024; metaanálisis preregistrado de 106 experimentos y 370 tamaños de efecto; g de Hedges = −0,23 frente al mejor de los dos; pérdidas en tareas de decisión; ganancias cuando la persona supera a la IA)
• Bainbridge, L. — Ironies of Automation (Automatica 19(6), 775–779, 1983; las tareas que el diseñador no sabe automatizar, la pérdida de destreza, los límites de la vigilancia y la ironía final sobre la formación)
• Bansal, G., Wu, T., Zhou, J., Fok, R., Nushi, B., Kamar, E., Ribeiro, M. T. y Weld, D. S. — Does the Whole Exceed its Parts? The Effect of AI Explanations on Complementary Team Performance (CHI 2021; las explicaciones aumentan la aceptación de la recomendación de la IA, sea correcta o no)
• Buçinca, Z., Malaya, M. B. y Gajos, K. Z. — To Trust or to Think: Cognitive Forcing Functions Can Reduce Overreliance on AI in AI-assisted Decision-making (CSCW 2021; 199 participantes; tres diseños que reducen la sobreconfianza sin eliminarla, y los menos preferidos por los usuarios)
• Geifman, Y. y El-Yaniv, R. — Selective Classification for Deep Neural Networks (NeurIPS 2017; la curva de riesgo frente a cobertura y el ejemplo de ImageNet)
• OpenAI — GPT-4 Technical Report (2023; figura 8: calibración del modelo preentrenado frente al post-entrenado en un subconjunto de MMLU)
• Civil Resolution Tribunal de la Columbia Británica — Moffatt v. Air Canada, 2024 BCCRT 149 (14 de febrero de 2024; texto íntegro de la resolución)
• Unión Europea — Reglamento de IA, artículo 14 · Supervisión humana (sesgo de automatización y capacidad de descartar o revertir la salida en los sistemas de alto riesgo; citado según la versión española del Diario Oficial)
• Grupo de Trabajo del Artículo 29 — Directrices sobre decisiones individuales automatizadas y elaboración de perfiles a los efectos del Reglamento 2016/679 (WP251rev.01) (adoptadas en 2017 y revisadas el 6 de febrero de 2018; participación humana significativa frente a gesto simbólico; citado según la versión oficial en castellano)

Las citas de fuentes publicadas en inglés están traducidas por nosotros.