5) Sichere Geheimnisverwaltung und Supply-Chain-Härtung

  • On-Prem-Secret-Store, getrennte Rollen, Hardware-gestützte Schlüssel, signierte Artefakte.

  • Reproduzierbare Builds: Deterministische Container-Images, SBOMs, Signaturen, Air-Gap-taugliche Registries.

6) Edge- und KI-Inferenz deterministisch betreiben

  • Model Packaging: ONNX/TensorRT/Kommandozeilentools für reproduzierbare Builds, feste Seeds, quantisierte Pfade, Messung unter Worst-Case-Last.

  • Ressourcen-Isolation: CPU/GPU-Zuteilung, NUMA-Affinität, GPU-MIG/Namespace, um Latenzen stabil zu halten.

7) LLM/Agent-Architektur on-premise

  • Retrieval-Augmented Generation lokal: Vektor-DB on-prem (z. B. Postgres mit Vektor-Erweiterung, oder spezialisierte Engines), Embeddings lokal erzeugen.

  • Toolformer-Prinzip kontrolliert: Agents bekommen whitelisted Tools mit strikten Verträgen; alle Aufrufe werden geloggt.

  • Observability & Governance: Vollständiges Tracing von Prompt bis Output, Metriken für Halluzinationen/Policy-Verstöße, Shadow- und Canary-Deployments. Plattformen wie unsere eigene (Alpi-M) adressieren genau das: Observability & Governance für LLM-Agenten im Rechenzentrum des Kunden.

Ein pragmatisches Entscheidungsmodell: Buy, Extend, Build

  • Buy: Unkritische Peripherie, geringe Integrationsschärfe, Cloud ist akzeptabel, Auditierbarkeit zweitrangig. Beispiel: interne Kollaboration, Commodity-BI, Ticketing.
  • Extend/Integrate: Kernfunktion bleibt individuell, umgeben von zugekauften, klar abgegrenzten Komponenten (z. B. Visualisierungsbibliotheken, Zeitreihen-DB, Message-Bus).
  • Build: Wenn mindestens zwei der harten Kriterien (Souveränität, Safety, Air-Gap/Edge, Lifecycle-Kontrolle, Brownfield mit Zero-Downtime, LLM-Governance) voll greifen.

Der Bewertungsablauf in der Praxis
1) Nichtfunktionale Anforderungen zuerst: Latenz, Offline-Anteil, Auditierbarkeit, Datenklassen, Exportkontrollen. Schriftlich, testbar.
2) Architektur-Scouting: Für 2–3 Kandidatenarchitekturen skizzieren Sie Flüsse, Deployments, Integrationen. Prüfen Sie jeweils die nichtfunktionalen Anforderungen.
3) Risikoanalyse: Was passiert, wenn der Anbieter Preismodelle ändert, Features deprecates, Rechenzentren wechselt? Was, wenn ein Audit morgen Belege fordert?
4) Build-Spike: Eine gezielte, zwei- bis vierwöchige Implementationsspitze in der heikelsten Ecke (z. B. deterministische Inferenz on edge oder Event-Sourcing-Auditlog). Ziel: technische Machbarkeit belegen oder falsifizieren.
5) Entscheidung mit TCO-Rahmen: Lizenzen/Abos vs. Engineering-Aufwand, Betrieb, Testevidenz, Qualifikation. Nicht vergessen: Kosten des Kontrollverlusts.

Zwei exemplarische Szenarien aus der Praxis

Szenario 1: Visuelle Qualitätsprüfung in der Fertigung
Ausgangslage:

  • Kameras direkt in der Linie, Takt < 100 ms, variable Beleuchtung, produktionsbedingte Varianten.

  • Kein Internetzugang in der Produktionszelle; strikte Trennung OT/IT.

  • Qualitätssicherung verlangt nachvollziehbare Entscheidungen, reproduzierbare Tests, versionierte Datensätze.

Warum Buy scheitert:

  • SaaS-Inspektionslösungen verlangen Cloud-Inferenz oder Telemetrie-Uploads zwecks “Verbesserung”.

  • Fehlende deterministische Latenzzusagen, keine Kontrolle über Modellversionen, eingeschränkte Exportfunktionen für Audit.

Build-Ansatz:

  • Edge-Inferenz mit quantisierten Modellen, Verpackung via ONNX/TensorRT, deterministische Pfade.

  • Datenerfassung über lokales Data Lakehouse, Ingestion per append-only Logs, strikte Versionierung von Datensätzen/Labels/Modellen.

  • Event-Sourcing für Entscheidungen: Jede Ausschussmarkierung ist ein Event mit Kamerakontrollparametern, Algorithmus-Version, Inferenz-Seed.

  • UI als dünner Client; Offline-Betrieb mit späterem Sync.

  • Ergebnis: Wartungsarm, auditierbar, erweiterbar auf neue Varianten ohne Cloud-Abhängigkeit.

Szenario 2: Planungs- und Lagebildsystem in sicherheitskritischer Umgebung
Ausgangslage:

  • Multi-User-Planung, Rollenkonzepte, klassifizierte Daten, intermittente Verbindungen zwischen Standorten.

  • Bedarf an feingranularer Nachvollziehbarkeit von Änderungen, inklusive Wer, Was, Wann, Warum.

Warum Buy scheitert:

  • COTS-GIS/Planning-Suites mit proprietären Datenmodellen, eingeschränkter Offline-Fähigkeit, eingeschränkter Audit-Tiefe.

  • Roadmap- und Jurisdiktionsrisiko.

Build-Ansatz:

  • Event-Sourcing-Kern für Planungsobjekte; CRDT- oder konfliktarme Merge-Strategien für Offline-Sync; strikte Schreibrechte als Policy-as-Code.

  • Datenhaltung verschlüsselt at rest, hardwaregestützte Schlüssel; Replikation nur entlang klassifizierter Kanäle.

  • Rollout via reproduzierbaren, signierten Artefakten; A/B-Partitionsupdates für Zero-Downtime.

  • Ergebnis: Kontrollierbares, skalierbares System mit reproduzierbaren, auditierbaren Zuständen.

Kosten und Zeithorizonte: Wie man Build ohne Selbstüberschätzung angeht

  • Problemausschnitt eng wählen: Nicht “die Plattform”, sondern ein “Walking Skeleton”: Ende-zu-Ende-Minimalfunktion mit allen kritischen Querschnittsthemen (Auth, Logging, Deployment, Test).
  • Strangler-Pattern bei Migrationen: Altsystem kapseln, neue Slices daneben, Traffic schrittweise umlenken. Keine heroischen Big-Bang-Cutovers.
  • Testevidenz früh etablieren: Testbar formulierte Anforderungen, automatisierte Akzeptanztests, formale Nachvollziehbarkeit. Schreiben Sie die ersten Compliance-Tests, bevor Sie das UI pixeln.
  • Kein Microservices-Fetisch: Beginnen Sie mit modularen Monolithen. Microservices erst, wenn Team- und Domänenschnitt das erzwingen (z. B. unabhängige Skalierung, organisatorische Grenzen).
  • TCO realistisch: Engineering-Kosten plus Betrieb, Schulung, Tools, Härtung. Lizenzkostenersparnis ist nicht das Ziel – Kontrolle ist das Ziel.

LLM/Agenten in Industrieumgebungen: Build ist Governance

LLM-Agenten sind in der Industrie nur so nützlich wie ihre Kontrollierbarkeit. Technische Eckpunkte:

  • Datenzugriff minimieren: Retrieval nur aus freigegebenen, lokal gehosteten Quellen; Datenklassifizierung wird Teil der Prompt-Build-Pipeline.

  • Werkzeuge kapseln: Jeder Tool-Aufruf ist ein Vertrag mit klaren Inputs/Outputs, Timeouts, Rücksetzlogik. Keine Shell-Zugriffe “ins Blaue”.

  • Evals als Gate: Jede Änderung am Prompt, am Toolset, am Modell läuft durch Evals mit repräsentativer Aufgabensuite. Shadow-Deployments vor Aktivierung.

  • Vollständiges Tracing: Prompt, Kontext, Tool-Aufrufe, Antworten, Policy-Entscheide, Embedding-/Vektor-DB-Versionen – alles lokal protokolliert.

  • Observability & Governance-Plattformen on-prem: Wir haben dafür eine eigene Plattform gebaut (Alpi-M), weil reine Logging-Ansätze das nicht leisten. Ziel ist: Verhalten messen, erklären, steuern – ohne Daten das Haus verlassen zu lassen.