KI-Prompts in der Webentwicklung: Welche Projektdaten darfst du eingeben?

„Solange du keine Passwörter einfügst, ist ein KI-Prompt unkritisch“ ist eine verbreitete Faustregel. Sie reicht für reale Webprojekte nicht aus. Auch harmlose Codeausschnitte, Fehlermeldungen und Screenshots können Kundendaten, interne Adressen oder vertrauliche Geschäftslogik enthalten. Behandle deshalb jede Eingabe als bewusste Datenweitergabe und beschränke sie auf das Material, das zur konkreten Frage nötig ist.

Das Risiko steckt selten in der offensichtlichen Frage

Beim Einsatz von KI möchtest du beispielsweise einen Fehler erklären lassen, eine Datenbankabfrage prüfen oder eine verwirrende Fehlermeldung einordnen. Die eigentliche Frage ist meistens unkritisch. Problematisch wird das Material, das du zur Erklärung mitlieferst.

Ein vollständiger Logauszug kann E-Mail-Adressen, IP-Adressen, Bestellnummern, Session-IDs und interne Pfade enthalten. In einem kopierten HTTP-Request stehen möglicherweise Cookies oder Autorisierungs-Header. Selbst ein kurzer Ausschnitt aus einer Konfigurationsdatei kann Zugangsdaten verraten, wenn du ein paar Zeilen zu großzügig markierst.

Zum Prompt gehören außerdem nicht nur die Wörter im Eingabefeld. Hochgeladene Dateien, Screenshots, automatisch eingebundene Dateien eines Editors und freigegebener Repository-Kontext sind ebenfalls Eingaben. Entscheidend ist daher nicht, was du bewusst tippst, sondern was das verwendete Werkzeug tatsächlich überträgt.

Ordne Projektdaten nach ihrem Schutzbedarf ein

Eine brauchbare Entscheidung beginnt mit der Art der Daten. Dafür brauchst du kein kompliziertes Klassifizierungssystem. Vier Gruppen reichen für den Projektalltag meist aus.

Öffentliche und allgemeine Informationen

Öffentliche Dokumentation, frei zugänglicher Quellcode und selbst formulierte Minimalbeispiele kannst du in der Regel verwenden. Prüfe trotzdem, ob dein Ausschnitt versehentlich interne Kommentare, Dateipfade oder projektspezifische Bezeichner enthält.

Interne technische Informationen

Dazu gehören eigene Datenmodelle, unveröffentlichte Funktionen, interne URLs, Architekturdetails und projektspezifischer Quellcode. Solche Informationen sind nicht automatisch geheim. Sie sollten aber nur in ein dafür freigegebenes Werkzeug gelangen und auf den notwendigen Ausschnitt reduziert werden.

Personenbezogene oder vertraglich geschützte Daten

Kundendaten, Supportnachrichten, Nutzungsprotokolle und Produktionsdaten brauchen eine gesonderte Prüfung. Bei personenbezogenen Daten gilt unter anderem der Grundsatz der Datenminimierung aus Artikel 5 der Datenschutz-Grundverordnung. Für deinen Arbeitsalltag bedeutet das: Wenn Namen, Kontaktdaten oder eindeutige Kennungen zur technischen Analyse nicht benötigt werden, entfernst oder ersetzt du sie.

Ob eine konkrete Verarbeitung zulässig ist, hängt außerdem vom Zweck, der Rechtsgrundlage, vertraglichen Vereinbarungen und dem eingesetzten Dienst ab. Ein kurzer Hinweis im Prompt wie „Bitte vertraulich behandeln“ ersetzt diese Prüfung nicht.

Zugangsdaten und andere Geheimnisse

API-Schlüssel, Passwörter, private Schlüssel, Session-Cookies, Datenbankzugänge und produktive Tokens gehören nicht in einen KI-Prompt. Für die Fehleranalyse wird normalerweise nur die Struktur benötigt, etwa dass ein Header vorhanden ist oder ein Schlüssel ein bestimmtes Format haben soll. Verwende dafür Platzhalter wie BEARER_TOKEN oder DATABASE_PASSWORD.

Vollständige Datenbankexporte, Backups und Produktionskonfigurationen sind ebenfalls ungeeignete Analysepakete. Sie enthalten fast immer mehr Informationen als nötig und sind schwer zuverlässig zu bereinigen.

Baue ein minimales Analysepaket statt eines Datenauszugs

Die sicherste Eingabe ist nicht die am stärksten geschwärzte Datei, sondern ein neu zusammengestelltes Paket mit genau den Informationen, die zur Frage gehören. Beginne deshalb nicht mit dem Kopieren, sondern formuliere zuerst das Problem in einem Satz.

Ein brauchbares Analysepaket enthält typischerweise:

• das erwartete Verhalten,
• das tatsächlich beobachtete Verhalten,
• eine gekürzte Fehlermeldung,
• den kleinsten betroffenen Codeausschnitt,
• synthetische Beispieldaten,
• relevante technische Rahmenbedingungen.

Synthetische Daten sind eigens für den Test erzeugte Werte ohne Bezug zu echten Personen oder Geschäftsvorgängen. Aus einer produktiven Bestellung wird beispielsweise ein Objekt mit der Bestellnummer TEST-1001, der Adresse test@example.invalid und einem frei erfundenen Betrag. Wichtig ist, dass Struktur und Datentypen erhalten bleiben. Die echten Inhalte werden für die technische Frage meistens nicht gebraucht.

Bei einem fehlerhaften Checkout musst du daher nicht das komplette Supportticket, den Datensatz aus der Produktion und den gesamten Controller übergeben. Häufig genügen die gekürzte Exception, die betroffene Methode und ein künstliches Eingabeobjekt. Falls die Antwort damit nicht weiterführt, kannst du gezielt eine weitere Information ergänzen. Umgekehrt bekommst du einmal weitergegebene Daten nicht durch einen besonders höflichen Folgeprompt zurück.

Bereinige Daten nach ihrem Inhalt, nicht nur nach Stichwörtern

Ein globales Suchen und Ersetzen nach E-Mail-Adressen entfernt nur die auffälligen Stellen. Vertrauliche Informationen stecken oft in technischen Zusammenhängen, die kein einfaches Muster abdeckt.

Prüfe bei typischen Projektartefakten besonders diese Bereiche:

• Logs: IP-Adressen, Benutzerkennungen, Request-Parameter, Dateipfade und Inhalte aus Formularen.
• HTTP-Anfragen: Cookies, Autorisierungs-Header, Query-Parameter und Request-Bodys.
• HAR-Dateien: Ein HTTP Archive zeichnet Netzwerkverkehr aus dem Browser auf und kann Header, Cookies sowie übertragene Formulardaten enthalten.
• Screenshots: Namen, Browser-Tabs, Domains, Benachrichtigungen und sichtbare Datensätze außerhalb des markierten Fehlers.
• Quellcode: interne Domains, Kommentare, Zugangsdaten, Mandantenbezeichnungen und Geschäftsregeln.
• Git-Daten: Namen und E-Mail-Adressen von Autoren, Commit-Nachrichten und Verweise auf interne Tickets.

Ersetze nicht nur einzelne Werte, sondern löse auch unnötige Beziehungen auf. Mehrere unterschiedliche Kundenkennungen sollten beispielsweise nicht durch denselben Platzhalter ersetzt werden, wenn ihre Verschiedenheit für den Fehler relevant ist. Verwende dann neutrale Werte wie CUSTOMER_A und CUSTOMER_B. So bleibt die technische Aussage erhalten, ohne reale Identitäten mitzuschleppen.

Prüfe das Zielsystem vor dem ersten Projekt-Prompt

Die Datenfreigabe hängt nicht allein vom Inhalt ab. Du musst auch wissen, in welches System du ihn eingibst. Ein privat angelegtes Konto, ein freigegebener Unternehmenszugang und eine vertraglich eingebundene API sind aus organisatorischer Sicht nicht dasselbe.

Vor dem Projekteinsatz sollten mindestens folgende Fragen geklärt sein:

• Ist das Werkzeug für diese Datenart intern freigegeben?
• Welche Inhalte werden gespeichert und wie lange?
• Wer kann innerhalb und außerhalb deines Unternehmens darauf zugreifen?
• Werden Eingaben für das Training oder andere Zwecke verwendet, und welche Einstellungen gelten für den verwendeten Tarif?
• Welche vertraglichen und datenschutzrechtlichen Vereinbarungen bestehen?
• Lässt sich eine Unterhaltung oder hochgeladene Datei nachvollziehbar löschen?

Diese Angaben ändern sich je nach Anbieter, Produkt und Vertragsmodell. Verlasse dich daher nicht auf allgemeine Aussagen über „die KI“. Maßgeblich sind die Bedingungen und Einstellungen des konkreten Zugangs, den du tatsächlich verwendest.

Auch eine lokal betriebene Lösung hebt die Prüfung nicht auf. Sie verlagert Verantwortung auf deine eigene Infrastruktur und kann weiterhin externe Modelle, Protokollierung oder eingebundene Dienste nutzen. „Läuft bei uns“ ist eine technische Ortsangabe, noch kein Datenschutzkonzept.

Kontrolliere automatisch eingebundenen Kontext

KI-Funktionen in Entwicklungsumgebungen können neben deiner direkten Auswahl weiteren Kontext verwenden. Dazu können geöffnete Dateien, benachbarter Code, Terminalausgaben oder Teile eines Repositorys gehören. Das ist praktisch, solange du weißt, welche Informationen das Werkzeug einbezieht.

Prüfe vor der Nutzung in einem Kundenprojekt:

1. Welche Dateien oder Ordner sind für die Funktion erreichbar?
2. Wird nur eine Auswahl übertragen oder zusätzlicher Kontext automatisch ergänzt?
3. Lassen sich sensible Verzeichnisse wie Konfigurationen, Exporte und Backups ausschließen?
4. Ist im Interface erkennbar, welche Anhänge und Dateien zum Prompt gehören?

Öffne für eine kleine Frage nicht vorsorglich das gesamte Repository. Stelle den Ausschnitt bewusst zusammen und kontrolliere die angezeigten Anhänge vor dem Absenden. Komfortfunktionen sind gelegentlich sehr gründlich. Das ist nicht immer ein Vorteil.

Lege eine kurze Teamregel für KI-Eingaben fest

Wenn mehrere Personen KI-Werkzeuge verwenden, führen individuelle Bauchentscheidungen zu uneinheitlichen Ergebnissen. Eine kurze interne Regel ist hilfreicher als ein langer Leitfaden, den niemand während eines Supportfalls liest.

Eine praktikable Ampel kann so aussehen:

• Grün: öffentliche Informationen, generische Beispiele und vollständig synthetische Daten dürfen in freigegebenen Werkzeugen verwendet werden.
• Gelb: interner Code, projektspezifische Strukturen und bereinigte Logs brauchen ein freigegebenes Konto sowie eine bewusste Prüfung.
• Rot: Zugangsdaten, vollständige Produktionsdaten, nicht bereinigte Kundendaten und vertraglich ausgeschlossene Inhalte dürfen nicht eingegeben werden.

Ergänze einen Ansprechpartner für Grenzfälle und eine klare Standardentscheidung: Ist die Datenart oder das Werkzeug unbekannt, wird zunächst nichts übertragen. Das kostet im Zweifel eine Rückfrage. Eine versehentlich veröffentlichte Produktionskonfiguration verursacht üblicherweise den unentspannteren Nachmittag.

Reagiere auf versehentlich übertragene Daten wie auf einen Sicherheitsvorfall

Wenn du einen Schlüssel oder andere sensible Daten eingegeben hast, genügt es nicht, die Unterhaltung zu löschen. Zugangsdaten müssen widerrufen oder rotiert werden, damit der alte Wert nicht mehr funktioniert.

Halte außerdem fest, welche Informationen an welches System übertragen wurden. Informiere die intern verantwortliche Person und prüfe, ob Kunden-, Vertrags- oder Personendaten betroffen sind. Für solche Fälle sollte der bestehende Sicherheits- oder Datenschutzprozess genutzt werden. Die konkrete Reaktion hängt vom Inhalt und vom verwendeten Dienst ab.

Bei weniger kritischen internen Informationen kann eine dokumentierte Prüfung ausreichen. Bei produktiven Zugangsdaten ist sofortiges technisches Handeln nötig. Entscheidend ist nicht, ob du eine missbräuchliche Nutzung beobachtet hast, sondern ob ein zuvor geschütztes Geheimnis außerhalb des vorgesehenen Bereichs gelandet ist.

Wann du auf die KI-Eingabe verzichten solltest

Manche Probleme lassen sich nur erklären, wenn du so viel Kontext übergeben müsstest, dass eine zuverlässige Bereinigung kaum möglich ist. Dann ist ein lokaler Debugger, ein gezielter Test oder die Analyse durch eine berechtigte Person der bessere Weg.

Verzichte auf die Eingabe insbesondere dann, wenn:

• du die Daten nicht sicher klassifizieren kannst,
• vertragliche Vorgaben die Weitergabe ausschließen,
• kein freigegebenes Werkzeug verfügbar ist,
• der Fehler nur mit einem vollständigen Produktionsdatensatz reproduzierbar ist,
• durch die Bereinigung genau der fachliche Zusammenhang verloren geht, den du untersuchen möchtest.

KI ist bei klar abgegrenzten Fragen besonders nützlich. Wenn das Problem nur durch das Abladen eines kompletten Projekts verständlich wird, fehlt häufig zuerst eine saubere Reproduktion.

Fazit: Übertrage eine technische Frage, keinen Projektbestand

Ob Projektdaten in einen KI-Prompt gehören, entscheidet sich an drei Punkten: Du brauchst einen klaren Zweck, ein minimales Analysepaket und ein für diese Daten freigegebenes Zielsystem. Öffentliche und synthetische Inhalte sind meist unkompliziert. Interner Code und bereinigte Logs verlangen eine bewusste Prüfung. Zugangsdaten, vollständige Produktionsbestände und ungefilterte Kundendaten bleiben draußen.

Der praktikable Standard lautet daher: Formuliere die Frage zuerst, rekonstruiere nur den nötigen Kontext und kontrolliere anschließend alle übertragenen Dateien und Anhänge. So wird KI zu einem gezielten Hilfsmittel in der Webentwicklung, statt zu einem zusätzlichen Ort, an dem dein Projekt versehentlich herumliegt.