+150 XP

Build, Buy oder Partner: den richtigen Weg zu Ihrer KI-Lösung wählen

# Build, Buy oder Partner: den richtigen Weg zu Ihrer KI-Lösung wählen

Das Operations-Team eines Tier-1-Automobilzulieferers hat zwei Vorschläge auf dem Tisch. Erstens: ein eigenes Demand-Forecasting-Modell entwickeln, trainiert auf 15 Jahren werksbezogener Versanddaten. Geschätzte Kosten: 400.000 bis 600.000 USD (Schätzung) und neun Monate. Zweitens: ein fertiges Forecasting-Modul lizenzieren, das sich an das bestehende MES (Manufacturing Execution System, die Software, die die Produktion in der Fertigung erfasst und steuert) anschließt. Geschätzte Kosten: 80.000 USD (Schätzung) pro Jahr, live in sechs Wochen.

Dasselbe Geschäftsproblem. Völlig unterschiedliche Tradeoffs bei Risiko, Geschwindigkeit und Kontrolle. Diese Lektion gibt Ihnen die Kriterien für diese Entscheidung.

Die drei Wege, definiert

Build: Ihr Team (intern oder beauftragt) entwickelt ein Modell von Grund auf, trainiert auf Ihren eigenen Daten, zugeschnitten auf Ihren Prozess.

Buy: Sie lizenzieren ein bestehendes KI-Produkt eines Anbieters, meist ein SaaS-Tool (Software as a Service), das sich in Ihr MES, ERP (Enterprise Resource Planning, das System für Finanzen, Bestände und Aufträge) oder Ihre PLC (Programmable Logic Controller, der Industrierechner mit der Maschinenlogik) integriert.

Partner: eine Mischform, Sie entwickeln gemeinsam mit einem Anbieter, Systemintegrator oder Ihrem Maschinenhersteller, oft mit gemeinsamer Nutzung von Daten und IP (geistiges Eigentum) auf Basis einer verhandelten Vereinbarung.

Keiner dieser Wege ist grundsätzlich besser. Die richtige Antwort hängt von fünf Faktoren ab.

Kriterium 1: Wie differenziert ist das Problem?

Wenn der KI-Use-Case Ihren zentralen Wettbewerbsvorteil berührt, ist Build (oder eine tiefe Partnerschaft) besser zu vertreten. Handelt es sich um ein verbreitetes operatives Problem, das die ganze Branche teilt, ist Buy meist klüger.

  • Buy-Territorium: Predictive Maintenance an Standard-CNC-Maschinen (Computer Numerical Control), Fehlererkennung an gängigen Schweißnahttypen, generisches Demand Forecasting.
  • Build-Territorium: ein proprietärer Legierungs-Aushärtungsprozess, den nur Ihr Werk fährt, ein Fehlerbild, das nur bei Ihrer Produktgeometrie auftritt, eine Planungsrestriktion, die an Ihre spezifischen Tarifvereinbarungen und Schichtregeln gebunden ist.

Siemens, Rockwell Automation und PTC verkaufen alle ausgereifte Predictive-Maintenance-Module, trainiert auf breiten Industriedatensätzen. Das von Null nachzubauen schlägt die Lizenzierung selten, es sei denn, Ihre Fehlermodi sind wirklich ungewöhnlich.

Kriterium 2: Datenreife und Eigentum

Maßgeschneiderte Modelle brauchen saubere, gelabelte, ausreichende historische Daten. Stellen Sie drei Fragen:

1. Haben wir mindestens 12 bis 24 Monate relevante, strukturierte Daten (für Zeitreihenprobleme wie Bedarf oder Wartung)?

2. Sind sie gelabelt (haben Sie für die Fehlererkennung tausende getaggte Bilder von "gut" vs. "defekt")?

3. Wem gehören die Daten und das resultierende Modell, uns oder dem Anbieter?

Ein häufiger Fehlschlag: Ein Werk kauft ein fertiges Computer-Vision-Tool zur Fehlerprüfung, aber das Modell des Anbieters wurde auf generischen Metallteilen trainiert, nicht auf den dunklen, reflektierenden Verbundoberflächen des Werks. Die Genauigkeit bricht deutlich ein, bis das Modell auf werksspezifischen Bildern neu trainiert wird, ein impliziter "Partner"-Schritt, der in der ursprünglichen Buy-Entscheidung nicht eingepreist war.

Kriterium 3: Integrationskomplexität

KI in der Fertigung steht selten für sich. Sie muss mit Legacy-MES, SCADA (Supervisory Control and Data Acquisition, Systeme zur Echtzeitüberwachung von Industrieanlagen) und jahrzehntealten PLCs sprechen, von denen einige Protokolle aus den 1990ern nutzen.

Ein vorintegriertes Tool zu kaufen (etwa das native Forecasting-Add-on eines MES-Anbieters) senkt das Integrationsrisiko deutlich. Build bedeutet, dass Ihr Team jede API-Verbindung (Application Programming Interface, die Schnittstelle, über die Softwaresysteme Daten austauschen), jede Data Pipeline und jeden künftigen Kompatibilitätsbruch verantwortet, wenn der MES-Anbieter ein Update ausrollt.

Ein nützlicher Bauchtest: Wenn das IT/OT-Team Ihres Werks (Information Technology / Operational Technology) kleiner als 5 Personen ist, sind tiefe Eigenentwicklungen langfristig meist zu riskant in der Wartung.

Kriterium 4: Speed to Value vs. langfristige Kosten

| Faktor | Buy | Build | Partner |

|---|---|---|---|

| Zeit bis zum ersten Nutzen | Wochen | Monate bis über ein Jahr | Monate |

| Anfangskosten | Niedriger | Höher | Mittel |

| Laufende Kosten | Abo-Gebühren, können sich über Jahre summieren | Internes Team, Infrastruktur, Wartung | Geteilt, verhandelt |

| Obergrenze der Anpassbarkeit | Begrenzt | Hoch | Mittel-hoch |

| Risiko Vendor-Lock-in | Höher | Keines | Mittel |

Ein einfacher Rechenvergleich (illustrativ, kein konkretes Anbieterangebot):

  • Buy: 80.000 USD/Jahr Lizenz, 5 Jahre = 400.000 USD, live in 6 Wochen.
  • Build: 500.000 USD einmalig + 100.000 USD/Jahr Wartung, 5 Jahre = 900.000 USD, live in 9 bis 12 Monaten.

Buy gewinnt hier bei den Kosten, es sei denn, das eigene Modell erzielt genug Zugewinn an Forecast-Genauigkeit (weniger Stockouts, weniger Überbestand), um die Differenz zu rechtfertigen. Das ist die eigentliche ROI-Frage (Return on Investment), nicht "was ist billiger zu bauen", sondern "was erzeugt über die nutzbare Lebensdauer des Modells mehr Wert pro Dollar".

Kriterium 5: Regulatorik und IP-Risiko

In der EU klassifiziert der EU AI Act (in Kraft seit 2024, mit stufenweisen Pflichten bis 2026-2027) manche industrielle KI als "hochriskant", etwa sicherheitskritische Qualitätskontrolle bei regulierten Produkten, was Pflichten zu Dokumentation, Risikomanagement und menschlicher Aufsicht auslöst. Der Kauf bei einem Anbieter, der Compliance-Dokumentation bereits in sein Produkt eingebaut hat, kann Ihre Compliance-Last senken. Bei Eigenentwicklung tragen Sie diese Compliance-Arbeit vollständig selbst.

In den USA gibt es bislang kein einheitliches Bundesgesetz zu KI (Stand Anfang 2026), aber sektorale Regeln gelten weiterhin, etwa die Aufsicht der FDA (Food and Drug Administration), wenn Sie Medizinprodukte herstellen, oder Anforderungen der OSHA (Occupational Safety and Health Administration) an Arbeitsschutzsysteme mit KI-gestützter Überwachung.

Auch IP ist relevant: Wenn Sie mit einem externen Dienstleister bauen, halten Sie im Vertrag fest, wem das trainierte Modell und die Trainingsdaten-Pipeline gehören. Unklarheit an dieser Stelle hat schon mehr als einem Hersteller die Möglichkeit genommen, seine eigene KI-Investition weiterzuverwenden oder zu vermarkten.

Wissenscheck

1. Ein Werksleiter entscheidet, wie er eine Predictive-Maintenance-Lösung für gängige, branchenübliche CNC-Maschinen beschaffen soll. Was ist nach dem Differenzierungskriterium der belastbarste Weg?

2. Warum nutzt die Lektion die beiden Angebote des Automobilzulieferers (maßgeschneidertes Modell vs. Off-the-shelf-Modul) als Einstiegsbeispiel?

3. Ein Werk hat eine Herausforderung bei der Fehlererkennung, die auf eine proprietäre Produktgeometrie zurückgeht, die kein anderer Hersteller verwendet. Welcher Weg ist nach dem Differenzierungskriterium am passendsten?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE korrekten Antworten zum „Partner“-Weg bei der KI-Beschaffung.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE korrekten Antworten dazu, wie Use Cases im „Buy-Territorium“ in der Lektion charakterisiert werden.

Wählen Sie alle richtigen Antworten aus.

Ein praktisches Entscheidungsframework

Schicken Sie Ihren Use Case durch diese Abfolge:

1. Ist das ein Commodity-Problem? (branchenweit verbreitet, gut durch bestehende Anbieter abgedeckt) → Buy.

2. Sind unsere Daten einzigartig, umfangreich und sauber genug, um etwas Besseres zu trainieren als das, was der Markt bietet? → Build oder Partner prüfen.

3. Haben wir das IT/OT-Team, um ein eigenes Modell über Jahre zu pflegen, nicht nur einmal zu bauen? → Falls nein, eher Buy oder Partner, selbst wenn Build technisch überlegen aussieht.

4. Berührt der Use Case einen regulierten oder sicherheitskritischen Prozess? → Gewichten Sie die Compliance-Reife des Anbieters stark; ein Anbieter mit vorhandener EU-AI-Act-Dokumentation spart Ihnen echte Zeit.

5. Wie sieht das realistische Payback-Fenster aus? → Wenn Buy sich in unter einem Jahr rechnet und Build drei Jahre braucht, gewinnt Buy fast immer, sofern nicht die Wettbewerbsdifferenzierung auf dem Spiel steht.

Bosch, Siemens und Schneider Electric bieten zunehmend "Partner"-Tracks an: Sie stellen die Plattform und die MLOps-Infrastruktur (Machine Learning Operations, die Praktiken für zuverlässiges Deployment und Wartung von ML-Modellen), Sie liefern werksspezifische Daten und das Domain-Tuning. Dieser Mittelweg wächst, weil er die Wartungslast teilt und dennoch Anpassung erlaubt, nützlich für mittelgroße Hersteller, die kein komplettes Data-Science-Team besetzen können, aber wirklich differenzierte Prozesse haben.

🎬 [VIDEO: "Build vs Buy: The Software Decision Every CTO Faces" - youtube.com - suchen Sie diesen Titel auf YouTube; eine praxisnahe Aufschlüsselung der Build-vs-Buy-Tradeoffs, die direkt auf Entscheidungen zu KI-Tooling in der Fertigung anwendbar ist]

Für eine tiefere Einführung speziell in die Bewertung von KI-Anbietern liefert das AI Risk Management Framework des NIST eine kostenlose, anbieterneutrale Checkliste, um Zuverlässigkeit, Transparenz und Risiko in jedem KI-System zu prüfen, das Sie kaufen oder bauen wollen.

Key Takeaways

  • Setzen Sie bei Commodity-Problemen standardmäßig auf Buy (Standard-Predictive-Maintenance, generische Fehlererkennung); reservieren Sie Build für wirklich proprietäre Prozesse, in denen fertige Tools schlecht abschneiden.
  • Datenreife entscheidet mehr als Ambition: Kein Budget der Welt repariert 12 Monate unsaubere, nicht gelabelte Daten.
  • Integration und die Personaldecke im IT/OT-Bereich sind oft die eigentliche Restriktion, nicht die theoretische Genauigkeit des Modells.
  • Vergleichen Sie die Gesamtkosten über die realistische Nutzungsdauer des Modells (3 bis 5 Jahre), nicht nur den Anfangspreis, und wägen Sie das gegen den echten ROI aus Forecast-Genauigkeit, weniger Downtime oder besserer Fehlererkennung ab.
  • Prüfen Sie regulatorische Risiken früh: Pflichten aus dem EU AI Act und sektorale Regeln (FDA, OSHA) können die Buy/Build-Rechnung verschieben, weil sie Compliance-Arbeit hinzufügen, die Anbieter möglicherweise schon gelöst haben.