Teil 20. Russischer Bankenkontext

Dieses Kapitel gibt keine rechtlichen Anweisungen. Es zeigt, wie öffentlich bekannte Einschränkungen in SDD-Regeln umgewandelt werden. Für einen Agenten ist es nutzlos, „das Gesetz einhalten" zu schreiben. Er braucht konkrete Einschränkungen, überprüfbare Fakten und Bestätigungen durch Menschen.

Einschränkungen als Spezifikationen

Für eine Lehrbank sind folgende Klassen von Einschränkungen wichtig:

• personenbezogene Daten und PII-Minimierung;
• Zahlungsvorgänge und Risiko unbefugter Handlungen;
• Einwilligungen zum Datenzugriff über Open API;
• AML und Risiko-Flags;
• Berichtswesen und Reproduzierbarkeit von Berechnungen;
• Lineage bis zur Quelle und Regelversion.

Wie man es im Projekt dokumentiert

Schreiben Sie nicht in AGENTS.md: „das Gesetz einhalten". Das ist nicht überprüfbar. Schreiben Sie konkret:

• Marts enthalten keine direkten PII-Felder;
• Einwilligungs-Mart trennt aktive und widerrufene Einwilligungen;
• Risiko-Signale-View löscht Vorgänge nicht ohne Notiz des Reviewers;
• Berichts-View verfügt über Prüffakten und Lineage;
• Änderung des Grain oder SLA erfordert eine Bestätigung.

Beispiel für die Übersetzung einer Einschränkung

Schwache Regel:

Нужно учитывать персональные данные.

Arbeitsfähige Regel:

Direkte PII-Felder (`pii_email`, `phone`, `passport_number`) dürfen nur im Staging erscheinen. Marts müssen einen Schema-Test gegen die Liste der verbotenen direkten PII bestehen. Der Reviewer muss neue Mart-Spalten vor dem Release prüfen.

Die zweite Regel ist keine Rechtsberatung. Es ist eine ingenieurmäßige Absicherung, die ausgeführt und überprüft werden kann.

Bestätigung durch Menschen

Eine Bestätigung durch Menschen ist dort nötig, wo ein Agent keine Entscheidung treffen sollte:

• Änderung der PII-Richtlinie;
• Änderung des Grain;
• Breaking Change am Vertrag;
• neue Risikomethodik;
• neue Interpretation von Einwilligungen;
• Änderung von Freshness/SLA.

Wenn eine Änderung klein erscheint, aber in diese Liste fällt, darf sie nicht als „nur SQL" übergangen werden.

Qwen-Anfrage

Lies Specs und Marts.
Finde Stellen, an denen der Bankenkontext als überprüfbare Regel ausgedrückt werden muss: PII, Einwilligungen, Risiko, Berichts-Lineage, Freigabe-Gates.
Ändere keine Dateien.

Minimale Ausgabe

Halten Sie Einschränkungen als technische Regeln fest:

PII: Marts enthalten keine direkten PII-Felder.
Einwilligungen: aktive und widerrufene Einwilligungen werden getrennt gezählt.
Risiko: Risiko-Vorgänge werden nicht ohne Mart auf Vorgangsebene aggregiert.

Berichtswesen: jede Berichtsmetrik hat eine Lineage bis zum Quellmodell.
Bestätigung: Grain/SLA/Vertragsfelder werden nicht ohne Bestätigung durch Menschen geändert.

Diese Regeln können in AGENTS.md, eine Prüfcheckliste oder die Reviewer-Fähigkeit übertragen werden.

Aufschlüsselung für den Leser

Der russische Bankenkontext in diesem Buch ist kein juristischer Abschnitt. Seine Aufgabe ist es zu zeigen, wie externe Einschränkungen in ingenieurmäßige Regeln umgewandelt werden. Ein Agent kann „das Gesetz einhalten" nicht allgemein umsetzen. Er kann PII nicht in Marts einfügen, eine Bestätigung bei Grain-Änderungen verlangen, Lineage bewahren, die Risikomethodik nicht ohne Spezifikation neu definieren. Je konkreter die Regel, desto besser funktioniert sie im SDD.

Es ist wichtig, regulatorische Texte nicht als Dekoration in Spezifikationen zu kopieren. Ein langes Gesetz-Zitat hilft dem Agenten selten, die richtige Entscheidung zu treffen. Es ist besser, einen Quellverweis festzuhalten und daneben eine ausführbare Projektregel zu formulieren. Zum Beispiel: direkte Identifikatoren sind in Marts verboten; eine Einwilligung gilt nur nach der beschriebenen Regel als aktiv; eine Berichtsmetrik hat eine Lineage bis zur Quelle; eine SLA-Änderung erfordert eine Bestätigung durch Menschen.

Eine Bestätigung durch Menschen bedeutet keine Ablehnung von Automatisierung. Im Gegenteil, sie zeigt, wo Automatisierung anhalten soll. Ein Agent kann ein Problem finden, eine Änderung vorschlagen, die Folgen aufzählen. Aber die Entscheidung über eine neue Risikomethodik, eine Änderung der PII-Richtlinie oder einen Breaking Change am Vertrag bleibt beim Menschen. Das ist die Verantwortungsgrenze, keine technische Einschränkung.

Für den Leser soll dieses Kapitel zur Übersetzungsgewohnheit werden. Jedes große Wort aus der Domäne — personenbezogene Daten, Einwilligung, Berichtswesen, Risiko, Audit — muss in eine überprüfbare ingenieurmäßige Regel übersetzt werden. Wenn die Übersetzung nicht gelingt, ist die Regel noch nicht bereit für den Agenten. Dann muss sie als offene Frage stehen bleiben und nicht hinter einer autoritativen Formulierung versteckt werden.

Praxis

Nehmen Sie ein rechtliches oder regulatorisches Wort aus Ihrer Domäne und übersetzen Sie es in eine ingenieurmäßige Einschränkung: eine Liste verbotener Felder, ein Pflicht-Review, ein Lineage-Fakt oder ein Freigabe-Gate.

Typischer Fehler

Lange Gesetz-Zitate in Spezifikationen einzufügen. Ein Agent braucht keinen rechtlichen Traktat, sondern überprüfbare ingenieurmäßige Regeln. Verweise auf Gesetze und regulatorische Dokumente sollten besser als Quellen und Einschränkungen geführt werden, nicht als ausführbare Anweisungen.

Kontrollfragen

1. Warum ist „152-FZ einhalten" keine ausreichende SDD-Regel?
2. Welche Felder sind in Marts verboten?
3. Wie beeinflussen Einwilligungen das Datenprodukt?