Methodologie: Decision Governance für CFP®-Berater
Wie Steerable Beratungsentscheidungen strukturiert, ohne sie zu bewerten — und warum diese Trennung die einzige tragfähige Antwort auf KI-Abundanz in der Finanzberatung ist.
Was ist Decision Governance in der Finanzberatung?
Decision Governance ist die strukturierte, prüfbare Dokumentation, wer in einer Beratung was auf welcher Grundlage entschieden hat — getrennt von der Frage, ob die Entscheidung gut war.
In der klassischen Compliance-Welt prüft eine Aufsichtsfunktion im Nachhinein, ob eine Empfehlung geeignet war. Decision Governance setzt früher an: Sie hält während der Beratung fest, welche Autorenschaft jedem Element der Empfehlung zugrunde liegt — der Mandant, der Berater, ein KI-Modell, ein externes Datenfeed, oder eine Kombination. Die Frage verschiebt sich von „war das richtig?" zu „wer hat was entschieden, und mit welchem Begründungsmuster?"
MiFID II bindet die Eignungsprüfung an die Begründungstiefe, nicht an das Ergebnis. Ein Berater muss zeigen können, dass er das Risikoprofil, die Kenntnisse und die Ziele des Mandanten verstanden und in eine kohärente Empfehlung übersetzt hat. Steerable trennt diesen Begründungspfad strukturell vom Inhalt der Empfehlung. Die normative Autorität bleibt beim Berater. Die Provenienz wird maschinell prüfbar.
„Bei der Erbringung von Anlageberatung oder Portfoliomanagement holt die Wertpapierfirma die erforderlichen Informationen ein über die Kenntnisse und Erfahrungen des Kunden, seine finanzielle Lage einschließlich seiner Fähigkeit, Verluste zu tragen, und seine Anlageziele einschließlich seiner Risikotoleranz [...]."
Was ist Ghost Ownership und warum entsteht es?
Ghost Ownership ist die Zurechnungslücke, die entsteht, wenn ein KI-System eine Beratungssitzung mitformt, der Audit Trail aber nicht mehr sauber zeigt, wer welchen Teil der Entscheidungslogik verantwortet.
Der Berater unterschreibt am Ende der Sitzung. Doch wenn Modellvorschläge, Recherchezusammenfassungen und Risikoabschätzungen aus KI-Werkzeugen stammen, bleibt offen, ob der Berater diese Inhalte aktiv geprüft, modifiziert oder lediglich übernommen hat. Die Unterschrift ist ein juristischer Akt — ohne forensische Substanz. Wenn ein Mandant zwei Jahre später Beschwerde einlegt, fragt der Ombudsmann nicht nach der Empfehlung — er fragt nach dem Begründungspfad.
Ghost Ownership ist deshalb kein technisches Problem, sondern ein Dokumentationsproblem. Die Logs der KI-Anbieter enthalten Prompts und Responses, jedoch keine Information darüber, welche Teile in die finale Beratung eingeflossen sind. Steerable zeichnet jedes übernommene KI-Element explizit aus und verlangt eine Beratereinstufung: akzeptiert, modifiziert, verworfen mit Begründung. So entsteht ein Artefakt, das die Lücke schließt.
Begriff: Ghost Ownership
Ghost Ownership ist die Attributionslücke, die entsteht, wenn KI-Systeme eine Beratungssitzung mitformen und der Audit Trail nicht mehr sauber beantworten kann, wer welchen Teil der Entscheidungslogik autorisiert hat. Der Berater bleibt rechtlich verantwortlich, jedoch ohne forensische Substanz.
Was ist ein Decision Packet?
Ein Decision Packet ist ein append-only Artefakt mit über 30 strukturierten Feldern, das dokumentiert, was entschieden wurde, von wem, auf welcher Grundlage und welche Alternativen verworfen wurden.
Das Packet ist das forensische Output einer Steerable-Sitzung. Es enthält vier Schichten: eine Provenienz-Schicht (Datenquellen, Zeitstempel, Tool-Versionen, externe API-Calls), eine Autorenschafts-Klassifikation pro Empfehlungselement, eine Liste verworfener Alternativen mit Beraterbegründung und einen auditfähigen Export in maschinen- und menschenlesbarer Form.
Weil das Format append-only ist, kann es nicht rückwirkend manipuliert werden. Jede spätere Korrektur erzeugt einen neuen Eintrag mit Verweis auf den ursprünglichen Stand. Somit erfüllt das Packet die Unveränderbarkeitsanforderung, die der BaFin-Aufsicht und der MiFID II-Aufbewahrungspflicht zugrunde liegt — und zwar nicht durch nachträgliche Versiegelung, sondern durch das Datenmodell selbst.
Begriff: Decision Packet
Decision Packet ist ein strukturiertes, append-only Artefakt einer Steerable-Sitzung, das Provenienz, Autorenschafts-Klassifikation, verworfene Alternativen mit Begründung und einen auditfähigen Export enthält. Es ist das forensische Gegenstück zur Beraterunterschrift.
Warum ist Non-Normativität die zentrale Designentscheidung?
Sobald ein System empfiehlt, evaluiert oder nudged, übernimmt es einen Teil der normativen Autorität — und genau diese Übernahme erzeugt Ghost Ownership.
Robo-Advisor lösen das Problem, indem sie die normative Autorität vollständig übernehmen und den Berater rauskürzen. Klassische CRM- und Compliance-Tools lösen es nicht, weil sie nachträglich dokumentieren. Steerable wählt einen dritten Weg: Es strukturiert den Entscheidungsraum, ohne ihn zu bewerten. Diese Selbstbeschränkung ist kein Verzicht auf Wertschöpfung — sie ist der Mechanismus, der die Beraterautorität verteidigt.
Die Konsequenz für das Design ist hart: Steerable enthält keine Scoring-Funktion, keine Empfehlungslogik, keine „Best Practice"-Vorlagen, die einen normativen Sog erzeugen würden. Es extrahiert Pillar Nodes aus dem Mandantengespräch, visualisiert deren Gewichtung und ermöglicht What-If-Simulationen mit Ripple Effects — jedoch ohne jeden Hinweis, welche Konfiguration „richtig" wäre. Der Berater bleibt die einzige Quelle normativer Aussagen.
„Steerable strukturiert, niemals empfiehlt. Diese Selbstbeschränkung ist nicht das, was Steerable nicht kann — sie ist das, was Steerable überhaupt erst möglich macht."
Begriff: Non-Normativität
Non-Normativität ist das Designprinzip, nach dem Steerable Entscheidungen weder bewertet, empfiehlt noch nudged. Es strukturiert den Entscheidungsraum, lässt jedoch die normative Autorität vollständig beim Berater. Dadurch entsteht keine geteilte Verantwortung und kein Ghost Ownership.
Wie unterstützt Steerable die MiFID II-Konformität bei KI-Einsatz?
Steerable erzeugt für jede Sitzung ein Suitability-Statement nach MiFID II Artikel 25(2) mit vollständiger Provenienz aller Inputs, inklusive AI-Tool-Versionen, externer Datenquellen und Beraterbegründung — exportfähig in jedes Archivsystem.
MiFID II verlangt von Wertpapierfirmen, dass sie die Eignung einer Empfehlung dokumentieren und diese Dokumentation zehn Jahre aufbewahren. Sobald KI-Werkzeuge in den Beratungsprozess eingebunden werden, dehnt sich die Dokumentationspflicht implizit aus: Auch die KI-Beiträge müssen rekonstruierbar sein, weil der Berater dafür einsteht. Die ESMA hat dies in mehreren Q&A-Veröffentlichungen klargestellt.
Praktisch bedeutet das: Wenn ein Berater 2025 einen Ruhestandsplan mit KI-Unterstützung erstellt und der Mandant 2034 eine Beschwerde einreicht, muss die ursprüngliche KI-Output-Version reproduzierbar sein. Modelle ändern sich jedoch laufend. Deshalb speichert Steerable nicht den KI-Output selbst, sondern die Anker-Daten: Modell-Identifier, Prompt-Hash, Response-Hash und Beratereinstufung. Daher kann die Sitzung auch ohne Originalmodell rekonstruiert werden — was sie auditierbar im juristischen Sinne macht.
„Beim Einsatz von KI-Systemen in der Anlageberatung müssen Institute insbesondere sicherstellen, dass die Nachvollziehbarkeit der Beratungsentscheidung gewährleistet bleibt und der Berater die volle Verantwortung trägt."
Wie verhält sich Steerable zum EU AI Act?
Der EU AI Act stuft KI-gestützte Finanzberatung als Hochrisiko-Anwendung ein und verlangt Transparenz, Nachverfolgbarkeit und menschliche Aufsicht — Steerable ist die operative Dokumentationsschicht, die diese Anforderungen pro Sitzung umsetzbar macht.
Die Verordnung (EU) 2024/1689 (EU AI Act) verlangt für Hochrisiko-Systeme unter anderem ein Risikomanagement, technische Dokumentation, Datenqualitätsanforderungen, menschliche Aufsicht und Protokollierung. Im Beratungskontext bedeutet Artikel 14 (Human Oversight), dass die letztliche Entscheidung beim Menschen liegen muss — und dass diese menschliche Aufsicht nachweisbar sein muss. Allerdings sagt der Act nicht, wie dieser Nachweis geführt wird.
Steerable schließt diese Lücke pro Sitzung. Das Decision Packet enthält für jeden KI-generierten Vorschlag eine explizite menschliche Beratereinstufung, einen Zeitstempel und eine Begründung. Menschliche Aufsicht ist dann kein pauschaler Compliance-Satz, sondern ein granulares Event-Log auf Empfehlungselement-Ebene. Ohne diese Granularität bleibt „Human Oversight" eine juristische Behauptung ohne forensische Substanz.
„Hochrisiko-KI-Systeme werden so konzipiert und entwickelt, dass sie [...] von natürlichen Personen während des Zeitraums ihrer Verwendung wirksam beaufsichtigt werden können. Die Aufsichtsmaßnahmen müssen den Risiken, der Autonomie und dem Einsatzkontext angemessen sein."
Begriff: Decision Provenance
Decision Provenance ist die dokumentierte Kette aller Inputs (Mandantendaten, externe Daten, KI-Modellversion, Beraterurteil), die zu einer konkreten Empfehlung geführt haben. Sie ist nach MiFID II und EU AI Act erforderlich, sobald KI-Werkzeuge im Beratungsprozess eingesetzt werden.
Was ist das Inverse Governance Paradox?
Je zuverlässiger KI in der Beratung wird, desto seltener überstimmt der Berater sie — und desto weniger bleibt zu dokumentieren. Die Haftung sinkt jedoch nicht, weshalb bessere KI das Governance-Risiko erhöht, statt es zu senken.
Dieser Effekt ist kontraintuitiv. Intuitiv erwartet man, dass verlässlichere Werkzeuge weniger Aufsicht benötigen. Im Beratungskontext gilt jedoch das Gegenteil: Wenn ein KI-Modell in 95 % der Fälle eine plausible Empfehlung liefert, sinkt die Schwelle, an der der Berater eingreift. Das Protokoll schrumpft der Override-Entscheidungen — also genau jener Datenpunkte, die in einem Streitfall die Berateurteilskraft belegen würden.
Allerdings bleibt die Haftung unverändert: Der Berater unterschreibt, der Berater haftet. Wenn der Audit Trail jedoch nur noch zeigt „KI-Vorschlag akzeptiert" ohne jede Modifikation, dann fehlt die forensische Substanz der menschlichen Aufsicht. Im Gegensatz zur intuitiven Erwartung ist daher eine zuverlässigere KI ein höheres Governance-Risiko. Steerable adressiert dies, indem es auch Akzeptanz ohne Modifikation als aktiven Akt dokumentiert — mit Beratereinstufung und optionaler Kurzbegründung.
„Bessere KI macht den Berater nicht zuverlässiger. Sie macht ihn nur stiller. Und Stille ist in einem Audit kein guter Zeuge."
Begriff: Inverse Governance Paradox
Inverse Governance Paradox beschreibt den Effekt, dass mit steigender KI-Zuverlässigkeit das Override-Verhalten des Beraters abnimmt, das Dokumentationsvolumen damit schrumpft, die Compliance-Haftung jedoch konstant bleibt. Bessere KI erzeugt somit höheres, nicht niedrigeres Governance-Risiko.
Was ist das SR7D-Framework?
SR7D ist die theoretische Grundlage von Steerable: sieben architektonische Patterns und drei ethische Leitplanken, die konsequente Entscheidungen in KI-reichen Umgebungen sichtbar, nachvollziehbar, anfechtbar und verbesserbar machen.
Die sieben Patterns adressieren wiederkehrende Strukturprobleme: Provenienz-Verlust, Autorenschafts-Verwischung, Override-Verarmung, Modell-Drift, Begründungsasymmetrie, Verworfene-Alternativen-Amnesie und Auditierbarkeitsverlust. Jedes Pattern ist als architektonische Lösung formuliert, nicht als Best Practice. Sie sind technologie-agnostisch und überleben einzelne Modellgenerationen.
Die drei Leitplanken — strikte Non-Normativität, Append-only-Provenienz und granulare menschliche Aufsicht — verhindern, dass die Patterns durch Implementierungskompromisse aufgeweicht werden. SR7D ist weniger eine Checkliste als ein Bauplan, der für jede beratungsorientierte KI-Integration einzeln angewandt werden muss. Die vollständige Spezifikation findet sich im Steerable Whitepaper.
Begriff: SR7D Framework
SR7D Framework ist die formale Spezifikation von sieben architektonischen Patterns und drei ethischen Leitplanken, die in KI-reichen Beratungsumgebungen Entscheidungen sichtbar, nachvollziehbar, anfechtbar und verbesserbar machen. Es ist die theoretische Grundlage hinter Steerable.
Wie sieht eine Steerable-Sitzung methodisch aus?
Eine Sitzung dauert typischerweise 30 Minuten und besteht aus vier Phasen: Pillar-Extraktion aus dem Mandantengespräch, Gewichtung auf gemeinsamem Canvas, What-If-Simulation mit Ripple Effects, Export des Decision Packets.
In Phase 1 (Extraktion) spricht der Mandant. Das System extrahiert Pillar Nodes — die zentralen Themen, die in der Beratung eine Rolle spielen. Empirisch erscheinen pro Sitzung etwa 25 bis 30 Themen, von denen typischerweise drei bis vier entscheidungstragend sind. Diese Quote ist konsistent über bisherige Pilotsitzungen mit Certified Financial Planners in Deutschland und Österreich.
In Phase 2 (Gewichtung) übersetzt der Berater die Pillars in einen Knoten-Graph auf einem geteilten Canvas — sichtbar für Berater und Mandant. Der Mandant sieht, welche Themen welches Gewicht bekommen, und kann widersprechen. So entsteht eine doppelte Authentifizierung der Prioritätenstruktur, bevor irgendeine Empfehlung formuliert wird.
In Phase 3 (Simulation) kann der Berater What-If-Szenarien durchspielen. Wenn der Mandant ein Pillar verändert (z.B. erhöhte Liquiditätsanforderung), zeigt der Ripple Effect, welche anderen Pillars sich strukturell mitverändern. Allerdings macht das System auch hier keine Aussage darüber, ob die neue Struktur besser oder schlechter ist — es zeigt nur die strukturellen Folgen.
In Phase 4 (Export) wird das Decision Packet generiert: über 30 Felder, vier Schichten, kryptografische Versiegelung. Der Export erfolgt in maschinenlesbarem Format (JSON-LD mit Schema.org-Annotationen) und als menschenlesbares PDF für die Mandantenakte. So erfüllt eine einzige Sitzung sowohl die Dokumentationspflicht nach MiFID II als auch die Transparenzanforderungen nach EU AI Act.
Welche externen Standards stützen die Methodologie?
Steerable referenziert vier externe Standardrahmen: MiFID II, EU AI Act, ISO 31000 (Risikomanagement) und DIN 77230 (Basis-Finanzanalyse für Privathaushalte) — keiner davon wird kopiert, jeder strukturell integriert.
Die ISO 31000 liefert die Grammatik für Risikomanagement: Identifikation, Analyse, Bewertung, Behandlung, Überwachung. Steerable nutzt diese Grammatik in der Pillar-Klassifikation, ohne die ISO-spezifische Bewertungsskala zu übernehmen — denn jede normative Skala würde gegen das Non-Normativitätsprinzip verstoßen.
Die DIN 77230 (Basis-Finanzanalyse für Privathaushalte) gibt eine Themenstruktur vor, die als Default-Inventar für Pillar-Kategorien dient. Allerdings ist sie nur ein Vorschlag — der Berater kann jede Kategorie überschreiben oder ergänzen, und die Überschreibung wird im Decision Packet protokolliert. Im Gegensatz zu einem starren Templatesystem bleibt damit die Beraterautonomie erhalten.
Die CFP-Standards des Financial Planning Standards Board liefern die Berufsethik, an die sich Steerable in der Designsprache anlehnt: Treuepflicht, Sorgfaltspflicht, Vertraulichkeit, Kompetenz. Steerable ist damit nicht nur technisch, sondern auch berufsethisch in das CFP®-Berufsbild eingebettet.
Begriff: Pillar Node
Pillar Node ist ein im Steerable-Graph repräsentiertes Beratungsthema, das aus dem Mandantengespräch extrahiert und gewichtet wird. Jeder Pillar Node trägt Provenienz-Metadaten (Quelle: Mandant, Berater, KI, Datenfeed) und ist Ausgangspunkt für Ripple-Simulationen.
Begriff: Ripple Effect
Ripple Effect bezeichnet die strukturelle Mitveränderung benachbarter Pillar Nodes im Graph, wenn ein einzelner Pillar modifiziert wird. Das System zeigt Folgen, jedoch ohne Bewertung — die normative Einordnung bleibt beim Berater.
Wovon grenzt sich Steerable ab?
Steerable ist kein Robo-Advisor, kein CRM, kein Compliance-Prüfungstool und kein normatives System — vier Abgrenzungen, die zusammen die Designentscheidung erst sichtbar machen.
Robo-Advisor automatisieren die Empfehlung. Sie übernehmen die normative Autorität vollständig und reduzieren den Berater auf eine Schnittstelle. Im Gegensatz dazu lässt Steerable die Empfehlung beim Berater und automatisiert ausschließlich die Dokumentation. CRM-Systeme verwalten Mandantenbeziehungen, jedoch keine Entscheidungsprovenienz; sie wissen dass ein Gespräch stattfand, aber nicht, was entschieden wurde. Compliance-Prüfungstools wiederum bewerten im Nachhinein, ob eine Empfehlung MiFID II-konform war — sie produzieren keine während der Sitzung verwertbaren Strukturen.
Diese Abgrenzungen sind nicht akademisch. Jede Verwischung würde Ghost Ownership zurückbringen: Sobald Steerable beginnen würde, „suboptimal" zu kennzeichnen, würde das System normative Autorität ausüben und die Beraterzurechnung würde verwässern. Daher ist Selbstbeschränkung kein Verzicht, sondern das eigentliche Sicherheitsmerkmal des Designs.
Weiterführende Quellen
Die folgenden externen Quellen werden in dieser Methodologie referenziert und bilden die regulatorische, akademische und berufsethische Grundlage von Steerable.
- Europäische Union (2024). Verordnung (EU) 2024/1689 über künstliche Intelligenz (EU AI Act). Amtsblatt der EU. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Europäische Union (2014). Richtlinie 2014/65/EU (MiFID II), Artikel 25 — Eignungsprüfung. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32014L0065
- Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin). Aufsicht und KI in der Anlageberatung. https://www.bafin.de/EN/verbraucherinnen-verbraucher/themen-finanzprodukte/finanzbetrug-erkennen/anlagebetrug/marktmanipulation/marktmanipulation_node_en.html
- European Securities and Markets Authority (ESMA). Guidelines on certain aspects of the MiFID II suitability requirements. https://www.esma.europa.eu
- Financial Planning Standards Board (FPSB). Global Standards for CFP® Professionals. https://www.fpsb.org/
- Deutsches Institut für Normung (DIN). DIN 77230: Basis-Finanzanalyse für Privathaushalte. https://din.de/
- International Organization for Standardization (ISO). ISO 31000: Risk management — Guidelines. https://www.iso.org/standard/65694.html
- Bracker, L. (2026). Reliable AI Doesn't Save the Advisor. Steerable Research. https://steerable.org/research/reliable-ai-doesnt-save-the-advisor
- Bracker, L. (2026). Ghost Ownership in der Finanzberatung. Steerable Research. https://steerable.org/research/ghost-ownership
// Stand 2026-05-27 — Diese Methodologie-Seite wird laufend aktualisiert. Die kanonische Spezifikation des SR7D-Frameworks ist im Steerable Whitepaper hinterlegt. Hinweise und Korrekturen an lars.bracker@steerable.org.