Eine KI kann aus einem Kundenbriefing eine Sitemap, einen Textentwurf oder einen Codevorschlag erstellen. Dafür muss sie nicht automatisch den echten Namen, die E-Mail-Adresse oder vertrauliche Vertragsdetails erhalten. Entscheidend ist, vor dem Hochladen zu prüfen: Welche Informationen werden für die Aufgabe wirklich gebraucht?
Dieser Beitrag beschreibt einen technischen Arbeitsprozess. Er ist keine Rechtsberatung und ersetzt keine datenschutzrechtliche Prüfung des konkreten KI-Dienstes, Vertrags oder Verarbeitungsvorgangs.
Welche Daten sind besonders kritisch?
Dazu zählen personenbezogene Informationen, Zugangsdaten, nicht öffentliche Projektdokumente, Rechnungen, Verträge, interne Geschäftsstrategien und Informationen über Dritte. Die OWASP-Risikoliste für generative KI warnt ausdrücklich vor der Offenlegung sensibler Informationen durch KI-Anwendungen.
Ein Beispiel aus der Webentwicklung: Ein technisches Problem an einer Kontaktseite lässt sich meist auch ohne den echten Kundenname, dessen Telefonnummer oder dessen SMTP-Passwort besprechen.
Der sichere Arbeitsablauf beginnt vor dem Prompt
1. Auftrag und notwendige Daten festlegen
Formuliere das Problem zuerst abstrakt: „Optimiere das responsive Kontaktformular einer Astro-Seite.“ Für die Analyse reichen oft HTML-Struktur, CSS-Klassen und ein synthetischer Testdatensatz.
2. Inhalte lokal klassifizieren
Trenne bewusst zwischen:
- Öffentlichen Angaben: bereits freigegebene Firmenanschrift oder sichtbare Leistungsbeschreibungen.
- Internen Arbeitsdaten: unveröffentlichte Preislisten, Angebote oder Projektentscheidungen.
- Vertraulichen Daten: personenbezogene Datensätze, Kennwörter, Tokens, Zugangsdaten und kundenspezifische Geheimnisse.
Nicht alles Öffentliche muss verschleiert werden. Vertrauliche Inhalte sollten dagegen standardmäßig außerhalb von KI-Prompts bleiben.
3. Identifizierende Werte durch Platzhalter ersetzen
Aus einem realen Briefing kann beispielsweise werden:
| Ursprünglicher Wert | Pseudonym |
|---|---|
| Name einer Kontaktperson | PERSON_001 |
| Interne Projektadresse | PROJEKT_URL_001 |
| E-Mail-Adresse | EMAIL_001 |
| Vertragssumme | BETRAG_001 |
Nutze synthetische Beispiele zum Testen. Die echte Zuordnungstabelle bleibt lokal unter Zugriffsschutz. Pseudonyme sind weiterhin nicht automatisch anonym. Je nach Zusatzwissen ist eine Rückzuordnung möglich.
4. Inhalte vor der Weitergabe manuell prüfen
Automatische Mustererkennung kann Namen, freie Texte, Kundennummern und Sonderfälle übersehen. Prüfe daher den vollständigen Export einschließlich Dateinamen, Kommentaren, Metadaten, Screenshots und Codebeispielen. Ein Regex-Scanner ist keine vollständige Datenschutzkontrolle.
5. Vertrauliche Originale geschützt ablegen
Verschlüssele lokal gespeicherte vertrauliche Daten mit einer etablierten Lösung. Achte auf Zugriffsschutz, getrennte Schlüssel, sichere Backups und ein getestetes Wiederherstellungsverfahren. Verschlüsselung schützt Daten bei Speicherung, entfernt aber keine Geheimnisse aus einem bereits versendeten Prompt.
6. Freigabe für den konkreten KI-Dienst klären
Prüfe vor jedem produktiven Einsatz die aktuellen Nutzungsbedingungen, organisatorischen Vorgaben, Verarbeitungskontexte und notwendigen Vereinbarungen. Ein privates Chatkonto, ein Teamangebot und eine API-Integration müssen nicht identische Regeln haben. Vertrauliche Daten nur weitergeben, wenn Rechtsgrundlage, Vertragslage und Schutzmaßnahmen passen.
Beispiel: Website-Code prüfen lassen
Ungünstig: „Hier ist das komplette Kundenrepository inklusive Konfiguration. Repariere bitte das Formular.“
Besser: „Hier ist eine reduzierte Astro-Komponente mit Testnamen und Dummy-Adressen. Prüfe Semantik, Validierung und Mobilansicht. Es sind keine echten Zugangsdaten enthalten.“
Der zweite Ansatz liefert meist denselben technischen Kontext und reduziert unnötige Offenlegung. Für die endgültige Übernahme in das echte Projekt ist weiterhin eine lokale Prüfung nötig.
Welche Grenzen bleiben?
- Eine Pseudonymisierung kann Informationen übersehen; Kombinationen von Merkmalen können identifizierend sein.
- Das Modell kann falsche Codeänderungen oder unpassende Datenschutzannahmen erzeugen.
- Lokale Backups, exportierte Dateien und temporäre Verzeichnisse benötigen eine eigene Lösch- und Schutzstrategie.
- Die Freigabe einer Datei für einen bestimmten Zweck bedeutet nicht automatisch eine Freigabe für jede spätere Verwendung.
Ein sinnvoller Standard für kleine Agenturen
Nutze für KI-Aufgaben minimalen Beispielcode, synthetische Daten, eine manuelle Exportprüfung und klar dokumentierte Zuständigkeiten. Bei personenbezogenen oder vertraulichen Originaldaten ist die interne Datenschutzprüfung ein eigener Arbeitsschritt.
Quellen und weiterführende Informationen
- OWASP: Sensitive Information Disclosure
- EU: Datenschutz-Grundverordnung (offizieller Gesetzestext)
- BSI: IT-Grundschutz
Bei Digitalhaus Kunze stehen technisch wartbare Websites und bewusster Umgang mit Daten im Mittelpunkt. Sensible Projektdateien werden nicht pauschal für KI-Funktionen vorausgesetzt.
War dieser Artikel hilfreich?
Dein Feedback hilft uns, unsere Ratgeber zu verbessern.
Mit Digitalhaus Kunze gearbeitet?
Dann freuen wir uns über deine ehrliche Erfahrung auf Google – unabhängig davon, ob sie positiv oder kritisch war.
Auf Google bewerten