OpenAI Intelligent UI vs OpenUI: UI generativa para empresas

OpenAI anunció Intelligent UI para ChatGPT el 7 de octubre de 2026, combinando texto con respuestas interactivas. Su implementación utiliza componentes que se pueden transmitir de forma progresiva y un compilador. Anuncio de lanzamiento de OpenAI

Por su parte, el repositorio de Thesys OpenUI mostraba unas 10.000 estrellas en GitHub cuando se consultó el 8 de octubre. Es una señal de interés entre los desarrolladores. El número de estrellas no permite saber cuántos flujos de negocio funcionan correctamente en producción.

Para un equipo de producto, la pregunta útil es qué ocurre cuando el usuario quiere hacer algo con la respuesta. Un asistente de compras que explica una aprobación resulta útil. Uno que muestra la solicitud correspondiente, permite revisarla y registra la aprobación correcta puede evitar todo un paso de coordinación.

Fuentes revisadas el 8 de octubre de 2026. El flujo y los criterios de evaluación siguientes son una propuesta de ingeniería de Wavect, no un informe sobre una implementación de OpenUI para un cliente ni una prueba de rendimiento medida.

¿Qué diferencia hay entre Intelligent UI y OpenUI?

Intelligent UI es una funcionalidad de ChatGPT; OpenUI es un framework que puedes integrar en una aplicación. La página de ayuda de OpenAI sobre Intelligent UI describe respuestas cuya disposición e interacción se adaptan a la pregunta.

Thesys documenta OpenUI Lang como un lenguaje declarativo para componer los componentes que hayas registrado. Tu aplicación renderiza la descripción del modelo. Aquí, UI generativa significa seleccionar y organizar la interfaz en tiempo de ejecución según la tarea del usuario.

Este modelo de entrega también difiere de pedir a un agente de programación que construya una pantalla para que los desarrolladores la revisen y publiquen. La generación en tiempo de ejecución crea una nueva presentación mientras alguien utiliza el producto. Por eso, la estabilidad de la interacción, la recuperación y las restricciones de los componentes forman parte del diseño del producto.

¿Puedes añadir OpenAI Intelligent UI a tu aplicación mediante una API?

El lanzamiento revisado no anuncia un renderizador de Intelligent UI que puedas integrar en otra aplicación. Describe la experiencia de producto de ChatGPT. La API de un modelo y la interfaz interactiva completa de un producto tienen contratos de integración distintos; no planifiques una implementación a partir de un SDK cuya existencia hayas deducido del anuncio de una funcionalidad.

Para una interfaz controlada por el desarrollador dentro de ChatGPT, OpenAI documenta por separado un servidor MCP con una interfaz opcional en un iframe, mediante el estándar MCP Apps. Consulta su guía de inicio de servidor MCP e interfaz en la documentación de Plugins.

Empieza por decidir dónde accederán los usuarios. Si ya trabajan en tu portal de clientes, crea allí el prototipo de la interacción. Si el punto de entrada previsto es ChatGPT, evalúa la vía de integración de ese entorno. Una empresa puede acabar ofreciendo ambas opciones, pero el primer experimento útil solo necesita una.

¿Qué proyecto OpenUI deberían evaluar los desarrolladores?

Esta guía trata de thesysdev/openui, mantenido por Thesys. El repositorio enumera entornos de ejecución para React, Vue, Svelte y Angular, además de componentes de interfaz ya preparados para React. Su licencia MIT cubre el proyecto de código abierto. Los cargos de servicios gestionados y la inferencia del modelo siguen siendo aspectos independientes.

Otros proyectos con nombres parecidos son OpenUI de Weights & Biases, para generar y previsualizar código de interfaces, y Open WebUI, una interfaz de IA autoalojada. Identifica al propietario del repositorio al comparar paquetes, ejemplos o instrucciones de despliegue.

En una aplicación existente, empieza con un catálogo de componentes deliberadamente pequeño. Registra los resúmenes, tablas, filtros y vistas de confirmación que el flujo realmente necesite. La documentación de componentes de OpenUI los define mediante esquemas y renderizadores.

Recomendamos que los componentes asociados a acciones con consecuencias expresen claramente su función. Un PurchaseApproval propio de la aplicación puede mostrar de forma coherente la solicitud, el importe, la moneda y lo que significa aprobar. Un botón genérico con texto generado por el modelo ofrece menos posibilidades de garantizar esa coherencia. La validación de los componentes sigue necesitando una validación de negocio independiente.

¿OpenUI necesita una llamada a un LLM por cada clic?

No. OpenUI puede generar la interfaz una vez y ejecutar las interacciones compatibles mediante su entorno de ejecución. Su documentación de arquitectura separa la generación de la ejecución y conecta herramientas mediante toolProvider.

Por ejemplo, cambiar un filtro de fechas puede actualizar la vista existente y recuperar datos nuevos. Una petición de rediseñar esa vista puede volver al modelo. Estas operaciones merecen rutas distintas porque una es una interacción conocida y la otra requiere una nueva composición.

La documentación de consultas y mutaciones distingue las lecturas con Query de las escrituras con Mutation. Una mutación se ejecuta cuando se activa mediante @Run. Esto facilita la conexión de las operaciones; el servidor debe seguir decidiendo si una operación concreta está permitida.

Limita las herramientas disponibles. Expón una operación específica, como aprobar una solicitud de compra existente, con argumentos validados. Evita dar a las interfaces generadas un endpoint genérico que pueda ejecutar SQL, URL o comandos arbitrarios. Una ruta de lectura también necesita controles de acceso: una tabla aparentemente inocua puede contener registros de otro cliente.

Separa la generación de la disposición visual de la recuperación de datos siempre que sea posible. Deja que una herramienta autorizada devuelva cifras actuales y calcula los totales con código convencional. Esto puede reducir la cantidad de datos de negocio que pasan por un modelo y evitar que un texto generado y obsoleto parezca la fuente de verdad. Que reduzca los costes depende de la carga real de solicitudes, herramientas y regeneraciones.

Ejemplo de UI generativa: aprobaciones de compra con un límite estable para ejecutar acciones

Considera esta petición interna hipotética: «Muestra las compras pendientes de mi aprobación, compara las fechas de entrega y déjame revisar una». El usuario debería poder explorar la lista libremente. Aprobar una compra concreta debe seguir siendo una operación explícita y verificable.

1. Carga la vista permitida para el usuario. El backend obtiene la identidad y la organización de la sesión autenticada. Devuelve los registros autorizados con sus versiones actuales y las acciones permitidas.
2. Genera una presentación útil. El modelo compone los componentes registrados de tabla, comparación y explicación. Los detalles relevantes para aprobar proceden del registro revisado de la aplicación, incluidos el proveedor, el importe y la moneda.
3. Mantén la confirmación bajo el control de la aplicación. El componente de confirmación muestra exactamente qué cambiará. Solo se puede utilizar cuando los datos y las validaciones requeridos estén completos, y conserva lo introducido por el usuario mientras llega el resto del contenido.
4. Vuelve a comprobar al ejecutar. El backend verifica los permisos actuales, la versión del registro y la transición de estado permitida. Registra la acción con protección contra duplicados.
5. Muestra el resultado registrado. La interfaz muestra el justificante del backend o el estado actual. Un timeout deja un resultado incierto que hay que conciliar; no justifica inventar un éxito ni enviar otra aprobación a ciegas.

Una propuesta de solicitud a la aplicación podría contener los siguientes campos. Es un contrato ilustrativo para tu propio endpoint, no sintaxis del SDK de OpenUI:

{
  "request_id": "PR-2048",
  "expected_version": 7,
  "operation_id": "8b47e18a-2986-4eb4-94a4-c6466bc12476"
}

El servidor obtiene de la sesión al usuario que realiza la acción. Vincula el identificador de operación a ese usuario, su organización y los datos de la acción, rechaza reutilizaciones incompatibles y comprueba la versión del registro de forma atómica al escribir. Si cambian los detalles de la aprobación, el usuario revisa la solicitud actualizada antes de volver a confirmar.

Este diseño sigue el principio de comprobar la autorización inmediatamente antes de ejecutar, descrito en la guía de OWASP sobre autorización de transacciones. Los campos concretos de la solicitud y el flujo anterior son decisiones de implementación que proponemos.

La consecuencia para el diseño es que todas las vías de acceso a una operación de negocio comparten las mismas comprobaciones. Un control generado, una pantalla convencional y una herramienta de agente no deben convertirse en tres sistemas de permisos distintos. Nuestra guía de patrones de diseño de agentes de IA explica las decisiones de ejecución que rodean este flujo.

¿Dónde guardar el estado de OpenUI y los registros de negocio?

Guarda el estado de interacción y el de negocio de forma explícita, con responsables distintos. La guía de interactividad de OpenUI documenta puntos de integración para la persistencia mediante onStateUpdate e initialState. La aplicación proporciona el almacenamiento y el comportamiento al volver a cargar.

Limita las interfaces guardadas al usuario y la organización correspondientes. Al volver a abrir un panel, deben recuperarse datos actuales y autorizados. Trata una etiqueta «aprobado» guardada como una presentación, nunca como prueba de que la aprobación existe en el sistema de registro.

También conviene comprobar un detalle de integración: onAction gestiona las acciones de conversación y URL, mientras que las operaciones del entorno de ejecución, como @Run, se gestionan internamente. Aplica los permisos de negocio en la ruta de herramienta o backend que realmente ejecuta, en lugar de asumir que un único callback de la interfaz intercepta todas las operaciones.

OpenUI vs A2UI, AG-UI y MCP Apps: ¿qué capa necesitas?

Estos nombres describen límites distintos. Compara la responsabilidad que necesitas cubrir antes de seleccionar dependencias.

Una primera funcionalidad puede utilizar el backend existente y una integración pequeña del renderizador. Añade otro protocolo cuando resuelva una necesidad real de conexión. Adoptarlos todos no es un requisito para descubrir si una vista generada ayuda a tus usuarios.

¿Qué debe comprobar una prueba de UI generativa para producción?

La propia guía de fiabilidad de OpenUI reconoce componentes desconocidos, valores no admitidos, referencias sin resolver y generaciones incompletas. Una pantalla que aparece correctamente puede seguir omitiendo el control o la información necesarios para completar la tarea.

Utiliza estos escenarios de aceptación propuestos para el flujo de compras. Pruébalos con la biblioteca de componentes, la configuración del modelo y el backend reales de la aplicación.

Incluye comprobaciones con teclado y lectores de pantalla. W3C explica por qué el orden del foco debe conservar una interacción con sentido y por qué los mensajes de estado deben estar disponibles para las tecnologías de asistencia. La transmisión progresiva hace especialmente útiles estos casos de prueba: un componente nuevo no debería desplazar al usuario de donde estaba, y un fallo de escritura debería anunciarse claramente.

¿Cuándo compensa el coste de una UI generativa?

Empieza donde cambiar la presentación evite interpretaciones o navegación repetitivas. Explorar un conjunto de datos desconocido, comparar varios proveedores o investigar excepciones entre registros son buenos candidatos para un piloto. Un formulario fijo sigue siendo una buena referencia para una tarea frecuente y estable que los usuarios experimentados ya completan con rapidez.

Compara tres versiones de una tarea: la pantalla actual, un asistente con un componente de respuesta fijo y una interfaz generada con restricciones. La versión generada merece adoptarse si mejora lo suficiente el trabajo completado para justificar sus costes adicionales de implementación y operación.

Proponemos medir el tiempo hasta el primer control utilizable: el tiempo transcurrido desde la solicitud hasta que el primer control pertinente para la tarea dispone de los datos requeridos, supera la validación y se puede utilizar. Comunica la mediana y el p95. No cuentan un marcador de posición, un título ni un botón sin terminar. Es una métrica de producto propuesta, no una referencia del sector.

Combínala con la tasa de finalización correcta, las correcciones del usuario, las pantallas incompletas, los reintentos y el coste total por flujo completado. OpenUI publica sus propias pruebas comparativas de UI generativa, pero una comparación de tokens entre formatos no permite determinar la economía de toda tu aplicación.

Coste por flujo completado = coste total de modelos, reparaciones, herramientas y alojamiento / flujos completados correctamente

Mide el tiempo de revisión humana junto con esa cifra. Cuenta las llamadas utilizadas para crear y regenerar la interfaz, aunque los clics posteriores se ejecuten sin inferencia. Para el método de cálculo más amplio, consulta nuestra guía de coste por acción de agentes de IA.

Nuestra valoración es que la UI generativa se está convirtiendo en una opción práctica dentro de la arquitectura de agentes. El lanzamiento y el interés de los desarrolladores no demuestran que todas las aplicaciones empresariales deban generar todas sus pantallas. La mejor implementación puede ser un producto estable con unas pocas vistas adaptables, justo donde benefician a los usuarios.

Para definir un piloto, trae un flujo de trabajo, una grabación de cómo lo completan las personas hoy y registros representativos. El servicio de desarrollo de IA de Wavect puede ayudarte a definir el catálogo de componentes, la integración y los criterios de aceptación. Nuestro caso de desarrollo de TwinSoft AI ilustra otro proyecto de producto; no es una implementación de referencia de OpenUI.

Utiliza la guía para elegir el stack tecnológico de un MVP para la decisión más amplia sobre responsabilidades, o comenta con Wavect un flujo de UI generativa.