Este ensayo desarrolla uno de los conceptos del marco PRAXIS: los errores dignos. Un error digno es el que la persona puede entender, corregir y perdonar. Su opuesto —el error que traiciona— es opaco, irreversible y silencioso. La distinción afecta directamente al carácter del producto y a cómo se diseña la agencia humana en el bucle.
El fallo que cambió la conversación
Carlos llevaba meses usando un asistente de escritura para su trabajo. Redactaba informes, propuestas, correos importantes. El sistema le ayudaba a pulir frases, sugería alternativas, corregía errores. Una herramienta útil que le ahorraba tiempo.
Un día, preparando una propuesta para un cliente importante, el asistente le sugirió incluir un dato sobre el mercado. Carlos no recordaba haber escrito ese dato, pero el sistema lo presentaba con la misma confianza que todo lo demás. Lo dejó. El informe salió.
El dato era inventado.
No había ninguna fuente. El sistema lo había generado porque estadísticamente encajaba bien en ese tipo de frases. Sonaba plausible. Eso era todo.
Carlos no perdió al cliente, pero perdió algo más difícil de recuperar: la confianza en la herramienta. Desde entonces, revisaba cada sugerencia como si viniera de alguien que ya le había mentido una vez.
Lo interesante no es que el sistema fallara. Todos los sistemas fallan. Lo interesante es el tipo de fallo. Y lo que ese fallo reveló sobre la relación entre Carlos y la herramienta.
No todos los errores son iguales
Hay errores que puedes perdonar. El corrector que cambia una palabra por otra parecida. El GPS que recalcula porque no giró a tiempo. El autocompletado que sugiere algo absurdo y te hace sonreír.
Estos errores tienen algo en común: los ves venir, los entiendes cuando pasan, y puedes corregirlos sin coste. Son errores transparentes. Torpes, a veces molestos, pero honestos.
Y hay otros errores que se sienten distintos. Que no ves venir. Que no entiendes del todo cuando ocurren. Que descubres tarde, cuando el daño ya está hecho. Errores que te hacen sentir que el sistema sabía algo que tú no sabías, y no te lo dijo.
El dato inventado de Carlos era de estos. El sistema no marcó incertidumbre. No dijo “esto podría ser así”. Lo afirmó con el mismo tono que todo lo demás. Carlos no tenía forma de distinguir la certeza de la invención.
Eso no es un fallo técnico. Es un fallo de carácter.
Lo que el error revela
Un error dice mucho sobre el producto que lo comete.
Dice si el producto sabe reconocer sus límites o si los disimula. Dice si el coste del fallo lo asume quien lo causó o quien lo sufre. Dice si hay forma de volver atrás o si el daño es irreversible. Dice si el usuario puede entender qué pasó o si se queda a oscuras.
Piensa en la diferencia entre estos dos escenarios:
Una app de navegación te lleva por una ruta más larga porque no tenía información de tráfico actualizada. Llegas tarde, te molesta, pero entiendes lo que pasó. La próxima vez miras el mapa antes de salir.
Una app de gestión financiera mueve tu dinero a una cuenta de inversión porque interpretó que “querías maximizar rendimientos” según tu perfil. No te avisó antes. Lo descubres cuando necesitas el dinero y no está donde esperabas.
Los dos son errores. Pero el segundo se siente como traición. No porque el daño sea mayor, sino porque había una asimetría: el sistema sabía lo que iba a hacer, tú no. El sistema tenía información que no compartió. El sistema decidió por ti, sin decirte que estaba decidiendo.
Errores que merecen perdón
Hay una forma de fallar que mantiene la dignidad de la relación entre el usuario y el producto.
Son errores que puedes ver. No escondidos, no disfrazados de funcionamiento normal. Cuando algo falla, se nota que falló.
Son errores que puedes entender. No hace falta ser ingeniero para saber qué pasó. La explicación es accesible, aunque sea simple.
Son errores que puedes corregir. Hay vuelta atrás, o al menos hay forma de limitar el daño. No estás atrapado en las consecuencias de algo que no elegiste.
Y son errores cuyo coste no recae solo en ti. Si el sistema se equivoca, el sistema asume alguna parte de la consecuencia, aunque sea reconociendo el fallo.
Estos son errores que permiten seguir confiando. No porque no ocurran, sino porque cuando ocurren, el producto responde de una forma que respeta a quien lo usa.
El error que Carlos no pudo perdonar
Lo que Carlos no podía quitarse de la cabeza no era el dato falso en sí. Era que el sistema no le había dado ninguna señal. Ningún “no estoy seguro de esto”. Ningún “este dato proviene de una inferencia”. Nada.
El sistema había presentado una invención con la misma confianza que una corrección ortográfica. Y esperaba que Carlos distinguiera lo uno de lo otro.
Eso es pedirle al usuario que haga el trabajo que el sistema debería hacer. Que detecte lo que el sistema no marca. Que dude donde el sistema no duda.
Cuando un producto traslada toda la responsabilidad de sus fallos al usuario, está diciendo algo sobre su carácter. Está diciendo: “Yo actúo, tú verificas. Si fallo, es tu culpa por no haberme revisado.”
Eso no es una herramienta. Es un riesgo disfrazado de ayuda.
La pregunta que queda
Los productos que diseñamos van a fallar. No es una posibilidad, es una certeza. La pregunta no es si fallarán, sino cómo.
¿Cómo falla tu producto cuando no tiene suficiente información? ¿Lo reconoce o lo disimula?
¿Cómo falla cuando se equivoca? ¿Hay forma de volver atrás? ¿Quién asume el coste?
¿Qué pasa cuando el usuario descubre el fallo? ¿Puede entender qué ocurrió? ¿O se queda preguntándose si puede seguir confiando?
El error no es el enemigo. El enemigo es el error que no puedes ver venir, que no puedes entender, que no puedes corregir, y cuyo coste pagas tú mientras el sistema sigue funcionando como si nada.
Ese es el error que traiciona.
¿Qué tipo de errores comete tu producto?
Estas ideas forman parte de PRAXIS, un marco para diseñar productos con IA que respeten a las personas. Más en www.praxisbook.com