39 mandamientos para no crear un monstruo: diseñar interfaces donde la IA y los humanos no se destruyan mutuamente

Este artículo está basado en el ensayo 39 principles for designing human-AI interaction, publicado en UX Collective, donde se propone un framework aplicado para diseñar interfaces de IA que fomenten una dependencia apropiada, control del usuario, transparencia y autonomía responsable.

El interfaz no es el decorado. Es la obra entera.

Hay una fantasía recurrente en el mundo tech que suena más o menos así: “si el modelo es bueno, el producto será bueno”. Es la misma lógica que diría que si tienes un motor de Fórmula 1, cualquier coche que construyas ganará el Gran Premio. Ignora, claro, que alguien tiene que diseñar el volante, los frenos, el asiento, la pantalla del piloto. Ignora, en definitiva, que el rendimiento percibido de cualquier sistema inteligente depende brutalmente de la interfaz que lo envuelve.

UX Collective acaba de publicar uno de los marcos de trabajo más serios y necesarios que han aparecido en el mundo del diseño de IA: 39 principios para diseñar la interacción humano-IA. No es una lista de buenas intenciones ni un manifiesto filosófico. Es, como reza su subtítulo, un framework aplicado. Y eso lo cambia todo.

Porque el problema real no es la IA. El problema es que estamos construyendo coches de Fórmula 1 y poniéndoles el volante de un Seat Panda.

El pecado original del diseño de interfaces tradicionales

Las interfaces clásicas se construyeron sobre un pacto tácito con el usuario: “lo que ves es lo que hay”. Un botón hace una cosa. Un formulario tiene estados conocidos. Los errores se anticipan, se documentan, se corrigen. Hay un manual, aunque nadie lo lea.

La IA rompe ese contrato de forma irreversible. Introduce algo que los patrones de UI convencionales jamás contemplaron: la misma entrada puede producir salidas diferentes. El sistema no es determinista. No hay un estado correcto universal. Y eso genera una clase de problemas de interacción para los que simplemente no teníamos vocabulario de diseño:

• ¿En qué momento debe el sistema sugerir, preguntar o actuar directamente?
• ¿Cómo se comunica la incertidumbre sin generar parálisis?
• ¿Quién tiene el control real, el usuario o el modelo?
• ¿Cómo evitas que alguien confíe ciegamente en una respuesta errónea?

Estas no son preguntas filosóficas. Son preguntas de producto. Y si nadie las responde en el proceso de diseño, las responde el usuario por su cuenta, generalmente de la peor manera posible.

Confianza apropiada: el equilibrio más difícil del diseño moderno

Uno de los ejes centrales del framework es el concepto de “reliance apropiada”, que podríamos traducir como dependencia calibrada. No se trata de que el usuario confíe en la IA —eso es fácil de conseguir, peligrosamente fácil— sino de que confíe en la medida justa: lo suficiente para beneficiarse del sistema, no tanto como para desconectar su criterio.

Es el mismo problema que tienen los pilotos de avión con el piloto automático. El sistema funciona tan bien la mayor parte del tiempo que el piloto humano pierde práctica, vigilancia y capacidad de reacción para las excepciones. En aviación esto tiene nombre: automation complacency. En diseño de productos de IA, todavía estamos aprendiendo a nombrarlo.

El framework propone que el diseño debe trabajar activamente contra la sobreconfianza. Esto implica decisiones contraintuitivas: a veces hay que hacer que la IA parezca menos segura de lo que es, mostrar alternativas incluso si una respuesta es probablemente correcta, o interrumpir flujos automáticos para forzar una revisión humana. No es diseño que deslumbra en las demos. Es diseño que funciona en el mundo real.

Transparencia sin parálisis: el arte de la honestidad útil

Otro principio que merece atención especial es el de la transparencia. Hay una corriente en el diseño de IA que interpreta “transparente” como “explica absolutamente todo lo que hace el sistema”. El resultado suele ser interfaces abrumadas de disclaimers, porcentajes de confianza, advertencias legales y textos en gris pequeño que nadie lee.

Eso no es transparencia. Es transparencia decorativa. El equivalente digital de incluir los términos y condiciones en 47 páginas de letra microscópica: técnicamente honesto, funcionalmente opaco.

Los 39 principios hacen una distinción más fina: la transparencia tiene que ser accionable. No basta con decirle al usuario “este resultado puede ser incorrecto”. Hay que darle las herramientas para verificarlo, el contexto para evaluarlo y la fricción justa para que no lo ignore. La información sobre incertidumbre solo tiene valor si cambia el comportamiento del usuario de manera útil.

Autonomía responsable: ¿quién conduce este coche?

Quizás el territorio más interesante —y más peligroso— del framework es el de la autonomía. ¿Hasta qué punto debería una IA actuar por su cuenta? ¿Enviar ese email? ¿Ejecutar esa transacción? ¿Borrar ese archivo?

La tentación del producto es siempre maximizar la autonomía. Más autonomía = menos fricción = más impresionante en el pitch. Pero hay una asimetría fundamental que el diseño debe tener en cuenta: el coste de un error aumenta exponencialmente con el nivel de autonomía. Una sugerencia incorrecta es molesta. Una acción incorrecta ejecutada sin confirmación puede ser catastrófica.

El framework propone pensar la autonomía como un espectro con niveles claramente definidos, y diseñar explícitamente qué nivel corresponde a cada tipo de acción. No es lo mismo que el sistema complete automáticamente un campo de texto que envíe un contrato en tu nombre. Parece obvio. No lo es en la práctica, donde los equipos de producto optimizan para la demo y no para el caso límite.

El control del usuario no es una feature. Es la estructura

Hay un principio transversal que atraviesa todos los demás: el control del usuario no puede ser un añadido de última hora, una pantalla de configuración escondida en el menú de ajustes. Tiene que ser arquitectónico.

Esto significa que la capacidad de interrumpir, corregir, revertir o simplemente decir “no, hazlo de otra manera” no puede depender de que el usuario encuentre el botón correcto bajo presión. Tiene que estar presente en el flujo principal, visible en el momento en que más se necesita, accesible incluso para alguien que no ha leído el manual —que, recordemos, es todo el mundo.

En términos de arquitectura de la información, esto implica repensar completamente algunos patrones que hemos heredado del software clásico. Los undo/redo tradicionales no son suficientes para sistemas que aprenden, se adaptan y actúan. Necesitamos nuevos patrones, nuevas metáforas, nuevos contratos visuales entre el sistema y quien lo usa.

39 principios y una sola verdad incómoda

Al final, lo que hace valioso este framework no es la cantidad de principios —podría haber sido 12 o 200— sino la premisa que los une: la calidad de un producto de IA no la determina el modelo. La determina el diseño que lo rodea.

Eso debería ser una llamada de atención para cualquier equipo que esté construyendo sobre modelos de lenguaje, sistemas de recomendación, agentes autónomos o cualquier otra forma de inteligencia artificial. El modelo es el motor. Pero el coche lo diseñamos nosotros. Y si el volante está mal puesto, da igual cuántos caballos tenga debajo del capó.

El monstruo no lo crea el científico loco. Lo crea el diseñador distraído.