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.

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.

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.

Warum ein eigenes GRC Journal?

Die Anforderungen an Datenschutz, IT-Sicherheit und den Compliance-konformen Einsatz von KI wachsen rasant. Steigender Wettbewerbsdruck machen den Einsatz von KI-Tools in vielen Unternehmen unerlässlich, während andere Unternehmen erst durch KI komplett neue Geschäftsmodelle erschließen. Die Smarte Integration von KI-Anbindungen in eigene Produkte, Schnittstellen oder Prozesse kann die Produktivität nicht nur erheblich steigern, sondern ganze Wertschöpfungsketten umstrukturieren.  Mit dem EU AI Act entsteht erstmals ein umfassender Rechtsrahmen für den Einsatz künstlicher Intelligenz, während NIS2 und ISO 27001 den Standard für Informationssicherheit in Europa neu (oder erneut) definieren. Ziel des Journals ist es, diese Entwicklungen verständlich, aktuell und praxisnah einzuordnen – für Datenschutzbeauftragte, IT-Leitungen, Geschäftsführungen und alle, die für Compliance und Governance im Unternehmen Verantwortung tragen. Elsen GRC zeigt, dass Governance und Innovation kein Widerspruch sind – sondern die Grundlage für vertrauenswürdige Technologien.

Strategie, Fokus und Motivation von Elsen GRC

Elsen GRC berät Unternehmen im DACH- und CH-Raum beim sicheren, datenschutz- und gesetzeskonformen Einsatz von KI- und Cloud-Technologien. Der Ansatz verbindet technische Expertise, rechtliches Verständnis und praktische Umsetzungskompetenz. Ziel ist es, GRC-Strukturen nicht nur zu planen, sondern im Unternehmen operativ und praxistauglich zu verankern – von der Datenschutz-Organisation bis zur KI-Governance.

Aber wie kam es dazu? Nachdem ich unter dem Dach der Elsen Media GmbH über 14 Jahre Erfahrung in der Entwicklung von Websites, Webanwendungen und Kampagnen gesammelt habe, hunderte Cookie-Consent-Tools konfiguriert und Datenschutzerklärungen auf die Füße der DSGVO gestellt hatte, stellte ich zunehmend fest, dass sich die Arbeitsweise meiner Kunden verändert: Immer häufiger wurden eigene – teils KI-generierte – Konzepte oder Inhalte geliefert, bei denen die Verarbeitung der Daten nicht nur fraglich, sondern teilweise unter Vernachlässigung geltender Datenschutzrichtlinien erfolgte.

Inzwischen findet sich KI in nahezu allen Prozessen mittelständischer Unternehmen. Doch eine zentrale Frage wird fast immer vernachlässigt: Wie gehen wir beim Einsatz von KI eigentlich mit sensiblen Unternehmens- und personenbezogenen Daten um?

Diese Frage führte mich 2025 zu einem neuen Schwerpunkt meiner IT-Tätigkeit – in die Welt von Governance, Risk und Compliance (GRC). Die gezielte Weiterbildung zum TÜV-zertifizierten Datenschutzbeauftragten, ergänzt durch die Vorbereitung auf die Tätigkeit als ISO 27001 Lead Auditor sowie die IAPP AIGP-Zertifizierung, bilden das Fundament der heutigen Arbeit von Elsen GRC.

Themen, die Sie im GRC Journal erwarten

Das Journal wird regelmäßig mit neuen Beiträgen gefüllt – fundiert, praxisnah und stets mit Blick auf aktuelle regulatorische Entwicklungen:

• Was sind Hoch-Risiko-KI-Systeme nach dem EU AI Act?
• Datenpanne – was tun, wenn’s passiert ist?
• TOMs im Auftragsverarbeitungsvertrag: Muster und Umsetzung
• Automatisierte Einzelentscheidung und Profiling im KI-Zeitalter
• Cloud Act vs. DSGVO – Datenhoheit und US-Anbieter im europäischen Kontext
• und viele weitere Themen!

Jeder Beitrag bietet einen klaren Mehrwert: rechtliche Einordnung, technische Perspektive und konkrete Handlungsempfehlungen – um Unternehmen bei der AI Act Readiness, NIS2-Umsetzung und Datenschutz-Governance zu unterstützen.

Bleiben Sie auf dem Laufenden und erhalten Sie praxisnahe Insights rund um AI Act, DSGVO, NIS2 und ISO 27001.
Abonnieren Sie unseren Newsletter oder folgen Sie Elsen GRC auf LinkedIn, um regelmäßig über neue Beiträge, Webinare und Fachanalysen informiert zu werden.

Sie möchten Ihr Unternehmen auf AI Act Readiness, NIS2-Compliance oder ISO 27001-Zertifizierung vorbereiten? Kontaktieren Sie uns gern für ein unverbindliches Orientierungsgespräch.

Der Beitrag GRC Journal: Praxisnahe Insights über Governance, Risk, Compliance und AI Act erschien zuerst auf ELSEN GRC.