Das sorgt in der Praxis für Verwirrung: Viele Unternehmen glauben, „der AI Act sei doch verschoben worden“ – und übersehen, dass die Transparenzpflichten längst gelten. Dieser Beitrag erklärt, wen die KI Kennzeichnungspflicht trifft, was konkret zu kennzeichnen ist, welche Ausnahmen bestehen – und wie Inhalte richtig gekennzeichnet werden, mit praktischer Anleitung für Bilder, Grafiken, Audio, Texte und Software-Lösungen wie KI-Chatbots.

KI-Kennzeichnungspflicht: Was seit dem 2. August 2026 gilt

Art. 50 der KI-Verordnung (EU) 2024/1689 bündelt die sogenannten Transparenzpflichten. Ihr Ziel: Menschen sollen erkennen können, wann sie es mit KI zu tun haben – sei es im Gespräch mit einem Chatbot oder beim Betrachten eines täuschend echten Bildes. Drei Punkte zur Einordnung vorab:

• Der Stichtag ist fix: Die Kernpflichten aus Art. 50 Abs. 1, 3 und 4 sind seit dem 2. August 2026 anwendbar. Dieser Termin wurde durch den Digital Omnibus nicht verschoben – anders als die Hochrisiko-Fristen (nun Dezember 2027 bzw. August 2028, mehr dazu hier).
• Eine Teilpflicht hat Aufschub: Nur die maschinenlesbare Markierung synthetischer Inhalte (Art. 50 Abs. 2, Stichwort Wasserzeichen) wurde im Omnibus-Verfahren für Systeme, die zum Stichtag bereits am Markt waren, um wenige Monate verlängert. Für neue Systeme gilt die Pflicht unmittelbar.
• Es drohen empfindliche Bußgelder: Verstöße gegen die Transparenzpflichten können mit bis zu 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes geahndet werden – je nachdem, welcher Betrag höher ist. Für KMU gelten abweichende Regeln.

Wen trifft die KI Kennzeichnungspflicht? Klar: Anbieter und Betreiber

Der AI Act verteilt die Pflichten entlang der Wertschöpfungskette. Für die Praxis entscheidend ist die Unterscheidung zwischen Anbietern („Provider“, die das KI-System entwickeln oder unter eigenem Namen bereitstellen) und Betreibern („Deployer“, die es einsetzen). Die meisten KMU sind Betreiber – und damit keineswegs aus dem Schneider, wie die Tabelle vereinfacht beschreibt:

Für die meisten Unternehmen sind damit zwei Baustellen relevant: der Chatbot-Hinweis (wenn sie selbst ein KI-System anbieten oder ein White-Label-System unter eigenem Namen betreiben) und die Deepfake-Kennzeichnung im Marketing – etwa bei fotorealistischen KI-Models, geklonten Stimmen oder täuschend echten Produktszenen bzw. Produktillustrationen, KI-generierten Produktfotos oder andere Marketing-Grafiken, die täuschend echt aussehen (können).

Wie richtig kennzeichnen? Die Praxis-Anleitung für die KI-Kennzeichnung

Der AI Act schreibt keine exakte Formulierung vor – er verlangt, dass die Information klar, erkennbar und spätestens bei der ersten Interaktion bzw. Wahrnehmung erfolgt. Was das für die fünf gängigsten Fälle bedeutet – Chatbots, Bilder, Grafiken, Texte und Software mit KI-Funktionen – zeigt die folgende Anleitung für die Kennzeichnungspflicht:

Fall 1: Chatbots und KI-Assistenten

• Ein sichtbarer Hinweis direkt im Chat-Fenster genügt – etwa „Sie chatten mit unserem KI-Assistenten“ als Begrüßung oder dauerhaft im Header.
• Der Hinweis gehört an den Anfang der Interaktion, nicht ins Impressum oder in die Datenschutzerklärung.
• Ein täuschend menschlicher Auftritt (Name, Foto, „Ich bin Lisa aus dem Support“) ohne KI-Hinweis ist genau das Muster, das Art. 50 verhindern will.

Fall 2: KI-generierte Bilder, Videos und Audio (Deepfake-Fälle)

• Kennzeichnung direkt am Inhalt: sichtbarer Hinweis wie „Mit KI erstellt“ oder „KI-generiert“ im oder unmittelbar am Bild/Video – nicht versteckt in der Bildunterschrift auf einer Unterseite.
• Maßgeblich ist die Täuschungseignung: Ein fotorealistisches KI-Model in der Werbekampagne ist kennzeichnungspflichtig. Ein offensichtlich fiktives Motiv (z.B. eine Deutsche Autobahn ohne Baustellen und Schlaglöcher) ist es  (vermeintlich) nicht – kleiner Spaß am Rande.
• Bei künstlerischen oder satirischen Werken genügt eine Offenlegung, die die Darbietung nicht beeinträchtigt – etwa im Abspann.
• Bei Audio-Spuren und VoiceOvers ist es schwieriger: Werden diese im Social Media Kontext genutzt (z.B. als Instagram oder TikTok Reel) kann ein Hinweis direkt im VoiceOver störend sein und den Effekt bzw. die Ausspielung der Inhalte stark verschlechtern. Sollte es sich in Kombination mit den übrigen Inhalten (Video / Bild) als nötig erweisen, reicht ein kombinierter Hinweis im sichtbaren Material, also dem Bild oder Video. Bei anderen Formaten, wie z.B. KI-generierten Podcasts oder Hörbüchern, sollte der Hinweis direkt in der Audiospur erfolgen. Hier kommt es auf den Einzelfall an. Gerne beraten wir dabei.

Go vs. No Go: Gleiches Bild, ein Unterschied: Erst die Kennzeichnung macht den täuschend echten KI-Inhalt zulässig. (Bild: KI-generiert, © Elsen GRC)

Fall 3: Grafiken, Illustrationen und Infografiken

• Für schematische Darstellungen gilt Entwarnung: Eine KI-generierte Infografik, ein Diagramm oder eine stilisierte Illustration ist in aller Regel nicht kennzeichnungspflichtig – ihr fehlt die Täuschungseignung, weil niemand sie für ein echtes Foto oder reales Ereignis hält.
• Die Grenze verläuft beim Fotorealismus: Sobald eine Grafik echte Personen, Orte oder Ereignisse täuschend echt nachbildet (etwa ein fotorealistisch gerendertes „Pressefoto“), greift die Deepfake-Regel aus Abs. 4 – dann bitte sichtbar kennzeichnen.
• Praktischer Zwischenweg für Corporate Design: Wer KI-Grafiken einheitlich einsetzt, kann einen dezenten Herkunftshinweis in den Bildnachweis oder das Impressum der Publikation aufnehmen – rechtlich meist nicht gefordert, aber ein Vertrauenssignal. Das lässt sich in Design-Vorlagen bei Canvas, Claude Design o.ä. sogar gezielt einstellen.

Fall 4: Software und eigene KI-Features

• Wer KI-Funktionen in die eigene Software einbaut (etwa einen Assistenten in der App, automatische Textvorschläge, KI-Auswertungen), wird dafür regelmäßig zum Anbieter im Sinne des Art. 50 – mit den entsprechenden Pflichten aus Abs. 1 und 2.
• Konkret heißt das: Interagiert der Nutzer mit einer KI-Komponente, muss das in der Oberfläche erkennbar sein – etwa durch eine Beschriftung wie „KI-Assistent“, ein einheitliches KI-Symbol oder einen Hinweis beim ersten Aufruf des Features. Ein Satz in den Release Notes genügt nicht.
• Erzeugt die Software synthetische Inhalte (Texte, Bilder, Audio), muss der Output maschinenlesbar markiert werden (Abs. 2) – bei eingebundenen Fremdmodellen (z.B. via API von OpenAI oder Anthropic) sollte vertraglich und technisch geklärt sein, wessen Markierung greift und dass sie nicht in der eigenen Verarbeitungskette verloren geht.
• Für die Dokumentation: Jedes KI-Feature gehört ins KI-Inventar – inklusive der Einordnung, welche Kennzeichnungspflichten es auslöst.

Mehr Infos: KI-Inventar erstellen und pflegen

Fall 5: KI-gestützte und KI-generierte Texte

• Interne Dokumente, E-Mail-Entwürfe, redaktionell geprüfte Blogbeiträge: keine Kennzeichnungspflicht nach Art. 50.
• Kennzeichnungspflichtig werden Texte erst, wenn sie die Öffentlichkeit über Angelegenheiten von öffentlichem Interesse informieren und keine menschliche redaktionelle Verantwortung besteht – etwa vollautomatisch publizierte News-Feeds.

Häufige Fehler bei der KI Kennzeichnungspflicht

• Überkennzeichnung aus Angst: Wer jeden KI-gestützten Text mit Warnhinweisen versieht, erfüllt keine Pflicht, sondern verwässert die Aussagekraft der Kennzeichnung – und verunsichert Kunden unnötig.
• Versteckte Hinweise: Der KI-Hinweis in den AGB oder der Datenschutzerklärung genügt nicht. Die Information muss dort erfolgen, wo die Interaktion oder Wahrnehmung stattfindet.
• „Der Anbieter macht das schon“: Die maschinenlesbare Markierung (Abs. 2) liegt beim Systemhersteller – die sichtbare Deepfake-Kennzeichnung (Abs. 4) aber bei Ihnen als Betreiber. Beide Ebenen verwechseln viele.
• Omnibus-Irrtum: „Der AI Act wurde doch verschoben“ gilt für Hochrisiko-Pflichten – nicht für die Transparenzpflichten. Die gelten jetzt.
• Fehlender Überblick: Ohne KI-Inventar weiß niemand, welche Systeme im Haus überhaupt Kennzeichnungspflichten auslösen.

Checkliste: KI Kennzeichnungspflicht umsetzen

Kompakt zum Abhaken – in wenigen Schritten zur konformen und sicheren KI-Kennzeichnung:

• KI-Inventar prüfen: Welche eingesetzten Systeme interagieren mit Menschen oder erzeugen synthetische Inhalte?
• Rolle klären: Sind wir je System Anbieter oder Betreiber – und welche Absätze von Art. 50 greifen damit?
• Chatbots ausweisen: Sichtbarer KI-Hinweis zu Beginn jeder Interaktion implementiert
• Inhalts-Kategorien definieren: Klare interne Regeln, was als „KI-generiert“, „KI-unterstützt mit redaktioneller Prüfung“ und „menschlich erstellt“ gilt
• Deepfake-Fälle identifizieren: Marketing-Assets mit fotorealistischen KI-Elementen erfasst und gekennzeichnet
• Kennzeichnungsstandard festlegen: Einheitliche Formulierungen und Platzierungen dokumentiert (Styleguide)
• Anbieter-Markierung prüfen: Bestätigung der Systemhersteller einholen, dass maschinenlesbare Markierung (Abs. 2) umgesetzt ist bzw. wird
• Mitarbeiter schulen: Regeln in der KI-Kompetenzschulung und der internen KI-Richtlinie verankern
• Prozess etablieren: Kennzeichnungsprüfung fest in den Content- und Kampagnen-Workflow integrieren

➞ Checkliste zur KI-Kennzeichnungspflicht als kostenloses PDF downloaden

Wie Elsen GRC Sie unterstützt

Die KI Kennzeichnungspflicht ist für viele Unternehmen der erste unmittelbare Berührungspunkt mit dem AI Act – und selten der letzte. Elsen GRC begleitet Sie dabei, aus der Einzelpflicht ein tragfähiges Fundament zu machen:

• AI Act Readiness Scan: Wir erfassen Ihre KI-Systeme, klären Rollen und Risikoklassen – und identifizieren dabei genau, wo Kennzeichnungspflichten bestehen.
• KI-Kompetenzschulung nach Art. 4 EU AI Act: Damit Ihre Teams die Transparenzregeln kennen und im Alltag korrekt anwenden – inklusive Zertifikat und Schulungsregister.
• KI-Governance-Beratung: Kennzeichnungsstandards, Freigabeprozesse und KI-Richtlinie aus einem Guss.

So wird aus einer Pflicht, die viele als Bürokratie empfinden, ein Baustein für ehrliche, vertrauensbildende Kommunikation.

Häufige Fragen zur KI Kennzeichnungspflicht (FAQ)

Muss ich jeden mit ChatGPT, Claude oder Gemini geschriebenen Text kennzeichnen?

Nein. Texte, die ein Mensch redaktionell prüft und verantwortet, unterliegen keiner Kennzeichnungspflicht nach Art. 50. Die Pflicht greift bei veröffentlichten Texten zu Angelegenheiten von öffentlichem Interesse ohne menschliche redaktionelle Verantwortung. Für Blogs, Redaktionen und Pressemeldungen kann die KI also eingesetzt werden.

Gilt die KI Kennzeichnungspflicht auch für kleine Unternehmen (KMU) und Selbständige?

Ja. Der AI Act knüpft an die Nutzung an, nicht an die Unternehmensgröße oder die Gewerbeanmeldung. Wer einen Chatbot betreibt oder täuschend echte KI-Inhalte veröffentlicht, ist unabhängig von der Mitarbeiterzahl in der Pflicht. Auch als Privatperson oder Freiberufler.

Wurde die Kennzeichnungspflicht nicht durch den Digital Omnibus verschoben?

Nein, das ist ein verbreiteter Irrtum. Verschoben wurden die Hochrisiko-Pflichten (auf Dezember 2027 bzw. August 2028). Die Transparenzpflichten nach Art. 50 Abs. 1, 3 und 4 gelten seit dem 2. August 2026. Lediglich die maschinenlesbare Markierung (Abs. 2) erhielt für Bestandssysteme eine kurze Übergangsfrist.

Wie muss ein Chatbot-Hinweis konkret aussehen?

Klar erkennbar und spätestens bei der ersten Interaktion – etwa als Begrüßungstext oder dauerhafter Hinweis im Chat-Fenster. Ein Hinweis nur in AGB oder Datenschutzerklärung genügt nicht.

Welche Strafen drohen bei Verstößen?

Bußgelder von bis zu 15 Millionen Euro oder 3 Prozent des weltweiten Jahresumsatzes – je nachdem, welcher Betrag höher ist. Für KMU gelten hier aber abweichende Regelungen.

Offene Fragen zum Thema? Nutzt gerne unser Kontaktformular für einen unverbindlichen Austausch!

Titelbild: KI-generierter Inhalt, passend zum Thema

Verwandte Themen

• EU AI Act: Definition, Bedeutung & Pflichten
• KI-Inventar erstellen und pflegen: Guideline nach EU AI Act
• KI-Governance: Definition, Bedeutung & GRC-Relevanz

Quellen

• TÜV Rheinland Consulting: Transparenzpflichten im EU AI Act (Art. 50)
• TÜV Rheinland Consulting: EU AI Act ab 2. August 2026 – was Unternehmen jetzt tun müssen
• heise online: KI-Kennzeichnungspflicht – Was die EU ab August 2026 verlangt
• EU AI Act, Art. 50 – Transparenzpflichten (Gesetzestext)

Der Beitrag KI Inhalte kennzeichnen: Anleitung zur KI-Kennzeichnungspflicht nach AI Act erschien zuerst auf ELSEN GRC.

Wir fassen die Fakten kompakt zusammen und werfen einen Blick auf das Thema Risikomanagement im Kontext von Open-Source Software wie WordPress.

Was ist die WordPress Sicherheitslücke wp2shell? Die Fakten in Kürze

Hinter dem griffigen Namen stecken zwei Schwachstellen, die erst in ihrer Kombination gefährlich werden. Entdeckt wurde die Lücke von Adam Kues (Searchlight Cyber).

• Zwei verkettete CVEs: CVE-2026-60137 und CVE-2026-63030 greifen ineinander. Einstiegspunkt ist eine Verwechslung in der REST-API-Batch-Route (/wp-json/batch/v1), die in eine SQL-Injection und von dort in die Codeausführung mündet.
• Ohne Authentifizierung ausnutzbar: Der Angreifer braucht kein Konto und keine Nutzerinteraktion. Genau das macht die Lücke so brisant – sie lässt sich automatisiert und mit KI-Agenten gegen große Mengen von Seiten fahren.
• Riesige Angriffsfläche: WordPress betreibt schätzungsweise deutlich über 500 Millionen Websites weltweit. Die Zahl potenziell betroffener Installationen ist entsprechend groß.
• Aktive Ausnutzung bestätigt: Laut BSI-Warnung (Update vom 20. Juli 2026) wurden am Wochenende Proof-of-Concepts veröffentlicht, die die vollständige Kette ohne Authentifizierung ausnutzen. Es liegen bereits Berichte über erste reale Angriffe vor.

Betroffene Versionen und Fixes

WordPress-Version	Status	Maßnahme
7.0.0 – 7.0.1	Anfällig (RCE)	Update auf 7.0.2
6.9.0 – 6.9.4	Anfällig (RCE)	Update auf 6.9.5
7.1 beta	Anfällig (RCE)	Update auf 7.1 beta2
6.8.x	Separate SQL-Injection	Update auf 6.8.6
vor 6.8	Nicht betroffen	–

Sofortmaßnahme: Prüfen Sie im WordPress-Dashboard die tatsächlich installierte Version – verlassen Sie sich nicht darauf, dass Auto-Updates gegriffen haben. Wer nicht sofort patchen kann, sollte den Pfad /wp-json/batch/v1 sowie den Parameter rest_route=/batch/v1 per Web Application Firewall (WAF) blockieren oder den unauthentifizierten Zugriff auf die REST-API einschränken. Diese Maßnahmen sind nur eine Notüberbrückung bis zum Update.

GRC-Betrachtung: Was der Vorfall über Risikomanagement lehrt

Ein Sicherheitsupdate einzuspielen ist Tagesgeschäft der IT. Der eigentliche Wert eines Vorfalls wie wp2shell für Unternehmen liegt woanders: Er ist ein Stresstest für das eigene Risikomanagement. Die entscheidende Frage lautet nicht „Haben wir gepatcht?“, sondern „hätten wir es rechtzeitig gemerkt?“ oder „hätten wir gewusst, welche Systeme überhaupt betroffen sind?“ – aus GRC-Perspektive legt der Fall vier Schwachpunkte offen, die weit über WordPress hinausreichen.

Willkommen bei WordPress 7.0.2 – wer diese Meldung sieht, hat rechtzeitig gehandelt und die Sicherheitslücke geschlossen.

1. Asset-Management: Man kann nur schützen, was man kennt

Die erste Frage nach einer solchen Meldung lautet: Betreiben wir überhaupt WordPress-Websites – und wenn ja – in welcher Version, an welchen Stellen?

Viele Unternehmen können das nicht ad hoc beantworten. Firmen-Blog, Landingpages, Kampagnen-Microsites, das von einer Agentur betreute Portal – digitale Assets wachsen dezentral und geraten aus dem Blick. Ohne ein gepflegtes Asset-Inventar wird jede Schwachstellenmeldung zur hektischen Suche. Die Parallele zum Shadow-AI-Problem ist offensichtlich: Was nicht inventarisiert ist, lässt sich nicht steuern.

2. Patch- und Schwachstellenmanagement als Prozess

Erzwungene Auto-Updates haben hier viele Seiten gerettet – aber sich darauf zu verlassen, ist keine Strategie, sondern Glück. Auto-Updates sind bei stark angepassten Installationen oft deaktiviert, aus Sorge vor Kompatibilitätsproblemen. Ein belastbares Patch-Management definiert im Vorfeld: Wer beobachtet Sicherheitsquellen wie die BSI-Warnungen? Innerhalb welcher Frist werden kritische Lücken eingespielt? Wer verifiziert den Erfolg? Ohne dokumentierten Prozess bleibt Reaktionsfähigkeit dem Zufall überlassen.

3. Meldepflichten: Wenn aus dem IT-Vorfall ein Rechtsthema wird

Hier wird die reine Technik zur Chefsache. Eine erfolgreiche RCE bedeutet, dass ein Angreifer den Server kontrolliert – und damit potenziell auf personenbezogene Daten zugreifen kann. Daraus können konkrete Pflichten entstehen:

• DSGVO-Meldepflicht (Art. 33): Bei einer Verletzung des Schutzes personenbezogener Daten ist die Aufsichtsbehörde in der Regel binnen 72 Stunden zu informieren. Die Uhr läuft ab Kenntnis – nicht ab Behebung.
• Benachrichtigung Betroffener (Art. 34): Bei hohem Risiko für die Betroffenen kommt deren direkte Information hinzu.
• NIS-2-Meldepflichten: Für Unternehmen im Anwendungsbereich der NIS-2-Richtlinie gelten zusätzliche, teils noch kürzere Meldefristen an das BSI.

Wer diese Pflichten erst im Schadensfall zum ersten Mal liest, verliert wertvolle Stunden. Ein vorbereiteter Incident-Response-Plan mit klaren Rollen und Eskalationswegen ist der Unterschied zwischen geordneter Reaktion und Chaos.

4. Lieferkette und Verantwortung: „Die Agentur macht das“ reicht nicht

Viele KMU lassen ihre Website von einer Agentur oder einem Freelancer betreuen. Das verlagert die technische Umsetzung – nicht aber die Verantwortung. Datenschutzrechtlich bleibt das Unternehmen der Verantwortliche. Ob der Dienstleister zeitnah patcht, ob es einen Auftragsverarbeitungsvertrag mit klaren Sicherheitspflichten oder gar einen Wartungsvertrag mit klar definierten Wartungsroutinen gibt oder ob im Ernstfall eine Meldekette funktioniert – das sind Fragen des Third-Party-Risk-Managements, die vor dem Vorfall geklärt sein müssen.

Die GRC-Kernaussage: wp2shell ist kein WordPress-Problem, sondern ein Governance-Thema. Die technische Lücke wird mit einem Klick geschlossen. Die eigentliche Frage ist, ob Ihr Unternehmen die Prozesse hat, um solche Lücken systematisch zu erkennen, zu bewerten, fristgerecht zu schließen und im Ernstfall korrekt zu melden. Genau das ist der Unterschied zwischen punktueller IT-Sicherheit und gelebtem Risikomanagement.

Eines ist garantiert: in Zeiten von KI-Agenten und autonom ausnutzbaren Sicherheitslücken wird uns das Thema in Zukunft noch dramatisch oft beschäftigen!

Handlungsempfehlung: Checkliste zum Vorfall

Kompakt zum Abhaken – so gehen Sie strukturiert mit wp2shell und ähnlichen Vorfällen um:

• Version prüfen: im Dashboard die installierte WordPress-Version verifizieren (Ziel: 7.0.2, 6.9.5 oder 6.8.6)
• Sofort patchen bzw. Auto-Update-Erfolg bestätigen, nicht nur annehmen
• Überbrückung, falls kein sofortiges Update möglich: REST-Batch-Route per WAF sperren
• Kompromittierung prüfen: Logs, neue Admin-Accounts, unbekannte Dateien und Cronjobs kontrollieren
• Asset-Inventar abgleichen: Welche weiteren WordPress-Instanzen (Microsites, Agentur-Projekte) betreiben wir?
• Dienstleister kontaktieren und Patch-Status der betreuten Seiten schriftlich bestätigen lassen
• Meldepflichten prüfen: bei Verdacht auf Datenabfluss DSGVO (Art. 33/34) und ggf. NIS-2 bewerten
• Patch-Prozess etablieren oder nachschärfen: Quellen, Fristen, Verantwortliche, Verifikation
• Incident-Response-Plan auf Aktualität prüfen (Rollen, Eskalation, Meldeketten)

Wie Elsen GRC Sie unterstützt

Ein einzelner Patch ist schnell eingespielt – ein belastbares Risikomanagement wächst nicht über Nacht. Elsen GRC hilft KMU, aus reaktivem Feuerlöschen einen gesteuerten Prozess zu machen, der in Zukunft seriöse und nachvollziehbare Reaktionen bei IT-Sicherheitsvorfällen ermöglicht.

• GRC- & Governance-Beratung: Aufbau von Asset-Inventar, Patch- und Schwachstellenmanagement sowie Incident-Response-Prozessen.
• Privacy QuickCheck: Schnelle Standortbestimmung zu Datenschutz, Meldepflichten und technisch-organisatorischen Maßnahmen (TOM).
• NIS-2- & DSGVO-Begleitung: Klärung Ihrer konkreten Meldepflichten und Aufbau der nötigen Nachweisdokumentation.

Häufige Fragen zu wp2shell (FAQ)

Bin ich betroffen, wenn ich nur einen kleinen Firmen-Blog betreibe?

Ja, potenziell. Die Lücke betrifft den WordPress-Kern selbst, unabhängig von Größe oder Plugins. Jede Installation in einer der betroffenen Versionen ist angreifbar – gerade automatisierte Angriffe machen keinen Unterschied zwischen groß und klein.

Reicht es, wenn Auto-Updates aktiviert sind?

In den meisten Fällen ja – aber verlassen sollten Sie sich nicht blind darauf. Prüfen Sie die tatsächlich installierte Version im Dashboard. Bei stark angepassten Installationen sind Auto-Updates häufig deaktiviert.

Muss ich den Vorfall den Behörden melden?

Das hängt davon ab, ob personenbezogene Daten betroffen sein könnten. Besteht dieser Verdacht, greift die DSGVO-Meldepflicht (Art. 33, in der Regel binnen 72 Stunden). Unternehmen im NIS-2-Anwendungsbereich haben zusätzliche Pflichten. Im Zweifel frühzeitig fachkundig bewerten lassen.

Meine Website wird von einer Agentur betreut – bin ich dann aus dem Schneider?

Technisch liegt die Umsetzung beim Dienstleister, die datenschutzrechtliche Verantwortung bleibt aber bei Ihnen. Lassen Sie sich den Patch-Status bestätigen und prüfen Sie, ob ein Auftragsverarbeitungsvertrag oder ein Wartungsvertrag mit klaren Sicherheits- und Meldepflichten besteht.

Falls Sie technische Unterstützung mit Ihrer WordPress-Website benötigen, können Sie unsere Webagentur Elsen Media kontaktieren.

---

Verwandte Themen

• NIS-2: Definition, Pflichten & Betroffenheit
• Shadow AI: Definition, Risiken & Maßnahmen
• Auftragsverarbeitungsvertrag (AVV): Definition & Pflichten

Quellen & Bild

• BSI: WordPress – Schwachstellen erlauben Remote Code Execution (Warnung, Stand 20.07.2026)
• WordPress.org: 7.0.2 Security Release
• Aikido Security: Unauthenticated RCE in WordPress core (wp2shell)
• heise online: wp2shell – Kritische WordPress-Lücke erlaubt Codeeinschleusung über API

Bild: Foto von Dima Pechurin auf Unsplash

Der Beitrag Kritische WordPress Sicherheitslücke wp2shell: Was Unternehmen jetzt tun müssen erschien zuerst auf ELSEN GRC.

Wer nicht weiß, welche KI-Systeme im Unternehmen überhaupt im Einsatz sind, kann weder ihre Risiken in Hinblick auf Recht und Regulatorik sowie hinsichtlich Cyber-Security bewerten, noch konkrete Risikostufen festlegen und damit nicht seinen Pflichten nach dem AI Act nachkommen. Diese Guideline erklärt, warum Sie bereits jetzt ein KI-Inventar erstellen sollten, was hineingehört, wie Sie es praktisch aufbauen und dauerhaft pflegen – und liefert am Ende eine kompakte Checkliste zum Abhaken. und natürlich auch eine kostenlose EXCEL-Vorlage für die KI-Inventarliste.

KI-Inventar erstellen: Was das ist – und warum jetzt

Ein KI-Inventar ist ein strukturiertes Verzeichnis aller Künstliche-Intelligenz-Systeme, die in einem Unternehmen entwickelt, eingekauft oder genutzt werden. Man kann es sich als das KI-Pendant zum Verzeichnis von Verarbeitungstätigkeiten (VVT) aus der DSGVO vorstellen: eine zentrale, gepflegte Übersicht, die auf Nachfrage einer Aufsichtsbehörde sofort vorzeigbar ist.

Der Grund für die neue Dringlichkeit liegt im gestaffelten Inkrafttreten des EU AI Act. Drei Punkte sind für KMU entscheidend:

• Die KI-Kompetenzpflicht gilt bereits: Seit dem 2. Februar 2025 verlangt Art. 4 KI-VO, dass Unternehmen für ausreichende KI-Kompetenz ihres Personals sorgen. Wer das nicht dokumentiert hat, ist streng genommen schon jetzt in der Pflichtverletzung.
• Ab dem 2. August 2026 wird die Verordnung weitgehend vollständig anwendbar: Dann greifen unter anderem die Transparenzpflichten nach Art. 50 – also die Kennzeichnung von Chatbots, KI-generierten Inhalten und Deepfakes.
• Die Hochrisiko-Fristen wurden verschoben: Mit der politischen Einigung zum „Digital Omnibus“ vom Mai 2026 rutschen die umfangreichen Pflichten für eigenständige Hochrisiko-Systeme (Anhang III) voraussichtlich auf Dezember 2027, für in Produkte eingebettete KI (Anhang I) sogar auf August 2028. Das verschafft Luft – macht das Inventar aber nicht weniger dringlich, denn ohne eine praxistaugliche Bestandsaufnahme weiß niemand, ob überhaupt ein Hochrisiko-System im Haus ist.

Warum gerade KMU ein KI-Inventar brauchen

Großkonzerne haben Compliance-Abteilungen, die solche Verzeichnisse (hoffentlich) ohnehin führen. Bei KMU ist die Ausgangslage eine andere – und paradoxerweise riskanter:

• Shadow AI wächst unbemerkt: In kleineren Unternehmen führen einzelne Mitarbeiter KI-Tools oft eigeninitiativ ein – ein ChatGPT-Konto hier, ein KI-Feature im CRM dort. Ohne Inventar entsteht eine Shadow-AI-Landschaft, die niemand vollständig überblickt.
• KI steckt längst in Standardsoftware: Viele KMU glauben, sie setzten „gar keine KI“ ein – dabei haben Microsoft 365 (Copilot), das E-Mail-Programm, die Buchhaltungssoftware oder das Bewerbermanagement längst KI-Funktionen integriert. Sogar die simplen Accounting-Lösungen für die Belegsortierung nutzen inzwischen KI-Werkzeuge zur Texterkennung. Auch diese zählen.
• Die Rolle entscheidet über die Pflichten: Der AI Act unterscheidet zwischen Anbietern, Betreibern, Importeuren und Händlern. Die meisten KMU sind Betreiber (Deployer) und haben damit reduzierte, aber reale Pflichten. Ohne Inventar lässt sich diese Rolle je System gar nicht bestimmen.
• KMU-Erleichterungen setzen Wissen voraus: Der AI Act sieht für kleinere Unternehmen vereinfachte Anforderungen vor – doch um sie zu nutzen, muss man erst wissen, welche Systeme man betreibt und wie sie einzustufen sind.

Was in ein KI-Inventar gehört

Ein brauchbares Inventar ist mehr als eine Namensliste. Pro erfasstem KI-System sollten mindestens die folgenden Angaben festgehalten werden. Die Tabelle zeigt die Kernfelder („Must-Haves“) mit einem kurzen exemplarischen Praxis-Beispiel:

Die beiden Felder Rolle und Risikoklasse sind das Herzstück: Aus ihnen leiten sich sämtliche weiteren Pflichten ab. Sie lassen sich aber erst sinnvoll ausfüllen, wenn die Grunddaten stehen – deshalb ist die Reihenfolge wichtig.

KI-Inventar erstellen in vier Schritten

Ein KI-Inventar erstellen Sie nicht mit einem Klick, aber der Aufbau des KI-Inventars muss nicht kompliziert sein. Für die meisten KMU reicht zu Beginn eine strukturierte Tabelle (Excel, CSV oder ein einfaches Tool). Entscheidend ist das systematische Vorgehen: Bestandsaufnahme, Rolle und Kontext bestimmen, Risikoklassifizierung durchführen, Maßnahmen ableiten.

Schritt 1: Bestandsaufnahme (Discovery)

Erfassen Sie alle KI-Systeme – und suchen Sie aktiv nach den versteckten „Schattensystemen“. Gehen Sie dazu Abteilung für Abteilung vor und prüfen Sie sowohl offensichtliche KI-Tools als auch KI-Funktionen in bestehender Standardsoftware sowie die echte, reale Nutzung Ihrer Mitarbeiter. Ein kurzer Fragebogen an die Teamleitungen („Welche digitalen Werkzeuge nutzt ihr, die Texte, Bilder, Vorschläge oder Auswertungen automatisch erzeugen?“) fördert erfahrungsgemäß mehr zutage als eine reine IT-Abfrage.

Schritt 2: Rolle und Kontext bestimmen

Klären Sie für jedes System Ihre Rolle nach dem AI Act. In den allermeisten Fällen sind KMU Betreiber – sie setzen fremde KI ein, entwickeln sie aber nicht selbst. Wer jedoch ein zugekauftes System wesentlich verändert oder unter eigenem Namen weitervertreibt, kann zum Anbieter mit deutlich höheren Pflichten werden. Das trifft insbesondere auf Software-Anbieter oder SaaS-Startups zu.

Schritt 3: Risikoklassifizierung

Ordnen Sie jedes System einer der vier Risikoklassen zu: minimal, begrenzt (Transparenzpflicht), hoch oder inakzeptabel (verboten). Prüfen Sie insbesondere, ob ein Anwendungsfall unter die Hochrisiko-Bereiche des Anhang III fällt (etwa Biometrie, Personalauswahl, Bonitätsprüfung). Wichtig: Auch das Ergebnis „nicht hochriskant“ sollte dokumentiert und begründet werden – der AI Act verlangt in bestimmten Fällen eine schriftliche Begründung, die idealerweise direkt notiert wird.

Schritt 4: Maßnahmen ableiten

Aus Rolle und Risikoklasse ergeben sich die konkreten To-dos: Transparenzhinweise ergänzen, AVV nachfordern, Schulungen ansetzen, Dokumentation aufbauen. Halten Sie diese Maßnahmen samt Verantwortlichkeit und Frist direkt im Inventar oder in einer verknüpften Maßnahmenliste fest.

KI-Inventar mit Software erstellen

Wer die Erfassung, Pflege und Überwachung seiner eingesetzten KI-Systeme vereinfachen und die Erinnerungen automatisieren möchte, kann auf maßgeschneiderte Software-Lösungen zur KI-Inventarisierung zurückgreifen. ElsenGRC hat eine spezielle KI-Inventarsoftware entwickelt, die neben Erfassung und Risikoeinstufung auch den rechtskonformen Export im Falle einer behördlichen Prüfung ermöglicht. Sprechen Sie uns gerne an!

Es existieren maßgeschneiderte Software-Lösungen für die Erstellung von KI-Inventarlisten. Unsere ElsenGRC App bietet eine komfortable Funktionen zum Erfassen und Pflegen der KI-Systeme.

KI-Inventar pflegen: Wenn aus Dokumentation ein Prozess wird

Der häufigste Fehler ist, das KI-Inventar einmal zu erstellen und dann im Laufwerks-Nirvana der internen Unternehmens-Cloud verschwinden zu lassen. Ein Inventar ist nur so viel wert wie seine Aktualität – und die KI-Landschaft eines Unternehmens verändert sich schnell. Damit aus dem Dokument ein lebendiger Prozess wird, haben sich drei Routinen bewährt:

• Feste Review-Zyklen: Legen Sie einen regelmäßigen Turnus fest (etwa quartalsweise), in dem das Inventar auf neue Systeme, geänderte Nutzung und ausgelaufene Tools geprüft wird.
• Inventar in den Beschaffungsprozess einbauen: Jedes neue Tool mit KI-Funktion wird vor der Einführung ins Inventar aufgenommen und klassifiziert. So entsteht Shadow AI gar nicht erst und die Geschäftsleitung kann auch wieder ruhig schlafen.
• Klare Verantwortlichkeit: Benennen Sie eine Person (KI-Beauftragter oder Compliance-Owner), die das Inventar führt. Ohne festen Verantwortlichen verwaist jedes Verzeichnis.

Wer diese Routinen mit der ohnehin fälligen KI-Kompetenzschulung und der DSGVO-Dokumentation verzahnt, spart Doppelarbeit – denn viele Felder (Anbieter, Datenkategorien, AVV-Status) überschneiden sich mit dem Verarbeitungsverzeichnis und können teilweise nahtlos übernommen werden.

Häufige Fehler beim KI-Inventar

• Nur die „offensichtliche“ KI erfassen: ChatGPT wird notiert, der KI-Filter im Bewerbertool übersehen. Gerade die eingebettete KI in Standardsoftware ist der blinde Fleck. Hier macht sich genaues Hinsehen bezahlt!
• Die Risikoklassifizierung raten statt prüfen: „Wird schon minimal sein“ ist keine Bewertung. Anhang III gehört konkret durchgesehen – und das Ergebnis dokumentiert.
• Das Inventar von der Realität entkoppeln: Ein Verzeichnis, das nach der Ersterstellung nie wieder angefasst wird, ist im Ernstfall wertlos und sogar irreführend.
• Datenschutz und AI Act getrennt behandeln: Beide hängen eng zusammen. Wer AVV-Status und Datenkategorien nicht miterfasst, muss später alles doppelt aufrollen.

Checkliste: KI-Inventar anlegen und pflegen

Kompakt zum Abhaken, Ausdrucken und Aufhängen – die zentralen Schritte für ein prüffestes KI-Inventar:

• Alle KI-Systeme abteilungsweise erfasst – inklusive eingebetteter KI in Standardsoftware
• Shadow AI aktiv aufgespürt (Team-Abfrage statt reiner IT-Sicht)
• Pro System die Kernfelder ausgefüllt (Anbieter, Zweck, Verantwortlicher, Datenkategorien)
• Rolle nach AI Act bestimmt (meist Betreiber/Deployer)
• Risikoklasse je System zugeordnet und die Bewertung dokumentiert
• Anhang-III-Prüfung durchgeführt (Hochrisiko-Bereiche gezielt geprüft)
• AVV-Status und Datenfluss je System vermerkt (Verzahnung mit DSGVO)
• Maßnahmen mit Verantwortlichkeit und Frist abgeleitet
• Fester Review-Turnus etabliert (z.B. quartalsweise)
• Verantwortliche Person für die Pflege benannt
• Inventar in den Beschaffungsprozess integriert (neue Tools vorab erfassen)

Die Checkliste gibt es auf Wunsch auch als PDF-Version zum Download:

• KI-Inventar erstellen: Kostenlose Checkliste (PDF, 1 Seite)

Natürlich gibt es unsere Vorlage zur KI-Inventarliste auch als kostenloses Muster im EXCEL-Format zum Download:

• KI-Inventarliste in EXCEL erstellen: Kostenlose Vorlage (EXCEL)

Wie Elsen GRC Sie unterstützt

Ein KI-Inventar ist der Einstieg in die AI-Act-Compliance – und selten der Endpunkt. Elsen GRC begleitet KMU auf dem gesamten Weg:

• AI Act Readiness Scan: Wir erstellen gemeinsam Ihr KI-Inventar, nehmen die Risikoklassifizierung vor und liefern eine Roadmap mit Blick auf die relevanten Fristen – so können Sie Ihr KI-Inventar erstellen lassen, statt es allein zu stemmen.
• KI-Kompetenzschulung nach Art. 4 EU AI Act: Erfüllt die gesetzliche Schulungspflicht – inklusive Mitarbeiter-Zertifikat, Schulungsregister und KI-Inventar-Vorlage.
• KI-Governance-Beratung: Vollständiges Governance-Framework mit Policies, Rollen und Freigabeprozessen – damit das Inventar dauerhaft gepflegt bleibt.
• KI-Inventar Software: Mit unserem Software-Angebot rund um die KI-Inventarisierung und Risikoeinstufung ermöglichen wir Ihnen die digitalisierte und automatisierte Erfassung und Überwachung Ihrer KI-Systeme.

So wird aus einer einmaligen Bestandsaufnahme ein gesteuerter, prüffester Bestandteil Ihrer GRC-Struktur.

Die häufigsten Fragen zum KI-Inventar (FAQ)

Ist ein KI-Inventar gesetzlich vorgeschrieben?

Der AI Act nennt kein „KI-Inventar“ als wörtliche Pflicht, setzt es aber faktisch voraus: Ohne vollständige Bestandsaufnahme lassen sich Risikoklassifizierung, Transparenz- und Dokumentationspflichten nicht rechtssicher erfüllen. Wer die Vorgaben erfüllen will, muss daher praktisch ein KI-Inventar erstellen – an einem strukturierten Verzeichnis führt kein Weg vorbei. Wer sich nicht mit Buntstiften und Karo-Papier bewaffnen will, sollte sich daher auch mit entsprechender Software für KI-Inventarisierung auseinandersetzen.

Zählt ChatGPT im Unternehmen als KI-System fürs Inventar?

Ja. Jedes eingesetzte KI-Tool gehört ins Inventar – auch allgemeine Assistenten wie ChatGPT, Claude oder Copilot sowie KI-Funktionen, die in vorhandener Software stecken. Unabhängig von der Dokumentation sollten Unternehmen aber darauf achten, dass Sie Claude sicher nutzen oder ChatGPT sicher nutzen.

Womit sollte man ein KI-Inventar erstellen – reicht Excel?

Für den Einstieg und kleinere Unternehmen ja: Sie können Ihr KI-Inventar mit einer Excel-Tabelle erstellen. Wichtig sind Struktur, Vollständigkeit und regelmäßige Pflege, nicht das Werkzeug. Mit wachsender Systemzahl kann später ein dediziertes Tool wie eine KI-Inventarsoftware sinnvoll werden.

Wer sollte das Inventar führen?

Eine klar benannte Person – etwa ein KI-Beauftragter oder Compliance-Owner – idealerweise in Abstimmung mit dem Datenschutzbeauftragten, da sich die Verzeichnisse inhaltlich stark überschneiden.

Wie oft muss das Inventar aktualisiert werden?

Ein fester Review-Turnus (häufig quartalsweise) plus anlassbezogene Updates bei jeder neuen KI-Einführung. Entscheidend ist, dass das Inventar den tatsächlichen Ist-Zustand abbildet.

Verwandte Themen

• EU AI Act: Definition, Bedeutung & Pflichten
• KI-Governance: Definition, Bedeutung & GRC-Relevanz
• Shadow AI: Definition, Risiken & Maßnahmen
• Risikoklassifizierung nach AI Act: Die vier Risikoklassen

Quellen

• EU-Kommission: Regulatory framework on AI
• EU AI Act: Implementation Timeline
• EU AI Act, Anhang III – Hochrisiko-KI-Systeme

Bild: Titelbild © Adrien Olichon auf Unsplash

Der Beitrag KI-Inventar erstellen und pflegen: Guideline nach EU AI Act erschien zuerst auf ELSEN GRC.

Geschäftsführung und IT hatten von dieser unbefugten ChatGPT-Nutzung im Unternehmen schließlich nur selten Kenntnis, was zum „Wildwuchs“ der KI-Tools und damit zum Entstehen ganzer „Shadow-AI“ Landschaft in kleinen wie großen Unternehmen kräftig beigetragen hat.  Während es zunächst nur darum ging, dass Arbeitsinhalte wie Kundendaten, Produktinformationen oder betriebliche Interna in privaten ChatGPT-Accounts landeten, wurde mit zunehmender Integration weitere Tools wie OpenAI Codex auch die Frage nach Sicherheit und Governance rund um ChatGPT lauter. Wie Unternehmen und Mitarbeiter ChatGPT sicher nutzen können, ist Kernthema dieser Guideline, die sich auch mit weiteren Fragen beschäftigt:

Wie sicher ist ChatGPT und Codex? Welche OpenAI Pläne müssen KMU nutzen? Welche Sicherheitsrisiken müssen berücksichtigt werden? Welche Verträge liegen der Nutzung zu Grunde?

Bleiben diese Fragen ungeklärt, drohen DSGVO-Verstöße, der ungewollte Abfluss von Betriebsgeheimnissen und Pflichtverletzungen nach dem EU AI Act. Diese Guideline sortiert die Nutzungsvarianten, arbeitet die datenschutzrechtlichen Unterschiede der OpenAI-Pläne heraus und schließt mit einer praxistauglichen Sicherheits-Checkliste – samt eigenem Abschnitt zum besonders heiklen Codex, dem agentischen Coding-Werkzeug von OpenAI.

Sicherheit von ChatGPT ist Chefsache

Die Verantwortung für die „compliant“ und sichere KI-Nutzung  sitzt im Regelfall weit oben: In der Geschäftsleitung bzw. im Management.  Dabei wirken drei Pflichtenkreise parallel, wenn man als Unternehmen ChatGPT sicher nutzen möchte:

• Datenschutz (DSGVO): In dem Moment, in dem personenbezogene Daten (etwa Namen, Adressen oder Kundendaten) in einen Prompt wandern, wird OpenAI zum Auftragsverarbeiter. Dafür braucht es einen Auftragsverarbeitungsvertrag (AVV/DPA) gemäß Art. 28 DSGVO – der bei privaten Consumer-Konten schlicht nicht existiert. Gibt ein Mitarbeiter Kundendaten in sein persönliches ChatGPT-Konto ein, ist damit das erste knackige Problem geboren.
• EU AI Act: Art. 4 der KI-Verordnung verlangt seit d. Februar 2025, dass Unternehmen für ausreichende KI-Kompetenz (AI Literacy) ihrer Belegschaft sorgen. Wer ChatGPT im Betrieb einsetzt, kommt an einer Schulung (Inhouse, Online oder auch außer Haus) nicht vorbei. Falls das bislang liegengeblieben ist: Unsere KI-Kompetenzschulung deckt genau diese Pflicht ab.
• Geschäftsgeheimnisschutz & Haftung: Ungesteuerte Tool-Nutzung – auf Deutsch Schatten-KI bzw. „Shadow AI“ – kann interne Betriebsgeheimnisse oder sogar Kundendaten in fremde Trainingsdaten spülen und die Sorgfaltspflichten der Geschäftsführung verletzen. Die wenigsten Arbeitsverträge sind auf ein solches Szenario überhaupt vorbereitet oder ausgelegt.

Die Nutzung von ChatGPT hat also zwei Perspektiven: Im Enterprise-Vertrag mit Zero Data Retention kann es ein compliancetaugliches Werkzeug sein, während es im privaten Plus-Konto eines Mitarbeiters ein meldepflichtiger Datenschutzvorfall sein könnte. Schauen wir uns die Nutzungsvarianten daher zuerst im Detail an.

Verfügbare Pläne für Privatpersonen und Unternehmen (Quelle: https://chatgpt.com/de-DE/pricing/)

Die Nutzungsvarianten von ChatGPT im Überblick

Für die Sicherheitsbewertung von ChatGPT kommt es auf drei Dimensionen an:

• Datenfluss: Was verlässt überhaupt das Unternehmen?
• Systemzugriff: kann das Tool lokale Dateien lesen oder Befehle ausführen?
• Vertrag: Consumer oder Business/Enterprise Terms?

Die folgende Tabelle stellt Nutzungsvariante, typische Anwendung und Sicherheitsrisiko kompakt gegenüber:

Ein häufiges Missverständnis hält sich hartnäckig: Die ChatGPT-App gilt als unbedenklich, Codex pauschal als gefährlich.

Datenschutzrechtlich führt diese Sichtweise in die Irre – denn ausschlaggebend ist nicht die Oberfläche, sondern der Vertrag und der rechtliche Rahmen dahinter. Ein privates Plus-Konto in der Web-App kann problematischer sein als ein API-Zugang unter Business-Terms, obwohl die API technisch weit mehr kann. Codex bringt durch seine tiefe Systemintegration zwar tatsächlich ein technisches Risiko mit – dieses lässt sich mit einem durchdachten Setup aber sehr gezielt eingrenzen, wie der eigene Abschnitt weiter unten zeigt.

Datenschutz & DSGVO: der entscheidende Unterschied zwischen den Plänen

OpenAI zieht eine klare Trennlinie zwischen zwei Vertragswelten – den Angeboten für Einzelpersonen (Consumer) und denen für Unternehmen (Business/Enterprise). An genau dieser Linie entscheidet sich, ob der Einsatz compliancetauglich ist oder nicht.

Enterprise Pläne von ChatGPT für Unternehmen bieten mehr vertragliche Sicherheit und Datenschutz

Einzelperson bzw. Consumer-Konten (Free, Plus, Pro)

Diese Pläne fallen unter die Consumer Terms – und dort ist die Voreinstellung eindeutig: Chats fließen standardmäßig in die Modellverbesserung, solange der Nutzer nicht aktiv widerspricht. Was das konkret bedeutet:

• Opt-out ist Pflicht, nicht Voreinstellung: Unter Einstellungen → Datensteuerung (Data Controls) → „Das Modell für alle verbessern“ muss der Schalter manuell auf Aus gestellt werden. Alternativ über das Privacy-Portal von OpenAI („Do not train on my content“).
• Aufbewahrung & Temporary Chat: Wer das Training deaktiviert, dessen neue Chats fließen nicht mehr ins Training. Der Temporary Chat erscheint nicht im Verlauf und wird nach 30 Tagen gelöscht – außer es bestehen Sicherheits- oder Rechtsgründe.
• Kein AVV: Für Consumer-Konten gibt es keinen Auftragsverarbeitungsvertrag. Damit fehlt die rechtliche Grundlage für die Verarbeitung personenbezogener Daten im Unternehmenskontext, die nach Art. 28 DSGVO notwendig ist.
• Wichtige Einschränkung: Das Opt-out wirkt nur in die Zukunft. Bereits für das Training verwendete Inhalte lassen sich nicht zurückholen. Zudem: Aufgrund eines laufenden Rechtsstreits (u.a. mit der New York Times) ist OpenAI derzeit gerichtlich verpflichtet, bestimmte Chat-Logs länger als üblich aufzubewahren – auch bei aktiviertem Opt-out oder gelöschten Chats. Ein Punkt, der für datensensible Unternehmen relevant ist (Stand Juni 2026).

Vorsicht bei der Team- bzw. Business-Umbenennung: OpenAI hat ChatGPT Team am 29. August 2025 in ChatGPT Business umbenannt. Business und Enterprise laufen unter Commercial Terms (kein Training standardmäßig). Im Zweifel den konkreten Vertragsstatus prüfen. Gerne beraten wir Sie bei der Auswahl des richtigen Plans.

Wer ChatGPT sicher nutzen will, muss die Modellverbesserung deaktivieren (Screenshot: ChatGPT)

Business-/Enterprise-Konten (ChatGPT Business, Enterprise, Edu, API)

Hier greifen geschäftliche Vertragsbedingungen – und die verschieben die Ausgangslage für Unternehmen grundlegend zum Positiven:

• Kein Training auf Ihren Daten: Inputs und Outputs von ChatGPT Business, Enterprise, Edu und der API werden standardmäßig nicht zur Modellverbesserung verwendet – ohne dass Sie etwas umstellen müssen. Nur ein ausdrückliches Opt-in ändert das.
• AVV/DPA verfügbar: OpenAI schließt für ChatGPT Business, Enterprise und die API einen Data Processing Addendum (DPA/AVV) ab und nutzt EU-Standardvertragsklauseln (SCC). Die aktualisierte DPA (Stand Jan. 2026) enthält zusätzliche Audit-Rechte.
• Zero Data Retention & konfigurierbare Aufbewahrung: Qualifizierende Organisationen können die Aufbewahrungsdauer konfigurieren und auf der API-Plattform eine Zero-Data-Retention-Regelung wählen. Der Goldstandard für sensible Branchen oder hoch brisante Unternehmensinformationen (Banken, Versicherungen, Medizintechnik, Gesundheitswesen, Rüstungsindustrie).
• Datenresidenz: Für berechtigte Enterprise-, Edu-, Healthcare- und API-Kunden lässt sich Content at rest (gespeicherte, ungenutzte Daten) in mehreren Regionen speichern (u.a. Europa, UK, USA); teils ist auch In-Region-Inferenz in Europa oder den USA möglich – relevant für Datensouveränität.
• Branchenspezifika: Für das Gesundheitswesen ist ChatGPT for Healthcare mit entsprechenden Vereinbarungen verfügbar. Standard-Consumer-ChatGPT ist nicht für sensible Gesundheitsdaten geeignet und erfordert gesonderte Vereinbarungen.

Codex sicher einsetzen: Ein Sonderfall mit eigenem Risiko

Codex ist als Agent ein Sonderfall für die Sicherheit von ChatGPT (Screenshot: ChatGPT Codex)

Codex gehört in einen eigenen Abschnitt, weil es mit der klassischen Chat-App kaum noch etwas gemein hat. Wir reden hier nicht über einen abgeschotteten Chatbot, sondern über einen Agenten mit echter Handlungsvollmacht, der direkt im Betriebssystem des Nutzers arbeitet: Er liest Quellcode, verändert Dateien, setzt Shell-Befehle ab und greift über das Model Context Protocol (MCP) sowie Connectors auf externe Werkzeuge zu – und das mit exakt den Rechten dessen, der ihn gestartet hat.

Daraus ergibt sich eine Angriffsfläche, die ein herkömmliches IDE-Plugin nie hatte. Immerhin: Codex trennt sauber zwischen Sandbox (was technisch überhaupt geht) und Approval Policy (wann nachgefragt wird), läuft lokal in der Grundeinstellung ohne Netzzugang und darf nur im aktuellen Arbeitsverzeichnis schreiben. Kritisch wird es dennoch, sobald jemand die Rechteverwaltung nicht sauber beherrscht oder den Full-Access-Modus außerhalb einer gekapselten Umgebung anwirft.

Die zentralen Risiken von Codex

• Dateizugriff: Sobald die Sandbox aufgeweicht wird, kann Codex an sensible Dateien gelangen – Umgebungsvariablen (.env), SSH-Schlüssel, hinterlegte Zugangsdaten. Immerhin bleiben .git-Pfade in der Standardkonfiguration schreibgeschützt. Änderungen sind hier aber möglich und eröffnen Sicherheitsrisiken.
• Befehlsausführung: Bash-Befehle laufen im Kontext der Entwickler-Shell – ein einziger fehlgeleiteter Befehl reicht, um Daten zu überschreiben oder zu löschen. Die Sandbox fängt das ab, aber eben nur, solange sie aktiv bleibt.
• Prompt Injection: Versteckte Anweisungen in Dateien, READMEs oder Paket-Metadaten können den Agenten kapern. Nicht ohne Grund zieht Codex Web-Suchergebnisse standardmäßig aus einem Cache statt live und behandelt sie als nicht vertrauenswürdig. Gerade öffentliche MCP-Packages, Libraries und sonstige Open-Source-Komponenten sind ein potenzielles Einfallstor für Schadcode.

Berechtigungsmodus: vom Vorsichtigen zum Riskanten

Codex verzahnt zwei Regler – den Sandbox-Modus und die Approval Policy. In der Grundeinstellung fragt es vor riskanten Aktionen nach. Diese Stufen sind entscheidend:

• Read-only (/permissions): Codex analysiert und schlägt vor, ohne etwas zu ändern. Der Plan-first-Ansatz (/plan) läuft hier. Die sicherste Methode, aber zeitintensiv und mit manueller Prüfung.
• Auto / workspace-write (–full-auto): Codex liest, editiert und führt Befehle im Arbeitsverzeichnis automatisch aus, fragt aber bei Aktionen außerhalb des Workspace oder bei Netzwerkzugriff nach. Guter Kompromiss für den Alltag – Netzwerk bleibt hier standardmäßig aus.
• Auto-Review: Ein Prüf-Subagent bewertet grenzüberschreitende Anfragen und genehmigt risikoarme Aktionen automatisch, statt den Nutzer bei jedem Schritt zu unterbrechen – die sicherere Mittellösung für längere autonome Läufe.
• –yolo / danger-full-access: Hebt Sandbox und Approvals komplett auf. Der Name ist eine bewusste Warnung und sollte niemals auf der lokalen Maschine ausgeführt werden! Nur in einer isolierten Sandbox / einem gehärteten Code-Runner oder isolierten Container.

Codex-Berechtigungen im Überblick:

Lokal vs. Container/VM: die Entscheidungslogik

An diesem Punkt fällt für technische Teams die wichtigste Sicherheitsentscheidung:

Faustregeln aus der Cybersecurity:

• Die Sandbox ist die Wand, die Approvals sind das Schloss an der Tür.
• Erst durch Isolation (Container/VM) lässt sich volle Autonomie verantworten – weil ein etwaiger Schaden auf den Container beschränkt bleibt.
• Praktische Maßnahmen: nur das eine Projektverzeichnis als Writable Root zulassen und das Netzwerk im workspace-write-Modus deaktiviert lassen bzw. den Egress auf eine Allowlist begrenzen.
• Secrets erst gar nicht in den Container geben, sondern parametrisiert einsteuern – in Codex Cloud werden sie ohnehin vor der Agent-Phase entfernt.

Enterprise-Kontrollen, die nicht umgangen werden können

Einzelne Approval-Abfragen ersetzen keine verbindliche Unternehmensvorgabe – sie hängen am Wohlverhalten des Einzelnen. Wer verlässliche Leitplanken will, setzt auf Managed Configuration (per requirements.toml, MDM oder cloud-managed), die sich nicht durch Projekt-Dateien aushebeln lässt.

Für einen sicheren Codex-Einsatz sollten insbesondere diese Punkte stehen:

• Least-Privilege-Permission-Profiles,
• Sperre von approval_policy = „never“ und danger-full-access außerhalb isolierter Umgebungen,
• Regeln (Rules) für erlaubte bzw. verbotene Befehls-Präfixe,
• genehmigte MCP-Server und Connectors,
• Agent-native Logs (Telemetrie) für Sichtbarkeit über alle Tool-Aufrufe.

Damit lässt sich Codex als effizientes, agentisches Tool in der KI-Entwicklung schon sehr sicher einsetzen.

ChatGPT sicher nutzen: Governance-Rahmen für Unternehmen

Mit technischen Einstellungen allein ist es nicht getan. Wer ChatGPT sicher nutzen will, braucht einen organisatorischen Rahmen mit konkreten Leitplanken – und der ist zugleich Pflicht nach dem AI Act:

• KI-Richtlinie (Policy): Schwarz auf weiß festhalten, welche Varianten und Pläne erlaubt sind, welche Daten in einen Prompt dürfen und wer die Freigabe erteilt.
• Freigabe- und Beschaffungsprozess: Dienstliches läuft nicht über private Konten. Wer Business-/Enterprise-/API-Zugänge zentral bereitstellt, nimmt Shadow AI den Nährboden.
• KI-Inventar: Aufnehmen, welche KI-Systeme tatsächlich im Einsatz sind – auch die stillen Zuwächse wie Custom GPTs und Connectors. Dieses Inventar ist zugleich die Basis für die Risikoklassifizierung nach AI Act.
• Mitarbeiterschulung (Art. 4 EU AI Act): Seit Februar 2025 Pflicht. Die Belegschaft muss verstehen, wie KI funktioniert, Halluzinationen erkennen und die internen Spielregeln kennen.
• Audit & Review: Turnusmäßig prüfen, ob Einstellungen (Training-Opt-out, Plan-Status, Konten, Connectors) noch stimmen – und alte Konversationen bereinigen.

Zu viel für den ohnehin vollen Schreibtisch? Verständlich, genau deshalb begleiten wir Unternehmen im Rahmen der KI-Governance Beratung bei allen relevanten Fragen rund um die Vorbereitung auf den EU AI Act. Buchen Sie einfach ein Erstgespräch, und wir setzen diese Leitplanken gemeinsam in Ihrem Unternehmen um.

Sicherheits-Checkliste: ChatGPT im Unternehmen

Die wichtigsten Key-Takeaways für den sicheren ChatGPT-Einsatz zum Mitnehmen, teilen und überprüfen:

• Nur Business-/Enterprise-Verträge oder die API für dienstliche Nutzung – keine privaten Plus-Konten (!!!)
• AVV/DPA mit OpenAI abgeschlossen
• Bei hohem Schutzbedarf: Zero Data Retention (API) bzw. konfigurierte Aufbewahrung aktiviert
• Auf verbliebenen Consumer-Konten: Training-Opt-out geprüft und dokumentiert (inkl. Feedback-Regel)
• KI-Richtlinie verabschiedet und kommuniziert
• KI-Inventar erstellt, Shadow-AI-Konten, Custom GPTs und Connectors identifiziert
• Art.-4-Schulung durchgeführt und dokumentiert
• Codex nur mit aktiver Sandbox / im Container/VM mit Secret-Sperren und Egress-Kontrolle betrieben
• Full-Access-Modus (–yolo) außerhalb der Sandbox gesperrt
• Audit-Logging und regelmäßige Reviews etabliert

Die Checkliste gibt es natürlich auch noch als PDF-Version zum Download und Ausdrucken für die Lobby:

• ChatGPT sicher nutzen: Checkliste (PDF, 1 Seite)

Wie Elsen GRC Sie unterstützt

Sicherer ChatGPT-Einsatz trifft genau den Schnittpunkt aus Datenschutz, KI-Governance und AI-Act-Compliance – das Feld, in dem Elsen GRC zu Hause ist:

• KI-Kompetenzschulung nach Art. 4 EU AI Act: Erfüllt die gesetzliche Schulungspflicht – inklusive Mitarbeiter-Zertifikat, Schulungsregister und KI-Richtlinien-Entwurf.
• AI Act Readiness Scan: KI-Inventar, Risikoklassifizierung und Roadmap mit Blick auf die AI Act Fristen bis August 2026.
• KI-Governance-Beratung: Vollständiges Governance-Framework mit Policies, Rollen und Freigabeprozessen für den kontrollierten KI-Einsatz.

So wird aus einem bislang ungesteuerten Tool ein kontrollierter, prüffester Baustein Ihrer GRC-Struktur und eine effiziente und sichere KI-Nutzung im Tagesgeschäft.

Ein paar weitere Fragen zur ChatGPT-Sicherheit im Überblick (FAQ)

Ist ChatGPT DSGVO-konform nutzbar?

Ja – allerdings nur unter Business-/Enterprise-Terms oder über die API, jeweils mit abgeschlossenem DPA/AVV. Private Consumer-Konten (Free, Plus, Pro) bieten keinen AVV und speisen Daten standardmäßig ins Training, solange niemand aktiv widerspricht.

Werden meine Chats zum Training von ChatGPT verwendet?

In Consumer-Konten per Voreinstellung ja, bis man aktiv widerspricht. In Business-, Enterprise- und API-Konten grundsätzlich nicht. Aufpassen bei Feedback: Eine Daumen-Bewertung kann die betroffene Konversation trotz Opt-out ins Training holen.

Reicht der Business-Plan für Unternehmen?

ChatGPT Business (früher Team) läuft bereits geschäftlich – mit DPA-Option und ohne Training. Für die weitreichendsten Kontrollen wie Datenresidenz oder erweiterte Admin-Funktionen führt der Weg zu Enterprise oder zur API.

Warum ist Codex riskanter und nicht so sicher wie die App?

Weil Codex mit den Rechten des Nutzers auf das Dateisystem zugreift und Befehle ausführt. Deshalb gehört es mit aktiver Sandbox, in einen Container oder eine VM – und nicht in den Full-Access-Modus auf dem lokalen Rechner.

Was ist Zero Data Retention?

Eine Option für qualifizierende Kunden auf der API-Plattform, bei der Daten über die unmittelbare Verarbeitung hinaus nicht gespeichert werden – der höchste Datenschutzstandard, ganz ohne eigene Infrastruktur.

Verwandte Themen

• Claude sicher nutzen: Guideline für Unternehmen
• EU AI Act: Definition, Bedeutung & Pflichten
• KI-Governance: Definition, Bedeutung & GRC-Relevanz
• Shadow AI: Definition, Risiken & Maßnahmen

Quellen

• OpenAI: Enterprise Privacy
• OpenAI Help Center: Data Controls FAQ
• OpenAI: Business data privacy, security & compliance
• OpenAI Developers: Codex Agent approvals & security

Der Beitrag ChatGPT sicher nutzen: Guide für mehr Sicherheit bei Codex und CustomGPTs erschien zuerst auf ELSEN GRC.

Sicherheit von Claude ist Chefsache

Die Verantwortung für den KI-Einsatz liegt nicht in der Fachabteilung, sondern bei der Leitung. Drei Pflichtenkreise greifen gleichzeitig ineinander:

• Datenschutz (DSGVO): Sobald personenbezogene Daten (z.B. Namen und Adressen von Personen) in einen Prompt gelangen, ist Anthropic Auftragsverarbeiter. Das setzt einen Auftragsverarbeitungsvertrag (AVV/DPA) voraus – den es bei privaten Consumer-Konten nicht gibt. Wenn der Mitarbeiter also Kundendaten in sein persönliches Claude-Konto überführt, entsteht das erste knackige Problem.
• EU AI Act: Seit Februar 2025 verpflichtet Art. 4 KI-VO Unternehmen, für ausreichende KI-Kompetenz der Mitarbeitenden zu sorgen. Wer Claude einsetzt, muss die Belegschaft schulen. Wer das bisher versäumt hat, kann auch gerne unsere KI-Kompetenzschulung in Anspruch nehmen.
• Geschäftsgeheimnisschutz & Haftung: Unkontrollierte Tool-Nutzung,  zu deutsch: Schatten-KI bzw. „Shadow AI“, kann Betriebsgeheimnisse in Trainingsdaten überführen und die Sorgfaltspflichten der Geschäftsleitung verletzen. Auch die meisten Arbeitsverträge von Mitarbeitern sind auf dieses Szenario längst nicht vorbereitet.

Die zentrale Erkenntnis vorweg: Nicht Claude selbst ist das Risiko, sondern die gewählte Nutzungsvariante und der zugrunde liegende Vertrag.  Erst in der zweiten Ebene kommen zusätzliche Risiken durch die technische Integration auf dem Endgerät (z.B. Claude Code oder Claude Cowork) zum Tragen.

Dieselbe Technologie ist in einem Enterprise-Vertrag mit Zero Data Retention compliancetauglich und im privaten Pro-Konto eines Mitarbeiters ein kritischer Datenschutzvorfall in Lauerstellung. Werfen wir also zunächst einen Blick auf die Nutzungsvarianten von Claude.

Die Nutzungsvarianten von Claude im Überblick

Claude lässt sich auf sehr unterschiedlichen Wegen einsetzen. Entscheidend für die Sicherheit sind drei Dimensionen:

• der Datenfluss (was verlässt das Unternehmen?),
• der Systemzugriff (kann das Tool Dateien lesen oder Befehle ausführen?) und
• der Vertrag (Consumer oder Commercial Terms?).

Die nachfolgende Tabelle gibt einen kompakten Überblick über Nutzungsvariante, Anwendung und Sicherheitsrisiko für Claude:

Ein verbreiteter Irrtum: Die Claude-App sei „harmlos“ und Claude Code per se ein „hohes Sicherheitsrisiko“.

In der Praxis entscheidet beim Datenschutz nicht die Oberfläche, sondern der Vertrag und die rechtlichen Rahmbedingungen. Eine Web-App unter einem privaten Pro-Konto ist riskanter als die API unter Commercial Terms, obwohl die API technisch mächtiger ist. Die Nutzung von Claude Code ist durch die direkte Systemintegration natürlich grundsätzlich ein technisches Sicherheitrisiko, das im Rahmen eines durchdachten Setups aber aktiv eingegrenzt werden kann.

Datenschutz & DSGVO: der entscheidende Unterschied zwischen den Plänen

Anthropic trennt seine Angebote in zwei vertragliche Welten : Einzelpersonen (Consumer) und Enterprise (oder Team-Konten). Genau hier entscheidet sich die Compliance-Tauglichkeit.

Nutzungsvarianten und Pläne von Claude (© Claude.ai)

Einzelperson bzw. Consumer-Konten (Free, Pro, Max)

Diese Pläne laufen unter den Consumer Terms. Seit der Richtlinienänderung im Herbst 2025 werden Chats und Coding-Sessions standardmäßig zur Modellverbesserung genutzt – es sei denn, der Nutzer widerspricht aktiv. Konkret bedeutet das:

• Opt-out ist Pflicht, nicht Voreinstellung: Unter Einstellungen → Datenschutz → „Claude für alle verbessern“ bzw. „Hilf uns, unsere KI-Modelle zu verbessern“ muss der Schalter manuell auf Aus gestellt werden.
• Verlängerte Speicherung: Mit aktiviertem Training steigt die Datenaufbewahrung auf bis zu fünf Jahre. Wer widerspricht, bleibt nach aktuellem Stand bei 30 Tagen (Juni 2026).
• Kein AVV: Für Consumer-Konten gibt es keinen Auftragsverarbeitungsvertrag . damit fehlt die rechtliche Grundlage für die Verarbeitung personenbezogener Daten im Unternehmenskontext, die nach Art. 28 DSGVO notwendig ist.
• Wichtige Einschränkung: Das Opt-out wirkt nur in die Zukunft. Bereits für das Training verwendete Inhalte lassen sich nicht zurückholen. Zudem können sicherheitsmarkierte Konversationen unabhängig von der Einstellung weiter ausgewertet werden.

Wer Claude sicher nutzen will, muss diese zentrale Einstellung für die Modellverbesserung kennen. (© Claude.ai)

Vorsicht beim Team-Plan: Trotz des Namens läuft der reine Claude-Team-Plan in wesentlichen Teilen weiterhin unter Consumer-Logik. Erst Enterprise liefert die volle vertragliche Absicherung. Im Zweifel den konkreten Vertragsstatus prüfen. Gerne beraten wir Sie bei der Auswahl des richtigen Plans über unsere Claude Code Beratungsleistung.

Commercial-Konten (Claude for Work / Enterprise, API, Bedrock, Vertex AI)

Claude Enterprise / Commercial Plans (© claude.ai)

Wie der Name schon verrät, laufen diese Konten unter den Commercial Terms, was für Unternehmen und Mitarbeiter den entscheidenden Unterschied macht:

• Kein Training auf Ihren Daten: Inputs und Outputs werden standardmäßig nicht zur Modellverbesserung verwendet – ohne dass Sie etwas umstellen müssen.
• AVV/DPA verfügbar: Anthropic stellt einen Auftragsverarbeitungsvertrag (AVV) bereit und nutzt EU-Standardvertragsklauseln (SCC) für Datenübermittlungen.
• Kürzere API-Aufbewahrung: Die Standard-Aufbewahrung der API liegt bei nur 7 Tagen, was deutlich strenger als die meisten Wettbewerber. Auf Wunsch per DPA (Data Processing Agreement) auf 30 Tage erweiterbar.
• Zero Data Retention (ZDR): Für qualifizierende Enterprise-Kunden verfügbar. Daten werden über die unmittelbare Verarbeitung hinaus gar nicht gespeichert. Der Goldstandard für sensible Branchen oder hoch brisante Unternehmensinformationen, wie sie in Banken, Versicherungen, Medizintechnik, Gesundheitswesen oder Rüstungsindustrie vorkommen.
• Branchenspezifika: Für das Gesundheitswesen ist ein Business Associate Agreement (BAA) verfügbar, Standard-Consumer-Claude ist nicht HIPAA-konform und darf nicht mit Gesundheitsdaten genutzt werden. Daher erfordert es hier gesonderter Vereinbarungen.

Claude Code sicher einsetzen: Ein Sonderfall mit eigenem Risiko

Das KI-Werkzeug Claude Code verdient einen eigenen Abschnitt, weil es sich grundlegend von der Chat-App unterscheidet. Es ist kein abgeschotteter Chatbot, sondern ein Agent mit echter Entwicklungs-Autorität, das als direkte Integration im Betriebssystem eines Nutzers laufen kann: Es liest Quellcode, ändert Dateien, führt Shell-Befehle aus und kann externe Werkzeuge über das Model Context Protocol (MCP) ansprechen und nutzen – und zwar mit denselben Rechten wie der Nutzer, der es startet.

Damit entsteht eine Angriffsfläche, die klassische IDE-Plugins nie hatten. Denn Claude Code kann insbesondere im „Auto mode“ erhebliche Sicherheitsrisiken mit sich bringen, wenn ein Nutzer keine adäquate Rechteverwaltung beherrscht oder Claude Code als abgeschotteter Agent z.B. in einer isolierten Container-Umgebung läuft.

Claude Code ist ein Sonderfall mit eigenen Risiko-Klassen und kann direkt im Terminal mit User-Rechten laufen

Die zentralen Risiken

• Dateizugriff: Ohne Sperren kann Claude Code sensible Dateien wie Umgebungsvariablen (.env), SSH-Schlüssel und Zugangsdaten lesen.
• Befehlsausführung: Der Agent führt Bash-Befehle im Kontext der Entwickler-Shell aus, ein fehlgeleiteter Befehl kann Daten komplett löschen oder überschreiben.
• Prompt Injection: In Dateien, READMEs oder Paket-Metadaten versteckte Anweisungen können den Agenten manipulieren. Sicherheitsforscher haben gezeigt, dass repository-gesteuerte Hooks und MCP-Konfigurationen zu Befehlsausführung oder Schlüsselabfluss führen können. Öffentlich verfügbare MCP-Packages, Libraries oder andere Open-Source Komponenten können hier ein erhebliches Einfallstor für schadhaften Code und böswillige Software sein.

Berechtigungsmodus: vom Vorsichtigen zum Riskanten

Claude Code folgt einem „ask before act“-Prinzip. Standardmäßig fragt es vor jeder relevanten Aktion nach. Drei Stufen sind relevant:

• Plan-/Standardmodus: Claude schlägt Änderungen vor, führt sie aber erst nach Freigabe aus. Für sensible Repositories die richtige Wahl. Die sicherste Methode, wenn ein Nutzer weiß, worauf er achten muss. Allerdings ist diese Methode zeitfressend und erfordert manuelle Prüfung der generierten Code-Artefakte.
• Accept-Edits / Allowlist: Vertraute Befehle (z. B. npm run test) werden vorab freigegeben, der Rest fragt weiter nach. Guter Kompromiss für den Alltag. Kostet aber deutlich mehr Zeit in der Entwicklung von Software.
• Auto-Mode: Vor jedem Tool-Aufruf prüft ein Klassifikator die Aktion auf potenziell destruktive Vorgänge wie Massenlöschungen, Exfiltration sensibler Daten oder Ausführung schädlichen Codes. Als sicher eingestufte Aktionen laufen automatisch, riskante werden geblockt und Claude auf einen anderen Weg umgeleitet; besteht Claude wiederholt auf einer geblockten Aktion, wird schließlich doch eine Rückfrage an den Nutzer ausgelöst.
• –dangerously-skip-permissions: Hebt alle Sicherheitsabfragen auf. Der Name ist eine bewusste Warnung. Niemals auf der lokalen Maschine! Diese Permission  sollte nur in einer isolierten Sandbox / Container laufen.

Claude Code Berechtigungen im Überblick:

Lokal vs. Container/VM: die Entscheidungslogik

Hier liegt die wichtigste Sicherheitsentscheidung für technische Teams:

Faustregeln aus der Cybersecurity:

• Die Sandbox ist die Wand, die Berechtigungen sind das Schloss an der Tür.
• Erst die Isolation (Container/VM) macht die volle Autonomie verantwortbar, weil der maximale Schaden auf den Container begrenzt bleibt.
• Konkrete Schutzmaßnahmen im Container: nur das eine Projektverzeichnis mounten, Egress auf eine Allowlist beschränken (Anthropic-API, nötige Paket-Registries)
• Secrets gar nicht erst in den Container lassen, sondern parametrisiert einsteuern

Enterprise-Kontrollen, die nicht umgangen werden können

Einzelne Berechtigungsabfragen sind keine Unternehmenspolitik. Für durchsetzbare Vorgaben nutzen Organisationen Managed Settings (per MDM oder server-seitig ausgeliefert, nicht durch Repository-Dateien überschreibbar).

Wer Claude Code sicher nutzen will, sollte ein paar zentrale Faktoren berücksichtigen und sicherstellen:

• Least-Privilege-Berechtigungen,
• Deny-Regeln für Secret-Dateien und Hochrisiko-Befehle,
• Sperre von –dangerously-skip-permissions außerhalb isolierter Container,
• genehmigte MCP-Server,
• Audit-Logging via OpenTelemetry und ein
• LLM-Proxy für Sichtbarkeit über alle Tool-Aufrufe.

Damit lässt sich Claude Code als effizientes, agentisches Tool in der KI-Entwicklung schon sehr sicher einsetzen.

Claude sicher nutzen: Governance-Rahmen für Unternehmen

Technische Einstellungen allein genügen nicht. Sicherer Claude-Einsatz braucht einen organisatorischen Rahmen (Leitplanken) und der ist zugleich AI-Act-Pflicht:

• KI-Richtlinie (Policy): Schriftlich regeln, welche Varianten und Pläne erlaubt sind, welche Daten eingegeben werden dürfen und wer freigibt.
• Freigabe- und Beschaffungsprozess: Keine privaten Konten für dienstliche Zwecke. Zentrale Bereitstellung von Enterprise-/API-Zugängen verhindert Shadow AI.
• KI-Inventar: Erfassen, welche KI-Systeme im Einsatz sind – inklusive der unbemerkt gewachsenen. Das ist zugleich die Grundlage für die Risikoklassifizierung nach AI Act.
• Mitarbeiterschulung (Art. 4 EU AI Act): Seit Februar 2025 verpflichtend. Die Belegschaft muss KI verstehen, Halluzinationen erkennen und die internen Regeln kennen.
• Audit & Review: Regelmäßige Prüfung der Einstellungen (Training-Opt-out, Plan-Status, Konten) und Bereinigung alter Konversationen.

Das Thema ist für Ihren Schreibtisch zu komplex? Kein Problem – Elsen GRC berät Unternehmen im Rahmen der KI-Governance Beratung zu den relevanten Aspekten rund um die Vorbereitung auf den EU AI Act. Einfach ein Erstgespräch buchen und wir kümmern uns um die Umsetzung dieser Leitplanken in Ihrem Unternehmen.

Sicherheits-Checkliste: Claude im Unternehmen

Kompakt zusammengefasst – die zentralen Punkte für den sicheren Claude-Einsatz im Unternehmen:

• Nur Commercial-Verträge (Enterprise/API) für dienstliche Nutzung – keine privaten Pro-Konten!
• AVV/DPA mit Anthropic abgeschlossen
• Bei hohem Schutzbedarf: Zero Data Retention aktiviert
• Auf verbliebenen Consumer-Konten: Training-Opt-out geprüft und dokumentiert
• KI-Richtlinie verabschiedet und kommuniziert
• KI-Inventar erstellt, Shadow-AI-Konten identifiziert
• Art.-4-Schulung durchgeführt und dokumentiert
• Claude Code nur im Container/VM mit Secret-Sperren und Egress-Allowlist betrieben
• Autonomer Modus ohne Sicherheitsabfragen außerhalb der Sandbox gesperrt
• Audit-Logging und regelmäßige Reviews etabliert

Die Checkliste gibt es natürlich auch noch als PDF Version zum Download:

• Claude sicher nutzen Checkliste (PDF, 1 Seite)

Wie Elsen GRC Sie unterstützt

Der sichere Einsatz von Claude berührt genau die Schnittstelle von Datenschutz, KI-Governance und AI-Act-Compliance, auf die Elsen GRC spezialisiert ist:

• KI-Kompetenzschulung nach Art. 4 EU AI Act: Erfüllt die gesetzliche Schulungspflicht – inklusive Mitarbeiter-Zertifikat, Schulungsregister und KI-Richtlinien-Entwurf.
• AI Act Readiness Scan: KI-Inventar, Risikoklassifizierung und Roadmap mit Blick auf die AI Act Fristen bis August 2026.
• KI-Governance-Beratung: Vollständiges Governance-Framework mit Policies, Rollen und Freigabeprozessen für den kontrollierten KI-Einsatz.

So wird aus einem unkontrollierten Tool ein gesteuerter, prüffester Bestandteil Ihrer GRC-Struktur.

Ein paar häufige Fragen zur Claude Sicherheit im Überblick (FAQ)

Ist Claude DSGVO-konform nutzbar?

Ja -aber nur unter Commercial Terms (Enterprise oder API) mit abgeschlossenem AVV. Private Consumer-Konten (Free, Pro, Max) bieten keinen AVV und nutzen Daten standardmäßig zum Training, wenn nicht aktiv widersprochen wird.

Werden meine Chats zum Training von Claude verwendet?

Bei Consumer-Konten standardmäßig ja, solange nicht widersprochen wird. Bei Commercial-Konten (Enterprise, API) standardmäßig nein.

Reicht der Team-Plan für Unternehmen?

Der Team-Plan läuft in wesentlichen Teilen unter Consumer-Logik. Für volle vertragliche Absicherung mit AVV und Trainings-Ausschluss ist Enterprise oder die API erforderlich.

Warum ist Claude Code riskanter und nicht so sicher wie die App?

Weil Claude Code mit den vollen Rechten des Nutzers auf das Dateisystem zugreift und Befehle ausführt. Es sollte deshalb in einem Container oder einer VM betrieben werden – nicht ungeschützt auf dem lokalen Gerät.

Was ist Zero Data Retention?

Ein Modus für qualifizierende Enterprise-Kunden, bei dem Daten über die unmittelbare Verarbeitung hinaus nicht gespeichert werden – der höchste Datenschutzstandard ohne eigene Infrastruktur.

Verwandte Themen

• ChatGPT sicher nutzen: Guideline für Sicherheit bei OpenAI ChatGPT und Codex
• EU AI Act: Definition, Bedeutung & Pflichten
• KI-Governance: Definition, Bedeutung & GRC-Relevanz
• Shadow AI: Definition, Risiken & Maßnahmen

Quellen & Bilder

Bilder: Screenshots, © Claude.ai

• Anthropic: Updates to Consumer Terms and Privacy Policy
• Anthropic Privacy Center: Is my data used for model training?
• Claude Code Docs: Development containers / Security

Der Beitrag Claude sicher nutzen: Guideline für Claude Code, Cowork und die Claude Desktop App erschien zuerst auf ELSEN GRC.

Executive Summary: US-Regierung erzwingt Abschaltung von Claude Fable 5 und Mythos 5 – was Unternehmen daraus lernen müssen

Nur drei Tage nach dem Launch seiner bislang leistungsfähigsten KI-Modelle musste Anthropic die Systeme Claude Fable 5 und Claude Mythos 5 am 12. Juni 2026 weltweit abschalten. Auslöser ist nach Darstellung des Unternehmens eine Exportkontrolldirektive der US-Regierung, die jeglichen Zugriff durch ausländische Staatsangehörige untersagt – innerhalb wie außerhalb der USA und sogar für eigene Mitarbeiter ohne US-Staatsbürgerschaft. Da eine Filterung auf Nutzerebene nicht kurzfristig umsetzbar war, blieb nur die vollständige globale Deaktivierung beider Modelle. Anthropic bezeichnet die Maßnahme als „Missverständnis“ und verweist auf einen lediglich engen, nicht-universellen Jailbreak. Aus Sicht von Governance, Risk & Compliance (GRC) ist der Fall ein Lehrstück: Er zeigt, wie geopolitische und exportrechtliche Risiken binnen Stunden zu einem Ausfall geschäftskritischer KI-Dienste führen können – und warum Modell-Abhängigkeit ein eigenständiges Compliance-Risiko ist.

Der Vorgang um Claude Fable 5 und Mythos 5 ist dabei kein gewöhnlicher Produktausfall. Er führt vor Augen, dass leistungsfähige KI-Modelle inzwischen im Spannungsfeld von Außenwirtschaftsrecht, nationaler Sicherheit und kommerzieller Verfügbarkeit stehen und dass Unternehmen, die solche Modelle in ihre Prozesse oder Software-Produkte einbinden, ein Risiko tragen, das weit über die Technik hinausreicht. Wie gravierend ist also die Abschaltung von Claude und welche Fallback-Szenarien sind realistisch?

Was ist passiert? Kurze Einordnung

Am 12. Juni 2026 erhielt Anthropic nach eigenen Angaben um 17:21 Uhr Ostküstenzeit eine Exportkontrolldirektive der US-Regierung. Diese untersagt den Zugriff auf Fable 5 und Mythos 5 für sämtliche ausländische Staatsangehörige – unabhängig vom Aufenthaltsort und ausdrücklich auch für ausländische Anthropic-Mitarbeiter. Weil sich Nationalität und Verwendungszweck aber nicht in Echtzeit auf Account-Ebene trennen lassen, sah sich das Unternehmen gezwungen, beide Modelle für alle Kunden weltweit abzuschalten. Alle übrigen Claude-Modelle bleiben laut Anthropic verfügbar. Diese Abschaltung ist in Europa kürzlich durch eine simple Meldung innerhalb der Claude-Anwendung sichtbar, wie der nachfolgende Screenshot zeigt.

Ein einfacher Hinweis in den Desktop- und Mobil-Apps von Claude informiert über die Abschaltung der Modelle

Hintergrund ist nach Darstellung Anthropics die Annahme der Regierung, es existiere eine Methode, um die Schutzmechanismen von Fable 5 zu „jailbreaken“. Laut Medienberichten soll ein nicht namentlich genanntes Unternehmen einen solchen Jailbreak demonstriert haben; Handelsminister Howard Lutnick habe Anthropic bereits Anfang Juni auf entsprechende Sicherheitsbedenken hingewiesen, bevor am 12. Juni die formale Anordnung folgte.

Bei Heise gibt es inzwischen Berichte darüber, dass der Amazon CEO die Fable-Sperre ausgelöst haben soll.

Anthropics Position: „Missverständnis“ und enger Jailbreak

Anthropic befolgt die Anordnung, widerspricht ihr aber öffentlich und ungewöhnlich deutlich. Das Unternehmen erklärt, die der Regierung vorliegende Demonstration habe lediglich eine kleine Anzahl bereits bekannter, geringfügiger Schwachstellen identifiziert – solche, die auch mit anderen öffentlich verfügbaren Modellen (genannt wird unter anderem OpenAIs GPT-5.5) reproduzierbar seien. Es habe sich um einen engen, nicht-universellen Jailbreak gehandelt, der im Kern darin bestehe, das Modell um die Analyse einer bestimmten Codebasis und das Beheben von Software-Fehlern zu bitten.

Anthropic argumentiert, das Auffinden eines derart begrenzten Jailbreaks rechtfertige nicht den Rückruf eines kommerziell breit eingesetzten Modells. Würde dieser Maßstab branchenweit angelegt, käme er nach Auffassung des Unternehmens faktisch einem Stopp sämtlicher neuer Modell-Deployments aller Anbieter von Frontier-Modellen gleich. Zugleich betont Anthropic, der Staat solle unsichere Deployments grundsätzlich blockieren dürfen – jedoch nur im Rahmen eines Verfahrens, das transparent, fair und technisch fundiert sei. Genau das sieht das Unternehmen hier nicht erfüllt.

Der regulatorische Kern: Exportkontrolle als Hebel

Bemerkenswert aus Compliance-Sicht ist dabei das verwendete Rechtsinstrument. Die US-Regierung greift nicht auf KI-spezifische Regulierung zurück, sondern auf Exportkontrollrecht – also klassisches Außenwirtschaftsrecht. KI-Modelle werden damit faktisch wie kontrollierbare Güter mit doppeltem Verwendungszweck (Dual-Use) behandelt.

Das hat eine weitreichende Logik: Wenn der Zugriff durch „ausländische Staatsangehörige“ den Tatbestand eines Exports erfüllt, dann ist nicht der physische Standort des Servers entscheidend, sondern die Staatsangehörigkeit des Nutzers. Für global aufgestellte Cloud-Dienste ist das ein kaum trennscharf umsetzbares Kriterium, was erklärt, warum die einzige praktikable Reaktion für den Claude-Hersteller die vollständige Abschaltung des Modells war.

Bewertung aus GRC-Sicht: Vier zentrale Risikofelder

1. Verfügbarkeits- und Kontinuitätsrisiko (Business Continuity)

Ein als „leistungsfähigstes Modell der Unternehmensgeschichte“ beworbenes System war drei Tage nach dem Launch nicht mehr verfügbar. Für Organisationen, die KI-Modelle produktiv in Geschäftsprozesse einbinden, ist das ein Lehrstück in Sachen Business Continuity Management (BCM): Ein erzwungener Modellwechsel ist die unangenehmste Form der Betriebsunterbrechung, weil sie ungeplant und von außen verursacht ist. Wer kein Fallback-Modell und keinen Ausweichprozess definiert hat, riskiert den absoluten Stillstand, insbesondere als SaaS-Betreiber oder bei tiefer Integration der KI-Modelle in die eigenen Geschäftsprozesse.

2. Konzentrations- und Anbieterabhängigkeit (Concentration Risk)

Der Fall verdeutlicht das Risiko einer einseitigen Abhängigkeit von einem einzelnen KI-Anbieter oder Modell. Was im Finanzsektor unter „Konzentrationsrisiko“ und „Auslagerungsmanagement“ längst reguliert ist (etwa durch DORA, Digital Operational Resilience Act und die EBA-Leitlinien), gilt sinngemäß für jede KI-gestützte Wertschöpfung: Eine Multi-Vendor- oder Multi-Modell-Strategie ist kein technisches Nice-to-have, sondern eine Risikomanagement-Entscheidung und – angesichts der aktuellen Vorfälle – ein absolutes „Must-Have“!

3. Geopolitisches und exportrechtliches Risiko

KI-Dienste US-amerikanischer Anbieter unterliegen US-Recht – mit extraterritorialer Wirkung. Der Zugriff europäischer Unternehmen kann durch Entscheidungen einer fremden Regierung binnen Stunden entfallen, ohne dass der Kunde Einfluss oder Vorlauf hat. Für die Bewertung von KI-Dienstleistern gehört diese Jurisdiktions- und Souveränitätsfrage künftig zwingend in die Lieferanten-Due-Diligence – vergleichbar mit den Debatten um Cloud-Souveränität und den DSGVO-Drittlandtransfer.

4. Verantwortung der Geschäftsleitung

Wie schon bei NIS-2 und dem EU AI Act gilt: Die Verantwortung für solche Risiken liegt auf der Leitungsebene. Die Frage „Was passiert, wenn unser zentrales KI-Modell morgen nicht mehr verfügbar ist?“ ist keine Frage der IT-Verfügbarkeit, sondern eine konkrete Governance-Entscheidung, die entsprechende Implikationen für Haftung, Sorgfaltspflichten und Notfallvorsorge mit bringt.

Was bedeutet das für deutsche Unternehmen und öffentliche Stellen?

Auch wenn Fable 5 und Mythos 5 für die meisten Organisationen längst nicht im alltäglichen Einsatz waren, hat der Fall strukturelle Konsequenzen:

• KI-Notfallplanung: Jedes Unternehmen, das KI-Modelle produktiv nutzt, sollte ein dokumentiertes Fallback-Szenario besitzen: welches Ersatzmodell kann schnell an die eigenen Services angebunden oder vorgehalten werden, welche Umschaltzeit ist realistisch, welche Qualitätssicherung existiert?
• Vertrags- und Exit-Management: Verträge mit KI-Anbietern sollten Regelungen zu Verfügbarkeit, Modell-Abkündigung und Datenportabilität enthalten.
• Souveränitätsabwägung: Für sensible Anwendungen (KRITIS, öffentliche Verwaltung, regulierte Branchen) gewinnt die Frage nach europäischen oder selbst-gehosteten Alternativen an Gewicht. Insbesondere lokale LLM-Modelle können eine attraktive Alternative darstellen.
• Lieferanten-Due-Diligence: Die Jurisdiktion des Anbieters und mögliche extraterritoriale Eingriffe gehören in jede Risikobewertung eingesetzter KI-Dienste.

Bedeutung für Governance, Risk und Compliance

Der Fall reiht sich in eine Entwicklung ein, die GRC-Verantwortliche zunehmend beschäftigt: KI-Risiken sind nicht mehr nur technischer oder datenschutzrechtlicher Natur, sondern berühren Außenwirtschaftsrecht, Geopolitik und Betriebskontinuität gleichzeitig.

• Governance muss klären, von welchen KI-Anbietern und Modellen die Organisation abhängt und wer über Ausweichoptionen entscheidet.
• Risk Management muss Anbieter-, Konzentrations- und Jurisdiktionsrisiken als eigene Risikokategorie erfassen und mit Verfügbarkeits- und Cyber-Risiken verknüpfen.
• Compliance muss die Brücke schlagen zu Auslagerungsanforderungen (z.B. DORA, MaRisk (Mindestanforderungen an das Risikomanagement), BAIT), zum EU AI Act und zu vertraglichen Verfügbarkeitszusagen – und dies nachweisbar dokumentieren.

Die zentrale Lehre ist nüchtern: Wer ein einzelnes KI-Modell zum kritischen Bestandteil seiner Wertschöpfung macht, übernimmt damit auch dessen regulatorische und geopolitische Risiken – oft ohne Mitsprache und ohne Vorwarnung. Und im Jahr 2026 kann auch eine launische US-Exportkontrolle am Wochenende unerwartet hart einschlagen.

Unterstützung durch Elsen GRC

Elsen GRC unterstützt Unternehmen und öffentliche Stellen dabei, Abhängigkeiten von KI-Modellen und -Anbietern strukturiert zu bewerten und in bestehende Governance-, Risk- und Compliance-Strukturen zu integrieren. Dazu gehören die Bewertung eingesetzter KI-Dienste, der Aufbau einer KI-Governance im Sinne des EU AI Acts, die Entwicklung von Fallback- und Exit-Strategien sowie die Verzahnung mit Auslagerungs-, NIS-2- und Datenschutzanforderungen.

Der Fall Fable 5 und Mythos 5 sollte nicht als Anlass für Panik, sondern für eine nüchterne Bestandsaufnahme dienen: Von welchen KI-Modellen hängen wir ab? Was passiert bei einem plötzlichen Ausfall? Welche Risiken akzeptieren wir bewusst – und welche nicht?

Gerne unterstütze ich Sie dabei im Rahmen eines unverbindlichen Erstgesprächs. Vereinbaren Sie einfach einen unverbindlichen Termin.

Quellen:

• Statement on the US government directive to suspend access to Fable 5 and Mythos 5 – Anthropic
• US-Regierung erzwingt Abschaltung von Anthropics KI Fable 5 und Mythos 5 – Heise online

Der Beitrag Abschaltung von Claude Fable 5 und Mythos 5 durch US-Regierung erzwungen erschien zuerst auf ELSEN GRC.

Executive Summary: Ist Claude Mythos ein Sicherheitsrisiko?

Mit Claude Mythos Preview hat Anthropic im April 2026 ein KI-Modell vorgestellt, das so leistungsfähig im Auffinden und Ausnutzen von Sicherheitslücken sein soll, dass es bewusst nicht öffentlich verfügbar gemacht wird. Stattdessen erhalten ausgewählte Unternehmen im Rahmen der Initiative „Project Glasswing“ exklusiven Zugriff, um kritische Software abzusichern. Aber schon wenige Tage nach der Vorstellung wurde bekannt, dass Unbefugte bereits am Tag der Veröffentlichung Zugang zu Mythos erlangt haben sollen. Alles nur Marketing? Oder ist Claude Mythos wirklich ein großes Sicherheitsrisiko für Unternehmen und Behörden? Aus Sicht von Governance, Risk & Compliance (GRC) wirft der Fall grundlegende Fragen auf: zur Risikoeinstufung leistungsfähiger KI-Modelle, zur Lieferketten- und Dienstleistersicherheit sowie zur Verantwortung der Geschäftsleitung beim Einsatz und beim Schutz solcher Systeme. Unternehmen, die KI strategisch einsetzen oder regulatorisch betroffen sind (z.B. durch NIS-2 oder den EU AI Act), sollten den Fall Mythos als Frühindikator für kommende Anforderungen verstehen.

Der Fall Claude Mythos ist mehr als eine Schlagzeile aus der KI-Entwicklung der letzten Wochen. Er macht sichtbar, was viele GRC-Verantwortliche seit Monaten ahnen: Hochleistungs-KI ist nicht nur ein wachsender Produktivitätsfaktor, sondern zunehmend auch ein systemisches Sicherheitsrisiko, mit Auswirkungen auf Cybersicherheit, Compliance und Governance im Unternehmen.

Was ist Claude Mythos? Kurze Einordnung

Claude Mythos Preview ist nach Angaben des Herstellers (Entwicklers) Anthropic ein KI-Modell, das auf das Auffinden und Ausnutzen von Software-Schwachstellen spezialisiert ist. Laut Heise online habe das Modell bereits tausende hochriskante Zero-Day-Schwachstellen in allen großen Betriebssystemen, Browsern und weiterer Software identifiziert. Auffällig ist dabei nicht nur die schiere Menge an Sicherheitslücken, sondern die Fähigkeit, aus identifizierten Lücken funktionierende Exploits abzuleiten, teilweise durch Verkettung mehrerer Schwachstellen. Insbesondere die Verkettung war für menschliche Sicherheitsforscher bis dato eine fast unlösbare Komplexität.

Anthropic verweist exemplarisch auf eine 27 Jahre lang unentdeckte Schwachstelle in der OpenBSD Pipeline sowie eine 16 Jahre alte Lücke in FFmpeg, die in Millionen automatisierter Scans nicht aufgefallen sei. Aufgrund dieser Fähigkeiten verzichtet Anthropic auf eine breite Veröffentlichung und stellt Mythos im Rahmen der Initiative „Project Glasswing“ ausschließlich ausgewählten Unternehmen aus dem Bereich IT-Sicherheit und kritische Infrastruktur zur Verfügung. Beteiligt sind unter anderem AWS, Apple, Cisco, CrowdStrike, Google, Microsoft und die Linux Foundation.

Warum gilt Mythos als „zu gefährlich“ für die Öffentlichkeit?

Die Argumentation Anthropics folgt einem klaren Muster: Solange noch kein vergleichbar leistungsfähiges Modell öffentlich verfügbar ist, soll Mythos genutzt werden, um Schwachstellen zu schließen, bevor andere KI-Systeme zu Mythos aufholen. Das scheint zunächst wie eine bloße Wette gegen den Markt. Sobald andere Modelle – auch in den Händen von Kriminellen oder staatlichen Akteuren – ähnliche Fähigkeiten erreichen, wäre der defensive Vorsprung verloren. Ein neues Wettrüsten hat also längst begonnen!

Dieser Ansatz ist sicherlich nachvollziehbar, aber risikobehaftet. Er basiert auf der Annahme, dass:

• der Zugriff auf Mythos kontrollierbar bleibt und die Öffentlichkeit keinen Zugriff erlangt,
• die beteiligten Unternehmen vertrauenswürdig und sicher genug sind, um das Modell zu schützen,
• und dass das Tempo der defensiven Nutzung schneller ist als das Aufholen offensiver Akteure.

Genau an diesen Annahmen entzündet sich aus einer GRC-Perspektive die Kritik.

Der Vorfall: Unbefugter Zugriff auf Claude Mythos seit Tag 1

Wenige Wochen nach der Vorstellung berichtete Heise online unter Berufung auf einen Bloomberg-Bericht, dass eine Gruppe Unbekannter bereits am Tag der Vorstellung Zugriff auf Mythos erlangt haben soll. Der Zugang sei laut Bericht über einen Drittanbieter-Mitarbeiter sowie über eine „fundierte Vermutung“ zur internen URL des Modells möglich gewesen. Die Gruppe tausche sich in einem privaten Discord-Kanal aus und nutze Mythos demnach für vergleichsweise harmlose Aufgaben, etwa den Bau von Websites – nicht für Angriffe. So wird berichtet.

Anthropic habe zugesichert, den Vorgang zu prüfen, und betont, es gebe keine Hinweise auf Auswirkungen über die Drittanbieter-Umgebung hinaus. Aus GRC-Sicht ist genau das aber der Punkt: Selbst wenn keine kriminelle Nutzung nachweisbar ist, zeigt der Vorfall, wie schwer der „kontrollierte Zugriff“ auf hochsensible KI-Modelle wie Claude Mythos in der Praxis durchzusetzen ist.

Bewertung aus GRC-Sicht: Drei zentrale Risken bei Claude Mythos

1. Lieferketten- und Dienstleistersicherheit

Der Vorfall macht erneut deutlich, dass Sicherheit nicht an der eigenen Unternehmensgrenze endet. Mit jedem Dienstleister, jedem Drittanbieter-Tool und jedem KI-Modell, das in Geschäftsprozesse integriert wird, vergrößert sich die Angriffsfläche. Frameworks wie NIS-2, BSI IT-Grundschutz und ISO 27001 fordern zu Recht eine systematische Bewertung der gesamten Lieferkette – inklusive KI-Komponenten und angebundener Systeme.

2. Risikoeinstufung leistungsfähiger KI-Modelle

Mythos ist ein praktisches Beispiel für ein Hochrisiko-KI-System im Sinne des EU AI Acts – auch wenn es formal nicht als solches reguliert wird, weil es nicht öffentlich angeboten wird. Unternehmen sollten den Fall zum Anlass nehmen, eingesetzte KI-Modelle systematisch zu klassifizieren:

• Welches Modell hat welche Fähigkeiten?
• Wo wird es verarbeitet?
• Welche Daten fließen ein?
• Welche vertragliche Grundlagen haben wir für diese Daten?
• Und welche Konsequenzen hätte ein Missbrauch oder Datenabfluss?

3. Verantwortung der Geschäftsleitung

Sowohl NIS-2 als auch der EU AI Act verlagern die Verantwortung für Cybersicherheit und KI-Compliance ausdrücklich auf die Leitungsebene. Der Fall Mythos zeigt, dass „die KI-Themen kennt sich der CTO schon mit aus“ als Governance-Ansatz nicht mehr ausreicht. Geschäftsführung und Vorstand müssen Risiken durch leistungsfähige KI-Modelle – eigene wie fremde – in ihre Risikolandschaft aufnehmen.

Was bedeutet das für deutsche Unternehmen und öffentliche Stellen?

Auch wenn Claude Mythos für die meisten Organisationen nicht direkt verfügbar ist, hat der Fall mittelbare Konsequenzen, für jede erarbeitete und bereits implementiert KI-Strategie:

• Schwachstellen in weitverbreiteter Software (Betriebssysteme, Browser, Open-Source-Bibliotheken) können durch Mythos und vergleichbare Modelle schneller identifiziert werden, im Idealfall (vor Exploit) durch Verteidiger, im Worst Case (nach Exploit) durch Angreifer.
• Patch-Management und Vulnerability-Management gewinnen weiter an Bedeutung. Wer Updates verzögert, riskiert, in einem Zeitfenster angegriffen zu werden, das KI-Tools dramatisch verkürzen. Wir reden nicht von Monaten oder Wochen, sondern von Tagen bei kritischen Sektoren.
• Die Bedeutung von Threat Intelligence und Incident Response wächst, weil Angriffe potenziell schneller, automatisierter und schwerer zuzuordnen werden.
• Regulierte Sektoren (Finanzwesen, KRITIS, öffentliche Verwaltung) müssen damit rechnen, dass Aufsichtsbehörden KI-bezogene Anforderungen verschärfen, etwa im Rahmen von NIS-2-Prüfungen oder DORA.

Bedeutung für Governance, Risk und Compliance

Aus GRC-Sicht ist Claude Mythos kein Einzelrisiko, sondern ein Vorbote. Das Thema KI-Sicherheit verlagert sich gerade vom „IT-Thema“ auf die Steuerungsebene der Organisation:

• Governance muss klären, wer im Unternehmen über den Einsatz von KI-Systemen entscheidet, welche Modelle erlaubt sind und welche Daten sie sehen dürfen.
• Risk Management muss KI-spezifische Risiken (Modellmissbrauch, Datenabfluss, Halluzinationen, Modell-Diebstahl oder Exploits sicherheitsrelevanter Systeme) systematisch erfassen und mit klassischen Cyber-Risiken verknüpfen.
• Compliance muss die Brücke schlagen zu DSGVO, EU AI Act, NIS-2, BSI C5 und sektorspezifischen Vorgaben und dabei nachweisbar bleiben.

Wer KI-Sicherheit weiterhin nur als technische Frage behandelt, wird im Ernstfall weder gegenüber Aufsichtsbehörden noch gegenüber Kunden erklären können, warum bestimmte Risiken nicht erkannt oder nicht adressiert wurden.

Unterstützung durch Elsen GRC

Elsen GRC unterstützt Unternehmen und öffentliche Stellen dabei, KI-Risiken strukturiert zu bewerten und in bestehende Governance-, Risk- und Compliance-Strukturen zu integrieren. Dazu gehören die Bewertung eingesetzter KI-Systeme, der Aufbau einer KI-Governance im Sinne des EU AI Acts, die Verzahnung mit NIS-2- und Datenschutzanforderungen durch KI-orientierte Datenschutzberatung sowie die Sensibilisierung der Geschäftsleitung.

Der Fall Claude Mythos sollte nicht Anlass für Panik, sondern für eine nüchterne Bestandsaufnahme sein: Welche KI-Systeme nutzen wir? Wer ist verantwortlich? Welche Risiken akzeptieren wir bewusst und welche nicht?

Gerne unterstütze ich Sie dabei im Rahmen eines unverbindlichen Erstgesprächs.

Foto: Foto von Palash Jain auf Unsplash

Quellen:

• Anthropics neues KI-Modell Mythos: Zu gefährlich für die Öffentlichkeit – Heise online
• Anthropics gefährliche KI Mythos: Unbefugte wohl mit Zugriff seit dem ersten Tag – Heise online
• Project Glasswing – Anthropic
• Mythos Preview – Anthropic Red Team Blog

Der Beitrag Ist Claude Mythos ein Sicherheitsrisiko? Eine GRC-Perspektive erschien zuerst auf ELSEN GRC.

Aus meiner Praxis als Webentwickler stand ich immer wieder vor der Aufgabe, nach passenden „Standardlösungen“ für Kunden zu suchen, die aus Kundensicht nicht nur einfach und unkompliziert zu managen sind, sondern auch meinen fachlichen Ansprüchen an GRC-Faktoren wie sauberen Datenschutz im Sinne der DSGVO genügen, nachvollziehbare Compliance sicherstellen und gleichzeitig eine klare und strukturierte Governance ermöglichen, die im Sinne des Unternehmens ist.

Was auf den ersten Blick wie ein Effizienzgewinn für kleine und mittlere Unternehmen aussieht, ist aus Compliance-Perspektive oft ein erhebliches Risiko. Und da wir als Agentur auch für die Auswahl externer Tools oftmals die Hand ins Feuer halten müssen, uns angesichts der hohen Intransparenz und des mangelnden Datenschutzes in vielen Tools aber nur ungern verbrennen, haben wir kurzerhand den Entschluss gefasst, einen GRC-optimierten und DSGVO-konformen KI-Chatbot zu entwickeln, der genau diese kritischen Punkte sicherstellt.

Das Kernproblem: Keine Datenhoheit bei den meisten KI-Chatbots

Die zentrale Frage, die sich jedes Unternehmen stellen muss, bevor es einen KI-Chatbot auf seiner Website einsetzt, lautet: Was passiert mit den Daten, die meine Kunden im Chat eingeben? Die Antwort ist bei den meisten Anbietern ernüchternd und bildet damit auch das Kernproblem. Fehlende Datenhoheit und Nachvollziehbarkeit über Speicherung und fortlaufende Verarbeitung von sensiblen und/oder personenbezogenen Daten sind bei fast jedem KI-Chatbot eine echte „Blackbox“.

Beispiel:

Ein Kunde besucht die Website eines Handwerksbetriebs und schreibt in den Chat: „Hallo, ich bin Max Müller aus der Kirchenstraße 12 in Hamburg. Können Sie bei uns im Bad die Fliesen erneuern? Meine Nummer ist 0170 1234567.“

In einer einzigen Nachricht mit etwa 140 Zeichen stecken Name, Adresse, Telefonnummer – alles personenbezogene Daten im Sinne des Art. 4 Nr. 1 DSGVO. Der Kunde hat sie freiwillig eingegeben, ohne gefragt zu werden. In der datenschutzrechtlichen Terminologie spricht man von „aufgedrängten Daten“. Je nach Anwendungsfall können noch medizinische oder ethnische Daten als besondere Kategorien personenbezogener Daten (Art. 9 DSGVO) dazukommen und zusätzlich an der Brisanz der Daten zündeln.

Und genau hier beginnt das Problem. Denn die meisten KI-Chatbot-Anbieter leiten diese Eingabe ungefiltert an ein Sprachmodell weiter — in der Regel an OpenAI, Anthropic oder Google. Die Daten verlassen den europäischen Rechtsraum, werden auf US-Servern verarbeitet, und der Betreiber der Website hat keine Kontrolle darüber, was mit diesen Daten geschieht.

Datenfluss-Blackbox bei KI-Chatbots: Ein echtes Problem für den Datenschutz

Das ist also nicht nur ein theoretisches Risiko. Die DSGVO ist hier eindeutig: Wer ein KI-System bereitstellt, das personenbezogene Daten verarbeitet, ist als Verantwortlicher nach Art. 4 Nr. 7 DSGVO einzustufen – und muss sämtliche Pflichten erfüllen, die damit einhergehen. Dazu gehören Rechtsgrundlage, Informationspflicht, Zweckbindung, Datenminimierung und das Recht auf Löschung. Der EU AI Act wird zudem noch weitere Stufen zur Risikoprüfung draufsatteln, die ab August 2027 ebenfalls zu berücksichtigen sind.

Ein simples „Bitte geben Sie keine persönlichen Daten ein“ als Hinweis im Chat reicht aus Compliance-Sicht also nicht aus, um die Verantwortung abzuwälzen. Kunden halten sich nicht an solche Hinweise – und das Unternehmen (oder der Website-Betreiber) bleibt in der Pflicht.

Was wir bei der Marktrecherche festgestellt haben

Im Rahmen unserer GRC-Beratungstätigkeit haben wir Dutzende KI-Chatbot-Lösungen geprüft – für unsere Kunden und für eigene Projekte. Das Ergebnis lässt sich in drei Kategorien zusammenfassen:

• Kategorie 1: US-basierte Self-Service-Plattformen wie Tidio, Botsonic, Chatling, CustomGPT. Einfach einzurichten, günstiger Preis, funktional überzeugend. Aber: Datenverarbeitung auf US-Servern, keine echte PII-Kontrolle, DSGVO-Konformität bestenfalls eine Behauptung im Marketing – kein Privacy by Design.
• Kategorie 2: Enterprise-Lösungen aus dem DACH-Raum wie ADVISORI, Pexon Consulting, assono und weitere. DSGVO wird ernst genommen, oft mit Privacy by Design. Aber: Hohe Projektkosten ab fünfstelligen Summen, Setup-Zeiten von Wochen bis Monaten, für KMU schlicht unbezahlbar und unverhältnismäßig teuer.
• Kategorie 3: DACH-Nischen-Anbieter wie Userlike, moinAI, KI-DACH. Hier gibt es bereits „deutsches Hosting“, DSGVO-Awareness. Aber: Entweder zu teuer für Kleinunternehmen, zu generisch in der Konfiguration oder ohne echte Anonymisierung – die Daten landen trotzdem beim KI-Modell.

Was fehlte: Eine Lösung, die technische Datenschutz-Architektur (nicht nur Marketing-Claims) mit der Einfachheit verbindet, die ein Handwerker, ein kleiner Online-Shop oder ein Beratungsbüro braucht. Eine Lösung, bei der ein Fliesenleger in Hamburg in fünf Minuten einen KI-Fachberater auf seiner Website hat und trotzdem jede Datenschutzprüfung besteht. Ein KI-Chatbot, der sich in maximal 5 Minuten in die eigene Website integrieren lässt und idealerweise eine native Unterstützung für WordPress liefert – z. B. via WordPress-Plugin.

Die Idee: Eigenentwicklung – Privacy by Design und in unter 5 Minuten live

Wir brauchen also etwas, das es (noch) nicht gibt. Nicht zu dem Preis, nicht in der Einfachheit und vor allem nicht mit der Datenschutz-Architektur, die wir aus GRC-Perspektive für notwendig und aus KMU-Sicht für bezahlbar halten.

Die Konsequenz war die Entwicklung unserer eigenen Chatbot-Lösung: Fachagent.com – eine SaaS-Plattform für KI-Fachberater auf Websites, die DSGVO-Konformität architektonisch verankert, statt sie als Feature-Label zu verwenden.

DSGVO-konforme KI-Chatbot-Lösung von Fachagent.com

Der Kern: Ein eigener Privacy-Layer, der Datenschutz sicherstellt

Das Herzstück ist unsere Anonymisierungsschicht ainony.me, die wir kurzerhand als separaten API-Service ausgelagert haben. Sie sitzt als eigenständige Anwendung zwischen dem Chat-Widget und dem KI-Modell. Jede Nachricht durchläuft diese Schicht, bevor sie die KI erreicht:

• PII-Erkennung in Echtzeit,
• Maskierung durch anonymisierte Platzhalter,
• Fail-Closed bei Fehlern,
• vollständiger Audit-Trail.

Die KI sieht damit keine personenbezogenen Daten – die Datenminimierung passiert vor der Verarbeitung, nicht danach.

Andere Anbieter setzen auf „EU-Server“ als DSGVO-Argument. Das ist notwendig, aber nicht hinreichend. Solange personenbezogene Daten das KI-Modell erreichen, findet eine Verarbeitung statt, unabhängig vom Serverstandort. Ainony.me und Fachagent eliminieren dieses Problem an der Wurzel.

Privacy Layer im KI-Chatbot von Fachagent

Was Fachagent darüber hinaus löst

Für den Nutzer läuft die gesamte Compliance-Architektur im Hintergrund. Das Setup ist einfach:

1. URL eingeben,
2. Branchenvorlage auswählen,
3. Chat-Widget einbinden – fertig.

Die Anonymisierung, das Audit-Logging und die Transparenzhinweise nach EU AI Act passieren vollautomatisch und revisionssicher. Der Handwerker, der seinen Chatbot einrichtet, muss sich nicht mit Art. 32 DSGVO beschäftigen. Das System stellt es sicher.

Fachagent ist nicht entstanden, weil der Markt noch einen Chatbot brauchte, sondern weil wir eine Lösung anbieten wollten, die Datenschutz durch transparente und nachvollziehbare Architektur garantiert und gleichzeitig ein präzises Beratungsangebot mit Lead-Generierung für Endkunden anbietet. Und genau das sind Features von Fachagent.

Der ideale KI-Chatbot für WordPress-Websites

WordPress ist das meistgenutzte CMS der Welt – und die Grundlage für Hunderttausende KMU-Websites im DACH-Raum. Gleichzeitig ist das WordPress-Ökosystem ein besonderer Risikobereich: Plugins laden externe Scripts, übertragen Daten an Drittanbieter und schaffen Angriffsvektoren, die vielen Betreibern nicht bewusst sind.

Für Fachagent haben wir deshalb ein eigenes WordPress-Plugin entwickelt, das die Integration des KI-Chatbots in WordPress so einfach wie möglich macht. Das Plugin verbindet die WordPress-Website mit dem Fachagent-Backend über einen API-Key. Das Chat-Widget wird asynchron geladen und hat keinen Einfluss auf die Seitenperformance. Es ist kompatibel mit allen gängigen Themes, Page-Buildern und Cookie-Consent-Plugins.

Der entscheidende Punkt: Das Plugin selbst überträgt keine personenbezogenen Daten. Es lädt lediglich das Widget, das die Chat-Oberfläche bereitstellt. Die gesamte Datenverarbeitung – inklusive Anonymisierung – läuft über das Fachagent-Backend auf deutschen Servern. Der WordPress-Betreiber hat keine zusätzliche Datenschutz-Verantwortung durch das Plugin, die über die normale Chatbot-Nutzung hinausgeht.

Du kannst Fachagent ab sofort 14 Tage kostenlos testen. Eine Registrierung reicht völlig aus und erfordert keine Zahlungsmethode.

Der Beitrag Fachagent als DSGVO-konformer KI-Chatbot für KMU erschien zuerst auf ELSEN GRC.

Executive Summary: Sicherheitslücke in Claude Cowork – Datei-Diebstahl via Prompt Injection?

Nur wenige Tage nach dem Start von Claude Cowork haben Sicherheitsforscher eine kritische Schwachstelle ermittelt: Angreifer können in scheinbar harmlosen Dokumenten wie E-Mails, PDFs und anderen Filesunsichtbare Anweisungen verstecken, die den KI-Agenten wie Claude’s „Cowork“ dazu bringen, vertrauliche Dateien aus verbundenen Ordnern des lokalen Systems zu exfiltrieren – und zwar ohne menschliche Genehmigung. Der Angriff nutzt eine bekannte Isolationsschwäche in der containerisierten Codeausführungsumgebung von Claude, die laut Berichten zwar bekannt, aber bislang nicht aktiv geschlossen wurde. Für Governance, Risk und Compliance ist das ein klassischer „Reality Check“: Sobald KI-Agenten Zugriff auf lokale Dateisysteme, Integrationen oder Unternehmensdaten erhalten, wird Prompt Injection nicht zu einem theoretischen Risiko, sondern zu einem konkreten Datenabfluss-Szenario mit potentiell erheblichen Folgeschäden.

Der Fall zeigt sehr plastisch, warum „agentische“ KI-Systeme („agentic ai“, also KI, die nicht nur antwortet, sondern Aktionen ausführt) eine neue Risikoklasse darstellen. Die Kernfrage für Organisationen lautet nicht mehr: „Ist das Tool nützlich?“, sondern:  Welche Daten dürfen überhaupt in Reichweite eines KI-Agenten liegen – und wie verhindern wir, dass der Agent auf manipulierte Anweisungen reagiert?

Was ist Claude Cowork und warum ist die Sicherheitslücke in Claude Cowork so kritisch?

Claude Cowork ist eine vollständig durch die von Anthropic entwickelte KI Claude automatisiert geschriebene Agenten-Software, die als produktiver KI-Begleiter gedacht ist, der mit der (lokalen) Arbeitsumgebung interagieren kann – z. B. über verbundene Ordner, Browser-Aktionen oder Integrationen. Wir sprechen also über eine direkte Integration von KI in die Systemumgebung beispielsweise von MacOS.

Genau diese Nähe zur „echten“ Datenquellen macht den Unterschied zu einem normalen Chatbot wie ChatGPT oder Google Gemini. Denn anders als in diesen Chat-basierten LLMs müssen in Claude Cowork keine Dateien hoch- und wieder runtergeladen werden, um eine aktive (Mit-) Arbeit der KI zu ermöglichen, sondern dieses geschiehet direkt im Dateisystem des lokalen Rechners. Claude nutzt dabei das bereits aus Claude Code bekannte „Terminal System“, das insbesondere bei Softwareentwickler sehr beliebt ist und erheblichen Vorteile gegenüber der Entwicklung beispielsweie mit OpenAIs „Codex“ beitet.

Wenn ein Agent Dateien lesen und Aktionen ausführen kann, wird jede Eingabe- oder Dokumentquelle zu einer potenziellen Angriffsfläche. heise und t3n sprechen in diesem Zusammenhang von Dateiexfiltration über indirekte Prompt-Injektionen – also versteckte Befehle, die nicht in der sichtbaren Benutzeranweisung stehen, sondern „im Hintergrund“ in einem Dokument platziert werden. Klassischen Beispiele sind schwarze Schriften auf schwarzem Hintergrund oder weiße Schriften auf weißem Hintergrund, die über eingelesene PDF-, Word- oder auch HTML-Dokumente direkt in den Systemprompt wandern und unauthorisierte Aktionen durchführen könnten.

So läuft der Angriff ab: „Harmloses Dokument“ + versteckte Anweisung = Datei-Upload

Die von Sicherheitsforschern beschriebene Angriffskette ist aus Angreifersicht unangenehm simpel: Ein Nutzer verbindet Claude Cowork mit einem lokalen Ordner, in dem auch vertrauliche Inhalte liegen (z.B. Fotos, andere Dokumente, Source Code). Danach wird eine Datei (z. B. eine Word-Datei) in Cowork geladen, die wie ein nützliches Hilfsdokument wirkt – in der Praxis werden solche „Prompt- oder Skill-Dateien“ gerne online geteilt, was die Eintrittswahrscheinlichkeit erhöht. In das Dokument ist jedoch eine Anweisung eingebettet, die für Menschen praktisch unsichtbar ist, etwa durch sehr kleine Schrift und Farb-/Layout-Tricks. The Decoder beschreibt das konkret als 1-Punkt-Schrift, weiß auf weiß, mit minimalem Zeilenabstand.

Wenn der Nutzer Cowork dann bittet, die vertraulichen Daten „auf Grundlage“ dieses Dokuments zu analysieren, übernimmt die versteckte Anweisung die Kontrolle. Laut heise und t3n wird der Agent dabei u. a. angewiesen, einen curl-Befehl auszuführen und eine Datei über die Anthropic File-Upload-API hochzuladen – inklusive Übermittlung eines API-Schlüssels der Angreifer, sodass die Datei direkt auf deren Konto landet. Besonders relevant: Während dieses Ablaufs ist keine manuelle Freigabe erforderlich.

Warum eine Sicherheitslücke bei Claude Cowork so schwer zu erkennen ist

Ein zentraler Punkt ist, dass der Datenabfluss nicht „wie Malware“ wirkt. Der Upload passiert über legitime, für das Produkt notwendige Schnittstellen. Laut Berichten bleibt der Angriff oft unentdeckt, weil die Anthropic-API als vertrauenswürdig gilt und daher nicht automatisch als verdächtiger Datenabfluss auffällt.
heise und t3n greifen zudem die Kritik auf, dass „Achtet auf verdächtige Aktionen“ als Warnhinweis für normale Nutzer nicht realistisch ist – Prompt Injection ist für viele Anwender schlicht nicht zuverlässig erkennbar.

GRC-Relevanz: Was bedeutet das für Governance, Risk und Compliance?

Auch für diesen sicherheitsrelevanten Case mit Claude Cowork nehme ich eine Einordnung in den Kontext von GRC vor, damit IT-Leader, IT-Spezialisten und Berater auf die neuen Bedrohungen durch agentische Systeme in Zukunft besser reagieren können:

Governance: KI-Agenten mit Datei- oder Integrationszugriff gehören nicht in die „Tool-Ecke“ einzelner Teams. Es braucht klare Policies: Welche Verzeichnisse dürfen angebunden werden? Welche Datenklassen sind tabu (Kundendaten, Verträge, HR, Quellcode, Finanzzahlen)? Welche Tools und Schnittstellen sind freigegeben – und mit welchen Settings?

Risk: Prompt Injection ist hier kein abstraktes Modellrisiko, sondern ein Datenabfluss-Risiko durch nicht vertrauenswürdige Inputs (Dokumente, Webseiten, geteilte „Skills“). Das Thema gehört klar in das Cyber-Risikomanagement: Eintrittswahrscheinlichkeit für Schäden steigt, sobald Agenten in reale Workflows integriert werden. Schadenshöhe ist potenziell hoch, weil es um vertrauliche Dateien geht – und diese könne personenbezogene, sensible Daten enthalten ebenso wie schützenswerte Geschäfts- und Kundendaten.

Compliance: Sobald personenbezogene Daten oder vertrauliche Unternehmensinformationen betroffen sein können, treffen Datenschutz, Geheimhaltung, Vertrags- und Sicherheitsanforderungen aufeinander. Organisationen müssen nachweisen können, dass sie angemessene TOMs etabliert haben – und dass KI-Tools nicht „ungeprüft“ Zugriff auf sensible Daten erhalten. Der Fall ist zudem ein gutes Beispiel für „Shadow AI“: Wenn Mitarbeitende solche Agenten eigenständig anbinden, entstehen Compliance-Risiken außerhalb formaler Kontrollen.

Pragmatische Konsequenzen: Was Unternehmen jetzt tun sollten

Wer agentische KI-Tools testet oder unmittelbar einführen will, sollte kurzfristig drei Leitplanken setzen:

1. Scope begrenzen (nur nicht-sensitive Testdaten, keine lokalen Ordner mit sensiblen Kundendaten).
2. Input-Hygiene (keine fremden „Skills“, Prompt-Dateien oder Dokumente aus unklaren Quellen in produktive Workflows).
3. Kontrollen einziehen (Monitoring, DLP (Data Loss Prevention)/Upload-Kontrollen, klare Freigabeprozesse für Integrationen und Datei-Zugriffe). Diese Maßnahmen ersetzen keine Produkt-Fixes – reduzieren aber das Risiko, bis Anbieter wirksame Schutzmechanismen liefern.

Beratung zur sicheren KI-Nutzung im Kontext Cybersecurity durch Elsen GRC

Elsen GRC unterstützt Unternehmen, SaaS-Anbieter und Behörden dabei, KI-Agenten und KI-Integrationen GRC-sicher zu betreiben – insbesondere dort, wo Datei-, System- oder Integrationszugriffe ins Spiel kommen. Dazu gehören Use-Case-Assessments, Policy- und Governance-Design (inkl. Datenklassen/Scopes), Risikoanalysen zu Prompt-Injection-Szenarien sowie die Ableitung pragmatischer TOMs (Freigaben, Monitoring, technische Guardrails). Ziel ist eine KI-Nutzung, die Produktivität ermöglicht, ohne unkontrollierte Datenabflüsse und Haftungsrisiken zu provozieren. Vereinbaren Sie gerne ein unverbindliches Beratungsgespräch.

Foto: © Claude.com

Quellen:

• Sicherheitslücke in Claude Cowork: So verschaffen sich Hacker unbemerkt Zugriff – heise.de
• Sicherheitslücke in Claude Cowork – t3n.de
• Claude Cowork hit with file-stealing prompt injection – The Decoder

Der Beitrag Kritische Sicherheitslücke in Claude Cowork entdeckt erschien zuerst auf ELSEN GRC.

Executive Summary: NIS-2 Registrierung startet jetzt beim BSI – was Unternehmen jetzt wissen müssen

Mit dem Start der NIS-2 Registrierung beginnt für viele Unternehmen und Organisationen eine neue Phase verpflichtender Cybersicherheits-Compliance. Die europäische NIS-2-Richtlinie  erweitert den Kreis der betroffenen Einrichtungen deutlich und verpflichtet diese, sich aktiv zu identifizieren, Sicherheitsmaßnahmen umzusetzen und Vorfälle zu melden. Auch wenn die nationale Umsetzung in Deutschland noch nicht vollständig abgeschlossen ist, laufen die Vorbereitungen für die NIS-2 Registrierung beim BSI bereits auf Hochtouren. Unternehmen sollten jetzt klären, ob sie betroffen sind, ab wann Pflichten greifen und wo die Registrierung erfolgen wird – denn eine automatische Benachrichtigung ist nicht vorgesehen.

Die NIS-2 Registrierung ist kein rein formaler Akt, sondern der sichtbare Einstieg in ein umfassendes Cybersicherheits- und Aufsichtsregime. Sie markiert den Punkt, an dem sich Organisationen gegenüber Behörden erklären müssen, ganz im Sinne von „Wir sind von NIS 2 betroffen  – und wir haben unsere Risiken und Schutzmaßnahmen im Griff!“

Was ist NIS-2 überhaupt? Kurze Einordnung

Die NIS-2-Richtlinie (Network and Information Security Directive 2) ist eine EU-weite Vorgabe zur Stärkung der Cyber-Resilienz. Sie ersetzt die bisherige NIS-Richtlinie und reagiert auf die zunehmende Bedrohung durch Cyberangriffe, Lieferkettenrisiken und systemische IT-Abhängigkeiten – auch im Kontext von KI.

Im Kern verpflichtet NIS 2 betroffene Organisationen dazu, angemessene technische und organisatorische Maßnahmen (sog. TOMs) zur IT- und Informationssicherheit umzusetzen, Sicherheitsvorfälle zeitnah zu melden und die Verantwortung klar auf der Leitungsebene zu verankern. Cybersicherheit wird damit ausdrücklich zur Management- und Governance-Aufgabe.

Ab wann gilt NIS-2 – und was bedeutet das für die Registrierung?

Die NIS-2-Richtlinie ist auf EU-Ebene bereits in Kraft getreten. Die Mitgliedstaaten müssen sie in nationales Recht überführen. In Deutschland erfolgt dies über das NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz, das sich aktuell noch im Gesetzgebungsverfahren befindet.

Unabhängig davon bereiten die zuständigen Behörden, insbesondere das Bundesamt für Sicherheit in der Informationstechnik (BSI), bereits die NIS-2 Registrierung vor. Geplant ist ein zentrales Registrierungsportal, über das betroffene Unternehmen ihre Zugehörigkeit anzeigen müssen. Die Registrierung ist damit eine aktive Pflicht: Unternehmen müssen selbst prüfen, ob sie unter NIS 2 fallen, und sich fristgerecht registrieren.

Für wen gilt die NIS-2 Registrierung und wer muss sich registrieren?

Die NIS-2-Richtlinie erweitert den Anwendungsbereich erheblich. Betroffen sind nicht mehr nur klassische Kritische Infrastrukturen, sondern auch viele mittelständische Unternehmen und KMU. Maßgeblich sind dabei vor allem Branche, Unternehmensgröße und Funktion.

Erfasst werden unter anderem Unternehmen aus den Bereichen Energie, Verkehr, Wasser, Gesundheitswesen, digitale Infrastruktur, IT-Dienstleistungen, Cloud- und Rechenzentrumsbetrieb, Industrie, Entsorgung sowie Teile der öffentlichen Verwaltung. Die Richtlinie unterscheidet zwischen wesentlichen Einrichtungen und wichtigen Einrichtungen. Beide Gruppen unterliegen der NIS-2 Registrierung und verbindlichen Sicherheitsanforderungen – mit abgestufter Aufsicht und Sanktionierung.

NIS-2 gilt also insbesondere für:

• Unternehmen ab 50 Mitarbeitenden oder 10 Mio. € Jahresumsatz, sofern sie in einem erfassten Sektor tätig sind
• Kritische und wichtige Branchen wie Energie, Verkehr, Gesundheitswesen, Wasser, digitale Infrastruktur, IT- und Cloud-Dienstleister
• Unternehmen mit systemischer Bedeutung, z. B. Managed Service Provider, Rechenzentren, SaaS- und Plattformanbieter
• Öffentliche Einrichtungen und Behörden, soweit sie unter den erweiterten Anwendungsbereich der Richtlinie fallen

Wo startet die Registrierung für NIS-2 beim BSI?

Die NIS-2 Registrierung soll in Deutschland zentral über ein BSI-Portal erfolgen (Link zur BSI-Pressemitteilung). Dort müssen Unternehmen künftig Angaben zu ihrer Organisation, Branche und Rolle machen. Auf dieser Basis erfolgt die Zuordnung zum NIS-2-Regime und die weitere aufsichtsrechtliche Betreuung.

Mit der Registrierung gehen weitere Pflichten einher: die Benennung von Ansprechpartnern, die Vorbereitung auf Meldepflichten bei Sicherheitsvorfällen sowie die Nachweisbarkeit von Sicherheitsmaßnahmen. Die Registrierung ist damit der erste formale Schritt in eine laufende Compliance-Beziehung mit der Aufsichtsbehörde.

Die NIS-2 Registrierung ist beim BSI über das BSI-Portal möglich

Bedeutung der NIS-2 Registrierung für Governance, Risk und Compliance

Aus GRC-Sicht stellt die NIS-2 Registrierung den Startpunkt für ein dauerhaftes Cybersicherheits-Management dar. Entsprechende Governance-Strukturen müssen sicherstellen, dass die Geschäftsleitung informiert, eingebunden und verantwortlich ist. Risiko-Management muss Cyberrisiken systematisch erfassen, priorisieren und regelmäßig überprüfen – auch mit Blick auf Dienstleister und Lieferketten.

Für die Compliance bedeutet NIS 2, dass Sicherheitsmaßnahmen, Schulungen, Risikoanalysen und Incident-Prozesse nicht nur existieren, sondern dokumentiert und prüfbar sein müssen. Die Registrierung macht Organisationen sichtbar – und damit auch überprüfbar. Wer hier also noch keine passenden Risk- und Compliance-Management Prozesse etabliert hat, sollte sich spätestens nach der Registrierung sputen!

Unterstützung bei der Registrierung durch Elsen GRC

Elsen GRC begleitet Unternehmen und öffentliche Stellen bei der NIS-2 Registrierung und der anschließenden Umsetzung der Anforderungen. Dazu gehören die Prüfung der Betroffenheit, die strukturierte Vorbereitung auf das BSI-Portal, der Aufbau oder Abgleich von Governance- und Risiko-Strukturen sowie die Integration von NIS-2-Pflichten in bestehende Compliance-Systeme.

Ziel ist es, die Registrierung nicht als isolierte Pflicht zu behandeln, sondern als Einstieg in eine belastbare und zukunftsfähige Cyber-Governance. Gerne unterstütze ich Sie dabei im Rahmen eines unverbindlichen Erstgesprächs.

Foto: Joshua Woroniecki – Unsplash.com

Quellen:

• NIS-2 Registrierung und BSI-Portal – Digital Business Magazin
• NIS-2 Umsetzungsgesetz – IHK Erfurt
• NIS-2-Richtlinie – Europäische Kommission
• NIS 2 startet – All-About-Security

Der Beitrag NIS-2 Registrierung startet – was Unternehmen jetzt wissen müssen erschien zuerst auf ELSEN GRC.