Die erste Frage, die die meisten Geschäftsführer bei Enterprise-KI stellen: „Sollten wir eigene Modelle bauen?" Es ist die falsche Frage. Die richtige lautet: „Wo liegt unser Wettbewerbsvorteil tatsächlich — im Modell oder im Workflow?"

Für die große Mehrheit der DACH-Mittelständler ist die Antwort eindeutig. Das Modell ist ein Standardprodukt. Die Workflow-Integration ist das Asset. Und trotzdem verbringen erstaunlich viele Organisationen sechs bis zwölf Monate und €200.000+ mit dem Bau eigener Modelle, obwohl sie in acht Wochen mit einem kommerziellen Modell und maßgeschneiderter Integration in Produktion sein könnten.

Das Build-vs-Buy-Framing ist überholt

Die klassische Build-vs-Buy-Entscheidung geht davon aus, dass man zwischen zwei vergleichbaren Wegen zum selben Ergebnis wählt. Eigenentwicklung dauert länger und kostet mehr, dafür besitzt man das Ergebnis. Zukauf ist schneller und günstiger, dafür besteht Abhängigkeit.

Für Enterprise-KI in 2026 verfehlt dieses Framing den Punkt vollständig. Der „Build" ist nicht eine Sache — er besteht aus drei Komponenten:

  1. Das Modell — die KI, die Klassifikation, Generierung, Extraktion oder Prognose durchführt
  2. Die Integration — wie das Modell mit Ihren Daten, Prozessen und Systemen verbunden wird
  3. Das Betriebsmodell — wie Menschen und KI im veränderten Workflow zusammenarbeiten

Die meisten Unternehmen, die „bauen", bauen alle drei von Grund auf. Die meisten Unternehmen, die erfolgreich in Produktion gehen, haben Komponente eins gekauft und Komponenten zwei und drei gebaut.

Warum Custom-Modelle für den Mittelstand selten sinnvoll sind

Custom-Modellentwicklung — das Feintuning von Foundation Models auf proprietären Daten oder das Training von Modellen von Grund auf — hat einen spezifischen und engen Anwendungsbereich, in dem sie gerechtfertigt ist:

  • Sie verfügen über einen genuinen proprietären Datensatz, der Wettbewerbsvorteil schafft (selten)
  • Kommerzielle Modelle erreichen die nötige Genauigkeit für Ihre Domäne nicht (zunehmend selten)
  • Regulatorische Anforderungen erzwingen, dass Modelle on-premise trainiert und gehostet werden (manchmal zutreffend, oft übertrieben dargestellt)

Für einen Industriezulieferer mit €50 Mio. Umsatz, der seinen ersten KI-Workflow ausrollt — etwa die Klassifizierung eingehender Aufträge nach Produktkategorie und Dringlichkeit — trifft keine dieser Bedingungen zu. Ein kommerzielles Sprachmodell mit gut entworfenen Prompts und sauberer Integration wird ein Custom-Modell übertreffen, das sechs Monate Training brauchte, weil es schneller in Produktion kommt, schneller iteriert und einen Bruchteil kostet.

Die Zahlen sind deutlich:

  • Custom-Modell: €100.000–500.000, 6–12 Monate bis Produktion, laufende Retraining-Kosten
  • Kommerzielles Modell mit Custom-Integration: €20.000–80.000, 6–12 Wochen bis Produktion, API-Kosten, die mit Nutzung skalieren

Die Kostendifferenz ist erheblich, aber die Zeitdifferenz ist entscheidend. In der Zeit, die der Bau eines Custom-Modells beansprucht, kann ein Unternehmen mit kommerziellen Modellen drei bis vier Produktiv-Workflows ausrollen, aus realem Einsatz lernen und die operative Fähigkeit für Level-2-Integration aufbauen.

Wo der echte Wert steckt

Der Wert bei Enterprise-KI liegt fast nie im Modell. Er liegt an drei Stellen:

Workflow-Design. Welcher Prozess bekommt KI? Wie ist er abgegrenzt? Was ist ein guter Output? Diese Entscheidungen bestimmen 80 % des ROI. Stimmt der Workflow nicht, rettet kein Modell — weder custom noch kommerziell — die Initiative.

Datenintegration. Die richtigen Daten zum Modell und den Output des Modells zurück in Ihre Systeme zu bringen, ist das schwierige Engineering-Problem. Das ist spezifisch für Ihre Organisation: Ihr ERP, Ihr Dokumentenmanagement, Ihre Freigabe-Workflows, Ihre Compliance-Anforderungen. Kein Anbieter kann das für Sie tun. Hier bauen Sie.

Betriebsmodell. Wie arbeitet das Team mit KI-Output? Was wird automatisch freigegeben? Was bekommt eine menschliche Prüfung? Wie werden Ausnahmen behandelt? Das ist Organisationsdesign, nicht Technologie — und es bestimmt, ob das Deployment Bestand hat oder innerhalb von 60 Tagen aufgegeben wird.

Custom-Modelltraining ist nichts davon. Es ist eine Technologieinvestition, die ein Problem löst, das die meisten Mittelständler nicht haben.

Die Integrationsschicht ist Ihr Burggraben

Wenn Sie akzeptieren, dass das Modell ein Standardprodukt ist — und für die meisten Use Cases ist es das —, dann kommt Ihr Wettbewerbsvorteil daher, wie gut Sie es in Ihre spezifischen Workflows integrieren, mit Ihren spezifischen Daten, unter Ihren spezifischen Compliance-Anforderungen.

Diese Integrationsschicht ist inhärent individuell. Keine zwei Organisationen haben dieselbe ERP-Konfiguration, dieselben Freigabeprozesse oder dieselben Compliance-Anforderungen. Diese Schicht gut zu bauen erfordert tiefes Verständnis des Workflows, der Datenlandschaft und des Betriebsmodells. Es ist die Art von Arbeit, für die das Accelerator-Engagement konzipiert wurde.

Wann „bauen" doch Sinn ergibt

Es gibt legitime Szenarien für Custom-Modellentwicklung:

Hochspezialisierte Domänen. Ein Medizintechnikhersteller, der Defekttypen aus Mikroskopbildern klassifiziert, braucht möglicherweise tatsächlich ein Custom-Vision-Modell, trainiert auf proprietären Defektdaten.

Performancekritische Anwendungen. Wenn der Unterschied zwischen 94 % und 98 % Genauigkeit erheblichen finanziellen Impact hat — etwa bei Betrugserkennung im Zahlungsverkehr —, kann Custom-Modelltraining auf proprietären Transaktionsdaten die Investition rechtfertigen.

Regulatorische Vorgaben. Manche Branchen und manche Auslegungen des EU AI Act verlangen, dass Modelle on-premise gehostet werden mit voller Auditierbarkeit der Trainingsdaten.

Selbst in diesen Szenarien empfiehlt die KI-Betriebssystem-Methodik: Starten Sie mit einem kommerziellen Modell, beweisen Sie, dass der Workflow funktioniert, und investieren Sie dann in ein Custom-Modell, wenn der bewiesene Workflow es verlangt. Erst Wert beweisen, dann optimieren.

Ein Entscheidungsrahmen

Stellen Sie für jede KI-Initiative diese vier Fragen in dieser Reihenfolge:

  1. Kann ein kommerzielles Modell ausreichende Genauigkeit für diesen Workflow erreichen? Testen Sie es. Die meisten Organisationen nehmen an, dass sie Custom-Modelle brauchen, ohne kommerzielle Alternativen zu testen.

  2. Ist der Time-to-Production-Unterschied relevant? Wenn ein Custom-Modell 9 Monate und ein kommerzielles 9 Wochen braucht — was kosten die 7 Monate Verzögerung? Rechnen Sie die Kosten des verzögerten operativen Hebels ein.

  3. Wo ist Ihre Engineering-Kapazität besser eingesetzt? Jede Stunde, die in Modelltraining fließt, fehlt bei Workflow-Integration, Datenpipelines und Betriebsmodell-Design — den Dingen, die tatsächlich über Erfolg oder Scheitern des Deployments entscheiden.

  4. Wie hoch sind die Wechselkosten, wenn Sie kommerziell starten? Fast immer niedrig. Gut entworfene Integrationen abstrahieren das Modell hinter einer Schnittstelle. Der Wechsel von einem kommerziellen Modell zu einem anderen — oder von kommerziell zu custom — ist eine Angelegenheit von Wochen, kein monatelanger Umbau.

Der Mittelstands-Vorteil

Die typischen Mittelstands-Constraints — begrenzte KI-Talente, pragmatische Budgets, schnelle Entscheidungswege — sind in der Build-vs-Buy-Frage tatsächlich ein Vorteil. Unternehmen, die sich kein neunmonatiges Custom-Modell-Projekt leisten können, werden in den schnelleren, pragmatischeren Pfad gezwungen: Modelle kaufen, Integration bauen, in Produktion gehen, aus realem Einsatz lernen.

Dieser Pfad erzeugt mehr operativen Hebel pro investiertem Euro als der Custom-Modell-Pfad. Und er baut die organisatorische Fähigkeit auf — die sechs Dimensionen —, die Level 2 und Level 3 erreichbar macht.

Wenn Sie evaluieren, ob Ihre nächste KI-Initiative bauen, kaufen oder — am wahrscheinlichsten — beides in den richtigen Proportionen tun sollte, buchen Sie ein Erstgespräch. Kein Pitch Deck, nur eine ehrliche Einschätzung Ihrer spezifischen Situation.

Zur Auswahl der richtigen Modelle, Plattformen und Partner ohne Lock-in siehe KI-Vendor-Auswahl. Für den breiteren operativen Kontext siehe KI im Betrieb.

Dieser Artikel ist Teil der Reihe KI im Betrieb von Andreas Anding. Für die vollständige Methodik siehe Das KI-Betriebssystem.