Errores de IA y cómo recuperarse: diseñar para cuando la respuesta está mal

¿Por qué los errores de IA son distintos?

Un error de software tradicional suele ser visible: un mensaje rojo, un botón que no responde. Un error de IA suele ser plausible. La respuesta está bien redactada, con tono seguro, y puede tener un dato inventado, un cálculo mal hecho o una cita que no existe. Por eso el usuario tiende a aceptarla.

Esto cambia el trabajo del diseñador. No basta con mostrar el error cuando el sistema lo detecta, porque muchas veces no lo detecta. Hay que diseñar para que el usuario pueda revisar, y para que la revisión sea barata.

¿Qué dice la guía de diseño de Microsoft?

La HAX Toolkit de Microsoft tiene una guía sobre corrección eficiente con una idea central: hacer fácil editar, refinar o recuperarse cuando el sistema de IA se equivoca. Su razonamiento es que una salida de IA puede estar parcialmente bien, y que el usuario debe poder corregirla sin abandonar su objetivo. Sus patrones principales son cambiar decisiones de clasificación, hacer ediciones detalladas y deshacer acciones automáticas. Para casos con muchos elementos, sugiere editar en lote (Microsoft HAX Toolkit, Guideline 9).

El ejemplo que da la guía es una app de navegación: el usuario puede ajustar manualmente la ruta recomendada. La lección sirve fuera de los mapas: la corrección debe vivir donde está el resultado, no en un formulario aparte.

¿Qué diseñar en la interfaz?

Un trabajo de 2023 de Bisante, Dix, Panizzi y Zeppieri sobre errores de IA en interfaces plantea que es esencial detectar los errores lo antes posible y que los sistemas deben tener mecanismos claros para repararlos, de modo que un fallo inicial no se vuelva catastrófico. Los autores reconocen que detectar errores de IA es difícil (Bisante et al., CHItaly 2023).

Un diseñador puede tomar cuatro medidas concretas, que coinciden con los patrones que describe Simon Whatley en un artículo de febrero de 2026 (mostrar razonamiento, confianza y fuentes, y facilitar deshacer y editar en el lugar):

1. Mostrar el razonamiento o la fuente. Así el usuario puede ver dónde falló la lógica o verificar un dato.
2. Mostrar la confianza cuando el sistema la tiene. Un resultado de baja confianza pide una revisión más cuidadosa.
3. Ofrecer corrección en un clic. Un botón “Esto no es correcto” o “No es relevante” sirve para marcar, y la edición directa para arreglar.
4. Preguntar qué debía ser. Una corrección guiada da un mejor resultado al instante y deja información útil al equipo.

Un ejemplo de lo que no conviene: un resultado pulido que oculta la duda. La interfaz debe decir cuándo no está segura.

¿Qué hacer cuando se detecta el error?

Recuperarse no es solo corregir el texto. El usuario necesita saber qué cambió, qué quedó afectado y qué puede deshacer. Tres pasos ayudan:

• Confirmar el alcance. “Corregí la fecha en 3 de 5 secciones” es mejor que un silencio.
• Ofrecer deshacer. Sobre todo si la IA ejecutó una acción: enviar, borrar o mover.
• Explicar el límite. Si el error viene de datos viejos o de información que la IA no tiene, dilo. Por ejemplo, “Mi información sobre precios puede estar desactualizada”.

Ejemplo

Ejemplo ilustrativo: una herramienta de facturación con IA extrae datos de facturas en PDF. Una factura trae el monto mal leído. En la vista de revisión, cada campo muestra la fuente en el PDF y un indicador de confianza. El campo de monto aparece en amarillo. El usuario hace clic, ve el fragmento original, escribe el monto correcto y la herramienta pregunta si quiere aplicar la misma corrección a facturas del mismo proveedor. Si acepta, la corrección se aplica en lote, con una lista previa de cambios y un botón para deshacer.

Cómo aplicarlo mañana

1. Haz una lista de las cinco respuestas más costosas que puede dar tu feature: datos inventados, acciones irreversibles, cifras mal calculadas. Para cada una, define cómo la persona se entera de que hay un error.
2. Revisa si cada acción que ejecuta la IA tiene deshacer. Si no lo tiene, agrégalo o pide una confirmación explícita antes de ejecutarla.
3. Escribe tres mensajes de recuperación con su siguiente paso: uno para datos incorrectos, uno para información desactualizada y uno para falta de respuesta.
4. Prueba un error a propósito en el entorno de pruebas y mide cuántos clics necesitas para corregirlo. Si son más de tres, el flujo de corrección necesita trabajo.

La pregunta que conviene llevar a la próxima revisión de diseño es: ¿qué hace la persona cuando la respuesta suena bien, pero no lo está?

Antes de diseñar la corrección, conviene decidir cuánta confianza mostrar; eso está en calibración de confianza. Los riesgos de la confianza excesiva se tratan en antropomorfización, y las pantallas de chat, en chat vs. UI estructurada.

Errores comunes

• Mostrar el error solo cuando el sistema lo detecta, que casi nunca es el error real.
• Usar un mensaje genérico, como “Algo salió mal”, sin decir qué hacer.
• Obligar a rehacer toda la tarea para corregir un solo dato.
• Ocultar la opción de deshacer detrás de un menú de ajustes.
• Corregir sin avisar: el usuario deja de confiar cuando descubre cambios que no vio.
• Diseñar solo para la respuesta mala y no para la respuesta parcialmente buena, que es la más común.

Fuentes

• Microsoft, HAX Toolkit, “Guideline 9: Support efficient correction”: https://www.microsoft.com/en-us/haxtoolkit/guideline/support-efficient-correction/
• Bisante, Dix, Panizzi y Zeppieri, “To Err is AI” (CHItaly, 2023): https://alandix.com/academic/papers/CHItaly2023-to-err-is-ai
• Simon Whatley, “Designing for AI errors and graceful recovery”: https://www.simonwhatley.co.uk/writing/designing-for-ai-errors-and-graceful-recovery/