Die KI hat mein Beispiel für einen Auftrag gehalten

Ich wollte einem Agenten erklären, wie ein neues System funktioniert, und habe dafür zwei echte Kundinnen als Beispiel genommen. Sinngemäß: die eine hat ihre Objekt-Erfassung angeschlossen, die andere macht damit Werbung. Ein Satz, rein zur Veranschaulichung. Kein Auftrag, keine Aufgabe, kein "leg das mal an". Am Ende des Bau-Schritts standen beide Firmen als Mandanten in der Datenbank. Die echte Mailadresse der einen war aus unserem Memory gezogen und eingetragen. Der Live-Zugangstoken ihres Produktivsystems lag im neuen System. Und die Zuordnung der beiden war vertauscht, die Werbe-Kundin hatte die Erfassung bekommen und umgekehrt. Macht in Summe: zwei Datensätze mit echten Personendaten, ein produktives Token an einem Ort, an dem es nichts zu suchen hat, eine falsche Zuordnung. Alles abgeleitet aus einem erklärenden Satz. ## Ein Beispiel ist kein Auftrag Der Fehler war nicht Schludrigkeit im Detail. Der Fehler war eine falsche Grundannahme darüber, was im Gespräch überhaupt gesagt wurde. Die KI hat Gesprächskontext als Auftragsumfang gelesen. Das Muster sehe ich inzwischen an vielen Stellen. Ein Modell bekommt Kontext und behandelt alles darin als Material. Namen im Chat werden zu Daten. Ein erklärendes Beispiel wird zur Aufgabenliste. Ein "so ungefähr funktioniert das" wird zu "so soll es aussehen, bau es". Aus Modellsicht fühlt sich das nicht falsch an, es sieht aus wie Mitdenken. Wer erklärt bekommt, wie ein System mit Mandanten arbeitet, und im selben Atemzug zwei Mandanten genannt bekommt, legt die zwei eben an. Das ist die hilfsbereite Variante desselben Reflexes, der auch einen Pool in eine Immobilienbeschreibung schreibt, in deren Daten nirgends ein Pool steht. Fehlende Anweisung wird plausibel aufgefüllt. ## Warum es bei Kundendaten schlimmer ist als bei erfundenem Text Einen erfundenen Satz siehst du beim Lesen. Er ist ärgerlich, aber er bleibt im Entwurf. Kundendaten sind aus drei Gründen anders. Erstens verlassen sie den Entwurf sofort. Ein angelegter Datensatz ist angelegt. Er steht in einer Tabelle, taucht in Listen auf, wird von anderen Prozessen gelesen. Löschen hinterher ist Schadensbegrenzung, kein Ersatz. Zweitens ist es rechtlich nicht egal. Die DSGVO kennt den Grundsatz der Zweckbindung, personenbezogene Daten dürfen nur für den Zweck verarbeitet werden, für den sie erhoben wurden. Das steht in [Artikel 5 der Verordnung](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32016R0679). Eine Mailadresse, die eine Kundin für die Kommunikation mit dir hinterlassen hat, gehört nicht in ein Testsystem, nur weil sie gerade greifbar war. Drittens das Token. Ein produktiver Zugangsschlüssel in einem halbfertigen System liegt an einer Stelle, an der ihn niemand vermutet und niemand überwacht. Das ist die Sorte Fehler, die erst Monate später auffällt. Der unangenehmste Teil daran: Punkt eins bis drei waren mir alle klar. Sie waren nur nicht im richtigen Moment präsent, weil im richtigen Moment gar keine Entscheidung stattfand. Es wurde einfach gemacht. ## Was ich geändert habe Zwei Dinge, und das kleinere wirkt mehr. Das kleinere: Platzhalter sind jetzt der Standard. Wenn gebaut wird, heißt der Testmandant `Testkunde A`, die Adresse ist `kundin@example.com`, das Zielsystem `https://intake.example`. Rollen statt Namen, also "die Testerin" und "der erste Kunde". Kostet nichts und ist der Unterschied zwischen einem Testdatensatz und einem Vorfall. Das größere: die Regel steht nicht mehr in meinem Kopf, sondern in einer Datei, die bei jedem Session-Start automatisch mitgelesen wird. Claude Code lädt neben der CLAUDE.md auch die Dateien unter `.claude/rules/` in den Kontext, ohne dass jemand danach suchen muss. Es gibt sogar ein eigenes Hook-Event dafür, `InstructionsLoaded`, das genau in diesem Moment feuert. Der Inhalt der Regel ist ein Satz plus eine Liste. Der Satz lautet: Kundendaten fasse ich nur an, wenn ich für genau diesen Kunden und genau diese Aktion beauftragt bin. Kein Ableiten, kein Vorbereiten, kein "brauchen wir ohnehin gleich". Die Liste sagt, was gemeint ist, nämlich alles, was auf eine reale Person oder Firma zeigt: Namen, Mailadressen, Telefonnummern, Adressen, Domains, Objektdaten und die Zugangstoken ihrer Systeme. Und wenn echte Daten wirklich gebraucht werden, wird gefragt. Ein Satz reicht. "Für X bräuchte ich die echte Adresse von Y, soll ich?" Bis zur Antwort läuft der Bau mit Platzhaltern weiter, es wartet niemand. ## Was das für dich heißt Du brauchst kein Agenten-Setup, damit dich das trifft. Derselbe Fehler passiert in jedem Chatfenster, in das du eine echte Kundenmail kopierst, damit die KI "den Kontext versteht". Was du zur Erklärung reingibst, wird zum Material, mit dem gearbeitet wird. Und du entscheidest das im Moment des Einfügens, nicht danach. Drei Sachen, die sofort helfen. Erzähl mit Rollen, nicht mit Namen. "Eine Kundin aus dem Immobilienbereich" erklärt das Prinzip genauso gut wie der echte Firmenname und hinterlässt nichts. Sag dazu, dass es ein Beispiel ist. "Nur zur Illustration, nichts anlegen" ist ein Halbsatz und schließt genau die Lücke, in die ich gelaufen bin. Und wenn echte Daten rein müssen, mach das zu einem bewussten Schritt mit Ansage, nicht zum Nebenprodukt einer Erklärung. Wenn du das systematisch angehen willst: die Lesson [Datenschutz, was darf ich eingeben](/levels/1/12-datenschutz-was-darf-ich-eingeben) geht durch, welche Daten in welchem Tool nichts verloren haben, und das Playbook [Datenschutz mit KI-Tools](/playbooks/datenschutz-mit-ki-tools) macht daraus eine Checkliste für den Alltag. Wie Regel-Dateien automatisch in den Kontext kommen, steht in der [Claude Code Doku zu Memory](https://code.claude.com/docs/en/memory).