Make, Buy oder Partner: ein KI-Entscheidungsrahmen mit echten Kosten

Nehmen Sie einen mittelgroßen Versicherer — ein Komposit aus mehreren Gesprächen der letzten zwei Jahre — mit drei Angeboten auf dem Tisch für einen Dokumentenassistenten in der Schadenbearbeitung. Ein SaaS-Copilot zum Monatspreis pro Nutzer. Die Plattform eines Systemintegrators, Festpreis-Aufbau plus Supportvertrag. Und ein interner Plan: zwei Entwickler, ein Open-Weight-Modell auf EU-gehosteten GPUs, Retrieval über das Schadenarchiv. Jedes Angebot ist das günstigste — auf seiner eigenen Folie, über seinen eigenen Horizont, mit seiner eigenen Definition von „fertig“.

Die Frage darunter lautet nicht, welche Option am wenigsten kostet. Sie lautet, was der Versicherer kaufen würde. Dieser Leitfaden ist die Methode, die ich für diese Frage verwende: drei Tore vor jeder Preisliste, ein Dreijahres-Kostenmodell, das den Ausstieg einschließt, und explizite Bewertungen für Lock-in und Souveränität. Er endet dort, wo die meisten echten Entscheidungen enden — bei einem Hybrid —, aber mit aufgeschriebenen Gründen.

Jede Option kauft drei Dinge zugleich

Was immer Sie wählen, Sie erwerben drei Dinge. Eine Fähigkeit: Das Ding erledigt die Arbeit. Eine Abhängigkeit: jemand oder etwas, worauf Sie sich nun verlassen — ein Anbieter, ein Modellbetreiber, ein Partner oder das Fortbestehen des eigenen Teams. Und eine Option: was die Wahl als Nächstes billig oder teuer macht.

Anbieterfolien bepreisen die Fähigkeit. Die Kosten stecken vor allem in der Abhängigkeit — Verträge, Preisänderungen, Integration, die Menschen, die das Ding verstehen müssen. Die Strategie steckt in der Option: ob der Anwendungsfall des nächsten Jahres eine Konfigurationsänderung ist oder eine neue Beschaffung.

Simon Wardleys Evolutionsachse — Genese, Eigenbau, Produkt, Commodity — ist das sauberste Werkzeug, das ich für einen ersten Schnitt kenne. Modellzugang ist in etwa drei Jahren von der Genese zur Commodity gewandert. Der Stanford AI Index berichtet, dass der Inferenzpreis für ein festes Fähigkeitsniveau zwischen Ende 2022 und Ende 2024 um mehr als das 280-Fache gefallen ist und dass Open-Weight-Modelle auf gängigen Benchmarks nur noch wenige Prozentpunkte hinter geschlossenen liegen. Eine Commodity zu kaufen ist richtig; eine Commodity zu bauen ist Eitelkeit. Der Fehler ist, die Schicht über den eigenen Daten — Retrieval, Integration in den Arbeitsablauf, Evaluation, Fachregeln — ebenfalls als Commodity zu behandeln. Sie ist per Definition Eigenbau, denn niemand sonst hat Ihre Daten.

Drei Tore vor jeder Preisliste

Tor eins: Differenzierung. Geoffrey Moores Unterscheidung zwischen Core und Context leistet hier noch immer die Arbeit. Core ist, wofür Kunden einen Aufpreis zahlen und was Wettbewerber nicht leicht kopieren können; Context ist alles, was funktionieren muss und was niemand bemerkt. Ein Schadenassistent, der Fragen zur Police schneller beantwortet, ist für fast jeden Versicherer Context. Einer, der einfache Schäden mit dokumentierter, prüfbarer Begründung reguliert, könnte Core sein. Der Test ist schlicht: Würden Kunden, Prüfer oder Wettbewerber es bemerken, wenn das hier deutlich besser wäre als das, was der Markt verkauft? Wenn nicht: kaufen — und die eigenen Entwickler auf etwas ansetzen, das bemerkt würde.

Tor zwei: Daten und Souveränität. Berührt der Anwendungsfall vertrauliche oder regulierte Daten, muss die Option das Souveränitätsniveau erfüllen, das diese Datenklasse auf allen vier Dimensionen verlangt — Ort, Rechtsraum, Kontrolle und Portabilität —, wie ich sie in einem eigenen Artikel (englisch) beschrieben habe. Ein SaaS-Produkt, das von außerhalb der EU betrieben wird, fällt beim Rechtsraum durch, es sei denn, eine EU-Gesellschaft betreibt es mit in der EU gehaltenen Schlüsseln; mehrere Anbieter bieten genau das inzwischen an, gegen Aufpreis und mit Einschränkungen in der Liste der Unterauftragsverarbeiter. Lesen Sie diese Liste, nicht die Marketingseite. Sind keine sensiblen Daten im Spiel, genügt Kaufen oder Partnern mit schlichtem EU-Hosting.

Tor drei: Betriebsfähigkeit. Bauen ist nicht der teure Teil; Betreiben ist es. Bereitschaft. Modellupdates, die das Verhalten ändern. Evaluationsläufe vor jeder Prompt-Änderung, denn eine Prompt-Änderung ist eine Produktionsänderung — die DORA-Aufsicht sieht das so, und Sie sollten es auch. Sicherheitspatches. Die Person, die geht. Wenn Sie die zwei Menschen nicht benennen können, die das System im achtzehnten Monat betreiben, bauen Sie nicht; Sie partnern mit Datum, und der Vertrag sollte das sagen.

Dreimal Ja ist der Fall fürs Bauen — auf offenen Standards, mit dem Exit entworfen vor dem ersten Commit. Alles andere hat einen Standard, der günstiger und ehrlicher ist als ein Eigenbau, den niemand betreiben kann.

Gesamtkosten über drei Jahre, nicht Preis pro Nutzer

Der Preis pro Nutzer ist die einzige Zahl, die sich leicht vergleichen lässt — deshalb dominiert sie die Diskussion, und deshalb ist sie die falsche Zahl. Die Kosten einer KI-Fähigkeit haben mindestens sieben Bestandteile, und die Optionen verteilen sie sehr unterschiedlich:

Bestandteil	Make	Buy	Partner
Lizenz oder Nutzung	Modell-Hosting oder API-Tokens	Pro Nutzer oder Token, steigend mit der Adoption	Im Aufbau enthalten, dann Supportpauschale
Integration	Ihre Entwickler	Nie nur einmal; bei jedem Upgrade erneut	Change Requests
Datenaufbereitung	Sie — und es ist der größte Teil der Arbeit	Weiterhin Sie	Teils der Partner, mit Ihren Datenverantwortlichen
Evaluation und QS	Sie	Sie; Anbieter können es nicht	Geteilt, dann Sie
Betrieb	Sie, vom ersten Tag an	Der Anbieter, innerhalb seines SLA	Der Partner, dann Sie
Adoption und Veränderung	Sie	Sie	Sie
Exit	Gering, wenn auf Standards gebaut	Export, Neuintegration, Umschulung	Übergabe, wenn der Vertrag es vorsieht

Drei Dinge zeigt das Diagramm, die eine Preisliste verbirgt. Kaufen ist in nichts vorfinanziert und wächst mit dem Erfolg: Die Nutzerzahl steigt, weil die Adoption funktioniert, und die Listenpreise steigen, weil sie es können. Bauen ist in Menschen vorfinanziert und flacht ab, sobald das System läuft. Partnern liegt dazwischen, und seine Kosten im zweiten Jahr sind vor allem Change Requests — die Dinge, von denen Sie erst merken, dass Sie sie brauchten, wenn echte Nutzer da sind. In diesem Modell überholt die SaaS-Option den Eigenbau bei den kumulierten Kosten um den achtundzwanzigsten Monat. Ihre Zahlen werden abweichen; die Form selten.

Das Diagramm endet bei Monat sechsunddreißig, weil Verträge das tun. Die Kosten des Ausstiegs stehen nicht darin, und sie sind die Zahl, die über die lange Frist entscheidet: Daten in einem brauchbaren Format exportieren, neu integrieren, Menschen umschulen, einen Korpus neu einbetten. Im Modell sind das grob 150 T€ für die SaaS-Option, 80 T€ für den Partneraufbau und 25 T€ für den Eigenbau. Fragen Sie in der Ausschreibung danach. Ein Anbieter, der keinen Exit beziffern kann, beziffert eine dauerhafte Beziehung.

Lock-in hat fünf Formen, und jede hat einen Preis

Über Lock-in wird meist als Gefühl gesprochen. Besser behandelt man ihn als fünf getrennte Kosten, die Sie vor der Unterschrift schätzen können.

1. Daten-Lock-in. Proprietäre Formate, kein Massenexport, Embeddings, die Sie nicht mitnehmen können. Preis: exportieren, transformieren, neu einbetten. Testen Sie es in der Erprobung: einen vollständigen Export verlangen und versuchen, ihn anderswo zu laden.
2. Modellverhaltens-Lock-in. Prompts, Beispiele und Leitplanken, die auf die Eigenheiten eines Modells abgestimmt sind. Ein Wechsel heißt neu abstimmen und neu evaluieren. Preis: ein Evaluationslauf und ein paar Wochen Feinarbeit — klein, wenn der Evaluationsdatensatz existiert, unabsehbar, wenn nicht. Halten Sie das Modell hinter einer Schnittstelle, die Sie austauschen könnten.
3. Ablauf-Lock-in. Die Oberfläche des Werkzeugs ist zum Prozess geworden; die Gewohnheiten der Menschen leben darin. Preis: Umschulung und ein Produktivitätseinbruch. Real — und meist unterschätzt von denen, die das Werkzeug nie benutzen.
4. Vertraglicher Lock-in. Mindestlaufzeiten, automatische Verlängerung, Preisgleitklauseln, Löschfristen. Seit September 2025 verpflichtet der EU Data Act Anbieter von Datenverarbeitungsdiensten, den Wechsel zu unterstützen, und schafft Wechselentgelte bis Januar 2027 ab; prüfen Sie, ob Ihr Dienst in den Anwendungsbereich fällt, und nutzen Sie das in der Verhandlung.
5. Kompetenz-Lock-in. Ihr Team kennt die Plattform des Anbieters, nicht die Fachdomäne. Der Preis zeigt sich an dem Tag, an dem Sie gehen wollen und niemand beschreiben kann, was das System eigentlich tut.

Für Finanzunternehmen ist nichts davon optional: DORA verlangt dokumentierte und getestete Ausstiegsstrategien für kritische IKT-Dienste, und ein Modellanbieter oder eine KI-Plattform ist einer. Für alle anderen ist es schlicht der Unterschied zwischen einer Entscheidung und einem Dauerzustand.

Souveränität ist eine Bewertung, kein Häkchen

Bewerten Sie jede Option auf den vier Dimensionen, je Datenklasse, von null bis vier. Ein von außerhalb der EU betriebenes SaaS-Produkt schneidet typischerweise gut beim Ort ab, schlecht bei Rechtsraum und Kontrolle — der Anbieter hält die Schlüssel — und schlecht bei der Portabilität. Dasselbe Produkt, betrieben von einer EU-Gesellschaft mit kundenverwalteten Schlüsseln, rückt bei Rechtsraum und Kontrolle nach oben; die Portabilität hängt vom Export ab, den Sie unter Lock-in getestet haben. Ein Partneraufbau erhält die Bewertung des Partner-Stacks — bestehen Sie deshalb an jeder Grenze auf offenen Standards. Ein Eigenbau auf EU-Infrastruktur erreicht bei Kontrolle und Rechtsraum die höchste Bewertung, und seine Portabilität ist eine Frage Ihrer eigenen Disziplin: Infrastructure as Code, portable Formate, eine bei einem zweiten Anbieter getestete Wiederherstellung.

Souveränität ist ein Spektrum. Entscheiden Sie je Datenklasse, welches Niveau Sie brauchen, bewerten Sie die Optionen daran und schreiben Sie die Begründung auf. Eine Behörde wird sie hoch gewichten; ein Start-up ohne personenbezogene Daten vielleicht niedrig. Beide haben recht — für ihre Situation.

Alles auf eine Bewertungsmatrix

Die Matrix entscheidet nicht. Sie macht die Diskussion explizit: Das Argument steckt in den Gewichten, und die Gewichte kommen aus der Strategie. Im Versichererbeispiel liegen Eigenbau und Partneroption nah beieinander, und der SaaS-Copilot verliert bei Exit-Kosten und Rechtsraum, obwohl er bei der Zeit bis zum Nutzen klar gewinnt. Das ist bei regulierten Daten ein typisches Ergebnis, kein manipuliertes. Ändern Sie die Datenklasse auf Marketingtexte, und der Copilot gewinnt.

Die normale Antwort ist ein Hybrid

Echte Entscheidungen landen selten in einer Spalte. Das Muster, das hält:

• Die Commodity-Schicht kaufen. Modellzugang — ein EU-gehosteter Inferenz-Endpunkt oder Open-Weight-Modelle auf eigenen GPUs — hinter einer Schnittstelle, die Sie in zwei Wochen austauschen könnten.
• Die differenzierende Schicht bauen. Retrieval über Ihre Daten, die Integration in den Arbeitsablauf, die Evaluationsumgebung, die Fachregeln. Das ist der Teil, um den es beim Context Engineering geht, und er gehört Ihnen, ob Sie wollen oder nicht.
• Partnern, wo Ihnen eine Fähigkeit vorübergehend fehlt, mit Transferklausel — Code, Dokumentation, Runbooks, ein Übergabe-Sprint — und einem Datum, an dem Ihre Leute übernehmen.

Drei Anti-Muster erklären die meisten teuren Fehler, die ich sehe: alles selbst bauen, weil das Entwicklungsteam begeistert ist; die Plattform kaufen und dann sechzig Prozent davon anpassen; und partnern ohne Enddatum, was Kaufen mit Umwegen ist.

Was das für Ihre nächste Entscheidung bedeutet

In der Version der Versicherergeschichte, die gut ausgeht, gewinnt der Hybrid: ein Open-Weight-Modell auf EU-GPUs, ein Partneraufbau mit neunmonatigem Transferplan und die Retrieval-Schicht über dem Schadenarchiv vom ersten Tag an im eigenen Haus. Als das Modell ein Jahr später ausgetauscht wird, ist das eine Sache von zwei Wochen, weil der Evaluationsdatensatz existiert. Als der separat gekaufte Copilot des Vertriebs seinen Preis erhöht und sein Export sich als unbrauchbar erweist, weiß die Finanzleitung genau, welchen Schritt diese Entscheidung übersprungen hat.

Nichts davon ist Glück. Es ist das Dritte, das jede Option kauft — die Option selbst —, ernst genommen in dem Moment, in dem das am günstigsten war: vor der Unterschrift.