Codex baut jetzt interne Websites: Warum KI-Prototypen trotzdem Webdesign brauchen

Interne Tools entstehen in vielen Unternehmen noch immer aus Notlösungen: eine Excel-Liste hier, ein geteiltes Dokument dort, ein Formular ohne klare Zuständigkeit und ein Dashboard, das nur eine Person versteht. Genau an dieser Stelle wird eine neue KI-Entwicklung spannend. OpenAI hat am 2. Juni 2026 ChatGPT Sites beziehungsweise Codex Sites vorgestellt: Codex kann daraus interaktive, gehostete Websites und Webapps erzeugen, die innerhalb eines Workspaces per URL geteilt werden können.

Das klingt nach einem großen Schritt für Teams, die schnell ein internes Dashboard, einen Projekt-Hub, einen Review-Bereich oder ein leichtes Planungstool brauchen. Für österreichische KMU ist aber die wichtigste Erkenntnis nicht: „Jetzt baut KI unsere Websites.“ Die bessere Erkenntnis lautet: Prototypen werden schneller, aber professionelle Webumsetzung wird anspruchsvoller. Denn sobald aus einem Prompt ein internes Tool wird, müssen Zugriff, Daten, Bedienbarkeit, Wartung und Sicherheit stimmen.

Was OpenAI am 2. Juni 2026 angekündigt hat

In den ChatGPT Business Release Notes vom 2. Juni 2026 beschreibt OpenAI ChatGPT Sites als Preview für Business-Workspaces mit Codex-Zugang. Teams können Codex bitten, leichte Full-Stack-Webapps in JavaScript oder TypeScript zu erstellen, zu iterieren und zu deployen. Die Apps erhalten gehostete URLs, können „Sign in with ChatGPT“ nutzen und Daten- sowie Dateispeicher verwenden, während der Zugriff workspace-intern bleibt.

Für Enterprise und Edu nennt OpenAI am selben Tag eine sehr ähnliche Preview. Dort ist ChatGPT Sites standardmäßig ausgeschaltet; Admins und Owner verwalten Aktivierung und Zugriff über Workspace Settings und rollenbasierte Rechte. Für Business-Workspaces ist Sites laut Release Notes standardmäßig aktiviert, kann aber ebenfalls über Permissions & Roles verwaltet werden. Veröffentlichte Sites können durch Admins und Owner deaktiviert werden.

Im offiziellen Codex-Beitrag vom 2. Juni 2026 ordnet OpenAI Sites breiter ein: Codex soll nicht nur Softwareentwicklung unterstützen, sondern auch Analysten, Marketing-, Operations-, Design- und Sales-Teams. Laut OpenAI nutzen inzwischen mehr als 5 Millionen Menschen Codex pro Woche; Nicht-Entwickler machen rund 20 Prozent der Codex-Nutzung aus und wachsen mehr als dreimal so schnell wie Entwickler. Sites sollen dabei Ideen, Analysen und Pläne in Dashboards, Planner, Review-Workspaces, Projektboards, Galerien und leichte Tools verwandeln.

Warum das für KMU relevant ist

Viele KMU haben Prozesse, die für Standardsoftware zu individuell, für ein großes Softwareprojekt aber zu klein wirken. Typische Beispiele sind Angebotsfreigaben, Projektanfragen, Kampagnenplanung, Content-Kalender, Kundenstatus, Eventplanung, Inventarlisten, interne Checklisten oder einfache Auswertungen. Genau solche Zwischenräume landen oft in Tabellen, E-Mails und Chatverläufen.

Codex Sites zeigt, dass diese Zwischenräume künftig schneller zu interaktiven Tools werden können. Ein Team beschreibt das gewünschte interne Tool, Codex erzeugt eine erste Version, speichert Daten, baut Filter, stellt eine URL bereit und kann nach Feedback iterieren. Für kleine Unternehmen ist das attraktiv, weil nicht jedes interne Werkzeug sofort ein monatelanges Projekt sein muss.

Gleichzeitig entsteht ein Risiko: Ein schneller Prototyp fühlt sich oft fertiger an, als er ist. Ein Formular, das Daten speichert, ist noch kein belastbarer Geschäftsprozess. Ein Dashboard mit hübscher Oberfläche ist noch kein geprüftes Reporting. Eine interne Webapp mit Login ist noch keine sauber betriebene Anwendung. Hier liegt der fachliche Bezug zu Webdesign und professioneller Website-Umsetzung: Gute digitale Oberflächen brauchen nicht nur Layout, sondern Informationsarchitektur, Nutzerführung, technische Qualität und klare Verantwortung.

Interne Webapps sind kein Ersatz für Webdesign

Der Begriff Webdesign wird häufig zu eng verstanden. Es geht nicht nur darum, ob eine Seite modern aussieht. Gerade bei internen Tools zählen Struktur, Lesbarkeit, Rollen, Fehlerzustände, Performance, Barrierearmut und Wartbarkeit. Ein Tool, das jeden Tag im Betrieb genutzt wird, muss schneller erfassbar sein als eine Präsentation. Es muss wiederholbare Entscheidungen unterstützen und darf keine falschen Daten suggerieren.

Wenn KI eine interne App erzeugt, ist der erste Entwurf oft nützlich, aber selten ausreichend. Wer darf welche Daten sehen? Welche Felder sind Pflicht? Was passiert bei leeren Zuständen? Wie werden Änderungen nachvollzogen? Welche Daten dürfen exportiert werden? Was passiert, wenn ein Prozess später nicht mehr passt? Diese Fragen gehören nicht in den letzten Feinschliff, sondern in die Konzeption.

Ostheimer kann an dieser Stelle die Lücke zwischen KI-Prototyp und belastbarer Umsetzung schließen. Ein Codex-Sites-Prototyp kann helfen, Anforderungen sichtbar zu machen. Danach braucht es Bewertung: Bleibt das ein internes Hilfstool, wird es in eine bestehende Website integriert, gehört es in WordPress, braucht es eine individuelle Webapp oder sollte ein bestehendes Fachsystem erweitert werden?

Was Codex Sites technisch verändert

Die OpenAI-Entwicklerdokumentation beschreibt Sites als Plugin, mit dem Codex Websites, Webapps und Games erstellen, speichern, deployen und inspizieren kann, ohne dass ein separates Deployment-Workflow eingerichtet werden muss. Wichtig ist dabei: Jede Deployment-URL ist laut Dokumentation eine Produktionsbereitstellung. Wer zuerst prüfen will, soll Codex eine Version speichern lassen, ohne sie direkt zu deployen.

Die Dokumentation unterscheidet außerdem zwischen gespeicherten Versionen und Deployments. Eine Version wird gebaut und als Kandidat gespeichert; ein Deployment veröffentlicht diese Version und liefert eine Produktions-URL. Das klingt technisch, ist aber für KMU sehr praktisch: Es schafft eine Trennung zwischen Entwurf, Prüfung und Freigabe. Genau diese Trennung fehlt bei vielen schnellen KI-Experimenten.

Für Daten nennt OpenAI typische Formen: relationale Speicherung für strukturierte Daten, Objekt-Speicher für Uploads und workspace-authentifizierte Identität für interne Tools. Das ist ein deutlicher Schritt über reine statische Seiten hinaus. Gleichzeitig bedeutet es: Sobald Daten persistent gespeichert werden, muss klar sein, welche Daten dort landen, wie lange sie gebraucht werden und wer darauf zugreift.

Wo die Chancen liegen

Die erste Chance ist Geschwindigkeit in der Klärung. Statt drei Wochen über ein mögliches internes Tool zu sprechen, kann ein Team innerhalb kurzer Zeit eine klickbare Version prüfen. Das verbessert Gespräche, weil echte Nutzer schneller merken, welche Felder fehlen, welche Schritte unklar sind und welche Informationen sie wirklich brauchen.

Die zweite Chance liegt in besseren Übergaben. Viele KMU verlieren Zeit, weil Informationen zwischen Vertrieb, Projektleitung, Marketing und Geschäftsführung in unterschiedlichen Formaten liegen. Ein kleiner Projekt-Hub oder Review-Workspace kann helfen, offene Punkte, Zuständigkeiten, Dateien und Entscheidungen an einem Ort zu bündeln.

Die dritte Chance betrifft Content und Marketing. Ein Launch-Hub, ein Kampagnenboard oder ein Freigabe-Tool kann die Arbeit rund um Content-Marketing und Online-Marketing deutlich strukturieren. Das Tool ersetzt nicht die Strategie, aber es macht Abstimmungen sichtbarer und reduziert Reibung.

Wo die Grenzen liegen

Die Grenze beginnt bei geschäftskritischen Prozessen. Ein KI-generiertes Tool sollte nicht ungeprüft Preise berechnen, rechtlich relevante Freigaben steuern, personenbezogene Daten sammeln oder Kundenkommunikation automatisieren. Für solche Prozesse braucht es fachliche Prüfung, technische Tests, Rollenmodell, Datenschutzbewertung und klare Betriebsverantwortung.

Auch Designqualität ist nicht automatisch gegeben. KI kann ein Interface erzeugen, aber sie kennt nicht immer die Prioritäten des Unternehmens, die Gewohnheiten der Mitarbeiter oder die tatsächlichen Engpässe im Prozess. Ein schönes Dashboard kann in der Praxis scheitern, wenn es die falschen Kennzahlen zeigt oder Nutzer zu viele Klicks brauchen.

Ein weiterer Punkt ist Plattformbindung. Sites können ein guter Preview- und Prototyping-Kanal sein. Ob ein Tool langfristig dort bleiben sollte, hängt aber vom Zweck ab. Für manche internen Anwendungen reicht ein workspace-internes Tool. Andere gehören in ein bestehendes CRM, in ein CMS, in eine WordPress-Struktur oder in eine individuell betriebene Webapp.

Ein pragmatischer Ablauf für KMU

Der sinnvolle Start ist kein großes KI-Webapp-Projekt, sondern ein kleiner Prozess mit klarer Zielgruppe. Zum Beispiel: „Projektanfragen intern sammeln und priorisieren“, „Content-Ideen freigeben“, „Kundenreview vorbereiten“ oder „wöchentliche Kennzahlen kommentieren“. Der Prozess sollte häufig genug vorkommen, damit sich Automatisierung lohnt, aber risikoarm genug sein, um Fehler kontrolliert zu lernen.

Danach werden Anforderungen kurz dokumentiert: Wer nutzt das Tool? Welche Daten werden eingegeben? Welche Daten werden angezeigt? Was muss gespeichert werden? Welche Aktionen dürfen Nutzer auslösen? Wer darf löschen, exportieren oder veröffentlichen? Welche Ansicht braucht die Geschäftsführung, welche das operative Team?

Erst dann lohnt sich der KI-Prototyp. Codex kann eine erste Version bauen, aber diese Version sollte wie ein Entwurf behandelt werden: testen, prüfen, überarbeiten, Zugriff begrenzen und erst danach für mehr Nutzer freigeben. OpenAIs Empfehlung, vor dem Ausweiten des Zugriffs Source-Änderungen, Datenmigrationen, Build-Status, Zielgruppe und Secrets zu prüfen, ist dafür ein guter Mindeststandard.

Was Ostheimer daraus machen kann

Für Ostheimer ist ChatGPT Sites vor allem ein Beschleuniger in der frühen Phase. Ein Prototyp kann helfen, ein internes Werkzeug greifbar zu machen, bevor zu viel Budget in die falsche Richtung fließt. Danach kommt die eigentliche Arbeit: Anforderungen schärfen, Oberfläche vereinfachen, Datenmodell prüfen, Hosting- und Zugriffskonzept klären und entscheiden, ob das Tool als Prototyp genügt oder professionell umgesetzt werden soll.

Bei öffentlichen Seiten bleibt professionelles Webdesign ohnehin zentral. Eine Unternehmenswebsite muss gefunden werden, Vertrauen schaffen, schnell laden, mobil sauber funktionieren und rechtlich sauber sein. Bei internen Tools verschieben sich die Kriterien: weniger Marketing, mehr Wiederholbarkeit, Datenqualität und Prozessklarheit. Beides gehört zusammen, wenn ein KMU digital wachsen will.

Wenn bereits WordPress im Einsatz ist, kann Ostheimer zusätzlich prüfen, ob ein Prozess besser als geschützter Bereich, Formularstrecke, Plugin-Erweiterung oder separate Webapp umgesetzt wird. Der Artikel WordPress wird zum KI-CMS zeigt bereits, wie Agenten Schreibzugriff und CMS-Prozesse verändern. ChatGPT Sites ergänzt diesen Blick um die Frage, wie schnell interne Hilfstools entstehen und wann daraus robuste Webanwendungen werden sollten.

Fazit

ChatGPT Sites macht sichtbar, wohin Webarbeit geht: Ideen werden schneller zu klickbaren, teilbaren Tools. Für KMU ist das wertvoll, weil interne Prozesse oft genau an der Grenze zwischen Tabelle und Software hängen bleiben.

Aber Geschwindigkeit ersetzt keine Verantwortung. Wer KI-Prototypen nutzt, braucht klare Prüfungen: Zielgruppe, Zugriff, Daten, Bedienbarkeit, Qualität und Betrieb. Dann wird Codex Sites nicht zur Abkürzung um Webdesign herum, sondern zu einem besseren Startpunkt für Webdesign, Automatisierung und digitale Prozessarbeit.

Quellen und Veröffentlichungsdaten

• OpenAI Help Center: ChatGPT Business Release Notes, Eintrag vom 2. Juni 2026 zu ChatGPT Sites.
• OpenAI Help Center: ChatGPT Enterprise & Edu Release Notes, Eintrag vom 2. Juni 2026 zu internen Workspace-Apps mit Sites.
• OpenAI: Codex for every role, tool, and workflow, veröffentlicht am 2. Juni 2026.
• OpenAI Developers: Sites – Codex, abgerufen am 9. Juni 2026.