KI-API vs. Eigenentwicklung.

Bei jeder zweiten KI-Konferenz wird Geschäftsführern mittelständischer Unternehmen erzählt, sie müssten „eigene KI-Modelle“ entwickeln, sonst würden sie abgehängt. An anderer Stelle hört man, dass Eigenentwicklung pure Geldverbrennung sei und man besser einfach eine OpenAI-API anbindet. Beide Aussagen sind unvollständig — und beide führen, je nach Kontext, in die Irre. Die ehrliche Frage lautet nicht „Kaufen oder selbst bauen“, sondern „Was genau wird gekauft, was selbst gebaut, was zusammengefügt“. Zwischen einer reinen API-Anbindung und einem trainierten Eigenmodell liegen mindestens vier weitere Stufen — und für die meisten mittelständischen Anwendungsfälle ist genau eine dieser Zwischenstufen die richtige Wahl. Dieser Artikel zerlegt die Optionen, rechnet sie durch und gibt eine Entscheidungslandkarte, die ohne sechsstelliges ML-Budget funktioniert.

Was „Eigenentwicklung“ heute überhaupt bedeutet.

Vor fünf Jahren bedeutete „eigene KI bauen“ in der Regel: ein Team aus ML-Ingenieuren, ein Trainingsdatensatz mit zehntausenden Beispielen, Wochen oder Monate Trainingszeit auf GPU-Clustern, hohe Investitionssummen. Diese Form der Eigenentwicklung ist im Mittelstand nach wie vor selten sinnvoll und meist nicht leistbar.

Heute meint „Eigenentwicklung“ etwas anderes. Es bedeutet meistens: Auf einem vortrainierten Basismodell (OpenAI GPT, Anthropic Claude, Mistral, Llama, Aleph Alpha) eine spezifische Anwendung aufbauen. Das eigentliche Sprachmodell wird nicht trainiert — es wird gekauft oder open-source genutzt. Eigenentwicklung beschränkt sich auf: die Integration, das Prompting, die Anbindung an unternehmenseigene Daten (RAG), gegebenenfalls ein leichtes Fine-Tuning, die Benutzeroberfläche und den Workflow.

Diese Form der Eigenentwicklung ist für mittelständische Unternehmen erreichbar. Sie verlangt keine ML-Forschungsabteilung, sondern erfahrene Software-Ingenieure mit KI-Verständnis. Die Investitionssumme liegt typischerweise zwischen 50.000 und 400.000 Euro pro Anwendung — eine Größenordnung, die im Mittelstand realistisch ist, wenn der Use Case relevant genug ist.

Die sechs Stufen zwischen pur Kaufen und pur Selbstbauen.

Zwischen „ChatGPT-Abo“ und „eigenes Modell trainieren“ liegt ein Spektrum. Sechs Stufen lassen sich praktisch unterscheiden:

1. Standard-Web-Tools. ChatGPT Plus, Claude Pro für Mitarbeitende. Keine Integration, keine eigenen Daten. Kosten: 20 bis 30 Euro pro Mitarbeiter und Monat.
2. API-Anbindung an bestehende Anwendungen. CRM, ERP oder eine eigene Webseite bekommen einen KI-Knopf, der eine Standard-API aufruft. Kosten: 20.000 bis 80.000 Euro Initialaufwand plus laufende API-Kosten.
3. Custom GPT / Assistant. Ein konfigurierter Assistent mit eigenen Anweisungen und kleiner Dokumentenbasis. Verfügbar bei OpenAI, Anthropic, Microsoft Copilot Studio. Kosten: 5.000 bis 30.000 Euro plus laufende Kosten.
4. RAG-System auf eigenen Dokumenten. Ein eigener Index der Unternehmensdaten, an den ein API-Modell zugreift. Kosten: 50.000 bis 200.000 Euro Initialaufwand.
5. Fine-Tuning eines Basismodells. Ein Basismodell wird auf unternehmensspezifische Aufgaben nachtrainiert. Kosten: 80.000 bis 400.000 Euro Initialaufwand plus erhebliche laufende Kosten.
6. Eigenes Modell trainieren. Selten sinnvoll im Mittelstand. Kosten: ab 1 Million Euro, oft deutlich mehr.

Die meisten Mittelständler landen bei Stufe 2 bis 4. Wer ohne genaue Analyse direkt zu Stufe 5 oder 6 greift, riskiert eine Fehlinvestition. Wer dauerhaft bei Stufe 1 bleibt, lässt strategische Hebel ungenutzt.

Wann reine API-Anbindung reicht.

Für viele Anwendungsfälle ist eine reine API-Anbindung (Stufe 2) die richtige Wahl. Sie ist schnell aufgebaut, kalkulierbar, und sie nutzt das beste verfügbare Modell des jeweiligen Anbieters — ohne dass das Unternehmen Modellpflege oder Training übernehmen muss.

Typische Fälle: Eine Vertriebsmitarbeiterin bekommt im CRM einen Knopf „Anschreiben formulieren“. Eine Service-Mitarbeiterin bekommt im Ticketsystem einen Vorschlag für die Antwort. Eine Marketingleitung bekommt im CMS einen Vorschlag für eine Produktbeschreibung. In all diesen Fällen ist die KI ein Werkzeug an einer bestimmten Stelle, der Workflow ist klar definiert, die Datensensitivität ist niedrig bis mittel.

Was hier nicht Eigenentwicklung ist: Das Modell, das Trainingsmaterial, die Inferenz-Infrastruktur. Was eigenentwickelt wird: Die Integration in die bestehende Software, das spezifische Prompting, gegebenenfalls eine kleine Logik zur Vorverarbeitung. Das ist Eigenentwicklung im pragmatischen Sinn — und es ist meist die wirtschaftlichste Wahl für klar abgegrenzte Anwendungsfälle ohne hochsensible Daten.

Wann RAG der richtige Ansatz ist.

Sobald eigene Unternehmensdaten in die KI-Antworten einfließen sollen — Produktinformationen, Verträge, interne Dokumentation, Kundendaten —, kommen reine API-Aufrufe an Grenzen. Hier setzt RAG (Retrieval Augmented Generation) an. Die Idee: Bevor das Sprachmodell antwortet, wird die relevante Information aus einer eigenen Datenbank gesucht und mit in den Prompt gegeben. Das Modell „weiß“ also nicht nur Allgemeines, sondern auch das Spezifische des Unternehmens.

RAG ist die meistunterschätzte Option im Mittelstand. Sie verlangt keine teure Modell-Anpassung, sondern sauber strukturierte Daten und eine gute Architektur. Die Initialinvestition liegt bei realistischen Use Cases zwischen 60.000 und 180.000 Euro — laufende Kosten setzen sich aus Cloud-Speicher, API-Aufrufen und gelegentlicher Pflege zusammen.

Typische RAG-Anwendungen: Ein Chatbot, der Fragen zur eigenen Produktpalette beantwortet. Ein interner Assistent, der Vertragsklauseln aus der eigenen Vertragsbibliothek findet. Eine Suchschnittstelle für die unternehmensspezifische Dokumentation. In diesen Fällen ist RAG dem Fine-Tuning fast immer überlegen — billiger, schneller, leichter zu aktualisieren.

Wann Fine-Tuning sich rechnet — und wann nicht.

Fine-Tuning bedeutet, ein vortrainiertes Modell auf eigenen Beispielen weiter zu trainieren. Das Ergebnis: Das Modell „versteht“ die eigene Sprache, den eigenen Stil, die eigene Domäne besser. Das klingt mächtig — und ist in den meisten Mittelstands-Konstellationen die falsche Wahl.

Fine-Tuning rechnet sich konkret in drei Konstellationen. Erstens: Wenn ein bestimmter Anwendungsfall extrem hohes Volumen hat (Millionen Anfragen pro Monat) und Fine-Tuning die Kosten pro Anfrage messbar senkt. Zweitens: Wenn die eigene Domäne so spezifisch ist, dass auch das beste Basismodell mit RAG-Unterstützung qualitativ nicht ausreicht — etwa bei sehr seltener Fachsprache. Drittens: Wenn ein bestimmtes Verhalten (Tonalität, Format, Konsistenz) systematisch erzwungen werden muss und Prompting allein nicht zuverlässig genug ist.

In allen anderen Fällen ist RAG der bessere Weg. Fine-Tuning ist teurer, weniger flexibel (jede Datenänderung erfordert erneutes Training), schwerer zu warten und für die meisten Anwendungen schlichtweg überdimensioniert. Wer ein „Fine-Tuning-Projekt“ vorgeschlagen bekommt, sollte die Frage stellen: Warum nicht RAG? Wenn die Antwort darauf nicht überzeugend ist, ist das Projekt zu hinterfragen.

Make-or-Buy: die Rolle des Dienstleisters.

Die Frage „API oder Eigenentwicklung“ verschränkt sich mit der Frage „mit eigenen Leuten oder mit Dienstleister“. Beide Achsen sind unabhängig: Eine API kann durch externe Dienstleister angebunden werden, eine RAG-Lösung kann intern gebaut werden, ein Fine-Tuning kann eingekauft sein.

Für die meisten mittelständischen Unternehmen sieht die optimale Aufstellung so aus: Ein erfahrener Dienstleister baut die Erstversion (Architektur, Integration, initialer Prompt- und Datenbestand). Eigene IT-Mitarbeitende — gerne in Reverse-Mentoring mit dem Dienstleister — übernehmen die laufende Pflege. Inhaltliche Verantwortung (welche Daten sollen rein, welche Tonalität, welche Use Cases) bleibt bei den Fachabteilungen.

Was nicht funktioniert: Komplette Abhängigkeit vom Dienstleister, ohne eigenes Verständnis. Wer den Dienstleister jedes Mal beauftragen muss, wenn ein neuer Anwendungsfall hinzukommt oder die Datenbasis aktualisiert wird, baut eine teure Dauerabhängigkeit. Ebenso scheitert die rein interne Eigenentwicklung, wenn das Unternehmen das nötige KI-Know-how nicht zur Verfügung hat. Die Mischung ist meist die richtige Antwort — und sie sollte von Anfang an so geplant sein.

Eine realistische Kostenrechnung — mit Beispielzahlen.

Ein konkretes Beispiel: Ein mittelständischer Maschinenbauer mit 250 Mitarbeitenden will einen KI-gestützten Assistenten für seine Service-Mitarbeitenden, der Fragen aus der eigenen Service-Dokumentation und Vergangenheitsfällen beantwortet.

Option A — reine API mit ChatGPT-Plus für alle Service-Mitarbeitenden (30 Personen): Jahreskosten 11.000 Euro. Limitation: Kein Zugriff auf eigene Daten, hohe Halluzinationsgefahr bei spezifischen Fragen.

Option B — RAG-Lösung mit interner Service-Datenbank: Initialinvestition 120.000 Euro (Dienstleister), jährliche Betriebskosten 35.000 Euro (Cloud-Infrastruktur, Pflege, API-Kosten). Drei Jahre Total Cost: 225.000 Euro. Erwartete Effizienzgewinn: 20 bis 30 Prozent der Service-Mitarbeiterzeit, also etwa sechs bis neun Vollzeitäquivalente an Kapazität.

Option C — Fine-Tuning: Initialinvestition 280.000 Euro, jährliche Kosten 80.000 Euro, jährliches Re-Training nötig (40.000 Euro). Drei Jahre Total Cost: 520.000 Euro. Qualitätsvorteil gegenüber Option B: meist marginal, in vielen Fällen sogar schlechter wegen geringerer Flexibilität.

Die Rechnung zeigt: In diesem Beispiel ist Option B (RAG) die mit Abstand wirtschaftlichste Wahl. Option A reicht nicht, Option C lohnt sich nicht. Diese Logik gilt für die meisten mittelständischen Anwendungsfälle — die Versuchung, zu viel Eigenentwicklung zu betreiben, ist real und teuer.

Was Sie als Geschäftsführung konkret entscheiden sollten.

Drei Schritte, die in der Praxis zu fundierten Entscheidungen führen:

1. Anwendungsfall klar definieren. Welches Problem soll konkret gelöst werden, mit welchem Volumen, mit welcher Qualität? Ohne diese Definition ist jede Make-or-Buy-Diskussion Spekulation.
2. Die Stufe-Frage stellen. Welche der sechs Stufen (von Web-Tool bis Eigenmodell) ist die niedrigste, die das Problem ausreichend löst? Höher als nötig zu greifen ist teuer und langsam.
3. Mit Pilot beginnen. Bei größeren Investitionen (Stufe 4 und höher) immer mit einem schmalen Piloten starten — ein Anwendungsfall, drei Monate, klare Erfolgskriterien. Erst nach erfolgreichem Pilot in die Breite gehen.

Die Versuchung im Markt ist groß, mittelständischen Unternehmen Eigenentwicklung zu verkaufen, die sie nicht brauchen. Ein erfahrener Berater wird Ihnen tendenziell zur niedrigeren Stufe raten, weil dort das Risiko geringer und der ROI verlässlicher ist. Wer Ihnen direkt Fine-Tuning oder gar ein eigenes Modell empfiehlt, ohne zuvor RAG zu erwägen, hat entweder eine ungewöhnliche Konstellation vor sich — oder ein anderes Interesse. Die grundlegende Make-or-Buy-Entscheidung ist ein guter Ausgangspunkt für jede tiefere Architekturdiskussion.

Sie wollen für einen konkreten KI-Anwendungsfall die richtige Mischung aus API-Nutzung und Eigenentwicklung finden? Unverbindlich anfragen — wir schauen gemeinsam auf den Use Case, die realistische Stufe und ein tragfähiges Kostenmodell.