El mapa: seis grupos de conceptos

Un mapa de metro: primero ves las líneas enteras, luego recorres estación por estación.

Los conceptos de este curso se dividen en seis grupos. El primero trata de la naturaleza del propio modelo. Los otros cinco son las cinco respuestas del diseño: expectativas honestas, mostrar el trabajo, el humano al mando, fallo elegante y el feedback loop. El capítulo siete lo une todo y añade el principio de cierre: Design for the Unhappy Path.

Cómo leer cada concepto

Un pasaporte: los mismos campos para todos, así es fácil compararlos.

Cada concepto a partir de aquí tiene las mismas partes: un nombre en inglés (recuérdalo: es el término que buscarás en artículos y guías), una imagen de la vida cotidiana, un diagrama y una tarjeta con campos: problema, idea, ejemplo, coste, cuándo usarlo y relaciones. La única regla de todo el curso: el modelo se equivocará, y el diseño decide en qué se convierte eso.

Fallible Component — el modelo es seguro incluso cuando se equivoca

Un experto carismático que da cada respuesta con el mismo tono de autosuficiencia — las correctas y las inventadas suenan exactamente igual.

Un modelo de lenguaje produce salidas fluidas y seguras esté o no en lo correcto. Sus errores no llegan con un tono de preocupación ni con una señal de alerta. Este es el componente falible — el desafío de diseño que define a los productos de IA. La interfaz no puede confiar en que el modelo señale su propia incertidumbre: suena igual de seguro cuando acierta y cuando alucina.

Así que es el diseño el que tiene que aportar lo que el modelo no aportará: pistas sobre la fiabilidad, espacio para verificar, formas de recuperarse. Estás envolviendo una experiencia de usuario alrededor de un componente seguro y falible.

Trust by Design — la confianza la construye el diseño, no el modelo

Confías en un buen banco no porque el cajero sea infalible, sino por los recibos, los extractos y la posibilidad de disputar un cargo — el sistema se gana una confianza que la persona por sí sola no podría.

Los usuarios no confiarán en una función de IA porque sea potente. Confiarán en ella porque la experiencia que la rodea les hace sentir seguros: pueden comprobarla, corregirla, deshacerla y saber qué esperar. Esto es trust by design: el modelo aporta capacidad; el diseño aporta confianza.

Un modelo brillante en una interfaz descuidada se siente poco fiable; un modelo modesto en una interfaz cuidadosa se siente de fiar. La confianza es una propiedad del producto que construyes, no del modelo que usaste.

Autonomy Calibration — ajusta la libertad a lo que está en juego

Dejarás encantado que una herramienta autocorrija una errata, pero querrás leer cada palabra antes de que envíe una carta legal — el mismo motor, salvaguardas muy distintas.

Cuánta libertad le das a la IA debería seguir lo costoso que sería un error. Esto es la autonomy calibration. Una salida de bajo riesgo y fácilmente reversible (una etiqueta sugerida, una frase borrador) puede ser más automática. Una acción de alto riesgo e irreversible (enviar dinero, borrar datos, publicar) exige revisión y confirmación.

Es la decisión más importante del diseño de producto con IA. Puedes equivocarte en ambas direcciones: demasiada libertad y la función es temeraria; muy poca y es inútilmente tímida.

AI Disclosure — di que es IA y que puede equivocarse

Un pronóstico del tiempo dice «70 % de probabilidad de lluvia», no «va a llover» — nombrar la incertidumbre de antemano es lo que hace que la gente confíe incluso cuando falla.

AI disclosure significa decir con franqueza que una función funciona con IA y que su salida puede ser imperfecta. Esto no es una disculpa ni una debilidad: es calibración. Un usuario que sabe que recibe una sugerencia de IA la lee como corresponde: útil, digna de revisarse, no un evangelio.

Ocultar que la salida está generada por IA, o dar a entender que es autoritativa, lleva a la gente a confiar de más y luego a sentirse traicionada cuando se equivoca. Un encuadre honesto convierte una respuesta errónea de traición en un suceso esperado y manejable.

Draft Framing — presenta las salidas como borradores

Un sello manuscrito de «borrador» en un documento cambia cómo lo lees: lo tratas como un punto de partida que mejorar, no como una última palabra que acatar.

Las palabras que rodean una salida moldean cuánto confían en ella los usuarios. Draft framing significa presentar los resultados de la IA como borradores, sugerencias o puntos de partida y no como respuestas acabadas y autoritativas. Invita al usuario a leer con ojo crítico y a editar — exactamente la postura correcta ante una herramienta falible.

«Aquí tienes un borrador que puedes editar» produce mejores resultados y menos desastres que «aquí está la respuesta». El encuadre hace un trabajo silencioso y constante para mantener al usuario en la relación correcta con el modelo.

Under-promise, Over-deliver — no vendas de más

Un vendedor que promete que un aparato lo hace todo te hace sentir engañado; uno que te dice exactamente en qué es bueno y en qué es malo se gana una confianza duradera.

Es tentador vender una función de IA como magia, pero prometer de más garantiza la decepción: la brecha entre la promesa y la realidad se convierte en la experiencia del usuario. El principio de under-promise, over-deliver es fijar las expectativas un poco por debajo de lo que el modelo puede hacer, y dejar que sorprenda para bien.

Ser honesto sobre sus límites — incluso de forma destacada — construye una confianza mucho más duradera que un bombo que el primer fallo hace añicos.

Citations — cita las fuentes detrás de una respuesta

Un artículo científico con notas al pie permite a cualquier lector rastrear una afirmación hasta su fuente — las citas son lo que lo hace creíble y no solo seguro.

Cuando el modelo responde a partir de información recuperada, muestra las fuentes (citations): enlaza el documento, cita el pasaje, señala de dónde salió la afirmación. Las citas permiten a los usuarios verificar una respuesta en lugar de aceptarla por fe. Convierten al modelo de un oráculo en el que hay que creer en un asistente de investigación al que se puede comprobar.

Este es el beneficio de diseño del grounding: no basta con que la respuesta tenga fuente dentro del sistema — el usuario tiene que ver la fuente y poder seguirla.

Verifiability — verificable, no solo plausible

Un buen contable no se limita a darte una cifra: te muestra las partidas, para que puedas confirmarla en lugar de fiarte de un total seguro.

Verifiability significa diseñar para que el usuario pueda comprobar la salida, no solo recibirla. Muestra en qué basó el modelo su respuesta, resalta los datos concretos que usó, facilita contrastarla con la realidad.

Una respuesta verificable es digna de confianza incluso cuando a veces se equivoca, porque el usuario puede pillar las erróneas. Una respuesta no verificable es peligrosa incluso cuando casi siempre acierta, porque no hay manera de distinguir las buenas de las malas. Construye para comprobar, y los errores inevitables pasan a ser detectables en lugar de costosos.

Confidence Signals — muestra la confianza y el razonamiento

Un médico que dice «estoy bastante seguro, pero confirmémoslo con una prueba» te guía mejor que uno que enuncia todos los diagnósticos con idéntica certeza.

Donde puedas, muestra confidence signals: un nivel de confianza, los pasos del razonamiento, una marca cuando el modelo no está seguro o trabaja con poca evidencia. Esto ayuda a los usuarios a decidir cuánto apoyarse en cada respuesta, en lugar de tratarlas todas como igual de sólidas.

No será perfecto. Pero incluso una señal aproximada de «esta es dudosa» mejora enormemente la seguridad con la que la gente usa la función. Dar al usuario la señal de fiabilidad que el tono del modelo oculta es de lo más valioso que puedes hacer en diseño.

Suggest, Don't Act — asiste, no actúes sin que te lo pidan

Un buen asistente redacta el correo y te lo deja para que lo envíes tú — no pulsa «enviar» por su cuenta y te lo cuenta después.

Para todo lo que tenga consecuencias, diseña la IA para que sugiera en lugar de actuar: que proponga la edición, redacte el mensaje, recomiende la opción — y deje decidir al humano. Esto mantiene a un humano en el circuito en las decisiones que importan, de modo que un error del modelo se convierte en una sugerencia rechazada y no en un error ejecutado.

Cuanto más importa una acción o menos se puede deshacer, más firmemente debe el modelo proponer y el humano disponer. Una asistencia que el usuario dirige es más segura que una autonomía que el usuario solo supervisa.

Editable Output — deja que los usuarios editen, no solo acepten o rechacen

Una buena plantilla te deja cambiar las partes que no encajan, en lugar de obligarte a elegir todo o nada entre perfecto e inútil.

Las mejores interacciones con IA permiten al usuario dar forma a la salida, no solo tomarla o dejarla. Esto es editable output: resultados de la IA fáciles de editar, refinar y conservar en parte. El modelo suele llevarte el 80 % del camino, y el valor está en dejar que el humano termine el último 20 % en lugar de descartarlo todo por un defecto.

Tratar la salida como arcilla editable y no como un veredicto acabado encaja con cómo rinde realmente el modelo: un buen borrador que un humano mejora. La capacidad de edición convierte el «casi correcto» de un fracaso en ventaja inicial.

Confirm & Undo — confirma antes de lo irreversible

Un banco exige una segunda confirmación para una transferencia grande — una pausa deliberada antes de lo que no se puede recuperar.

Pon un paso de confirmación claro antes de cualquier acción que el usuario no pueda deshacer: enviar, pagar, borrar, publicar. Es el mismo pensamiento de blast radius de la seguridad, expresado en la UX: un error del modelo debería producir, como mucho, una sugerencia que el usuario rechaza, nunca una acción irreversible ejecutada por su cuenta.

Y combínalo con undo siempre que puedas, para que incluso las acciones aceptadas sigan siendo recuperables. Poder dar marcha atrás es lo que permite a los usuarios actuar con confianza, y no con miedo, sobre lo que propone la IA.

Abstention — deja que diga «no lo sé»

El experto en quien más confías es el que dice «eso queda fuera de lo que sé» en lugar de inventarse algo con seguridad para llenar el silencio.

Abstention significa diseñar la experiencia para permitir — y preferir — un honesto «no lo sé» o «no estoy seguro» antes que una respuesta inventada. El fallo más peligroso de la IA es inventar con seguridad una respuesta cuando no tiene base alguna. Un producto que hace de la negativa un resultado válido y elegante es mucho más seguro que uno que presiona al modelo para que siempre produzca algo.

Sacar a la luz la incertidumbre en lugar de disimularla no es un fallo de la función: es la función trabajando con honestidad. Un modelo que conoce sus límites, y un diseño que los respeta, se gana más confianza que uno que siempre responde.

Low-confidence Routing — manda el caso dudoso por otro camino

Un filtro de spam que está seguro enruta el mensaje automáticamente, pero uno que duda lo marca para que lo revises tú — el caso incierto se atiende, no se esconde.

No trates todas las salidas igual sin importar lo dudosas que sean. Cuando el modelo no está seguro o trabaja con evidencia débil, diseña un camino distinto — es el low-confidence routing: márcalo, pide confirmación, pásalo a un humano o hazle una pregunta aclaratoria al usuario.

Los casos inciertos son justo donde la automatización a ciegas hace más daño, así que merecen su propio tratamiento en lugar de salir con la misma seguridad que los sólidos. Diseñar para el terreno dudoso del medio, y no solo para el happy path, es lo que hace robusta la función.

Graceful Degradation — degrada, no te derrumbes

Cuando el GPS pierde la señal, muestra tu última posición conocida y dice «buscando», en lugar de quedarse en blanco o mandarte por un precipicio — falla con suavidad.

Cuando la IA no puede cumplir — un error, una caída, una petición fuera de alcance — la experiencia debería degradarse con elegancia en lugar de romperse o, peor, producir basura. Recurre a una opción más simple, un mensaje claro, un camino manual, un resultado en caché.

Una función que falla hacia un estado sensato y honesto conserva la confianza del usuario; una que falla hacia una respuesta errónea y segura, o hacia una pantalla rota, la destruye. Planifica los modos de fallo tan deliberadamente como el camino del éxito, porque con un componente falible el fallo forma parte del funcionamiento normal.

Feedback Controls — da a los usuarios una forma fácil de reaccionar

Un pulgar arriba y un pulgar abajo junto a cada respuesta — una forma de un toque para que el usuario te diga si acertó o falló, sin costarle nada.

Los feedback controls — pulgar arriba/abajo, una valoración rápida, una marca — hacen que decir si una salida fue buena o mala no cueste esfuerzo. Esto logra dos cosas a la vez: el usuario siente que tiene voz y que lo escuchan, y tú obtienes un flujo continuo de señal real sobre dónde funciona la función y dónde falla.

Una función que no se puede valorar es una función en la que vuelas a ciegas; un simple control de reacción es el feedback más barato y más rico que obtendrás. Captura la reacción que los usuarios darían de todos modos.

Corrections as Signal — deja que las correcciones enseñen al sistema

Cuando corriges la dirección que te sugirió el teclado del móvil, aprende — la corrección no sirve solo para esta vez, mejora la siguiente.

El feedback más rico es que el usuario corrija la salida. Cuando alguien edita una sugerencia de la IA, esa edición es una señal precisa de cómo era lo «correcto». Esto es corrections as signal, o implicit feedback — captúralo. Las correcciones y los rechazos son oro: te dicen exactamente dónde se quedó corto el modelo, en casos reales.

Devuélvelos a tus evals (véase el curso de evals) para que la función mejore de forma medible, y el producto mejore siguiendo los contornos de donde los usuarios reales de verdad tropiezan. La corrección es a la vez un arreglo para ahora y una lección para después.

Feedback Loop — el feedback de producción es tu mejor conjunto de evals

Las mejores preguntas de examen salen del examen real que hicieron los alumnos, no de lo que imaginó el profesor — la realidad escribe mejores pruebas que tú.

Las reacciones y correcciones que llegan del uso real son la fuente más valiosa de casos de eval que tienes: son lo que tus usuarios de verdad hacen, incluidos los fallos que nunca habrías inventado. Explotar este feedback para encontrar dónde se rompe la función, e incorporar esos casos a tu conjunto de evals, cierra el feedback loop: producción te enseña qué arreglar, lo arreglas y el siguiente lanzamiento es mejor.

Un producto con este ciclo en marcha mejora de forma continua; uno sin él va a tientas. El ciclo es lo que hace que una función de IA mejore en lugar de simplemente existir.

Autonomy Calibration en todas partes — capas de salvaguardas según lo que está en juego

Dejas que el asistente tramite los papeles por su cuenta, que redacte la carta importante para que la revises y que nunca firme el contrato sin ti — autonomía escalada a la consecuencia.

La decisión que lo unifica todo, tomada una y otra vez a lo largo de un producto, es cuánto dejar que haga la IA por su cuenta y cuánto pasar por el humano. La respuesta es siempre Autonomy Calibration: ajústala a lo que está en juego. Lo de bajo riesgo y reversible puede ser más automático; lo de alto riesgo e irreversible recibe encima capas de expectativas, verificación, control y confirmación.

Un producto de IA bien diseñado no es uniformemente autónomo ni uniformemente cauteloso. Está calibrado, pieza por pieza, según lo que costaría un error ahí.

Design for the Unhappy Path — diseña para la respuesta equivocada

Un buen ingeniero de seguridad diseña el coche asumiendo que habrá un choque, no esperando que no lo haya — los airbags son para el mal día, y son el objetivo.

La marca del diseño de producto con IA maduro es que está construido en torno a que el modelo esté equivocado, no solo en torno a que acierte. Este es el principio de designing for the unhappy path. La demo muestra la respuesta correcta; el producto sobrevive a la equivocada. Así que diseñas la verificación, el control, el fallo elegante, el feedback loop — la maquinaria que hace que un error seguro de sí mismo sea detectable y recuperable.

Haz funcionar el happy path y tienes una demo; diseña para el unhappy path y tienes un producto al que la gente puede confiar de verdad un trabajo real.

Cómo encaja todo

Una orquesta: cada sección toca su propia parte, pero oyes una sola pieza de música.

Todo empieza por el Fallible Component: el modelo es seguro incluso cuando se equivoca. Los cinco grupos de prácticas — expectativas, mostrar el trabajo, control, fallo elegante, feedback — son las cinco respuestas del diseño. Autonomy Calibration decide cuánto de cada respuesta necesita un punto dado. Juntas producen Trust by Design. Y el feedback loop vuelve a fluir a través de los evals y mejora el modelo con el tiempo.