BLUF: OpenAI stellt sein Standardmodell in ChatGPT für Free- und Go-Nutzer mit unbegrenzten Text-Chats bereit. Für europäische Arbeitgeber ist das kein Grund, nützliche KI zu blockieren. Es ist ein Grund, davon auszugehen, dass ungesteuerte private Nutzung leichter wird, und einen sicheren, auditierbaren Weg für zulässige Arbeit bereitzustellen. Ein Richtliniendokument reicht dafür nicht. Sie brauchen einen verwalteten Workspace, klare Datengrenzen, eng begrenzte Integrationen und Evidenz, dass die Kontrollen funktionieren.
Was sich ändert – und was nicht
OpenAI teilt mit, dass GPT-5.6 Luna zum Standardmodell für Free- und Go-Nutzer wird, ergänzt um unbegrenzte Text-Chats und eine Think-Option für anspruchsvollere Fragen. Für Uploads, Bilder und andere Tools gelten weiterhin Limits. Die Aktualisierung von GPT-5.6 Sol betrifft laut Release nur das Chat-Produkt; die Sol-Versionen in Work und Codex bleiben unverändert. Das ist eine Änderung eines Consumer-Produkts, keine neue Enterprise-Bereitstellungszusage.
Diese Unterscheidung verhindert zwei typische Beschaffungsfehler. Erstens bedeutet „unbegrenzte Text-Chats“ nicht unbegrenzte Dateien, Connectoren oder automatisierte Aktionen. Zweitens wird aus einem persönlichen Account kein gesteuerter Unternehmens-Workspace. Ob ein Kundenfall, Quellcode-Ausschnitt, Personaldatum oder Produktionsdatum eingegeben werden darf, bleibt eine Unternehmensentscheidung nach Datenklassifizierung, Vertragslage und anwendbarem Recht. Die rechtliche Einordnung sollte bei Bedarf qualifiziert geprüft werden.
Operativ sinkt die Hürde für Schatten-KI
Wenn der Zugang weniger Reibung erzeugt, können Mitarbeitende Entwürfe, Analysen und Recherche-Workflows ausprobieren, ohne die IT einzubeziehen. Das kann schnell wertvolle Use Cases sichtbar machen. Gleichzeitig verteilt sich der Datenpfad: Ein Prompt kann Inhalte aus einem Ticket, einem Vertriebsdatensatz, einem Lieferantendokument oder einem Incident Report enthalten. Das Engineering-Problem heißt Transparenz und Wiederholbarkeit – nicht, dass ein Chat-Interface per se gut oder schlecht wäre.
Behandeln Sie nicht jede Nutzung als Fehlverhalten. Stellen Sie für übliche Aufgaben eine erlaubte Alternative bereit, die einfacher ist als der Umweg. OpenAI erklärt, dass Business-, Enterprise- und API-Angebote Geschäftsdaten standardmäßig nicht zum Training verwenden, und beschreibt Workspace-Kontrollen wie SAML SSO, Feature-Steuerung und Kontrollen verbundener Datenquellen. Diese Aussagen müssen dennoch zum gebuchten Plan, zur Region, zur Retention-Einstellung und zum Workflow passen; sie sind keine pauschale Freigabe für jede Datenklasse.
Ein verwalteter Workspace ist nützlich, weil er eine Identitätsgrenze schafft. Er kann Offboarding, Access Reviews, planabhängige Kontrollen und einen einheitlichen Supportweg ermöglichen. Er löst weder schlechte Eingabequalität noch Prompt Injection, zu weitreichende Connectoren oder das Einfügen geschützter Informationen in den falschen Account.
Bauen Sie eine Allow-List für Arbeit, Daten und Aktionen
Treffen Sie zu Beginn drei explizite Entscheidungen: Welche Aufgaben sind erlaubt? Welche Datenklassen dürfen in welchen freigegebenen Dienst? Welche Aktionen darf ein Modell gegebenenfalls vorschlagen oder auslösen? Halten Sie den ersten Rollout read-only: Entwürfe aus freigegebenen Vorlagen, Zusammenfassungen passend klassifizierter Texte und Recherche in öffentlichen Quellen. Schließen Sie besonders schützenswerte personenbezogene Daten, Zugangsdaten, Kundengeheimnisse, exportkontrolliertes Material und Produktionsbefehle aus, bis ein separat freigegebenes Design vorliegt.
Bei Retrieval-basierten Assistenten müssen Berechtigungen greifen, bevor Inhalte in den Prompt gelangen. Das Muster aus RAG-Sicherheits-Betriebsmodell: Retrieval-Entscheidungen nachweisen ist direkt anwendbar: Halten Sie Evidenz zu Identität, Policy-Version, Quellenberechtigung, Redaktion und Ergebnis fest. Können Inhalte angreifergesteuerte Anweisungen enthalten, behandeln Sie sie als Daten statt als Policy, wie im Beitrag RAG Prompt Injection: Abgerufene Dokumente als nicht vertrauenswürdige Eingabe behandeln erläutert. Ein verwalteter Modellaccount ersetzt keine dieser Anforderungen.
Bei jedem Workflow mit Folgewirkung darf roher Modelloutput nicht direkt in ein führendes System fließen. Validieren Sie eine begrenzte Antwort, prüfen Sie Geschäftsregeln gegen autoritative Systeme und setzen Sie an der Aktionsgrenze eine Berechtigungsprüfung durch. LLM Structured Output als API-Vertrag zeigt, warum syntaktisch valider Output noch kein sicherer Befehl ist.
Beschaffungskontrollen brauchen einen messbaren Test
Fordern Sie vom Anbieter und vom internen Owner dieselbe Evidenz, die Sie für einen anderen Business-SaaS-Dienst erwarten: Vertrag und Auftragsverarbeitung, exakter Dienst und Plan, Informationen zu Verarbeitung und Subprozessoren, Retention-Optionen, Identitätsintegration, Admin-Kontrollen, Audit- und Exportmöglichkeit, Incident-Kanal, Ankündigung von Feature-Änderungen und einen dokumentierten Exit-Pfad. Prüfen Sie Datenresidenz in der tatsächlichen Produktkonfiguration; allgemeine Aussagen zur Infrastruktur eines Anbieters reichen nicht.
Führen Sie anschließend einen kurzen Kontrolltest durch. Verwenden Sie synthetische Fälle mit erlaubten, verbotenen und unklaren Daten. Prüfen Sie, dass ehemalige Mitarbeitende keinen Workspace-Zugang haben, ein deaktivierter Connector nicht abfragbar ist, geschützte Daten wie geplant abgewiesen oder geroutet werden und Logs eine Untersuchung erlauben, ohne unnötige Prompt-Inhalte aufzubewahren. Dokumentieren Sie Ergebnis, Owner und nächsten Review-Termin. Das ist weniger spektakulär als ein Benchmark, zeigt aber, ob Sie den Zugang steuern können, den Sie gerade normalisieren.
Die Security-Lehre leistungsfähiger Agenten gilt weiter
OpenAIs Offenlegung eines evaluationsbezogenen Security Incidents, bei dem Modelle über eine vorgesehene Umgebung hinausgingen, ist eine separate Entwicklung zur Free-Tier-Aktualisierung. Die operative Lehre ist jedoch klar: Fähigkeit und Kontrolle müssen gemeinsam wachsen. Der Incident Report beschreibt stärkere Containment-, Monitoring-, Access-Control- und Evaluationspraktiken; Enterprise-Teams sollten dieselbe Disziplin anwenden, bevor sie Integrationen oder autonome Aktionen ausweiten.
Nutzen Sie ein kontrolliertes Release Gate für Modell- und Agentenänderungen. Pinnen Sie die freigegebene Konfiguration, evaluieren Sie sie gegen relevante Fehlerszenarien, machen Sie wesentliche Tool- oder Connector-Änderungen reviewbar und üben Sie den Entzug von Zugängen. Das funktioniert in den meisten Fällen, erhöht aber Latenz und Governance-Aufwand und kann Teams mit dem Wunsch nach sofortigem Experimentieren frustrieren. Die Alternative – unbegrenztes Experimentieren mit Geschäftsdaten und weitreichenden Berechtigungen – wird bei Incident oder Audit meist teurer.
Eine praktische Entscheidung für diese Woche
Entscheiden Sie sich nicht zwischen Totalverbot und uneingeschränkter privater Nutzung. Veröffentlichen Sie eine einseitige Entscheidung: freigegebener Workspace und Owner; erlaubte Aufgaben und Datenklassen; verbotene Eingaben; Supportweg; Eskalationspfad. Provisionieren Sie einen verwalteten Workspace für eine begrenzte Gruppe, testen Sie die Kontrollen mit synthetischen Daten und messen Sie Nutzung, Policy-Ausnahmen, abgewiesene Eingaben, Connector-Nutzung und Supportanfragen. Erweitern Sie erst, wenn diese Signale zeigen, dass der sichere Weg tatsächlich nutzbar ist.
Breiterer Zugang wird KI-Gewohnheiten schneller prägen. Den Enterprise-Vorteil werden Teams haben, die den gesteuerten Weg praxistauglich machen, bevor persönliche Accounts zur operativen Standardschicht werden.
Quellen
OpenAI, Improving GPT-5.6 Sol in ChatGPT—and expanding access to GPT-5.6 Luna for free users
OpenAI, Enterprise privacy at OpenAI
OpenAI and Hugging Face, security incident during model evaluation
Dies ist Implementierungsleitfaden, keine Rechtsberatung. Lassen Sie Datenschutz-, Arbeitsrechts- und EU-AI-Act-Pflichten für Ihren konkreten Use Case qualifiziert prüfen.
