• Reproduzierbarkeit:
  • Containerisierte Pipelines, pinned Base Images.
  • Data/Feature/Code/Config‑Hashes in der Modellkarte.
  • Air‑gapped Artefakt‑Flow: Signierte SBOMs, Viren-/Lizenz‑Scans, Freigabeprozess.
  • Model Registry und Evaluationsharness:
  • Jede Version hat: Trainingsdaten‑Slice, Metriken auf Golden‑Sets, Robustheits‑Checks, Daten‑Drift‑Baselines.
  • Promotions nur nach automatisierten Gate‑Checks und manuellem Review.
  • Deployment‑Strategien:
  • Shadow/Canary an der Linie mit Live‑Telemetry.
  • Rollback via Promotionsjournal binnen Minuten.
  • Observability:
  • Feature‑Drift, Datenlücken, Latenz‑SLOs, Fehlerraten.
  • End‑to‑End‑Tracing: von Event über Feature bis Entscheidung.
  • Governance:
  • RBAC/ABAC pro Domäne und Datenklasse.
  • Datenschutz by Design: Pseudonymisierung am Edge, Verschlüsselung at rest/in transit, Schlüsselhoheit on‑prem.
  • Audit‑Trails unveränderlich geschrieben.

LLM‑Systeme in der Industrie: Retrieval, Agentik und Governance on‑prem

LLMs sind kein Chat‑Widget, sondern ein System aus Retrieval, Tools und Guardrails. In industriellen Kontexten sind drei Anforderungen nicht verhandelbar: Datensouveränität, Nachvollziehbarkeit, Fehlertoleranz.

  • Retrieval‑Augmented Generation:
  • Vektorindizes on‑prem (z. B. pgvector/Qdrant/Weaviate), pro Domäne isoliert.
  • Chunking/Embedding als deterministische, versionierte Pipelines.
  • Zugriffspfade entsprechen Domänen‑RBAC; kein Cross‑Leakage zwischen Werken.
  • Agentik mit Tools:
  • Tooling strikt whitelist‑basiert (z. B. Abfrage von MES‑Sichten, nicht des Roh‑ERP).
  • Rate‑Limits, Kosten‑Budgets, deterministische Fallbacks.
  • Observability/Governance:
  • Vollständige Kette loggen: Prompt, Retrieval‑Kontext, Tool‑Calls, Antworten, User‑Feedback, Fehler.
  • Evaluationssuiten mit Golden‑Fragen, Halluzinations‑Checks, PII‑Leak‑Scans.
  • On‑prem‑Plattform zur Steuerung und Auditierbarkeit von LLM‑Agents. Genau hier setzt Alpi‑M an: Observability und Governance für Agenten in souveränen Umgebungen, inkl. Data‑Access‑Tracing und Versionierung von Policies.

Sicherheits‑ und Souveränitätsprinzipien: nicht verhandelbar

  • Identität/Access:
  • Zentrales OIDC (z. B. Keycloak), RBAC/ABAC down to Topic, Table, Feature.
  • Service‑to‑Service Auth mit mTLS, kurzlebige Tokens.
  • Netzwerk:
  • Zonen strikt trennen, minimaler East‑West‑Traffic, egress‑kontrolliert.
  • One‑Way‑Gateways/Datadiodes dort, wo es regulatorisch gefordert ist.
  • Kryptografie:
  • Mandatorische Verschlüsselung in Transit/at Rest; Schlüsselmanagement on‑prem.
  • Software‑Supply‑Chain:
  • Signierte Container/Artefakte, SBOM, isolierte Build‑Runner.
  • Datenklassifikation:
  • Labeln, wer welche Datenkategorie verarbeitet; SLOs/SLAs pro Klasse.
  • Standard‑Policies: Speicherfristen, Zugriffspfade, Exportregeln.

Konkretes Szenario: Qualitätsinspektion + Predictive Maintenance über mehrere Werke

Problem: Werk A–C betreiben visuelle End‑of‑Line‑Prüfung und Vibrationssensorik an kritischen Aggregaten. Modelle müssen lokal laufen (ms‑Latenz), aber konzernweit verbessert werden. Netzwerke sind teil‑air‑gapped, interne Vorgaben untersagen Cloud‑Speicherung.

Lösungsskizze:

  • Pro Werk ein Edge‑Gateway:
  • Bilddaten und Inferenz‑Ergebnisse werden lokal gepuffert, mit Metadaten (Los, Station, Kameraserie) angereichert.
  • Timeseries der Sensorik werden gestreamt, Features (z. B. Spectral Kurtosis) lokal vorgerechnet.
  • Pseudonymisierung der Chargen‑IDs am Edge bei Bedarf.
  • Zentraler, on‑prem Lakehouse‑Cluster:
  • Asynchrone Synchronisation der Bronze/Silver‑Daten sobald die Verbindung steht.
  • Navigierbare Data Products: “eol_inspection_images_silver”, “vibration_features_silver”.
  • Training on‑prem:
  • Wöchentliche Trainingsjobs, Balanced Sampling über Werke, Augmentierungen versioniert.
  • Evaluationsharness mit Golden‑Sets je Werk; Promotions nur, wenn alle Werk‑SLOs erfüllt sind.
  • Deployment:
  • Modell‑Container gesigned via Artifakt‑Registry, Rollout asynchron in jedes Werk, Shadow‑Phase mit Telemetrie.
  • Online Feature Store lokal liefert Features in <10 ms; Triton hostet die Modelle; Abschnittsweise Canary auf Produktionsstationen.
  • Observability/Governance:
  • Drift‑Monitore je Werk; automatische Rückrolllogik bei Degradierung.
  • Auditierbare Kette: Daten‑ und Modellversionen bis zum Qualitätsentscheid.

Entscheidungshilfen: Wann welches Muster?

  • Data Warehouse:
  • Für standardisierte KPIs, Finanz/Operations‑Reporting, SCD‑Handling.
  • Nicht als Quelle für CV/zeitkritische KI nutzen.
  • Data Lake/Lakehouse:
  • Für Roh‑/semistrukturierte Daten, Feature‑Pipelines, Training, Reproduzierbarkeit.
  • Ohne Governance wird es teuer und intransparent – nie “nur ein Bucket”.
  • Data Mesh:
  • Wenn Domänen Verantwortung übernehmen können und wollen.
  • Starten Sie klein: 2–3 Domänen, klare Verträge, echte SLOs; zentraler Enablement‑Layer statt zentraler Kontrolle.

90‑Tage‑Plan für den Start ohne Big‑Bang

  • Tage 1–15: Scope und Schnittstellen
  • Wählen Sie eine Domäne mit hohem Nutzen (z. B. visuelle Inspektion) und eine zweite mit Timeseries.
  • Katalogisieren Sie Quellen, Latenzbudgets, Compliance‑Anforderungen.
  • Definieren Sie Data‑Product‑Verträge: Schemas, SLOs, Owner.
  • Tage 16–30: Minimal funktionsfähige Plattform
  • S3‑kompatibler Storage, Schema‑Registry, Kafka/Redpanda, Iceberg/Delta.
  • CI/CD für Daten‑ und ML‑Pipelines, Container‑Registry.
  • Edge‑Gateway PoC mit Pufferung und Validierung.
  • Tage 31–60: Erste Data Products und MLOps
  • Bronze/Silver‑Pipelines, Feature‑Store offline/online.
  • Model‑Registry, Evaluationsharness mit Golden‑Set.
  • Shadow‑Deployment an 1–2 Stationen, Observability aufsetzen.
  • Tage 61–90: Härtung und Mesh‑Ausbau
  • RBAC/ABAC, Audit, WORM‑Policies, Disaster‑Recovery‑Proben.
  • Zweite Domäne anschließen, Cross‑Domänen‑Feature teilen.
  • Review der SLOs, Finetuning der Betriebsprozesse.

Antipatterns, die Sie vermeiden sollten

  • “Erst die Daten, irgendwann die Governance”: Später wird nie billiger. Ohne Schema‑Registry und Ownership degenerieren Topics/Tables schnell.
  • “Alles in Echtzeit”: Vieles ist “Near‑Realtime genug”. Echtzeit kostet massiv Komplexität – zahlen Sie nur dort, wo nötig.
  • “One‑size‑fits‑all‑Warehouse”: Ein Warehouse ist kein Ersatz für ein Lakehouse, besonders nicht für Bild‑/Sensorikdaten.
  • “POC‑itis”: Modelle ohne Deployment‑Plan sind verschwendet. Planen Sie Observability und Rollback mit.
  • “Cloud ist einfacher”: Vielleicht, aber wenn Datensouveränität nicht verhandelbar ist, ist “einfach” irrelevant. Bauen Sie sauber on‑prem – der Betrieb wird dann beherrschbar.

Warum on‑prem GPU‑Training oft die richtige Wahl ist