Cuándo no funciona la supervisión humana en un sistema de IA

Al desarrollar un sistema de IA para organizaciones, una de las primeras cosas que se piden es la aprobación humana. Este artículo explica cómo saber si esa aprobación funciona de verdad dentro del sistema.

Cuando se habla de gobernanza de la inteligencia artificial, la frase que más se oye es esta. "Hay aprobación humana, la decisión no queda en manos de la máquina."

Cuando oigo esa frase, solo hago una pregunta. ¿Cuál es su tasa de aprobación?

No llega respuesta, porque no se mide. En los pocos lugares donde sí se mide, el resultado suele superar el noventa y ocho por ciento. Es decir, la persona supervisora rechaza el modelo una vez de cada cincuenta decisiones. Decir que en ese cuadro existe supervisión humana es formalmente cierto pero funcionalmente falso. Quien decide de hecho es el sistema; la persona solo firma.

Por qué el botón de aprobación no funciona

La causa no es la mala fe, sino el diseño.

Si a un usuario se le muestran trescientas recomendaciones al día y se le pide que apruebe cada una, ese usuario se automatiza en poco tiempo. Si la tasa de acierto del modelo es alta, esto se acelera aún más, porque también en los pocos casos que rechaza el modelo suele tener razón, y el usuario deja de confiar en su propio juicio.

Esto se llama en la literatura confianza excesiva en la automatización, y es un fenómeno bien conocido. Es decir, cuanto mejor funciona el sistema, más se debilita la supervisión humana. Es un hecho que hay que tener en cuenta al diseñar la supervisión.

Las tres condiciones que hacen significativa la supervisión

Para que la supervisión sea funcional, deben darse tres cosas a la vez.

La persona supervisora debe poder ver el fundamento de la recomendación. Si no se muestra a partir de qué entradas llegó el modelo a ese resultado, la persona solo puede evaluar el resultado, y para evaluarlo tendría que decidir todo de nuevo por su cuenta. Esto hace la supervisión prácticamente imposible.

Rechazar debe ser gratuito. Un usuario al que rechazar le exige rellenar un formulario adicional, redactar una justificación y obtener la aprobación de su superior, opta por no rechazar. El flujo de rechazo debe ser al menos tan sencillo como el de aprobación.

El rechazo debe tener una consecuencia. Si las recomendaciones rechazadas se anotan en algún sitio y nadie las mira, la persona supervisora lo nota y con el tiempo pierde interés. Que los casos rechazados alimenten la mejora del modelo mantiene viva la supervisión.

No existe supervisión que no se mida

Incluso una vez cumplidas estas tres condiciones, sigue haciendo falta medir.

Hay al menos tres indicadores que deben vigilarse. La tasa de rechazo, el tiempo medio dedicado por decisión y la tasa de acierto posterior de las decisiones rechazadas. Si el tiempo por decisión ha bajado al orden de los segundos, no se está supervisando. Si la tasa de rechazo se acerca a cero, la conclusión es la misma.

Muy pocas organizaciones tienen respuesta cuando se les preguntan estos indicadores en una auditoría. Sin embargo, no son mediciones difíciles: se extraen de datos que el propio sistema ya genera.

El derecho a impugnar determina la arquitectura

El artículo 11 de la Ley 6698 reconoce a la persona el derecho a impugnar un resultado adverso derivado exclusivamente del análisis por sistemas automatizados.

La consecuencia técnica de esta disposición es directa. Cuando llega una impugnación, hay que poder mostrar cómo se tomó la decisión. Si no se puede mostrar, no se puede defender la decisión.

De ahí se deriva esta regla arquitectónica. En un flujo que produce consecuencias para una persona no puede usarse un modelo que no genere una justificación. Esto debe escribirse desde el principio como una restricción en la selección del modelo. Añadir explicabilidad a posteriori no es posible en la mayoría de las arquitecturas.

Llevar registro no basta, hay que registrar lo correcto

Al hablar de pista de auditoría, lo primero que viene a la mente es llevar un registro, pero lo determinante es el contenido de ese registro.

Para que una decisión pueda revisarse después, deben registrarse conjuntamente cinco elementos. Los datos que entraron en el sistema, la versión del modelo, el resultado producido, la justificación en que se basa ese resultado y la decisión final tomada por la persona. Si estos cinco se guardan en sistemas separados, después no pueden emparejarse. Si no se registró la versión del modelo, meses después no hay forma de responder a la pregunta de qué decía el modelo en esa fecha.

La versión del modelo sin registrar es, en la práctica, la carencia que veo con más frecuencia. El modelo se actualiza, se intenta explicar decisiones antiguas con el modelo nuevo, y no cuadra.

Hay que mostrar la diferencia entre certeza e incertidumbre

Un último punto. El sistema debe mostrar de forma distinguible el resultado que produce con baja confianza frente al que produce con alta confianza.

Si esa distinción no existe, el usuario confía por igual en todos ellos y no recibe ninguna advertencia justo donde el error es más probable. Sin embargo, la incertidumbre del propio modelo suele poder medirse. Llevar esa medición a la interfaz es la mejora más barata y más eficaz de la supervisión.

Si tuviera que elegir una sola cosa que hacer hoy en un proyecto de inteligencia artificial, esa sería mi elección.