RingCentral setzt ChatGPT Work und Codex ein, um KI-Produkte schneller zu entwickeln und operatives Wissen über Engineering und Operations hinweg zu bündeln. Für Unternehmen ist daran weniger die einzelne Software interessant als das Organisationsmuster: Codearbeit und betriebliche Koordination werden nicht als getrennte KI-Projekte behandelt. Beide greifen auf gemeinsamen Kontext zurück, bleiben aber unterschiedlich kontrolliert. Genau daraus lässt sich ein belastbarer Einführungsansatz ableiten.
Was im RingCentral-Fall bestätigt ist
Die am 12. August 2026 veröffentlichte OpenAI-Fallstudie bestätigt drei Kernaussagen: RingCentral nutzt ChatGPT Work und Codex, will damit die Entwicklung eigener KI-Produkte beschleunigen und zentralisiert operatives Wissen über Engineering und Operations hinweg. Beschrieben wird außerdem eine intern geförderte AI-Native Challenge. Teilnehmende arbeiteten von Planung und Implementierung bis zu Tests, Dokumentation, CI/CD und Iteration an vollständigen Projekten.
Für den operativen Bereich nennt die Quelle das Program Management Office. Dort werden verstreute Notizen und Chatverläufe durch KI-gestützte Abläufe für Statusverfolgung, Reporting, Release-Governance und Wissenstransfer ersetzt. Statusinformationen werden aus Systemen wie Jira, Google Sheets und CRM-Anwendungen zusammengeführt. Die Quelle beschreibt damit einen realen Unternehmenseinsatz, liefert aber keine unabhängig geprüften Angaben zu Kosten, Fehlerquoten oder Zeitersparnis.
Der übertragbare Kern: zwei Arbeitsbahnen statt eines KI-Sammelprojekts
Aus GNS-Sicht sollte ein ähnliches Vorhaben in zwei Arbeitsbahnen gegliedert werden. Die Codebahn umfasst Aufgaben, bei denen ein Agent Dateien verändert, Tests ausführt oder technische Artefakte erzeugt. Die Wissensbahn bündelt Projektkontext, Status, Entscheidungen und nächste Schritte. Beide Bahnen dürfen Informationen austauschen, benötigen aber eigene Freigaben, Qualitätsmaßstäbe und Verantwortliche.
- Codebahn: klar begrenzte Repositories, überprüfbare Änderungen, automatisierte Tests und menschliche Freigabe vor produktiven Releases.
- Wissensbahn: definierte Quellsysteme, nachvollziehbare Aktualität, Rollenrechte und ein sichtbarer Besitzer für Status und Entscheidungen.
- Gemeinsamer Übergabepunkt: Anforderungen, Risiken und Akzeptanzkriterien werden strukturiert zwischen Operations und Engineering übergeben.
- Gemeinsame Messung: Nicht die Zahl erzeugter Texte oder Codezeilen zählt, sondern kürzere Durchlaufzeit bei stabiler Qualität und weniger Koordinationsaufwand.
Diese Trennung verhindert zwei typische Fehlentscheidungen. Erstens wird ein Coding-Agent nicht zum unkontrollierten Unternehmensgedächtnis. Zweitens bleibt ein Wissensassistent von produktiven Änderungen getrennt, solange die erforderlichen Prüfungen fehlen. Der Nutzen entsteht an der Schnittstelle, nicht durch möglichst weitreichende Zugriffsrechte.
Entscheidungsrahmen für den ersten Anwendungsfall
Ein geeigneter Einstieg verbindet einen häufigen Koordinationsengpass mit einem begrenzten technischen Ergebnis. Denkbar ist etwa ein Release-Prozess, in dem Statusinformationen konsolidiert werden und Codex anschließend nur eine klar umrissene Änderung vorbereitet. Vor dem Pilot sollten Entscheider fünf Fragen schriftlich beantworten.
- Prozesswert: Welche Wartezeit, Doppelarbeit oder Informationslücke soll konkret sinken?
- Quellenklarheit: Aus welchen freigegebenen Systemen stammen Anforderungen, Status und technische Informationen?
- Aktionsgrenze: Darf die KI nur zusammenfassen und vorschlagen oder auch Dateien und Workflows verändern?
- Prüfbarkeit: Welche Tests, Reviews und Protokolle machen Fehler sichtbar, bevor sie Kunden oder Betrieb erreichen?
- Verantwortung: Wer entscheidet bei widersprüchlichem Kontext, fehlgeschlagenen Tests oder veralteten Informationen?
Ein Pilot ist nur sinnvoll, wenn diese Fragen ohne pauschale Antworten wie „das Team prüft schon“ beantwortet werden. Jede Übergabe benötigt einen benannten Eigentümer. Für technische Änderungen kann das ein Repository-Verantwortlicher sein; für operativen Kontext ein Process Owner. Die KI übernimmt Arbeitsschritte, nicht die organisatorische Haftung.
Kosten und Risiken vor der Skalierung sichtbar machen
Der RingCentral-Fall zeigt eine breite Experimentierhaltung. Andere Unternehmen sollten daraus nicht automatisch einen flächendeckenden Rollout ableiten. Breiter Zugriff erhöht zunächst Schulungs-, Integrations- und Kontrollaufwand. Wirtschaftlich wird der Einsatz erst, wenn vermiedene Koordination, schnellere Freigaben oder bessere Wiederverwendung den zusätzlichen Betriebsaufwand übersteigen.
- Kontextkosten erfassen: Pflege, Berechtigungen und Aktualisierung der Wissensquellen gehören in die Gesamtkosten.
- Fehlerkosten begrenzen: Technische Änderungen bleiben testbar und werden vor Produktion freigegeben.
- Datenrisiken reduzieren: Nur notwendige Quellen und Repositories werden für den jeweiligen Anwendungsfall geöffnet.
- Anbieterabhängigkeit planen: Prozesswissen, Prüfkriterien und Artefakte dürfen nicht ausschließlich im KI-Werkzeug verbleiben.
- Nutzung messen: Durchlaufzeit, Nacharbeit, eskalierte Fehler und manuelle Übergaben werden vor und während des Piloten verglichen.
Ein kontrollierter Rollout in vier Schritten
- Einen Prozess wählen, Ausgangswerte dokumentieren und erlaubte Datenquellen festlegen.
- Wissensbahn zuerst stabilisieren: Kontext, Eigentümer, Aktualität und Zugriffsrechte klären.
- Codebahn begrenzt ergänzen: kleine Änderungen, isolierte Umgebung, Tests und verpflichtendes Review.
- Nach einem festen Prüfzeitraum entscheiden: skalieren, Kontrollen nachschärfen oder den Anwendungsfall stoppen.
Die wichtigste Lehre ist damit organisatorisch: AI-native Arbeit entsteht nicht dadurch, dass jedes Team dasselbe Werkzeug erhält. Sie entsteht, wenn Wissen, Ausführung und Verantwortung in einem überprüfbaren Ablauf verbunden werden. RingCentral liefert dafür ein aktuelles Praxisbeispiel. Für DACH-Unternehmen beginnt die Übertragung mit einem kleinen, messbaren Prozess – und mit klaren Grenzen zwischen Vorschlag, Änderung und Freigabe.