• Security und Compliance:
  • SBOM-Erzeugung (Syft), Signaturen (Cosign), Admission Controller, die unsignierte Artefakte blocken.
  • Secrets-Management on-prem (HashiCorp Vault), Hardware-Root-of-Trust wo sinnvoll.
  • Rollback-Strategien und Canary Releases mit harten Abort-Kriterien.

LLM-gestützte Assistenz on-prem

  • Retrieval-Architektur:

  • Dokumente in eigenem DMS, Extraktion in ETL-Jobs, Chunking und Embedding lokal.

  • Vektorindex on-prem (pgvector in Postgres, oder eine eigenbetriebene Vektordatenbank).

  • RAG-Pipelines mit deterministischen Pre- und Post-Prozessen; jede Antwort verknüpft mit Dokument-Hashes und Embedding-Versionen.

  • Inferenz:
  • On-Prem-LLMs (je nach Domäne), oder abgeschottete dedizierte Single-Tenant-Inferenz-Endpoints.
  • Policy-Gateway davor: Input/Output-Filter, PII-Redaction, DLP-Regeln, Prompt- und Tool-Use-Policies.
  • Governance und Observability:
  • Vollständige Protokollierung aller Agentenaktionen inkl. Tool-Aufrufe, Parameter, Kontextfenster, Antwortbewertung.
  • Human-in-the-Loop Workflows für risikobehaftete Aktionen, mit Freigabe- und Vier-Augen-Prinzip.
  • Reproduzierbarkeit: Jede Antwort ist re-playable mit exakt denselben Artefakten (Modellhash, Embedding-Version, Prompt-Template, Tool-Version).

Integrationsmuster

  • Contract-first: gRPC/Protobuf-Schnittstellen mit Versionierung, Backwards-Kompatibilität über explizite „oneof“-Evolutionspfade.

  • Strangler-Fig-Pattern: Legacy-Systeme schrittweise umranken, fachliche Schnittstellen nach außen ziehen, interne Implementierung migrieren, ohne Betrieb zu unterbrechen.

  • Adapter-Layer: Protokoll-Gateways (OPC UA-Server/Client, Feldbus-Bridges) gekapselt, austauschbar, mit klaren Time-Budgets und Circuit-Breakern.

Trade-offs ehrlich benennen

Build hat Kosten: Teamaufbau, Time-to-First-Value, Wartungsverantwortung. Wer hier mit rosigen „Wir nehmen nur Open Source und sparen Lizenzen“-Rechnungen argumentiert, verkennt Lifecycle-Kosten. Umgekehrt hat Buy versteckte Kosten: Workarounds, Datenexport-Limits, Roadmap-Abhängigkeiten, forensische Lücken, Latenz- und Zuverlässigkeitsprobleme, die im Pilot nicht sichtbar sind.

Wie reduziert man Build-Risiken?

  • Produktlinien-Ansatz: Wiederverwendbare Kernbausteine (Auth, Observability, CI/CD-Standards, Telemetrie, Policy-Gateways) definieren, Domain-spezifisch konfigurieren.

  • Technische Ownership verankern: Ein verantwortliches Team mit Entscheidungsmandat, ADR-Dokumentation, automatisierte Qualitätsleitplanken (Linters, SAST/DAST, Policy-as-Code).

  • Messbare Inkremente: Von Tag 1 SLOs definieren (Latenz-P99, Fehlerrate, Drift-Grenzen), Canary und Dunkel-Deployments nutzen.

  • Governance-by-Design: Audits, SBOM, Signaturen, Reproducible Builds nicht „später“, sondern ab Commit 1.

Wann „Buy“ trotzdem sinnvoll ist

Es gibt Domänen, in denen Buy die richtige Wahl ist:

  • Nicht-differenzierende Funktionen: Generisches Ticketing, HR-Tools, Commodity-BI – solange Datenexport klar, Mandantentrennung sauber und Datenklassifikation passt.

  • Peripherie ohne Latenz-/Souveränitätszwang: Wissenssuche auf öffentlich verfügbaren Inhalten, interne Kollaborations-Tools ohne Betriebsrelevanz.

  • Komponenten statt Gesamtprodukt: Z. B. einen Vektorindex als On-Prem-Software lizenzieren, aber die Orchestrierung, Policies und Datenpfade selbst verantworten.

Wichtig ist: „Buy“ heißt nicht „SaaS“. Ein lizenzierbares, on-prem fähiges Produkt unter Ihrer Betriebs- und Security-Kontrolle kann Teil eines Build-Ansatzes sein. Der kritische Fehler ist das „Buy“ eines Betriebsmodells (Multi-Tenant, telefonierende Appliances), das Ihren Randbedingungen widerspricht.

Ein einfacher, technischer Entscheidungsrahmen

Bewerten Sie jeden Kandidaten (Build oder Buy) entlang folgender Fragen, 0–3 Punkte, je höher desto kritischer:

Souveränität

  • Verlässt irgendeine Telemetrie Ihr Netzwerk? (0: nein, 3: ja, unvermeidlich)

  • Können Sie jede Entscheidung vollständig reproduzieren? (0: ja, 3: nein)

  • Single-Tenant-Isolation möglich? (0: garantiert, 3: nein)

Echtzeit/Betrieb

  • P99-Latenz innerhalb Budgets ohne Internet? (0: ja, 3: nein)

  • Geplante Offline-Szenarien unterstützt? (0: voll, 3: gar nicht)

  • Update- und Rollback-Pfad unter Ihrer Kontrolle? (0: ja, 3: nein)

Integration

  • Native Unterstützung Ihrer Protokolle/Schnittstellen? (0: voll, 3: nein)

  • Evolvierbare, versionierte Verträge? (0: ja, 3: proprietär, starr)

  • Toleranz gegenüber Legacy-Zyklen? (0: hoch, 3: gering)

Lebenszyklus/Eigentum

  • Reproduzierbare Builds und SBOM? (0: vorhanden, 3: nein)

  • Roadmap-Verlässlichkeit für Domänenfeatures? (0: vertraglich, 3: vage)

  • Vendor-Lock-in-Risiko? (0: gering, offene Standards, 3: hoch)

Ab 12 Punkten ist „Buy“ in der Regel teurer – nicht in der Lizenz, sondern im Betrieb und Risiko. Dann ist Build die robuste Wahl.

Drei häufige Fehlannahmen – und bessere Alternativen

1) „BYOK löst das Souveränitätsproblem.“

  • Problem: Schlüsselkontrolle ohne Control-Plane-Kontrolle bringt wenig. Telemetrie, Metadaten, Modellupdates bleiben außerhalb Ihrer Kontrolle.

  • Besser: Volle On-Prem-Kette, inklusive Observability und Policy-Enforcement. Wenn ein externer Service nötig ist, dedizierte Single-Tenant-Deployments mit klaren Datenflüssen.

2) „Wir können SaaS später ‚on-prem‘ nachbauen.“

  • Problem: Der spätere Rebuild kostet doppelt: zunächst Integrationsaufwand, später Migrationsaufwand mit Downtime-Risiko.

  • Besser: Von Anfang an strangler-basiert denken, Daten- und Entscheidungsgrenzen sauber ziehen, austauschbare Bausteine nutzen.

3) „Fine-Tuning macht das LLM produktiv.“

  • Problem: Häufig sind Datenpipelines, Dokumentlebenszyklus, RAG-Qualität, Tool-Use-Sicherheit die Engpässe – nicht das Basismodell.

  • Besser: Erst Governance, Observability und Retrieval-Qualität lösen, dann ggf. fine-tunen – auf einer Plattform, die diese Schritte nachvollziehbar macht.

Ein pragmatisches Vorgehensmodell für Build

Phase 0: Architektur- und Risikorahmen

  • Domänen-SLOs definieren (z. B. P99-Latenz, Fehlerraten, maximaler Drift).

  • Datenklassifikation und Flussdiagramme erstellen – bis auf Prozess-/Queue-Ebene.

  • Threat Modeling und Betriebsrichtlinien (Backup, Restore, Rollback, Air-Gap-Prozesse).

Phase 1: Minimaler, messbarer Kern

  • End-to-End-„Steel Thread“: Vom Eingangssignal bis zur Entscheidung – klein, aber vollständig.

  • Observability ab Tag 1: Request/Response-Tracing, Modell-/Artefakt-Hashes in Logs.

  • Contract-Tests mit Legacy-Systemen, synthetische Last, Fault-Injection für Offline.

Phase 2: Härtung und Governance

  • CI/CD etablieren mit signierten Artefakten, Policy-as-Code (Admission Controller).

  • Reproduzierbare Builds, SBOM, Versions-Matrix (Modell, Daten, Code).

  • Canary- und Blau/Grün-Rollouts, automatische Rollbacks.