Ein GenAI-Tool ist schnell geöffnet, ein Text schnell hineinkopiert. Genau darin liegt das Risiko: Ohne klare Einordnung von Informationen werden vertrauliche Inhalte, personenbezogene Daten oder geschützte Geschäftsgeheimnisse versehentlich in Systeme gegeben, die nicht dafür vorgesehen sind. Eine belastbare Datenklassifizierung übersetzt Sicherheits- und Compliance-Anforderungen in einfache Regeln, die im Alltag funktionieren.
Der Nutzen ist doppelt: Teams arbeiten schneller, weil sie wissen, was erlaubt ist – und die Organisation reduziert Haftungs-, IP- und Reputationsrisiken, weil Datenflüsse nachvollziehbar werden. Entscheidend ist dabei nicht eine perfekte Theorie, sondern ein Klassensystem mit klaren Beispielen, eindeutigen Do’s & Don’ts und einer Umsetzungslogik, die in Tools, Prozessen und Schulungen verankert wird.
Warum GenAI ohne Datenklassen zur Risiko-Falle wird
Prompting ist Datenweitergabe – auch ohne Datei-Upload
Schon ein Prompt kann Informationen enthalten, die als vertraulich gelten: Angebotskonditionen, Kundennamen, interne Strategiepapiere, Quellcode-Ausschnitte oder sensible Vertragsklauseln. Selbst wenn kein Dokument hochgeladen wird, entsteht eine Datenweitergabe an ein System außerhalb des eigenen Dokumentspeichers. Ob diese Weitergabe zulässig ist, hängt von Datenart, Zweck, Systemkonfiguration und organisatorischen Vorgaben ab.
Risiken verteilen sich über Abteilungen
Marketing sieht im Prompt „nur“ Text, HR „nur“ Lebensläufe, Legal „nur“ Klauseln, Vertrieb „nur“ E-Mails. Technisch sind das unterschiedliche Risikokategorien: personenbezogene Daten, besondere Kategorien, Geschäftsgeheimnisse, urheberrechtlich geschützte Inhalte oder sicherheitsrelevante Details. Ohne gemeinsame Sprache – also Klassen – entstehen Lücken, weil jede Abteilung anders bewertet.
Klassen schaffen Entscheidungssicherheit, nicht Bürokratie
Ein gutes System reduziert Rückfragen. Ziel ist eine praxistaugliche Standardentscheidung: „Darf in Tool A, nur anonymisiert in Tool B, nie in Tool C.“ Damit werden Freigaben skalierbar.
Datenklassen definieren: pragmatisch, eindeutig, trainierbar
Ein bewährter Zuschnitt: 4 Klassen plus Sonderfälle
Viele Organisationen fahren gut mit vier Grundklassen. Wichtig ist nicht die Anzahl, sondern die Klarheit der Abgrenzung und die Fähigkeit, Beispiele schnell zuzuordnen:
- Öffentlich: Inhalte, die bereits publiziert sind oder ohne Schaden publiziert werden dürfen (z. B. Website-Text, öffentliches Datenblatt).
- Intern: Informationen für Mitarbeitende, bei deren Verlust ein begrenzter Schaden entsteht (z. B. interne Prozessbeschreibung ohne Kundendaten).
- Vertraulich: Informationen mit merklichem Geschäfts- oder Datenschutzrisiko (z. B. nicht öffentliche Preise, nicht veröffentlichte Roadmap, Kundendaten).
- Streng vertraulich: hochkritische Informationen (z. B. M&A-Unterlagen, Schlüsselmaterial, Sicherheitsarchitektur-Details, sensitive Personalakten).
Sonderfälle sollten explizit markiert werden, statt sie irgendwo „mitlaufen“ zu lassen: personenbezogene Daten, Geheimhaltungsvereinbarungen, regulierte Inhalte (z. B. Gesundheitsdaten) oder besonders schützenswerte IP. Diese Sonderfälle können als „Attribute“ zusätzlich zur Klasse geführt werden (z. B. „Vertraulich + personenbezogen“).
Definitionen müssen als Beispiele lesbar sein
Abstrakte Definitionen („jede Information mit hohem Schadenspotenzial“) werden im Alltag selten korrekt angewendet. Besser: pro Klasse 8–12 typische Beispiele, zusätzlich 3–5 Gegenbeispiele („sieht harmlos aus, ist es aber nicht“). Ein Klassiker: „Projektname ohne Kontext“ wirkt intern – kann aber in Kombination mit Zeitplan oder Kundenbezug schnell vertraulich werden.
Grenzfälle über ein kurzes Entscheidungsprinzip lösen
Wenn Unsicherheit bleibt, helfen zwei Leitfragen: (1) Würde die Veröffentlichung dieser Information dem Unternehmen, Kunden oder Mitarbeitenden schaden? (2) Ist die Information rechtlich oder vertraglich gebunden (Datenschutz, NDA, Berufsgeheimnis)? Bei „Ja“ mindestens „Vertraulich“, bei starkem Schaden „Streng vertraulich“.
Regeln ableiten: welche Klasse darf in welches GenAI-Setup?
Drei typische GenAI-Betriebsarten
In der Praxis existieren meist mehrere Zielsysteme mit unterschiedlichem Schutzprofil. Für die Zuordnung zählen: Datenverarbeitung, Mandantentrennung, Protokollierung, Zugriffsmodelle und ob Eingaben für Training/Verbesserung genutzt werden. Eine Datenklasse ist erst dann operational, wenn sie an erlaubte Nutzungsszenarien gekoppelt ist.
| Datenklasse | Öffentliches GenAI-Tool | Unternehmens-GenAI (Tenant/Policy) | Geschützte Umgebung (z. B. isoliert/on-prem) |
|---|---|---|---|
| Öffentlich | Erlaubt | Erlaubt | Erlaubt |
| Intern | Nur, wenn Richtlinie es explizit erlaubt und keine sensiblen Attribute | Erlaubt nach Policy | Erlaubt |
| Vertraulich | In der Regel nicht | Erlaubt mit Schutzmaßnahmen (z. B. Maskierung, Zugriff) | Erlaubt |
| Streng vertraulich | Nicht | Nur in Ausnahmefällen mit Freigabeprozess | Erlaubt, aber nur für berechtigte Rollen |
Diese Matrix ist absichtlich generisch: Sie muss an das reale Setup angepasst werden. Dabei hilft, Zugriffe und Protokolle sauber zu gestalten.
Wichtig: „Erlaubt“ heißt nicht „unkontrolliert“
Selbst bei „Intern“ sollten Teams wissen, welche Eingaben tabu sind (z. B. Kundendaten). Besonders wirksam ist ein kurzer Standard: „Keine personenbezogenen Daten, keine Geheimnisse, keine Security-Details“ – ergänzt um Beispiele aus dem eigenen Betrieb.
Regeln für Ausgaben mitdenken
Auch Outputs können neue Risiken erzeugen: Zusammenfassungen können unbeabsichtigt personenbezogene Daten enthalten; generierter Code kann Lizenzrisiken oder Security-Issues tragen; rechtliche Texte können falsche Zusagen enthalten. Darum gehören zu jeder Datenklasse auch Output-Regeln: Reviewpflicht, Kennzeichnung, Ablageort, erlaubte Weitergabe.
Konkrete Schutzmaßnahmen für „Vertraulich“ ohne Arbeitsstopp
Maskieren, minimieren, segmentieren
In vielen Fällen reicht es, Daten zu reduzieren, statt sie komplett zu verbieten. Drei Muster sind praxistauglich:
- Datenminimierung: Nur den relevanten Ausschnitt verwenden, keine ganzen Akten oder Postfächer.
- Maskierung: Namen, E-Mail, IDs, Kontonummern durch Platzhalter ersetzen (z. B. „KUNDE_01“).
- Segmentierung: Inhalte in Teile trennen, sodass kein vollständiges Bild entsteht (z. B. erst Strukturfragen, dann Formulierung ohne Details).
Maskierung ist allerdings nur dann wirksam, wenn Re-Identifikation unwahrscheinlich ist. Bei kleinen Kundengruppen oder einzigartigen Fällen kann auch eine anonymisierte Beschreibung noch identifizierbar sein.
Rollenbasierte Nutzung statt Tool-Wildwuchs
Nicht jede Rolle braucht Zugriff auf jede Funktion: Datei-Uploads, Connectoren in Drittsysteme oder Exportmöglichkeiten erhöhen das Risiko. Eine einfache Rollentrennung („Nutzer“, „Power-User“, „Admins“) plus dokumentierte Ausnahmen reduziert den Entscheidungsaufwand.
Protokollierung als Sicherheitsnetz
Auditierbarkeit ist kein Selbstzweck: Logs helfen, Fehlverhalten zu erkennen, Hotspots zu identifizieren (z. B. eine Abteilung kopiert regelmäßig Vertragsauszüge) und Schulung gezielt nachzuschärfen. Dabei sollten Logdaten selbst wieder klassifiziert werden, da sie Inhalte enthalten können.
Typische Stolperfallen bei der Einführung
Zu viele Klassen, zu wenig Entscheidungshilfe
Sechs bis acht Klassen wirken präzise, scheitern aber oft an der Anwendung. Wenn Mitarbeitende länger als wenige Sekunden überlegen müssen, wird die Regel umgangen. Besser sind wenige Klassen und klare Attribute (z. B. „personenbezogen“, „NDA“, „Security“).
„Intern“ wird zur Müllklasse
Wenn „Intern“ alles umfasst, was nicht öffentlich ist, werden Risiken unterschätzt. Eine harte Kante ist nötig: Kundendaten, nicht öffentliche Preise, Vertragsinhalte und Security-relevante Informationen sind praktisch nie „nur intern“.
Fehlende Verknüpfung mit Tools und Workflows
Eine PDF-Richtlinie allein ändert kein Verhalten. Wirksam wird Klassifizierung erst, wenn sie in GenAI-Eingabemasken (Hinweise), in Freigabeprozesse (für Ausnahmen), in Vorlagen und in Schulungen landet.
Ein Ablauf, der in 2–4 Wochen startklar wird
Kleiner Start, klare Verantwortungen
Für einen schnellen, kontrollierten Einstieg braucht es kein Großprojekt, sondern ein fokussiertes Paket: Klassen, Beispiele, Tool-Matrix, Kommunikationsbausteine. Fachbereiche liefern reale Beispielartefakte, Security/Compliance definiert Mindestanforderungen, IT setzt Policies um.
Praktische Schritte für das Einführen im Team
- Inventar erstellen: Welche GenAI-Tools sind im Einsatz, welche Daten wandern hinein?
- Vier Klassen definieren und pro Klasse Beispiele/Gegenbeispiele aus dem eigenen Alltag sammeln.
- Nutzungsmatrix pro Tool festlegen: Was ist erlaubt, was nur mit Maskierung, was verboten?
- Kurze Textbausteine für Prompts/Guidelines bereitstellen (z. B. „keine Kundennamen, keine IDs“).
- Freigabeweg für Ausnahmen definieren (wer entscheidet, wie dokumentiert, wie lange gültig).
- Stichproben und Feedback-Kanal einrichten, um Regeln nachzuschärfen.
Besonders wichtig ist der Feedback-Kanal: Er zeigt, wo Regeln unklar sind oder die Realität nicht abbilden. So bleibt Klassifizierung lebendig, ohne ständig neu erfunden zu werden.
Kurze Einordnung häufiger Praxisfragen
Dürfen personenbezogene Daten in ein Unternehmens-GenAI?
Das hängt von Zweck, Rechtsgrundlage, Vertragssituation und technischen Schutzmaßnahmen ab. In der Praxis wird häufig ein „nur mit Minimierung/Maskierung“ etabliert, plus feste Regeln für sensible Kategorien. Wenn personenbezogene Daten regelmäßig gebraucht werden, sollte das als eigener Use Case geplant werden – mit dokumentierten Prozessen und Zugriffen.
Wie wird mit Quellcode umgegangen?
Quellcode ist häufig IP und kann Sicherheitsrelevanz haben. Ein sinnvoller Ansatz ist: öffentliches Open-Source-Beispielcode kann „öffentlich“ sein, Produktivcode mindestens „vertraulich“, sicherheitskritische Bereiche „streng vertraulich“. Zusätzlich sollten Reviews für generierten Code festgelegt werden (Security, Lizenzen, Tests).
Reicht eine Schulung zum Start?
Schulung hilft, ersetzt aber keine Tool- und Prozessintegration. Besonders wirksam ist die Kombination aus kurzer Schulung, sichtbaren UI-Hinweisen, Vorlagen und einer klaren Matrix „Datenklasse → erlaubte Nutzung“. So wird korrektes Verhalten zur Standardoption.
