¿Proponer una interfaz otorga permiso para actuar?

La IA puede sugerir la disposición de una pantalla, la información que mostrar y las acciones que ofrecer. Aplicar la propuesta, comprobar la veracidad de los datos y autorizar la operación exigen decisiones separadas. ¿Cómo abordo este límite en Muhit?

Imaginemos que queremos revisar una nota de investigación. Pedimos al sistema una vista que reúna las fuentes y muestre lo que falta.

El modelo propone un resumen, una tabla de fuentes y algunas acciones. En pantalla podrían aparecer botones como «Revisar nota», «Aplicar corrección» o «Publicar».

Hasta aquí se ha propuesto un entorno de trabajo. Pero, cuando los botones se hacen visibles, surgen otras preguntas: ¿qué registro cambiará? ¿Quién podrá modificarlo? ¿Cómo se interpretará la elección de la persona? Cuando termine la operación, ¿con qué evidencia lo afirmaremos?

En el trabajo de Muhit sobre interfaces generadas con IA, me interesa que estas preguntas no queden sin resolver detrás de la pantalla.

Una propuesta necesita una forma comprensible

A partir de la petición de una persona, un modelo puede sugerir qué información conviene mostrar junta. Puede dividir una respuesta larga en secciones, colocar en una tabla registros que se van a comparar o describir un formulario para campos que necesitan edición.

Es una posibilidad útil, sobre todo para contenidos cuya presentación aún no se ha decidido. Si cambia la necesidad, también puede cambiar la vista.

El adaptador de interfaces JSON de Muhit actúa como la capa que convierte esa propuesta en componentes definidos. La conexión con el modelo corresponde a la aplicación; el adaptador no contiene un modelo que funcione por su cuenta ni un servicio de operaciones autónomas.

Primero se valida la definición recibida. Se comprueban los tipos de componentes, los campos obligatorios y los valores admitidos. Una definición válida se representa mediante los componentes permitidos.

Así, la vista propuesta por el modelo entra en un espacio de expresión que la aplicación ha delimitado de antemano. La definición no puede incorporar código arbitrario ni permisos para realizar operaciones.

Pero hay que entender qué nos dice realmente esa validación.

Un encabezado con una estructura correcta no demuestra que la afirmación situada debajo sea verdadera. Una tabla formada por filas válidas no prueba que sus registros estén actualizados. Que una acción aparezca en la definición tampoco significa que esté permitido ejecutarla.

Una definición de interfaz válida no puede decidir por sí sola si el contenido es verdadero o si una operación está autorizada.

Por eso, en el ejemplo de la nota de investigación, la aplicación debe aclarar además de dónde proceden las fuentes, a qué versión corresponden y qué información es una interpretación del modelo. Una pantalla ordenada no debería sustituir estas distinciones.

El camino del botón a la operación real

En Muhit, una acción de una tarjeta puede enviar a la aplicación un evento con los identificadores del componente y de la acción. La aplicación lo vincula con un comportamiento que reconoce.

Por ejemplo, «Revisar nota» podría abrir el detalle de un registro determinado por la aplicación. El adaptador no lee el nombre de la acción y genera por su cuenta una dirección, guarda datos o inicia una publicación.

Este límite tiene una consecuencia práctica: que el modelo escriba «Publicar» en un botón no otorga a la aplicación una nueva capacidad de publicación. La aplicación debe reconocer la operación, determinar sobre qué registro se realiza y comprobar los permisos necesarios.

Una aplicación de publicación podría organizar el recorrido así: la persona revisa el cambio propuesto, la aplicación muestra el registro afectado y el alcance, y el servidor comprueba los permisos y el estado actual del registro. El éxito se comunica después de conocer el resultado de la operación real.

Este recorrido no es un sistema de publicación que Muhit proporcione por sí solo. Es un ejemplo de comportamiento de aplicación que podría construirse con sus componentes.

También hay que distinguir entre un evento y la intención de la persona. Recibir un evento de un componente no constituye, por sí solo, prueba de una orden humana autorizada. Algunos eventos de estado también pueden surgir de cambios hechos por el código de la aplicación. La existencia de un manejador de eventos no sustituye las comprobaciones de identidad y permisos.

Por tanto, no basta con vincular la autorización a que un botón sea visible. El permiso debe evaluarse también en la capa donde se ejecuta la operación.

En el segundo artículo traté la diferencia entre la confirmación local y el almacenamiento persistente. Aquí se aplica el mismo principio: el resultado que comunica la interfaz debe describir el alcance de lo que realmente ocurrió.

El control humano empieza por comprender

Es fácil reducir el control a un botón de confirmación. Pero, si alguien no puede entender qué está aprobando, la presencia del botón no basta.

En el ejemplo de la nota de investigación, el cambio propuesto debe poder verse antes de elegir «Aplicar corrección». ¿Qué frase cambia? ¿El cambio se apoya en una fuente o procede de la interpretación del modelo? ¿Sobre qué versión del texto actual se está trabajando?

Esta información constituye el contexto de la decisión.

Una interfaz que preserve el control humano debe mantener abiertas las vías para revisar una propuesta, modificarla cuando sea necesario y descartarla. En vez de pedir una confirmación de igual peso para cada operación, hay que pensar el control en proporción a sus consecuencias. Un filtro que reduce la vista y una acción que modifica un texto publicado tienen efectos distintos.

Una nueva propuesta del modelo tampoco debería romper esta continuidad. Si la pantalla se reconstruye mientras alguien edita un campo, debe haberse decidido de antemano qué ocurrirá con lo que está escribiendo.

El adaptador de Muhit conserva la vista actual cuando una actualización no es válida. Una actualización correcta reconstruye la vista; los filtros y la selección de la tabla anterior no se transfieren automáticamente. Si hay un estado del usuario que deba conservarse, la aplicación tiene que gestionarlo aparte.

Este detalle técnico afecta directamente al control humano. Las personas deben poder distinguir sus propios cambios de la nueva propuesta del modelo y volver al trabajo que empezaron.

Este es el límite que intento establecer en Muhit: definir con claridad el espacio de propuestas del modelo y mantener visibles tanto la responsabilidad de la aplicación como la decisión humana.

Poder generar una pantalla abre una posibilidad importante. Usarla con confianza depende de que se comprenda el camino entre la propuesta y el resultado real.

Cuando alguien puede decir «Esto lo propuso el sistema; esta parte la cambié yo; esta operación la elegí yo; este resultado ocurrió realmente», la interfaz abre espacio para crear y conserva el rastro de la decisión.

---

Fuente: el contrato de interfaces JSON de Muhit y los principios de diseño del código local de desarrollo. La nota de investigación y el recorrido de publicación son escenarios ilustrativos para explicar los límites de responsabilidad.

Artículos anteriores sobre Muhit: Muhit: ¿Qué hace coherente una interfaz? · Muhit: ¿Cómo funciona una decisión de diseño en pantalla?

Conceptos del Atlas: Diseño · Software · Contexto · Sistemas · Inteligencia