Wenn Sie die folgenden Fragen mehrheitlich mit „Ja“ beantworten, deutet alles auf Build hin:
- Muss das System air-gapped oder strikt on-prem laufen – ohne ausgehende Telemetrie?
- Benötigen wir reproduzierbare, auditierbare ML/LLM-Pipelines mit kontrolliertem Tool-Use?
- Sind harte Latenz- oder Verfügbarkeitsanforderungen zu erfüllen, die Cloud-Pfade ausschließen?
- Erfordert der Betrieb kontrollierte, seltene Updates und qualifizierte Rollbacks?
- Ist der Domänenkern ein Differenzierungsfaktor, der nicht über Standardprodukte abbildbar ist?
- Müssen wir Integrationsgrenzen zu Legacy-Systemen so absichern, dass Änderungen dort unsere Kerninvarianten nicht gefährden?
Und für „Buy“:
- Ist die Komponente austauschbar und hinter einem stabilen Interface kapselbar?
- Können wir Schlüssel, Daten und Telemetrie vollständig selbst kontrollieren?
- Existiert ein On-prem-Betriebsmodell ohne Remote-Zwang?
- Erlaubt der Anbieter Escrow oder transparente SBOMs und reproduzierbare Artefakte?
Fazit
In regulierten Industrien ist „Build vs Buy“ eine Souveränitätsentscheidung. Wer Kontrolle über Daten, Modelle, Entscheidungen und Betrieb braucht, landet zwangsläufig bei maßgeschneiderter Software – allerdings auf einer disziplinierten, wiederverwendbaren Plattformbasis. Der Weg führt nicht über die perfekte Feature-Liste, sondern über klare Kontrollziele, saubere Integrationsgrenzen, reproduzierbare Pipelines und Technical Ownership. Kaufen Sie bewusst dort, wo es Commodity ist, aber geben Sie die Zügel über Domänenlogik, Datenflüsse und Betrieb niemals aus der Hand.
FAQ
Frage: Wie rechtfertige ich „Build“ gegenüber dem CFO ohne Marketingzahlen?
Antwort: Formulieren Sie Kontrollziele als Risiken mit operativem Preis:
- Ausfallkosten pro Stunde bei Cloud- oder Lizenzserver-Abhängigkeit
- Audit-/Zertifizierungsaufwände bei nicht reproduzierbaren Pipelines
- Vendor-Lock-in-Kosten bei notwendigen Funktionsanpassungen
Hinterlegen Sie diese Punkte mit konkreten Betriebsabläufen (Patch-Fenster, Cutover-Prozesse, Audit-Belege) und zeigen Sie, welche davon Sie nur mit Build unter Kontrolle bekommen.
Frage: Wie organisiere ich On-Prem GPU-Kapazität effizient?
Antwort: Konsolidieren Sie Inferenz-Workloads über Kubernetes mit GPU-Device-Plugins, priorisieren Sie produktive Workloads mittels Taints/Tolerations, und nutzen Sie Quoten. Bauen Sie eine zentrale Artefakt-Pipeline mit signierten Images. Messen Sie Auslastung, Latenz und Heat-Maps pro Modell. Planen Sie Kapazität über Batch-Fenster und reservierte Kontingente je Werk/Flotte, statt isolated Islands zu betreiben.
Frage: Wie gehe ich mit Zertifizierung und Audit um, wenn ML/LLM im Spiel ist?
Antwort: Trennen Sie deterministische Kontrollpfade von adaptiven Modellen. Dokumentieren Sie Daten- und Modell-Linien lückenlos, halten Sie Golden Datasets und Evaluationsberichte versioniert vor, und erzwingen Sie Gatechecks vor Produktion. Setzen Sie auf reproduzierbare Builds, SBOMs, signierte Artefakte und WORM-Logs. So beantworten Sie Auditfragen mit konkreten Nachweisen statt Narrativen.
Frage: Können wir von einem bestehenden „Buy“-System schrittweise zu „Build“ migrieren?
Antwort: Ja, über Strangler-, Shadow- und Replay-Muster. Stellen Sie eine Proxy-Fassade vor das Altsystem, implementieren Sie neue Services in kleinen, getesteten Schnitten, validieren Sie sie im Shadow-Mode, und schalten Sie selektiv um, sobald Domänen-KPIs stabil sind. So vermeiden Sie Big-Bang-Risiken.
Frage: Was, wenn uns Inhouse-Expertise für ML/LLM fehlt?
Antwort: Trennen Sie Produktkern und Plattform. Starten Sie mit einem schlanken, souveränen AI-Fundament (Artefakt- und Policy-Pipelines, Observability, On-prem-Inferenz), und holen Sie sich gezielte Unterstützung für die ersten Fälle. Entscheidend ist, dass Sie Technical Ownership – Code, Artefakte, Betriebswissen – bei sich aufbauen. Externe können enablen, Ownership bleibt intern.