Thema: Teil 20. Russischer Bankenkontext
Schwierigkeitsgrad: Mittel
Geschätzte Lernzeit: 2–3 Stunden aktive Arbeit, einschließlich praktischer Übungen
Voraussetzungen: Grundlegendes Verständnis der Data-Warehouse-Architektur (Staging, Marts, Vitrinen)
Vertrautheit mit den Prinzipien von SDD (Specification-Driven Development)
Verständnis der Rolle der Datei AGENTS.md in der Arbeit des Agenten
Allgemeine Vorstellung von Bankprozessen (KYC, AML, Zahlungen, Einwilligungen)
Grundlegende Kenntnisse in SQL und dbt-ähnlichen Werkzeugen
Lernziele: Erklären, warum abstrakte Formulierungen aus dem Fachgebiet ('halten Sie 152-FZ ein', 'berücksichtigen Sie personenbezogene Daten') als SDD-Regeln für einen Agenten ungeeignet sind.
Die wichtigsten Klassen von Einschränkungen im russischen Bankenkontext aufzählen: PII, Einwilligungen, Risikoflags, Berichts-Lineage, Gates für menschliche Bestätigung.
Eine überprüfbare ingenieurmäßige Regel (mit verbotenen Feldern, Schema-Tests, Review-Checklisten) auf Basis einer vagen regulatorischen Norm formulieren.
Zonen unterscheiden, in denen Automatisierung zulässig ist, und Zonen, die zwingend eine menschliche Bestätigung erfordern (Änderung des Grain, PII-Richtlinien, Risikomethodik).
Das Prinzip der minimalen Ausgabe anwenden: jedes 'große Wort' der Domäne (personenbezogene Daten, Einwilligung, Berichtswesen) in eine konkrete technische Einschränkung übersetzen.
Übersicht: Das Kapitel 'Russischer Bankenkontext' ist kein juristisches Nachschlagewerk. Seine Aufgabe ist zu zeigen, wie öffentlich bekannte Bankbeschränkungen (152-FZ, 115-FZ, Anforderungen der Zentralbank an Berichtswesen und Risiken) in überprüfbare ingenieurmäßige Regeln umgewandelt werden, die für die SDD-Spezifikation und die Arbeit des Agenten geeignet sind. Im Buch werden nacheinander sechs Klassen von Einschränkungen eingeführt: personenbezogene Daten und PII-Minimierung, Zahlungsoperationen und das Risiko unbefugter Handlungen, Einwilligungen zum Datenzugriff über Open API, AML und Risikoflags, Berichtswesen und Reproduzierbarkeit von Berechnungen, Lineage zur Quelle und Regelversion. Für jede Klasse wird gezeigt, wie man von einer schwachen Formulierung ('personenbezogene Daten müssen berücksichtigt werden') zu einer funktionierenden Regel übergeht ('direkte PII-Felder pii_email, phone, passport_number dürfen nur im Staging vorkommen; 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'). Separat wird der Mechanismus der menschlichen Bestätigung behandelt: er hebt die Automatisierung nicht auf, sondern markiert ihre Grenze. Das Kapitel verankert die Übersetzungsgewohnheit: jedes 'große Wort' der Domäne muss in eine überprüfbare ingenieurmäßige Regel umgewandelt werden, sonst bleibt es eine offene Frage und keine ausführbare Anweisung.
Schlüsselkonzepte: Einschränkungen als Spezifikationen: In SDD ist eine Domäneneinschränkung keine Verweisung auf ein Gesetz, sondern eine technisch überprüfbare Regel. Die Regel muss eine Form haben, die es dem Agenten ermöglicht, eindeutig zu verstehen, ob sie erfüllt ist oder nicht: eine Liste verbotener Felder, ein Schema-Test, eine Review-Checkliste, ein Lineage-Fakt, ein Genehmigungs-Gate. Wenn eine Regel nicht ausgeführt und überprüft werden kann, bleibt sie eine Deklaration und keine Spezifikation.
PII und Minimierung: Personenbezogene Daten werden in direkte Identifikatoren (E-Mail, Telefon, Passnummer) und indirekte (Geschlecht, Alter, Region) unterteilt. Im russischen Bankenkontext sind direkte PII nur auf der Staging-Schicht und in geschützten PII-Sandboxes zulässig. Auf der Ebene der Marts sind sie verboten, und dies wird durch einen Schema-Test gegen die Liste der verbotenen Spalten verankert. Jede neue Spalte in einem Mart muss hinsichtlich des Auftretens direkter Identifikatoren überprüft werden.
Marts vs Staging: Staging ist eine technische Schicht mit rohen oder schwach bereinigten Daten, in der die Speicherung von PII unter Zugriffskontrolle zulässig ist. Marts sind eine Schicht, aus der Produktteams, Analysten, ML-Modelle und externe Partner lesen. Die Grenze 'Marts enthalten keine direkten PII-Felder' ist eine zentrale ingenieurmäßige Regel, die das Prinzip der Datenminimierung (Art. 5 152-FZ) formalisiert.
Einwilligungen (consents): Die Einwilligung des Kunden zur Datenverarbeitung ist keine boolesche Variable, sondern ein Zustand mit Historie. Eine Einwilligung kann aktiv, widerrufen, abgelaufen oder auf Bestätigung wartend sein. Ein Einwilligungs-Mart muss aktive und widerrufene Einwilligungen trennen und Ausstellungsdatum, Widerrufsdatum und Rechtsgrundlage speichern. Jede Vitrine, die Kundendaten verwendet, muss auf eine aktive Einwilligung des erforderlichen Typs verweisen.
Open API und Zugriffseinwilligungen: Offene APIs der Bank von Russland und kommerzieller Banken dürfen nur die Daten übertragen, für die der Kunde eine Einwilligung erteilt hat. In SDD drückt sich dies in folgender Regel aus: 'Die Open-API-Vitrine liefert nur Kunden mit aktiver Einwilligung des entsprechenden Typs am Anfragedatum'. Ohne eine solche Regel kann der Agent einen Filter nicht sicher generieren.
AML und Risikoflags: Anti-Geldwäsche-Regeln (115-FZ, Anforderungen der Zentralbank) und interne Risikomodelle erzeugen Flags für verdächtige Operationen. Diese Flags dürfen ohne Verlust der Reproduzierbarkeit nicht über die Operationsebene hinaus aggregiert werden. Regel: 'Risiko-Operationen werden nicht ohne Mart auf Operationsebene aggregiert; der Mart für Risikosignale löscht keine Operationen ohne Reviewer-Notiz.'
Berichtswesen und Reproduzierbarkeit: Regulatorische Berichte müssen reproduzierbar sein: dieselbe Metrik zum selben Datum muss bei einer Neuberechnung denselben Wert ergeben. Dies erfordert Versionierung der Modelle, Fixierung von Snapshots und Prüffakten (test expectations) für jeden Berichtsindikator.
Lineage zur Quelle: Jede Berichtsmetrik muss eine Lineage bis zum Quellmodell haben: welche Quellen, welche Transformationen, welche Codeversion. Ohne Lineage sind weder eine Vorfallsuntersuchung noch eine Bestätigung der Korrektheit gegenüber dem Regulator möglich. In SDD drückt sich dies durch ein obligatorisches lineage_id-Attribut oder einen ähnlichen dbt-Graph-Mechanismus aus.
Grain (Körnigkeit) der Daten: Grain ist die Detailebene, auf der eine Tabelle oder Vitrine definiert ist (zum Beispiel 'eine Zeile = ein Kunde', 'eine Zeile = eine Operation'). Eine Änderung des Grain bricht alle Konsumenten der Vitrine, daher kann eine solche Änderung nicht im Rahmen einer gewöhnlichen Aufgabe vorgenommen werden – nur über das Gate der menschlichen Bestätigung.
SDD-Regel: Eine gute SDD-Regel: 1) wird vom Agenten eindeutig verstanden; 2) ist überprüfbar (es gibt einen Test, eine Checkliste oder einen Review-Schritt); 3) bezieht sich auf eine konkrete Schicht/Tabelle/Feld; 4) hat einen Eigentümer (wer bestätigt die Änderung). Die Formulierung 'halten Sie das Gesetz ein' erfüllt keinen einzigen Punkt.
Menschliche Bestätigung (Human-in-the-Loop): Liste von Ereignissen, die der Agent nicht autonom ausführen darf: Änderung der PII-Richtlinie, Änderung des Grain, Breaking Change des Vertrags, neue Risikomethodik, neue Interpretation von Einwilligungen, Änderung von Freshness/SLA. Dies ist die Verantwortungsgrenze, keine Ablehnung der Automatisierung. Der Agent kann ein Problem finden, eine Änderung vorschlagen, die Folgen aufzählen – aber die Entscheidung trifft ein Mensch.
Schematest (schema test): Ein automatischer Test, der prüft, dass eine Tabelle keine Spalten aus der verbotenen Liste enthält (zum Beispiel direkte PII). In dbt wird dies über custom tests oder dbt-utils realisiert, in anderen Frameworks über Makros. Der Schematest verwandelt eine vage Regel in eine ausführbare Einschränkung im CI.
Minimaler Output (minimal output): Prinzip, nach dem in AGENTS.md und in der Spezifikation nur die Regeln aufgenommen werden, die ausgeführt und überprüft werden. Lange Gesetzestexte und allgemeine Deklarationen werden nicht aufgenommen, um beim Agenten keine Illusion von Abdeckung zu erzeugen. Wenn eine Regel nicht als überprüfbare Regel bereit ist, bleibt sie eine offene Frage mit Quellenverweis.
Wichtige Termine: 2001-08-07 — 115-FZ: Bundesgesetz 'Über die Bekämpfung der Legalisierung (Geldwäsche) kriminell erlangter Einkünfte und der Finanzierung des Terrorismus'. Grundlage der AML-Anforderungen in Russland; legt die Verpflichtungen der Bank zur Überwachung von Operationen, Identifikation von Kunden und Meldungen an Rosfinmonitoring fest.
2006-07-27 — 152-FZ: Bundesgesetz 'Über personenbezogene Daten'. Legt die Grundsätze der PD-Verarbeitung fest, einschließlich Minimierung, Einwilligung und Lokalisierung. Für SDD wichtig als Quelle der Regel 'Marts enthalten keine direkten PII-Felder'.
2014-07-21 — 242-FZ: Änderungen zum 152-FZ, die die Anforderung einführen, personenbezogene Daten russischer Bürger auf Servern innerhalb Russlands zu speichern und zu verarbeiten. Beeinflusst die Architektur der Staging-Schichten und den grenzüberschreitenden Datenaustausch.
2018-05-25 — DSGVO (EU): EU-Datenschutzverordnung. Relevant für russische Banken, die mit Daten von EU-Einwohnern arbeiten, sowie als Vorbild für die Struktur 'Rechtsgrundlage → ingenieurmäßige Regel'.
2019-2024 — Standards der offenen APIs der Bank von Russland: Reihe von Zentralbank-Standards zu Open API, die den Umfang der übertragenen Daten und die Verpflichtungen zu Einwilligungen definieren. Für SDD eine direkte Quelle für Filterregeln auf der Ebene der Open-API-Vitrinen.
Regelmäßig — Anweisungen und Verordnungen der Zentralbank (zum Beispiel 590-P, 611-P): Normative Dokumente, die Anforderungen an das Risikomanagement, die Eigenkapitalausstattung und das Berichtswesen festlegen. Werden als Quellen verwendet, auf die SDD-Regeln verweisen, aber nicht vollständig in den Spezifikationen zitiert.
Übungsaufgaben: Name: Übersetzung einer vagen Formulierung in eine überprüfbare Regel
Problem: Ihnen liegt eine Spezifikation einer Kunden-Vitrine vor, in der steht: 'Es ist notwendig, den Schutz personenbezogener Daten der Kunden gemäß 152-FZ zu gewährleisten'. Wandeln Sie diesen Satz in eine überprüfbare SDD-Regel um, die für AGENTS.md geeignet ist. Die Regel muss enthalten: (a) eine Liste konkreter verbotener direkter PII-Felder, (b) die Schicht/Tabelle, in der die Einschränkung gilt, (c) die Überprüfungsmethode (Test, Review-Schritt).
Lösung: Schritt 1. Identifizieren Sie die 'großen Worte': 'Schutz personenbezogener Daten', '152-FZ'. Schritt 2. Übersetzen Sie sie in technische Kategorien: direkte PII-Felder (E-Mail, Telefon, Passnummer, INN, SNILS), indirekte PII (Geschlecht, Alter, Region). Schritt 3. Formulieren Sie eine überprüfbare Regel. Beispiel einer finalen Regel für AGENTS.md:
PII: Marts enthalten keine direkten PII-Felder.
Verbotene direkte PII-Felder: pii_email, phone, passport_number, inn, snils,
date_of_birth, full_name_unmasked.
Zulässige Schichten für direkte PII: nur staging.* und geschützte pii_sandbox.*.
Überprüfung: jeder Mart besteht im CI einen Schema-Test gegen die Liste
der verbotenen Spalten. Neue Spalten in einem Mart erfordern ein Review
durch den Domäneneigentümer.Schritt 4. Stellen Sie sicher, dass die Regel ausführbar ist (keine direkten PII zum Mart hinzufügen) und überprüfbar (der Schema-Test schlägt bei Verletzung fehl).
Komplexität: beginner
Name: Identifizierung direkter PII in einer fiktiven Vitrine
Problem: Ihnen liegt eine Liste von Feldern der Vitrine dm.customer_360 vor: customer_id, full_name, email, phone, gender, age, region, registration_date, last_transaction_amount, device_id, ip_address, hashed_email. Bestimmen Sie, welche Felder direkte PII sind und im Mart verboten sein müssen. Erklären Sie den Unterschied zwischen direkten und indirekten Identifikatoren. Formulieren Sie Ausnahmen (falls vorhanden).
Lösung: Direkte PII (müssen aus dem Mart entfernt/maskiert werden): full_name, email, phone, ip_address, device_id (in Kombination mit anderen Daten). Die Felder hashed_email und customer_id sind entweder Pseudonyme oder technische Schlüssel, aber ihre Zuordnung zu PII erfordert Analyse: hashed_email ist ein Pseudonym, wird aber bei Kompromittierung des Hashes zu einem indirekten Identifikator. Indirekte PII (bei Aggregation zulässig): gender, age, region. Technische Felder: customer_id, registration_date, last_transaction_amount. Finale Regel für diese Vitrine: 'aus dm.customer_360 full_name, email, phone, ip_address, device_id entfernen; hashed_email als Join-Schlüssel behalten; gender, age, region als indirekte Identifikatoren behalten'. Überprüfung: Schema-Test gegen die Liste der verbotenen Spalten.
Komplexität: beginner
Name: Entwurf eines Einwilligungs-Marts
Problem: Entwerfen Sie einen Einwilligungs-Mart für eine Bank. Die Vitrine muss folgende Fragen beantworten: (1) Welche Einwilligungen hat der Kunde am Datum X aktiv? (2) Welche Einwilligungen wurden widerrufen und wann? (3) Welche Einwilligungstypen gibt es (zur PD-Verarbeitung, zur Übertragung über Open API, für Marketing, für Scoring)? Beschreiben Sie: Grain, Schlüsselfelder, Trennung aktiver und widerrufener Einwilligungen, was in separate Spalten ausgelagert wird. Formulieren Sie eine SDD-Regel.
Lösung: Grain: eine Zeile = ein Einwilligungsfakt (Ausstellung, Widerruf, Änderung). Empfohlene Struktur:
dm.consent_event
- client_id
- consent_type -- 'pd_processing', 'open_api_share', 'marketing', 'scoring'
- consent_state -- 'active', 'revoked', 'expired', 'pending'
- valid_from
- valid_to
- issued_at
- revoked_at
- source_system
- evidence_id -- Verweis auf das EinwilligungsdokumentParallel dazu eine Vitrine für den Produktiveinsatz:
dm.consent_current
- client_id
- consent_type
- is_active -- true, wenn am Anfragedatum ein aktiver Eintrag existiert
- last_updatedSDD-Regel: 'Einwilligungen: dm.consent_event und dm.consent_current trennen aktive und widerrufene Einwilligungen. Jede Vitrine, die Kundendaten verwendet, muss sich mit dm.consent_current verbinden und nach is_active=true filtern. Eine Änderung der Logik zur Bestimmung der aktiven Einwilligung erfolgt über das Gate der menschlichen Bestätigung.'
Komplexität: intermediate
Name: Lineage für eine Berichtsmetrik
Problem: Sie müssen die Lineage für die Berichtsmetrik 'Anteil überfälliger Kredite am 1. des Monats' (NPL Ratio) beschreiben. Beschreiben Sie: welche Quellen beteiligt sind, welche Transformationen, welche Modellversionen fixiert werden, welches lineage_id-Attribut Sie hinzufügen, wie Sie die Reproduzierbarkeit sicherstellen. Formulieren Sie eine SDD-Regel.
Lösung: Quellen: core.loan_agreement (Verträge), core.payment_schedule (Zahlungsplan), core.loan_status_history (Status). Transformationen: stg.loan_agreement → int.loan_with_status → dm.loan_snapshot (Snapshot am 1. jedes Monats) → rep.npl_ratio. Versionsfixierung: dbt-Snapshot-Modell wird mit dbt_snapshot_id markiert; Code-Version – git_sha; Methodikversion – methodology_version (zum Beispiel 'v2.1-2024-CB'). Das Attribut lineage_id wird als hash(source_system + source_table + load_date + methodology_version) gebildet. Überprüfung: jede Berichtszeile hat eine nicht-leere lineage_id; im CI ein Test, dass der Anteil der Zeilen ohne lineage_id < 100% ist. SDD-Regel: 'Berichtswesen: jede Berichtsmetrik hat eine lineage_id bis zum Quellmodell; die Methodikversion wird in der Spalte methodology_version fixiert; die Reproduzierbarkeit wird durch den Snapshot zum Berechnungsdatum gewährleistet. Eine Änderung der Methodik erfolgt über das Gate der menschlichen Bestätigung.'
Komplexität: intermediate
Name: Bestimmung der Grenzen von Automatisierung und menschlicher Bestätigung
Problem: Der Agent schlägt folgende Änderungen an der Spezifikation vor: (1) Hinzufügen der Spalte email_md5 zum Mart dm.customer_360 zur Vereinfachung von Joins; (2) Neudefinition des Grain von dm.transactions von Operationsebene auf Tagesebene; (3) Hinzufügen eines Filters nach is_active=true aus dm.consent_current in dm.marketing_audience; (4) Aktualisierung der Methodik zur NPL-Berechnung von v2.1 auf v2.2; (5) Änderung des SLA der Vitrine von 24 auf 12 Stunden; (6) Korrektur eines Tippfehlers im Spaltennamen dt statt date. Welche dieser Änderungen erfordern eine menschliche Bestätigung, welche können autonom ausgeführt werden?
Lösung: Erfordern menschliche Bestätigung (gemäß der Liste im Kapitel): (2) Änderung des Grain von dm.transactions – Breaking Change des Vertrags; (4) Aktualisierung der NPL-Berechnungsmethodik – neue Risikomethodik; (5) Änderung des SLA von 24 auf 12 Stunden – Änderung von Freshness/SLA. Bedingt bestätigungspflichtig: (1) Hinzufügen von email_md5 – neue Spalte in einem Mart, verstößt nicht gegen die Liste der verbotenen PII, erfordert aber ein Review des Domäneneigentümers hinsichtlich des Auftretens von Identifikatoren (zumindest als indirekte). Autonom ausführbar: (3) Hinzufügen des Filters nach dm.consent_current.is_active=true – dies ist die Anwendung der bereits bestehenden Regel 'Vitrine muss nach aktiven Einwilligungen filtern'; (6) Korrektur eines Tippfehlers – kosmetische Änderung ohne semantische Auswirkung. Ergebnis: 3 Änderungen gehen durch das Gate, 1 durch ein Review, 2 autonom. Ziel der Übung ist zu verankern, dass eine 'kleine' Änderung (zum Beispiel eine neue Spalte) gefährlich sein kann, während eine 'große' SQL-Änderung (Filter nach Einwilligungen) sicher ist, sofern sie einer bereits akzeptierten Regel folgt.
Komplexität: advanced
Name: Übersetzung einer realen regulatorischen Anforderung in eine SDD-Regel
Problem: Nehmen Sie eine reale Anforderung aus Ihrem Bankenkontext (zum Beispiel Artikel 9 152-FZ zur Einwilligung des Betroffenen, oder die Anforderung 115-FZ zur Kundenidentifikation, oder die Anforderung eines Standards zu offenen APIs). Wandeln Sie diese nach dem Schema des Kapitels in eine SDD-Regel um: (1) 'großes Wort' der Domäne, (2) technische Kategorie, (3) überprüfbare Regel, (4) Überprüfungsmethode, (5) was menschliche Bestätigung erfordert. Gestalten Sie das Ergebnis als Block für AGENTS.md.
Lösung: Beispiel für Art. 9 152-FZ (Einwilligung des Betroffenen). (1) Großes Wort: 'Einwilligung des Betroffenen in die PD-Verarbeitung'. (2) Technische Kategorie: Einwilligungsfakt mit Historie (Ausstellung, Widerruf, Frist). (3) Überprüfbare Regel: 'Jede Vitrine, die PD des Kunden verwendet, verbindet sich mit dm.consent_current und filtert nach is_active=true und consent_type in (erforderliche Typen). Eine Einwilligung gilt nur dann als aktiv, wenn ein Eintrag in dm.consent_event mit dem Status active vorhanden ist, dessen valid_from <= now() < valid_to ist.' (4) Überprüfungsmethode: dbt-Test, dass der Anteil der Kunden ohne verknüpften Eintrag in dm.consent_current in der Zielvitrine gleich 0 ist; Review neuer Vitrinen auf Vorhandensein des Filters. (5) Menschliche Bestätigung ist erforderlich bei: Änderung der Typen consent_type, Änderung der Logik zur Bestimmung der aktiven Einwilligung, Hinzufügung neuer Kanäle zur Einwilligungserhebung. Fertiger Block für AGENTS.md:
Einwilligungen: dm.consent_event speichert alle Einwilligungsfakten
(Ausstellung, Widerruf, Ablauf). dm.consent_current ist ein Snapshot der
aktiven Einwilligungen zum aktuellen Datum. Jede Vitrine, die PD des
Kunden verwendet, muss sich mit dm.consent_current verbinden und nach
is_active=true filtern. Änderungen der Einwilligungstypen, der
Aktivitätslogik und der Einwilligungsquellen erfolgen über das Gate der
menschlichen Bestätigung.Komplexität: advanced
Fallstudien: Name: Kunden-360-Vitrine: Übergang von Deklaration zum Schema-Test
Szenario: Das Analystenteam einer großen Retailbank baute die Vitrine dm.customer_360, in die die Felder email, phone und Geburtsdatum des Kunden gelangten. In der Spezifikation der Vitrine stand: 'Die Vitrine gewährleistet den Schutz personenbezogener Daten gemäß den Anforderungen des 152-FZ'. Die Spezifikation passierte das Review des Architekten, aber direkte PII tauchten weiterhin im Mart auf. Eine Anfrage des Produktteams zur Nutzung der Vitrine zur Anreicherung von Marketingkampagnen warf die Frage auf: Können diese Daten an einen Partner übertragen werden?
Aufgabe: Das Hauptproblem war, dass sich die Formulierung zum 'Schutz gemäß 152-FZ' als nicht überprüfbar erwies. Der Architekt hatte kein objektives Kriterium, nach dem er die Merge-Anfrage hätte ablehnen können. Es gab keinen Schema-Test auf verbotene Spalten. Die Einwilligung des Kunden zur Übertragung an den Partner wurde nicht überprüft. Risiko – Verlust direkter Identifikatoren und Verstoß gegen die Datenminimierung (Art. 5 152-FZ) sowie potenzielle Bußgelder und Reputationsschäden.
Lösung: Das Team übersetzte die abstrakte Anforderung in drei überprüfbare Regeln. Erstens: die Liste der verbotenen direkten PII (email, phone, passport_number, date_of_birth, full_name_unmasked) wurde explizit fixiert und ein Schema-Test eingeführt, der im CI fehlschlägt, wenn diese Spalten in einem beliebigen Mart auftauchen. Zweitens: die Vitrine dm.consent_current wurde eingeführt und jeder Mart, der Kundendaten verwendet, muss sich mit ihr verbinden und nach is_active=true filtern; ein Test wurde eingeführt, der prüft, dass der Anteil der Kunden ohne aktive Einwilligung im Mart gleich null ist. Drittens: für die Übertragung an Partner wurde eine separate Schicht pii_partner_safe mit Aggregaten (nur Geschlecht, Altersgruppe, Region) und einem Vertrag hinzugefügt, der das Fehlen direkter Identifikatoren festschreibt. Die Spezifikation in AGENTS.md enthielt nun konkrete Regeln statt allgemeiner Deklarationen. Die Änderung der Liste verbotener Spalten oder der Einwilligungslogik wurde in das Bestätigungs-Gate durch den Domäneneigentümer und den DPO ausgelagert.
Ergebnis: Einen Monat nach Einführung des Schema-Tests wurden drei Versuche, 'praktische' Felder zum Mart hinzuzufügen (Kartennummer für Joins, E-Mail für Kommunikation), automatisch im CI abgelehnt. Das Review wurde objektiv: Der Reviewer gleicht mit der Liste der verbotenen Spalten und dem Testergebnis ab, anstatt die 'Gesetzmäßigkeit' zu interpretieren. Das Produktteam erhielt ein sicheres Aggregat für Partnerkampagnen. Das regulatorische Audit verlief ohne Beanstandungen im Abschnitt zur Datenminimierung. Das Team verankerte die Gewohnheit: Jedes 'große Wort' aus 152-FZ (Einwilligung, Minimierung, Lokalisierung) wird in eine überprüfbare Regel mit Eigentümer und Test übersetzt.
Gewonnene Erkenntnisse: Die Formulierung 'entspricht 152-FZ' hat ohne Liste der verbotenen Felder und automatische Überprüfung keine operative Bedeutung.
Der Schema-Test verwandelt eine architektonische Regel in ein objektives Abnahmekriterium – dies entlastet den Reviewer und beschleunigt das CI.
Eine Einwilligung ist keine boolesche Variable, sondern ein Zustand mit Historie; die Einwilligungs-Vitrine muss aktive und widerrufene Einwilligungen trennen.
Selbst das 'kleine' Hinzufügen einer Spalte in einem Mart kann die PII-Richtlinie verletzen und muss ein Review durchlaufen.
Verwandte Konzepte: PII und Minimierung
Marts vs Staging
Einwilligungen (consents)
Schematest (schema test)
SDD-Regel
Name: Open API und Einwilligungen: Wie man Datenlecks in den Partnerkanal vermeidet
Szenario: Eine Bank bringt eine Open API für Partner – Versicherungsgesellschaften und Marktplätze – auf den Markt. Partner fordern das Kundenprofil (Name, Kontakte, Operationshistorie) zur Berechnung personalisierter Angebote an. Das interne Entwicklungsteam bereitete eine Vitrine vor, die 'alles, was über den Kunden vorhanden ist, mit Filter auf Vorhandensein eines Eintrags in der Datenbank' liefert. Das Sicherheitsteam schlug Alarm: Anfragen von Partnern berücksichtigen weder den Einwilligungstyp noch den Widerrufsfakt.
Aufgabe: Ohne Formalisierung der Filterregeln konnte der Agent (oder ein Junior-Entwickler) bei der Generierung des Open-API-Endpoints leicht Daten eines Kunden weitergeben, der seine Einwilligung zur Übertragung an Partner widerrufen hatte. Außerdem benötigen verschiedene Partner unterschiedliche Datensätze: der Versicherer – die Operationshistorie, dem Marktplatz genügen Aggregate. Die allgemeine Regel 'nur das weitergeben, wofür eine Einwilligung vorliegt' ist zu vage: welcher Einwilligungstyp, welches Aktualitätsdatum, was tun mit indirekten Identifikatoren?
Lösung: Das Team führte eine Hierarchie von Vitrinen ein. Auf der unteren Ebene – dm.consent_event (alle Einwilligungsfakten) und dm.consent_current (aktive Einwilligungen). Darüber – dm.open_api_profile, die nur die Kunden sammelt, für die consent_type='open_api_share' und is_active=true zum Zeitpunkt der Anfrage gilt, und nur die Felder, die für den jeweiligen partner_scope (insurance, marketplace, scoring) zulässig sind. Für jeden partner_scope ist die Liste der zulässigen Felder als separate Konfigurationstabelle fixiert. In AGENTS.md wurde folgende Regel festgehalten: 'Open API: dm.open_api_profile liefert nur Kunden mit aktiver consent_type=open_api_share. Die Feldliste wird durch die Tabelle config.partner_scope_allowlist bestimmt. Änderungen der Feldlisten und Einwilligungstypen erfolgen über das Gate der menschlichen Bestätigung (Produkteigentümer + DPO).' In dbt wurde ein Test hinzugefügt: Der Anteil der Zeilen in dm.open_api_profile ohne aktive consent_type=open_api_share muss gleich null sein. Zusätzlich wurde ein Test zur Übereinstimmung der zulässigen Felder mit partner_scope_allowlist eingeführt.
Ergebnis: Der Start der Open API verlief ohne Vorfälle. Der Versuch eines Partners, den Scope zu erweitern (Name und E-Mail zu erhalten), wurde automatisch auf Endpoint-Ebene abgelehnt. Als ein Kunde seine Einwilligung über die Mobile-App widerrief, verschwand er innerhalb einer Stunde aus dm.open_api_profile, und der Partnerkanal erhielt seine Daten nicht mehr – ohne manuelles Eingreifen. Der Zentralbank-Auditor stellte das Vorhandensein einer formalisierten Lineage von der Partneranfrage bis zum Einwilligungsfakt fest.
Gewonnene Erkenntnisse: Eine Einwilligung muss Typen und zeitliche Aktualität haben; eine einzelne Markierung 'einverstanden' reicht nicht aus.
Eine Vitrine für externe Konsumenten ist nicht 'alles, was vorhanden ist', sondern eine Projektion mit Filter nach Einwilligungstyp und Scope.
Die Konfiguration der zulässigen Felder nach partner_scope muss eine separate Tabelle mit Eigentümer sein, kein Hardcode im Code.
Eine Lineage von der API-Anfrage bis zum Einwilligungsfakt ist eine obligatorische Bedingung für das regulatorische Audit.
Verwandte Konzepte: Einwilligungen (consents)
Open API und Zugriffseinwilligungen
Lineage zur Quelle
Menschliche Bestätigung (Human-in-the-Loop)
Name: Anti-Pattern: Gesetzestexte statt Regeln
Szenario: Ein Team führte SDD in der Risikomanagement-Abteilung ein. Ein Analyst-Experte, der für die Spezifikationen verantwortlich war, fügte vollständige Texte der Artikel 6, 9 und 11 des 152-FZ sowie Auszüge aus der Verordnung 590-P in AGENTS.md ein. Sein Argument: 'Der Agent muss das Gesetz kennen, um korrekte Entscheidungen zu treffen'. Infolgedessen wuchs AGENTS.md auf 40 Seiten an, und bei Anfragen zur SQL-Generierung begann der Agent, Formulierungen zurückzugeben, die das Gesetz zitieren, aber die Aufgabe nicht beantworten.
Aufgabe: Das Hauptproblem – langer juristischer Text ist keine ausführbare Anweisung. Der Agent kann einen Gesetzesartikel nicht 'anwenden'; er kann eine konkrete Regel ausführen oder nicht. Die Spezifikation wurde zu Rauschen: Der Reviewer konnte keine überprüfbaren Einschränkungen finden, der Entwickler verstand nicht, welche Felder verboten sind, der Analyst konnte nicht formulieren, welche Marts eine Bestätigung erfordern.
Lösung: Das Team führte ein Refactoring der Spezifikation durch. Aus AGENTS.md wurden alle langen Zitate entfernt. Stattdessen kurze Quellenverweise ('siehe Art. 9 152-FZ') und daneben die überprüfbare Regel. Beispielsweise erschien anstelle des vollständigen Textes von Art. 9: 'Einwilligung: dm.consent_event speichert Einwilligungsfakten; Vitrinen, die PD verwenden, filtern nach is_active=true in dm.consent_current. Quellregel: Art. 9 152-FZ. Änderung der Einwilligungstypen erfolgt über das Gate der menschlichen Bestätigung.' Statt Auszügen aus 590-P – konkrete Regeln für Marts von Risikometriken: Methodikversion, lineage_id, Verbot der Aggregation von Risiko-Operationen oberhalb der Operationsebene. Die Quellen (Verweise auf normative Dokumente) wurden in eine separate Datei references.md ausgelagert, die beim Generieren von SQL nicht in den Kontext des Agenten geladen wird.
Ergebnis: Der Umfang von AGENTS.md reduzierte sich von 40 auf 8 Seiten. Die Review-Zeit für Spezifikationen halbierte sich ungefähr. Der Agent begann konkrete, ausführbare Vorschläge zu liefern statt juristischer Formulierungen. Der Reviewer erhielt objektive Kriterien (Schema-Test, Test auf den Anteil der Kunden mit aktiver Einwilligung, Test auf lineage_id), anstatt das Gesetz zu interpretieren. Beim Audit zeigte das Team sowohl AGENTS.md (ausführbare Regeln) als auch references.md (Quellen), was sowohl den Regulator als auch die Entwickler zufriedenstellte.
Gewonnene Erkenntnisse: Ein langes Gesetzestext-Zitat in einer Spezifikation ist Dekoration, keine ingenieurmäßige Einschränkung; dem Agenten hilft es nicht.
Quellenverweise neben der überprüfbaren Regel sind die optimale Struktur: sowohl juristische Rückverfolgbarkeit als auch Ausführbarkeit.
AGENTS.md muss in den Kontext des Agenten beim Lösen von Aufgaben geladen werden; folglich muss es kompakt und überprüfbar sein.
Die Rechtsabteilung ist Eigentümer von references.md, das Engineering-Team ist Eigentümer von AGENTS.md; dies sind verschiedene Artefakte mit unterschiedlicher Verantwortung.
Verwandte Konzepte: Minimaler Output (minimal output)
SDD-Regel
Menschliche Bestätigung (Human-in-the-Loop)
Lineage zur Quelle
Name: Änderung des Grain als Punkt ohne Wiederkehr: Lehre aus einem Vorfall
Szenario: Das Team der Transaktionsvitrine beschloss, die Leistung zu optimieren, und schlug vor, vom Grain 'eine Zeile = eine Operation' auf 'eine Zeile = ein Tag pro Konto' zu wechseln. Die Änderung wurde als gewöhnliche Merge-Anfrage mit der Notiz 'Leistungsoptimierung' formalisiert. Nach dem Release stellten vier Produktteams fest, dass ihre Joins und ML-Modelle kaputt waren: Details zu Operationen verschwanden, Summen änderten sich, Duplikate traten auf. Die Rückabwicklung dauerte eine Woche.
Aufgabe: Die Änderung des Grain ist eines der Ereignisse, die das Kapitel dem Gate der menschlichen Bestätigung zuordnet. In diesem Fall wurde sie als 'gewöhnliches SQL-Refactoring' durchgeführt, und niemand sah, dass sie den Vertrag bricht. Die Spezifikation enthielt keine explizite Regel darüber, dass eine Änderung des Grain ohne Bestätigung des Produkteigentümers und der Konsumententeams verboten ist.
Lösung: Nach dem Vorfall nahm das Team in AGENTS.md und in die Review-Checkliste eine explizite Regel auf: 'Grain: dm.transactions hat das Grain = eine Zeile = eine Operation. Eine Änderung des Grain (in jede Richtung) erfolgt über das Gate der menschlichen Bestätigung mit Benachrichtigung aller Konsumenten 5 Werktage im Voraus. Ein PR mit Änderung des Grain muss einen Abschnitt Affected downstream mit Auflistung aller betroffenen Vitrinen und ML-Modelle enthalten.' Zusätzlich wurde im dbt-Test eine Erwartung fixiert: count(distinct operation_id) = count(*) in dm.transactions (Test auf Eindeutigkeit des Grain). Bei dem Versuch, die Vitrine oberhalb der Operationsebene zu aggregieren (zum Beispiel in der int-Schicht zu summieren), erinnert der Test auf Lineage und Grain den Agenten an die Grenze.
Ergebnis: Der nächste Optimierungsversuch (durch Indizierung, Partitionierung und materialisierte Sichten) verlief ohne Änderung des Grain. Die Leistung stieg um 40%, ohne den Vertrag zu brechen. Das Konsumententeam bestätigte, dass die Daten kompatibel blieben. Das Lineage-Audit zeigte, dass alle Downstream-Vitrinen weiterhin auf das korrekte Grain verweisen. Die Lehre wurde im Onboarding für neue Ingenieure fixiert.
Gewonnene Erkenntnisse: Eine Änderung des Grain ist ein Breaking Change des Vertrags, auch wenn sie als 'Optimierung' formalisiert wird.
Ein Test auf Eindeutigkeit des Grain ist eine einfache und zuverlässige Methode, um eine Verletzung automatisch zu erkennen.
Ein PR mit Änderung des Grain muss einen Abschnitt Affected downstream enthalten; ohne ihn sollte die Änderung das Review nicht bestehen.
Das Bestätigungs-Gate ist keine Bürokratie, sondern ein Schutz vor kostspieligen Rückabwicklungen.
Verwandte Konzepte: Grain (Körnigkeit) der Daten
Menschliche Bestätigung (Human-in-the-Loop)
Lineage zur Quelle
SDD-Regel
Lerntipps: Fragen Sie sich immer: 'Kann ich einen Test schreiben, der diese Regel überprüft?' Wenn die Antwort 'nein' ist – die Regel ist noch nicht bereit, lassen Sie sie als offene Frage stehen.
Halten Sie in AGENTS.md nur das, was ausgeführt und überprüft wird. Lange Gesetzestexte lagern Sie in eine separate references.md aus, auf die die Regel verweist.
Übersetzen Sie jedes 'große Wort' der Domäne (personenbezogene Daten, Einwilligung, Risiko, Berichtswesen, Audit) in eine konkrete technische Kategorie: verbotenes Feld, Test, Review-Schritt, Gate.
Die Liste der Bestätigungs-Gates (PII-Richtlinie, Grain, Vertrag, Risikomethodik, Einwilligungen, SLA) halten Sie an einer Stelle – zum Beispiel in der Review-Checkliste und am Anfang von AGENTS.md. Dies reduziert die Zahl zufälliger Verstöße.
Für jede Berichtsmetrik fordern Sie lineage_id und methodology_version. Ohne sie ist die Reproduzierbarkeit nicht gewährleistet und das regulatorische Audit wird unmöglich.
Der Schema-Test gegen die Liste der verbotenen Spalten ist das minimale und obligatorische Werkzeug. Führen Sie ihn zuerst ein, bevor Sie komplexe Richtlinien aufbauen.
Modellieren Sie Einwilligung als Zustand mit Historie, nicht als boolesche Variable. Dies deckt sofort die Anforderungen an die Einwilligungs-Vitrine und an die Filterung der Konsumenten auf.
Üben Sie das Übersetzen: Nehmen Sie eine reale Anforderung aus Ihrer Bank und gestalten Sie sie als AGENTS.md-Block. Dies geht schneller als das Lesen des Kapitels und deckt sofort Verständnislücken auf.
Verwechseln Sie eine 'kleine' Änderung nicht mit einer 'sicheren'. Das Hinzufügen einer einzelnen Spalte in einem Mart kann die PII-Richtlinie verletzen, während ein Filter nach einer bestehenden Regel sicher ist.
Denken Sie daran: Menschliche Bestätigung ist die Verantwortungsgrenze, keine Ablehnung der Automatisierung. Der Agent kann ein Problem finden und eine Lösung vorschlagen, aber die Entscheidung trifft ein Mensch.
Zusätzliche Ressourcen: Bundesgesetz 152-FZ 'Über personenbezogene Daten': Hauptrussisches PD-Gesetz. Als Quelle für Verweise in references.md verwenden, nicht als Text für AGENTS.md.
Bundesgesetz 115-FZ 'Über die Bekämpfung der Legalisierung von Einkünften': Grundlage der AML-Anforderungen. Nützlich bei der Formulierung von Regeln für Marts zu Risikosignalen und Operationen.
Verordnungen und Anweisungen der Bank von Russland (590-P, 611-P u.a.): Regulatorische Dokumente zu Risikomanagement und Eigenkapitalausstattung. Quelle für Regeln zu methodology_version und Lineage.
Standards der offenen APIs der Bank von Russland: Quelle für Filterregeln der Open-API-Vitrinen und den Umgang mit Einwilligungstypen.
Dbt-utils (custom schema tests): Werkzeug zur Implementierung von Schema-Tests gegen die Liste der verbotenen Spalten und andere überprüfbare Einschränkungen.
Dbt-snapshot: Mechanismus zur Fixierung von Modellversionen für die Reproduzierbarkeit von Berichtsmetriken.
Interne Richtlinien der Bank zu PII und Risiken: Jede Bank hat eigene Richtlinien zur PD-Verarbeitung, Risikomodelle und Abstimmungsregelungen. Sie sind die Hauptquelle konkreter Regeln für Ihr Projekt.
DSGVO (EU-Verordnung 2016/679): Nützlich als Vorbild für die Struktur 'Rechtsgrundlage → ingenieurmäßige Regel' und als Ideenquelle für die Datenminimierung.
Open Source: great expectations, soda core: Werkzeuge zur Beschreibung und Auto[... truncated by prompt_safety limit ...]