Explicabilidad en productos con IA: cuánto explicar y cómo

La explicabilidad muestra por qué la IA dijo algo. Cuánto explicar según el riesgo, cómo presentar la confianza y qué hacer si el razonamiento no se ve.

info Definición Rápida
Explicabilidad en un producto con IA es la información que el sistema muestra al usuario para entender por qué produjo un resultado, de qué datos depende y qué tan fiable es. Su objetivo no es abrir la caja negra del modelo, sino dar a la persona lo necesario para decidir cuándo creer y cuándo revisar.

¿Qué debe explicar un producto?

Hay cuatro preguntas que el usuario se hace, a veces sin decirlo: por qué salió esto, con qué datos, qué tan seguro está el sistema y qué puedo hacer si está mal. La explicabilidad responde a esas preguntas en la medida que el caso necesita.

La guía People + AI Guidebook de Google PAIR dice que toda predicción se basa en datos, así que las fuentes de datos deben formar parte de la explicación: qué datos se usan, si el resultado es personalizado o agregado y si la persona puede quitarlos o reiniciarlos. Esa parte no es técnica; es parte de la relación con el usuario.

El NIST (Instituto Nacional de Estándares y Tecnología de EE. UU.) propone, en su informe NISTIR 8312 de septiembre de 2021, cuatro principios para sistemas explicables que sirven como lista de revisión: el sistema da evidencia o razones para sus resultados (explicación); esas razones las entiende quien las recibe (significativa); describen de verdad cómo se produjo el resultado (exactitud de la explicación); y el sistema solo opera en las condiciones para las que fue diseñado o cuando tiene confianza suficiente (límites del conocimiento). El segundo principio es el que más toca a diseño: una explicación correcta pero ilegible no cumple.

¿Por qué le importa a un diseñador?

Porque la explicación compite con la simplicidad. Mostrar todo el razonamiento de un modelo puede abrumar y no ayudar. Mostrar nada deja a la persona sin herramientas para juzgar. El diseño tiene que encontrar la cantidad correcta para cada situación.

Una revisión sistemática de interfaces de explicación (Cappuccio et al., publicada en arXiv en 2025 y en ACM Computing Surveys) analizó 146 artículos y concluyó que la presentación de las explicaciones suele quedar como un aspecto secundario del diseño del sistema. Entre sus principios transversales están el diseño centrado en el usuario (con lenguaje claro y menos carga cognitiva), la interactividad y el control, los distintos niveles de detalle y adaptar la profundidad a la experiencia de cada persona. Entre las brechas, señala que el diseño centrado en el usuario está poco explorado en este campo y que la transparencia se evaluó de forma explícita en solo ocho estudios.

Un argumento de fondo de PAIR: como los productos de IA se basan en estadística y probabilidad, el usuario no debería confiar en ellos por completo. Las explicaciones sirven para que sepa cuándo apoyarse en el sistema y cuándo usar su propio juicio.

¿Cuánto explicar?

Cuatro criterios prácticos:

  1. Según el riesgo. Una decisión rara o de alto impacto necesita más explicación que una rutinaria. Un filtro de correo no requiere lo mismo que la decisión sobre un préstamo.
  2. Ligada a la acción. Muestra la relación entre lo que hizo el usuario y el resultado. “Te sugerimos este plan porque cambiaste tu presupuesto” es más útil que un párrafo sobre el modelo.
  3. Parcial por defecto. Enfócate en lo que afecta la confianza y la decisión. Una explicación completa y reproducible tiene sentido cuando hay obligación de rendir cuentas, como en decisiones legales o públicas.
  4. Omitida cuando sobra. Si el resultado coincide con lo que la persona espera, o si explicar expondría datos privados o métodos propietarios, no hace falta.

¿Cómo presentar la confianza?

Mostrar un porcentaje parece lo más preciso, pero no siempre es lo más útil. La guía de PAIR recomienda otra cosa:

  • Muestra la confianza solo si afecta una decisión y las pruebas con usuarios confirman que ayuda.
  • Evita métricas que inviten a aceptar a ciegas. PAIR advierte que un indicador de confianza puede llevar a confiar de más, por ejemplo si muestra un puntaje falsamente alto.
  • Prefiere niveles categóricos con una acción clara. Alto, medio y bajo funcionan si cada nivel dice qué hacer: aceptar, revisar, pedir ayuda.
  • En casos dudosos, muestra alternativas. Dar dos o tres opciones invita al usuario a aplicar su criterio.
  • Un número necesita contexto. PAIR señala que los indicadores numéricos suponen que el usuario entiende bien la probabilidad. Un 62% dice poco si la persona no sabe si es bueno o malo para ese caso.

Para el detalle de cómo indicar la duda en el texto, revisa mostrar incertidumbre.

¿Qué hacer cuando no se puede explicar el razonamiento?

En algunos modelos no es posible dar una explicación completa del razonamiento. La guía de PAIR propone alternativas y dice que lo más probable es que la mejor explicación sea parcial:

  • Explicaciones parciales, sobre el sistema en general o sobre una salida concreta.
  • Ejemplos parecidos, como casos de entrenamiento similares o casos en los que el sistema suele acertar o fallar.
  • Contrafácticos: explicar por qué no ocurrió otro resultado (en una solicitud de crédito hipotética: “con un plazo de 24 meses en lugar de 36, la cuota habría cabido en tu límite”).
  • Exploración de “qué pasaría si”, para que el usuario aprenda los límites del sistema.
  • Detalle progresivo, para quien quiera profundizar sin abrumar al resto.

¿Cuándo NO conviene explicar?

  • Cuando la explicación es ruido. Si cada respuesta trae tres párrafos de justificación, la gente deja de leerlos.
  • Cuando la explicación es falsa. Una justificación plausible pero que no corresponde al cálculo real es peor que ninguna, y rompe el principio de exactitud del NIST.
  • Cuando expone datos sensibles. Una explicación no debe filtrar información de otros usuarios o de terceros.
  • Cuando la persona solo necesita el resultado. Un recordatorio de cita no requiere explicar cómo se calculó la hora.

Si la explicación tiene que ver con el uso de datos personales para entrenar, revisa consentimiento para entrenar con datos del usuario.

Ejemplo

Ejemplo ilustrativo: una app bancaria que sugiere reducir un gasto en suscripciones. La tarjeta dice: “Sugerimos cancelar una suscripción porque se cobró tres veces en los últimos 90 días sin que la usaras. Esto se basa en tus movimientos de ese periodo.” Debajo, dos botones: “Ver movimientos” y “No volver a sugerir esto”. Si la persona pregunta “¿por qué no sugieren la otra?”, la app responde que esa suscripción tuvo uso en los últimos días. La explicación es corta, ligada a la acción, dice de qué datos sale y ofrece una forma de corregir.

Errores comunes

  • Explicar la arquitectura del modelo en lugar de la razón del resultado.
  • Mostrar un porcentaje de confianza sin contexto ni acción.
  • Escribir explicaciones que no coinciden con el cálculo real.
  • Ocultar de qué datos sale la recomendación.
  • Probar la explicación solo con equipos técnicos y no con las personas que la van a leer. Revisa calibración de confianza para ver por qué importa.

Fuentes

Preguntas frecuentes

¿Qué es la explicabilidad en un producto con IA?
Es la información que el sistema muestra al usuario para entender por qué produjo un resultado, de qué datos se apoya y qué tan fiable es, en un lenguaje que pueda usar.
¿Hay que explicar siempre cada respuesta de la IA?
No. La cantidad de explicación debe depender del riesgo y de la decisión. Una explicación parcial suele ser mejor que una completa e ilegible, y en tareas rutinarias puede sobrar.
¿Conviene mostrar un porcentaje de confianza?
Solo si afecta una decisión y las pruebas muestran que ayuda. Un porcentaje sin contexto puede inducir a aceptar a ciegas. Niveles categóricos con una acción clara suelen funcionar mejor.
¿Qué se hace cuando el modelo no puede explicar su razonamiento?
Se ofrecen explicaciones parciales, ejemplos parecidos, contrafácticos (‘qué habría cambiado el resultado’) o exploración de casos ‘qué pasaría si’, con detalle progresivo.