KI-Anbieter-Due-Diligence: die Fragen, auf die es ankommt

Wer einen KI-Anbieter einkauft, kauft dessen Modellrisiko mit ein. Deren Trainingsdaten, deren Labeling-Entscheidungen, deren Drift und deren Ausfallmuster werden in dem Moment zu Ihren, in dem deren Output eine Kundenentscheidung oder ein Hauptbuch berührt. Due Diligence ist die Arbeit, diese geerbten Risiken vor Vertragsabschluss zu finden, nicht erst dann, wenn ein Prüfer fragt, wer das Modell validiert hat.

Die meiste KI-Beschaffung im Finanzsektor läuft wie eine Software-Beschaffung ab. Sicherheitsfragebogen, SOC-2-Bericht, Zusammenfassung des Pentests, Auftragsverarbeitungsvertrag, unterschreiben. Das deckt ab, ob der Anbieter Ihre Daten sicher verwahren kann. Es sagt nichts darüber aus, ob das Modell korrekt ist, ob dessen Genauigkeitsversprechen den Kontakt mit Ihren Daten übersteht oder was mit Ihrer Straight-through-Processing-Quote passiert, wenn dessen Modell in der Woche driftet. Das sind die Fragen, die entscheiden, ob das Ding funktioniert, und genau die überspringen die meisten Checklisten.

Behandeln Sie die Genauigkeitszahl als unbelegte Behauptung

Jeder KI-Anbieter führt mit einer Kennzahl. Vierundneunzig Prozent Genauigkeit bei der Rechnungsextraktion, ein Betrugsmodell, das das meiste fängt, was Regeln entgeht, ein Abstimmungstool, das den Long Tail automatisch matcht. Nehmen Sie nichts davon für bare Münze. Fragen Sie, wogegen die Zahl gemessen wurde.

• Was war das Evaluierungsset? Die Demo-Genauigkeit eines Anbieters wird auf dessen Daten gemessen, die von den Leuten bereinigt und gelabelt wurden, die das Produkt gebaut haben. Ihre Rechnungen, Ihre Kontrahenten und Ihre Firmennamen sehen völlig anders aus.
• Wie wurden die Labels erstellt, und von wem? Wenn ein Fachexperte die Ground Truth gelabelt hat, bedeutet die Zahl etwas. Wenn sie vom selben Modell oder durch billige Annotation gelabelt wurde, misst die Zahl Übereinstimmung, nicht Korrektheit.
• War der Split zeitbasiert? Genau hier bricht Finanz-ML klammheimlich zusammen. Wenn der Anbieter auf einem zufälligen Split desselben Zeitraums trainiert und getestet hat, hat er mit an Sicherheit grenzender Wahrscheinlichkeit Zukunftsinformationen in die Vergangenheit durchsickern lassen. Fragen Sie direkt, ob die Evaluierung die Point-in-Time-Korrektheit respektiert und ein Vorwärtsfenster zurückhält. Lookahead in einem Backtest ist der häufigste Weg, auf dem die plakative Zahl eines Anbieters eine Fiktion ist.
• Wie hoch ist das False-Positive-Budget? Ein Betrugs- oder AML-Modell, das doppelt so viel markiert, wie Ihre Ermittler abarbeiten können, fängt in der Praxis nicht mehr Betrug. Es verbrennt Prüfstunden und schiebt echte Alerts ans Ende der Warteschlange. Die Kennzahl, auf die es ankommt, ist die Präzision bei dem Recall, mit dem Sie tatsächlich arbeiten, auf einem Alert-Volumen, das Ihr Team an einem Tag durchgehen kann.

Die einzige Genauigkeitszahl, der man trauen kann, ist die, die Sie selbst erzeugen. Lassen Sie den Anbieter vor der Unterschrift auf einem zurückgehaltenen Ausschnitt Ihrer eigenen historischen Daten mit bekannten Ergebnissen laufen. Ein Anbieter, der einen bezahlten Proof of Concept auf Ihren Daten verweigert oder der zuerst auf Ihrem Testset tunen will, sagt Ihnen damit, dass seine allgemeine Zahl nicht übertragbar ist.

Verfolgen Sie nach, wie der Output entstanden ist

Eine Finanzentscheidung muss gegenüber einem Freigebenden, einem Prüfer und irgendwann einer Aufsichtsbehörde erklärbar sein. Das heißt, der Output des Anbieters kann keine nackte Antwort sein. Er muss seine Herkunft mit sich tragen.

• Lineage. Kann der Anbieter für jede Zahl, die das Modell produziert, zeigen, aus welchem Quelldokument, Feld oder welcher Transaktion sie stammt? Ein Abstimmungs-Match ohne ein nachverfolgbares Datensatzpaar ist nicht prüfbar. Eine Extraktion ohne Verweis auf den Zeichenbereich auf der Seite lässt sich zum Quartalsende nicht überprüfen.
• Entitätsauflösung. Wenn das Produkt Kontrahenten, Konten oder Wertpapiere über Systeme hinweg zusammenführt, fragen Sie, wie es entscheidet, dass zwei Datensätze dieselbe Entität sind. Genau hier leben die stillen Fehler. Ein falscher Merge verschiebt ein Exposure auf den falschen Schuldner, und niemand bemerkt es, bis es groß ist.
• Der Audit-Trail. Erfasst das System für jede Entscheidung die Modellversion, den Input, den Output und den Menschen, der akzeptiert oder überstimmt hat? Wenn sich eine Entscheidung von vor acht Monaten nicht rekonstruieren lässt, können Sie sie gegenüber einem Prüfer nicht verteidigen. Die Erwartungen an das Modellrisiko setzen voraus, dass Sie jede Entscheidung auf Anforderung wieder aufbauen können. Schreiben Sie die Anforderung also in den Vertrag, statt zu hoffen, dass der Anbieter genug protokolliert.
• Menschliches Override. Wenn ein Prüfer das Modell korrigiert, wohin geht diese Korrektur? Wenn sie das Modell still nachtrainiert, haben Sie ein Governance-Problem. Wenn sie ins Leere läuft, haben Sie ein Lernproblem. Sie wollen sie erfasst, versioniert und in kontrolliertem Takt zurückgespielt haben.

Lassen Sie sich während der Evaluierung eine echte Entscheidung von Anfang bis Ende zeigen. Nehmen Sie einen schwierigen Fall, verfolgen Sie ihn vom Rohinput bis zum finalen Output und prüfen Sie, dass jede Zahl dazwischen eine Quelle hat, auf die Sie zeigen können.

Modellrisiko und Lebenszyklus: was nach dem Go-live passiert

Der Ausfall, der Sie etwas kostet, tritt selten beim Start auf. Er kommt ein halbes Jahr später, wenn sich die Welt, die das Modell gelernt hat, verschoben hat und niemand hingesehen hat.

• Drift-Monitoring. Was überwacht der Anbieter im Produktivbetrieb, und was zeigt er Ihnen davon? Verschiebung der Input-Verteilung, Verschiebung der Output-Verteilung sowie Match- oder Akzeptanzraten über die Zeit sind das Minimum. Wenn das Monitoring eine grüne Statusseite ist, ist es Theater.
• Retraining und Change Control. Wann ändert sich das Modell? Ein Anbieter, der still eine neue Modellversion ausliefert, kann Ihr Straight-through Processing über Nacht kaputt machen und jede Validierung, die Sie durchgeführt haben, entwerten. Sie wollen Release Notes, Version-Pinning und das Recht, eine neue Version zu testen, bevor sie Ihren Produktivverkehr erreicht.
• Feature- und Datenabhängigkeiten. Wenn das Produkt auf einem Feature Store oder Datenfeeds von Dritten läuft, sind das Abhängigkeiten, die Sie erben. Fragen Sie, was mit dem Modell-Output passiert, wenn ein vorgelagerter Feed zum Quartalsende zu spät kommt oder fehlt. Ein Modell, das auf veralteten Features still degradiert, ist schlimmer als eines, das laut einen Fehler wirft.
• Konzentration und Ausstieg. Sitzt dieser Anbieter in einem kritischen Prozess, behandelt DORA ihn als IKT-Drittdienstleister. Sie brauchen Prüfrechte, Fristen für die Meldung von Vorfällen und einen echten Ausstiegsplan: Bekommen Sie Ihre Daten, Ihre Labels und Ihre Entscheidungshistorie heraus, und kann der Prozess ohne sie laufen, während Sie ihn ersetzen?

Wovon die Freigabe tatsächlich abhängen sollte

Reduzieren Sie die ganze Übung auf wenige Bestehensbedingungen. Sie haben den Anbieter auf Ihren eigenen zurückgehaltenen Daten laufen lassen, und die Genauigkeit hat an Ihrem Betriebspunkt gehalten. Jeder Output ist auf eine Quelle zurückführbar. Der Audit-Trail rekonstruiert jede vergangene Entscheidung. Sie kontrollieren, wann sich die Modellversion ändert. Sie haben ein Monitoring, das Sie lesen können, und einen Ausstieg, den Sie tatsächlich durchführen könnten. Fehlt eines davon, verschwindet die Lücke nicht dadurch, dass Sie gekauft statt gebaut haben. Sie wandert in Ihr Modellrisiko-Inventar, mit Ihrem Namen daneben.