Die KI-Architektur für das Meldewesen der Zukunft

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

u.a. 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: IIsolation Forest + Autoencoder für automatische Anomalieerkennung, wenn dieses eigenständig aufgesetzt werden will. Ansonsten kann hier auch bereits am Markt vorhandene Software genutzt werden. Wichtig: Die ML-Modelle (Isolation Forest, Autoencoder) werden ausschließlich auf internen Produktionsdaten trainiert und verbleiben vollständig in der eigenen Infrastruktur – kein Modelltransfer nach außen.
• 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

• bspw. AnaCredit-Service / IReF-Service (IReF: derzeit im Aufbau, produktive Meldepflicht ab ca. 2027/2028+)
• Ä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 / Azure – kein Training auf Kundendaten (vertraglich abgesichert, nicht nur konfigurierbar) – nur EU-Regionen – AVV/DPA erforderlich

• Claude Sonnet als Regulatory Interpreter – Fragen in Sekunden beantwortet
• RAG-Pipeline auf regulatorischen Dokumenten und Texten.
• Code-Generierung: Python, SQL, auf Basis fachlicher Beschreibung
• Cross-Region Inference deaktivieren – ausschließlich EU-Regionen nutzen (eu-central-1, eu-west-1), kein Transfer in US-Regionen
• AWS Bedrock in der EU‑Region unterstützt eine DSGVO‑konforme Nutzung, wenn keine personenbezogenen Daten im Prompt landen und geeignete technische und organisatorische Maßnahmen umgesetzt sind.
• KRITISCH: Nur anonymisierte Daten und Schemabeschreibungen an KI – keine personenbezogenen Daten, keine Geschäftsdaten im Prompt. Auch Metadaten (Feldnamen, Tabellennamen mit Geschäftsbezug) sind vorab auf Personenbezug zu prüfen.

DSGVO-Anforderungen im KI-Layer – Checkliste für den Einsatz im Bankumfeld:

• DPIA (Art. 35 DSGVO) durchführen – bei KI-gestützter Verarbeitung in Kreditinstituten in der Regel verpflichtend
• AVV/DPA mit dem Cloud-Anbieter (AWS, Azure) abschließen
• Cross-Region Inference deaktivieren – nur EU-Regionen zulassen
• Prompt-Design: Keine personenbezogenen Daten, keine Echtdaten. Auch Metadaten (Feldnamen) auf Personenbezug prüfen.
• Technische und organisatorische Maßnahmen (TOMs) dokumentieren
• Prompt Injection als Sicherheitsrisiko berücksichtigen: Wenn Agenten dynamisch Schema-Informationen oder CDE-Beschreibungen in den Prompt laden, können indirekt persönliche Daten einfließen – Eingaben sind entsprechend zu validieren.

Der Agenten-Layer – die nächste Evolutionsstufe

Agenten stellen keinen Ersatz für Microservices dar, sondern bilden eine zusätzliche Ausführungsebene darüber. Der DQ-Agent ruft weiterhin den DQ-Service auf, während der Code-Agent dbt-Modelle schreibt, die dann im Transformation Layer laufen. Auf diese Weise bleiben die Schichten unverändert, allerdings orchestrieren die Agenten die Arbeit zwischen ihnen deutlich flexibler und besser nachvollziehbar.

Überblick der spezialisierten Agenten

Der Orchestrierungs-Agent plant Aufgaben, delegiert sie an Spezialagenten, überwacht die Ergebnisse und entscheidet schließlich darüber, wann an einen Menschen eskaliert werden muss. Dadurch entsteht ein klarer Fluss: Zunächst arbeitet der Agent autonom innerhalb definierter Grenzen, anschließend prüft ein fachlich verantwortlicher Mensch die kritischen Punkte. So wird die Geschwindigkeit von KI genutzt, ohne die regulatorische Verantwortung aus der Hand zu geben.

Guardrails sind dabei nicht nur im Prompt, sondern vor allem architektonisch im Gesamtsystem zu verankern. Zum einen dürfen KI-Agenten Meldungen niemals autonom absenden, sondern agieren ausschließlich vorbereitend. Zum anderen ist ein direkter Zugriff der KI auf Echtdaten grundsätzlich ausgeschlossen, sodass alle sensiblen Datenzugriffe über klar berechtigte, traditionelle Anwendungsschichten laufen. Zusätzlich wird jede Agent-Aktion mit vollständigem Audit-Log (Eingaben, Entscheidungen, verwendete Tools, Versionen, Genehmigungen) nachvollziehbar protokolliert. Schließlich ist an allen kritischen Punkten – insbesondere bei Anomalie-Bestätigung und bei der Auslegung oder Auflösung von Regelambiguitäten – obligatorisch ein Human-in-the-Loop-Freigabeprozess vorgesehen, der fachliche Verantwortung, Vier-Augen-Prinzip und regulatorische Nachvollziehbarkeit sicherstellt.

Aufgabenbeschreibung der Agenten

Der DQ-Agent überwacht den Input Layer, führt definierte Datenqualitätsprüfungen aus, markiert Auffälligkeiten und erstellt einen strukturierten DQ-Report mit klaren Findings und Empfehlungen. Er ruft dazu den DQ-Service auf, greift bei Bedarf lesend auf das Data Warehouse zu und eskaliert kritische Anomalien an menschliche Fachexperten zur finalen Beurteilung. Dadurch bleibt die fachliche Entscheidung nach wie vor beim Menschen, während die Vorbereitung deutlich effizienter und konsistenter wird.

Der Research-Agent durchsucht die Dokumentation und interpretiert die Spezifikationen, um fachliche Fragen aus dem Regulatory-Reporting-Kontext verständlich und konsistent zu beantworten. Dafür nutzt er eine RAG-Pipeline auf Basis von Claude sowie die angebundenen BIRD-APIs, sodass Antworten stets auf den aktuell gültigen fachlichen Vorgaben beruhen. Gleichzeitig reduziert er Medienbrüche, weil Fachbereich und IT auf dieselbe Wissensquelle zugreifen und damit deutlich schneller zu abgestimmten Interpretationen kommen.

Der Code-Agent generiert Python- und dbt-Modelle für Datenpipelines, führt Tests zu deren Korrektheit und Performance aus und bereitet die Artefakte für die Integration in die bestehende Landschaft vor. Er nutzt dafür eine Code-Ausführungsumgebung, Claude zur Code-Generierung und -Überarbeitung sowie Git für Versionierung und saubere Change-Nachverfolgung im Sinne von DevOps- und Compliance-Anforderungen. Dadurch lassen sich neue Transformationslogiken schneller erstellen, während dennoch alle regulatorisch relevanten Schritte dokumentiert, prüfbar und jederzeit reproduzierbar bleiben.

Der Lineage-Agent dokumentiert die Datenherkunft (Data Lineage) automatisch über alle relevanten Stufen hinweg und pflegt den CDE-Katalog (Critical Data Elements) aktuell. Dazu liest er Informationen aus dem Data Warehouse und dem Metadatenkatalog aus, verknüpft technische mit fachlichen Objekten und macht so Abhängigkeiten, Auswirkungen von Änderungen und Verantwortlichkeiten transparent. Auf diese Weise vereinfacht er sowohl Impact-Analysen als auch die Beantwortung regulatorischer Nachfragen der Aufsicht, weil Datenwege und Verantwortlichkeiten jederzeit sichtbar sind.

Der Validierungs-Agent prüft die Daten vor der Abgabe von Meldungen auf fachliche Plausibilität und Regelkonformität und stellt damit eine zusätzliche Sicherungsschicht vor der regulatorischen Einreichung dar. Er nutzt dazu den Validierungs-Service, um definierte Regeln auszuführen, und bindet bei Unklarheiten oder kritischen Abweichungen einen Human-in-the-Loop-Eskalationspfad ein, sodass finale Freigaben immer in fachlicher Verantwortung bleiben. Gerade dadurch passt der Agenten-Layer gut zu bestehenden Governance-Strukturen, statt sie zu unterlaufen, und stärkt zugleich die Qualität und Nachvollziehbarkeit im Meldewesen.

Praxisbeispiel: 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.

Agent Architect (technischer Schwerpunkt)

Ein Agent Architect ist für das konzeptionelle Design der Agentenlandschaft verantwortlich und denkt primär in Architektur, Sicherheit und Governance, während ein Agent Engineer diese Agenten praktisch umsetzt, betreibt und im Alltag am Laufen hält. Damit definiert er die Leitplanken, in denen Agent Engineers operativ arbeiten.

Agent Engineer

Der Agent Engineer setzt die vom Architect geplanten Konzepte praktisch um und baut die Agenten inklusive der notwendigen Tools und Integrationen. Er schreibt und pflegt Prompts, Tool-Definitionen und die Anbindung an bestehende Services, damit die Agenten ihre Aufgaben zuverlässig ausführen können. Darüber hinaus testet er das Verhalten der Agenten, simuliert typische und kritische Szenarien und stellt sicher, dass Guardrails korrekt greifen. Im laufenden Betrieb überwacht er die Ausführung, reagiert auf Fehler, optimiert Performance und verbessert die Agenten iterativ anhand von Monitoring- und Logging-Daten. Diese Rolle ist damit eher operativ‑umsetzend geprägt und sorgt dafür, dass die in der Architektur vorgesehenen Fähigkeiten stabil im Tagesgeschäft ankommen.

Tech-Stack – heute verfügbar

Model Agnosticism als Architekturprinzip

Die Architektur sollte von Anfang an modellunabhängig sein, 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.

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.