KI, Code und Datenschutz: Was ISO 27001 und Compliance wirklich verlangen

KI-gestützte Entwicklung ist längst Normalität. Teams nutzen GitHub Copilot, Cursor, Windsurf oder ChatGPT, um schneller Code zu schreiben, Bugs zu erklären und Daten zu analysieren. Dahinter verbirgt sich jedoch ein Sicherheitsproblem, das viele Unternehmen unterschätzen: Sobald KI Tools Zugriff auf Quellcode, Kundendaten oder interne Dokumente bekommt, entstehen neue Angriffsflächen – und neue Pflichten für ISO 27001, DSGVO und branchenspezifische Compliance.

Dieser Artikel zeigt, worauf es bei der Nutzung von KI im Entwicklungsalltag ankommt, welche Anforderungen Standard und Gesetz stellen und wie Sie Risiken ohne Innovationsbremse beherrschen.

Wie KI den Sicherheits-Status quo verändert

Traditionell lag die Verantwortung für sicheren Code beim Entwicklungsteam: Code-Reviews, statische Analysen, Penetrationstests und klare Richtlinien sollten Schwachstellen verhindern. KI-Tools verändern diesen Prozess auf drei Ebenen:

1. Unbekannte Herkunft des Codes: KI-generierte Snippets stammen aus Millionen öffentlicher Quellen. Sie können Lizenzkonflikte, veraltete Patterns oder bekannte Sicherheitslücken enthalten, ohne dass das Team es sofort erkennt.
2. Datenfluss in Drittsysteme: Viele KI-Dienste verarbeiten Eingaben in der Cloud. Wer Quellcode, Logs oder personenbezogene Daten in einen Prompt kopiert, gibt sie möglicherweise an Anbieter weiter – mit unklaren Speicher- und Trainingsbedingungen.
3. Geschwindigkeit vor Sorgfalt: KI produziert überzeugend klingenden Code. Unter Zeitdruck wird seltener hinterfragt, ob Validierung, Fehlerbehandlung und Sicherheitskonzepte wirklich passen.

Diese Verschiebung macht ein klares Regelwerk nötig. Genau dort setzen ISO 27001 und Datenschutzvorschriften an.

Code-Sicherheit: Die häufigsten KI-bedingten Risiken

Aus der Praxis lassen sich wiederkehrende Schwachstellen identifizieren, die durch unsachgemäßen Einsatz von KI verstärkt werden:

• Hartcodierte Secrets: API-Keys, Datenbankpasswörter oder private Tokens tauchen in generiertem Code auf, weil die KI Beispiele aus Repositories reproduziert.
• Unzureichende Eingabevalidierung: Formulare, Uploads und API-Endpunkte werden ohne korrekte Sanitisierung umgesetzt – ein klassischer Weg zu SQL-Injection, XSS oder Path-Traversal.
• Falsche Authentifizierung und Autorisierung: Rollenkonzepte werden oberflächlich umgesetzt, Sessions unsicher verwaltet oder CORS-Konfigurationen zu großzügig gewählt.
• Abhängigkeiten mit Schwachstellen: KI schlägt gerne Packages vor, die veraltet sind oder bekannte CVEs aufweisen, weil das Trainingsdatum hinter der aktuellen Sicherheitslage liegt.
• Datenschutzrelevante Daten im Training: Prompts, die echte Kundendaten enthalten, können in Modelle einspeisen oder zumindest bei Anbietern zwischengespeichert werden.

Wer KI im Entwicklungsprozess einsetzt, muss diese Risiken aktiv steuern – nicht nur technisch, sondern auch organisatorisch.

ISO 27001: Was für KI-Nutzung relevant wird

ISO 27001 ist kein KI-Standard im engeren Sinne, aber viele ihrer Kontrollen lassen sich direkt auf den KI-Einsatz übertragen. Besonders wichtig werden folgende Bereiche:

Informationssicherheits-Richtlinien (A.5)

Das Management muss klar kommunizieren, welche KI-Tools erlaubt sind, für welche Daten sie genutzt werden dürfen und wer die Verantwortung trägt. Eine interne KI-Nutzungsrichtlinie gehört hierher – inklusive Verboten für sensible Daten in öffentlichen Modellen.

Zugriffssteuerung (A.5.15, A.8.2)

Wer darf KI-Tools nutzen? Welche Rechte haben sie im Repository? Welche Daten dürfen in Prompts gelangen? Rollen und Berechtigungen müssen dokumentiert und regelmäßig geprüft werden.

Kryptographie und Schlüsselmanagement (A.8)

Secrets gehören niemals in Code oder Prompts. ISO 27001 verlangt einen kontrollierten Umgang mit Schlüsseln und Zugangsdaten. Tools wie Secret-Scanner in CI/CD-Pipelines, HashiCorp Vault oder Cloud-eigene Key-Management-Dienste sind hier Standard.

Betriebssicherheit (A.8)

Code-Reviews, automatisierte Sicherheitstests, Dependency-Scanning und sichere Deployment-Prozesse müssen auch für KI-generierten Code gelten. Die Tatsache, dass ein Mensch den Code abgenickt hat, reicht nicht aus, wenn die Prüfung selbst lückenhaft ist.

Lieferantenmanagement (A.5.19, A.5.20)

KI-Anbieter sind Lieferanten wie jeder andere. ISO 27001 verlangt eine Bewertung der Informationssicherheit bei Dienstleistern. Dazu gehören Fragen zu Datenspeicherung, Unterauftragsverarbeitung, Verfügbarkeit, Incident-Management und – bei personenbezogenen Daten – einem Auftragsverarbeitungsvertrag nach DSGVO.

Incident-Management (A.5.24 – A.5.26)

Was passiert, wenn ein KI-Tool versehentlich sensible Daten verarbeitet oder generierter Code eine Sicherheitslücke einführt? Es braucht klare Eskalationswege, Meldeverfahren und Lessons-Learned-Prozesse.

Aufzeichnung und Nachweis (A.5.36)

ISO 27001 verlangt Beweise für den Betrieb des ISMS. Das umfasst auch Logs zur KI-Nutzung: wer welches Tool wann für welche Daten verwendet hat, welche Sicherheitsprüfungen stattgefunden haben und wie Vorfälle behandelt wurden.

DSGVO und Datenschutz: Was zusätzlich gilt

Wenn personenbezogene Daten ins Spiel kommen, greift die DSGVO. Für den KI-Einsatz bedeutet das:

• Rechtsgrundlage prüfen: Die Verarbeitung personenbezogener Daten in KI-Systemen muss auf einer zulässigen Rechtsgrundlage beruhen – etwa Vertragserfüllung, berechtigtes Interesse oder Einwilligung.
• Auftragsverarbeitung: Nutzt ein Anbieter personenbezogene Daten in seinem Namen, ist ein Auftragsverarbeitungsvertrag erforderlich. Bei vielen KI-Diensten ist das nicht selbstverständlich.
• Datenminimierung: Nur die Daten verwenden, die wirklich nötig sind. Echte Kundendaten haben in Test-Prompts oder öffentlichen Modellen nichts zu suchen.
• Transparenz: Betroffene müssen darüber informiert werden, dass ihre Daten durch KI-Systeme verarbeitet werden können – je nach Kontext in der Datenschutzerklärung oder durch gesonderte Information.
• Automatisierte Entscheidungen: Werden KI-Systeme für Entscheidungen mit Rechtswirkung oder ähnlich erheblicher Wirkung genutzt, gelten besondere Informations- und Widerspruchsrechte.

Hinweis: Dieser Artikel beschreibt technische und organisatorische Maßnahmen. Er ersetzt keine Rechtsberatung. Bei konkreten Compliance-Fragen sollten Sie einen Datenschutzbeauftragten oder Rechtsanwalt einbinden.

Praktische Maßnahmen für Teams

Ein pragmatischer Ansatz funktioniert in fünf Schritten:

1. Inventur der KI-Tools Welche Tools nutzt das Team heute? Welche Daten fließen hinein? Wer hat Zugriff? Ohne diese Übersicht lassen sich Risiken nicht bewerten.

2. Klar definierte Regeln Erlaubte Tools, verbotene Anwendungsfälle, Datenklassen, die niemals in Prompts gehören, und Pflichten wie Code-Review und Security-Scan vor dem Merge.

3. Technische Absicherung

   • Secret-Scanning in Repositories und CI/CD
   • Statische Sicherheitsanalyse (SAST) für KI-generierten Code
   • Dependency-Scanning auf bekannte Schwachstellen
   • Prompt-Monitoring bei selbst gehosteten oder unternehmenseigenen Modellen
   • Zugangsbeschränkungen zu KI-Tools über SSO und Rollen

4. Lieferantenbewertung Für jeden KI-Anbieter Dokumentation anfordern: Wo werden Daten verarbeitet? Werden sie gespeichert? Fließen sie ins Training? Gibt es einen AVV? Ist eine Enterprise-Version mit DSGVO-Konformität verfügbar?

5. Regelmäßige Überprüfung KI-Tools entwickeln sich schnell. Mindestens einmal im Jahr sollten Richtlinien, Tools und Lieferanten neu bewertet werden – oder bei neuen Funktionen, die Datenverarbeitung ändern.

Fazit

KI ist ein leistungsstarker Entwicklungshelfer, aber kein Selbstläufer in Sachen Sicherheit. Wer KI produktiv nutzt, muss die gleichen Standards an Code-Qualität, Datenschutz und Lieferantenmanagement anlegen wie bei manuell erstelltem Code. ISO 27001 und DSGVO bieten dafür den passenden Rahmen – vorausgesetzt, die Regeln werden konsequent umgesetzt und regelmäßig geprüft.

Wer unsicher ist, wo im eigenen Stack die größten Risiken liegen, sollte mit einer gezielten Sichtung beginnen: Welche Daten fließen wohin, welche Schwachstellen hat der aktuelle Code, und wo fehlen noch technische oder organisatorische Kontrollen? Genau das ist der Ausgangspunkt für jeden nachhaltigen Sicherheitsprozess.