OpenAI Codex datenschutzkonform nutzen im Unternehmen

Ein Fehlerlog kann mehr verraten als dein Prompt.

Du bittest Codex, einen kaputten Test zu reparieren, und der Agent findet in der Ausgabe echte Kundenadressen. Schon hängt die Datenschutzfrage an einer Datei, die du gar nicht bewusst hochgeladen hast.

Wenn du OpenAI Codex datenschutzkonform nutzen möchtest, musst du genau solche Datenwege begrenzen. Ich zeige dir, welchen Zugang du prüfen solltest, welche Trainingsschalter relevant sind und wie du lokale Rechte einschränkst. Danach klärst du EU-Verarbeitung und Cloud-Aufgaben.

Für die Bedienung findest du die wichtigsten Codex-Befehle separat. Hier richten wir den Blick auf Kundenprojekte und Unternehmensdaten.

1. Trenne lokalen Client und tatsächlichen Datenweg

Die Codex-App oder CLI kann auf deinem Rechner arbeiten, was zunächst den Ausführungsort der lokalen Werkzeuge beschreibt. Bei einem Cloud-Modell werden Prompts und benötigter Kontext trotzdem beim Modellanbieter verarbeitet.

Ich würde deshalb zuerst das Projekt bereinigen. Nutze erfundene Testdaten, entferne Produktionszugänge und prüfe Logs auf personenbezogene Inhalte. Ein Fehlerbericht braucht selten die echte E-Mail-Adresse eines Kunden.

Die relevanten Wege lassen sich so unterscheiden. Die Codex-Berechtigungsdokumentation trennt diese Kontrollbereiche ausdrücklich.

Falls du den Agenten noch auswählst, hilft dir der Vergleich von Claude Code und Codex.

Diese Trennung verhindert eine typische Fehlannahme, denn eine lokale Dateisperre ersetzt keinen Anbieter-Vertrag. Den klärst du vor der nächsten Konfiguration.

2. Prüfe kommerziellen Zugang, AVV und Speicherfristen

Für ein Team würde ich einen zentral freigegebenen Zugang wählen, um Konten, Rechte und Vertragsunterlagen nachvollziehbar zuzuordnen. Private Abos einzelner Mitarbeiter erschweren diese Kontrolle.

OpenAI verwendet Business-, Enterprise- und Edu-Inhalte standardmäßig nicht zum Training, und auch bei der API gilt dieser Trainingsverzicht. Die Speicherfristen musst du zusätzlich prüfen.

Der OpenAI-DPA ist in die entsprechenden Services-Verträge einbezogen.

Prüfe, ob dein Zugang darunter fällt. Halte Vertragsfassung, Organisation und den zulässigen Verwendungszweck fest.

Schedule 1 sieht keine geplante Übertragung sensibler Daten vor, außer Nutzer fügen sie unerwartet in unstrukturierte Daten ein. Halte solche Inhalte aus Prompts, Logs und Testdaten heraus.

Der Anhang nennt dafür risikogerechte Schutzmaßnahmen wie Zugriffsbeschränkungen und Zugriffsprotokolle. Kläre den konkreten Vertragsumfang und die rechtliche Freigabe, bevor du solche Daten verarbeitest.

Die Unterauftragsverarbeiter gehören ebenfalls in diese Prüfung.

Bei einem Kundenprojekt prüfst du deine eigene Berechtigung zur Weitergabe, denn dein Kunde kann zusätzliche Vorgaben machen.

Ein AVV liefert keine Rechtsgrundlage für deine eigene Verarbeitung. Halte Zweck und Rechtsgrundlage fest und kläre Informationspflichten sowie die Bearbeitung von Auskunft, Berichtigung und Löschung. Die Orientierungshilfe der Datenschutzkonferenz verlangt außerdem eine Vorabprüfung des Risikos. Bei voraussichtlich hohem Risiko ist grundsätzlich eine Datenschutz-Folgenabschätzung nach Artikel 35 DSGVO erforderlich.

Für API-Aufrufe beschreibt OpenAI in „Your data“ getrennte Sicherheitslogs und Anwendungsdaten. Sicherheitslogs können regulär bis zu 30 Tage gespeichert werden. Bestimmte API-Funktionen speichern zusätzliche Zustände.

Zero Data Retention setzt eine passende Freigabe und kompatible Funktionen voraus, die ein API-Schlüssel allein nicht herstellt. Wenn eine kurze Aufbewahrung erforderlich ist, prüfst du sie für den verwendeten Endpunkt.

Mit diesen Bedingungen im Blick kannst du die zusätzlichen Trainings- und Diagnostikpfade einstellen.

3. Prüfe beide Trainingsschalter und die Telemetrie

Bei persönlichen ChatGPT-Konten hängen neue Codex-Aufgaben an der allgemeinen Einstellung zur Modellverbesserung.

Öffne dazu die ChatGPT-Einstellungen und den Bereich „Data controls“. Deaktiviere „Improve the model for everyone“.

Prüfe anschließend die Codex-Einstellung „Include environments“, die einen separaten Einbezug von Umgebungsdaten steuert. Der allgemeine Opt-out ändert diesen Schalter nicht. OpenAI erklärt beide Kontrollen in der Datenschutzdokumentation.

Ein Opt-out wirkt nicht wie eine nachträgliche Löschung, deshalb brauchen bereits übertragene Inhalte ihren eigenen Löschweg.

Freiwilliges Feedback kann trotz Trainings-Opt-out die gesamte zugehörige Unterhaltung zur Modellverbesserung freigeben.

Sende daher für vertrauliche Aufgaben kein solches Feedback, auch nicht über Daumen-hoch- oder Daumen-runter-Schaltflächen.

Wechselst du zwischen Agenten, prüfst du deren Schalter jeweils neu. Die Claude-Code-Datenschutzanleitung erklärt dessen andere Konfiguration.

Für den lokalen Client enthält ~/.codex/config.toml weitere Kontrollen. Diese Einstellungen sind in der Konfigurationsreferenz dokumentiert. Ergänze vorhandene Abschnitte, statt dieselben Tabellen doppelt anzulegen.

[analytics]
enabled = false

[feedback]
enabled = false

[history]
persistence = "none"

Der History-Schalter betrifft history.jsonl und verspricht keine vollständige Löschung sämtlicher Sitzungsdateien.

feedback.enabled deaktiviert die lokale /feedback-Funktion. Es sperrt keine anderen Feedbackwege in ChatGPT oder im Web.

Anbieterlogs und Cloud-Aufbewahrung bleiben ebenfalls getrennt.

Damit begrenzt du zusätzliche Datennutzung. Die lokalen Befehle brauchen noch eigene Zugriffsgrenzen.

4. Begrenze lokale Befehle mit einem Berechtigungsprofil

Der Projektordner allein begrenzt die Zugriffsrechte nicht. Ein Berechtigungsprofil kann lokale Befehle auf die freigegebenen Dateien beschränken.

Codex dokumentiert benannte Berechtigungsprofile als Beta-Funktion. Das folgende Beispiel orientiert sich am offiziellen Profil für reinen Projektzugriff. Prüfe es mit deiner eingesetzten Client-Version.

Die Zuweisungen stehen im oberen Bereich von ~/.codex/config.toml, vor den Tabellen. Darunter kommen die Profilabschnitte.

Ohne verwaltete allowed_permission_profiles verdrängt ein geladenes sandbox_mode oder ein Start mit --sandbox das Berechtigungsprofil. Diese verwaltete Allowlist ist die dokumentierte Ausnahme. Entferne trotzdem alte sandbox_mode- und sandbox_workspace_write-Einstellungen aus allen geladenen Konfigurationen und gewählten Profilen.

Starte ohne --sandbox und ohne Schutz-Bypass. approval_policy mit „on-request“ verlangt eine Bestätigung, wenn Codex eine Ausführung außerhalb der Sandbox anfordert.

approval_policy = "on-request"
default_permissions = "projekt"

[permissions.projekt]
extends = ":workspace"

[permissions.projekt.filesystem]
glob_scan_max_depth = 3
":root" = "deny"
":minimal" = "read"
":tmpdir" = "deny"
":slash_tmp" = "deny"

[permissions.projekt.filesystem.":workspace_roots"]
"**/.env" = "deny"
"**/.env.*" = "deny"

[permissions.projekt.network]
enabled = false

Das Profil übernimmt die Regeln von :workspace für alle wirksamen Workspace-Roots der Sitzung und zusätzlich aktivierte Profil-Roots. Prüfe daher auch weitere eingebundene Verzeichnisse. Temporäre Verzeichnisse und passende Geheimnisdateien werden zusätzlich gesperrt.

:minimal bleibt eine von Codex je Plattform und Laufzeit bestimmte Leseausnahme für Pfade üblicher Werkzeuge. Es ist keine von dir abschließend benannte Allowlist. Prüfe ihren wirksamen Umfang mit der eingesetzten Client-Version.

default_permissions wählt nur das Standardprofil. Höhere Konfigurationsschichten können das Profil ergänzen oder ersetzen. Für Teamvorgaben definierst du die Profile in der verwalteten requirements.toml und setzt allowed_permission_profiles. Ausgelassene Profile, auch eingebaute, sind dann gesperrt. Diese Kontrolle braucht Codex 0.138.0 oder neuer.

Auf Linux, WSL und nativem Windows begrenzt glob_scan_max_depth die Mustersuche vor dem Sandbox-Start. Passende Deny-Glob-Pfade werden dabei vorab ermittelt.

Die Beispieltiefe 3 muss zur Projektstruktur passen. Tiefere Dateien brauchen eine passende Tiefe oder explizite Pfadregeln.

Eine danach angelegte oder verschobene Geheimnisdatei ist durch den vorherigen Scan nicht nachweislich geschützt. Starte nach solchen Änderungen neu. Prüfe vorhandene Dateien und einen während des Tests neu angelegten Pfad getrennt.

Größere Werte verursachen zusätzliche Scanarbeit. Prüfe Lese- und Schreibsperren mit erfundenen .env-Dateien auf der tatsächlich verwendeten Plattform.

Wenn diese strenge Variante Build-Werkzeuge blockiert, prüfst du den tatsächlich benötigten weiteren Pfad.

Gib ihn gezielt frei und wiederhole den Test. Eine Freigabe des gesamten Rechners würde den Schutz aufheben.

Die Netzwerkregel betrifft ebenfalls lokale Befehle, und für Domain-Regeln braucht Codex zusätzlich seinen aktiven Netzwerkproxy.

Eine Allowlist im Profil stellt keine globale Firewall für sämtliche Codex-Funktionen her.

Dein Team muss diese Grenzen und Ausnahmen verstehen. Die Einordnung zur KI-Kompetenzpflicht hilft dir bei der Schulungsplanung.

Mit dem Test prüfst du, was lokale Werkzeuge einsammeln können. Wo der erlaubte Modellkontext verarbeitet wird, entscheidet weiterhin der Anbieterweg.

5. Wähle den passenden Weg für europäische Verarbeitung

Für EU-Anforderungen prüfst du die Zusagen für Speicherung und Inferenz separat. Datenresidenz beschreibt die Speicherung in einer vereinbarten Region, während Inferenzresidenz die Verarbeitung durch das Modell betrifft.

Die ChatGPT-Residenzdokumentation beschreibt entsprechende Optionen für berechtigte Enterprise- und Edu-Arbeitsbereiche. Codex-App und CLI werden unterstützt. Codex Web wird ausdrücklich ausgenommen.

„Europa“ umfasst dort den EWR und die Schweiz.

Außerdem können Systemdaten, bestimmte Verarbeitungsschritte und externe Dienste außerhalb der gewählten Region bleiben. Übertrage die Zusage daher nicht auf alle Daten eines Kontos.

Im API-Weg prüfst du ein entsprechend berechtigtes Projekt, den regionalen Endpunkt und das unterstützte Modell. Verwende dafür die API-Residenzbedingungen. Ein allgemeiner OpenAI-Endpunkt stellt diese Region nicht automatisch ein.

Ein anderer möglicher Weg führt über Azure, das die Codex-Providerkonfiguration als eigenen Anbieter unterstützt. Damit ändern sich auch Vertrags- und Betriebsweg.

Microsoft unterscheidet globale, zonale und geografische Bereitstellungsarten, weshalb die Ressourcenregion allein keinen entsprechenden Inferenzort garantiert.

Prüfe zusätzlich die Azure-Datenbedingungen und das Logging der verwendeten Funktion.

Auch ein Gateway wie EUrouter schafft einen eigenen Datenweg. Seine Responses-API liefert eine technische Schnittstelle. Vertrag, Modellroute und Ausweichregeln musst du zusätzlich prüfen. Ich würde eine Region niemals allein aus dem Produktnamen ableiten.

Du kannst die Modellverarbeitung auch auf dem eigenen Rechner halten, brauchst dafür aber mehr als eine lokale Codex-Installation.

6. Prüfe lokale Modelle und Cloud-Aufgaben getrennt

Ollama kann ein heruntergeladenes Modell auf deinem Rechner ausführen. Seine Codex-Integration richtet dafür ein eigenes Profil ein. Du startest sie mit folgendem Befehl.

ollama launch codex

Wähle tatsächlich ein lokales Modell, denn ein Cloud-Modell in derselben Auswahl verarbeitet deine Eingaben weiterhin extern. Prüfe außerdem die verwendeten Tools.

Die Websuche der Ollama-Integration kann auch bei lokalen Modellen online laufen. Für das angelegte Profil dokumentiert Ollama diesen Start ohne Websuche.

codex --profile ollama-launch -c 'web_search="disabled"'

Für einen abgegrenzten lokalen Betrieb prüfst du zusätzlich Telemetrie, MCP, Connectoren und Netzwerkzugriffe.

Das lokale Modell kontrolliert seinen eigenen Verarbeitungsschritt. Es übernimmt nicht die Kontrolle aller anderen Funktionen.

Cloud-Aufgaben gehen den umgekehrten Weg. Die Codex-Cloud-Umgebung kann Repositories und vorbereitete Dateisysteme übernehmen. Abhängigkeiten und Zugänge gehören dann ebenfalls in die Cloud-Freigabe.

Verbinde nur benötigte Repositories und Testzugänge, und prüfe die Nutzungsrechte sowie den Löschweg der Umgebung. Deine lokale TOML-Datei liefert dafür keinen vollständigen Nachweis.

Nutzt dein Team zusätzlich Cursor Cloud Agents, brauchen diese eine eigene Freigabe. Die Cursor-Datenschutzanleitung erklärt deren Speicher- und Netzwerkwege.

Die gewählten Wege prüfst du im letzten Schritt gemeinsam mit ungefährlichen Daten.

7. Prüfe deine Freigabe mit einem Testprojekt

Lege ein kleines Projekt mit erfundenen Datensätzen an, in dem eine Testdatei einen deutlich erkennbaren Fantasiewert enthält. Eine zweite liegt außerhalb des freigegebenen Bereichs. Verwende keine echten Schlüssel oder Kundenangaben.

Teste den tatsächlich vorgesehenen Betriebsweg und halte die unterschiedlichen Nachweise der folgenden Prüfungen getrennt fest.

1. Kontrolliere das angemeldete Konto, den ausgewählten Anbieter und das aktive Profil.
2. Prüfe erlaubte Projektarbeit und gesperrte Dateien über lokale Befehle.
3. Prüfe Netzwerkzugriffe der lokalen Werkzeuge und jede externe Integration separat.
4. Kontrolliere, welche lokalen Transkripte und Verlaufsdateien entstehen.
5. Wiederhole die Prüfung separat für jede freigegebene Cloud-Umgebung.

Dokumentiere jeweils Client-Version, Einstellung und Ergebnis. Ein funktionierender Build bestätigt erlaubte Projektarbeit, beweist aber weder einen sicheren MCP-Server noch europäische Verarbeitung.

Wenn ein Werkzeug mehr liest als vorgesehen, sperrst du diesen Weg bis zur korrigierten Grenze und erneuten Prüfung. Vertraue dabei nicht auf eine Verhaltensanweisung im Prompt.

Eine KI-Richtlinie für dein Unternehmen kann die Freigabe festhalten. Sie verbindet Konten, erlaubte Daten und geprüfte Funktionen für alle Beteiligten.

Richte jetzt ein bereinigtes Testprojekt mit dem vorgesehenen Zugang ein. Kundendaten folgen erst nach der dokumentierten Freigabe.