Un usuario hace clic en Enviar después de que un asistente dice “Enviar factura a Alice”, porque la interfaz hace que ese resumen parezca la acción que realmente se llevará a cabo.
A continuación, la interfaz ejecuta una solicitud cuyo destinatario real es bob@vendor.com, y el usuario solo se entera de ello a posteriori, cuando la factura llega a la bandeja de entrada equivocada.
Nada en este fallo requiere que el modelo “hackee” el producto.
El fallo se produce en el punto de contacto de la interfaz donde el texto generado pasa a ser algo que un humano aprueba, y la interfaz permite que la descripción fluida del asistente sustituya a los parámetros que realmente se ejecutarán.
El siguiente ejemplo muestra una interfaz de asistente sencilla que evidencia la discrepancia directamente al hacer clic en el botón.
Este código hace concreto el problema al separar lo que muestra la interfaz de usuario (UI) de lo que enviaría la acción; además, el clic revela los datos reales que el producto transmitiría.
La discrepancia que acabamos de ver surge porque el flujo de un asistente en el frontend consta de varias etapas distintas, y cada una puede generar un tipo diferente de percepción errónea o insegura.
Podemos identificar cuatro etapas controladas por el frontend y vincular cada una al mismo escenario de “envío de factura”, de modo que las correcciones posteriores se apliquen en el punto correcto del flujo.
La ventaja de distinguir estas etapas radica en que cada una requiere un control de interfaz diferente; colocar un aviso de advertencia en la etapa incorrecta no evita el problema resultante.
El siguiente diagrama señala los dos límites más importantes de este curso: aquel donde el texto se convierte en DOM y aquel donde la aprobación se transforma en una solicitud.