Ein minimal belastbarer Produktionspfad:

  • Build

  • Deterministische Builds mit Containerisierung; Base-Images aus internen Mirrors; SBOM-Erzeugung; Signaturen (cosign/sigstore).

  • Trainings- und Evaluationspipelines als Code (Orchestrierung z. B. mit Airflow, Argo Workflows). Keine “Manual Steps” in kritischen Pfaden.

  • Evaluate

  • Offline-Evaluation mit repräsentativen Edge-Cases; statistische Power berücksichtigen.

  • LLM-spezifisch: Halluzinations- und Groundedness-Checks; Retrieval-Evaluierung (z. B. nDCG, Recall@k); Tool-Use-Sicherheitstests (Prompt Injection, Datenabfluss).

  • Red-Teaming und Sicherheitsreviews als Pflichtschritt.

  • Deploy

  • Progressive Rollouts: Shadow, A/B, Canary. Feature-Gates für Nutzersichtbarkeit.

  • Ressourcenplanung: GPU/CPU-Sizing, Batch/Streaming-Pfade, Latenzbudgets; vorausschauende Skalierung.

  • Disaster-Recovery: Rollback in Minuten, nicht Tagen. Backups von Model Registry, Feature Store, Vector Indexen.

  • Operate

  • Observability: Metriken (Latenz, Fehlerraten), Daten-/Kontext-Drift, Kosten, Nutzungsmuster. Für LLMs zusätzlich: Prompt-/Response-Logging mit PII-Scrubbing, Tool-Aktionen, Policy-Verletzungen.

  • Governance: Genehmigungs-Workflows für neue Modelle/Prompts/Tools; Pflichtfelder für Model Cards und Change-Logs; regelmäßige Audits.

  • Lifecycles: Retirements planen, End-of-Life definieren, Archivierung rechtssicher.

Warum viele POCs hier sterben:

  • Fehlender Eigentümer im Betrieb (Run) – niemand fühlt sich zuständig.

  • Keine Budgetierung für Telemetrie, Sicherheit, GPU-Kapazität – das echte CapEx/OpEx kommt erst nach dem POC.

  • Unklare Datenverträge – Input ändert sich, Modell kippt.

  • Vendor-Lock-in – der gewünschte souveräne Betrieb ist später technisch oder vertraglich blockiert.

5) Drei Referenzarchitekturen aus der Praxis

A) Visuelle Qualitätsprüfung in der Fertigung (Edge + On-Prem)

  • Problem: 2-Sekunden-Latenz, ungeplante Stillstände minimieren, Auditierbarkeit.

  • Architektur:

  • Edge-Cams -> On-Prem Inferenz-Cluster (Kubernetes) mit GPU-Nodes; Modelle als optimierte Artefakte (TensorRT, OpenVINO).

  • Datenpfad zweigeteilt: Online (Inferenz) strikt isoliert; Offline (Training/Drift) mit verzögerter, pseudonymisierter Stichprobe.

  • Lineage: Jede Entscheidung referenziert Modell-Hash, Datensatz-ID, Konfig-Commit; lokal signierte Logs.

  • Trade-offs: Maximale Souveränität und Latenzfestigkeit vs. begrenzte Elastizität. Lösung: Kapazitätsplanung + Burst nur für nicht sensible Trainingsjobs in souveräner Cloud – nie für Live-Inferenz.

B) On-Prem RAG für Wartung und Instandhaltung (Bahn, Maschinenbau)

  • Problem: Zugriff auf vertrauliche Handbücher, Variantenstand, Service-Historien; keine Datenabflüsse; nachvollziehbare Antworten.

  • Architektur:

  • Dokumenten-Pipeline: Parsing (lokal), semantische Segmentierung, Embeddings on-prem, Vektorindex (z. B. pgvector oder Milvus) in der Sicherheitszone.

  • LLM-Inferenz lokal (gguf-quantisierte Modelle oder vLLM/TensorRT-LLM). Prompt- und Tool-Policies enforcebar (OPA).

  • Telemetrie: Prompt-/Response-Logs mit PII-Scrubbing; Faithfulness-Scoring offline; Zitierpflicht (Quellen-Attribution).

  • Trade-offs: Kleinere Modelle, dafür Datenhoheit; Qualität wird über gutes Retrieval, Domänen-Prompts und Evaluation erreicht – nicht über das “größtmögliche Modell”.

C) Air-gapped LLM-Agenten im sicherheitskritischen Umfeld (Defense/OT)

  • Problem: Kein externes Netzwerk, nur whitelisted Tools; strikte Command- und Action-Policies; vollständige Nachvollziehbarkeit.

  • Architektur:

  • Air-gapped K8s-Cluster; Artefakte via signierten, geprüften Offline-Medien; SBOM-Prüfung am Import-Gateway.

  • Agenten-Sandbox (z. B. gVisor/Firecracker); Tools als explizite, signierte Plugins mit deklarativen Rechten; Human-in-the-Loop für irreversible Aktionen.

  • Evidenzspeicher: Append-only, signierte Events (WORM-Storage); periodische Reviews.

  • Trade-offs: Höchste Sicherheit vs. Entwicklungs- und Wartungsaufwand. Dafür echte Zertifizierbarkeit.

6) Build vs. Buy und die Cloud-Frage – nüchtern betrachtet

  • API-first (externe LLM-Services)

  • Pro: Geschwindigkeit, Qualität out-of-the-box.

  • Contra: Datenabflussrisiko, Jurisdiktionsrisiko, unklare Reproduzierbarkeit, volatile Kosten, eingeschränkte Auditierbarkeit.

  • Geeignet: Unkritische Use Cases mit nicht sensiblen Daten und klarer Entkopplung.

  • On-Prem/ Sovereign Cloud

  • Pro: Kontrolle, Reproduzierbarkeit, klare Kostensteuerung, Auditfähigkeit.

  • Contra: Anfangsinvest, eigene Betriebsverantwortung, Talentbedarf.

  • Geeignet: Alles mit personenbezogenen, vertraulichen oder sicherheitskritischen Daten – also der Großteil industrieller Kernprozesse.

TCO-Perspektive:

  • Hardware: GPU-Verfügbarkeit, Lifecycle (3–5 Jahre), Ersatzteile, Treiber/ROCm/CUDA-Kompatibilität.

  • Betrieb: Plattform (K8s), Observability, Security-Tooling, Patch-Management.

  • Modelle: Feintuning-Kosten, Evaluierung, Red-Teaming, periodische Re-Trainings.

  • Lock-in-Kosten: Späterer Exit aus proprietären APIs ist teurer als frühe Souveränität. Die Frage ist nicht, ob Sie zahlen – sondern wann und wofür.

7) Governance und Observability für LLMs und Agenten
LLM-Systeme sind dynamische, nichtdeterministische Komponenten. Ohne Governance riskieren Sie Kostenexplosion, Datenabfluss und Compliance-Verstöße.

Was verpflichtend ist:

  • Telemetrie mit Datenschutz: Prompt-/Response-Logs mit PII-Redaktion; Tool-Use-Events; Kosten und Latenzen; Policy-Verstöße; Sampling für Qualitätsreviews.

  • Policies als Code: Welche Tools dürfen auf welche Daten? Wer darf neue Prompts/Tools einführen? Welche Ausgaben sind verboten? Maschinenlesbar und testbar (OPA/Rego).

  • Evaluierung im Betrieb: Periodische Benchmarks, Drift-Erkennung; qualitative Review-Schleifen; Regressionstests für Prompts, Retriever und Tools.

  • Sicherheit: Secret-Handling zentral (KMS/Vault); Sandboxing von Tools; Network Egress Control; Signierte Artefakte; SBOM für Modelle und Pipelines.

  • Human-in-the-Loop: Definierte “Hold”-Zustände für riskante Aktionen; Eskalationspfade; Erklärbarkeit für Business-Owner.

8) Wenn Sie nur 90 Tage hätten: ein realistischer Fahrplan

  • Woche 1–2: Problemdefinition schärfen, NFRs dokumentieren, Datenklassifizierung, Verantwortliche benennen. Entscheidung: Souveränitätslevel (on-prem/hybrid).

  • Woche 3–4: Datenverträge aufsetzen; minimalen Datenfluss aufbauen; Lineage/Versionierung aktivieren.

  • Woche 5–6: Baseline ohne KI (Rule-based/Search). Daran wird KI gemessen. Erst dann Prototyp eines Modells.

  • Woche 7–8: Reproduzierbare Pipeline (Build/Eval/Deploy), Modell-Registry, signierte Artefakte, Observability-Grundgerüst.

  • Woche 9–10: Offline-Evaluation mit echten Edge-Cases; Red-Teaming; Datenschutzprüfung; Security-Review.

  • Woche 11–12: Shadow-Deployment in echter Umgebung; Canary mit klaren Abbruchkriterien; Betriebsdokumentation und Runbooks.