Problema
Pedir a un agente que genere una interfaz completa como código introduce tres riesgos: puede inventar componentes, saltarse permisos y producir una experiencia imposible de mantener. El resultado parece dinámico, pero queda fuera del sistema de diseño y del control del producto.
Imagina un agente de soporte que decide mostrar un reembolso. Si genera HTML libre, puede dibujar un botón convincente aunque el usuario no sea elegible, aunque falte una confirmación o aunque esa acción ni siquiera exista en el backend. El fallo no está en el color del botón. Está en haber confundido representación con autoridad.
Ese es el punto ciego de buena parte de la conversación sobre generative UI: celebrar que la pantalla cambia sin preguntar quién controla el vocabulario con el que cambia.
Tesis
A2UI propone una separación útil: el agente expresa la intención de la interfaz como datos y la aplicación anfitriona decide qué componentes reales puede renderizar. La unidad de gobierno deja de ser la pantalla y pasa a ser el catálogo permitido.
La consecuencia es más profunda de lo que parece. El design system deja de ser una biblioteca visual para diseñadores y se convierte en una política ejecutable para máquinas. Cada componente define no solo cómo se ve una capacidad, sino cuándo puede aparecer, con qué datos y qué efectos puede iniciar.
La idea incómoda: la interfaz generativa no sustituye al design system. Es la prueba definitiva de si ese sistema contiene decisiones o solo estilos.
Framework
Una interfaz generativa operativa necesita cuatro contratos:
- Catálogo: el conjunto de piezas que el host sabe renderizar.
OrderSummaryoRefundProposalson capacidades controladas; undivlibre no lo es. - Propiedades: los datos admitidos, sus tipos y sus estados vacíos, de error y de carga. El schema es parte de la experiencia.
- Acciones: la diferencia entre mostrar una propuesta, solicitar confirmación y ejecutar un efecto real. Renderizar nunca debe conceder autoridad por accidente.
- Versión: el acuerdo entre lo que el agente intenta expresar y lo que la aplicación entiende. Sin negociación, una capacidad nueva puede degradarse en silencio.
Así el agente compone sin adquirir permiso para inventar. El host conserva accesibilidad, telemetría, identidad visual y controles. El modelo decide qué combinación ayuda; el producto decide qué combinaciones son legales.
Un catálogo maduro también incorpora componentes de negativa y escalado: PermissionDenied, NeedsHumanApproval o UnsupportedAction. Si el único vocabulario disponible sirve para avanzar, el agente aprenderá a ocultar la incertidumbre en vez de expresarla.
Señal medible: porcentaje de interfaces generadas solo con componentes aprobados y sin corrección manual de permisos.
Por que importa ahora
Google presentó A2UI como proyecto abierto para interfaces dirigidas por agentes y publicó la versión 0.9 con negociación de versiones y un modelo independiente del framework. La oportunidad no es generar más pantallas: es convertir el design system en una API segura para agentes.
Esto cambia el backlog. Ya no basta con documentar variantes en Figma. Producto e ingeniería deben decidir qué componentes son puramente informativos, cuáles recogen intención y cuáles representan acciones con consecuencias. Accesibilidad y permisos pasan a formar parte del contrato, no de una revisión posterior.
También cambia la métrica. Contar pantallas generadas premia volumen. Medir composiciones válidas, acciones confirmadas y degradaciones recuperables premia calidad del sistema.
Anti-ejemplo
“Que el modelo devuelva HTML y ya lo sanearemos.” El saneado reduce ataques obvios, pero no resuelve coherencia, accesibilidad, permisos ni evolución del sistema.
Tampoco resuelve la promesa al usuario. Un botón puede ser técnicamente seguro y operativamente falso. Si ofrece cancelar un pedido que ya salió del almacén, la interfaz no contiene malware; contiene una mentira de producto.
Protocolo (3 pasos)
- Clasifica componentes. Separa lectura, edición y acciones con efecto real.
- Define contratos. Valida propiedades, estados, accesibilidad y eventos permitidos.
- Versiona el catálogo. Registra qué versión entendió el agente y cuál renderizó el host.
Antes de ampliar el catálogo, prueba tres clases de fallo: dato incompleto, acción no autorizada y componente desconocido. Una interfaz generativa es fiable cuando sabe degradarse con claridad, no cuando siempre consigue dibujar algo.
| Capa | Control | Evidencia |
|---|---|---|
| catálogo | lista permitida | componente registrado |
| acción | permiso por contexto | evento autorizado |
| versión | compatibilidad | negociación registrada |
Relacionado
- Brief In, System Out: por qué la interfaz está dejando de ser el producto
- Figma Design Agent: cuando el canvas se convierte en sistema operativo de producto
Fuentes consultadas
Proximo paso
Elige un flujo de producto y publica para el agente un catálogo mínimo de diez componentes. Si no puedes explicar qué acciones permite cada uno, todavía no tienes interfaz generativa: tienes generación sin gobierno.