Build vs Buy: Wann individuelle Entwicklung die einzige Option ist

Souveränität ermöglicht Intelligenz. Dieser Satz ist keine Marketingfloskel, sondern eine technische Beobachtung: Ohne Kontrolle über Daten, Prozesse und Abhängigkeiten bleibt jede AI- oder Digitalisierungsinitiative im Grenzbereich des Machbaren stecken. In regulierten und sicherheitskritischen Branchen entscheidet genau diese Souveränität darüber, ob ein System überhaupt produktionstauglich ist. Deshalb ist „Buy“ nicht immer die Abkürzung. Es gibt Randbedingungen, unter denen individuelle Entwicklung nicht Nice-to-have, sondern die einzige verantwortbare Option ist.

In diesem Beitrag formuliere ich einen technischen Entscheidungsrahmen für Build vs Buy in industriellen und regulierten Umgebungen. Er adressiert CTOs und technische Leiter, die nicht den nächsten „KI-Pilot“ bauen wollen, sondern Systeme, die jahrelang unter harten Bedingungen laufen, auditierbar sind und sich kontrolliert weiterentwickeln lassen.

Problem zuerst: Welche Zwänge dominieren Ihre Architektur?

Bevor es um Features geht, klären Sie die nicht verhandelbaren Randbedingungen. In regulierten Industrien überfahren genau diese Zwänge jede „wir nehmen erst mal SaaS“-Überlegung.

Häufige Non-Negotiables:

  • Datenhoheit und Jurisdiktion: Müssen Daten das Firmengelände oder eine EU-Jurisdiktion nie verlassen? Gilt ein Verbot von US-Cloud-Abhängigkeiten? Gibt es strikte Vorgaben zu Telemetrie/Telefonie „nach Hause“?

  • Netzsegmentierung und Offline-Betrieb: Air-gapped Zonen, keine eingehenden Verbindungen, periodischer Datenaustausch nur via kontrollierten Gateways, intermittierende Konnektivität (z. B. Züge, Baustellen).

  • Deterministische Latenz/Throughput: Feste Budgets für End-to-End-Latenz (z. B. <10 ms für einen Regelkreis), harte Backpressure-Strategien, keine unvorhersagbaren Cloud-Spikes.

  • Erklärbarkeit, Auditierbarkeit, Nachvollziehbarkeit: Vollständige Traceability von Anforderungen bis Code-Artefakt, reproduzierbare Builds, prüfbare Modellversionen.

  • Lebenszyklus- und Sicherheitsanforderungen: 10+ Jahre Laufzeit, härtbare Plattform, SBOM-Pflicht, kontrollierte Update-Fenster, Null-Toleranz für ungeplante Downtime.

Wenn zwei oder mehr dieser Punkte mit „ja“ beantwortet werden, schrumpft der Markt an kaufbaren Produkten dramatisch. Vor allem AI-bezogene SaaS-Angebote scheitern oft an:

  • Datenegress (Telemetrie, versteckte Trainingsdatenpfade)

  • Black-Box-Verhalten (keine prüfbare Entscheidungslogik)

  • Shared Responsibility, die in der Praxis niemand eigenverantwortlich trägt

  • Abhängigkeit von Drittanbietern, die sich der Governance des Betreibers entziehen

Was Buy oft nicht leisten kann

1) Vertrauensanker und Supply Chain unter eigener Kontrolle

  • Sie brauchen reproduzierbare, deterministische Builds, nachvollziehbare Upgrades, unterschriebene Artefakte, kontrollierte Abhängigkeitsbäume. Bei COTS/SaaS bleiben Build-Pipelines, Upstream-Dependencies und Telemetrie für Sie intransparent.

2) Offline-First als primäre Betriebsform

  • Viele kommerzielle Plattformen sind internetgebunden. Edge-Varianten sind oft abgespeckte Klone. Wenn „Offline“ kein Fallback, sondern der Normalfall ist, müssen Architekturentscheidungen (z. B. lokale Feature Stores, rollierende Schlüsselrotation, luftspaltkompatible Artefaktlieferung) von Tag 1 getragen werden.

3) Änderungsökonomie statt Feature-Katalog

  • In dynamischen Umgebungen dominiert nicht der einmalige Lizenzkauf, sondern die Änderungsrate: neue Sensoren, neue Prozessparameter, neue Compliance-Auflagen. Wenn jede Anpassung ein Herstellerprojekt ist, wächst die „Change Tax“ schneller als der Nutzen.

4) Auditierbarkeit bis auf Code- und Modellartefaktebene

  • Regulatoren und interne Revisionen verlangen Antworten auf „Welcher Commit, welches Modell, welches Prompt-Template hat diese Entscheidung erzeugt?“ Ohne Einblick in Datenpfade, Versionierung und Nebenwirkungen bleibt die Antwort Spekulation.

Typische Anti-Patterns bei Buy

  • SaaS per Reverse-Proxy in OT-Netze „einbinden“: Der Proxy reduziert nicht die eigentliche Angriffsfläche des externen Dienstes, schafft aber neue Wartungsrisiken und Monitoringlücken.
  • COTS bis zur Unkenntlichkeit customizen: Teuer, fragil und am Ende weder standardkonform noch vendor-supported.
  • Pilot-Purgatory: Unverbindliche Evaluationen, die nie die Nicht-Funktionalen Anforderungen (NFA) adressieren. Im produktiven Szenario brechen latente Annahmen (Latenz, Offline, Audit) auf.

Die Architekturfrage: Welche Muster begünstigen Build?

Die meisten „Build“-Projekte scheitern nicht an der Feature-Komplexität, sondern an der fehlenden Disziplin in den tragenden Architekturmustern. Was sich bewährt:

  • Hexagonale/Ports-and-Adapters-Architektur:
  • Entkoppeln Sie Fachlogik strikt von Infrastruktur. So können Sie Datenquellen (z. B. OPC UA, Profinet), Speichersysteme (SQL/TSDB/Object Store) und Dienste (Inference-Layer) ohne Kaskadeneffekte tauschen.
  • Ereignisorientiertes Design mit klaren Schemas:
  • Domain-Events als erste Bürger, versionierte Schemas, „append-only“ Logik für Audits, Idempotenz für Replays.
  • CQRS, wenn Lesen/Schreiben unterschiedliche SLAs haben:
  • Produktionskritische Schreibpfade hart optimieren, leseseitige Projektionen für Analyse/AI separat skalieren.
  • On-Prem-Container-Orchestrierung:
  • K3s/microk8s für Edge-Cluster, Härtung nach eigenem Baseline, interne Registry, Air-Gap-Updates via signierte Bundle-Artefakte.
  • Zero-Trust und identitätsbasierte Maschinenkommunikation:
  • Kurzlebige Zertifikate, mTLS zwischen Services, Policy-as-Code für Netzwerk- und Datenzugriffe.
  • Observability als Architekturbaustein:
  • Metriken, Logs, Traces mit einheitlichen Korrelationen; domänenspezifische Events zusätzlich zu Infrastruktur-Telemetrie.
  • Reproduzierbare Builds und SBOM:
  • Hermetische Builds, feste Dependency-Pins, Artefaktsignaturen, dokumentierte Lieferkette von Source bis Binary.

AI-spezifisch: Modell- und Agent-Governance on-prem

Sobald ML/LLM ins Spiel kommen, verschiebt sich der Schwerpunkt in Richtung Governance und Nachvollziehbarkeit:

  • Datenhoheit:
  • Trainings-, Validierungs- und Inferenzdaten verbleiben lokal. Keine stillen Datenpfade in Drittregionen. Feature Stores, Vektorspeicher und Prompt-Repositorien on-prem.
  • Modellverwaltung:
  • Versionierte, signierte Modellpakete; reproduzierbare Trainingsläufe; klare Promotionspfade (Dev/Staging/Prod) mit Gatekeeping.
  • Inferenz-Isolation:
  • Dedizierte Inferenzdienste (CPU/GPU), restriktive Netzpolicy, Resource Quotas, Backpressure-Strategien.
  • LLM-Agent-Observability:
  • Vollständige Aufzeichnung und Governance von Prompts, Kontexten, Tool-Calls, Rückgabewerten und Policy-Entscheidungen. Ohne diese Ebene sind LLMs in regulierten Domänen blind.
  • Policy-Enforcement:
  • Richtlinien für Datenklassifizierung, Tool-Zugriffe, Output-Filter und Interaktionslogs als Code. Änderungen nur über signierte, überprüfte Pipelines.