OpenAI Intelligent UI vs. OpenUI: Generative UI für Business-Apps

OpenAI kündigte Intelligent UI für ChatGPT am 7. Oktober 2026 an. Die Funktion verbindet Text mit interaktiven Antworten. Ihre Umsetzung nutzt streambare Komponenten und einen Compiler. OpenAIs Produktankündigung

Das OpenUI-Repository von Thesys zeigte bei der Prüfung am 8. Oktober rund 10.000 GitHub-Sterne. Das belegt Interesse unter Entwicklern. Die Zahl sagt allerdings nicht aus, wie viele Geschäftsprozesse damit erfolgreich im Produktivbetrieb laufen.

Für ein Produktteam ist entscheidend, was passiert, wenn Nutzer mit einer Antwort etwas erledigen möchten. Ein Beschaffungsassistent, der eine Freigabe erklärt, ist hilfreich. Zeigt er den passenden Antrag, ermöglicht dessen Prüfung und erfasst die richtige Freigabe, kann er einen ganzen Übergabeschritt einsparen.

Quellen geprüft am 8. Oktober 2026. Der folgende Workflow und seine Bewertungskriterien sind ein Umsetzungsvorschlag von Wavect. Sie beschreiben weder eine OpenUI-Kundenimplementierung noch Ergebnisse eines praktischen Leistungstests.

Was unterscheidet Intelligent UI von OpenUI?

Intelligent UI ist eine ChatGPT-Funktion. OpenUI ist ein Framework, das du in eine eigene Anwendung integrieren kannst. OpenAIs Hilfeseite zu Intelligent UI beschreibt Antworten, deren Aufbau und Interaktion sich an die jeweilige Frage anpassen.

Thesys dokumentiert OpenUI Lang als deklarative Sprache zur Zusammenstellung registrierter Komponenten. Deine Anwendung rendert die vom Modell erzeugte Beschreibung. Generative UI bedeutet hier, die Oberfläche zur Laufzeit passend zur Aufgabe des Nutzers auszuwählen und anzuordnen.

Das unterscheidet sich auch davon, einen Coding-Agenten einen Bildschirm entwickeln zu lassen, den Entwickler anschließend prüfen und ausliefern. Generierung zur Laufzeit erzeugt eine neue Darstellung, während jemand das Produkt verwendet. Verlässliche Bedienung, Wiederherstellung und Grenzen der Komponenten gehören damit zum Produktdesign.

Kannst du OpenAI Intelligent UI per API in deine eigene App integrieren?

Die geprüfte Ankündigung stellt keinen einbettbaren Intelligent-UI-Renderer vor. Sie beschreibt das Produkterlebnis in ChatGPT. Eine Modell-API und eine vollständige interaktive Produktoberfläche haben unterschiedliche Integrationsschnittstellen. Plane eine Umsetzung daher nicht mit einem SDK, dessen Existenz du lediglich aus einer Funktionsankündigung ableitest.

Für eine von Entwicklern gestaltete Oberfläche innerhalb von ChatGPT dokumentiert OpenAI separat einen MCP-Server mit optionaler iframe-UI auf Basis des MCP-Apps-Standards. Siehe dazu den aktuellen Schnellstart für MCP-Server und UI in der Plugins-Dokumentation.

Entscheide zuerst, wo Nutzer einsteigen sollen. Arbeiten sie bereits in deinem Kundenportal, prototypisiere die Interaktion dort. Soll ChatGPT der Einstieg sein, prüfe den Integrationsweg dieses Hosts. Ein Unternehmen kann später beide Wege unterstützen. Für das erste aussagekräftige Experiment genügt einer.

Welches OpenUI-Projekt sollten Entwickler prüfen?

Dieser Leitfaden behandelt thesysdev/openui, gepflegt von Thesys. Das Repository nennt Laufzeitumgebungen für React, Vue, Svelte und Angular sowie zusätzliche fertige React-Oberflächenkomponenten. Die MIT-Lizenz gilt für das Open-Source-Projekt. Kosten für verwaltete Dienste und Modellinferenz musst du gesondert berücksichtigen.

Ähnlich benannte Projekte sind OpenUI von Weights & Biases zur Generierung und Vorschau von UI-Code sowie Open WebUI, eine selbst gehostete KI-Oberfläche. Achte beim Vergleich von Paketen, Beispielen und Deployment-Anleitungen auf den jeweiligen Repository-Inhaber.

Beginne bei einer bestehenden Anwendung mit einem bewusst kleinen Komponentenkatalog. Registriere die Zusammenfassungen, Tabellen, Filter und Bestätigungsansichten, die der Workflow tatsächlich benötigt. OpenUIs Komponentendokumentation definiert Komponenten über Schemas und Renderer.

Wir empfehlen, Komponenten für folgenreiche Aktionen fachlich eindeutig zu gestalten. Eine von der Anwendung kontrollierte PurchaseApproval-Komponente kann Antrag, Betrag, Währung und Bedeutung der Freigabe konsistent anzeigen. Eine generische Schaltfläche mit modellgeneriertem Text bietet dem Produkt weniger Möglichkeiten, diese Konsistenz durchzusetzen. Die Validierung der Komponente braucht dennoch eine gesonderte Prüfung der Geschäftsregeln.

Braucht OpenUI für jeden Klick einen LLM-Aufruf?

Nein. OpenUI kann die Oberfläche einmal erzeugen und unterstützte Interaktionen anschließend über seine Laufzeitumgebung ausführen. Die Architekturdokumentation trennt Generierung und Ausführung und bindet Tools über toolProvider an.

Ein geänderter Datumsfilter kann beispielsweise die bestehende Ansicht aktualisieren und neue Daten abrufen. Der Auftrag, diese Ansicht neu zu gestalten, kann zurück an das Modell gehen. Diese Vorgänge brauchen unterschiedliche Pfade: Der eine ist eine bekannte Interaktion, der andere erfordert eine neue Zusammenstellung der Oberfläche.

Die Dokumentation zu Queries und Mutations unterscheidet Lesezugriffe mit Query von Schreibzugriffen mit Mutation. Eine Mutation wird ausgeführt, wenn sie über @Run ausgelöst wird. Das liefert die technische Anbindung für die Ausführung. Ob eine konkrete Aktion erlaubt ist, muss weiterhin der Server entscheiden.

Begrenze die verfügbaren Tools. Stelle eine benannte Operation mit validierten Argumenten bereit, etwa die Freigabe eines bestehenden Beschaffungsantrags. Gib generierten Oberflächen keinen allgemeinen Endpunkt, der beliebige SQL-Anweisungen, URLs oder Befehle ausführen kann. Auch Lesezugriffe brauchen Zugriffskontrollen: Eine harmlos wirkende Tabelle kann Datensätze eines anderen Kunden enthalten.

Trenne die Generierung des Layouts möglichst vom Datenabruf. Lass ein freigegebenes Tool aktuelle Zahlen liefern und berechne Summen in gewöhnlichem Anwendungscode. So können weniger Geschäftsdaten durch ein Modell fließen. Außerdem wird veralteter generierter Text nicht zur scheinbar maßgeblichen Datenquelle. Ob das Kosten senkt, hängt vom tatsächlichen Aufwand für Anfragen, Tools und erneute Generierungen ab.

Generative UI am Beispiel: Beschaffungsfreigaben mit klarer Ausführungskontrolle

Betrachte eine hypothetische interne Anfrage: „Zeige mir die Beschaffungsanträge, die auf meine Freigabe warten, vergleiche Liefertermine und lass mich einen prüfen.“ Nutzer sollten die Liste frei untersuchen können. Die Freigabe eines konkreten Antrags muss eine ausdrückliche, überprüfbare Aktion bleiben.

1. Lade die für den Nutzer erlaubte Ansicht. Das Backend ermittelt Identität und Organisation aus der authentifizierten Sitzung. Es liefert die zugänglichen Datensätze mit ihren aktuellen Versionen und erlaubten Aktionen.
2. Erzeuge eine hilfreiche Darstellung. Das Modell kombiniert die registrierten Komponenten für Tabellen, Vergleiche und Erläuterungen. Wesentliche Freigabedetails stammen aus dem geprüften Datensatz der Anwendung, einschließlich Lieferant, Betrag und Währung.
3. Behalte die Bestätigung unter Kontrolle der Anwendung. Die Bestätigungskomponente zeigt genau, was sich ändern wird. Sie wird erst bedienbar, wenn erforderliche Daten und Prüfungen vollständig vorliegen, und erhält Nutzereingaben, während weitere Inhalte eintreffen.
4. Prüfe unmittelbar vor der Ausführung erneut. Das Backend kontrolliert aktuelle Berechtigungen, Datensatzversion und erlaubten Zustandsübergang. Es speichert die Aktion mit Schutz vor doppelter Ausführung.
5. Zeige das erfasste Ergebnis. Die Oberfläche zeigt die Bestätigung oder den aktuellen Status des Backends. Bei einem Timeout bleibt das Ergebnis bis zum Abgleich unklar. Das rechtfertigt weder eine erfundene Erfolgsmeldung noch das blinde erneute Absenden einer Freigabe.

Eine Anfrage an deine Anwendung könnte beispielsweise die folgenden Felder enthalten. Das ist ein Schnittstellenbeispiel für deinen eigenen Endpunkt, keine OpenUI-SDK-Syntax:

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

Der Server ermittelt den handelnden Nutzer aus der Sitzung. Er bindet die Vorgangskennung an diesen Nutzer, die Organisation und die Aktionsdaten, weist widersprüchliche Wiederverwendung zurück und prüft die Datensatzversion atomar beim Schreiben. Ändern sich Freigabedetails, prüft der Nutzer den aktualisierten Antrag vor einer erneuten Bestätigung.

Dieses Design folgt dem Prinzip, die Autorisierung unmittelbar vor der Ausführung zu prüfen, wie es OWASPs Leitfaden zur Transaktionsautorisierung beschreibt. Die konkreten Anfragefelder und der obige Workflow sind unsere Umsetzungsvorschläge.

Daraus folgt eine zentrale Architekturentscheidung: Jeder Zugang zu einer Geschäftsoperation muss dieselben Kontrollen durchlaufen. Ein generiertes Bedienelement, eine gewöhnliche Bildschirmansicht und ein Agenten-Tool dürfen nicht zu drei unterschiedlichen Berechtigungssystemen werden. Unser Leitfaden zu KI-Agenten-Designmustern behandelt die umgebende Ablaufsteuerung.

Wo sollten OpenUI-Zustand und Geschäftsdaten gespeichert werden?

Lege für Interaktionszustand und Geschäftszustand bewusst unterschiedliche Verantwortlichkeiten fest. OpenUIs Interaktivitätsleitfaden dokumentiert Hooks zur Zustandsspeicherung über onStateUpdate und initialState. Speicherung und Wiederherstellung stellt die Anwendung bereit.

Ordne gespeicherte Oberflächen ihrem Nutzer und ihrer Organisation zu. Beim Wiederöffnen eines Dashboards sollten aktuelle Daten innerhalb der geltenden Zugriffsrechte abgerufen werden. Eine gespeicherte Beschriftung „freigegeben“ ist eine Darstellung. Sie beweist nicht, dass im führenden System eine Freigabe existiert.

Prüfe außerdem ein Integrationsdetail: onAction behandelt Gesprächs- und URL-Aktionen, während Laufzeitoperationen wie @Run intern verarbeitet werden. Erzwinge fachliche Berechtigungen im tatsächlich ausführenden Tool- beziehungsweise Backend-Pfad. Gehe nicht davon aus, dass ein einzelner UI-Callback jede Operation abfängt.

OpenUI vs. A2UI, AG-UI und MCP Apps: Welche Ebene brauchst du?

Diese Namen beschreiben unterschiedliche Schnittstellen. Vergleiche zuerst die benötigte Verantwortung, bevor du Abhängigkeiten auswählst.

Eine erste Funktion kann ein bestehendes Backend und eine kleine Renderer-Integration nutzen. Ergänze ein weiteres Protokoll, wenn es einen tatsächlichen Verbindungsbedarf löst. Du musst nicht alle einsetzen, um herauszufinden, ob eine generierte Ansicht deinen Nutzern hilft.

Was muss ein Test für produktive Generative UI tatsächlich prüfen?

OpenUIs eigener Leitfaden zur Zuverlässigkeit behandelt unbekannte Komponenten, nicht unterstützte Werte, unaufgelöste Referenzen und unvollständige Generierungen. Selbst eine erfolgreich dargestellte Oberfläche kann ein Bedienelement oder eine Information auslassen, die zum Erledigen der Aufgabe nötig ist.

Nutze die folgenden vorgeschlagenen Abnahmeszenarien für den Beschaffungsworkflow. Prüfe sie mit der tatsächlichen Komponentenbibliothek, Modellkonfiguration und dem Anwendungsbackend.

Beziehe Tastatur- und Screenreader-Prüfungen ein. Das W3C erklärt, warum die Fokusreihenfolge eine sinnvolle Bedienung erhalten muss und Statusmeldungen für assistive Technologien zugänglich sein müssen. Durch Streaming werden diese Fälle besonders relevant: Eine neue Komponente sollte den Nutzer nicht aus seiner aktuellen Position reißen. Ein fehlgeschlagener Schreibvorgang muss klar angekündigt werden.

Wann lohnt sich Generative UI?

Beginne dort, wo eine angepasste Darstellung wiederholtes Interpretieren oder Navigieren erspart. Geeignete Pilotaufgaben sind die Untersuchung eines unbekannten Datensatzes, der Vergleich mehrerer Lieferantenoptionen oder die Analyse von Ausnahmefällen über mehrere Datensätze hinweg. Für eine häufige, gleichbleibende Aufgabe, die geübte Nutzer bereits schnell erledigen, bleibt ein festes Formular ein starker Vergleichsmaßstab.

Vergleiche drei Varianten derselben Aufgabe: die aktuelle Oberfläche, einen Assistenten mit einer festen Antwortkomponente und eine begrenzt generierte Oberfläche. Die generierte Variante rechtfertigt ihre Einführung, wenn sie die erledigte Arbeit ausreichend verbessert, um zusätzliche Implementierungs- und Betriebskosten zu tragen.

Wir schlagen vor, die Zeit bis zum ersten nutzbaren Bedienelement zu messen: die Zeitspanne von der Anfrage bis zu dem Moment, in dem das erste aufgabenrelevante Bedienelement alle erforderlichen Daten besitzt, die Validierung besteht und bedient werden kann. Erfasse Median und p95. Ein Platzhalter, eine Überschrift oder eine unfertige Schaltfläche zählt nicht. Das ist eine vorgeschlagene Produktkennzahl, kein Branchenbenchmark.

Ergänze die Quote korrekt abgeschlossener Aufgaben, Nutzerkorrekturen, unvollständige Oberflächen, Wiederholungsversuche und Gesamtkosten pro abgeschlossenem Workflow. OpenUI veröffentlicht eigene Benchmarks für Generative UI. Ein Tokenvergleich auf Formatebene kann die Wirtschaftlichkeit deiner gesamten Anwendung jedoch nicht bestimmen.

Kosten pro abgeschlossenem Workflow = gesamte Modell-, Korrektur-, Tool- und Hostingkosten / korrekt abgeschlossene Workflows

Erfasse zusätzlich die menschliche Prüfzeit. Zähle die Aufrufe zur Erzeugung und erneuten Generierung der UI mit, auch wenn spätere Klicks ohne Modellinferenz ablaufen. Die umfassendere Berechnung erläutert unser Leitfaden zu KI-Agentenkosten pro Aktion.

Unsere Einschätzung: Generative UI entwickelt sich zu einer praktischen Option im Agenten-Stack. Produktankündigung und Entwicklerinteresse beweisen nicht, dass jede Business-App jeden Bildschirm generieren sollte. Die überzeugendste Umsetzung kann ein stabiles Produkt mit wenigen anpassbaren Ansichten sein, genau dort, wo Nutzer davon profitieren.

Bringe zur Planung eines Piloten einen Workflow, eine Aufzeichnung seiner heutigen Nutzung und repräsentative Datensätze mit. Wavects KI-Entwicklung kann helfen, Komponentenkatalog, Integration und Abnahmekriterien zu definieren. Unsere Fallstudie zur Umsetzung von TwinSoft AI zeigt ein eigenständiges Produktprojekt. Sie ist keine OpenUI-Referenzimplementierung.

Nutze den Leitfaden zur Wahl des MVP-Technologie-Stacks für die übergreifende Verantwortungsentscheidung oder besprich einen Generative-UI-Workflow mit Wavect.