UI generativa: cuando la IA decide la interfaz

¿Qué es, en la práctica?

La pantalla deja de ser una lista fija de vistas y pasa a ser una respuesta a lo que la persona está haciendo. Un asistente de viajes puede mostrar un selector de fechas cuando la conversación llega a las fechas, y un mapa cuando se pregunta por hoteles cercanos. Ninguna de esas piezas estaba en una pantalla predefinida: el modelo las eligió.

Conviene separarla de otras formas de IA dentro de la interfaz. Un chat genera texto. Una UI generativa genera estructura: qué bloques aparecen, en qué orden y con qué controles. El chat es un contenedor; la UI generativa es una forma de componer lo que hay dentro.

¿Qué patrones existen?

La guía de producción de MetaCTO distingue tres patrones según cuánta libertad tiene el modelo:

Cuanto más se acerca el sistema a generar código en ejecución, más difícil es probarlo y recuperarse de sus fallos. La propia guía recomienda restringir al modelo a seleccionar y configurar un inventario fijo de componentes. Por eso la mayoría de los equipos empiezan por selección.

¿Qué protocolos y SDKs existen hoy?

Estado consultado en las fuentes oficiales el 1 de noviembre de 2026. Todo esto cambia rápido: revisa la fecha de tus fuentes.

Las diferencias de diseño importan. En A2UI el cliente define un catálogo de componentes de confianza, como Card, Button o TextField, y el agente solo puede pedir piezas de ese catálogo: la interfaz usa tus propios componentes y estilos. En MCP Apps el servidor trae su propio HTML, aislado en un iframe: es más flexible, pero se parece menos a tu producto. AG-UI no es un formato de pantalla sino el canal por el que viajan los mensajes. Para entender el lado de las herramientas, mira MCP explicado para diseñadores.

¿Por qué le importa a un diseñador?

Porque la UI generativa mueve decisiones que eran del diseñador a un modelo que decide en tiempo real. Tiene tres consecuencias.

La primera es la predictibilidad. Quien usa un software a diario aprende sus pantallas; si el layout cambia en cada visita, ese aprendizaje se pierde. Pesa más en productos de uso repetido, donde la eficiencia viene de la familiaridad. El artículo de Lazarev Agency propone envolver las zonas generativas en una navegación y un layout fijos, para que nadie pierda la orientación cuando el contenido cambia.

La segunda es el vocabulario de componentes. El mismo artículo dice que hay que diseñar primero ese vocabulario, porque un modelo compone bien solo con piezas pensadas para recombinarse, y que los componentes inconsistentes producen pantallas generadas inconsistentes. Aquí sirve un sistema de diseño bien documentado. La accesibilidad también depende de eso: si el modelo elige el orden de lectura y los encabezados, nada garantiza una estructura estable para un lector de pantalla, salvo que los componentes del catálogo ya la traigan resuelta.

La tercera es el diseño de los estados de excepción. Una interfaz generada va a fallar a veces. El mismo artículo trata los estados vacío, de error y de baja confianza como entregables centrales, porque no hay una pantalla fija de respaldo.

¿Cómo se aplica en un producto?

Cuatro pasos para empezar:

1. Define el catálogo. Lista los componentes permitidos (tarjeta, lista, formulario corto, gráfico, botón de acción), cada uno con sus propiedades.
2. Fija la estructura. Deja navegación y layout estables alrededor de la zona generativa.
3. Diseña los estados de baja confianza. Cuando el modelo no sabe, muestra algo distinto: una pregunta de aclaración o una vista más simple.
4. Mantén un punto de control humano. Para acciones con efecto real, la interfaz debe mostrar qué va a pasar y pedir confirmación. Lo generado puede proponerse; no debería ejecutarse solo. Mira aprobación de acciones.

Conviene en productos donde la personalización amplia es parte del valor. En un producto simple y casi estático, una interfaz fija suele ser mejor.

¿Cuándo NO conviene la UI generativa?

• Cuando la estructura de la tarea es finita y conocida. Un formulario da un estado claro y una validación comprobable.
• Cuando hay efectos reales. Mover dinero, enviar mensajes o escribir en un sistema de registro necesita una interfaz diseñada, con confirmación explícita.
• Cuando hay auditorías. Una pantalla que cambia es difícil de usar como evidencia de lo que la persona vio, salvo que guardes lo que se mostró.
• Cuando la latencia importa. Generar la interfaz añade tiempo de espera frente a una pantalla ya construida.

Ejemplo

Ejemplo ilustrativo: un panel de finanzas personales. Alguien pregunta “¿cuánto gasté en comida este trimestre?”. El modelo elige entre tres componentes del catálogo (un gráfico de barras, una tabla y una tarjeta de resumen) y rellena sus datos. Los tres ya estaban diseñados, con sus estados de carga, error y vacío. Lo único que decidió la IA fue cuál usar. Si la persona quiere mover dinero desde ese panel, aparece un formulario fijo con confirmación, no un componente generado.

Errores comunes

• Dejar que el modelo genere código en producción sin pruebas que cubran esos casos.
• Cambiar el layout en cada visita y desorientar a quien trabaja a diario en la misma pantalla.
• Generar componentes sin un sistema de diseño detrás: el resultado se ve coherente solo en la demo.
• No diseñar el estado de error ni el de baja confianza.
• Usar UI generativa para acciones que deberían tener un formulario y una confirmación.
• Basar una decisión en una versión de protocolo vieja: A2UI y MCP Apps se anunciaron hace menos de un año y siguen cambiando.

Fuentes

• Google Developers Blog: Introducing A2UI
• A2UI: sitio del proyecto
• Blog de MCP: MCP Apps (26 de enero de 2026)
• AI SDK: interfaces de usuario generativas
• AI SDK: introducción
• AI SDK RSC: resumen
• AG-UI: documentación
• MetaCTO: Generative UI, When AI Should Build the Interface
• Lazarev Agency: Generative UI design