LLM-Halluzinationen im Wealth-Report: Warum Claude-Output nicht zum Kunden gehört

Das Problem: Warum LLMs bei Finanzzahlen systematisch driften

Ein Large Language Model rechnet nicht. Es sagt das nächste Token voraus. Diese Unterscheidung klingt akademisch, ist aber der Kern jedes Halluzinationsproblems im Client Reporting. Wenn Claude oder GPT in einem Portfoliobericht schreibt „Die Position MSCI World ETF erzielte im dritten Quartal eine Rendite von 4,7 Prozent”, dann hat das Modell diese Zahl nicht berechnet. Es hat sie generiert, weil sie statistisch plausibel ins Satzmuster passt.

Das funktioniert oft gut. Genau das ist das Problem. Bei neun von zehn Zahlen liegt das Modell nahe an der Wahrheit. Bei der zehnten driftet es. Und bei einem Quartalsreport mit 40 bis 80 Zahlen ist die Wahrscheinlichkeit, dass mindestens eine falsch ist, faktisch eins.

Die typischen Fehlertypen im Wealth-Kontext:

• Erfundene Renditen: Das Modell rundet 3,82 Prozent auf 3,8 oder „korrigiert” auf 4,0, weil der umgebende Text eine glattere Zahl nahelegt.
• Falsche Allokationsprozente: In einem Multi-Asset-Mandat mit zwölf Positionen summiert sich die Allokation im LLM-Output plötzlich auf 99,3 Prozent oder 101,2 Prozent. Das Modell verteilt die Restprozente nach Gefühl.
• Interpolierte Zeiträume: Sie geben dem Modell Daten zum 30. September. Im Text taucht plötzlich ein Vergleich „seit Jahresanfang” auf, den niemand angefragt hat, mit einer Zahl, die nirgendwo herkommt.
• Verwechselte Bezugsgrößen: Die TER einer Position wird zur Performance, die absolute Wertentwicklung zur prozentualen.

Das Problem eskaliert mit der Länge des Reports. Je länger der Kontext, je mehr Zahlen, desto höher die Drift. Bei einem zehnseitigen Reporting für ein vermögendes Privatkundenmandat ist ungeprüfter LLM-Output nicht akzeptabel. Punkt.

Ein Anschauungsbeispiel aus einem typischen Setup: Die Portfolio-API liefert für eine Apple-Position eine Quartalsperformance von 7,34 Prozent. Im generierten Kundenbrief steht „rund 7,5 Prozent”. Klingt harmlos. Ist es nicht. Bei einem Mandat über zwei Millionen Euro und einer Apple-Gewichtung von 4 Prozent ist die Differenz zwischen 7,34 und 7,5 Prozent ungefähr 128 Euro im ausgewiesenen Beitrag. Der Kunde sieht das. Und er fragt nach.

Regulatorischer Sprengstoff: WAG und MiFID II im Blick

Ab hier wird es haftungsrelevant. MiFID II Artikel 25 verlangt eine Geeignetheitserklärung, die nachweist, dass die erbrachte Anlageberatung zu den Zielen, der Risikobereitschaft und den Verhältnissen des Kunden passt. Artikel 27 fordert bestmögliche Ausführung und vollständige Dokumentation. Beide Pflichten verlangen, dass die ausgewiesenen Zahlen stimmen. Nicht „im Wesentlichen”, sondern exakt.

Das österreichische WAG 2018 verschärft das in Paragraph 47 und 48 nochmals: Die Beratungsdokumentation muss nachvollziehbar, vollständig und prüfbar sein. Die FMA prüft das im Rahmen der laufenden Aufsicht.

Die entscheidende Grenze für KI im Beratungsprozess: Solange das Modell als internes Arbeitsmittel dient, etwa um interne Notizen zu strukturieren oder Researchmaterial zusammenzufassen, ist die Compliance-Last überschaubar. Sobald aus dem LLM-Output Kundeninformation wird, egal ob im Quartalsreport, in der Anlageempfehlung oder in der Beratungsdokumentation, gilt: Die Bank haftet für jeden Inhalt. Auch für die halluzinierten 7,5 Prozent.

Aus meiner Sicht ist das die Stelle, an der die meisten Häuser den Fehler machen. Der Client Advisor bekommt einen Claude-Zugang, generiert sich Reporting-Entwürfe, kürzt die Prüfzeit und schickt das Ergebnis raus. Sechs Monate später kommt der erste Kunde mit einem Excel-Vergleich und fragt, warum die Zahlen abweichen. Die Aufsicht stellt im nächsten Prüfzyklus die Frage, wie die Erstellung dokumentiert ist. Eine saubere Antwort gibt es dann meistens nicht.

Die BaFin hat in ihrer Orientierungshilfe zu KI im Wertpapiergeschäft aus 2023 deutlich gemacht: Der Einsatz generativer KI für kundenbezogene Inhalte braucht eine dokumentierte Validierungskette. Ohne diese Kette ist der Output nicht regelkonform, egal wie gut er klingt.

Haftungsrechtlich liegt das Risiko beim Berater und beim Institut, nicht beim Modellanbieter. Anthropic, OpenAI und Google schließen in den AGB jede Haftung für generierten Output aus. Das ist in der Branche bekannt, wird aber in der internen Risikoabwägung oft ignoriert.

Anatomie eines unsicheren Setups

Im typischen DACH-Wealth-Setup, das ich in Gesprächen immer wieder sehe, bauen Berater oder kleine IT-Teams folgendes:

Anti-Pattern 1: Rohdaten direkt in den Prompt. Der Berater exportiert die Positionsliste als CSV oder kopiert eine Excel-Tabelle in den Chat. Dann der Auftrag: „Erstelle daraus einen Quartalsbericht für Kunde Müller.” Das Modell muss jetzt gleichzeitig die Zahlen interpretieren, plausibilisieren und in Text gießen. Genau die Konstellation, in der die Drift maximal wird.

Anti-Pattern 2: LLM als Rechner. „Berechne die gewichtete Performance über alle Positionen.” Das Modell tut so, als würde es rechnen. Tatsächlich generiert es eine plausibel aussehende Zahl. Bei einfachen Summen klappt das oft. Bei gewichteten Durchschnitten, Sharpe-Ratios oder Time-Weighted-Returns nicht.

Anti-Pattern 3: Kein Output-Logging. Der generierte Text wird per Copy-Paste ins Kundenmail übernommen. Im Audit-Trail steht nichts. Welcher Prompt, welches Modell, welcher Output, welche Korrekturen durch den Berater. Alles weg. Für die Compliance ist das ein blinder Fleck.

Retrieval-Augmented Generation, also RAG, löst das Zahlenproblem nicht. RAG verbessert die Faktentreue bei textuellen Informationen, weil das Modell auf einen geprüften Wissensbestand zugreift. Bei numerischen Daten bleibt die Drift bestehen, sobald das Modell die Zahl in den Generierungsprozess übernimmt. Die Zahl steht im Kontext, ja. Aber das autoregressive Sampling kann sie trotzdem leicht verändern, besonders wenn der umgebende Text eine andere Zahl nahelegt.

Das sichere Architektur-Pattern: Tool Calling plus LLM nur für Narrativ

Das Kernprinzip lautet: Die Zahlen-Hoheit gehört zur Portfolio-API. Das LLM darf Zahlen sehen, darf sie aber nicht generieren.

Der Ablauf in Schritten:

1. Trigger: Der Berater löst die Reporterstellung für einen bestimmten Kunden und Zeitraum aus. Keine freie Eingabe von Zahlen.
2. Portfolio-API-Call: Ein Tool-Call holt strukturierte Daten aus dem Portfoliomanagementsystem. Positionen, Performance, Allokationen, Vergleichszeiträume. Alles als typisiertes JSON, mit definierten Feldnamen und Einheiten.
3. Validierungs- und Berechnungsschicht: Sämtliche Aggregationen (gewichtete Performance, Beitrag pro Position, Allokationssummen) werden in deterministischem Code berechnet. Nicht im LLM. Python, SQL oder die API selbst, egal, aber nicht generativ.
4. LLM-Kontext: Das fertig berechnete JSON wird dem Modell als strukturierter Kontext übergeben, mit der expliziten Anweisung: Verwende ausschließlich die Zahlen aus diesem Block. Schreibe keine eigenen Berechnungen. Wenn eine Zahl fehlt, schreibe „[Daten nicht verfügbar]”.
5. Generierung des Narrativs: Das Modell produziert ausschließlich Fließtext. Einordnungen, Kommentare, Marktkontext. Die Zahlen werden über Template-Slots eingefügt, nicht vom Modell getippt.
6. Post-Validierung: Ein deterministischer Check vergleicht jede Zahl im Output gegen das JSON. Findet sich eine Zahl im Text, die nicht im strukturierten Input steht, wird der Report zur manuellen Prüfung markiert.
7. Logging: Prompt, Modellversion, Input-JSON, Output-Text und Validierungsergebnis werden revisionssicher gespeichert. Aufbewahrungsfrist mindestens fünf Jahre nach WAG.

Ein Beispiel für ein Tool-Schema, vereinfacht:

{
  "name": "get_portfolio_performance",
  "parameters": {
    "client_id": "string",
    "period_start": "date",
    "period_end": "date",
    "benchmark": "string"
  },
  "returns": {
    "positions": [{
      "isin": "string",
      "name": "string",
      "weight_pct": "decimal(5,2)",
      "performance_pct": "decimal(7,4)",
      "contribution_pct": "decimal(7,4)"
    }],
    "total_performance_pct": "decimal(7,4)",
    "benchmark_performance_pct": "decimal(7,4)"
  }
}

Mit decimal-Typisierung und festen Nachkommastellen ist die Drift technisch ausgeschlossen. Das Modell sieht 7,3400 und schreibt 7,3400 in den Template-Slot. Es kann nicht „rund 7,5” daraus machen, weil es die Zahl gar nicht selbst produziert, sondern aus einem geschützten Feld einfügt.

Die Validierungsschicht ist der entscheidende Sicherheitsgurt. Sie prüft mit einem Regex jede Zahl im Outputtext gegen den Inputblock. Findet sich eine Abweichung, geht der Report nicht raus. So einfach.

Implementierungs-Roadmap für DACH-Banken

Phase 1: Bestandsaufnahme. Welche Reporting-Workflows nutzen heute ungekoppelten LLM-Einsatz? Wo sitzen die Berater mit Claude-Pro-Accounts und generieren Entwürfe? Das ist meistens unangenehm zu erfragen, weil viel davon Shadow-AI ist. Aber ohne ehrliche Bestandsaufnahme starten Sie blind. Zeitrahmen: zwei bis drei Wochen.

Phase 2: API-Anbindung und Tool-Schema-Definition. Hier kostet es Zeit. Die meisten Portfoliomanagementsysteme in DACH (Avaloq, Olympic, Geos, eigene Lösungen) haben REST-APIs, aber die Datentypen sind oft nicht sauber numerisch. Strings, gemischte Einheiten, regional unterschiedliche Dezimaltrenner. Diese Schicht zu härten, ist Arbeit. Realistisch: drei bis sechs Monate, abhängig von der Anzahl der Mandatstypen.

Phase 3: Prompt-Engineering für rein narrativen Output. Der System-Prompt muss explizit verbieten, dass das Modell Zahlen schreibt, die nicht im Inputblock stehen. Das klingt einfach, ist es aber nicht. Das Modell hat eine starke Tendenz, Zahlen zu „glätten” oder „natürlicher” zu formulieren. Sie brauchen Tests gegen eine repräsentative Stichprobe von Mandaten und müssen den Prompt mehrfach iterieren. Vier bis acht Wochen.

Phase 4: Human-in-the-Loop für den Rollout. In der ersten Phase prüft der Berater jeden Report vollständig. Nach drei bis sechs Monaten mit nachweislich sauberer Validierungsschicht und Logging können Sie das Prüfregime lockern, etwa auf Stichprobenbasis. Vollständig autonom geht im aktuellen regulatorischen Rahmen nicht und sollte auch nicht das Ziel sein.

Typische Stolpersteine: Die IT will den schnellen Weg über einen direkten LLM-Aufruf gehen, ohne Tool-Layer. Der Vorstand möchte Zeitersparnis sehen, bevor die Validierungsschicht steht. Die Compliance ist erst spät im Projekt eingebunden. Drei Muster, die ich immer wieder beobachte. Alle drei sind vermeidbar, wenn die Reihenfolge der Phasen eingehalten wird.

Fazit

KI im Client Reporting ist möglich. Sie spart messbar Zeit. Aber nur mit klarer Architektur-Hygiene: Zahlen-Hoheit bei der API, LLM ausschließlich für Narrativ, deterministische Validierung vor Versand, vollständiges Logging für die Aufsicht.

Was Aufgabe des menschlichen Beraters bleibt: die Einordnung der Zahlen im Kundengespräch, die Plausibilisierung gegen die individuelle Anlagestrategie, die Beantwortung von Rückfragen. Das LLM ist Werkzeug, nicht Berater. Diese Trennung in der eigenen Architektur sichtbar zu machen, ist die eigentliche Aufgabe.

Wenn Sie in Ihrer Bank, Ihrer Vermögensverwaltung oder Ihrem Family-Office ein bestehendes Reporting-Setup mit LLM-Einsatz haben und nicht sicher sind, ob die Architektur einer FMA- oder BaFin-Prüfung standhält: Melden Sie sich. Ein Review der bestehenden Workflows und der Validierungskette dauert in der Regel zwei bis drei Tage. Das ist deutlich günstiger als die Nachbearbeitung nach dem ersten Kundenbeschwerdefall.