Open AI

LLM „Access our frontier models and APIs.“

– (0)

Deine Bewertung

8,0/10 KIFOX Score – Sehr gut

Standort: USA ⓘ

Bildgenerierung Embeddings Funktionsaufrufe KI-Agenten LLM-API Multimodale-KI Programmierung Reasoning-Modell Sprachausgabe Sprachmodell Textgenerierung Transkription Videogenerierung

weiterführender Link

Zielgruppe
Die OpenAI-API-LLMs richten sich primär an Entwicklerteams, SaaS-Anbieter, Agenturen, Start-ups, interne Automatisierungs-Teams, Produktorganisationen und Enterprise-IT. Für Einzelanwender ohne technischen Build-Kontext ist die API weniger naheliegend als ChatGPT; für alle, die eigene Anwendungen, Assistenten, Agenten, Automatisierungen oder dokumentennahe Workflows bauen wollen, ist sie dagegen ein sehr starkes Fundament. Durch die Staffelung von Nano über Mini bis Frontier und Reasoning deckt OpenAI sowohl High-Volume- als auch High-Complexity-Szenarien ab.

Herausragende Funktionen
Die größte Stärke ist die Kombination aus Modellbreite und Werkzeugtiefe. OpenAI kombiniert Frontier-Modelle wie GPT-5.4 mit günstigeren Varianten wie GPT-5.4 mini und nano, ergänzt um Reasoning-Modelle wie o3. Die offiziellen Docs heben außerdem Structured Outputs, Function Calling, Web Search, File Search und bei ausgewählten Modellen Computer Use hervor. Für textlastige Business-Anwendungen sind besonders die sehr großen Kontextfenster von GPT-5.4 und GPT-4.1 interessant.

Wichtigste Anwendungsfelder
Besonders stark ist OpenAI bei Coding, Assistenten, Automatisierung, Dokumentenverarbeitung, internen Wissenssystemen, Kundenkommunikation, Rechercheunterstützung, Übersetzung und Textproduktion. Die Modellfamilien sind so differenziert, dass man für einfache Klassifikation oder Extraktion ein günstiges Modell wählen und für komplexes Planning, mehrstufiges Reasoning oder hochwertige Output-Anforderungen auf größere Modelle gehen kann. Genau diese Staffelung macht OpenAI für reale API-Produktentwicklung so attraktiv.

Nutzung & Hinweise
Praktisch wird OpenAI meist über die Responses API oder die Client-SDKs eingebunden. Für produktive Nutzung sollte man die Modellwahl nicht nur nach Qualität, sondern auch nach Latenz, Kontextfenster, Toolbedarf, Datenschutzanforderungen und Tokenpreis treffen. Wichtig ist außerdem, Endpunkt-spezifische Datenhaltungen zu beachten: Standardmäßig werden API-Daten nicht fürs Training genutzt, aber je nach Endpunkt können Abuse-Monitoring-Logs bis zu 30 Tage anfallen; für berechtigte Organisationen sind Zero Data Retention oder Modified Abuse Monitoring verfügbar. Für Europa sind Data-Residency-Optionen vorhanden, aber nur auf unterstützten bzw. berechtigten Konfigurationen.

Berechnung der Token und Kosten mit KIFOX-Tokenizer

Kurze Praxiseinordnung

Für neue professionelle Text-/Coding-/Agenten-Anwendungen: gpt-5.5 oder gpt-5.4.

Für maximale Qualität bei schwierigen Aufgaben: gpt-5.5-pro.

Für günstige, schnelle Produktions-Workloads: gpt-5.4-mini.

Für sehr günstige Klassifikation, Routing und Extraktion: gpt-5.4-nano.

Für Bildgenerierung und Bildbearbeitung: gpt-image-2.

Für Live-Sprachagenten: gpt-realtime-2.

Für Live-Übersetzung: gpt-realtime-translate.

Für Live-Transkription: gpt-realtime-whisper.

Für Coding-Agenten: gpt-5.3-codex.

Für RAG/Wissensdatenbanken: gpt-5.4-mini oder gpt-5.4-nano plus text-embedding-3-large/text-embedding-3-small.

Zielgruppe	Einschätzung
Entwickler / Softwareteams	Sehr geeignet – für Chatbots, Agenten, strukturierte Ausgaben, Code, Tool-Calling, RAG, Automatisierung, Multimodalität, Audio, Bild und produktive KI-Anwendungen.
SaaS-Anbieter / Produktteams	Sehr geeignet – wenn KI direkt in eigene Produkte, Plattformen oder Workflows eingebettet werden soll.
KMU mit IT-Ressourcen	Geeignet – für Support-Automation, interne Suche, Dokumentenanalyse, Content-Prozesse und Datenextraktion.
Großunternehmen	Sehr geeignet – wegen breitem Modellportfolio, Data-Residency-Optionen, ZDR/Modified Abuse Monitoring, Enterprise Key Management und Governance-Möglichkeiten.
Privatpersonen ohne Technikbezug	Eher nicht geeignet – für sie ist ChatGPT passender; die API setzt technische Integration voraus.

All Modells

GPT-/Reasoning-/Textmodelle über API

gpt-5.5-pro – Für sehr anspruchsvolle professionelle Aufgaben, komplexe Analysen, schwierige Programmieraufgaben, mehrstufiges Reasoning, Strategie, Architektur, juristisch/technisch anspruchsvolle Entwürfe und maximale Antwortqualität. Laut OpenAI ist GPT-5.5 pro die präzisere, rechenintensivere Variante von GPT-5.5 und für schwierige Probleme gedacht.

gpt-5.5 – Bestes allgemeines Frontier-Modell für komplexe professionelle Arbeit, Coding, Analyse, technische Konzepte, Agenten, RAG-Workflows, strukturierte Ausgaben und hochwertige Textgenerierung. OpenAI beschreibt es als neuestes Frontier-Modell für komplexe professionelle Arbeit.

gpt-5.4-pro – Für sehr schwierige professionelle Aufgaben, wenn höhere Präzision wichtiger ist als Geschwindigkeit. Besonders geeignet für komplexe Problemlösung, lange Analysen, tiefes Reasoning und schwierige Code-/Architekturfragen.

gpt-5.4 – Für professionelle Standard- und Enterprise-Workflows mit hoher Qualität, aber günstiger als GPT-5.5. Geeignet für Coding, Analyse, Dokumentation, Agenten, Wissenssysteme, Beratungstexte und strukturierte Business-Anwendungen.

gpt-5.4-mini – Für schnelle, kosteneffiziente Anwendungen mit guter Qualität: Chatbots, Assistenten, Sub-Agenten, Coding-Hilfe, Klassifikation, Datenextraktion, Support-Automatisierung und hohe Anfragevolumen. OpenAI nennt es ein starkes Mini-Modell für Coding, Computer Use und Subagents.

gpt-5.4-nano – Für sehr günstige und schnelle Massenverarbeitung: Klassifikation, Ranking, einfache Datenextraktion, Routing, Vorfilterung, Tagging, kurze Zusammenfassungen und Sub-Agenten. OpenAI beschreibt es als günstigstes GPT-5.4-Klassenmodell für einfache High-Volume-Aufgaben.

gpt-5.3-chat-latest – ChatGPT-ähnliches Modell, das laut OpenAI auf den GPT-5.3-Instant-Snapshot zeigt. Geeignet, wenn ein ChatGPT-nahes Antwortverhalten über API gewünscht ist; nicht erste Wahl für neue technische Systeme, wenn GPT-5.5 oder GPT-5.4 verfügbar sind.

gpt-5.2-pro – Vorheriges Pro-Modell für professionelle Arbeit. Geeignet für sehr komplexe Aufgaben, falls aus Kompatibilitäts-, Kosten- oder Stabilitätsgründen bewusst nicht auf GPT-5.5 pro gewechselt wird.

gpt-5.2 – Vorheriges Frontier-Modell für professionelle Arbeit mit konfigurierbarem Reasoning. Geeignet für bestehende Anwendungen, die auf GPT-5.2 abgestimmt wurden, sowie für komplexe Analysen, Coding und Agenten-Workflows.

gpt-5.1 – Älteres GPT-5-Modell für Coding und agentische Aufgaben. Geeignet für Bestandsanwendungen, die noch auf GPT-5.1 optimiert sind.

gpt-5-pro – Pro-Variante von GPT-5. Geeignet für komplexere Aufgaben als GPT-5, insbesondere dann, wenn mehr Rechenaufwand und Antwortpräzision gewünscht sind.

gpt-5 – Vorheriges intelligentes Reasoning-Modell für Coding, Agenten, Analyse und allgemeine anspruchsvolle Textaufgaben. Heute eher für Kompatibilität und bestehende Implementierungen relevant.

gpt-5-mini – Schnellere und günstigere GPT-5-Variante für klar definierte Aufgaben, präzise Prompts, hohe Anfragevolumen, Chatbots, einfache Agenten und Standard-Automatisierung.

gpt-5-nano – Schnellste und günstigste GPT-5-Variante. Geeignet für Klassifikation, Zusammenfassung, einfache Extraktion, Routing, Tagging und sehr hohe Volumina.

gpt-4.1 – Starkes Nicht-Reasoning-Modell. Geeignet für schnelle, hochwertige Textgenerierung, Coding, Instruktionsbefolgung, lange Kontexte und allgemeine API-Anwendungen, wenn kein tiefes Reasoning erforderlich ist.

gpt-4.1-mini – Kleinere und schnellere GPT-4.1-Variante. Geeignet für produktive Chatbots, Support, Content-Erstellung, Klassifikation und Kostenoptimierung.

gpt-4.1-nano – Sehr schnelle, günstige GPT-4.1-Variante, laut OpenAI inzwischen deprecated. Geeignet nur noch für bestehende Workflows, einfache Klassifikation und Massenverarbeitung.

gpt-4o – Multimodales GPT-Modell für Text und Bildverständnis, schnelle Chatbots, Assistenzsysteme, Analyse von Bildern/Screenshots und allgemeine Anwendungen. Weiterhin relevant für Bestandsprojekte.

gpt-4o-mini – Günstige kleinere GPT-4o-Variante für fokussierte Aufgaben, einfache Chatbots, Klassifikation, kurze Texte und hohe Volumina. Weiterhin relevant für ältere Implementierungen.

gpt-4-turbo – Älteres GPT-4-Modell, inzwischen eher Legacy. Geeignet nur noch für Bestandsanwendungen, die bewusst nicht migriert wurden.

gpt-4 – Älteres High-Intelligence-Modell. Heute primär Legacy/Kompatibilität.

gpt-3.5-turbo – Legacy-Modell für günstige Chat- und Textaufgaben. Heute nur noch für alte Systeme sinnvoll.

o3-pro – Rechenintensivere Variante von o3 für bessere Antworten. Geeignet für sehr schwierige Reasoning-Aufgaben, wenn ein älteres o-Series-Modell benötigt wird.

o3 – Reasoning-Modell für komplexe Aufgaben; laut OpenAI inzwischen von GPT-5 abgelöst. Geeignet für Bestandsanwendungen mit o3-Optimierung.

o4-mini – Schnelles, kosteneffizientes Reasoning-Modell; laut OpenAI inzwischen deprecated und von GPT-5 mini abgelöst. Geeignet nur noch für bestehende Anwendungen, schnelle Reasoning-Aufgaben, Coding und visuelle Aufgaben.

o3-mini – Älteres kleines Reasoning-Modell. Heute nur noch Legacy/Kompatibilität.

o1-pro – Ältere Pro-Variante von o1 für schwierige Reasoning-Aufgaben. Deprecated/Legacy.

o1 – Frühere o-Series-Reasoning-Generation. Deprecated/Legacy.

o1-mini – Frühere kleine o-Series-Variante. Deprecated/Legacy.

o1-preview – Frühe Preview-Version der o-Series. Deprecated/Legacy.

Coding-Modelle

OpenAI führt eigene Codex-/Coding-Modelle für Softwareentwicklung und agentische Coding-Aufgaben.

gpt-5.3-codex – Aktuell wichtiges Coding-Modell für agentische Softwareentwicklung, Codex-ähnliche Workflows, Refactoring, Bugfixing, komplexe Codebasen, Pull-Request-Arbeit und längere Coding-Aufgaben. OpenAI beschreibt es als besonders leistungsfähiges agentisches Coding-Modell.

gpt-5.2-codex – Vorgänger-/Bestandsmodell für lange agentische Coding-Aufgaben, komplexe Codeänderungen und Softwareentwicklung.

gpt-5-codex – Älteres GPT-5-Codex-Modell für agentisches Coding. Heute eher Legacy.

gpt-5.1-codex – Älteres Codex-Modell für Coding-Agenten und Bestandsworkflows. Deprecated/Legacy.

gpt-5.1-codex-max – Variante für länger laufende Coding-Aufgaben. Deprecated/Legacy.

gpt-5.1-codex-mini – Kleinere, günstigere Codex-Variante. Deprecated/Legacy.

codex-mini-latest – Schnelles älteres Reasoning-Modell für Codex CLI. Deprecated/Legacy.

Image-Modelle

OpenAI listet GPT Image 2, GPT Image 1.5, chatgpt-image-latest, GPT Image 1, gpt-image-1-mini sowie DALL·E 3 und DALL·E 2 in der API-Modellübersicht.

gpt-image-2 – Aktuelles State-of-the-Art-Bildmodell für hochwertige Bildgenerierung und Bildbearbeitung. Offizieller API-Name ist GPT Image 2, nicht „GPT Image 2.0“. Geeignet für realistische Bilder, Produktbilder, Illustrationen, Marketinggrafiken, Bildvarianten, Inpainting/Editierung und professionelle visuelle Inhalte.

gpt-image-1.5 – Vorheriges Bildgenerierungsmodell. Geeignet für bestehende Workflows, die auf GPT Image 1.5 abgestimmt sind.

chatgpt-image-latest – Vorheriges Bildmodell aus ChatGPT-Kontext. Geeignet, wenn ChatGPT-ähnliche Bildausgabe gewünscht ist; für neue API-Projekte eher GPT Image 2 bevorzugen.

gpt-image-1 – Vorheriges Bildgenerierungsmodell, inzwischen deprecated. Nur noch für Legacy-Anwendungen relevant.

gpt-image-1-mini – Kosteneffiziente Bildmodell-Variante. Geeignet für günstigere Bildgenerierung, einfache Varianten, Entwürfe, Vorschaubilder und skalierbare Bild-Workflows.

dall-e-3 – Älteres Bildgenerierungsmodell, inzwischen deprecated. Nur noch für Bestandsprojekte relevant.

dall-e-2 – Erste ältere DALL·E-Generation, inzwischen deprecated. Nur noch Legacy.

Realtime-, Audio- und Sprachmodelle

OpenAI listet Realtime- und Audio-Modelle für Live-Sprachinteraktion, Speech-to-Speech, Transkription, Text-to-Speech und Audio-Workflows.

gpt-realtime-2 – Aktuell wichtigstes Realtime-Sprachmodell für Live Voice Agents, Echtzeitdialoge, Callbots, Support-Assistenten, sprachgesteuerte Agenten, Tool Calling während Gesprächen und komplexere Live-Interaktionen. OpenAI beschreibt es als Reasoning-Modell für Realtime Voice Interactions.

gpt-realtime-translate – Spezielles Modell für Live-Übersetzung von Sprache zu Sprache. Geeignet für mehrsprachige Echtzeitkommunikation, Kundensupport, Bildung, Meetings, internationale Teams und Dolmetsch-Workflows. OpenAI beschreibt es als Streaming Speech-to-Speech Translation Model; die aktuelle Ankündigung nennt Echtzeitübersetzung aus über 70 Eingabesprachen in 13 Ausgabesprachen.

gpt-realtime-whisper – Streaming-Speech-to-Text-Modell für Live-Transkription. Geeignet für Meeting-Captions, Live-Untertitel, Call-Transkription, Protokolle, Voice Notes und Dokumentations-Workflows.

gpt-realtime-1.5 – Sehr gutes Voice-Modell für Audio-in/Audio-out. Geeignet für Live-Sprachassistenten, Callcenter-Prototypen, Voice UX und interaktive Sprachdialoge.

gpt-realtime – Realtime-Modell für Text- und Audioeingaben sowie Audioausgabe. Geeignet für ältere Realtime-Implementierungen und Bestandsprojekte.

gpt-realtime-mini – Kosteneffiziente Realtime-Variante. Geeignet für günstigere Voice Agents, einfache Sprachdialoge, hohe Anfragevolumen und Prototypen.

gpt-audio-1.5 – Audio-in/Audio-out-Modell für Chat-Completions-basierte Audio-Workflows. Geeignet für Anwendungen, die nicht zwingend WebRTC-/Realtime-Sessions benötigen.

gpt-audio – Audio-Modell für Audioeingaben und Audioausgaben über Chat Completions. Geeignet für ältere Audio-Workflows, Sprachassistenten und multimodale Audio-Apps.

gpt-audio-mini – Kosteneffiziente Audio-Variante. Geeignet für einfachere Audioaufgaben und skalierbare Audio-Workloads.

gpt-4o-audio – Älteres/deprecated GPT-4o-Audio-Modell. Geeignet nur noch für bestehende Implementierungen.

gpt-4o-mini-audio – Älteres/deprecated kleineres GPT-4o-Audio-Modell. Geeignet nur noch für Bestandsprojekte.

gpt-4o-realtime – Älteres Realtime-Modell für Text- und Audioeingabe sowie Audioausgabe. Geeignet für bestehende Realtime-Apps.

gpt-4o-mini-realtime – Kleinere ältere Realtime-Variante. Deprecated/Legacy.

gpt-4o-transcribe – Speech-to-Text-Modell auf GPT-4o-Basis. Geeignet für hochwertige Transkription, Audioauswertung, Untertitel, Meetings, Interviews und Call-Analyse.

gpt-4o-mini-transcribe – Kleinere, günstigere Transkriptionsvariante. Geeignet für hohe Volumina, einfache Transkription und kostensensible Speech-to-Text-Workflows.

gpt-4o-transcribe-diarize – Transkriptionsmodell mit Sprechererkennung. Geeignet für Interviews, Meetings, Gesprächsprotokolle und Callcenter-Auswertung, wenn unterschieden werden soll, wer wann spricht.

gpt-4o-mini-tts – Text-to-Speech-Modell auf GPT-4o-mini-Basis. Geeignet für natürlich klingende Sprachausgabe, Chatbot-Vorlesen, Voice UX, Lerninhalte und einfache Audioausgaben.

tts-1 – Älteres Text-to-Speech-Modell, auf Geschwindigkeit optimiert. Geeignet für schnelle TTS-Ausgabe.

tts-1-hd – Älteres Text-to-Speech-Modell, auf Qualität optimiert. Geeignet für hochwertigere Sprachausgabe in Legacy-Workflows.

whisper – Allgemeines Speech-Recognition-Modell. Geeignet für klassische Transkription, Audio-zu-Text, Übersetzung/Transkription älterer Workflows und Legacy-Anwendungen.

Deep-Research-Modelle

o3-deep-research – Früheres Deep-Research-Modell für intensive Rechercheaufgaben, Quellenarbeit und mehrstufige Informationsanalyse. Laut Modellübersicht deprecated.

o4-mini-deep-research – Schnellere/günstigere Deep-Research-Variante. Laut Modellübersicht deprecated.

Open-Weight-Modelle

gpt-oss-120b – Open-Weight-Modell unter Apache-2.0-Lizenz. Geeignet für Self-Hosting, eigene Infrastruktur, Forschung, Anpassung und Szenarien, bei denen Modellgewichte relevant sind. OpenAI beschreibt es als stärkstes Open-Weight-Modell, das in eine H100-GPU passt.

gpt-oss-20b – Kleineres Open-Weight-Modell. Geeignet für niedrigere Latenz, lokale/selbst gehostete Anwendungen, Experimente und ressourcenschonendere Deployments.

Weitere API-Modelle, die häufig vergessen werden

computer-use-preview – Spezialmodell für Computer-Use-/Browser-/GUI-Automation. Laut OpenAI deprecated; nur für Bestandsworkflows relevant.

gpt-4o-search-preview – Älteres GPT-Modell für Websuche in Chat Completions. Deprecated; heute eher durch Web-Search-Tools/Responses-Workflows ersetzt.

gpt-4o-mini-search-preview – Kleine ältere Search-Preview-Variante. Deprecated/Legacy.

omni-moderation – Moderationsmodell für die Erkennung potenziell schädlicher Inhalte in Text und Bild. Geeignet für Safety Checks, User-Generated-Content-Prüfung und Compliance-Filter.

text-moderation – Älteres Textmoderationsmodell. Deprecated/Legacy.

text-moderation-stable – Ältere stabile Textmoderationsvariante. Deprecated/Legacy.

text-embedding-3-large – Leistungsfähiges Embedding-Modell. Geeignet für semantische Suche, RAG, Vektorindizes, Ähnlichkeitssuche, Wissensdatenbanken und Clustering.

text-embedding-3-small – Günstigeres Embedding-Modell. Geeignet für skalierbare RAG-Systeme, Suchfunktionen, Klassifikation und semantische Ähnlichkeit bei geringeren Kosten.

text-embedding-ada-002 – Älteres Embedding-Modell. Heute vor allem für Legacy-Vektorindizes relevant.

sora-2 – Videogenerierungsmodell mit synchronisiertem Audio; laut Modellübersicht deprecated.

sora-2-pro – Fortgeschrittene Sora-2-Pro-Variante; laut Modellübersicht deprecated.

Hosting & Daten

✅ = abgedeckt ⚠️ = teilweise / indirekt ❓ = nicht verfügbar / unklar

On-prem / local hosting	❓
Private cloud / data center	⚠️
EU SaaS / Managed	✅
Hybrid	⚠️
DPA / AVV	❓
No training on customer data	✅
Open source / transparency path	⚠️

On-Prem / lokales Hosting: indirekt / nicht verfuegbar

Auf der Website ist keine On-Premise-, Self-Hosting- oder lokal selbst betriebene Modelloption für die OpenAI-API dokumentiert. Dokumentiert ist vielmehr ein gehosteter API-Dienst.

Private Cloud / RZ: teilweise

Es sind Datenresidenz-Kontrollen pro Projekt dokumentiert, einschließlich einer europäischen Region mit regionaler Speicherung und regionaler Verarbeitung für unterstützte Dienste. Eine dedizierte Private-Cloud- oder Single-Tenant-Umgebung wird auf der Website jedoch nicht ausdrücklich beschrieben.

EU-SaaS / Managed: abgedeckt

Die Website dokumentiert eine von OpenAI betriebene SaaS/API-Option mit EU-Datenresidenz für 'Europe (EEA + Switzerland)' über 'eu.api.openai.com'. Für unterstützte Dienste sind regionale Speicherung und regionale Verarbeitung angegeben, allerdings nur unter Voraussetzungen wie Freigabe und zusätzlichen Kontrollen.

Hybrid: teilweise

Die Website erwähnt lokale Ausführung in einzelnen Kontexten, etwa 'Skills' in lokaler Ausführung neben gehosteter containerbasierter Ausführung. Das beschreibt einen technischen Mischpfad für Teilkomponenten, aber kein voll dokumentiertes allgemeines Hybrid-Betriebsmodell für die gesamte Kernlösung.

AVV / DPA: unklar

Einen AVV/DPA oder eine entsprechende Vereinbarung konnte ich auf der angegebenen Domain nicht finden. Auf der Website nicht angegeben.

Kein Training: abgedeckt

In der Datenkontroll-Tabelle steht für die aufgelisteten API-Endpunkte bei 'Data used for training' jeweils 'No'. Zusätzlich sind 'Zero Data Retention' und 'Modified Abuse Monitoring' beschrieben, die Missbrauchsprotokollierung weiter einschränken können, vorbehaltlich Freigabe und Bedingungen.

Open-Source / Transparenz-Pfad: teilweise

Es gibt einen dokumentierten Transparenzpfad über Open-Source-Komponenten von Codex auf GitHub, darunter Codex CLI, Codex SDK, Codex App Server, Skills und die 'Universal cloud environment'. Gleichzeitig sind laut Website zentrale Teile wie 'IDE extension' und 'Codex web' nicht Open Source; ein self-hostbarer Gesamtpfad für die OpenAI-API ist nicht dokumentiert.

Datenverarbeitung

Die Website beschreibt die OpenAI-API als gehosteten Dienst. Für viele Endpunkte ist dokumentiert, dass API-Daten nicht für Training verwendet werden. Standardmäßig gibt es je nach Endpunkt Aufbewahrungsfristen für Abuse-Monitoring und teils Anwendungszustand; für '/v1/responses' ist standardmäßig eine 30-tägige Application-State-Speicherung beschrieben, sofern nicht durch geeignete Kontrollen eingeschränkt. Für europäische Datenresidenz nennt die Website die Region 'Europe (EEA + Switzerland)' mit regionaler Speicherung und für viele unterstützte Dienste auch regionaler Verarbeitung. Gleichzeitig gilt laut Website: Datenresidenz umfasst nicht 'Systemdaten', bestimmte Funktionen haben Einschränkungen, und Daten an Drittanbieter wie Remote-MCP-Server unterliegen deren eigenen Richtlinien.

Fazit

Für den EU/EWR-Raum ist OpenAI auf Basis der dokumentierten Best-Case-Option nicht pauschal, aber bedingt nutzbar: positiv sind EU-Datenresidenz, regionale Verarbeitung für viele Dienste und dokumentierte No-Training-/Retention-Kontrollen. Negativ sind die Freigabeabhängigkeit, fehlende konkrete Angaben zu AVV/DPA, fehlende Subprozessorenangaben auf der Domain, fehlende On-Prem-Option für die Kern-API sowie mehrere Funktionsgrenzen und Ausnahmen. Für ein europäisches Verzeichnis ist daher 'bedingt' die tragfähigste Einstufung.

Quellen

On-prem / local hosting	❓
Private cloud / data center	⚠️
EU SaaS / Managed	✅
Hybrid	⚠️
DPA / AVV	❓
No training on customer data	✅
Open source / transparency path	⚠️