En noviembre de 2022, Jake Moffatt acababa de perder a su abuela. Entró en la web de Air Canada y le preguntó al chatbot por las tarifas de duelo (los descuentos que algunas aerolíneas ofrecen a quien tiene que viajar por la muerte de un familiar cercano). El bot le dijo que podía pedir la tarifa reducida con carácter retroactivo, una vez comprado el billete. Incluso enlazó a la página con la política de la aerolínea, que decía otra cosa.
Moffatt confió en el bot. Compró el billete. Cuando pidió el reembolso, Air Canada se lo negó.
En febrero de 2024, un tribunal de Columbia Británica le dio la razón. Air Canada había sostenido que no respondía de lo que dijera su chatbot, como si el bot fuera una entidad aparte. El tribunal calificó ese argumento de llamativo y ordenó a Air Canada pagar a Moffatt unos 812 dólares canadienses.
La cuantía es lo de menos. Lo revelador es que Moffatt tenía delante dos fuentes contradictorias, en el mismo sitio y con la misma autoridad, y nadie había diseñado cómo saber en cuál confiar.
La pregunta de fondo
Llevo tiempo dándole vueltas a algo: qué es buen diseño cuando el sistema ya no hace siempre lo mismo.
Durante años la respuesta cabía en una frase: el producto hace lo que esperas y no te estorba. Con IA se queda corta, porque el sistema a veces se equivoca con total seguridad y, cada vez más, actúa en tu nombre.
Propongo cuatro criterios. Salen de casos públicos y documentados, y te aviso de algo: son criterios míos. No hay evidencia de que seguirlos mejore los resultados de negocio. Es un juicio de diseño, y como tal se puede discutir.
1. Confianza calibrada
El buen diseño busca que el usuario confíe lo que el sistema merece, ni más ni menos.
Moffatt no fue ingenuo. Preguntó en el canal que la empresa puso para eso. El tribunal señaló que Air Canada no explicó por qué una parte de su web debía ser más fiable que otra.
Calibrar es mostrar de dónde sale la respuesta, hacer que el lenguaje refleje la certeza real y dejar un camino claro hacia la fuente oficial cuando hay dinero o derechos en juego. Un asistente que responde igual de seguro a una pregunta trivial y a otra que compromete un reembolso está mal diseñado, aunque acierte casi siempre. Es lo que conté al hablar de errores dignos y errores que traicionan.
2. Fricción que no depende de la obediencia
A finales de abril de 2026, según su fundador, un agente de programación (Cursor con Claude Opus 4.6) borró la base de datos de producción de PocketOS y sus copias de seguridad en nueve segundos. Hacía una tarea rutinaria en el entorno de pruebas, encontró una conexión sin relación con esa tarea que le daba permiso para borrar, y la usó. Las copias estaban en el mismo volumen. La empresa había configurado reglas de seguridad explícitas, y al preguntarle después, el agente enumeró las que había incumplido. Según el fundador, Railway acabó recuperando los datos más recientes.
Una regla escrita no es un control. Ya escribí que saber cuándo no usar IA es la nueva competencia de producto. Aquí es el sistema el que tiene que saber cuándo no actuar. La fricción que protege tiene que vivir en la estructura: permisos que no dejen borrar producción desde una tarea de pruebas, entornos separados, una confirmación humana antes de lo irreversible. Y esa confirmación solo cuenta si la persona entiende qué va a pasar. Un «¿Seguro?» genérico es un ritual, no una barrera.
3. Propósito operativo
En 2024, Klarna dijo que su asistente de IA hacía el trabajo de 700 agentes. En 2025, su CEO reconoció ante Bloomberg que el coste había pesado demasiado como criterio y que el resultado era una calidad menor. Klarna empezó a reclutar personas de nuevo para atención al cliente, y su CEO añadió algo que me parece importante: que el cliente tiene que saber que siempre podrá hablar con un humano si quiere.
Klarna corrigió y lo explicó en público, y eso le da crédito. Su caso enseña algo más fino que un propósito oculto: en 2024 anunció a la vez una satisfacción equivalente a la de los agentes humanos y un ahorro estimado de 40 millones de dólares. Cuando los dos objetivos chocaron, mandó el coste, y lo reconoció su propio CEO. Eso es el propósito operativo: el que gana cuando hay que elegir.
Escribe qué métrica gobierna de verdad el sistema y compárala con la promesa que le haces al usuario. Si no coinciden, el diseño ya está torcido antes de dibujar la primera pantalla.
4. Capacidad humana preservada
Un producto que mejora los resultados de hoy pero erosiona la capacidad del usuario para juzgar mañana está incompleto. Lo escribí en primera persona en ¿Cuándo fue la última vez que pensaste sin ayuda?. Aquí van datos, con sus límites.
En 2026, un preprint con tres experimentos aleatorizados (1.222 participantes reclutados, 1.060 en el análisis) midió un efecto parecido en tareas de laboratorio. Tras unos diez minutos con una IA que daba respuestas, la gente resolvía peor los problemas justo después de quitársela y, en dos de los tres experimentos, abandonaba más a menudo. El coste se concentró en quienes pedían la respuesta directa. Quienes pedían pistas rindieron casi igual que el grupo que no tuvo IA. Es un preprint, midió minutos y no años, con tareas sin consecuencias (fracciones y comprensión lectora),
En medicina la evidencia está dividida. Un estudio observacional de 2025 con endoscopistas polacos vio que detectaban menos adenomas cuando trabajaban sin IA tras haberla usado. Otro estudio observacional, prospectivo y de tres años, no vio deterioro, aunque es de un solo centro y entre sus autores hay desarrolladores del sistema.
Así que no sé si la IA deteriora la habilidad de un endoscopista. Sí sé qué haría un buen diseño: medir el desempeño humano sin asistencia en lugar de suponer que se conserva, programar práctica sin IA y diseñar la herramienta para ayudar con pistas y no solo con respuestas cuando el objetivo es que la persona aprenda.
Lo que tienen en común
Ninguno de los cuatro se arregla solo con un modelo mejor o una pantalla mejor. Son fallos de sistema: de procedencia de la información, de permisos, de métricas, de práctica. Es la capa donde se decide quién delega, quién verifica y cómo se recupera la confianza cuando algo sale mal.
Dónde puedo estar equivocado
Elegí fallos, y eso sesga la muestra: hay productos con IA bien diseñados que no salen en titulares y no he intentado medirlos. Tampoco sé cuánto de esto se resolvería con mejores modelos. La fricción, además, es peligrosa si se lleva al extremo, y no tengo una regla para decidir cuánta. Y los cuatro criterios son normativos: describen lo que yo considero buen diseño, no lo que haya demostrado dar mejores resultados. Si tienes datos en un sentido o en otro, me interesan.
Una pregunta antes de lanzar
Antes de lanzar un producto con IA, escribe qué ocurre cuando el sistema se equivoca con total seguridad, quién lo nota y cuánto cuesta. Si no puedes contestar a las tres cosas, falta diseño.
¿Qué responderías hoy sobre 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