Das Playbook zur Bewertung von KI im Finanzbereich

Überblick

Einleitung

Ein wiederholbares Vorgehen, um zu entscheiden, welche Funktionen einen Platz in einem kontrollierten Workflow verdienen, welche nicht und welche Nachweise vor einer Skalierung erforderlich sind.

Funktionen auf Basis künstlicher Intelligenz (KI) sollten sich ihren Platz in Finance-Workflows verdienen. Dieses Toolkit bietet einen praxisnahen Rahmen, um tragfähige Use Cases zu identifizieren, Anbieterangaben unter realen Betriebsbedingungen zu prüfen sowie Nachvollziehbarkeit, Kontrollen und Wirtschaftlichkeit im Produktivbetrieb zu bewerten. Auf dieser Grundlage führt das Playbook Finance-Teams zu einer dokumentierten Entscheidung für Go, Revise oder Stop – gestützt auf Nachweise, klare Verantwortlichkeiten und einen messbaren Nutzen im Workflow. Die folgenden sieben Schritte zeigen den Einstieg.

Schritt 1

Beginnen Sie mit der Entscheidung, nicht mit der Technologie

Eine überzeugende Demo beweist, dass Software ein Ergebnis erzeugen kann. Sie beweist nicht, dass dieses Ergebnis in den Abschlussprozess, einen Forecast, eine Abstimmung oder eine Berichtsvorlage für das Aufsichtsgremium gehört. Entscheidend ist hier eine Frage: „Verdient diese Funktion einen Platz in diesem Workflow?“

Die Antwort aus Sicht der Bewertenden verändert die Beurteilung. Eine generierte Abweichungserklärung kann beispielsweise perfekt formuliert und dennoch unbrauchbar sein, wenn Finance die Aussage nicht auf die zugrunde liegenden Konten und Transaktionen zurückführen kann. Ein Zuordnungsvorschlag für eine Abstimmung wirkt möglicherweise weniger beeindruckend, bietet aber einen Nutzen. Warum? Weil eine prüfende Person den Vorschlag in Sekunden verifizieren kann und das System protokollieren kann, wer die Abstimmung freigegeben hat.

Der Chief Financial Officer (CFO) sollte den Nachweisstandard festlegen und bei wesentlichen Use Cases die abschließende Go-, Revise- oder Stop-Entscheidung treffen. Die meisten Tests sollten anschließend Controller, Chief Accounting Officers, Verantwortliche für Financial Planning and Analysis (FP&A), interne Revision, IT, Informationssicherheit und Einkauf durchführen. Der CFO muss den Piloten nicht selbst leiten, sollte aber bereits vor dessen Beginn wissen, welche Nachweise einen Produktiveinsatz rechtfertigen würden.

Nutzen Sie eine dreistufige Wertschöpfungskette

Der Nutzen von KI im Finanzbereich sollte in dieser Reihenfolge belegt werden:

Springen Sie nicht direkt vom Modellergebnis zu Marge, Umsatz oder Unternehmenswert. Software kann Entscheidungen unterstützen, aber Preis-, Einkaufs-, Einstellungs- oder Vertriebsmaßnahmen nicht eigenständig umsetzen. Ein Business Case, der eine direkte Verbindung zwischen KI-Ergebnis und finanzieller Performance herstellt, lässt die wichtigsten Annahmen im Verborgenen.

Schritt 2

Bauen Sie eine Pipeline von Use Cases auf

KI im Finanzbereich ist ein Portfolio kleiner Workflow-Entscheidungen mit unterschiedlicher Wirtschaftlichkeit und unterschiedlichen Risiken. Die Chance mit der höchsten Rendite ist häufig nicht die sichtbarste.

Prüfen Sie jeden Kandidaten anhand von fünf Fragen

Das Volumen ist relevant, weil „mühsam“ und „teuer“ unterschiedliche Dinge sind. Eine Aufgabe von 30 Minuten, die 400-mal im Monat ausgeführt wird, umfasst 200 Stunden. Dieselbe Aufgabe, sechsmal pro Quartal ausgeführt, umfasst 3 Stunden. Im ersten Fall kann ein Business Case für Automatisierung tragfähig sein; im zweiten reicht möglicherweise eine Prozessverbesserung.

• 200 Std.

  Arbeit pro Monat bei einer 30-minütigen Aufgabe, die 400-mal im Monat ausgeführt wird – ein Business Case für Automatisierung kann tragfähig sein

• 3 Std.

  pro Quartal bei derselben Aufgabe, sechsmal pro Quartal ausgeführt – möglicherweise reicht eine Prozessverbesserung

Die Kosten der Überprüfung sind relevant, weil sie den vermeintlichen Gewinn aufzehren können. Um einen Abstimmungsvorschlag zu bestätigen, genügt häufig der Vergleich zweier Beträge. Ein generierter Kommentar kann dagegen erfordern, dass ein erfahrener Analyst die Herleitung rekonstruiert, bevor der Text verwendet werden kann. Beides kann unter demselben „KI“-Label angeboten werden, wirtschaftlich aber völlig unterschiedlich ausfallen.

Auch Datenkomplexität verursacht Kosten. Jedes zusätzliche Quellsystem, jeder Kontenplan, jedes manuelle Mapping und jeder Ausnahmeprozess erzeugt Implementierungs- und Wartungsaufwand. Wenn die Funktion erst arbeitet, nachdem Finance die Umgebung manuell vorbereitet hat, gehört dieser Aufwand in den Business Case, statt als kostenlose Einrichtung behandelt zu werden.

Priorisieren Sie zunächst „unspektakuläre“ Use Cases

Kommentare für das Aufsichtsgremium, Executive Summaries und Fragen in natürlicher Sprache lassen sich überzeugend demonstrieren, weil jeder die Ergebnisse lesen kann. Sie stellen jedoch auch hohe Anforderungen an die Nachweise: Die Ergebnisse sind sichtbar, ein plausibel wirkender Fehler kann teuer werden und die Überprüfung ist häufig aufwendig.

Die besseren Erstinvestitionen sind meist weniger glamourös:

• Zuordnung von Posten bei Abstimmungen
• Klassifizierung von Ausnahmen
• Erkennung von Anomalien
• Arbeitslisten für die weitere Untersuchung

Dasselbe gilt für andere Aufgaben mit hohem Volumen, bei denen Nachweise bereits vorliegen und eine prüfende Person einen ungeeigneten Vorschlag mit geringem Aufwand verwerfen kann

Schritt 3

Übersetzen Sie Anbieterangaben in überprüfbare Hypothesen

Eine Aussage verdient nur dann Aufmerksamkeit, wenn Finance sie widerlegen kann. Bevor Sie eine Nutzenaussage akzeptieren, verlangen Sie Angaben zu Tätigkeit, Menge, Einheit, Ausgangswert, Zeitraum, Grundgesamtheit und Nachweisquelle.

Trennen Sie Kennzahlen, die Anbieter häufig vermischen

Fragen Sie außerdem, welche Technologie den demonstrierten Schritt ausführt. Deterministische Regeln, statistische Modelle und generative Modelle versagen auf unterschiedliche Weise und erfordern daher unterschiedliche Nachweise. Ein Produkt kann letztlich alle drei enthalten. Die Bewertung sollte sich deshalb auf das Verhalten der konkreten Funktion konzentrieren, nicht auf das Produktlabel.

Schritt 4

Führen Sie vor dem Produktiveinsatz vier Tests durch

Jeder Pilot sollte vier Fragen beantworten. Für jede Frage sollte vor Testbeginn ein Ausschlusskriterium festgelegt werden.

1. Workflow: Ist der Workflow definiert?
2. Daten: Funktioniert die Lösung mit unseren Daten?
3. Ergebnis: Lässt sich das Ergebnis fundiert vertreten?
4. Kontrollen: Lässt sich die ausgeführte Aktion wirksam steuern und kontrollieren?

Test 1: Workflow – ist er definiert und liegt die Verantwortung fest?

Erstellen Sie vor der Demo ein einseitiges Workflow-Briefing. Benennen Sie Aufgabe, Nutzer, Verantwortlichen für den Produktivbetrieb, erwartetes Ergebnis, nachgelagerte Entscheidung, Risiko bei Fehlern und das System, in dem die Arbeit stattfindet. „Intercompany-Abstimmung für Produktionsgesellschaften“ ist ein Workflow. „Abschluss“ ist keiner.

Die Beschreibung des Fehlerrisikos bestimmt die Anforderungen an Nachweise und Kontrollen. Die Erstellung interner Kommentarentwürfe sollte nicht denselben Kontrollen unterliegen wie eine wesentliche Journalbuchung; umgekehrt darf für eine wesentliche Journalbuchung nicht der niedrigere Standard für Textentwürfe gelten.

Test 2: Daten – funktioniert die Lösung unter unseren Produktivbedingungen?

Stellen Sie den Testdatensatz anhand realer Unternehmensbedingungen zusammen, nicht anhand einer Referenzumgebung des Anbieters. Berücksichtigen Sie die Komplikationen, an denen Automatisierung üblicherweise scheitert:

• Mehrere Systeme
• Unterschiedliche Kontenpläne
• Offene und geschlossene Perioden
• Restatements
• Währungen
• Nicht zugeordnete Datensätze
• Gescannte Dokumente
• Bekanntermaßen fehlerhafte Datensätze

Geben Sie dem Anbieter die Referenzlösungen anschließend nicht vorab bekannt.

Zählen Sie korrekt erkannte Fälle, übersehene Fälle und False Positives. False Positives sind keine nachrangige Qualitätskennzahl: Sie entscheiden darüber, ob die Funktion Arbeit abnimmt oder eine neue Prüfliste erzeugt. Dokumentieren Sie jedes Mapping und jeden manuellen Vorbereitungsschritt, an dem der Anbieter beteiligt ist. Bereinigen Sie die Daten nicht vorab, sofern dies nicht auch im Produktivprozess vorgesehen ist.

Test 3: Ergebnis – kann Finance das Ergebnis fundiert vertreten?

Verwechseln Sie eine Antwort nicht mit einer Erklärung, Nachweisen, einem Audit Trail oder Reproduzierbarkeit. Ein brauchbares Ergebnis im Produktivbetrieb sollte ein seinen möglichen Folgen angemessenes Nachweisniveau bieten. Bei wesentlichen Ergebnissen sollte Finance Folgendes identifizieren können:

• Quelldatensätze
• Ausgeführte Operation
• Wesentliche Eingabedaten und Ausschlüsse
• Version des Modells oder Regelwerks
• Prüfhistorie
• Ausreichend aufbewahrte Nachweise, um das Ergebnis später reproduzieren oder rekonstruieren zu können

Wenn die Nachweise nur in der Anbieterumgebung oder nur unter der aktuellen Modellversion vorliegen, hat der Audit Trail ein Verfallsdatum. Verhandeln Sie Aufbewahrungs- und Exportrechte vor der Vertragsunterzeichnung.

Test 4: Kontrollen – kann das System das Betriebsmodell durchsetzen?

Die Kontrollen sollten sich danach richten, welche Aktionen die Funktion ausführen kann. Für wesentliche Buchungen und Reporting-Ergebnisse benötigt Finance typischerweise Folgendes:

• Freigabe, bevor die Aktion wirksam wird
• Angemessene Zugriffskontrollen
• Eine Protokollierung, die die Rekonstruktion von Ereignissen ermöglicht
• Funktionstrennung zwischen Vorschlag bzw. Konfiguration und Freigabe

Diese Empfehlungen betreffen die Governance und sind keine gesetzlichen Vorgaben. Die zuständigen Verantwortlichen für die internen Kontrollen sollten die genaue Ausgestaltung festlegen.

Testen Sie Kontrollen, indem Sie das System zu einer unzulässigen Aktion auffordern. Wenn die Person, die den Workflow konfiguriert hat, das Ergebnis nicht freigeben darf, versuchen Sie es trotzdem. Die Verweigerung durch das System ist ein Nachweis. Ein Richtliniendokument ist keiner.

Schritt 5

Machen Sie aus Produktivität eine wirtschaftliche Entscheidung

Der häufigste Fehler im Business Case für KI im Finanzbereich besteht darin, eingesparte Stunden mit eingesparten Kosten gleichzusetzen. Ein Pilot kann monatlich 200 Stunden freisetzen, ohne die Kostenbasis zu verändern. Die Technologie mag einwandfrei funktioniert haben – Finance hat lediglich nie entschieden, wie die Kapazität genutzt werden soll.

Prüfen Sie jede Aussage zu Stunden anhand von vier Stufen

Für Kapazität mit beschlossener Verwendung gibt es drei belastbare Optionen:

Entlastung kann eine legitime Entscheidung sein, insbesondere bei überlasteten Teams. Benennen Sie sie jedoch korrekt. „Wir haben entschieden, dem Team wieder mehr freie Kapazität zu geben“ ist etwas anderes als die Behauptung einer direkt kostenwirksamen Einsparung.

Schritt 6

Entscheiden Sie: Go, Revise oder Stop

Jede Bewertung sollte mit einer von drei schriftlichen Entscheidungen und den zugehörigen Nachweisen enden.

Ein erfolgreicher Pilot liefert Nachweise für den getesteten Umfang, nicht für einen unternehmensweiten Einsatz. Die Übertragbarkeit auf andere Gesellschaften, Systeme, Sprachen oder Prozessvarianten ist eine gesondert zu prüfende Aussage. Testen Sie vor der Skalierung mindestens eine bewusst anspruchsvolle zweite Umgebung, statt das Team auszuwählen, das sich am einfachsten freiwillig einbinden lässt.

Nutzen Sie für alle Piloten dieselbe Scorecard

Ein Pilot kann insgesamt gut abschneiden und dennoch an einem Punkt scheitern, der den Produktiveinsatz unvertretbar macht. Nutzen Sie die folgende Scorecard, um Kandidaten einheitlich zu vergleichen, betrachten Sie die Freigabekriterien aber separat. Der Score zeigt die relative Stärke; die Voraussetzung für den Produktiveinsatz entscheidet dagegen, ob eine Funktion produktionsreif ist. Bewerten Sie jede Dimension mit 0 bis 3:

• 0 = keine Nachweise
• 1 = Behauptung des Anbieters
• 2 = Nachweise aus dem Piloten
• 3 = Nachweise, die eine unabhängige prüfende Person ohne Beteiligung des Anbieters einsehen könnte

Ein hoher Score allein reicht nicht aus. Manche Anforderungen müssen erfüllt sein, bevor eine Funktion produktiv eingesetzt werden darf. Vergleichen Sie Kandidaten anhand des gewichteten Scores und entscheiden Sie anhand der Voraussetzungen für den Produktiveinsatz, ob eine Funktion einsatzbereit ist.

Schritt 7

Erläutern Sie die Entscheidung wirkungsvoll

Aufsichtsgremien und Prüfungsausschüsse beurteilen das Urteilsvermögen des Managements:

• Was die Funktion leistet und wo ihre Grenzen liegen
• Was sich im Kontrollumfeld verändert hat
• Wer die Verantwortung für das Ergebnis trägt
• Welcher Nutzen tatsächlich nachgewiesen wurde
• Was das Management dazu veranlassen könnte, den Einsatz einzugrenzen oder zu stoppen

Beantworten Sie bei einer Go-Entscheidung vier Fragen

• Umfang: Was leistet die Funktion und was nicht?
• Kontrolle: An welcher Stelle ist eine menschliche Freigabe vorgesehen und was verhindert das System?
• Nutzen: Wie hoch ist der Nettonutzen im getesteten Umfang – nicht die Schätzung des Anbieters oder die Bruttozeitersparnis?
• Monitoring: Wie sind Verantwortlichkeit, Überprüfungsrhythmus, Restrisiko und die vorab vereinbarte Bedingung für einen Stopp oder Rollback geregelt?

Beginnen Sie bei einer Stop-Entscheidung mit dem ausschlaggebenden Ausschlussgrund

Nennen Sie die Entscheidung, ohne den gesamten Piloten nachzuerzählen, die Nachweise, die den Produktiveinsatz unvertretbar machten, ob eine enger gefasste Aufgabe weiterhin infrage kommt und was die Bewertung gekostet hat. Ein gestoppter Pilot ist kein Beleg für ein gescheitertes KI-Programm, sondern dafür, dass der Bewertungsstandard funktioniert.

Zeigen Sie bei einem begrenzten Einsatz, wie konsequent Sie den Umfang eingrenzen

Legen Sie dar, was einbezogen und ausgeschlossen ist, warum diese Grenze besteht und welche Nachweise für eine Erweiterung erforderlich wären. Vermeiden Sie jedoch, den Umfang während der Besprechung auszuweiten. So wird aus einem kontrollierten Piloten eine Abhängigkeit ohne geregelte Governance.

Fazit

Fazit

Dieses Toolkit beruht auf einem einfachen Gedanken: KI sollte genauso bewertet werden wie jede andere Investition im Finanzbereich.

Prüfen Sie nicht nur, ob eine Funktion beeindruckt, sondern ob sie einen konkreten Workflow verbessert, verlässliche Ergebnisse für Finance liefert und messbaren Nutzen schafft. Gute Entscheidungen beruhen auf Nachweisen, nicht auf Demos. Dazu gehört zu verstehen, wo eine Funktion sinnvoll eingesetzt werden kann, wo nicht und welche Kontrollen vor dem Produktiveinsatz erforderlich sind.

Das Ergebnis einer Bewertung sollte eindeutig sein. Manche Use Cases rechtfertigen einen breiteren Rollout, andere benötigen einen engeren Umfang, zusätzliche Tests oder überhaupt keine weiteren Investitionen. Diese Disziplin ist eine Stärke, keine Einschränkung. Letztlich muss Finance bei jedem Piloten dieselben Standards anwenden, um die Ressourcen auf die richtigen Funktionen zu konzentrieren: auf solche, die reale Probleme lösen, bessere Entscheidungen unterstützen und einer kritischen Prüfung auch dann standhalten, wenn die anfängliche Begeisterung über die Demo längst verflogen ist.