Projektdokumentation KI-Assistent ohne echte Zugangsdaten

Nicht in die Datei gehören Zugangsdaten, API-Keys, Kundennamen ohne Freigabe, Serveradressen, Anwendungskennungen, interne Pfade, produktive Konfigurationen und alles, was der Assistent bei jedem Lauf mitliest. Die Codeablage ist keine sichere Ablage — sie ist der Ort, an dem viele Beteiligte lesen, kopieren und suchen.

Die Negativliste schützt nicht nur vor Lecks, sondern macht Arbeit planbar. Wenn der Assistent einen echten Wert nie sieht, kann er ihn auch nicht in eine Änderung ziehen.

Der erlaubte Ersatz ist knapp: Statt der Kennung ein Platzhalter und der Satz, wo die echte steht. Der Assistent kommt damit weiter, der Leser der Codeablage nicht.

Eine Datei, die ein Agent bei jedem Lauf liest, ist ein Verteiler — was drinsteht, geht mit. Inhalte aus der Projektdokumentation fließen in Aufgaben, Vorschläge, Codeänderungen und Antworten ein.

Damit verlässt ein Geheimnis seinen ursprünglichen Schutzbereich, ohne dass jemand es bewusst weitergeben wollte. Niemand hat etwas falsch gemacht. Die Datei hatte nur die falsche Rolle.

Bei KI-gestützter Entwicklung zählt deshalb nicht nur der Befehl an den Assistenten. Entscheidend ist die Grenze zwischen Arbeitsanweisung und Betriebsinformation.

Erlaubt sind Platzhalter, Verweise auf geschützte Ablagen, Verantwortlichkeiten, Namenskonventionen, Umgebungsnamen und Erklärungen zur Nutzung ohne Geheimnisse. Ein Platzhalter beschreibt die Form eines Werts, nicht den Wert selbst.

Der Assistent braucht genug Struktur, um eine Datei zu ändern oder einen Ablauf zu verstehen. Er braucht aber keinen produktiven Servernamen, kein echtes Kennwort und keinen Kundennamen aus einem laufenden Vertrag.

Gute Einträge lesen sich wie Anweisungen für Ersatzwerte: PROJEKT_SCHLUESSEL kommt aus der geschützten Umgebung. Daneben steht, welche verantwortliche Person den echten Wert pflegt und welche Umgebung ihn bereitstellt.

Die echten Werte stehen in Umgebungsvariablen, in einer Geheimnisverwaltung oder in einer anderen geschützten Betriebsumgebung. Die Projektdokumentation nennt diesen Ort, aber sie wiederholt den Inhalt nicht.

Vorlagen enthalten nur Platzhalter, weil eine Vorlage oft in neue Zweige und neue Projekte wandert. Wer dort echte Werte einträgt, verteilt sie mit jeder Kopie weiter.

Eine Umgebungsvariable ist ein benannter Wert, den der Betrieb zur Laufzeit bereitstellt. Der Assistent darf den Namen kennen — den gespeicherten Wert braucht er für seine Aufgabe nicht.

Die Regel wird überprüfbar, wenn sie vor dem Zusammenführen einen festen Prüfweg hat. Der Prüfweg muss klein genug sein, damit jede Änderung ihn wirklich durchläuft:

Die harte Gegenprobe lautet: Der Vorgang muss ohne echten Wert erklärbar bleiben. Wenn eine Kennung nur erklärt, welche Stelle befüllt wird, darf sie ins Dokument.

Regeln, Verantwortung und Freigaben ersetzen Bauchgefühl. So wird aus einer Sicherheitserinnerung eine prüfbare Arbeitsweise — besonders bei langen Projektlaufzeiten.

Besonders oft landen kopierte Umgebungen, echte Testzugänge, produktive Servernamen und Kundendaten in Dateien, die dafür zu offen sind. Der Fehler entsteht meist beim schnellen Helfen, nicht aus Absicht.

Der gemeinsame Nenner ist die Wiederverwendung. Was einmal in einer Vorlage steht, taucht später in Aufgaben, Kopien, Zweigen und Assistentenläufen auf.

Die Projektdokumentation bleibt nutzbar, wenn sie Struktur, Zweck und sichere Verweise trennt. Der Assistent kann mit Platzhaltern arbeiten, sobald Namen, Zuständigkeiten und Umgebungen stabil beschrieben sind.

Eine stabile Projektdatei ähnelt einer CLAUDE.md, die nach sechs Monaten noch stimmt: knapp, aktuell und ohne verdeckte Geheimnisse. Sie erklärt den nächsten Arbeitsschritt, aber sie ersetzt keine geschützte Betriebsablage.

Saubere Dokumentations- und Automatisierungsprozesse beginnen an dieser Trennlinie. Wer sie einhält, gibt dem Assistenten Orientierung und hält echte Werte dort, wo der Betrieb sie kontrolliert.