Redact-Bug-Snippet – der schmale Pfad zwischen PRD-Slice und Claude-Chat
Wenn die Anonymisierung den Bug maskiert hat, braucht es einen disziplinierten Workflow: PRD-Slice mit 4-Augen ziehen, durch redact-bug-snippet.js laufen lassen, in Hardened AI VDI mit Claude debuggen – alles auditiert. Der konkrete Prozess + die Skript-Struktur.
Der Fall, der den Workflow nötig macht
Tester reproduziert einen Bug auf QAS – funktioniert nicht. Die Anonymisierung hat etwas geschluckt: vielleicht hat der Date-Shift das Problem-Datum verfälscht, vielleicht hat der NER-Scrub einen kritischen Material-Code rausgenommen. Der Bug ist nur auf PRD reproduzierbar.
Jetzt steht der Tester vor einer Wahl, die nicht trivial ist:
- Option A: Bug-Schluss nach „nicht reproduzierbar“ – das wäre falsch, der Bug ist real.
- Option B: PRD-Daten in den Chat kopieren – Datenschutz-GAU.
- Option C: Disziplinierter Repro-Workflow mit redact-bug-snippet.js.
Diese Use-Case beschreibt Option C, weil A und B beide den Schaden grösser machen als der Bug.
Der vollständige Pfad
mermaid
flowchart TD
Bug[Bug auf QAS<br/>nicht reproduzierbar]
Bug --> Esc[Eskalation an<br/>AI Privacy & Ops Lead]
Esc --> Just[Begründung +<br/>4-Augen-Approval]
Just --> JIT[JIT PRD-Read<br/>4h Window]
JIT --> Slice[Sliced Query<br/>nur betroffene Records]
Slice --> Redact[redact-bug-snippet.js<br/>Tool-gestützte Anonymisierung]
Redact --> Review[Privacy-Lead reviewed<br/>Output]
Review --> Chat[Claude in Hardened AI VDI<br/>Session aufgezeichnet]
Chat --> Fix[Fix als PR]
Fix --> Audit[Audit-Trail<br/>vollständig dokumentiert]
style Bug fill:#fecaca,stroke:#b91c1c
style Audit fill:#bbf7d0,stroke:#15803d
Schritt 1 – Eskalation und Begründung
Tester eskaliert an die Rolle „AI Privacy & Operations Lead“. Die Eskalation enthält: - Bug-Ticket-ID - Was auf QAS getestet wurde - Hypothese, warum die Anonymisierung den Bug maskiert - Welche Records aus PRD nötig sind (so eng wie möglich)
Wenn der Privacy-Lead zustimmt, holt er ein 4-Augen-Approval vom DPO oder einem zweiten Senior. Beides geht im BTP Audit Log mit Begründung.
Schritt 2 – JIT-PRD-Access aktivieren
Der Privacy-Lead aktiviert für sich (nicht für den Tester) einen 4-Stunden-JIT-Access auf die PRD-HANA mit Read-Only-Scope. Das geht über XSUAA-Role-Assignment mit time-bound expiry.
Wichtig: der Tester selbst bekommt nie PRD-Access. Die Slice-Extraktion macht der Privacy-Lead.
Schritt 3 – Sliced Query
sql
-- Beispiel – eng begrenzt auf den Bug-relevanten Datensatz
SELECT *
FROM BAMVP_PRD.BillingItems
WHERE settlementRunId = 'SR-2026-Q1-457'
AND invoiceNumber = '0001234567'
LIMIT 50
Output kommt als CSV in einen temporären Container, nie in einen Shared-Folder. Der Privacy-Lead lädt das CSV in seine Hardened AI VDI.
Schritt 4 – redact-bug-snippet.js
Das ist das Kernstück. Das Skript ist ein Node-CLI-Tool, das:
- CSV liest
- Pro Spalte die Anonymisierungs-Regel aus der Field-Registry holt (dieselbe wie der Anonymizer-Service, aber ohne den deterministischen HMAC-Salt)
- Faker-replacement, Date-shift, NER-scrub anwendet
- Ein Markdown-Snippet ausgibt, das in den Claude-Chat kopiert werden kann
javascript
// scripts/redact-bug-snippet.js – vereinfacht
const csv = readCsv(args.input);
const registry = loadFieldRegistry();
const redacted = csv.map(row => {
return Object.entries(row).reduce((acc, [k, v]) => {
const rule = registry[k] || 'omit';
acc[k] = applyRule(rule, v);
return acc;
}, {});
});
const md = toMarkdownTable(redacted);
console.log(md);
Output-Eigenschaften: - Keine Original-Werte für K1/K2/K4-Felder - K3-Felder mit ±5% Jitter (summen-erhaltend) - Free-Text mit NER-scrub (Namen weg) - Aggregat-Erhaltung (so dass der Bug-Pattern sichtbar bleibt)
Schritt 5 – Privacy-Lead Reviewt Output
Der Lead schaut sich den Markdown-Output an. Wenn dort noch Reste von PRD-Daten sind (z.B. ein Material-Code, der im Klartext rausfällt) – Skript anpassen, neu laufen lassen. Disziplin: kein „passt schon“ beim Review.
Schritt 6 – Chat mit Claude in Hardened AI VDI
Der Lead kopiert das Markdown-Snippet in Claude. Claude debuggt. Session ist aufgezeichnet (Keyboard + Screen, 90-Tage-Retention).
Was Claude bekommt: die Form des Bugs ohne die Identität der Records. Genug, um einen Fix vorzuschlagen.
Schritt 7 – Fix als PR + Audit-Closure
Fix wird als PR aufgemacht. Im PR-Body wird dokumentiert: „Bug auf PRD reproduziert via Slice X, redact-snippet-hash Y, Claude-Session-ID Z.“
Der Audit-Trail hat damit: - Wer (Privacy-Lead-User-ID) - Wann (4h-Window-Start/End) - Was (welche PRD-Records, Slice-Hash) - Warum (Bug-Ticket + 4-Augen-Approval) - Wie (Skript-Version, Claude-Session-ID)
Was diesen Workflow durchhält
- Tester sind geschult, Repro-First auf QAS zu versuchen – und beim Fail nicht eigenmächtig PRD anzufragen.
- Privacy-Lead hat 100% FTE, also Zeit für solche Eskalationen ohne Überlast.
- Audit-Log ist tagesaktuell (nicht erst nach Quartal), damit Anomalien sichtbar werden.
Wer das einsetzen will
Ein Workshop (halbtägig) baut den Repro-Workflow für Ihre Domäne: Field-Registry, Skript-Konfiguration, Eskalationspfad. Output: dokumentierter Prozess + lauffähiges Skript.
Stand: 2026-06-25
