Generative KI im
Bankreporting –
Lokale Inferenz,
empirische Befunde
und regulatorische Einordnung

1   Problemstellung und Motivation

Bankreporting ist das informationelle Rückgrat regulatorischer und strategischer Entscheidungen. Die Spanne reicht von der quartalsmäßigen Risikodeckungsmassenberechnung im Rahmen des ICAAP über MaRisk-konforme Lageberichte bis hin zu Vorstandsvorlagen mit KPI-basierter Interpretation. Gleichzeitig ist der Prozess in einer strukturellen Ineffizienz gefangen: Der überwiegende Teil der Arbeitszeit im Bankencontrolling entfällt nicht auf die Ermittlung von Kennzahlen – diese ist weitgehend automatisiert –, sondern auf deren sprachliche Aufbereitung, Kontextualisierung und Kommentierung.

Diese Aufgabe folgt in hohem Maße reproduzierbaren Mustern: Abweichungsanalysen, Trendinterpretationen, Einordnungen in regulatorische Schwellenwerte. Exakt hier liegt das operative Potenzial generativer Sprachmodelle. LLMs sind keine numerischen Analysewerkzeuge – sie berechnen keine Kennzahlen und schließen keine Datenlücken. Ihre Stärke liegt in der Transformation strukturierter Daten in sprachliche Repräsentationen: in kohärenter, managementtauglicher Prosa, die einem analytischen Rahmen folgt.

Die zentrale Forschungsfrage dieses Beitrags lautet entsprechend: Unter welchen technischen und organisatorischen Bedingungen ist lokale LLM-Inferenz für das bankaufsichtliche Reporting operativ einsetzbar – und welche Grenzen sind dabei nicht überschreitbar?

2   Technischer Aufbau des Experiments

2.1 Modellauswahl

Die Wahl fiel auf Mistral-7B Instruct v0.2 im GGUF-Format (Q4_K_M-Quantisierung). Diese Entscheidung war das Ergebnis eines Abwägungsprozesses entlang dreier Kriterien:

• RAM-Footprint: Quantisierte 7B-Modelle benötigen ca. 5–6 GB RAM im Modellspeicher, was auf Büroservern ohne GPU realisierbar ist. Modelle der 13B- und 70B-Klasse scheiden bei einer 32-GB-Infrastruktur entweder vollständig aus oder erfordern aggressive Quantisierung mit deutlichem Qualitätsverlust.
• Instruction-Following: Mistral-7B weist im MMLU-Benchmark und in Instruction-Following-Evaluierungen (MT-Bench) eine für seine Größenklasse überdurchschnittliche Leistung auf. Insbesondere die strukturierte Textgenerierung auf Basis tabellarischer Eingaben zeigte in Vorabtests konsistente Ergebnisse.
• Lizenz und Deployment: Das Modell steht unter der Apache-2.0-Lizenz und erlaubt kommerziellen Einsatz ohne Lizenzgebühren. Die Bereitstellung erfolgte über Ollama – ein lokal laufendes Inferenz-Framework, das HTTP-basierte Anfragen ohne Netzwerkkontakt verarbeitet.

Für den Vergleich wurden in einem Vortest auch Llama 3.2 (8B) und Phi-4-Mini (3.8B) evaluiert. Llama 3.2 erzielte vergleichbare Ergebnisse bei höherem RAM-Bedarf; Phi-4-Mini zeigte bei komplexen Tabellenstrukturen messbar mehr Ausreißer in der Strukturtreue.

2.2 Hardware und Deployment

2.3 DSGVO-Konformität: technische Fundierung

Die Frage der DSGVO-Konformität wird in der Debatte häufig pauschal beantwortet. Eine technische Fundierung ist jedoch erforderlich, da die Konformität nicht vom Modell abhängt, sondern von der Deployment-Architektur. Folgende Eigenschaften begründen die datenschutzrechtliche Unbedenklichkeit im vorliegenden Setup:

• Lokale Inferenz: Das Modell läuft vollständig auf dem eigenen Server. Es findet kein API-Aufruf an externe Dienste statt. Damit entfällt die Notwendigkeit eines Auftragsverarbeitungsvertrags (Art. 28 DSGVO) gegenüber Drittanbietern.
• Kein Training durch Nutzerdaten: Ollama und llama.cpp führen ausschließlich Inferenz durch. Die Eingabedaten werden nicht zur Modelloptimierung verwendet und nach dem Inference-Call nicht persistiert.
• Keine externen Logs: Das System generiert keine Telemetrie-Daten und kommuniziert nicht mit Update-Servern während der Nutzung.
• Air-Gap-Option: Der Server kann vollständig netzwerkisoliert betrieben werden, was auch für besonders schützenswerte Daten (§ 25 DSGVO, Kreditnehmerdaten) relevant ist.

Hinweis: Die rechtliche Bewertung im Einzelfall obliegt dem zuständigen Datenschutzbeauftragten. Die genannten technischen Eigenschaften bilden jedoch eine belastbare Grundlage.

2.4 Datenbasis und Testumfang

Als Eingabedaten wurden synthetisch generierte, aber strukturell realistische KPI-Zeitreihen über acht Quartale verwendet. Die Werte orientierten sich an typischen Ausprägungen einer mittelgroßen Genossenschaftsbank (Bilanzsumme 500–1.500 Mio. Euro): LCR zwischen 120 % und 185 %, NPL-Quoten zwischen 1,2 % und 3,8 %, Cost-Income-Ratio zwischen 62 % und 78 %. Insgesamt wurden 40 Berichtsgenerierungen in vier Szenarien durchgeführt (stabile Lage, Liquiditätsrückgang, NPL-Anstieg, kombiniertes Stressszenario), jeweils mit drei Prompt-Varianten.

3   Prompt-Engineering als Kernarchitektur

Die häufigste Fehlannahme beim Einsatz von LLMs in Fachkontexten ist die Gleichsetzung von Modellqualität und Ergebnisqualität. Tatsächlich ist der Prompt – nicht das Modell – die primäre Determinante für Präzision, Strukturtreue und fachliche Adäquatheit des Outputs. Ein unstrukturierter Prompt liefert auch bei einem überlegenen Modell inkonsistente Ergebnisse; ein präziser Prompt erzeugt mit einem mittelmäßigen Modell stabile, verwertbare Ausgaben.

Für dieses Experiment wurden drei Prompt-Generationen entwickelt und iterativ optimiert. Die finale Version enthielt folgende Strukturelemente:

import pandas as pd

df = pd.read_excel("kpi_dashboard.xlsx")
kpi_block = df.to_string(index=False)

prompt = f"""
[ROLLE]
Du bist Referent für Gesamtbanksteuerung einer deutschen
Genossenschaftsbank. Du erstellst Vorstandsvorlagen auf
Basis von KPI-Zeitreihen.

[KONTEXT]
Berichtszeitraum: Q3 2024
Vergleichszeitraum: Q3 2023 und Durchschnitt Q1–Q2 2024
Regulatorischer Rahmen: MaRisk, ICAAP

[DATENBASIS]
{kpi_block}

[AUFGABE]
Erstelle einen strukturierten Risikobericht mit:
1. Management Summary (max. 120 Wörter, kein Fachjargon)
2. Kritische KPI-Entwicklungen: Top 3 nach Handlungsdringlichkeit
3. Trendanalyse mit Ursachenhypothesen (klar als Hypothese
   kennzeichnen)
4. Handlungsempfehlungen mit Zeithorizont

[STIL]
Sachlich, präzise. Keine wertenden Adjektive ohne
Datenbasis. Zahlenwerte immer mit Vorperiode angeben.
Unvollständige Datenlage explizit benennen.
"""

4   Empirische Befunde

4.1 Qualität der Narrativbildung

Die auffälligste Stärke des Systems lag in der kohärenten Verbindung mehrerer KPIs zu einem Risikobild. Statt isolierter Einzelaussagen generierte das Modell kausale Ketten, die dem analytischen Vorgehen erfahrener Controller ähneln:

„Die NPL-Quote ist im Berichtsquartal von 2,1 % auf 2,4 % gestiegen (+0,3 Pp. ggü. Vorquartal). In Verbindung mit dem gleichzeitigen Rückgang des Zinsüberschusses um 4,2 % ergibt sich eine doppelseitige Belastung der Risikodeckungsmasse, die nach aktuellem Stand mit einem Puffer von 18 Mio. Euro noch ausreichend abgedeckt ist. Eine Fortschreibung des Trends über zwei weitere Quartale würde den Puffer auf unter 10 % des regulatorischen Mindestwertes reduzieren – eine proaktive Überprüfung der Kreditrisikosteuerung wird empfohlen."

Diese Passage wurde ohne manuellen Eingriff generiert. Die Zahlenwerte sind korrekt aus dem Eingabe-DataFrame extrahiert; die Trendprojektion ist transparent als Hypothese formuliert. In der qualitativen Bewertung durch zwei Fachexperten wurde der Output in 78 % der Fälle als „unmittelbar berichtsreif nach redaktioneller Durchsicht" eingestuft.

4.2 Schwächen und Ausreißer

In 8 von 40 Durchläufen (20 %) traten strukturelle Abweichungen auf: fehlende Abschnitte, verkürzte Handlungsempfehlungen oder Duplikation von Textbausteinen. Diese Ausreißer korrelierten signifikant mit langen Eingabe-DataFrames (mehr als 35 Tabellenzeilen), was auf eine Degradation der Attention-Mechanismen bei langen Kontexten hinweist – ein bekanntes Phänomen bei 7B-Modellen mit Standard-Kontextfenstern.

Regulatorische Spezifika (exakte MaRisk-Paragraphen, CRR-Artikel) wurden in 11 % der Fälle fehlerhaft oder unvollständig wiedergegeben. Das Modell ist nicht als Rechtsquelle zu verwenden; alle regulatorischen Aussagen müssen durch Human-in-the-Loop validiert werden.

5   Governance und regulatorische Einordnung

5.1 Klassifizierung nach EU AI Act

KI-gestützte Systeme, die im Kontext der Kreditrisikobewertung oder des bankaufsichtlichen Reportings eingesetzt werden, fallen nach Annex III Nr. 5(b) EU AI Act voraussichtlich in die Kategorie High-Risk AI System. Dies zieht folgende Verpflichtungen nach sich: Risikomanagement-System (Art. 9), Daten-Governance (Art. 10), technische Dokumentation (Art. 11), Record-Keeping (Art. 12), Transparenz gegenüber Nutzern (Art. 13), Human Oversight (Art. 14) und Genauigkeits- und Robustheitsanforderungen (Art. 15).

Für Kreditinstitute, die ohnehin unter MaRisk und DORA operieren, bedeutet dies in der Praxis keine unüberwindliche Hürde – die regulatorischen Anforderungen sind in weiten Teilen deckungsgleich mit bestehenden IT-Governance-Vorgaben. Entscheidend ist, dass das KI-System von Beginn an in das institutionelle Risikomanagement integriert und nicht als informelles Werkzeug betrieben wird.

6   Die strukturelle Verschiebung im Controlling

Die wesentliche Erkenntnis lautet nicht, dass menschliche Expertise ersetzt wird, sondern dass sie auf eine höherwertige Ebene verlagert wird. Der Controller der Zukunft im Bankenkontext validiert, interpretiert und verantwortet – er formuliert nicht mehr. Diese Verschiebung ist keine Bedrohung für Qualifikationen, sondern eine strukturelle Aufwertung der analytischen Kernkompetenz.

7   Implementierungspfad für Kreditinstitute

Auf Basis der Experimentbefunde lässt sich ein dreistufiger Implementierungspfad ableiten, der auch für Institute mit begrenzten IT-Ressourcen realisierbar ist:

1. Proof of Concept (4–6 Wochen): Installation von Ollama und Mistral-7B auf einem vorhandenen Server mit mindestens 32 GB RAM. Entwicklung eines initialen Prompt-Templates für einen klar abgegrenzten Berichtstyp (z.B. monatliche Liquiditätslagebeurteilung). Bewertung der Output-Qualität durch Fachexperten anhand eines Kriterienkatalogs.
2. Pilotbetrieb unter Governance (3–4 Monate): Einführung der Governance-Elemente G1–G5 (vgl. Abbildung 4). Parallelbetrieb mit manuellem Prozess; systematische Dokumentation von Abweichungen. Abstimmung mit Datenschutzbeauftragtem und ggf. Informationssicherheitsbeauftragtem.
3. Operativer Rollout: Ausweitung auf weitere Berichtstypen nach erfolgreicher Pilotphase. Integration in bestehende Reporting-Infrastruktur. Einbindung in das institutionelle Risikoinventar gemäß MaRisk AT 7.2.

Die Gesamtinvestition für Phase 1 liegt – bei vorhandener Serverinfrastruktur – ausschließlich im Personalaufwand für die Prompt-Entwicklung und Evaluation: erfahrungsgemäß 15–25 Arbeitstage in der Fachbereichs-IT.

8   Fazit

Die Experimentbefunde belegen, dass lokale LLM-Inferenz für das Bankreporting technisch realisierbar und unter den beschriebenen Bedingungen auch datenschutzrechtlich unbedenklich ist. Die Einstiegshürde ist überraschend gering: 32 GB RAM, Ollama, ein sorgfältig entwickeltes Prompt-Template und ein strukturierter Governance-Prozess bilden eine funktionsfähige Minimalarchitektur.

Gleichzeitig sind die Grenzen des Ansatzes nicht zu relativieren. Das Modell rechnet nicht; es interpretiert auf der Grundlage sprachlicher Muster. Halluzinationen sind reduzierbar, aber nicht eliminierbar. Regulatorische Sachverhalte müssen fachlich validiert werden. Human-in-the-Loop ist keine Option, sondern strukturelle Voraussetzung.

Die entscheidende strategische Implikation für Kreditinstitute lautet: Wer heute beginnt, Reporting-Wissen in strukturierten Prompt-Bibliotheken zu institutionalisieren, baut einen Wettbewerbsvorteil auf, der mit zunehmender Modellqualität exponentiell an Wert gewinnt. Die Frage ist nicht mehr, ob generative KI im bankaufsichtlichen Reporting eingesetzt wird – sondern welche Institute diese Transformation aktiv gestalten und welche sie reaktiv absolvieren.