Warum KI-Agenten Kostenquoten ignorieren und wie Sie Produkte filtern

Das Problem: Warum LLMs Kostenquoten im Fließtext übersehen

Fondsgebundene Lebensversicherungen kranken an einer unbequemen Wahrheit: Die Kostenquote entscheidet über Jahrzehnte stärker über die Ablaufleistung als die Fondsauswahl. Die Effektivkostenquote bündelt Abschluss-, Verwaltungs- und Fondskosten in einem Prozentwert. Sie ist die wichtigste Kennzahl für den Kostenvergleich. Genau diese Kennzahl verschwindet im Text. Ein Unterschied von 1,4 Prozentpunkten Effektivkosten pro Jahr kann bei 200 Euro Monatsbeitrag und 30 Jahren Laufzeit einen Betrag im hohen fünfstelligen Bereich ausmachen. Trotzdem passiert in vielen KI-gestützten Beratungsprototypen genau das Gegenteil. Der Agent vergleicht Fondslisten, Garantiebausteine und Anbieterbonität. Die Kostenquote bleibt ein blinder Fleck.

Der Grund ist kein Softwarefehler im klassischen Sinn. Er liegt in der Art, wie Large Language Models Text verarbeiten. Ein LLM liest nicht wie ein Analyst, der Werte aus einer Tabelle zieht und in Relation setzt. Er zerlegt Text in Token. „0,89 %" und „0,89 Prozent p.a." sind für das Modell unterschiedliche Tokensequenzen. „Laufende Kosten" und „laufende Kosten des Fondsvermögens" sind ebenfalls nicht automatisch identisch. Genau diese Variationen finden sich in Basisinformationsblättern, Produktinformationsblättern und Versicherungsbedingungen laufend.

Dazu kommt die Verteilung der Kostenarten. Die Effektivkosten stehen oft im Fließtext des Basisinformationsblatts. Die Abschlusskosten finden sich im Abschnitt „Kosten bei Vertragsabschluss". Die laufenden Fondskosten, also die TER, sind im Anhang zur Fondsliste versteckt. Die Verwaltungskosten sind in Euro oder Prozent angegeben, je nach Tarifgeneration. Ein LLM, das frei über einem Produktstapel arbeitet, verliert dabei den Überblick. Es gewichtet die Textstellen nicht nach ihrer finanziellen Auswirkung, sondern nach ihrer sprachlichen Präsenz.

Die Folge ist ein häufiges Muster: Der Agent empfiehlt ein Produkt, weil die Fondsauswahl überzeugt oder der Anbieter bekannt ist. Die Kostenquote taucht in der Erklärung zwar auf, wird aber nicht als Entscheidungsgröße verwendet. Aus meiner Sicht ist das kein harmloser Schönheitsfehler. Für einen Honorarberater, der nach Geeignetheit dokumentiert, ist eine Empfehlung ohne belastbaren Kostenvergleich ein Haftungsrisiko. Und für den Kunden ist es ein Renditeverlust, der sich erst nach 20 Jahren zeigt.

Der Lösungsansatz: Kostenquote als strukturierter Produktfilter

Der Ausweg ist eine Architektur, die dem LLM genau eine Aufgabe gibt: Kostenbestandteile aus Dokumenten extrahieren und in ein festes Schema schreiben. Den Vergleich übernimmt danach deterministischer Code. Diese Zweiteilung verhindert, dass das Sprachmodell selbst entscheidet, was teuer und was günstig ist.

Konkret definieren Sie für jede fondsgebundene Lebensversicherung ein Schema mit Pflichtfeldern. Dazu gehören mindestens:

• Effektivkosten in Prozent pro Jahr
• Laufende Fondskosten, also TER, in Prozent pro Jahr
• Abschlusskosten in Euro oder Prozent der Beitragssumme
• Verwaltungskosten in Euro oder Prozent
• Bezugsgröße, etwa Beitrag, Vertragsguthaben oder Fondsvolumen
• Stand des Dokuments mit Datum, Version und Anbieter

Das LLM bekommt den Auftrag, diese Felder aus dem Dokument zu füllen. Es liefert die Zahlen, keine Bewertung. Der Filter danach ist eine Codekomponente, die harte Schwellenwerte anwendet. Ein Beispiel: Produkte mit Effektivkosten über 2,0 Prozent pro Jahr scheiden aus. Produkte mit einer TER über 1,5 Prozent erhalten einen Malus. Die Rangfolge entsteht aus einer Formel, nicht aus einem Prompt.

Diese Trennung hat einen praktischen Grund: LLMs können mit Anweisungen wie „Vergleiche die Kostenquoten" nicht zuverlässig umgehen. Sie rechnen nicht im herkömmlichen Sinn, sie erzeugen Text. Wenn Sie im Prompt eine Rangfolge verlangen, liefert das Modell eine sprachlich plausible Antwort, die numerisch falsch sein kann. Wenn der Code die Rangfolge bildet, ist jeder Schritt nachvollziehbar und reproduzierbar.

Ein typisches Beispiel: Ein Honorarberater vergleicht 12 fondsgebundene Tarife. In der ersten Stufe extrahiert das LLM aus jedem Produktinformationsblatt die Kostenfelder. In der zweiten Stufe sortiert der Code die Tarife nach einem gewichteten Kostenscore. Der Berater sieht auf einen Blick, welche Produkte wegen hoher Abschlusskosten ausscheiden, bevor er Fondsqualität oder Garantien prüft. Das LLM schreibt in diesem Prozess keine Empfehlung. Es füllt eine strukturierte Tabelle.

Extraktion validieren: gegen Halluzinationen bei Versicherungszahlen

Zahlen sind für LLMs ein klassisches Halluzinationsrisiko. Eine Zahl wie „1,2 %" kann im Kontext korrekt sein, aber auch frei erfunden. Das Problem verschärft sich bei Versicherungsunterlagen, weil dort mehrere Kostenarten mit ähnlichen Namen vorkommen. Ohne Validierung bauen Sie den Produktfilter auf Sand.

Die wichtigste Regel lautet: Jede extrahierte Zahl braucht einen Quellenbeleg. Seite und Abschnitt, idealerweise der Originaltext als Zitat. Wenn das Modell diesen Beleg nicht liefern kann, wird das Produkt nicht bewertet. Das klingt hart, schützt aber vor stillen Fehlern. Ein Produkt mit fehlendem Beleg landet auf einer Review-Liste, nicht im Vergleich.

Dazu kommen Plausibilitätsregeln, die deterministisch prüfen. Ein Beispiel: Effektivkosten können nicht niedriger sein als die laufenden Fondskosten. Die Summe aus Verwaltungskosten und Fondskosten kann nicht über den Effektivkosten liegen, wenn diese als Gesamtkostenquote definiert sind. Der Dokumentenstand muss zur aktuellen Tarifgeneration passen. Solche Checks sind einfach zu coden und verhindern grobe Ausreißer.

Für die Qualitätssicherung empfehle ich ein Golden-Set aus echten Produktinformationsblättern. Das sind 20 bis 30 Dokumente, bei denen Sie die korrekten Kostenwerte manuell erfasst haben. Jede Änderung am Schema, am Prompt oder am Modell wird gegen dieses Set getestet. Sinkt die Extraktionsgenauigkeit unter einen definierten Schwellenwert, geht der Agent nicht in Produktion. Ein praxistauglicher Schwellenwert ist 95 Prozent korrekt extrahierte Pflichtfelder auf dem Golden-Set. Dazu kommen Stichproben-Reviews durch einen Fachmenschen, mindestens bei jedem neuen Anbieter oder Tarifwerk.

Die in der Diskussion genannten 52 Prozent falsche Fakten in der KI-Finanzberatung sind kein Grund, LLMs in der Beratung zu verbieten. Sie sind aber ein Grund, keinem einzigen unvalidierten Output zu vertrauen. Bei Kostenquoten ist die Validierung vergleichsweise einfach, weil die richtige Zahl im Dokument steht. Sie brauchen kein probabilistisches Modell, um eine Zahl zu beurteilen, sondern einen Abgleich mit der Quelle. Wer den Abgleich weglässt, übernimmt Halluzinationen als Beratungsgrundlage.

Vom Prototyp zum Berater-Workflow (DACH-Kontext)

Für Honorarberater in Deutschland, Österreich und der Schweiz ist die technische Architektur nur die halbe Arbeit. Die zweite Hälfte ist der Einbau in einen rechtskonformen Beratungsprozess.

Der typische Workflow sieht in der Zielversion so aus:

1. Produktuniversum definieren: Der Berater legt fest, welche Tarife in die Vorauswahl kommen.
2. Kostenextraktion starten: Der Agent zieht die Kostenfelder aus den aktuellen Produktinformationsblättern.
3. Hartes Filtern: Der Code wendet die definierten Schwellenwerte an und erstellt eine Rangliste.
4. Fachliche Prüfung: Der Berater bewertet die verbleibenden Produkte mit Fokus auf Fondsqualität, Garantien und Kundenziele.
5. Beratungsdokumentation: Jede Empfehlung wird mit Produkt, Kosten, Quelle und Entscheidungslogik belegt.

Wichtig ist die Erwartungshaltung: Der KI-Agent ersetzt den Tarifvergleich nicht. Er beschleunigt die Vorauswahl, die sonst mehrere Stunden dauert. Ein klassischer Vergleich über 15 Tarife mit händischer Kostenextraktion kostet leicht einen halben Tag. Der Agent reduziert das auf Minuten. Die finale Empfehlung bleibt beim Menschen, weil Geeignetheit nicht allein von der Kostenquote abhängt. Fondsqualität, Garantieumfang, Flexibilität und steuerliche Rahmenbedingungen fließen weiter in die Entscheidung ein.

Datenschutz und Nachweispflichten sind im DACH-Raum kein Nebenschauplatz. Wenn Sie Produktunterlagen durch ein Sprachmodell schicken, sollten Sie klären, wo die Verarbeitung stattfindet. Für sensible Kundendaten gilt ohnehin eine restriktive Linie. Produktinformationsblätter sind nicht unbedingt personenbezogen. Sobald sie in die Beratung eines konkreten Kunden einfließen, ändert sich der Kontext. Der Agent sollte deshalb protokollieren: welches Dokument, welche Version, welcher Extraktionsstand, welches Modell, welcher Prompt, welches Ergebnis. Diese Art von Audit-Trail ist die Basis, um im Streitfall zu zeigen, warum ein Produkt in die Vorauswahl kam und ein anderes nicht. Für Honorarberater, die nach IDD dokumentieren, ist dieser Nachweis kein Nice-to-have, sondern Teil der Geeignetheitsprüfung.

Checkliste: 7 Fragen, bevor Ihr Agent Produkte filtern darf

Bevor Sie einen solchen Agenten in der Praxis einsetzen, prüfen Sie sieben Punkte. Fehlt einer davon, bleibt die Anwendung ein Prototyp.

1. Sind Kostenfelder als strukturierte Pflichtfelder definiert? Das LLM darf nicht frei formulieren. Es braucht ein festes Schema mit Effektivkosten, TER, Abschlusskosten, Verwaltungskosten, Bezugsgröße und Dokumentenstand.

2. Gibt es einen Quellenbeleg pro Zahl? Jede extrahierte Zahl muss mit Seite, Abschnitt oder Originalzitat belegbar sein. Ohne Beleg keine Bewertung.

3. Entscheidet Code oder LLM über den Filter? Die Schwellenwerte und die Rangfolge müssen im Code liegen. Das LLM liefert nur die Daten. Das ist der wichtigste Punkt gegen numerische Halluzinationen.

4. Sind Plausibilitätsregeln und Golden-Set-Tests vorhanden? Effektivkosten größer TER, Summenchecks, Dokumentenstand aktuell. Dazu regelmäßige Regressionstests gegen manuell geprüfte Daten.

5. Ist der Dokumentenstand Teil jedes Vergleichs? Ein Produkt aus einem veralteten Produktinformationsblatt darf nicht gegen einen aktuellen Tarif antreten. Der Stand gehört in jedes Extraktionsschema.

6. Wird jede Empfehlung mit Produkt und Kosten belegt? Die Beratungsdokumentation muss nachvollziehbar machen, warum ein Produkt in die engere Wahl kam. Eine Kostenquote allein reicht nicht, aber ohne Kostenbeleg ist die Geeignetheitsprüfung unvollständig.

7. Ist der menschliche Berater in der finalen Freigabe? Der Agent darf filtern, nicht entscheiden. Die finale Produktempfehlung bleibt beim Honorarberater, der die Kundenziele, Risikopräferenzen und steuerlichen Aspekte einordnet.

Diese sieben Punkte sind keine Anforderungen an einen perfekten Robo-Advisor. Sie sind die Mindestvoraussetzungen dafür, dass ein LLM-basierter Produktfilter in der Finanzberatung mehr Nutzen als Risiko bringt. Wer sie umsetzt, hat einen Werkzeugvorteil: Die Kostenquote wird vom blinden Fleck zur strukturierten Entscheidungsgröße. Und genau daran entscheidet sich, ob ein Agent in der fondsgebundenen Lebensversicherung belastbar ist oder nur gut klingt.