Diseñar el permiso

Durante años, gran parte del diseño de interacción ha partido de una premisa bastante simple: el usuario decide y el sistema responde.

Hacemos clic, elegimos una opción, confirmamos una acción, enviamos un formulario. Incluso cuando el sistema automatiza parte del proceso, suele existir un momento claro en el que la persona inicia, valida o ejecuta lo que está ocurriendo.

La inteligencia artificial está empezando a cambiar esa relación.

Un sistema ya no tiene por qué limitarse a esperar una instrucción concreta. Puede interpretar una intención, anticipar el siguiente paso, preparar una acción e incluso ejecutarla sin que el usuario intervenga de nuevo en cada momento.

Y ahí aparece una nueva pregunta de diseño.

Ya no basta con preguntarnos qué puede hacer técnicamente una IA. También tenemos que decidir qué debería poder hacer sin nosotros.

Porque capacidad y permiso no son lo mismo.

Que un sistema pueda redactar un correo no significa que deba enviarlo. Que pueda reorganizar una agenda no significa que deba mover cualquier reunión. Que pueda encontrar una alternativa más barata no significa que deba realizar automáticamente una compra.

En cada uno de esos casos, la tecnología puede ser capaz de completar la acción. Lo que cambia es el grado de autonomía que estamos dispuestos a concederle.

Por eso, diseñar productos con IA implica empezar a trabajar con una frontera que antes era mucho más sencilla: hasta dónde puede avanzar el sistema antes de devolver la decisión a la persona.

Esa frontera no será igual para todas las acciones, ni para todos los usuarios, ni para todos los contextos.

Y probablemente una de las decisiones de diseño más importantes de los próximos años no será qué funciones incorporamos a la IA, sino cuáles de ellas puede ejecutar sin volver a preguntarnos.

Sugerir, preparar, confirmar y actuar son permisos distintos

Cuando hablamos de autonomía en sistemas con inteligencia artificial, es fácil caer en una simplificación: o la persona mantiene el control o la máquina actúa de forma automática.

Pero entre ambos extremos hay muchas posibilidades.

Una IA puede limitarse a sugerir una acción, preparar el siguiente paso y dejarlo listo, pedir una confirmación antes de ejecutarlo o actuar directamente cuando el contexto lo permite.

La diferencia entre una opción y otra no está necesariamente en la capacidad técnica del sistema, sino en el permiso que tiene para avanzar.

Un asistente puede recomendar varios horarios libres para una reunión. También puede redactar la invitación y seleccionar a los asistentes. Puede dejarlo todo preparado y pedir una confirmación final o, si ya existen unas condiciones definidas, enviar directamente la convocatoria.

La tecnología puede ser prácticamente la misma. Lo que cambia es el punto en el que la persona deja de intervenir.

Y ese punto no tiene por qué ser fijo.

La misma IA puede actuar con mucha autonomía en una tarea rutinaria y, pocos segundos después, pedir confirmación para otra acción con mayores consecuencias. Puede reorganizar una lista sin preguntar, preparar una respuesta sin enviarla y detenerse antes de realizar una compra.

Por eso, hablar de sistemas “autónomos” como una categoría única puede resultar engañoso.

Lo importante no es decidir si una IA es autónoma o no, sino qué grado de autonomía tiene en cada acción concreta.

Diseñar esa diferencia permite que la automatización no sea una propiedad general del producto, sino una decisión de interacción que puede adaptarse al contexto, al riesgo y a las expectativas del usuario.

El permiso debería depender de la acción, no del agente

Hablar de una IA como “autónoma” puede resultar útil para describir una capacidad general, pero es una categoría demasiado amplia cuando llega el momento de diseñar la experiencia.

Un mismo sistema puede comportarse de formas muy distintas según lo que esté haciendo.

Puede reorganizar automáticamente una lista, preparar una respuesta que todavía necesita revisión, sugerir una alternativa o detenerse antes de ejecutar una acción con consecuencias mayores.

Por eso, quizá la pregunta no debería ser cuánto control tiene el agente en términos generales, sino qué permiso tiene para cada acción concreta.

Esta diferencia es importante porque no todas las acciones tienen el mismo peso.

Cambiar el orden de unos elementos, modificar una reserva, enviar un mensaje o realizar un pago pueden formar parte del mismo flujo, pero no deberían compartir necesariamente el mismo nivel de autonomía.

Diseñar desde la acción obliga a mirar con más detalle qué ocurre en cada momento: qué cambia, quién puede verse afectado, qué consecuencias puede tener y qué margen existe para corregirlo después.

También evita una idea peligrosa: que, una vez concedida cierta autonomía al sistema, esa autonomía deba aplicarse por igual a todo lo que hace.

El permiso puede ser granular.

Una persona puede estar cómoda dejando que la IA resuelva determinadas tareas sin intervención y, al mismo tiempo, querer mantener la decisión final en otras.

Por eso, la unidad real de diseño no es el agente en abstracto, sino la acción, su contexto y sus consecuencias.

Cuándo introducir fricción

Durante años, una parte importante del diseño digital ha intentado reducir fricción: menos pasos, menos clics, menos interrupciones.

Pero cuando un sistema puede actuar por nosotros, eliminar fricción no siempre mejora la experiencia.

A veces, detenerse forma parte del buen diseño.

La cuestión no es añadir confirmaciones por precaución, sino entender qué tipo de acción está a punto de realizarse y qué consecuencias puede tener.

Hay acciones donde el coste de equivocarse es prácticamente irrelevante. En otras, una decisión puede implicar dinero, comprometer a otra persona, modificar información importante o resultar difícil de deshacer.

También importa la reversibilidad.

No es lo mismo una acción que puede corregirse inmediatamente que otra cuyos efectos son permanentes o muy difíciles de recuperar. Cuanto menor sea la posibilidad de volver atrás, más sentido tiene que el sistema reduzca su autonomía o solicite una intervención explícita.

Otro factor importante es si la acción afecta únicamente al usuario o también a terceros.

Reorganizar información personal puede requerir muy poca supervisión. Enviar un mensaje, cancelar una reunión o aceptar unas condiciones en nombre de alguien introduce consecuencias que van más allá de la propia interfaz.

Y está el contexto.

Una decisión que era válida cuando se inició una tarea puede dejar de serlo unos minutos después. Puede cambiar un precio, desaparecer una disponibilidad, modificarse un destinatario o aparecer nueva información que altere la decisión.

Por eso, diseñar autonomía también significa decidir cuándo merece la pena interrumpir el flujo.

No toda fricción es un obstáculo. En determinados momentos puede ser precisamente lo que permite al usuario entender qué está a punto de ocurrir, revisar una decisión o conservar el control cuando realmente importa.

La buena experiencia no será siempre la que pregunte menos, sino la que sepa cuándo preguntar tiene sentido.

Del “¿confirmas?” al permiso condicionado

Pedir confirmación antes de cada acción puede ser una forma sencilla de mantener el control, pero también tiene un límite.

Si un sistema pregunta constantemente, la confirmación deja de ser una decisión consciente y puede convertirse en un gesto automático.

En muchos casos, una alternativa más útil es permitir que el usuario defina de antemano las condiciones bajo las cuales la IA puede actuar.

No se trata de conceder un permiso general, sino de establecer límites concretos.

“Hazlo si cuesta menos de 50 euros.”

“Reserva solo si puede cancelarse.”

“Responde automáticamente únicamente a este tipo de mensajes.”

“Reorganiza mi agenda, pero no muevas reuniones con clientes.”

Este tipo de interacción cambia de forma importante el papel de la interfaz.

Ya no diseñamos únicamente el momento en el que alguien pulsa “Confirmar”. Diseñamos también las reglas que delimitan hasta dónde puede llegar el sistema sin volver a preguntar.

Eso exige que esas condiciones sean comprensibles, visibles y fáciles de modificar.

El usuario debería poder saber qué ha autorizado, en qué circunstancias se aplicará y qué excepciones ha definido. De lo contrario, la autonomía puede convertirse rápidamente en algo difícil de anticipar.

También aparece una cuestión interesante: una autorización no tiene por qué ser absoluta.

Puede depender de un importe, de un destinatario, de un horario, de una categoría de tarea o de cualquier otro elemento relevante para esa decisión.

En ese sentido, diseñar autonomía se parece menos a activar una función automática y más a definir el espacio dentro del cual el sistema puede actuar con libertad.

El reto ya no consiste solo en preguntar antes de hacer algo, sino en permitir que cada persona establezca con claridad cuándo no hace falta volver a preguntarle.

El sistema también debe saber cuándo volver a preguntar

Dar permiso a una IA para actuar no debería significar que ese permiso sea válido indefinidamente.

Las condiciones cambian.

Puede cambiar el precio, el destinatario, el nivel de riesgo, la información disponible o incluso el objetivo que tenía sentido unos minutos antes.

Una acción que encajaba perfectamente dentro de unas condiciones determinadas puede dejar de hacerlo cuando cambia el contexto.

Por eso, un sistema autónomo no solo necesita saber cuándo puede actuar. También necesita reconocer cuándo el permiso que tenía ya no es suficiente.

Imaginemos que alguien ha autorizado una reserva automática por debajo de un determinado importe. Si el precio aumenta, si cambian las condiciones de cancelación o si aparece un coste adicional, el sistema debería ser capaz de detenerse.

Lo mismo ocurre con acciones que afectan a otras personas.

Un mensaje automático puede ser perfectamente aceptable en un contexto habitual, pero quizá no cuando cambia el destinatario, el contenido adquiere mayor sensibilidad o la decisión empieza a tener consecuencias que no estaban previstas.

Aquí aparece una responsabilidad de diseño especialmente importante: definir qué cambios obligan al sistema a devolver la decisión a la persona.

No se trata de hacer que la IA dude constantemente, sino de identificar los momentos en los que seguir adelante supondría actuar bajo unas condiciones distintas de las que el usuario aceptó.

En ese sentido, la autonomía no consiste únicamente en avanzar sin intervención humana.

También consiste en saber cuándo detenerse.

Un sistema bien diseñado no demuestra inteligencia solo cuando resuelve una tarea por sí mismo, sino también cuando reconoce que el contexto ha cambiado lo suficiente como para volver a preguntar.

Conclusión

La evolución de la inteligencia artificial suele medirse en términos de capacidad.

Qué puede hacer, cuántas tareas puede completar, cuánto contexto puede interpretar o hasta qué punto puede actuar sin intervención humana.

Pero desde el diseño, quizá la pregunta más importante sea otra.

No cuánto puede hacer una IA, sino bajo qué condiciones debería poder hacerlo sin nosotros.

Porque a medida que los sistemas ganan autonomía, también aumenta la necesidad de definir límites claros: cuándo pueden avanzar, cuándo necesitan confirmación, qué condiciones deben respetar y en qué momento una autorización deja de ser válida.

Eso obliga a diseñar algo más que funcionalidades.

Obliga a diseñar permisos, excepciones, umbrales y momentos de retorno al usuario.

Y ahí aparece una diferencia importante entre una automatización simplemente eficiente y una experiencia realmente bien pensada.

La primera intenta reducir al máximo la intervención humana.

La segunda entiende que hay momentos en los que intervenir sigue siendo parte del valor de la experiencia.

Diseñar autonomía, por tanto, no consiste en eliminar al usuario del flujo.

Consiste en decidir con criterio cuándo puede apartarse y cuándo debe volver a entrar.

Porque un sistema no demuestra que está bien diseñado solo cuando sabe actuar por nosotros.

También cuando sabe reconocer que ha llegado el momento de devolvernos la decisión.

Si una IA puede completar una acción sin preguntarnos, ¿hemos diseñado también las condiciones que deberían obligarla a volver a hacerlo?