Diseñar productos con IA: control, confianza y recuperación

Una herramienta resume una reunión, identifica decisiones y propone tareas. Todo parece correcto hasta que atribuye un compromiso a la persona equivocada. ¿Puede el usuario detectar el error, corregirlo y evitar que se envíe? Esa secuencia revela tanto sobre la calidad del producto como la precisión del modelo.

Diseñar con IA implica decidir qué puede delegarse, qué necesita revisión y cómo continuar cuando el resultado falla. Control, confianza y recuperación deben formar parte del flujo principal.

Las siguientes recomendaciones combinan investigación y guías de interacción con propuestas prácticas para equipos de producto. Los ejemplos son hipotéticos; no describen proyectos ni resultados reales.

1. Definir la tarea antes de elegir la interfaz

Antes de diseñar un chat, conviene escribir una frase: «Esta función ayuda a esta persona a completar esta tarea, bajo estas condiciones». Después hay que identificar qué parte requiere interpretación y cuál necesita exactitud.

En el ejemplo del resumen, redactar una síntesis y asignar responsables son operaciones distintas. Una admite variaciones de estilo; la otra puede crear compromisos incorrectos.

Las guías de interacción humano-IA de Microsoft, publicadas en 2019, recomiendan comunicar las capacidades del sistema y su nivel de desempeño. Para aplicarlo, el equipo puede documentar:

• Qué información utiliza la función.

• Qué produce y qué queda fuera de alcance.

• En qué situaciones requiere revisión.

• Qué ocurrirá después de aceptar el resultado.

Una descripción como «Genera un borrador a partir de la transcripción; revisa nombres y acuerdos antes de compartir» establece expectativas concretas. También permite comprobar si el flujo cumple lo prometido.

2. Graduar el control según las consecuencias

Separar sugerir, preparar y ejecutar

Una sugerencia de título necesita poco esfuerzo de supervisión. Enviar una comunicación o modificar permisos exige otro nivel de control. Como criterio de diseño, conviene evaluar cada acción por su impacto, reversibilidad y alcance.

En una herramienta hipotética de atención al cliente, el sistema podría preparar una respuesta, mostrar las referencias utilizadas y permitir editarla. Enviar el mensaje sería una acción diferenciada, con el destinatario y el contenido final visibles.

Para cambios en lote, la revisión debería mostrar cuántos elementos se modificarán, cuáles y con qué criterio. Una confirmación genérica aporta menos información que una vista de cambios.

Ofrecer controles comprensibles

La guía Feedback + Control de Google PAIR propone equilibrar automatización y control, y explicar qué efecto tendrá el feedback y cuándo.

En la práctica, «Hazlo mejor» deja demasiadas decisiones abiertas. Controles como «Conservar cifras», «Reducir extensión» o «Usar únicamente estos documentos» permiten expresar restricciones comprobables. Deben presentarse como capacidades reales del producto, con sus limitaciones, y validarse técnicamente.

También conviene separar tres acciones: editar este resultado, guardar una preferencia y reportar un problema. El usuario debería comprender cuál afecta solo al documento actual y cuál cambia experiencias futuras.

3. Construir confianza con evidencia verificable

La confianza útil depende de saber cuándo apoyarse en el sistema y cuándo revisar. El capítulo Explainability + Trust de PAIR aborda esa calibración y la elección de explicaciones adecuadas al contexto.

Para un asistente documental hipotético, una respuesta podría incluir enlaces a los fragmentos consultados y distinguir información encontrada de propuestas generadas. El equipo debe comprobar que las referencias sostienen las afirmaciones: mostrar enlaces, por sí solo, no garantiza respaldo.

Una cifra como «92 % de confianza» necesita una definición y una validación que el usuario pueda interpretar. Si el producto carece de esa base, resulta más útil comunicar una limitación concreta: «Solo se consultaron documentos de este proyecto» o «No se encontró una fecha en las fuentes».

Diseñar la revisión, además de la explicación

Buçinca, Malaya y Gajos estudiaron intervenciones para fomentar la reflexión en decisiones asistidas por IA. En su experimento de 2021 con 199 participantes, estas intervenciones redujeron la dependencia de recomendaciones incorrectas frente a explicaciones simples, pero las más eficaces recibieron valoraciones subjetivas menos favorables. El resultado pertenece a ese contexto experimental; no establece una receta universal.

La implicación práctica es probar dónde merece la pena añadir esfuerzo. Para una decisión importante, puede ser útil contrastar datos antes de aceptar. Para corregir una frase, esa misma interrupción podría resultar excesiva.

4. Diseñar la recuperación desde el primer prototipo

La guía Errors + Graceful Failure de PAIR recomienda anticipar errores y devolver control a la persona. Un mensaje de disculpa sirve de poco si el trabajo anterior desapareció o la única salida es comenzar de nuevo.

Una propuesta práctica es diseñar tres caminos:

• Corregir una parte: cambiar un nombre o una cifra sin regenerar todo.

• Volver atrás: recuperar la versión anterior y comparar diferencias.

• Continuar manualmente: completar la tarea con las herramientas habituales.

En nuestro resumen hipotético, cada acuerdo podría editarse por separado. Si falta una sección de la transcripción, el producto indicaría cuál, conservaría lo ya revisado y permitiría añadir información.

La recuperación también requiere honestidad sobre el estado. Detener la generación de texto no equivale a cancelar una operación externa. Si un mensaje ya se envió, la interfaz debe mostrarlo claramente y ofrecer las opciones realmente disponibles. Prometer «Deshacer» solo tiene sentido cuando el sistema puede revertir la acción.

5. Evaluar el recorrido completo

El HAX Playbook de Microsoft propone explorar fallos de interacción y simular comportamientos antes de construir un sistema completo. Esto permite investigar la recuperación desde prototipos tempranos.

Para una sesión de prueba, prepara resultados correctos, incompletos y plausibles pero equivocados. Observa si las personas detectan el problema, encuentran la evidencia y consiguen terminar la tarea.

Como propuesta de evaluación, registra:

• Tareas completadas con calidad aceptable, incluida la revisión.

• Tiempo total, desde la petición hasta el resultado utilizable.

• Errores detectados y errores aceptados sin advertirlos.

• Tiempo y pasos necesarios para recuperarse.

• Trabajo perdido durante la corrección.

Compara estos resultados con el flujo existente. Que una función genere más rápido no demuestra que ahorre tiempo si después exige una revisión extensa. Segmenta también por experiencia y contexto: un promedio puede ocultar dificultades importantes.

Checklist antes de lanzar una función con IA

• ¿La persona entiende qué hace la función y qué debe revisar?

• ¿Puede anticipar qué datos se utilizarán y qué acciones ocurrirán?

• ¿Las acciones de mayor impacto tienen una revisión proporcionada?

• ¿Las referencias permiten comprobar las afirmaciones relevantes?

• ¿Se puede corregir una parte sin perder el resto del trabajo?

• ¿Cancelar, revertir y continuar manualmente tienen comportamientos claros?

• ¿El feedback explica su alcance y su tiempo de efecto?

• ¿Se probaron errores plausibles, además de resultados satisfactorios?

• ¿La evaluación incluye el coste de supervisar y recuperarse?

Un producto con IA necesita que las personas puedan entender lo que está pasando, decidir cuánto delegar y resolver los problemas que aparezcan. Esas capacidades se diseñan en los permisos, las palabras, los estados y las salidas del flujo. Conviene tratarlas como requisitos del producto desde el inicio.

Fuentes

1. Amershi et al. (2019). Guidelines for Human-AI Interaction. CHI 2019, Microsoft Research.

2. Google PAIR. Feedback + Control. People + AI Guidebook; sin fecha individual visible.

3. Google PAIR. Explainability + Trust. People + AI Guidebook; sin fecha individual visible.

4. Buçinca, Malaya y Gajos (2021). To Trust or to Think: Cognitive Forcing Functions Can Reduce Overreliance on AI in AI-assisted Decision-making. Investigación experimental.

5. Google PAIR. Errors + Graceful Failure. People + AI Guidebook; sin fecha individual visible.

6. Microsoft. HAX Playbook. Herramienta de diseño; sin fecha individual visible.