Interfaz generativa: cómo evaluar UI creada por IA

Una interfaz generativa es una experiencia donde el modelo decide qué combinación de texto, visuales y controles ayuda mejor a resolver una intención. No debería significar que el modelo escribe y ejecuta frontend arbitrario. El 7 de octubre de 2026, OpenAI presentó Intelligent UI en ChatGPT: GPT-6 puede componer respuestas con gráficos, botones, formularios y experiencias interactivas, usando una biblioteca de componentes nativos y un compilador que procesa la interfaz mientras el modelo la genera. Para un equipo de producto, la decisión correcta no es copiar la demostración, sino definir seis límites verificables: cuándo conviene generar UI, qué componentes están permitidos, qué estado es autoritativo, qué acciones requieren confirmación, qué condiciones de accesibilidad deben sostenerse y qué resultado demuestra utilidad. Sin esos gates, una interfaz visualmente convincente puede ocultar datos incompletos, perder estado, disparar un efecto no deseado o degradar móvil y lectores de pantalla. Con ellos, la generación queda contenida dentro de un sistema de diseño, permisos y pruebas observables.

La novedad central tiene un día de antigüedad al publicar este artículo. OpenAI también advierte que todavía debe mejorar el criterio de diseño del modelo. Sus cifras de velocidad y calidad son evaluaciones internas del proveedor; no son benchmarks reproducidos por Wasyra ni evidencia de que una interfaz generada funcione mejor para cada producto.

El mecanismo útil separa tres decisiones. Primero, el modelo interpreta la tarea y selecciona una representación: texto para una respuesta directa, tabla para comparar, gráfico para detectar un patrón o controles para explorar alternativas. Segundo, produce una especificación estructurada dentro de un vocabulario cerrado de componentes. Tercero, un runtime valida esa especificación, resuelve datos y estado, y renderiza elementos conocidos. El modelo organiza; el host conserva la autoridad sobre código, capacidades y efectos.

OpenAI describe para Intelligent UI una biblioteca de componentes nativos transmitibles y un compilador que muestra la interfaz progresivamente. Esa arquitectura evita esperar a una respuesta completa, pero crea estados intermedios: componente aún sin datos, bloque que cambia de orden, acción todavía no habilitada o respuesta que continúa pensando. Cada estado debe tener semántica explícita. Un placeholder no puede parecer un total confirmado, y un control no debería activarse antes de que sus argumentos y permisos sean válidos.

Las superficies para desarrolladores de OpenAI ofrecen una referencia relacionada, no una descripción exacta del producto anunciado. Su Apps SDK separa contratos de herramientas, contenido estructurado, recursos de UI y estado del widget; su biblioteca UI aporta tokens y componentes accesibles. Esa separación es transferible: datos verificables en un canal, presentación en otro y side effects detrás de herramientas con contratos estrechos.

El contrato debe evaluarse antes del render y nuevamente antes de cualquier efecto. Los seis gates siguientes cubren la frontera mínima entre una respuesta flexible y una aplicación controlada. No todos exigen aprobación humana, pero ninguno debería depender únicamente de que el modelo recuerde una instrucción del prompt.

Imagine un líder de producto que carga tres propuestas de proveedores y pregunta cuál reduce mejor el riesgo de entrega. El modelo podría responder con una matriz editable: alcance, dependencias, supuestos, hitos y cláusulas sin evidencia. Al cambiar la prioridad de velocidad a continuidad operativa, la matriz reordena criterios y explica por qué. Esa interacción aporta más que un bloque de texto porque permite explorar una decisión multicriterio sin perder la trazabilidad de cada afirmación.

El ejemplo es hipotético. Su implementación segura mantendría los documentos originales como evidencia inmutable, cada celda derivada enlazada a una página o fragmento, y los pesos como estado visible del usuario. El modelo podría proponer una ponderación, pero no esconderla. Si falta un dato, la UI mostraría desconocido y permitiría solicitar aclaración; no convertiría la ausencia en cero. Exportar el análisis sería una acción de lectura. Enviar una recomendación al comité sería una acción separada, con destinatarios, preview y confirmación.

El test principal no preguntaría si la matriz se ve moderna. Mediría si el decisor detecta contradicciones reales, identifica incertidumbre, corrige un peso y recupera el estado después de salir y volver. Una UI generada falla aunque sea atractiva si acelera una conclusión equivocada.

En una conversación, hay al menos cuatro estados posibles: datos de la herramienta, estado del componente, memoria de la sesión y resumen que el modelo cree vigente. Si cualquiera puede sobrescribir a los demás sin versión o regla de merge, aparecen carritos que regresan a una cantidad anterior, filtros que el modelo ignora o confirmaciones que muestran valores distintos de los enviados. Defina una fuente autoritativa por campo, incluya versión en cada mutación y haga que un conflicto sea visible en lugar de resolverlo en silencio.

Las acciones necesitan una frontera aún más estricta. El componente puede emitir intención, pero el servidor debe volver a validar identidad, permiso, argumentos, estado actual y límite de impacto. Una compra, borrado, publicación o mensaje externo requiere un resumen estable de lo que ocurrirá y una confirmación cercana al efecto. La idempotencia evita duplicados si la interfaz reintenta por red. Un recibo con identificador permite distinguir éxito, pendiente y resultado incierto.

Pruebe además la reanudación. Cierre la vista durante el streaming, vuelva desde el historial, repita una herramienta después de un timeout y cambie de dispositivo. La recuperación correcta no consiste en dibujar la misma tarjeta: consiste en reconstruir la verdad del workflow sin repetir el efecto.

Construya el set de evaluación desde tareas reales y estados difíciles, no desde prompts bonitos. Incluya una respuesta donde texto es suficiente, otra que necesita comparación, datos parciales, una herramienta lenta, una acción irreversible, una sesión reabierta y contenido largo en ambos idiomas. Para cada caso, defina la modalidad esperada, componentes permitidos, datos obligatorios, acciones prohibidas y criterio de éxito. Así puede detectar tanto sobre-generación como omisión de una interacción útil.

Mida por capas. En estructura: validez de esquema, componentes desconocidos y estabilidad del árbol durante streaming. En contenido: fidelidad a fuentes, tratamiento de faltantes y correspondencia entre datos y visual. En interacción: finalización correcta, errores de entrada, foco y recuperación. En efectos: autorizaciones, confirmaciones, idempotencia y auditoría. En experiencia: tiempo hasta contenido útil, cambios acumulativos de layout, reflow a 200% y navegación completa con teclado y lector de pantalla.

Compare contra una base fija: texto estructurado o una UI diseñada manualmente. El experimento debe usar la misma tarea y los mismos datos. Una tasa de clics mayor no basta si aumentan errores o acciones revertidas. Promueva la interfaz generativa solo cuando mejore el resultado objetivo dentro del presupuesto de latencia, accesibilidad y riesgo, y conserve una ruta de fallback para especificaciones inválidas o capacidades no disponibles.

No toda respuesta debe convertirse en una miniaplicación. La UI generada añade tokens o cómputo de planificación, validación, estados de streaming, pruebas combinatorias y mantenimiento de componentes. También puede producir choice overload, variaciones difíciles de documentar y superficies que usuarios no reconocen entre sesiones. Para flujos regulados o de alta frecuencia, una interfaz fija suele conservar mejor aprendizaje muscular, auditoría y soporte. Reserve generación para tareas variables donde la composición realmente cambia con el contexto.

Empiece con componentes solo de lectura y un dominio estrecho. Registre la intención detectada, especificación generada, versión de biblioteca, fallbacks y resultado de tarea sin guardar más datos personales de los necesarios. Después habilite edición reversible. Las acciones externas llegan al final, una por una, con permisos y recibos propios. Un kill switch debe poder desactivar una plantilla, componente o acción sin retirar toda la experiencia.

La decisión ejecutiva es sencilla: adopte interfaz generativa cuando la variabilidad de la tarea justifique composición dinámica y cuando pueda demostrar los seis gates. Si el equipo todavía no puede versionar estado, contener efectos o probar accesibilidad, el siguiente paso no es generar más UI; es fortalecer el runtime. Wasyra puede ayudar a convertir un caso concreto en un slice medible, con contrato de componentes, evaluación y rollout reversible, sin confundir una demo visual con un sistema listo para operar.