← Alle Beiträge
28.07.2026 · 8 min

KI-Protokolle vor der Ombudsstelle: Suitability im Praxistest

Drei typische Ombudsstellen-Fälle zeigen, wo KI-gestützte Suitability-Prüfungen scheitern und warum IDD-konforme Dokumentation nicht schützt.

Einleitung: Die Ombudsstelle als Lackmustest für KI-gestützte Beratung

Die Zahl der Beschwerden bei der Ombudsstelle für Finanzberatung steigt. In den veröffentlichten Tätigkeitsberichten ist ein neues Muster erkennbar: Fälle, in denen die Anlageempfehlung nicht vom Menschen allein stammte, sondern von einem KI-gestützten System. Anders als früher, wo Fehlberatungen meist auf unvollständige Erfassung der Kundenangaben oder schlichte Fehleinschätzung zurückgingen, geht es heute um Prozesse, die formal korrekt dokumentiert sind, deren inhaltliche Geeignetheit aber nicht standhält.

Das ist eine neue Qualität. Ein Berater kann sich nicht mehr allein auf ein Beratungsprotokoll verlassen, das die IDD-Kriterien abhakt, wenn der dahinterstehende Algorithmus die falsche Logik verfolgt hat. Die Ombudsstelle prüft nicht nur, ob die Dokumentation stimmt. Sie prüft, ob die Empfehlung zum Kunden passt. Und genau dieser Gap zwischen formaler Compliance und materieller Richtigkeit wird bei KI-Einsatz gefährlich.

Meine These: Der Suitability-Algorithmus optimiert den Prozess, nicht die Substanz. Er erzeugt eine formal saubere Spur, aber die inhaltliche Prüfung bleibt lückenhaft. Das fällt spätestens vor der Ombudsstelle auf und wird für Honorarberater und Vermögensverwalter zum Haftungsrisiko.

Dieser Artikel zeigt anhand typischer Fallmuster, wo KI-Suitability-Systeme regelmäßig scheitern, was die IDD tatsächlich verlangt und wie Sie Ihren KI-Einsatz ombudsstellenfest machen.

Anatomie eines Suitability-Algorithmus: Wo die Logik bricht

Moderne KI-Assistenten für die Anlageberatung arbeiten meist mit großen Sprachmodellen (LLMs), ergänzt um embeddingsbasierte Suche und Scoring-Komponenten. Der typische Ablauf: Kundenangaben werden vektorisiert, im Datenbestand passende Produkte gesucht, Rankingergebnisse generiert und eine Top-N-Liste dem Berater vorgeschlagen. Formal lässt sich das als „intelligentes Matching" verkaufen. In der Praxis offenbaren sich drei systematische Schwachstellen.

Erstens: Trainingsbias. Die Modelle lernen aus historischen Verkaufsdaten, nicht aus optimalen Allokationen. Produkte, die oft verkauft wurden, erscheinen überrepräsentiert. Ein Beispiel: Wenn in der Vergangenheit Rentenversicherungen mit bestimmten Tarifmerkmalen dominierten, schlägt das Modell diese auch Kunden mit ganz anderen Risikoprofilen vor. Es fehlt die Korrektur durch das, was der Kunde eigentlich bräuchte.

Zweitens: fehlende Kontexttiefe. Die Lebenssituation eines Kunden ist kein Set von Merkmalen, sondern ein Narrativ. Ein 62-jähriger mit niedrigem Einkommen, aber geerbtem Immobilienvermögen benötigt eine andere Strategie als ein 62-jähriger mit hohem Einkommen und keinerlei Rücklagen. LLM-basierte Systeme erkennen solche Nuancen oft nicht, weil sie auf standardisierte Fragenkataloge trainiert sind. Die semantische Lücke zwischen „Risikobereitschaft" und „tatsächlicher Verlusttragfähigkeit" bleibt bestehen.

Drittens: Blackbox-Output. Der Algorithmus liefert eine Liste ohne transparente Begründung. Der Berater sieht „Produkt X passt zu 92 Prozent", aber nicht, warum. Das IDD-konforme Protokoll muss genau diese Begründung enthalten. Ohne Einsicht in die Entscheidungslogik ist jede nachträgliche Rechtfertigung schwierig. Die Ombudsstelle kann mit Standardargumenten wie „das System hat es so vorgeschlagen" nichts anfangen.

Kritische Frage an dieser Stelle: Wann wird eine algorithmische Abweichung vom Soll zur Pflichtverletzung? Nach deutschem und österreichischem Recht haftet der Berater für die Auswahl und Überwachung seiner Hilfsmittel. Stützt er sich blind auf ein System, dessen interne Logik er nicht versteht, und kommt es dadurch zu einer objektiv ungeeigneten Empfehlung, liegt eine Pflichtverletzung vor. Das Protokoll mag die Sorgfalt im Prozess abbilden. Wenn das Ergebnis jedoch gegen die Wohlverhaltenspflichten der IDD verstößt, nützt das nichts.

Typische Fallmuster aus der Ombudsstellen-Praxis

Zum besseren Verständnis lohnt der Blick auf wiederkehrende Konstellationen, die in den Jahresberichten der Ombudsstelle immer wieder auftauchen. Ich zeichne drei charakteristische Muster nach, anonymisiert und verallgemeinert, aber in der Struktur realitätsnah.

Fall A: Die falsche Rentenversicherung trotz korrekter Abfrage

Ein 55-jähriger Kunde mit konservativem Risikoprofil, Anlagehorizont 10 Jahre und Wunsch nach Kapitalerhalt. Der KI-Assistent verarbeitet sämtliche Angaben aus dem Fact-Find lückenlos. Das System schlägt eine fondsgebundene Rentenversicherung mit hohem Aktienanteil vor, Score 94 Prozent. Die Begründung im Protokoll: „Renditeerwartung deckt langfristigen Vorsorgebedarf". Der Berater übernimmt die Empfehlung ohne tieferes Hinterfragen. Nach einem Jahr deutliche Verluste. Der Kunde beschwert sich.

Das Problem: Der Algorithmus hatte Aktienprodukte höher gewichtet, weil er den langen Anlagehorizont als alleinigen Rechtfertigungsfaktor interpretierte. Die Risikoklasse des Kunden fand zwar Eingang in die Berechnung, wurde aber durch einen hohen Renditewunsch neutralisiert. Das System gewichtete aktivische Chancen stärker als passive Schutzziele. Formal hat der Berater alle Fragen gestellt und dokumentiert. Inhaltlich war das Produkt ungeeignet. Die Ombudsstelle gab dem Kunden recht. Das formale Protokoll schützte nicht.

Fall B: Fehlende Aktualisierung der Anlegerdaten

Ein Vermögensverwalter setzt ein KI-Modul ein, das quartalsweise Anpassungsvorschläge für Fondsdepots generiert. Grundlage sind die einmalig erhobenen Kundenprofile. Der Kunde, ein Selbstständiger, erlebte zwei Jahre später einen starken Einkommensrückgang durch Auftragswegfall. Der Berater aktualisierte die Angaben nicht. Das KI-System schlug weiterhin Produkte mit mittlerem Risiko und langen Haltefristen vor. Über mehrere Monate wurde mehrfach umgeschichtet, stets auf Basis des veralteten Profils. Der Kunde erlitt Verluste, weil er die Anlagen vorzeitig liquidieren musste.

Die Ombudsstelle sah eine grobe Pflichtverletzung. Zwar war die KI-Schnittstelle technisch tadellos dokumentiert, aber die unterbliebene Aktualisierung der Eingangsdaten machte jede nachfolgende Empfehlung hinfällig. Der Berater konnte sich nicht damit verteidigen, dass das System „funktionierte". Vielmehr war er verpflichtet, vor jeder Anpassungsrunde die Stammdaten zu überprüfen. Hier zeigt sich: Ein KI-gestützter Prozess entbindet nicht von der Pflicht, die Aktualität der Daten sicherzustellen. Wer das vernachlässigt, riskiert Schadensersatz und Reputationsverlust.

Fall C: Ignorierte gesetzliche Anlagegrenzen unter MiFID II

Ein unabhängiger Vermögensverwalter betreut einen Kunden mit strengen Anlagerichtlinien nach MiFID II, darunter eine Begrenzung des Anteils komplexer Produkte auf maximal 10 Prozent des Portfolios. Das KI-System generierte einen Anpassungsvorschlag mit einem Anteil von 18 Prozent zertifikateähnlichen Produkten. Der Berater gab die Order frei, ohne die Quote zu prüfen. Bei einer Routineprüfung fiel die Überschreitung auf. Der Fall landete nicht nur bei der Ombudsstelle, sondern auch bei der Aufsicht.

Das KI-Modul war mit Standardparametern trainiert, die kundenindividuelle Anlagegrenzen nicht kannten. Die Logik kannte Risikoklassen, aber keine produktspezifischen Quoten. Die Verantwortung für die Einhaltung gesetzlicher Grenzen lag beim Berater. Sich auf die KI zu verlassen, war hier keine Entlastung, sondern ein Organisationsverschulden. Die Ombudsstelle erkannte dies als schwerwiegenden Verstoß.

Alle drei Fälle zeigen: Der Algorithmus entscheidet nach statistischen Mustern, nicht nach rechtlichen und kundenindividuellen Vorgaben. Das Protokoll dokumentiert den Prozess, nicht die inhaltliche Richtigkeit.

IDD-Compliance und die Grenzen formaler Korrektheit

Die IDD verlangt eine Geeignetheitserklärung, die dem Kunden nachvollziehbar macht, warum eine bestimmte Empfehlung zu seinem Profil passt. Artikel 25 IDD nennt vier Prüfbereiche: Kenntnisse und Erfahrungen, finanzielle Verhältnisse, Anlageziele und Risikobereitschaft. Ein algorithmisches Protokoll kann diese Punkte zwar abhaken, aber nicht glaubhaft erläutern.

Die Rechtsprechung des BGH und österreichischer Höchstgerichte betont: Die Beratung muss anleger- und objektgerecht sein. Ein reines Abhaken von Kriterien genügt nicht. Der Berater muss das Produkt verstanden haben und die Eignung im Lichte der Gesamtsituation beurteilen. Diese Verpflichtung delegiert kein Algorithmus.

Was bedeutet das für KI-Protokolle? Ein automatisch generierter Report, der lediglich die Scoringwerte auflistet, reicht nicht. Die Ombudsstelle akzeptiert Protokolle nur dann, wenn daraus hervorgeht, dass eine menschliche Plausibilitätskontrolle stattgefunden hat und die Empfehlung fachlich begründet ist. Das Fehlen einer solchen Kontrolle ist ein Indiz für eine Pflichtverletzung.

Ein häufiger Irrglaube: Wenn die KI die gesamte IDD-Checkliste digital abarbeitet, ist der Berater haftungsentlastet. Dem ist nicht so. Die Ombudsstelle unterscheidet zwischen Verfahrensdokumentation und materieller Prüfung. Das automatisierte Protokoll bescheinigt nur, dass die Daten verarbeitet wurden. Ob das Ergebnis richtig war, prüft der Mensch. Wer diesen Schritt weglässt, haftet.

Handlungsempfehlungen: So machen Sie KI-Beratung ombudsstellenfest

Aus diesen Erkenntnissen lassen sich konkrete Maßnahmen ableiten, die über die bloße Einführung eines KI-Tools hinausgehen. Ich empfehle eine dreistufige Absicherung.

1. Inhaltliche Plausibilisierungspflicht einführen. Jede KI-generierte Empfehlung muss von einer Fachkraft auf drei Fragen geprüft werden: Passt das Risiko zum Kundenprofil? Sind alle aktuellen Daten berücksichtigt? Hält die Empfehlung regulatorische Grenzen ein? Das Ergebnis dieser Prüfung ist zu dokumentieren, inklusive Abweichungsbegründung. Nur so entsteht eine nachvollziehbare Akte, die vor der Ombudsstelle standhält.

2. Human-in-the-Loop mit fachlicher Begründungspflicht. Nicht der Algorithmus trifft die Entscheidung, sondern der Berater. Jeder KI-Vorschlag ist ein Entwurf, der final freigegeben wird. Die Freigabe muss schriftlich begründet sein. Formulierungen wie „laut System passend" genügen nicht. Stattdessen: „Produkt X erfüllt das Risikoprofil, weil die Aktienquote unter 30 Prozent liegt und der Anlagehorizont übereinstimmt." Ohne solche Sätze bleibt das Protokoll formal, aber substanzlos.

3. Regelmäßige Systemaudits durchführen. KI-Modelle sind keine statischen Werkzeuge. Sie müssen anhand realer Fälle getestet werden: Würde das System bei geänderten Kundendaten noch korrekt empfehlen? Welche Biases zeigen sich? Solche Audits sind nicht nur auf technischer Ebene nötig, sondern auch Teil der Compliance-Organisation. Ich empfehle, einmal pro Quartal eine Stichprobe von zehn Kundenfällen manuell durchzurechnen und mit den KI-Vorschlägen zu vergleichen. Abweichungen dokumentieren und auswerten.

4. Neue Regulierung vorbereiten. Der EU AI Act stuft KI-Anwendungen in der Finanzberatung als Hochrisikosysteme ein. Ab 2026 gelten Pflichten zur Risikobewertung, menschlichen Aufsicht und Transparenz. Die neue Produkthaftungsrichtlinie erweitert den Haftungsbegriff und kann Hersteller und Betreiber gleichermaßen treffen. Berater sollten sich jetzt mit den Entwürfen vertraut machen und ihre Verträge mit KI-Anbietern prüfen, insbesondere Haftungsklauseln im Schadensfall.

5. Kundenkommunikation anpassen. Erklären Sie dem Kunden, wie die KI eingesetzt wird und wo die menschliche Letztentscheidung liegt. Das schafft Vertrauen und dokumentiert die Arbeitsteilung. Im Beschwerdefall können Sie nachweisen, dass die KI nur assistiert hat und Sie die inhaltliche Verantwortung tragen. Verstecken Sie die KI nicht, sondern machen Sie sie zum kontrollierten Instrument.

Fazit: Der Algorithmus entlastet, aber enthaftet nicht

KI-gestützte Geeignetheitsprüfung kann die Arbeit von Honorarberatern und Vermögensverwaltern effizienter machen. Sie beschleunigt das Matching, reduziert Routinefehler und schafft eine standardisierte Dokumentation. Aber sie gibt keine Garantie für materielle Richtigkeit. Die Ombudsstelle prüft den Einzelfall, nicht die Prozessarchitektur. Und sie prüft den Inhalt, nicht nur das Protokoll.

Wer meint, mit einem KI-Beratungsprotokoll sei er auf der sicheren Seite, irrt. Das Gegenteil ist der Fall: Die schiere Existenz eines formal korrekten Protokolls kann die Aufmerksamkeit des Prüfers erst recht auf die Frage lenken, ob die Substanz dahinter stimmt. Fehlt diese Substanz, wird aus dem vermeintlichen Schutzschild ein Belastungsdokument.

Die Kernbotschaft ist einfach: Verantwortung bleibt beim Menschen. Wer KI einsetzt, muss die Kontrollpflichten verdoppeln, nicht halbieren. Die drei Fallbeispiele zeigen, dass selbst ausgereifte Systeme systematische Schwächen haben. Es ist Ihre Aufgabe, diese zu kennen und zu korrigieren. Nur dann wird aus einem Risiko ein echter Produktivitätsgewinn.

Jetzt ist die Zeit, Ihre Prozesse umzustellen und den Human-in-the-Loop nicht als lästige Pflicht, sondern als haftungsrechtliche Notwendigkeit zu verankern. Die Ombudsstelle wartet nicht. Die nächste Beschwerde ist vielleicht schon unterwegs.