Viele Build-vs-Buy-Diskussionen heute drehen sich um generative Modelle, Agenten und ML-getriebene Qualitätssicherung. Hier kippt Buy besonders schnell ins Risiko, weil:

  • Daten die IP sind: Trainings-, Validierungs- und Produktionsdaten sind der Wettbewerbsvorteil. Externe Trainings- oder Prompt-Telemetrie sind Gift.
  • Modelle Governance brauchen: Ohne Evals, Red-Teaming, Rollbacks und klare Policies entsteht Wildwuchs.
  • Edge-Fähigkeit zählt: Inferenz muss oft offline, latenzarm und ressourcenschonend funktionieren.

Bewährte Muster:

  • Modellstrategie: Kleine bis mittelgroße Modelle, die on-prem performant laufen (quantisiert, passende Runtimes), statt Cloud-großer Blackboxes. Fine-Tuning/Adapter lokal, Trainingsdaten bleiben unter eigener Kontrolle.
  • Evals vor Hype: Domänenspezifische Evaluation-Suites mit Golden Sets und Scenario-basierter Prüfung schlagen „Benchmarks von außen“.
  • Agenten unter Aufsicht: Entscheidungsgraphen, Tools und Datenzugriffe sind politikenbasiert und auditiert. Aktionen sind nachvollziehbar, rücknehmbar und mit Freigaben koppelbar (Human-in-the-Loop, wenn irreversibel).
  • ML-Ops on-prem: Data Version Control, Feature Stores, Modell-Registries, Pipelines – alles in der eigenen Infrastruktur. Updates sind batched, signiert und trackbar.

Wir betreiben für LLM-Agenten Observability und Governance on-prem, weil sonst gerade in industriellen Workflows (z. B. Dokumentverarbeitung mit Personenbezug, Fertigungsdaten mit IP-Relevanz) keine Freigabe erteilt wird. Das umfasst:

  • Telemetrie, die nie das Unternehmen verlässt.

  • Eval- und Red-Teaming-Harnesses, die fachliche Risiken messen.

  • Policy-Enforcement und Rollbacks, um Fehlverhalten schnell einzufangen.

Praxisbeispiele, wo Build Pflicht ist

  • Fertigung: Visuelle Qualitätsprüfung. Off-the-shelf-Modelle scheitern an variierenden Lichtverhältnissen, Linsen, Materialien. Erfolgreich ist eine Pipeline, die Domänenaugmentation, robuste Vorverarbeitung, hardwareangepasste Inferenz (CPU/GPU/Edge-TPU) und einen sauberen Nachbearbeitungspfad kombiniert – alles nachvollziehbar versioniert.
  • Defense-nahe Kommunikation: Systeme müssen ohne externen Zugriff laufen, mit restriktiver Netzpolitik und nachvollziehbarer Protokollierung. „Schnelle“ Cloud-Lösungen fallen im Security-Review durch.
  • Bahn-Fahrzeugflotten: Integration in heterogene Telematik, Legacy-Protokolle und wechselnde Netzverfügbarkeit. Build-orientierte Gateways, Pufferung, asynchrone Analysen und vorhersehbare Degradationsmodi sind Pflicht.

Gegenargument: „Aber Buy bringt schnell Wert“

Stimmt kurzfristig oft – sofern die Randbedingungen weich sind. Drei Anti-Pattern, die ich immer wieder sehe:

  • Proof-of-Concept in Sandbox-Cloud, der in der Realität nicht deploybar ist (Daten dürfen nicht raus, Latenz passt nicht, kein Single-Tenant verfügbar).
  • Konfiguration statt Architektur: Man „klickt“ einen Prozess zusammen, der nicht zum wirklichen Workflow passt, und zahlt später mit irreparabler Komplexität.
  • Verdeckte Integrationskosten: Die eigentliche Arbeit – Datenqualität, Schnittstellenhärtung, Betriebsprozesse – bleibt und verteuert sich, weil das Produkt den eigenen Rahmen nicht unterstützt.

Ein konstruktiver Mittelweg ist „Buy to Build“: Man kauft Bausteine (Runtimes, Datenbanken, Message-Broker, UI-Frameworks), nicht komplette Monolithen. So bleiben Architektur und Datenhoheit in der eigenen Hand, während man nicht jedes Rad neu erfindet.

Kosten- und Risikobetrachtung ohne Augenwischerei

Build heißt nicht „billig“. Aber Buy ist selten so günstig, wie Folien versprechen. Worauf ich in Kalkulationen achte:

  • TCO statt Lizenzlinie: Betrieb, Updates, Integrationen, Schulungen, Downtime-Kosten, Auditaufwände.
  • Exit-Kosten: Was kostet es, in drei Jahren zu wechseln? Bei eigenem Code ist es Migrationsaufwand; bei Buy oft Daten- und Prozess-Gefangenschaft.
  • Sicherheitskosten: Wer haftet im Vorfall? Wie schnell schließen wir Lücken ohne Vendor-Wartezeit? Wie auditieren wir die Supply Chain?
  • Time-to-Value vs. Time-to-Regret: Ein schneller PoC, der später blockiert, ist teurer als ein fokussierter Build-Ansatz, der regulatorisch tragfähig ist.

Design für den Betrieb: On-Prem ohne Kopfweh

Die größten Schmerzen entstehen im Betrieb. Ein on-prem-fähiges System braucht genauso viel Liebe in der Betriebsarchitektur wie im Code:

  • GitOps und reproduzierbare Deployments: Declarative Manifeste, signierte Artefakte, Promotions über Stufen (Dev/Test/Prod) – auch air-gapped via portable Registries.
  • Observability lokal: Metriken, Logs, Traces mit Retention und Alarmierung, die zum Schichtbetrieb passen. Keine externen Abhängigkeiten.
  • Secrets- und Identity-Management: Eigene PKI, kurzlebige Tokens, feingranulare Rollen. Service-Konten mit Least Privilege.
  • Updates als Ereignis, nicht als Nebensache: Wartungsfenster, Rollbacks, Kompatibilitätsmatrizen, Dark Launch/Shadow Mode vor Freigabe.
  • Testpyramide für ML/AI: Unit/Property-Tests für Vor- und Nachverarbeitung, Regressions- und Golden-Dataset-Tests für Modelle, End-to-End mit synthetischen Störungen (Paketverlust, Uhrzeitdrift, Sensorfehler).

Legacy-Migration ohne Stillstand

Viele Build-Projekte sind in Wahrheit Migrationsprojekte. Erfolgsfaktoren:

  • Strangler-Fig-Ansatz: Neue Komponenten kapseln Altlasten und übernehmen Funktionalität schrittweise.
  • Side-by-Side-Betrieb: Shadow-Modus mit Live-Daten, fachliche Validierung, kontrollierte Umschaltung pro Linie/Standort.
  • Vertragliche Stabilität: Vor Umschnitt stabile, getestete Schnittstellen schaffen – erst dann Altlasten ablösen.
  • Datenhygiene vor ML: Bevor ein Modell Wunder wirken soll, müssen Dubletten, inkonsistente Kodierungen und fehlende Historie bereinigt werden.

Konkrete Entscheidungscheckliste

Wenn Sie vor Build vs. Buy stehen, beantworten Sie für Ihr Vorhaben:

  • Dürfen Daten, Logs, Modelle das Unternehmen verlassen? Wenn nein, erübrigen sich 80% der SaaS-Optionen.
  • Welche Latenz-/Verfügbarkeitsziele gelten im Fehlerfall? Was ist der definierte Degradationsmodus?
  • Welche Zertifizierungs-/Audit-Anforderungen bestehen? Können Sie Toolchain, Artefakte und Betriebsprozesse mit dem Produkt nachweisen?
  • Wie sieht das Threat Model aus? Welche externen Telemetrien, Updatekanäle, Supportzugänge sind akzeptabel?
  • Wer trägt das Technical Ownership? Gibt es ein Team, das langfristig Architektur, Betrieb und Weiterentwicklung verantwortet?
  • Was sind die Exit-Kosten? Können Sie Daten/Workflows ohne Totalschaden migrieren?
  • Welche Teile sind wirklich differenzierend? Baue diese. Für undifferenzierende Bausteine: robuste, portable Open-Source- oder Commercial-Komponenten unter eigener Kontrolle.

Werkzeugkasten, der sich in On-Prem-Setups bewährt

Kein Dogma, aber in der Praxis tragfähig: