Autor: admin

In meinem letzten Artikel hatte ich ja bereits das Thema Plattform und Architektur erläutert. Ausgehend von dem Gedanken bin ich nun einen Schritt weiter gegangen und mir folgende Frage gestellt:

Wie sieht die Architektur aus, die das Meldewesen der Zukunft trägt – mit der heute verfügbaren Technik, erweitert um innovative, umsetzbare Ideen?

Dieser Artikel ist ein zunächst nur ein Entwurf und kein fertiges Konzept, aber eine ernsthafte Skizze – basierend auf dem, was heute meines Erachtens technisch möglich und regulatorisch vertretbar ist.

Drei Grundprinzipien der Architektur

• Datenhoheit beim Kunden – kein Vendor erhält die Schlüssel zu den eigenen Daten.
• Transparenz statt Blackbox – jede Transformation ist dokumentiert, versioniert und testbar.
• KI als Werkzeug, nicht als Entscheider – Human-in-the-Loop ist keine Option, sondern Pflicht.

Die fünf Schichten

graph TD
    %% QUELLSYSTEME
    subgraph Q["Schicht 1 - Quellsysteme"]
        Q1[Kernbank] & Q2[Risiko] & Q3[Trading] & Q4[Rechnungswesen]
    end

    %% BIRD DWH
    subgraph D["Schicht 2 - BIRD Data Warehouse - Single Source of Truth\n"]
        D1[Input Layer\ngranular - versioniert] --> D2[Lineage + CDEs\nDatenherkunft je Attribut]
        D2 --> D3[Transformation\ndbt - Git-versioniert]
        D3 --> D4[Output Layer\nfertige Meldepositionen]
    end

    %% DQ LAYER
    subgraph DQ["Schicht 3 - DQ-Layer - keine externe KI"]
        DQ1[DQ-Service\nIsolation Forest] & DQ2[Lineage-Service\nCDE-Katalog] & DQ3[Validierungs-Service\nPlausibilität]
    end

    %% MICROSERVICES
    subgraph M["Schicht 4 - Regulatory Microservices · je Rahmenwerk eigenständig\n"]
        M1[AnaCredit\nEZB/OeNB] & M2[CoRep\nEBA/CRR] & M3[LCR/NSFR\nLiquidität] & M4[FinRep\nEBA/IFRS] & M5[IReF 2029\nEZB]
    end

    %% KI LAYER
    subgraph K["Schicht 5 - AWS Bedrock - DSGVO-konform - nur synthet. Daten\n"]
        K1[Claude Sonnet\nRegulatory Interpreter] & K2[RAG-Pipeline\nBIRD-Docs - IReF] & K3[Code-Generierung\nPython - SQL]
    end

    %% AGENTEN
    subgraph A["Schicht 6 - Agenten-Layer - Orchestrierung über alle Schichten\n"]
        A0[Orchestrierungs-Agent\nplant - delegiert - überwacht]
        A0 --> A1[DQ-Agent] & A2[Research-Agent] & A3[Code-Agent] & A4[Lineage-Agent] & A5[Validierungs-Agent]
        A1 & A5 --> H["👤 Human-in-the-Loop · PFLICHT\nAnomalie-Bestätigung - Meldungs-Freigabe - Eskalation"]
        H --> G["🔒 Guardrails\nKein autonomes Melden · Kein Echtdaten-Zugriff - Audit-Log je Aktion"]
    end

    %% ROLLEN
    subgraph R["Neue Rollen - Agenten-Ära"]
        R1[Agent Architect\ntechnisch] & R2[Agent Engineer\noperativ] & R3["★ Solution Owner\nFach + Governance + KI"]
    end

    %% OUTPUT
    subgraph O["Output & Reporting"]
        O1[Aufsicht\nEZB · BaFin] & O2[DQ-Dashboard] & O3[Audit Trail]
    end

    %% FLUSS
    Q --> D
    D --> DQ
    DQ --> M
    M --> K
    K --> A
    G --> R
    G --> O
    M --> O1

    %% STYLING
    classDef src   fill:#555555,stroke:#333,color:#fff
    classDef dwh   fill:#0F6E56,stroke:#084d3c,color:#fff
    classDef dql   fill:#534AB7,stroke:#3d3589,color:#fff
    classDef msv   fill:#185FA5,stroke:#0f4578,color:#fff
    classDef ki    fill:#854F0B,stroke:#5c3708,color:#fff
    classDef agt   fill:#7B2D8B,stroke:#5a1f66,color:#fff
    classDef hil   fill:#EF9F27,stroke:#c47d0a,color:#222
    classDef guard fill:#C00000,stroke:#8a0000,color:#fff
    classDef role  fill:#185FA5,stroke:#0f4578,color:#fff
    classDef owner fill:#EF9F27,stroke:#c47d0a,color:#222
    classDef out   fill:#993C1D,stroke:#711f0f,color:#fff

    class Q1,Q2,Q3,Q4 src
    class D1,D2,D3,D4 dwh
    class DQ1,DQ2,DQ3 dql
    class M1,M2,M3,M4,M5 msv
    class K1,K2,K3 ki
    class A0,A1,A2,A3,A4,A5 agt
    class H hil
    class G guard
    class R1,R2 role
    class R3 owner
    class O1,O2,O3 out

Schicht 1 – Quellsysteme

Kernbank | Risiko | Trading | Rechnungswesen

• Liefern die granularen Rohdaten auf Einzelgeschäftsebene
• Keine Transformation – rohe, unverfälschte Quelldaten
• Schnittstellen: API, CDC (Change Data Capture), Batch-Load

Schicht 2 – BIRD-konformes Data Warehouse (Fundament )

Single Source of Truth – Data Lineage – Versionierung

• Input Layer: Rohdaten werden unveränderlich gespeichert, mit Zeitstempel und Data Owner
• Critical Data Elements (CDEs): je Melderahmen definiert und dokumentiert
• Data Lineage Engine: jedes Attribut rückverfolgbar bis zum Quellsystem
• Transformation Layer: regulatorische Logik als versionierte dbt-SQL-Modelle, Git-basiert und jederzeit beauskunftbar.
• Output Layer: strukturierte Einzeldatensätze gemäß BIRD-Attributdefinition – bereit zur Übergabe an den jeweiligen Reporting-Service.
• Time Travel: historische Meldungen jederzeit exakt reproduzierbar und auswertbar im DWH.

Schicht 3 – Transformations- & DQ-Layer

Läuft vollständig lokal – keine KI-API, keine externen Aufrufe

• DQ-Service: Isolation Forest + Autoencoder für automatische Anomalieerkennung, wenn dieses eigenständig aufgesetzt werden will. Ansonsten kann hier auch bereits am Markt vorhandene Software genutzt werden.
• Lineage-Service: automatische Dokumentation von Datenflüssen und CDEs. Auch hier gilt: externe Software kann an der Stelle auch genutzt werden.
• Validierungs-Service: regelbasierte Plausibilitätsprüfung bekannter Geschäftsregeln
• Alles testbar, versioniert, mit Regressionsschutz

Schicht 4 – Regulatory Microservices

Je Melderahmen eigenständig – austauschbar, testbar, unabhängig

• AnaCredit-Service – IReF-Service
• Änderung in IReF betrifft nur den Service – kein Plattform-Release nötig
• Alle Services lesen aus derselben BIRD-DWH-Datenbasis
• Neue Anforderung = neuer Service, keine neue Plattform

Schicht 5 – KI-Layer

AWS Bedrock – DSGVO-konform – kein Training auf Kundendaten – SOC2/ISO27001

• Claude Sonnet als Regulatory Interpreter – Fragen in Sekunden beantwortet
• RAG-Pipeline auf regulatorischen Dokumenten und Texten.
• Code-Generierung: Python, SQL, auf Basis fachlicher Beschreibung
• KRITISCH: Nur synthetische/anonymisierte Daten und Schemabeschreibungen an KI – keine personenbezogenen Daten, keine Geschäftsdaten im Prompt.

Der DSGVO-Kniff: AWS Bedrock in der EU-Region trainiert meines Wissens nach nicht auf Kundendaten. Durch strikte Trennung «Schema ja, Echtdaten nein» bleibt die Architektur auch bei strengen internen Compliance-Richtlinien auf der sicheren Seite. Der Prompt enthält die fachliche Struktur – nicht den Inhalt.

Das Prinzip in einem Satz: Die KI sieht die Landkarte, nicht das Territorium.

Die drei Beispiele zeigen den Unterschied konkret:

Bei der DQ-Prüfung gilt: nicht „hier sind meine Daten, was stimmt nicht?“, sondern „hier ist meine Validierungsregel – schreib mir den passenden Python-Code“. Der Code wird anschließend lokal auf den Echtdaten ausgeführt, sodass keine sensiblen Daten an die KI übertragen werden.

Für die Fehleranalyse gilt: nicht „bei Kunde Müller GmbH schlägt Regel 1234 fehl“, sondern „Feldtyp Integer, Regel maturity_days > 0 schlägt fehl – was sind typische Ursachen?“. Übergeben wird also nur die Struktur des Fehlers, nicht der konkrete inhaltliche Bezug.

Code-Generierung: Nicht die CSV mit 500+ Zeilen Produktionsdaten – sondern das Schema: Feldnamen, Datentypen, Constraints. Das reicht vollständig um validen dbt-Code zu generieren.

Der Agenten-Layer – die nächste Evolutionsstufe

Agenten stellen kein Ersatz für Microservices dar. Sie sind eine Ausführungsebene darüber. Der DQ-Agent ruft den DQ-Service auf. Der Code-Agent schreibt dbt-Modelle, die dann im Transformation Layer laufen. Die Schichten bleiben – die Agenten orchestrieren die Arbeit zwischen ihnen.

Orchestrierungs-Agent

Plant Aufgaben, delegiert an Spezialagenten, überwacht Ergebnisse, entscheidet über Eskalation an einen Menschen.

Spezialisierte Agenten

Guardrails sind architektonisch zu verankern, nicht nur im Prompt: Kein autonomes Abschicken von Meldungen – Kein Echtdaten-Zugriff via KI – Audit-Log je Agent-Aktion -Human-in-the-Loop bei Anomalie-Bestätigung, Meldungs-Freigabe und Regelambiguitäten

Konkret: Wie der Code-Agent ein dbt-Modell erzeugt

Der entscheidende Punkt: Der Code-Agent schreibt SQL-Text – er führt nichts direkt auf der Datenbank aus. Acht Schritte vom Auftrag bis zum produktiven Modell:

• Auslöser – Orchestrierungs-Agent erkennt fehlende Transformationsregel, oder ein Mensch beauftragt direkt
• Kontext sammeln – Agent liest BIRD-Schema aus dem CDE-Katalog und bestehende dbt-Modelle als Stilvorlage – keine Echtdaten
• Prompt an Claude – Feldname, Datentyp und Zielattribut werden übergeben, nicht die Vertragsdaten selbst
• Claude generiert – eine vollständige .sql-Datei als reinen Text – noch keine Ausführung gegen die Datenbank
• Datei schreiben – der Agent legt die generierte Datei im dbt-Projekt-Repository ab
• Lokaler Testlauf – dbt run und dbt test laufen lokal – reine Tool-Ausführung, kein LLM mehr beteiligt. Schlägt der Test fehl, geht es zurück zu Schritt 3 mit der Fehlermeldung
• Human-in-the-Loop – Pull-Request-Review prüft die fachliche Mapping-Logik. Kein automatischer Merge – der Mensch entscheidet
• Merge in Produktion – erst jetzt wird das Modell Teil des regulären dbt run und läuft ab sofort bei jedem Pipeline-Durchlauf mit – versioniert, dokumentiert, Audit-Trail vollständig

Neue Rollen in der Agenten-Ära

Der Solution Owner in der Agenten-Ära ist nicht derjenige, der Agenten baut – sondern derjenige, der verantwortet, was sie tun. Er definiert Eskalationsregeln, stellt sicher, dass der Output regulär korrekt ist, und ist der Ansprechpartner, wenn ein Agent falsch entschieden hat. Das ist eine Fach- und Governance-Rolle mit technischem Verständnis.

Tech-Stack – heute verfügbar

Model Agnosticism als Architekturprinzip

AWS Bedrock mit Claude ist ein guter Einstieg – aber kein Pflichtprogramm. Die Architektur sollte von Anfang an modellunabhängig sein. Das Stichwort: Model Agnosticism. Wer den KI-Aufruf hinter einem einheitlichen Gateway abstrahiert, kann das Modell wechseln ohne die Architektur anzufassen – dasselbe Prinzip wie bei den Microservices.

Statt: response = claude.invoke(prompt)

Besser: response = llm_gateway.invoke(prompt, model=„claude-sonnet“)  –  oder model=„qwen-72b-local“  –  oder model=„mistral-large-eu“

Mögliche Tools dafür: LiteLLM als universelles Gateway, Ollama für lokale Modelle, LangChain als Abstraktionsschicht.

Drei Deployment-Optionen für den KI-Layer – je nach Datenschutzanforderung und Reifegrad:

Fazit: Architektur ist eine bewusste Entscheidung

Diese Architektur ist kein Zukunftsroman. Jede einzelne Komponente ist bereits heute verfügbar. Was fehlt, ist nicht die Technologie – sondern die Bereitschaft, Datenhoheit, Transparenz und Governance von Anfang an mitzudenken.

• BIRD gibt die Struktur vor.
• Microservices lösen die Plattformabhängigkeit.
• Agenten übernehmen die Orchestrierung.
• Der Mensch behält die Verantwortung – in den Daten und in den Prozessen.

Was haltet ihr von dieser Architekturskizze? Wo seht ihr die größten Hürden bei der Umsetzung – technisch, organisatorisch oder regulatorisch? Ich freue mich auf einen regen Austausch.