KI: eigenes Modell, API oder fertiges Tool?

Make or Buy bei KI: drei Wege, ein Missverständnis

Wenn jemand sagt wir machen jetzt was mit KI, verbergen sich dahinter fast immer drei völlig verschiedene Vorhaben. Den Unterschied zu kennen, spart dir Monate und einen sechsstelligen Betrag. Der erste Weg: du kaufst ein fertiges Tool, das eine Aufgabe bereits löst, und meldest dich an. Der zweite: du baust deine eigene Software und bindest ein KI-Modell über eine API an, also über eine Schnittstelle zu einem Anbieter wie OpenAI, Anthropic oder Google. Der dritte: du trainierst oder feintunst ein eigenes Modell auf deinen Daten und betreibst es selbst.

Das Missverständnis steckt im Wort eigenes Modell. Viele meinen damit eigentlich Weg zwei, denken aber, sie bräuchten Weg drei. Die meisten Firmen, die KI sinnvoll im Produkt haben, trainieren gar nichts. Sie schicken einen Prompt an eine API und bekommen eine Antwort. Das eigene am Ergebnis ist die Software drumherum, nicht das Modell. Diese Unterscheidung trägt den ganzen Rest dieses Artikels.

Fertiges Tool: schnell live, wenig Kontrolle

Ein fertiges KI-Tool ist Software, die ein Anbieter gebaut, mit einem Modell verdrahtet und als Produkt verpackt hat. Du bezahlst pro Monat oder pro Nutzer und legst los. Beispiele kennst du: ein Schreibassistent, ein Support-Chatbot von der Stange, ein Transkriptionsdienst, ein KI-Feature direkt in deinem CRM. Für klar abgegrenzte Aufgaben, die nicht zu deinem Kern gehören, ist das oft die richtige Wahl.

Der Reiz liegt in der Geschwindigkeit. Heute anmelden, morgen produktiv. Du trägst kein Entwicklungsrisiko, kein Betriebsrisiko, und der Anbieter kümmert sich um Modell-Updates. Der Preis dafür ist Kontrolle. Du nimmst das Tool, wie es ist. Passt der Funktionsumfang zu 80 Prozent, lebst du mit den fehlenden 20. Willst du einen eigenen Schritt im Ablauf, ein eigenes Datenfeld, eine andere Logik, geht das meist nicht oder nur über Umwege.

Dazu kommt die Frage, wohin deine Daten fliessen. Bei einem fertigen Tool gibst du den Inhalt an einen Anbieter, dessen Vertragsbedingungen du akzeptierst und im Detail selten liest. Für interne Brainstormings unkritisch. Für Kundendaten, Verträge oder Gesundheitsinformationen musst du genau hinschauen, welcher Anbieter wo speichert und ob das mit deinen Pflichten zusammenpasst. Ein fertiges Tool ist eine Mietwohnung: schnell bezogen, aber die Wände gehören dir nicht.

Es gibt einen Punkt, an dem ein Tool zur Falle wird. Wenn die Funktion, die das Tool liefert, zu deinem Differenzierungskern gehört, machst du dich von einem Anbieter abhängig, der genau diese Funktion auch jedem Wettbewerber verkauft. Dann mietest du deinen Vorsprung. Mehr dazu, wie man sich aus solcher Abhängigkeit heraushält, steht in Vendor-Lock-in vermeiden.

Fremde API: dein Produkt, fremdes Modell

Der mittlere Weg ist für die meisten der eigentliche. Du baust deine eigene Anwendung und nutzt die Intelligenz eines grossen Modells über eine API. Dein Code formuliert die Anfrage, schickt sie an den Anbieter, bekommt die Antwort zurück und macht damit, was dein Produkt verlangt. Das Modell ist Zulieferer, das Produkt ist deins.

Dieser Weg verbindet zwei Dinge, die sich beim fertigen Tool ausschliessen: volle Kontrolle über Ablauf, Oberfläche und Datenhaltung auf der einen Seite, und ein Spitzenmodell ohne eigene Trainingsabteilung auf der anderen. Du entscheidest, was der Nutzer sieht, wie das Ergebnis weiterverarbeitet wird, welche Daten du speicherst und welche du nach dem Aufruf verwirfst. Du kannst zwischen Anbietern wechseln oder mehrere kombinieren, ohne dein Produkt neu zu bauen. Das Modell selbst musst du weder trainieren noch betreiben noch auf dem aktuellen Stand halten.

Die Kosten verstehst du am besten über die Treiber. Bezahlt wird meist pro Token, also grob pro Textmenge rein und raus. Lange Eingaben, ausführliche Antworten und stärkere Modelle kosten mehr. Wenige, kurze Anfragen pro Tag bleiben im Bereich, über den man nicht nachdenkt. Hunderttausende Aufrufe mit langem Kontext bewegen sich in einer ganz anderen Liga. Rechne mit deinem konkreten Volumen, nicht mit Bauchgefühl. Ein kurzes klassifizierendes Modell ist um Grössenordnungen günstiger als ein grosses, das ganze Dokumente verfasst, und oft reicht das kleine.

Zwei Eigenheiten solltest du einplanen. Erstens die Abhängigkeit von der Verfügbarkeit: fällt die API aus oder ändert der Anbieter Preise und Konditionen, betrifft dich das direkt. Deshalb baut man die Anbindung so, dass ein Wechsel möglich bleibt, statt sich tief in die Eigenheiten eines einzigen Anbieters zu verheddern. Zweitens der Datenschutz: auch hier verlassen Inhalte dein Haus. Seriöse Anbieter bieten Optionen, bei denen API-Daten nicht zum Training verwendet werden, und Standorte in der EU oder der Schweiz. Das gehört in die Bewertung, bevor der erste Produktivnutzer Daten eingibt. Wie Auth, Abrechnung und Compliance bei eigener Software zusammenhängen, behandelt Auth, Billing und Compliance im SaaS.

Eigenes Modell: wenn dir Kontrolle und Daten gehören müssen

Der dritte Weg bedeutet, ein Modell selbst zu trainieren oder ein offenes Modell auf deine Daten zu feintunen und auf eigener oder gemieteter Hardware zu betreiben. Hier liegt die volle Kontrolle bei dir. Kein Inhalt verlässt deine Infrastruktur, kein Anbieter ändert dir die Preise, und das Modell lernt genau die Muster deiner Domäne. Das klingt nach dem Ziel und ist für die meisten der teuerste Umweg.

Die Kosten verschieben sich grundlegend. Beim API-Weg zahlst du pro Nutzung, der Einstieg ist nahe null. Beim eigenen Modell zahlst du vorab und laufend: für die Aufbereitung sauberer Trainingsdaten, für Rechenleistung beim Training, für Fachleute, die das können, und danach für den Dauerbetrieb der Hardware, ob ausgelastet oder nicht. Du brauchst nicht nur einmal Geld, sondern ein Team, das das Modell pflegt, überwacht und neu trainiert, wenn sich die Welt ändert. Das ist kein Projekt mit Enddatum, sondern eine Betriebsverpflichtung. Was Dauerbetrieb wirklich heisst, steht in Was kostet der SaaS-Betrieb pro Monat.

Wir haben das selbst durchgespielt. Für ein internes Vorhaben haben wir auf einer DGX-Spark-Maschine mit lokalen Modellen gearbeitet, statt jeden Aufruf nach aussen zu geben. Die Erfahrung daraus: lokal zu betreiben ist machbar und bei sensiblen Daten ein echter Vorteil, aber der Aufwand für Einrichtung, Tuning und Betrieb ist nichts, was man nebenbei erledigt. Genau deshalb empfehlen wir Kunden den eigenen Weg nur, wenn die Gründe wirklich tragen.

Und die gibt es. Strenge Datenschutz- oder Regulierungslagen, bei denen Daten das Haus nicht verlassen dürfen. Ein Spezialgebiet, in dem allgemeine Modelle schlecht abschneiden und dein Datenschatz echten Vorsprung schafft. Ein Volumen, bei dem die nutzungsbasierten API-Kosten die Fixkosten eigener Hardware übersteigen. Trifft mindestens einer dieser Punkte hart zu, lohnt sich die Investition. Trifft keiner zu, baust du teuer nach, was du günstiger mieten könntest.

Die fünf Achsen im direkten Vergleich

Für die Entscheidung helfen fünf Achsen, an denen du jeden Weg misst. Kosten: Tool und API starten niedrig und laufen nutzungsabhängig, das eigene Modell verlangt hohe Vorab- und Fixkosten. Kontrolle: beim Tool gering, bei der API hoch über das Produkt herum, beim eigenen Modell vollständig bis ins Modell hinein. Datenschutz: beim Tool und der API verlassen Daten dein Haus, regelbar über Anbieterwahl und Vertrag; beim eigenen Modell bleiben sie drin. Aufwand: das Tool kostet fast keinen, die API einen mittleren über die Software, das eigene Modell einen hohen und dauerhaften. Differenzierung: das Tool gibt dir keine, weil es jeder kaufen kann; die API gibt sie dir über das Produkt drumherum; das eigene Modell zusätzlich über das Modell, falls deine Daten den Unterschied machen.

Lies die Liste nicht als Rangfolge, sondern als Profil. Es gibt keinen besten Weg, nur einen besten Weg für deinen Fall. Eine interne Notizhilfe ohne sensible Daten ruft nach dem Tool. Ein Produkt, dessen KI-Funktion den Kern bildet, ruft nach mindestens der API. Ein Modell, das auf vertraulichen Patientendaten arbeiten und im Haus bleiben muss, ruft nach dem dritten Weg, mit allem, was das an Betrieb bedeutet.

Warum die API fast immer der richtige Start ist

Für den Grossteil der Vorhaben empfehlen wir, mit der API zu beginnen, und das aus einem nüchternen Grund: sie hält dir die Optionen offen, zu den geringsten Kosten. Du baust dein Produkt, lernst am echten Nutzer, was die KI leisten muss, und zahlst nur für das, was du wirklich nutzt. Stellt sich heraus, dass ein fertiges Tool gereicht hätte, hast du wenig verloren. Stellt sich heraus, dass du ein eigenes Modell brauchst, weisst du jetzt aus Erfahrung, wofür genau, statt es vorab zu raten.

Der häufigste Fehler ist, mit Weg drei zu beginnen. Ein Team beschliesst, ein eigenes Modell sei strategisch, und verbrennt ein halbes Jahr und viel Geld an etwas, das eine API in zwei Wochen besser gekonnt hätte. Das eigene Modell ist eine Antwort auf einen bewiesenen Bedarf, kein Startpunkt. Beweise den Bedarf erst günstig, bevor du teuer investierst. Diese Make-or-Buy-Frage ist eng verwandt mit der Frage, ob man Standardsoftware anpasst oder selbst baut, ausführlich in Standard-Tool anpassen vs. eigenes bauen.

Genau hier liegt der Unterschied zwischen einem Berater, der ein Konzept abgibt, und jemandem, der mitbaut und mitbetreibt. Wir bei Wertstifter bauen und betreiben eigene Produkte, Wortfreunde und Reazon, mit KI-Anteilen darin. Wir kennen die laufenden Kosten, die Betriebslast und die Stellen, an denen ein eigenes Modell sich rechnet oder eben nicht, weil wir die Rechnung selbst jeden Monat sehen. Genau diese Verbindung aus Bauen und Betreiben steckt in unserer SaaS-Produktentwicklung.

Die Make-or-Buy-Frage bei KI ist am Ende keine Modellfrage, sondern eine Reihenfolgenfrage. Kauf, was nicht zu deinem Kern gehört. Bau über die API, was deins werden soll. Trainier selbst nur, was nachweislich beides verlangt, deine Daten und deine Kontrolle. Wer diese Reihenfolge hält, gibt sein Geld dort aus, wo es Vorsprung schafft, und nicht dort, wo es nur teuer aussieht.