La UI que decide la IA: qué es la Generative UI
Durante años el patrón fue claro: el desarrollador diseña pantallas fijas y el código las pinta. La Generative UI (GenUI) rompe ese supuesto. La idea es que un agente de IA decida, en tiempo de ejecución, qué interfaz mostrar —qué componentes, en qué orden, con qué datos— y la app la renderice de forma nativa.
Respuesta directa para quien evalúa si esto ya es real o sigue siendo demo: es real y tiene estándar. Google publicó la GenUI SDK para Flutter y el protocolo abierto A2UI (Agent-to-UI), que en su versión 0.9 ya define un esquema portable y agnóstico de framework. No es una curiosidad de laboratorio: es parte del roadmap oficial de Flutter para 2026.
En Dribba somos Flutter Partner oficial de Google desde 2017 —la única agencia española en el directorio— así que este cruce entre Flutter e IA aplicada es exactamente nuestro terreno. Vamos a lo concreto, incluyendo cuándo no deberías usarlo.
A2UI en una frase
A2UI es un protocolo declarativo para que un agente describa una interfaz sin ejecutar código arbitrario en el cliente. El agente no envía un binario ni JavaScript: envía una declaración de UI que el cliente renderiza con sus propios widgets nativos. Por eso el mismo agente puede pintar en Flutter, React, Angular o Lit —los renderers soportados— sin reescribir nada.
El detalle de seguridad importa: el agente nunca ejecuta código en el dispositivo. Describe; el cliente interpreta contra su propio catálogo de componentes. Eso elimina de raíz toda una categoría de riesgos de "UI dinámica" que en el pasado obligaba a evaluar código remoto.
Cómo encaja en una app Flutter
La GenUI SDK conecta tu app a un servidor A2UI y renderiza la interfaz que el agente compone, ensamblando widgets reales de tu catálogo. El flujo, simplificado:
final genUiManager = GenUiManager(
// El catálogo limita QUÉ puede pintar el agente.
// Si no está aquí, no se renderiza. Punto.
catalog: myWidgetCatalog,
);
final surface = GenUiSurface(
manager: genUiManager,
onAction: (action) => handleUserIntent(action),
);
// El agente envía una declaración A2UI; GenUiSurface la pinta
// con tus widgets, respetando tu design system.
await genUiManager.connect(a2uiServer);
La pieza clave —y la que decide si esto es seguro en tu producto— es el catálogo de widgets. El agente solo puede componer con los componentes que le has dado. Si tu catálogo contiene una tarjeta de producto, un selector de fecha y un botón de confirmación, eso es todo lo que el agente puede pintar. No hay forma de que invente un componente que viole tu design system. La libertad del agente está acotada por diseño.
Dos arquitecturas: agente en servidor vs. agente on-device
Hay dos formas de montar esto y la elección no es trivial:
| Criterio | Agente en servidor (A2UI remoto) | Agente on-device (p. ej. Gemma) |
|---|---|---|
| Privacidad | Datos salen del dispositivo | Datos nunca salen del teléfono |
| Latencia | Depende de la red | Sin latencia de red |
| Coste | Coste de API por interacción | Cero coste de inferencia |
| Capacidad del modelo | Modelos grandes y potentes | Modelos ligeros, limitados |
| Offline | No funciona | Funciona sin conexión |
El on-device, con modelos como Gemma corriendo en el propio teléfono, es una de las tendencias fuertes de 2026 y conecta directamente con lo que ya cubrimos en Edge AI: modelos de IA en el dispositivo. Para datos sensibles —salud, finanzas— la combinación de GenUI on-device es especialmente interesante: la IA adapta la interfaz sin que un solo byte salga del dispositivo.
Casos donde aporta valor real
No es para cualquier pantalla. Donde hemos visto que tiene sentido:
- Interfaces conversacionales con resultado estructurado. El usuario pide algo en lenguaje natural y la respuesta natural no es un párrafo, sino un formulario, una tarjeta o un comparador. El agente compone ese widget en vez de describirlo con texto.
- Flujos muy ramificados. Onboardings o configuradores donde el siguiente paso depende de mucho contexto. En lugar de programar todas las ramas, el agente decide qué mostrar.
- Personalización profunda. Dashboards que se reordenan según lo que el usuario realmente usa.
Cuándo NO usar Generative UI
Aquí está el matiz que rara vez se cuenta. GenUI es una herramienta nueva y potente, y precisamente por eso es fácil meterla donde no toca.
- Pantallas críticas y deterministas. Un checkout, un flujo de pago, una pantalla legal. Aquí quieres control total, comportamiento predecible y testeable. Que una IA decida el layout de tu pasarela de pago es buscarse un problema.
- Cuando la latencia de inferencia rompe la experiencia. Si pintar la pantalla depende de que un modelo razone, has añadido una espera donde antes había un render instantáneo. Para navegación frecuente, mata la sensación de fluidez.
- Cuando un diseño fijo ya resuelve el problema. Si las pantallas no necesitan adaptarse, GenUI es complejidad sin beneficio. La mayoría de pantallas de la mayoría de apps están bien como están.
- Sin un design system sólido detrás. GenUI amplifica tu catálogo de componentes. Si ese catálogo es inconsistente, el agente generará interfaces inconsistentes más rápido.
La regla que aplicamos: GenUI para lo adaptativo y conversacional; UI fija para lo crítico y frecuente. Casi siempre conviven en la misma app.
Conclusión
La Generative UI con Flutter ha pasado de concepto a stack con estándar abierto en 2026: GenUI SDK, A2UI v0.9 y soporte on-device. Es una de las novedades más relevantes del roadmap de Flutter y abre productos que antes no eran prácticos.
Pero la decisión de diseño sigue siendo humana: saber dónde una interfaz que decide la IA aporta y dónde es un riesgo innecesario. Esa frontera es justo el tipo de criterio que aportamos antes de escribir código, como contamos en product discovery.
Si estás valorando IA generativa en la interfaz de tu app Flutter y quieres un equipo senior in-house que distinga la tendencia del valor real, hablemos en dribba.com.
