LLM-spezifische Architekturen on-prem

  • Retrieval-augmented Generation statt blindem End-to-End-Fine-Tuning; alle Wissensquellen versioniert und auditierbar.

  • Policy Engine, die Ausgaben vor Freigabe bewertet (Regeln, Klassifikatoren, Heuristiken), deterministisches Replay von Agentenläufen.

  • Prompt-/Template-Versionierung, Datenklassenbildung (z. B. PII vs. technische Daten) und Trennung in Sandboxes.

Kosten und Risiken ehrlich bilanzieren

Build wirkt teuer, weil die Kosten sichtbar sind. Buy wirkt günstig, weil vieles versteckt ist. Für eine tragfähige Entscheidung brauchen Sie TCO über 5–10 Jahre:

  • Entwicklung: Teamaufbau, Architekturarbeit, Domänenmodellierung, Hardware- und Edge-Enablement, MLOps.
  • Zertifizierung/Validierung: Requirements-Engineering, Traceability, Testautomation, formale Nachweise, Safety-Case-Dokumentation, Qualitätssicherung.
  • Betrieb: Patching, Vulnerability Management, Modellüberwachung, Datenqualität, Rotationspläne für Zertifikate/Schlüssel.
  • Infrastruktur: CAPEX für Edge/GPU, Energie-/Kühlungskonzepte, Lifecycle-Management.
  • Abhängigkeiten: Vendor-Lock-in, Preissprünge, API-Deprecations, EoL-Risiken, eingeschränkte Auditierbarkeit.

Ein praktischer Hebel ist, die “Exit-Kosten” einzupreisen: Was kostet es, das System in drei Jahren aus einem Vendor herauszulösen? Wenn diese Zahl die initiale Einsparung bei Buy übersteigt, ist Build in Summe günstiger.

Anonymisierte Muster aus der Praxis

Defense: Sichere Einsatzplanungssoftware mit on-prem LLM-Unterstützung

  • Randbedingungen: strikte Klassifizierung, keine externen Verbindungen, nachvollziehbare Entscheidungen.

  • Architektur: Air-gapped Cluster, lokal gehostetes LLM für Textzusammenfassungen und Dokumentnavigation, Policies, die jede Antwort gegen Regelwerke prüfen, Event-Sourcing für alle Nutzeraktionen.

  • Ergebnis: Reduzierte Auswertezeiten ohne Abgabe der Souveränität.

Manufacturing: Visuelle Qualitätsprüfung

  • Randbedingungen: Latenz <50 ms, Integration mit Kameras/PLC, wechselnde Varianten, auditierbare Entscheidungen.

  • Architektur: Edge-Inferenz auf Industrierechnern, zentraler Trainings-Cluster, Shadow-Deployments, versionssichere Dataset-Kuration, robuste Datenpipelines mit Sensor-Härtung.

  • Ergebnis: Stabiler Betrieb trotz Variantenvielfalt, schnelle Rückrollbarkeit bei Modellregressionen.

Rail: Flottenintelligenz

  • Randbedingungen: Intermittierende Konnektivität, verteilte Sensoren, lange Fahrzeuglebenszyklen.

  • Architektur: Store-and-forward, Ereignisorientierung, konfliktfreie Replikation, Offline-Analysen mit nachträglicher Konsolidierung, klare Anti-Corruption-Layer zu Bestandssystemen.

  • Ergebnis: Verbesserte Verfügbarkeit der Daten ohne Betriebseinschnitte.

Aviation: Trainingsplattform

  • Randbedingungen: EU-Datenhaltung, feingranulare Rechte, Versionskontrolle von Inhalten, Revisionssicherheit.

  • Architektur: EU-only Cloud oder Private Cloud, deterministische Content-Pipelines, pro Tenant isolierte Workloads, robuste Nachweisketten für Kursinhalte und Prüfungen.

  • Ergebnis: Skalierung ohne die Auditierbarkeit zu gefährden.

Technical Ownership: Was es praktisch bedeutet

Technical Ownership ist nicht “wir haben die Repo-Rechte”, sondern Ergebnisverantwortung für Systemverhalten in Produktion. Konkret:

  • Ein Team besitzt Architektur, Code, Betrieb, Qualität und Kosten. Keine Lücken zwischen “Entwicklung” und “Betrieb”.
  • Klare SLOs/SLA mit Messbarkeit. Wenn eine Anomalie auftritt, ist das Team handlungsfähig und priorisiert Gegenmaßnahmen.
  • Architektur-Entscheidungen sind dokumentiert (ADRs), rückverfolgbar und überprüft. Keine unsichtbaren Abhängigkeiten.
  • Lieferkettensicherheit ist im Prozess verankert: SBOM in jedem Build, signierte Artefakte, Verified Builds, reproduzierbare Toolchains.
  • Für KI: Evaluationsharness, Red-Teaming, Drift-Detektion, Dokumentation der Einsatzgrenzen (Model Cards), kontrollierte Datenzyklen.

Warum rettet das Projekte? Weil Ownership Entscheidungs- und Durchführungsvermögen bündelt. Wenn etwas schiefgeht, agiert ein verantwortliches Team im Rahmen eines klaren Budgets und einer technischen Leitplanke – anstatt Zuständigkeiten zwischen Vendor, IT und Fachbereich zu verschieben.

Qualitätssicherung für sicherheitskritische und AI-gestützte Systeme

  • Traceability von Anforderungen zu Tests: Jede Anforderung hat eindeutige Akzeptanzkriterien, verknüpft mit automatisierten Tests.
  • Szenario- und Property-Based-Testing: Nicht nur “Happy Path”, sondern systematische Grenzfälle, Fuzzing für Parser/Protokolle.
  • Fault-Injection und Chaos in staging-nahen Umgebungen: Netzwerkabrisse, fehlerhafte Sensoren, korruptes Input – wie reagiert das System?
  • Daten- und Modellqualität: DQ-Checks, Label-Reviews, synthetische Datensätze, Gegenbeispiele, Bias-Analysen, Reproduzierbarkeit.
  • Sicherheitsprüfungen: Bedrohungsmodellierung, sichere Defaults, Härtung (CIS-artige Benchmarks), statische/dynamische Codeanalyse, Lieferkettenprüfungen.
  • LLM-spezifische QA: Prompt-/Policy-Versionierung, automatisierte Evaluationssuites pro Use-Case, deterministisches Replay, dokumentierte No-Go-Zonen, zweistufige Freigabe bei hohem Risiko (Mensch im Loop).

Pragmatische Implementierungs-Route

Erste 90 Tage

  • Domänen- und Schnittstellenaufnahme, harte Nicht-Verhandelbarkeiten festzurren.

  • Risikoregister: rechtlich, betrieblich, technisch, lieferkette.

  • Proofs auf Zielhardware: Latenz, Thermik, Durchsatz, Energie, Offline-Fähigkeit.

  • Build-Buy-Dekomposition, Lieferkettenstrategie, Artefakt- und Geheimnis-Management.

  • Minimaler MLOps-Kern on-prem aufsetzen: Registry, Feature Store, Evaluationsharness.

6–12 Monate bis MVP im kritischen Pfad

  • Strangler-Schnitt legen, die kritischsten Legacy-Anschlüsse kapseln.

  • Canary-/Shadow-Deployments etabliert, Fehlerbudget und Rollback-Prozeduren geprobt.

  • Operability: Metriken, Logs, Traces, Audit-Streams in ein konsistentes Observability-Layout integrieren.

  • Sicherheitsgrundlagen in Routine überführen: Secrets-Rotation, Patch-Programme, Schwachstellenmanagement.

Skalierung und Zertifizierbarkeit

  • Vollständige Traceability, Safety-Cases, Testabdeckung, formale Reviews, regelmäßige Architektur-Health-Checks.

  • Kapazitätsplanung: GPU-Zuteilung, Cluster- und Edge-Flottenmanagement, Updates ohne Downtime.

Wo Buy weiterhin Sinn ergibt

  • Infrastruktur- und Datenplattformkomponenten mit stabilen Standards, die in Ihrem Perimeter laufen: Datenbanken, Message-Broker, Filesysteme, Observability-Stacks.
  • Open-Source-Modelle oder -Frameworks, die Sie hart einfassen: OnnxRuntime, TensorRT, vLLM, ggml/gguf-Stacks, wenn sie reproduzierbar aufgebaut und versioniert werden.
  • Werkzeuge für CI/CD, Artefaktmanagement, Testing, sofern sie lokal gespiegelt und ohne Cloud-Zwang betrieben werden können.

Regel: Besitzen Sie die Komponenten, deren Fehlverhalten existenzielle Konsequenzen hat. Kaufen Sie robust standardisierte Bausteine, die Sie im Zweifel austauschen können.

Ein Wort zu LLM-Agenten in der Industrie