Build vs. Buy für Finance-Ops-KI: ein Entscheidungsrahmen und TCO-Modell

Ist Ihr Workflow Standard und Ihre Daten verschaffen keinen Vorsprung, kaufen Sie ein Point-Tool. Berührt er eine regulierte Entscheidung oder läuft er auf Daten, die nur Sie haben, ist das Modell der einfache Teil; bauen Sie die Pipeline drumherum. Die meisten Finance-Teams liegen dazwischen – und dort lautet die Antwort: ein Build auf zugekauften Komponenten, der Kontrolle über Lineage und Evaluation gegen Geschwindigkeit bis zum ersten Output abwägt.

Das ist die Kurzfassung. Der Rest zeigt, wie wir mit einem konkreten Team dorthin kommen, und die Zahlen, auf die wir alle blicken lassen, bevor jemand unterschreibt.

Drei Optionen – und was jede Sie wirklich kostet

Es liegen drei Formen auf dem Tisch, und das Marketing rund um alle drei verwischt die Unterschiede.

Ein Point-Tool erledigt genau eine Aufgabe. Spesenkategorisierung, Rechnungsextraktion, ein Chatbot über Ihre Richtliniendokumente. Sie schicken Daten rein, Sie bekommen strukturierten Output zurück. Der Reiz: Es funktioniert nächste Woche. Der Preis, den Sie mitunterschreiben: Das Modell des Anbieters wurde auf den Daten aller trainiert, wird also bei Ihrem Ledger nie besser sein als bei dem Ihres Wettbewerbers – und Sie erben dessen False-Positive-Rate, ob sie zu Ihrer Risikobereitschaft passt oder nicht.

Eine Plattform liefert Ihnen Komponenten: einen Retrieval-Layer, ein Agent-Framework, Konnektoren, vielleicht einen gehosteten Feature Store. Die Logik schreiben Sie weiterhin selbst. Das Versprechen: Die Klempnerei ist gelöst, Sie bauen nur noch den Teil, der Ihnen gehört. Manchmal stimmt das. Der Fehlerfall: Die Abstraktionen der Plattform passen nicht zu der Form, in der Ihre Daten tatsächlich vorliegen, und Sie verbringen die gesparte Zeit damit, gegen den Konnektor zu kämpfen, statt den Konnektor zu schreiben.

Ein Engineering-geführter Build heißt, die Pipeline gehört Ihnen. Sie entscheiden, wie Features berechnet werden, wie Lineage protokolliert wird, was im Eval-Set steht und wann eine Modellversion ausgeliefert werden darf. Das ist der langsamste Weg zum ersten Output – und die einzige Option, mit der Sie eine Entscheidung gegenüber einem Aufseher mit Ihrem eigenen Audit-Trail verteidigen können.

Der Fehler ist, diese drei als ein einziges Spektrum von billig zu teuer zu behandeln. Es sind verschiedene Wetten darauf, wo Ihr Vorteil liegt. Liegt Ihr Vorteil in proprietären Daten und einer Entscheidung, die einer Prüfung standhalten muss, kann ein Point-Tool die Aufgabe zu keinem Preis erfüllen. Es löst ein anderes Problem, und kein Rabatt ändert das.

Das TCO-Modell, das wir tatsächlich verwenden

Anbieterpreise sind eine Abo-Zeile. Die realen Kosten sind es nicht. Wir stellen jede Option über drei Jahre in dieselbe Tabelle und erzwingen, dass die versteckten Spalten ausgefüllt werden.

• Lizenz oder Infrastruktur. Pro Seat, pro Call oder die GPU- und Hosting-Rechnung. Die einzige Zeile, die Anbieter freiwillig nennen.
• Integrations-Engineering. Ihre Daten rein und den Output zurück ins System of Record. Hier wird aus „zwei Wochen bis zum Deployment” ein Quartal.
• Das Evaluations-Set. Sie brauchen ein gelabeltes Set, das Ihre eigenen Fälle abbildet, mit harten Beispielen und Edge Cases – egal ob Sie kaufen oder bauen. Niemand reicht Ihnen das. Budgetieren Sie die Analystenzeit für den Aufbau und den Prozess, es aktuell zu halten.
• Monitoring und Drift. Verteilungen verschieben sich. Ein Transaction-Monitoring-Modell, kalibriert auf die Typologien des Vorjahres, verfällt. Jemand muss die Input-Verteilung beobachten, die Output-Rate beobachten und nach Plan neu trainieren.
• Incident Response. Wenn das Modell in der Produktion falsch liegt: Wer bereinigt den Schaden, wer erklärt ihn, und wie lange läuft der Workflow im manuellen Fallback?
• Wechselkosten. Die Zahl, die mehr entscheidet, als man zugibt. Stecken Ihre Features, Prompts und Evals im Format eines Anbieters fest, ist der Preis des Ausstiegs der Preis des Neuaufbaus. Ein niedriges Abo mit teurem Exit ist teuer.

Ein durchgerechnetes Beispiel, das wir mit Kunden fahren: Ein Point-Tool zu einer moderaten Monatsgebühr sieht im ersten Jahr wie ein Bruchteil eines Builds aus. Verlängern Sie auf drei Jahre, addieren Sie das Eval-Set, das Sie ohnehin bauen müssen, addieren Sie die Integrationsarbeit und addieren Sie Wechselkosten unter der Annahme, dass Sie das Tool im zweiten Jahr entwachsen – und die Lücke schließt sich massiv. Der Build kostet immer noch mehr im Vorfeld. Er ist nur nicht mehr offensichtlich teurer, sobald die vollständige Tabelle ausgefüllt ist.

Zwei Kostenpunkte dominieren, und beide stehen auf der Build-Seite der Bilanz. Der Data Layer kommt zuerst. Point-in-time-korrekte Features, abfragbare Lineage und Entity Resolution über Systeme, die dieselbe Gegenpartei auf drei Arten schreiben, dauern länger als das Modell. Teams, die das überspringen, schleusen Lookahead in ihr Trainingsset und bekommen einen wunderschönen Backtest, der in der Produktion kollabiert. Der zweite ist die Evaluation. Sie sind nicht fertig, wenn die Demo läuft. Sie sind fertig, wenn Sie ein False-Positive-Budget haben, dem das Business zugestimmt hat, und ein Eval-Set, das belegt, dass Sie innerhalb davon liegen.

Wie man entscheidet

Führen Sie den Workflow durch vier Fragen, bevor Sie sich irgendeinen Preis ansehen.

• Verschaffen Ihre Daten Ihnen hier einen Vorsprung? Steckt das Signal in Ihrer Historie und Ihren Beziehungen, wirft der Kauf eines auf dem Marktdurchschnitt trainierten Modells den ganzen Grund weg, das überhaupt zu tun. Bauen oder stark anpassen. Ist die Aufgabe generische Extraktion, ist der Marktdurchschnitt in Ordnung. Kaufen.
• Was kostet eine falsche Antwort? Falsch kontierte Spesen: gering. Zu Unrecht abgelehnter Antragsteller nach ECOA oder ein übersehener Sanktionstreffer: hoch. Je höher die Kosten, desto mehr brauchen Sie Ihren eigenen Audit-Trail, Ihre eigenen Schwellenwerte und Kontrolle darüber, wann eine Version ausgeliefert wird. Das drängt in Richtung Build.
• Ist der Prozess stabil oder in Bewegung? Ein etablierter Workflow ist ein guter Kaufkandidat. Einen, den Sie Quartal für Quartal noch umgestalten, wird eine Anbieter-Roadmap nicht einholen, und Sie verbrennen die Abogebühr im Kampf gegen die Annahmen des Tools.
• Können Sie den Betrieb besetzen, nicht nur den Launch? Ein Build, den Sie nicht überwachen können, ist schlimmer als ein Tool, das Sie überwachen können. Haben Sie niemanden, der Drift, Retraining und Incident Response verantwortet, kaufen Sie das Ding, das jemand anderes am Leben hält – und seien Sie ehrlich, dass Sie dessen False-Positive-Rate als Ihre eigene akzeptiert haben.

Die meisten Finance-Ops-Teams landen bei einem Hybrid. Kaufen Sie die langweilige Klempnerei zu: Zugang zu einem Foundation-Modell, einen Extraktionsdienst, einen Vektorspeicher. Bauen Sie den Teil, der die regulierte Entscheidung berührt, und den Teil, der auf Daten läuft, die nur Sie halten. Ziehen Sie die Linie genau dort, wo Sie einen Output verteidigen müssen. Alles auf der Entscheidungsseite gehört Ihnen. Alles davor: kaufen, wenn es jemand günstiger verkauft, als Sie es selbst betreiben können. Nichts davon ist Ideologie. Ermitteln Sie, auf welcher Seite dieser Linie jedes Teil des Workflows liegt, und zahlen Sie nur dort für Kontrolle, wo Kontrolle ihre Kosten verdient.