KI & Sicherheit

Daten und KI-Kontext

Welche Projektdateien, Datenklassen und lokalen Inhalte nicht ungeprüft in KI-Kontexte gehören.

Stand: 2026-06-02

Kurzfassung

  • .gitignore schützt nicht den KI-Kontext.
  • .aiignore oder gleichwertige KI-Ausschlüsse sind Pflicht.
  • KI-IDEs ohne projektbezogene Ausschlussfunktion sind für Kundenprojekte nicht geeignet.
  • Secrets, Dumps, Logs, Backups, Produktionsdaten und echte Zugänge gehören nicht in den KI-Kontext.
  • KI-Regeln sollen vor der Arbeit prüfen, ob der Kontext sicher begrenzt ist.
  • CI/Pre-Push soll prüfen, ob .aiignore und KI-Regeln existieren und nicht abgeschwächt wurden.

Thema

Daten und Datenklassen beim Einsatz von KI-Tools im Entwickleralltag.

Ausgangslage

Im Team werden KI-Tools wie ChatGPT, Claude, Codex, OpenAI-Dienste und IDE-Assistenten wie PhpStorm AI oder ähnliche Werkzeuge genutzt oder sollen genutzt werden.

Tools dürfen in der Praxis Kundencode und Projektdateien sehen. Externe Entwickler arbeiten teilweise remote auf eigenen Rechnern mit lokal geklonten Repositories. Teilweise haben externe Entwickler echte Zugänge zu Staging- oder Produktionssystemen.

Die wichtigste praktische Erkenntnis:

.gitignore schützt Git. Es schützt nicht automatisch den KI-Kontext.

Risiko in einem Satz

Kundencode, lokale Projektdateien, Secrets, Logs, Dumps oder echte Zugangsdaten können durch Bequemlichkeit oder fehlende Ausschlüsse in private oder nicht zentral kontrollierte KI-Kontexte geraten.

Empfehlung

KI-gestützte IDEs und Assistenten sind in Kundenprojekten nur erlaubt, wenn sie projektbezogene Ausschlüsse für KI-Kontext unterstützen.

Für JetBrains/PhpStorm bedeutet das:

  • .aiignore ist Pflicht.
  • .aiignore muss im Projekt vorhanden und aktiviert sein.
  • .aiignore muss sensible Dateien und Ordner ausschließen.
  • Änderungen an .aiignore gelten als sicherheitsrelevant.

IDEs oder KI-Assistenten ohne vergleichbare Ausschlussfunktion sollen für Kundenprojekte nicht erlaubt sein.

Begründung

Das Hauptproblem ist nicht primär böswilliges Verhalten. Das größere Alltagsrisiko ist Bequemlichkeit:

  • jemand kopiert zu viel Kontext in einen Chat,
  • ein IDE-Assistent sieht mehr Projektdateien als beabsichtigt,
  • lokale .env-Dateien, Dumps oder Logs liegen im Projektordner,
  • externe Entwickler nutzen private KI-Accounts,
  • sensible Dateien sind zwar nicht versioniert, aber trotzdem lokal vorhanden.

Eine verpflichtende KI-Ausschlussdatei reduziert dieses Risiko mit wenig Aufwand.

P0-No-Gos

  • Keine Secrets, Tokens, SSH-Keys oder Passwörter in Prompts.
  • Keine Dumps, Logs, Backups oder Produktionsdaten im Projektordner.
  • Keine echten Zugangsdaten in Projektdateien, Tickets oder KI-Regeln.
  • Keine Produktionszugänge in privaten KI-Accounts oder Agenten.
  • Keine personenbezogenen Daten in KI-Tools ohne Freigabe.
  • Keine KI-IDE ohne .aiignore-ähnliche Ausschlussfunktion in Kundenprojekten.

Mindestinhalt einer .aiignore

# Environment and secrets
.env
.env.*
!.env.example
*.key
*.pem
*.p12
*.crt
id_rsa*
id_ed25519*

# Dumps, backups, databases, logs
*.sql
*.sqlite
*.db
dump/
dumps/
backup/
backups/
logs/
*.log

# Symfony
var/cache/
var/log/
.env.local
.env.*.local

# TYPO3
typo3conf/LocalConfiguration.php
typo3temp/
var/

# IDE and local metadata
.idea/

Der konkrete Inhalt muss pro Projekt geprüft werden.

Technische Empfehlung

Für jedes Kundenprojekt:

  • .aiignore im Repository pflegen.
  • Existenz und Mindestinhalt von .aiignore per CI oder Pre-Push prüfen.
  • Änderungen an .aiignore im Review sichtbar behandeln.
  • Zusätzlich lokale Sensitivdateien vermeiden, auch wenn sie in .gitignore stehen.
  • Externe Entwickler schriftlich auf diese Regel verpflichten.

KI-Regel-Anweisung zur Kontextprüfung

Zusätzlich zur technischen Prüfung sollte jedes Kundenprojekt eine KI-Regel-Anweisung enthalten, die den Agenten oder IDE-Assistenten zwingt, den Projektkontext vor der Arbeit zu prüfen.

Wichtig:

Diese KI-Regel ersetzt keine CI- oder Pre-Push-Prüfung. Sie ist eine zusätzliche Leitplanke gegen Bequemlichkeit und Schlamperei.

Empfohlene Regel:

Vor jeder Arbeit mit Projektdateien:

1. Prüfe, ob eine `.aiignore` oder gleichwertige KI-Ausschlussregel existiert.
2. Wenn keine `.aiignore` existiert, stoppe und weise darauf hin.
3. Verwende keine Dateien als KI-Kontext, die Secrets, Tokens, `.env`-Daten, Dumps, Logs, Backups, personenbezogene Daten oder Produktionsdaten enthalten können.
4. Behandle `.gitignore` nicht als KI-Schutz. Auch ignorierte lokale Dateien können für KI sichtbar sein.
5. Prüfe besonders Projektbereiche, die häufig sensible lokale Daten enthalten: `.env*`, `var/`, `logs/`, `backup/`, `dumps/`, `typo3temp/`, `typo3conf/LocalConfiguration.php`.
6. Änderungen an `.aiignore`, KI-Regeln oder Tool-Regeln sind sicherheitsrelevant und müssen im Review erwähnt werden.
7. Wenn der benötigte Kontext nur mit sensiblen Daten verständlich wäre, frage nach anonymisiertem oder reduziertem Kontext.

Diese Regel sollte nicht als private Prompt-Notiz gepflegt werden, sondern als sichtbare Projektregel, zum Beispiel in der jeweiligen Projektkonfiguration für KI-Tools oder Agenten.

Erwarteter Nutzen:

  • Agenten erinnern aktiv an .aiignore.
  • fehlende oder schwache Kontextgrenzen fallen früher auf.
  • sensible Projektbereiche werden nicht aus Bequemlichkeit in den KI-Kontext gezogen.
  • Änderungen an KI-Regeln und .aiignore werden als Security-Thema sichtbar.

Grenze:

Eine böswillige oder schlecht konfigurierte KI kann solche Regeln ignorieren. Deshalb bleibt die deterministische Prüfung per Script, CI oder Pre-Push notwendig.

Wichtige Grenze:

CI sieht keine lokalen, nicht versionierten Dateien auf Entwicklerrechnern.

Deshalb ersetzt CI keine lokale Sorgfalt. CI kann prüfen, ob das Projekt eine sinnvolle .aiignore vorgibt. Es kann aber nicht garantieren, dass ein externer Entwickler lokal keine sensiblen Dateien im Projektordner liegen hat.

Empfehlung für externe Entwickler

Externe Entwickler dürfen KI nutzen, aber nur mit begrenztem Kontext:

  • keine Secrets,
  • keine Dumps,
  • keine Logs,
  • keine Backups,
  • keine personenbezogenen Daten,
  • kein kompletter Projektordner in privaten KI-Accounts,
  • keine echten Zugänge im KI-Kontext,
  • KI-Unterstützung bei sicherheitsrelevanten Änderungen im Review offenlegen.

Vorgeschlagene Wandregel

.gitignore schützt Git. .aiignore schützt KI-Kontext. Beides ist nicht dasselbe.

Teamfragen zur Entscheidung

  • Welche KI-IDEs und Assistenten erfüllen unsere Mindestanforderung?
  • Welche Tools werden blockiert, weil sie keine Projekt-Ausschlüsse unterstützen?
  • Welche Pflichtpatterns gehören in unsere Standard-.aiignore?
  • Welche KI-Regel-Anweisung zur Kontextprüfung wird in Kundenprojekten vorgeschrieben?
  • Soll .aiignore per CI, Pre-Push oder beidem geprüft werden?
  • Wie wird geprüft, dass die KI-Regel-Anweisung existiert und nicht abgeschwächt wurde?
  • Welche Regel bekommen externe Entwickler schriftlich beim Onboarding?
  • Wie gehen wir mit bestehenden Projekten um, die noch keine .aiignore haben?