Mit der neuen Agents API von OpenAI können Sie die Ausführungsumgebung eines Agenten auf Ihrer eigenen Infrastruktur betreiben. Die verwaltete Agentenlaufzeit zieht dadurch jedoch nicht in Ihr Rechenzentrum um. Laut aktueller Dokumentation unterstützt die API Datenresidenz ausschließlich in den USA und ist nicht für Zero Data Retention geeignet – auch nicht mit einer selbst gehosteten Sandbox. Für deutsche Unternehmen ist das die erste Freigabefrage: Prüfen Sie die Grenze für Sitzungsdaten, bevor Sie ein privates Repository, ein Data Warehouse oder ein betriebliches Werkzeug anbinden.
Die Neuerung ist die verwaltete Orchestrierung, nicht eine Ausnahme von Ihrer Datenrichtlinie. Ein begrenzter Pilot kann Wartungsaufwand für die Agentenlaufzeit reduzieren. Ein Anwendungsfall mit verbindlicher EU-Speicherung für Sitzungsdaten oder ZDR-Anforderung darf dagegen nicht unter der Annahme starten, lokale Rechenleistung erfülle diese Vorgaben bereits.
Was sich geändert hat: die Codex-Laufzeit als verwaltete API
Am 10. September 2026 hat OpenAI die Agents API als öffentliche Beta vorgestellt. Nach Angaben des Unternehmens steht sie allen Entwicklern zur Verfügung und erschließt die Laufzeit sowie Infrastruktur hinter Codex. Sie wählen Werkzeuge und Ausführungsumgebung; OpenAI betreibt den Harness, also die Agentenlaufzeit. Dieser Beitrag analysiert die Ankündigung und die am 12. September abgerufene technische Dokumentation. Er ist kein selbst durchgeführter Leistungstest.
Die verwalteten Funktionen umfassen Kontextkomprimierung, Werkzeugsuche, programmatische Werkzeugaufrufe und parallele Unteragenten. Das kann Implementierungsarbeit aus Ihrer Anwendung herausnehmen. OpenAIs Aussagen zu Leistung und Effizienz sind jedoch Herstellerangaben, kein unabhängiger Nachweis für niedrigere Kosten oder weniger Produktionsstörungen.
Die Architekturdokumentation unterscheidet drei Komponenten: den gehosteten Harness für Modell- und Werkzeugschleife sowie Sitzungszustand; eine optionale Umgebung für Befehle und Dateien; und Ihren Anwendungsserver, der Aufgaben übermittelt, Ereignisse empfängt und Funktionswerkzeuge ausführt. Ein Agent kann auch ohne eigene Ausführungsumgebung arbeiten, wenn die konfigurierten entfernten Werkzeuge und Funktionen ausreichen.
Damit ändern Sie mehr als das Modell innerhalb eines bestehenden Orchestrierungsstapels. Ihre Anwendung überträgt einen Teil der Laufzeitverantwortung an den Anbieter. Trennen Sie diese Entscheidung von den modellbezogenen Zugangs- und Evaluationsfragen im Beitrag zu GPT-6 Astra für Unternehmen.
Verfügbarkeit ist nicht gleich zulässiger Datenstandort
Die Übersicht zur Agents API ist eindeutig: Sitzungszustand wird für die Fortsetzung von Aufgaben gespeichert; Sitzungen und veröffentlichte Artefakte können gelöscht werden; Datenresidenz wird derzeit nur in den USA unterstützt; ZDR wird nicht unterstützt. Eine selbst gehostete Sandbox ändert die ZDR-Eignung nicht.
OpenAIs endpunktspezifische Datenkontrollen nennen für /v1/agents eine Aufbewahrung des Anwendungszustands bis zur Löschung und kennzeichnen den Endpunkt als nicht ZDR-fähig. Für diesen Endpunkt wird keine Trainingsnutzung angegeben. Das sind verschiedene Kontrollen: „nicht für Training verwendet“ bedeutet nicht „nicht gespeichert“. Die Löschung einer Sitzung verspricht zudem nicht, dass sämtliche separaten Protokolle oder nachgelagerten Kopien im selben Moment verschwinden.
Übertragen Sie die Residenzeigenschaften eines anderen OpenAI-Endpunkts nicht auf diesen Dienst. Ebenso beweisen ein europäischer Sandbox-Partner oder eine virtuelle Maschine in Frankfurt keine europäische Datenresidenz der verwalteten Sitzung. Der Einkauf benötigt den konkreten Endpunkt, die Datenklassen, das Aufbewahrungsverhalten und die vertraglich vereinbarte Verarbeitung.
Daraus folgt kein pauschales Nutzungsverbot für deutsche Organisationen. Es besteht aber ein Widerspruch zu Anwendungsfällen, deren freigegebene Anforderungen EU-exklusive Sitzungsresidenz oder ZDR verlangen. Rechtsberatung und Datenschutzverantwortliche müssen die tatsächlichen Übermittlungsregelungen und rechtlichen Pflichten prüfen. Dieser Beitrag bietet technische Orientierung, keine Rechtsberatung. Die ausgewerteten Quellen belegen keinen Termin für europäische Datenresidenz oder ZDR bei der Agents API.
Was in Ihrer selbst gehosteten Umgebung läuft
Der Leitfaden für selbst gehostete Sandboxes beschreibt einen Executor namens codex exec-server innerhalb Ihrer Umgebung. OpenAIs Harness fordert Befehle an; der Executor führt Shell-Befehle aus, liest und schreibt Dateien und verwendet lokale MCP-Server. Er registriert sich mit einer Umgebungskennung und einem eingeschränkten Schlüssel. Anschließend empfängt er Befehle und übermittelt Ergebnisse über eine WebSocket-Verbindung.
Die Verbindungen werden ausgehend aufgebaut. Zu den dokumentierten Pflichtzielen gehören api.openai.com für die Registrierung und codex-cloud-environments.chatgpt.com für Befehle und Ergebnisse. Damit müssen Sie keinen eingehenden Listener öffnen. Der Arbeitsablauf wird dadurch aber weder offline noch gegen Datenabfluss abgeschottet. Werkzeugergebnisse, die an den verwalteten Harness zurückgehen, gehören in die Datenflussprüfung.
Die Dokumentation unterscheidet Executor-MCP-Verbindungen aus Ihrer Umgebung von Remote-MCP-Verbindungen aus OpenAIs Dienst. Diese Unterscheidung verändert Firewall-Regeln sowie den Ort, an dem Zugangsdaten und Werkzeugantworten verarbeitet werden. „Unser MCP-Server ist privat“ reicht nicht: Beschreiben Sie den tatsächlichen Verbindungsmodus und die zurückgegebenen Inhalte.
Bei selbst gehosteter Ausführung verantwortet Ihre Anwendung Bereitstellung, Wiederverbindung, Abschaltung und dauerhaft benötigte Dateien. Eine verwaltete Wiederaufnahme der Sitzung hebt diese Aufgaben nicht auf. Auch eine verbundene Umgebung beweist keinen erfolgreichen Aufgabenabschluss. Die Architekturdokumentation verlangt die Prüfung des tatsächlichen Ergebnisses und weist darauf hin, dass nicht verfügbare Funktionshandler den Agenten auf ein Ergebnis warten lassen können.
Preise: kein API-Aufschlag bedeutet keine kostenlose Ausführung
OpenAI nennt keine zusätzliche Gebühr für die Agents API selbst. Laut Übersicht werden Modellnutzung nach den API-Tarifen des gewählten Modells, OpenAI-Werkzeuge nach deren Standardtarifen und OpenAI-gehostete Sandboxes nach den Standardtarifen für Container abgerechnet. Beim Selbsthosting tragen Sie weiterhin Ihre eigenen Infrastruktur- und Betriebskosten.
Als konkreten Bezugspunkt nennt die Preisdokumentation für GPT-6 Astra im Standardtarif bei kurzem Kontext 10 US-Dollar pro Million Eingabetokens und 50 US-Dollar pro Million Ausgabetokens. Für zwischengespeicherte Eingaben und Cache-Schreibvorgänge gelten eigene Tarife; lange Kontexte werden anders berechnet. Das sind Modellpreise, keine Festpreise pro erfolgreich abgeschlossener Agentenaufgabe. Prüfen Sie Tarifstufe, Kontextkategorie und Werkzeuggebühren vor der Budgetierung.
Bewerten Sie einen Anwendungsfall pro akzeptiertem Arbeitsergebnis: einschließlich Modellaufrufen, Unteragenten, Sandbox-Laufzeit, externen Diensten und menschlicher Prüfung. Kontextkomprimierung kann lange Sitzungen handhabbar machen, ohne sie günstig zu machen. Parallele Unteragenten können die verstrichene Zeit verkürzen und zugleich den Gesamtaufwand erhöhen. Welche Abwägung für Ihre Aufgaben besser ausfällt, belegt die Ankündigung nicht.
Eine Architekturentscheidung, keine pauschale Migrationsempfehlung
Eine OpenAI-gehostete Umgebung passt, wenn freigegebene Daten in den Dienst gelangen dürfen und ein geringerer Sandbox-Betriebsaufwand wichtiger ist als spezielle lokale Abhängigkeiten. Eine selbst gehostete Umgebung passt, wenn Sie kontrollierte Pakete, private Netzwerkwerkzeuge oder einen bestimmten Rechenstandort benötigen – und die Grenze der verwalteten Sitzung separat akzeptieren können.
Wenn Ihre Anforderung eine lokale Orchestrierung mit expliziter Kontrolle über persistierten Zustand ist, prüfen Sie stattdessen eine anwendungsseitig betriebene Laufzeit. Damit fallen Kontextverwaltung, Wiederholungen, Werkzeugausführung und Wiederherstellung wieder an Ihr Team. Ein Cloud-Modellaufruf entspricht dadurch nicht automatisch Ihrer Datenrichtlinie. Der grundlegende Vergleich von n8n, LangGraph und eigenem Backend erklärt diese Verantwortungsverteilung. Eine stabile, begrenzte Automatisierung braucht nicht allein deshalb einen Ersatz, weil ein verwalteter Harness neu verfügbar ist.
Ein sinnvoller erster Versuch für diese Beta ist eine ausschließlich lesende Analyse synthetischer Betriebsdaten. Verwenden Sie keine echten Zugangsdaten oder Kundeninhalte. Prüfen Sie zunächst, ob sich Sitzungsgrenze, Werkzeugpfad und Bereinigung nachweisen lassen. Vergleichen Sie anschließend akzeptierte Ergebnisse und Betriebsaufwand mit Ihrer vorhandenen Laufzeit. Das ist ein vorgeschlagener Test, keine Behauptung über eine bereits realisierte Kundenimplementierung.
Entscheidungscheckliste für Einkauf und Pilot
1. Geben Sie die Sitzungsgrenze vor dem Sandbox-Standort frei
Dokumentieren Sie Endpunkt, Projekt, Modell, Ausführungsregion, Datenklassen und Aufbewahrungsverantwortliche. Unterscheiden Sie Prompts, Befehlsausgaben, Werkzeugergebnisse und veröffentlichte Artefakte. Die Freigabe erfolgt nur für die tatsächlich genehmigte Dienstkonfiguration. Stoppen Sie den Pilot, wenn „selbst gehostet“ der einzige Residenznachweis ist. Mit dem Muster der KI-Lieferantensteuerung wird aus einer Einkaufsnotiz eine technisch durchsetzbare Konfiguration.
2. Belegen Sie Isolation und getrennte Zugangsdaten
OpenAIs Sandbox-Sicherheitsleitfaden warnt davor, dass agentengenerierter Code verfügbare Dateien, Zugangsdaten und Netzwerkressourcen erreichen kann. Isolieren Sie Arbeitslasten und verwenden Sie einen eingeschränkten Executor-Schlüssel. Der umfassendere Anwendungsschlüssel bleibt außerhalb der Umgebung. Vermitteln Sie nach Möglichkeit Drittanbieterzugriffe über einen Credential-Broker, der Geheimnisse nur genehmigten Anfragen hinzufügt. Prüfen Sie mit synthetischen Testdaten, dass fremde Arbeitslastdateien und nicht freigegebene Ziele tatsächlich gesperrt sind.
3. Verfolgen Sie ein Werkzeugergebnis über den tatsächlichen Pfad
Bestimmen Sie für jedes MCP, ob die Verbindung über den Executor oder den gehosteten Dienst läuft. Erfassen Sie ein bereinigtes Beispiel der Inhalte, die die Umgebung verlassen und in den Sitzungszustand eingehen. Die Prüfung ist erst bestanden, wenn die Integrationsverantwortlichen den vollständigen Pfad erklären können. Eine lokale Quelldatei bildet keine ausreichende Grenze, wenn ihr Inhalt als Werkzeugantwort ausgegeben wird.
4. Testen Sie Verbindungsverlust und Bereinigungsverantwortung
Unterbrechen Sie während einer ungefährlichen Aufgabe die Executor-Verbindung. Dokumentieren Sie den beobachteten Umgebungsstatus – wartend, verbunden oder fehlgeschlagen – gemeinsam mit dem abschließenden Aufgabenergebnis. Prüfen Sie, wie Ihr Handler unerledigte Arbeit abgleicht, bevor neue Arbeit zugelassen oder Rechenleistung abgeschaltet wird. Testen Sie anschließend Sitzungslöschung, Artefaktentfernung und Bereinigung Ihrer Umgebung getrennt. Entdecken Sie dieses Verhalten nicht durch echte Finanz- oder Betriebsschreibvorgänge.
5. Definieren Sie ein messbares Erweiterungskriterium
Legen Sie Bewertungskriterien für akzeptierte Ergebnisse, ein Prüfzeitbudget und eine Gesamtkostengrenze pro Aufgabe fest, bevor Sie den verwalteten Harness mit Ihrer Referenz vergleichen. Starten Sie ohne Schreibrechte auf Produktionssysteme. Erweitern Sie erst, wenn Datenfreigabe, Zugriffssperren, Verbindungswiederherstellung und Bereinigungsnachweise bestanden sind – nicht bereits bei einer überzeugenden Modellantwort. Halten Sie während der Beta einen Rückweg zum bisherigen Arbeitsablauf bereit.
Beginnen Sie mit einer Prüfung der Systemgrenzen
Die Agents API kann den Wartungsaufwand für eine leistungsfähige Agentenlaufzeit reduzieren. Ihre Selbsthosting-Option ist gerade deshalb nützlich, weil Rechenstandort und Laufzeitverantwortung unterschiedliche Entscheidungen sind. Diese Trennung muss in der Beschaffung sichtbar bleiben.
Für ein begrenztes KI-Automatisierungsprojekt ist der praktische Einstieg eine endpunktspezifische Datenflussprüfung mit einem Abnahmeplan für einen rein lesenden Pilot: freigegebene Sitzungsdaten, MCP-Verbindungsmodi, Zugangsdaten, Kostenmessung und Bereinigungsnachweise. Entscheiden Sie zuerst, welche Inhalte die Grenze zum verwalteten Dienst überschreiten dürfen – und erst danach, wie viel Arbeit Sie delegieren.
