Die meisten Finanzteams kaufen heute mehr KI ein, als sie selbst entwickeln. Sie rufen eine gehostete Modell-API auf, erhalten eine brauchbare Antwort und machen weiter. Diese Bequemlichkeit verdeckt eine Governance-Tatsache, die immer wieder in Vergessenheit gerät: Wenn Sie das Modell eines anderen über das Netz aufrufen, haben Sie einen IKT-Dienst übernommen, mitsamt allen Third-Party-KI-Risiken, die damit einhergehen. Das Modell liegt nicht in Ihrem Repository. Die Gewichte gehören nicht Ihnen. Und trotzdem landet die Ausgabe in einem Prozess, der mit dem Geld Ihrer Kunden in Berührung kommt.
Das ist kein Grund, auf Anbietermodelle zu verzichten. Alles selbst zu bauen ist selten die richtige Antwort, und die besten gehosteten Modelle sind ausgesprochen gut. Es ist vielmehr ein Grund, gekaufte KI mit derselben Disziplin zu behandeln, die Sie ohnehin schon jedem kritischen Lieferanten entgegenbringen.
Eine Modell-API ist ein Drittanbieter in Ihrem Register
Beginnen wir mit der unspektakulären administrativen Wahrheit. Eine gehostete Modell-API ist ein IKT-Dienst, der von einem Dritten erbracht wird, und sie gehört in Ihr Drittanbieterregister, neben Ihre Verwahrplattform und Ihren Marktdaten-Feed. DORA erwartet von Finanzunternehmen, ein Register der vertraglichen Vereinbarungen über IKT-Dienste zu führen und das damit verbundene Risiko jeweils zu bewerten. Ein Modell-Endpunkt, nach dem Ihr Team ad hoc greift, erhält keine Ausnahme, nur weil er sich leicht aufrufen lässt.
Die erste Aufgabe ist also wenig glamourös: Finden Sie jede Stelle, an der ein externes Modell genutzt wird. In der Praxis heißt das, Codebasen nach API-Schlüsseln und Basis-URLs zu durchsuchen, die Teams zu fragen, was sie verdrahtet haben, und festzuhalten, was jeder Aufruf tatsächlich tut. Einige davon treiben eine kundenseitige Entscheidung an. Andere extrahieren im Backoffice Daten aus Meldungen. Das Register muss wissen, was wovon zu unterscheiden ist, denn das Risiko ist nicht dasselbe.
Konzentrationsrisiko und der einzelne Anbieter
Sobald Sie die Liste haben, zeigt sich meist ein Muster. Drei Teams, fünf Prozesse und ein einziger Anbieter hinter allen. Das ist Konzentrationsrisiko, und genau hier setzt DORA am stärksten an. Wenn der Entity-Resolution-Helfer, der Dokumenten-Summarizer und der Kunden-Chatbot allesamt vom selben Anbieter abhängen, trifft ein einziger Ausfall, eine Preisänderung oder eine Anpassung der Nutzungsbedingungen sie alle auf einen Schlag.
Konzentration ist nicht automatisch schlecht. Sich auf einen leistungsfähigen Anbieter zu konsolidieren, kann die richtige Entscheidung sein. Entscheidend ist, dass diese Entscheidung bewusst getroffen und dokumentiert wird, und nicht zufällig zustande kommt, weil alle nach demselben Namen gegriffen haben. Sie wollen Ihr Exposure kennen, bevor der Anbieter eine schlechte Woche hat, nicht erst mittendrin.
An diesem Punkt hören Exit und Kontinuität auf, bloße Formsache zu sein. Stellen Sie die schlichten Fragen:
- Wenn dieser Anbieter genau das Modell zurückzöge, von dem wir abhängen, wie lange dauerte es, bis wir auf einer Alternative liefen?
- Lassen sich unsere Prompts und unser Evaluierungsdatensatz zu einem anderen Anbieter umziehen, oder sind sie um die Eigenheiten eines einzelnen Modells herum geformt?
- Gibt es einen Fallback-Pfad, der kontrolliert herunterfährt, notfalls auf ein langsameres oder günstigeres Modell, statt den Prozess ganz scheitern zu lassen?
Das Problem der stillen Updates
Hier kommt der Teil, der auch sorgfältige Teams erwischt. Bei Ihrem eigenen Modell kontrollieren Sie die Gewichte, eine Änderung ist also ein Ereignis, das Sie selbst terminiert haben. Bei einem Anbietermodell können sich die Gewichte unter Ihnen verändern. Die Versionsbezeichnung bleibt gleich, der Endpunkt ist unverändert, und trotzdem driftet das Verhalten ab, weil der Anbieter etwas nachtrainiert oder getunt hat. Ihr Audit-Trail sagt, nichts habe sich geändert. Ihre Ausgaben sagen etwas anderes.
Ein undurchsichtiges Anbietermodell können Sie nicht von innen prüfen, also validieren Sie um es herum. Zwei Methoden leisten den Großteil der Arbeit. Erstens: Grenzen Sie die Eingaben ein. Beschränken Sie, was Sie senden, sodass das Modell innerhalb eines getesteten Bereichs arbeitet, und weisen Sie alles außerhalb davon zurück oder markieren es. Zweitens: Gleichen Sie die Ausgaben gegen eine unabhängige Quelle ab. Wenn das Modell eine Umsatzzahl aus einer Meldung extrahiert, prüfen Sie sie gegen den strukturierten Feed. Wenn es eine Transaktion klassifiziert, ziehen Sie eine Stichprobe und vergleichen sie mit einem regelbasierten Ergebnis. Wenn beide stärker auseinanderlaufen als üblich, ist das Ihr Frühsignal, dass sich das Modell bewegt hat, selbst wenn der Anbieter Ihnen nie etwas gesagt hat.
Pinnen Sie Modellversionen fest, wo die API es erlaubt, und halten Sie einen festen Evaluierungsdatensatz bereit, den Sie planmäßig erneut durchlaufen lassen können. Ein Einbruch in dieser Kennzahl ist Ihre Art, ein stilles Update aufzuspüren, bevor ein Kunde es tut. Nichts davon erlaubt Ihnen den Blick ins Innere des Modells. Es erlaubt Ihnen zu bemerken, wann sein Verhalten nicht mehr zu dem passt, was Sie freigegeben haben.
Dies ist keine Rechtsberatung, und Ihre DORA-Pflichten hängen von Ihrer konkreten Einstufung und Ihren Vereinbarungen ab. Doch die technische Haltung gilt unabhängig davon, wie die Regulierung im Einzelfall auf Sie zutrifft: Behandeln Sie jede Modell-API als Lieferanten, kennen Sie Ihre Konzentration, und gehen Sie davon aus, dass sich das Modell ändern kann, ohne Ihnen Bescheid zu geben.