Bis zu 3 Prozent des weltweiten Jahresumsatzes. Fuer einen DAX-Konzern mit 50 Milliarden Euro Umsatz sind das bis zu 1,5 Milliarden Euro. Das ist der Bussgeldrahmen, in den sich Unternehmen begeben, wenn ihre Mitarbeiter Custom GPTs mit internen Dokumenten befuellen – meist ohne dass IT, Legal oder Compliance davon wissen. In den Finanzabteilungen grosser Konzerne laeuft seit Monaten ein Experiment, das niemand offiziell genehmigt hat. Mitarbeiter laden Quartalberichte, interne Budgetmodelle und Kreditrichtlinien in selbst erstellte Custom GPTs – KI-Assistenten, die auf Basis dieser Dokumente Fragen beantworten, Texte zusammenfassen und Entscheidungen vorbereiten. OpenAI foerdert dieses Verhalten aktiv: Fuer Finance-, Marketing-, Operations-, Healthcare- und Customer-Success-Teams gibt es dedizierte Anleitungen, wie Custom GPTs abteilungsspezifisch konfiguriert werden sollen 135.
Das bedeutet konkret:
Wenn in Ihrem Unternehmen jemand interne Daten in einen Custom GPT laedt – und das tut mit hoher Wahrscheinlichkeit gerade jemand -, dann ist Ihr Unternehmen rechtlich Deployer im Sinne des EU AI Act. Nicht OpenAI. Sie. Mit Dokumentationspflichten, Risikoklassifizierung und einem Bussgeldrahmen, der in die Milliarden geht. Der erste Schritt ist banal und unangenehm zugleich: herausfinden, wie viele dieser Assistenten ueberhaupt existieren. Die meisten Unternehmen kennen die Zahl nicht. Gell?
Das stille Experiment: Wie Custom GPTs in Unternehmen wuchern
Das Ergebnis ist eine stille Proliferation. Jede Abteilung baut ihren eigenen Assistenten, laedt ihre eigenen Dokumente hoch, definiert ihre eigenen Systemanweisungen. Die IT-Abteilung weiss davon oft nichts. Legal und Compliance noch weniger.
Ein dokumentiertes Beispiel fuer den breiten internen KI-Einsatz liefert das japanische Bauunternehmen Taisei Corporation, das Custom GPTs fuer die interne Talententwicklung und Wissensverteilung einsetzt 7. Ein Modell, das Unternehmen weltweit kopieren, ohne die regulatorischen Implikationen zu verstehen.
Das strukturelle Problem: Es gibt keinen zentralen Genehmigungsprozess dafuer, welche Daten in welche Custom GPTs fliessen. Wer entscheidet, ob ein Prozesshandbuch mit Kundendaten hochgeladen werden darf? Wer prueft, ob ein Custom GPT, der fuer eine Abteilung gebaut wurde, versehentlich fuer das gesamte Unternehmen freigegeben wird?
Niemand. Das ist die ehrliche Antwort.
Diese Dynamik ist nicht neu. Sie ist die Wiederkehr der Shadow-IT in einer neuen Schicht. Damals waren es Cloud-Dienste, die an der IT vorbei eingefuehrt wurden, weil sie schneller waren als der offizielle Beschaffungsprozess. Der Unterschied: Eine nicht genehmigte Dropbox-Instanz speichert Daten. Ein nicht genehmigter Custom GPT verarbeitet sie, interpretiert sie und bereitet Entscheidungen darauf auf. Das Risikopotenzial ist eine Stufe hoeher.
Was Custom GPTs technisch koennen – und was das fuer Datensicherheit bedeutet
Custom GPTs funktionieren ueber drei Mechanismen: System-Prompts, die das Verhalten des Assistenten definieren. Hochgeladene Dateien, die als Retrieval-Basis dienen. Und optionale API-Anbindungen an externe Systeme 8. Die hochgeladenen Dokumente werden im sogenannten Knowledge-Store gespeichert und bei Bedarf als Kontext in die Anfragen eingespeist.
OpenAI dokumentiert die technischen Moeglichkeiten ausfuehrlich 9. Was die Dokumentation weniger prominent hervorhebt: Der Datenschutz haengt entscheidend davon ab, welchen Account-Typ ein Unternehmen nutzt.
Was das in der Praxis bedeutet: Bei ChatGPT Team und Enterprise gilt eine Datenisolation. Inhalte werden nicht fuer das Training des Modells verwendet. Bei Consumer-Accounts – ChatGPT Free und Plus – ist das standardmaessig anders, sofern Nutzer nicht aktiv widersprechen.
Und genau hier liegt der Bruch. Viele Mitarbeiter nutzen ihre privaten ChatGPT-Accounts fuer berufliche Zwecke. Sie laden interne Dokumente hoch, ohne zu wissen, dass diese Daten moeglicherweise in Trainingszyklen einfliessen koennten.
Noch kritischer: Wenn ein Custom GPT mit sensiblen Dokumenten fuer andere Nutzer innerhalb einer Organisation freigegeben wird, koennen diese Nutzer ueber gezielte Prompts Inhalte aus der Knowledge-Base extrahieren. Ein Risiko, das in Research-Workflows besonders ausgepraegt ist, wo proprietaere Forschungsdaten und unveroeffentlichte Ergebnisse verarbeitet werden 10.
Der Knowledge-Store ist also kein Tresor. Er ist ein Kontextspeicher, der ueber die richtige Anfrage zurueckgibt, was hineingelegt wurde.
Das ist der Punkt, an dem die intuitive Annahme bricht. Wer ein Dokument hochlaedt, denkt: Das liegt jetzt sicher in meinem Assistenten. Technisch korrekt ist: Das Dokument ist abrufbar fuer jeden, der Zugriff auf den Assistenten hat – und mit der richtigen Formulierung auch fuer den, der eigentlich nur eine Zusammenfassung wollte. Gell? Die Grenze zwischen ,,verarbeiten” und ,,herausgeben” ist bei einem Sprachmodell duenn.
Provider oder Deployer? Warum der EU AI Act Unternehmen unbemerkt in die Pflicht nimmt
Hier liegt die eigentliche rechtliche Zeitbombe. Der EU AI Act unterscheidet zwischen Providern – Unternehmen, die ein KI-System entwickeln und auf den Markt bringen – und Deployern – Unternehmen, die ein KI-System fuer einen bestimmten Zweck einsetzen 14. Nach Artikel 28 des EU AI Act gilt: Wer ein KI-System konfiguriert und fuer einen spezifischen Anwendungsfall einsetzt, uebernimmt Deployer-Pflichten 14.
Genau das tun Unternehmen, wenn ihre Mitarbeiter Custom GPTs mit internen Dokumenten befuellen und fuer operative Entscheidungen nutzen. OpenAI ist der Provider des Basismodells. Das Unternehmen, dessen Mitarbeiter den Custom GPT konfiguriert und einsetzt, wird zum Deployer – mit allen damit verbundenen Pflichten.
Diese Pflichten sind nicht trivial. Deployer muessen das eingesetzte KI-System nach Risikoklassen klassifizieren, Transparenzpflichten erfuellen, Dokumentationsanforderungen einhalten und menschliche Aufsicht sicherstellen. Bei Hochrisiko-KI-Systemen – und hier wird es fuer viele Unternehmen unangenehm – gelten noch strengere Anforderungen.
Wann wird ein Custom GPT zur Hochrisiko-KI? Der EU AI Act definiert Hochrisiko-Anwendungen unter anderem in den Bereichen Personalentscheidungen, Kreditbewertung und Gesundheitsversorgung 15. Ein Custom GPT, der auf Basis von Mitarbeiterdaten Befoerderungsempfehlungen generiert 4. Ein Finanz-Assistent, der Kreditrisiken bewertet 11. Ein Healthcare-Tool, das auf Patientendaten zugreift 12. All diese Szenarien koennten als Hochrisiko-KI eingestuft werden.
Der entscheidende Punkt: Die Einstufung haengt nicht davon ab, wie das Unternehmen den Assistenten nennt, sondern davon, was er tut. Ein Custom GPT, intern als ,,Recruiting-Helfer” gefuehrt, der Lebenslaeufe vorsortiert, faellt funktional in den Hochrisiko-Bereich Personalentscheidungen. Die Bezeichnung schuetzt nicht. Die Funktion entscheidet.
Der Bussgeldrahmen ist erheblich: Bei Verstoessen gegen Deployer-Pflichten drohen Sanktionen von bis zu 3 Prozent des weltweiten Jahresumsatzes. Fuer einen DAX-Konzern mit 50 Milliarden Euro Umsatz waeren das bis zu 1,5 Milliarden Euro.
Die offene Frage, die Compliance-Verantwortliche derzeit beschaeftigt: Wie werden nationale Aufsichtsbehoerden Custom-GPT-Deployments in der Praxis bewerten? Die Antwort ist noch nicht klar. Aber das Schweigen der Behoerden ist keine Entwarnung.
DSGVO, NIS2 und DSA: Das regulatorische Dreieck, das Custom-GPT-Governance erzwingt
Der EU AI Act ist nicht das einzige regulatorische Risiko. Unternehmen, die Custom GPTs mit personenbezogenen Daten betreiben, bewegen sich gleichzeitig im Anwendungsbereich der DSGVO.
DSGVO Artikel 28 verlangt einen Auftragsverarbeitungsvertrag (AVV) mit jedem Dienstleister, der personenbezogene Daten im Auftrag verarbeitet. OpenAI bietet entsprechende Vertraege fuer Enterprise-Kunden an. Fuer Mitarbeiter, die ueber Consumer- oder Team-Accounts Custom GPTs mit Kundendaten befuellen, ist die Vertragslage oft unklar oder schlicht nicht vorhanden.
Dazu kommt das Drittlandtransfer-Problem: OpenAIs Server stehen primaer in den USA. Das EU-US Data Privacy Framework bietet zwar eine Grundlage fuer Datentransfers, ist aber politisch fragil. Ein Schrems-III-Szenario, in dem der Europaeische Gerichtshof das Framework kippt, ist nicht ausgeschlossen.
Fuer Unternehmen in kritischen Sektoren – Energie, Gesundheit, Finanzdienstleistungen, Infrastruktur – kommt NIS2 hinzu. Die Richtlinie verlangt, dass KI-Tools in das unternehmensweite Risikomanagement einbezogen werden. Ein Custom GPT, der auf kritische Betriebsdaten zugreift, ist ein Risikofaktor, der dokumentiert und bewertet werden muss.
Methodische Analogie zur Risikoprofilierung: Aehnlich wie bei der regulatorischen Debatte um KI-Systeme fuer vulnerable Nutzergruppen – etwa Minderjaehrige – laesst sich fuer Custom GPTs ein strukturiertes Risikoprofil nach zwei Dimensionen aufstellen: Datensensitivitaet (von oeffentlichen Informationen bis zu Gesundheits- oder Finanzdaten) und Nutzerkreis (von einzelnen Mitarbeitern bis zu unternehmensweiten oder externen Deployments). Diese Methodik ist explizit als analytischer Rahmen zu verstehen, nicht als direkter inhaltlicher Vergleich. Aber sie zeigt: Risikoprofilierung fuer KI-Deployments ist ein etabliertes Werkzeug, das Unternehmen fuer Custom GPTs noch kaum anwenden.
Das Ergebnis all dieser regulatorischen Anforderungen: Eine AI Acceptable Use Policy ist kein Nice-to-have, sondern eine Compliance-Pflicht. Sie muss mindestens definieren, welche Datenklassen in Custom GPTs hochgeladen werden duerfen, welche Account-Typen fuer welche Anwendungsfaelle zulaessig sind, und wer Genehmigungen erteilt.
Das Governance-Vakuum: Warum Unternehmen trotz bekannter Risiken nicht handeln
Die Risiken sind bekannt. Warum handeln Unternehmen trotzdem nicht? Die Antwort liegt in einer strukturellen Dynamik, die an die Shadow-IT-Welle der 2010er Jahre erinnert – mit hoeherem Risikopotenzial.
Die Adoption-Kurve taeuscht. Viele Unternehmen befinden sich formal noch in der Pilotphase, behandeln Custom GPTs aber faktisch als produktive Systeme 13. Der Unterschied ist nicht nur semantisch: Pilotprojekte unterliegen anderen Governance-Anforderungen als produktive Deployments. Wenn ein Custom GPT taeglich fuer operative Entscheidungen genutzt wird, ist er kein Pilot mehr – unabhaengig davon, wie das Unternehmen ihn intern bezeichnet.
OpenAIs Produktivitaetsversprechen verstaerken den Druck. Dokumentierte Produktivitaetssteigerungen durch Custom GPTs 13 werden intern als Argument gegen Governance-Bremsen verwendet: ,,Wenn wir jetzt Prozesse einfuehren, verlieren wir den Wettbewerbsvorteil.” Dieses Argument ist verstaendlich. Und gefaehrlich.
Die Zustaendigkeitsluecke ist das eigentliche strukturelle Problem. IT-Abteilungen sehen Custom GPTs als Business-Entscheidung. Legal und Compliance sehen sie als IT-Thema. Fachbereiche sehen sie als ihr operatives Werkzeug. Das Ergebnis: Niemand fuehlt sich zustaendig, und niemand hat einen Ueberblick darueber, wie viele Custom GPTs intern existieren, welche Daten sie verarbeiten und wer Zugriff hat.
Was das in der Praxis bedeutet: Das Vakuum ist nicht das Resultat von Ignoranz, sondern von verteilter Verantwortung. Jeder vertraut darauf, dass ein anderer das Risiko bereits geprueft hat. Niemand hat.
Was Unternehmen jetzt tun muessen: Ein Governance-Framework in fuenf Schritten
Die gute Nachricht: Das Governance-Vakuum laesst sich schliessen. Hier sind fuenf konkrete Schritte, die Unternehmen jetzt einleiten muessen.
Schritt 1: Inventarisierung. Bevor Governance moeglich ist, braucht es Transparenz. Unternehmen muessen alle bestehenden Custom GPTs erfassen: Wer hat sie erstellt? Welche Daten wurden hochgeladen? Wer hat Zugriff? Dieser Schritt ist unangenehm, weil er das Ausmass des Problems sichtbar macht. Aber er ist unumgaenglich.
Schritt 2: Klassifizierung. Jeder Custom GPT muss nach zwei Dimensionen bewertet werden: Datensensitivitaet der hochgeladenen Inhalte und potenzieller Risikoklasse nach EU AI Act. Custom GPTs in HR, Finance und Healthcare sind besonders kritisch zu pruefen 412.
Schritt 3: Vertragsgrundlage pruefen. Unternehmen muessen klaeren, ob ein gueltiger Auftragsverarbeitungsvertrag mit OpenAI vorliegt, der die tatsaechliche Nutzung abdeckt. Wo das nicht der Fall ist, muss entweder auf Enterprise-Tier migriert oder die Nutzung eingestellt werden.
Schritt 4: AI Acceptable Use Policy. Die Policy muss klare Verbote enthalten – keine personenbezogenen Daten in Consumer-Accounts, keine Hochrisiko-Anwendungen ohne explizite Genehmigung – sowie einen definierten Genehmigungsprozess fuer neue Custom GPTs.
Schritt 5: Technische Kontrollen. Zugriffsbeschraenkungen, Audit-Logs und regelmaessige Reviews sind keine optionalen Extras, sondern Voraussetzungen fuer nachweisbare Compliance. OpenAIs eigene Academy-Ressourcen bieten einen Ausgangspunkt fuer Mitarbeiterschulungen 9.
Die Reihenfolge ist kein Zufall. Ohne Schritt 1 ist Schritt 2 unmoeglich, denn klassifizieren laesst sich nur, was bekannt ist. Und ohne die Schritte 1 bis 4 sind technische Kontrollen blosse Kosmetik. Wer mit Schritt 5 beginnt, baut Zaeune um ein Feld, dessen Groesse er nicht kennt.
Fazit: Die Uhr tickt – aber die meisten Unternehmen hoeren sie nicht
Die Risiken sind real und mehrschichtig: Datenschutzverstoesse durch unkontrollierte Drittlandtransfers, EU-AI-Act-Haftung durch unbemerkte Deployer-Rollen, und ein strukturelles Governance-Vakuum, das sich mit jeder neuen Abteilung, die einen Custom GPT baut, vergroessert.
Der EU AI Act tritt schrittweise in Kraft 16. Die Verbote fuer inakzeptable Risiken gelten seit Februar 2025, die Anforderungen fuer Hochrisiko-KI greifen ab August 2026 15. Das Zeitfenster fuer proaktive Compliance-Massnahmen ist also noch offen. Aber es schliesst sich.
Die These dazu ist nuechtern: Unternehmen, die Custom GPTs heute als harmlose Produktivitaetstools behandeln, halten morgen regulatorische Haftungsfaelle in der Hand. Die Technologie ist schneller als die Governance – das ist keine neue Erkenntnis. Neu ist der Abstand. Selten klaffte er so weit, und selten waren die regulatorischen Konsequenzen so konkret absehbar. Wer jetzt nicht inventarisiert, klassifiziert und vertraglich absichert, verlagert die Entscheidung nicht, sondern delegiert sie an die erste Aufsichtsbehoerde, die genauer hinsieht.
Quellen
- 1 ChatGPT for customer success teams [https://openai.com/academy/customer-success]
- 2 ChatGPT for finance teams [https://openai.com/academy/finance]
- 3 ChatGPT for marketing teams [https://openai.com/academy/marketing]
- 4 ChatGPT for operations teams [https://openai.com/academy/operations]
- 5 Using skills [https://openai.com/academy/skills]
- 6 Healthcare [https://openai.com/academy/healthcare]
- 7 Taisei Corporation shapes the next generation of talent with AI [https://openai.com/index/taisei]
- 8 Using custom GPTs [https://openai.com/academy/custom-gpts]
- 9 ChatGPT for research [https://openai.com/academy/research]
- 10 How should AI systems behave, and who should decide? [https://openai.com/index/how-should-ai-systems-behave]
- 11 ChatGPT for finance teams [https://openai.com/academy/finance]
- 12 Healthcare [https://openai.com/academy/healthcare]
- 13 Surging developer productivity with custom GPTs [https://openai.com/index/paf]
- 14 Amt fuer Veroeffentlichungen der EU, “Verordnung (EU) 2024/1689 (KI-Verordnung): Definition Betreiber/Deployer und Anbieter/Provider, Pflichten der Betreiber von Hochrisiko-KI-Systemen”, 2024 [https://eur-lex.europa.eu/eli/reg/2024/1689/oj]
- 15 Europaeische Kommission, “Regulatory framework on AI: risikobasierter Ansatz, Hochrisiko-Bereiche (u.a. Beschaeftigung) und Anwendungszeitplan”, 2024 [https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai]
- 16 Europaeische Kommission, “AI Act enters into force”, 2024 [https://commission.europa.eu/news/ai-act-enters-force-2024-08-01_en]
[ANMERKUNG REDAKTION: source_floor behoben (2026-06-20). Drei verifizierte Primaerquellen ergaenzt – EUR-Lex (Verordnung (EU) 2024/1689, Quelle 14), Europaeische Kommission Regulatory Framework on AI (Quelle 15) und Europaeische Kommission AI Act enters into force (Quelle 16) – jeweils per WebFetch auf HTTP 200 + inhaltliche Deckung der zitierten Aussagen geprueft. Damit drei distinkte Domains (openai.com, europa.eu-Subdomains). Es wurden keine neuen Behauptungen eingefuehrt; die ergaenzten Quellen stuetzen ausschliesslich bereits vorhandene Aussagen zu Provider/Deployer-Pflichten, Hochrisiko-Klassifizierung und Zeitplan.]
