Build or Buy: Eigene KI-Lösung oder Plattform-KI von SAP & Co.?

SAP bewirbt Joule, Microsoft den Copilot, Salesforce Agentforce. Und parallel versichert Ihnen jede Entwicklungsagentur, eine maßgeschneiderte KI-Lösung sei der einzig sinnvolle Weg. Beide Seiten verdienen an ihrer Empfehlung. Ihr Problem ist ein anderes: Wofür reicht die KI, die in Ihren bestehenden Systemen ohnehin enthalten ist? Und wo lohnt der Aufwand einer Eigenentwicklung wirklich? Dieser Guide liefert eine Entscheidungslogik entlang von vier Kriterien: Differenzierungswert, Gesamtkosten, Datenhoheit und Exit-Kosten.

Was Build or Buy bei KI bedeutet

Build or Buy (auch Make or Buy) bezeichnet die Entscheidung zwischen einer eigenentwickelten Lösung und dem Einkauf einer fertigen. Bei KI heißt das konkret: Entweder Sie nutzen die KI-Funktionen, die Plattformanbieter wie SAP, Microsoft, Salesforce oder ServiceNow in ihre Produkte einbauen. Oder Sie entwickeln eine eigene Anwendung auf Basis von Sprachmodellen, die Sie über eine API (eine Programmierschnittstelle, über die Software auf das Modell zugreift) oder als selbst betriebenes Open-Source-Modell einbinden.

Wichtig ist die richtige Flughöhe. Build or Buy ist keine Unternehmensentscheidung, sondern eine Entscheidung pro Anwendungsfall. Dasselbe Unternehmen kann für die E-Mail-Zusammenfassung im Posteingang sinnvoll auf Microsoft Copilot setzen und zugleich die Angebotskalkulation, die sein Kerngeschäft ausmacht, als eigene Lösung bauen. Wer pauschal entscheidet, entscheidet in der Hälfte der Fälle falsch.

Was Plattform-KI leistet — und was nicht

Plattform-KI ist KI-Funktionalität, die ein Softwareanbieter direkt in sein bestehendes Produkt integriert. SAP Joule beantwortet Fragen zu Geschäftsdaten im SAP-Kontext, Microsoft Copilot arbeitet in Word, Outlook und Teams, Salesforce Agentforce automatisiert Vorgänge im CRM. Die Stärken liegen auf der Hand. Die Integration in die Datenquellen ist vorgefertigt, der Anbieter übernimmt Betrieb und Modell-Updates, und die Einführung ist eher ein Rollout-Projekt als ein Entwicklungsprojekt.

Die Grenzen sind genauso real, werden im Vertrieb aber seltener erwähnt:

• Der Anbieter bestimmt die Roadmap. Welche Funktionen kommen, welche Modelle eingesetzt werden, was abgekündigt wird: darauf haben Sie keinen Einfluss.
• Plattform-KI endet an der Plattformgrenze. Prozesse, die über mehrere Systeme laufen, bildet ein einzelner Copilot nur unvollständig ab.
• Standard bleibt Standard. Die Funktion, die Sie nutzen, nutzt Ihr Wettbewerber in identischer Form. Ein Vorsprung entsteht daraus nicht.
• Anpassungstiefe ist begrenzt. Eigene Geschäftslogik lässt sich oft nur über die vorgesehenen Erweiterungspunkte einbringen, und diese Erweiterungen sind dann wiederum plattformgebunden.

Trotzdem gilt: Für Standardaufgaben ohne Differenzierungspotenzial ist Plattform-KI in den meisten Fällen die wirtschaftlichere Wahl. Wie sich vorhandene Plattform-Funktionen systematisch erschließen und sauber konfigurieren lassen, beschreiben wir unter Plattform-Agents.

Was Eigenentwicklung heute bedeutet

„Build“ heißt heute fast nie, ein eigenes Sprachmodell zu trainieren. Das ist für die allermeisten Unternehmen weder nötig noch wirtschaftlich darstellbar. Eigenentwicklung bedeutet in der Praxis etwas anderes: eine eigene Anwendung um ein bestehendes Modell herum bauen. Typische Bausteine sind RAG (Retrieval-Augmented Generation, das Modell erhält vor der Antwort relevante Dokumente aus den eigenen Beständen als Kontext), eigene Agenten-Logik (KI-Systeme, die mehrstufige Aufgaben mit Werkzeugzugriff selbstständig abarbeiten) und Integrationen in die eigene Systemlandschaft.

Das senkt die Einstiegshürde erheblich. Beseitigt sie aber nicht. Eine eigene KI-Lösung ist Software, und Software muss betrieben werden: Monitoring, Qualitätssicherung der Ausgaben, Modell-Wechsel wenn ein Anbieter eine Version abkündigt, Sicherheits-Updates. Wer „Build“ sagt, sagt auch „Betrieb“. Dieser Punkt wird in Entscheidungsvorlagen regelmäßig unterschätzt, weil das Proof-of-Concept-Stadium ihn noch nicht sichtbar macht. Ehrlich ist auch: Ein erheblicher Teil selbst gebauter KI-Lösungen scheitert nicht an der Technik, sondern an fehlender Pflege nach dem Go-live.

Kriterium 1: Differenzierungswert

Die erste und wichtigste Frage lautet: Ist dieser Anwendungsfall ein Wettbewerbsfaktor oder eine Commodity, also eine austauschbare Standardleistung?

Meeting-Zusammenfassungen, E-Mail-Entwürfe, Übersetzungen, Standard-Reports: Das sind Commodities. Sie werden dadurch nicht besser als Ihr Wettbewerb, Sie vermeiden nur, schlechter zu sein. Hier eigenzuentwickeln bindet Kapazität ohne Ertrag. Kaufen Sie.

Anders liegt der Fall, wenn die KI einen Prozess berührt, der Ihr Geschäft ausmacht: die Preisfindung eines Großhändlers, die Schadensbewertung eines Versicherers, die technische Auslegung eines Maschinenbauers. Hier steckt der Wert in Ihrem spezifischen Wissen, und genau das kann eine generische Plattform nicht abbilden. Eine brauchbare Faustregel: Wenn der Prozess in Ihrem Geschäftsbericht als Stärke vorkommen könnte, prüfen Sie Build. Wenn er in jeder Stellenbeschreibung jeder Branche stehen könnte, kaufen Sie.

Kriterium 2: Gesamtkosten statt Lizenzpreis

Der häufigste Fehler in Build-or-Buy-Kalkulationen ist der Vergleich von Lizenzkosten mit Entwicklungskosten. Beides sind nur Ausschnitte. Belastbar wird die Rechnung erst als Total Cost of Ownership (TCO), die Gesamtkosten über die Nutzungsdauer, typischerweise über drei bis fünf Jahre betrachtet.

Zwei Muster aus unserer Projekterfahrung. Bei Buy unterschätzen Unternehmen typischerweise die Einführungskosten. Eine Copilot-Lizenz entfaltet ohne aufgeräumte Datenbasis und sauberes Berechtigungskonzept wenig Wirkung. Bei Build werden typischerweise die laufenden Kosten unterschätzt, weil die Kalkulation beim Go-live endet. Als Größenordnung: Über die Lebensdauer einer selbst gebauten Lösung übersteigen Betrieb und Weiterentwicklung die initiale Entwicklung häufig deutlich.

Kriterium 3: Datenhoheit

Datenhoheit bezeichnet die tatsächliche Kontrolle darüber, wo Daten gespeichert, verarbeitet und von wem sie eingesehen werden können. Bei Plattform-KI verarbeitet der Anbieter Ihre Daten in seiner Infrastruktur, vertraglich geregelt, aber außerhalb Ihrer direkten Kontrolle. Die großen Anbieter bieten EU-Datenregionen und Auftragsverarbeitungsverträge. Für viele Anwendungsfälle reicht das.

Es gibt jedoch Konstellationen, in denen das nicht genügt: Gesundheitsdaten, Verschlusssachen, Konstruktionsdaten mit hohem Industriespionage-Risiko, oder Branchen mit Aufsichtsanforderungen, die eine Verarbeitung außerhalb der eigenen Infrastruktur faktisch ausschließen. Hier verschiebt sich die Abwägung Richtung Build, bis hin zum Betrieb eines Open-Source-Modells auf eigener Hardware, mit allen Konsequenzen für Kosten und Qualität. Selbst betriebene Modelle erreichen je nach Aufgabe nicht immer das Niveau der großen API-Modelle, und der Betrieb erfordert Spezialwissen.

Eine zweite, oft übersehene Dimension: Auch Zwischenergebnisse haben einen Wert. Wer jahrelang Prompts, Bewertungslogik und Korrekturdaten in eine Plattform einspeist, baut dort Wissen auf, das beim Ausstieg nicht mitkommt. Das führt direkt zum vierten Kriterium.

Kriterium 4: Exit-Kosten

Exit-Kosten sind alle Aufwände, die entstehen, wenn Sie eine Lösung wieder verlassen wollen: Datenmigration, Neuaufbau von Integrationen und Automatisierungen, Umschulung, Parallelbetrieb während des Übergangs. Sie sind das Maß für Vendor-Lock-in, also die Abhängigkeit von einem Anbieter, die einen Wechsel wirtschaftlich unattraktiv macht.

Bei KI-Plattformen entsteht Lock-in subtiler als bei klassischer Software, weil nicht nur Daten gebunden werden, sondern Arbeitsweisen: konfigurierte Agenten, eingeübte Prompts, plattformspezifische Erweiterungen. Stellen Sie deshalb vor der Einführung drei Fragen:

• In welchem Format kommen unsere Daten und Konfigurationen wieder heraus, und ist das vertraglich zugesichert?
• Was passiert mit unseren Prozessen, wenn der Anbieter die Funktion abkündigt oder den Preis substanziell erhöht?
• Wie tief verweben wir Erweiterungen mit proprietären Formaten, und gäbe es eine portablere Alternative?

Auch Build hat Exit-Kosten, etwa die Abhängigkeit von einem Modellanbieter oder von den Personen, die das System gebaut haben. Eine saubere Architektur hält die Modellanbindung austauschbar. Das ist eine Designentscheidung, die am Anfang wenig kostet und später viel wert ist.

Die Entscheidung in der Praxis: meist ein Sowohl-als-auch

Die vier Kriterien führen selten alle in dieselbe Richtung. Ein praktikables Vorgehen:

• Anwendungsfälle einzeln bewerten. Listen Sie die KI-Kandidaten auf und bewerten Sie jeden entlang der vier Kriterien, nicht das Unternehmen als Ganzes.
• Commodity-Fälle kaufen, schnell und diszipliniert. Hier zählt Time-to-Value, nicht Perfektion.
• Differenzierende Fälle prüfen, bevor gebaut wird. Ein begrenzter Pilot klärt, ob der erwartete Wert real ist, bevor Betriebskosten entstehen.
• Hybride Architekturen ernst nehmen. Häufig ist die beste Lösung eine eigene, schlanke Schicht, etwa eine Agenten-Logik mit eigenem Wissen, die Plattformsysteme anspricht, statt sie zu ersetzen.

Für diese Bewertung braucht es eine Rolle, die beide Welten beurteilen kann: Plattform-Fähigkeiten realistisch einschätzen und zugleich Aufwand und Risiken einer Eigenentwicklung beziffern. Genau das ist das Profil eines KI-Architekten, als externe, anbieterneutrale Kompetenz oft sinnvoller als eine Festanstellung, weil die Entscheidung punktuell ansteht, der Betrieb danach aber andere Profile braucht. Unklare Begriffe aus diesem Guide finden Sie im KI-Glossar erklärt.

Fazit

Build or Buy bei KI ist keine Glaubensfrage, sondern eine Portfolio-Entscheidung pro Anwendungsfall. Die Kurzform der Entscheidungslogik: Kaufen Sie Commodity-Funktionen über die Plattformen, die Sie ohnehin betreiben, und bauen Sie nur dort, wo Ihr spezifisches Wissen den Unterschied macht, Datenhoheit es erzwingt oder keine Plattform den Prozess abbildet. Rechnen Sie beide Wege als Gesamtkosten über mehrere Jahre, und prüfen Sie die Exit-Kosten vor der Einführung, nicht beim Ausstieg. Wenn Sie unsicher sind, wo ein konkreter Anwendungsfall steht: Eine anbieterneutrale Architektur-Bewertung ist deutlich günstiger als eine korrigierte Fehlentscheidung, in beide Richtungen.