• Modelle
  • Start pragmatisch: Gradient Boosting/Isolation Forest mit interpretierbaren Features. Deep Learning erst, wenn Latenz/Budget es erlauben.
  • Re-Train: Trigger via Konzeptdrift (KS-Test, PSI) und Ground-Truth-Delays (Wartungs-Tickets).
  • Serving
  • Low-latency Serving über Triton/KServe; Inferenz unter 50 ms P95, inkl. Feature-Berechnung.
  • Alarm-Workflow: Score > Threshold → Ticket in MES/EAM mit erklärenden Features; Feedback-Button für Operatoren (True/False Alarm).
  • Governance
  • SLA: Alarm-Recall > X%, Precision > Y%; SLO-Monitoring im Dashboard.
  • Change-Management: Canary auf 10% der Maschinen, automatischer Rollback bei SLO-Verletzung.

Souveränität ist keine Optionstaste: Architekturentscheidungen unter europäischen Randbedingungen

  • DSGVO/Datensouveränität
  • Datenresidenz: Kein Transfer außerhalb des EWR. Modelle lokal. Logs ohne PII. Zweckbindung und Aufbewahrung technisch erzwungen.
  • Zugriff: RBAC/ABAC via Keycloak, Attributbasiert (Standort, Rolle, Zweck). Alle Entscheidungen auditiert.
  • US CLOUD Act/Vendor-Lock-in
  • Risiko: Verwaltungszugriffe durch außereuropäische Anbieter sind Compliance-Risiken. Minimieren durch EU-Hoster oder On-Prem.
  • Architektonischer Hebel: OSS-First (K8s, MinIO, Iceberg, Feast, MLflow, Qdrant) statt proprietärer Monolithen. Austauschbarkeit ist Teil der Strategie.
  • On-Prem Compute
  • GPU-Planung: Kapazität pro Anwendungsfall (Tokens/s, Batchgrößen, Quantisierung). Für LLM-RAG reichen oft wenige A100/H100/RTX 6000 Ada, wenn Architektur stimmt.
  • Scheduling: K8s mit Node-Labels für GPU/CPU, PodDisruptionBudgets, MIG/NVML Monitoring.
  • Netzwerk: Ost-West-Verschlüsselung, mTLS zwischen Services, Service Mesh nur wenn nötig (Overhead beachten).
  • Air-gapped Betrieb
  • Artefakt-Supply-Chain: Signierte Container, Reproducible Builds, SBOM (Software Bill of Materials).
  • Update-Frequenz: Klare Cadence (z. B. monatlich), Out-of-band Hotfix-Prozess für CVEs.

Von PoC zu Produktion: Die Checkliste, die die meisten überspringen

  • Data SLAs live schalten: Freshness, Completeness, Schema-Drift-Alerts. PagerDuty/On-Call für Daten, nicht nur für Apps.
  • CI/CD für Modelle und Prompts:
  • Unit-Tests für Feature-Code.
  • Offline-Evals mit Golden Sets.
  • Property-based Tests für Prompts (keine PII-Leakage, kein “Make up facts”).
  • Canary Deployment mit Shadow Traffic.
  • Sicherheitsgrundlagen: Secrets in Vault, Rotations-Policy, signierte Modelle, Least Privilege für Pipelines.
  • Dokumentation: Datenkatalog-Einträge verpflichtend, Onboarding-Notebooks, Runbooks für Incidents.
  • Betriebskennzahlen: Kosten pro Anfrage, GPU-Auslastung, Tokens pro Antwort, Speicherkosten pro TB, Embedding-Throughput. Ohne Kostentelemetrie gibt es keinen ROI.

Entscheidungsrahmen: Build vs Buy, zentral vs föderiert

  • Minimal Viable Platform (12–16 Wochen)
  • K8s-Cluster (RKE2/Openshift), MinIO, Kafka/Redpanda, Iceberg/Delta + Trino, MLflow, Feast, Qdrant/pgvector, Airflow/Argo, Keycloak, Vault, OpenTelemetry + Grafana/Prometheus.
  • Zwei Produktpfade: “Docs→RAG” und “Sensor→Prediction”. Alles andere ist Ablenkung.
  • Data Mesh vs Zentral
  • Früh zentral, domänennahes Operating: Zentrales Team stellt Plattform, Domänenteams ownen Data Products. Vollständiges Mesh erst, wenn Reife da ist.
  • Buy wo es repetitiv ist
  • Hardware, MDM, ETL-Connectors, Compliance-Scans. Build wo Differenzierung entsteht: Feature-Engineering, Domain-LLMs, Decisioning-Workflows, Evaluationsharness.
  • EU-Cloud vs On-Prem
  • Wenn Datenklassifizierung “intern”/“öffentlich” und Latenz unkritisch: EU-Cloud ok. Bei “vertraulich/geheim”, Produktionsnähe, Exportkontrollen: On-Prem/Air-gapped.

Wie man in 90 Tagen Substanz schafft (ohne Marketing-Folien)

Woche 1–2: Scoping und Inventur

  • Ein Use Case, eine Kennzahl, ein Prozess. Owner mit Budget.

  • Dateninventur: Quellen, Schemas, Zugriffe, Datenschutzklassifizierung.

  • NFRs festlegen: Latenz, Verfügbarkeit, Audit, Kostenkorridor.

Woche 3–6: Backbone und Thin Slice

  • K8s-Cluster, MinIO, Kafka, Iceberg/Delta, Trino, Keycloak, Vault.

  • Ingestion-Pipeline für genau eine Quelle (CDC oder OPC UA) mit Data Contract.

  • Katalogeintrag, Lineage, Data Quality Checks.

  • Thin-Slice-Produkt:

  • Entweder: RAG mit 500 Dokumenten, Evals + Audit.

  • Oder: Streaming-Score auf 1 Maschine, mit Alarm-Workflow ins EAM/MES.

Woche 7–10: Härtung und Observability

  • CI/CD, Canary, Rollback.

  • Drift-Metriken, Business-Dashboards (SLOs).

  • Sicherheitsreview, Pen-Test-Light, Secrets-Rotation.

Woche 11–12: Go/No-Go und Scale-Plan

  • Abnahmekriterien: SLOs grü n, Audit komplett, Kosten im Korridor.

  • Plan zum Hochskalieren (Nutzer/Maschinen x10), Konsequenzen für Compute/Storage.

Häufige Anti-Pattern (bitte nicht)

  • Prompt-Engineering ohne Datenfundament: führt zu Demo-Effekt, keine Produktion.
  • ETL per Notebook: nicht reproduzierbar, nicht betreibbar.
  • Unversionierte Dokumente im RAG: Antworten ohne Quelle sind Compliance-Risiko.
  • “Wir fine-tunen das Modell, dann wird’s schon”: Meist überflüssig. Erst RAG sauber aufsetzen.
  • Evaluationsverzicht: “Sieht gut aus” ist keine Metrik.

Wann Fine-Tuning, wann RAG?

  • RAG zuerst: Wenn Wissen in Dokumenten/Tabellen steckt und sich ändert. Vorteile: Aktualität, Nachvollziehbarkeit, geringe Compute-Kosten.
  • Fine-Tuning:
  • Für Stil/Policy: Lightweight (LoRA) reicht oft.
  • Für domänenspezifische Terminologie nur, wenn RAG nicht reicht und Datenmenge + Labelqualität hoch sind.
  • Hybrid: RAG für Fakten, kleines Policy-Finetune für Tonalität/Sicherheitsvorgaben.

Sicherheits- und Compliance-Grundlagen für LLM/ML on-prem

  • Datenflussdiagramm und DPIA früh: Welche Daten wohin, wer greift zu, Retention.
  • Output-Filter: PII-Redaktion, DLP-Scanner am Ausgang.
  • Zugriffspfade versiegeln: Kein “Testzugang” mit Adminrechten, keine Outbound-Calls aus Air-Gap.
  • Auditierbarkeit: Jede Antwort muss auf Eingaben und Datenstände zurückführbar sein. WORM-Logging.

Was “messbarer Nutzen” konkret heißt

  • Technische Metriken: Latenz, Verfügbarkeit, Fehlerquoten, Drift-Indikatoren.
  • Produktmetriken: Ersparnis pro Fall, vermiedene Stillstandszeit, Erstlösungsquote, NPS für interne Nutzer.
  • Finanzmetriken: Kosten/1000 Anfragen, GPU-Stunden/Tag, Speicherkosten/TB/Monat.
  • Entscheidungsregeln: Kill-Switch bei SLO-Verletzung, Stage-Gates für Investitionsfreigaben.

Fazit

KI kennt Ihr Business nicht. Ihre Sensorik, Ihre Richtlinien, Ihre Prozesse sind der eigentliche “Moat”—und der liegt in Ihrer Datenarchitektur. Wer zuerst Data Contracts, Transport, Lakehouse-Governance und betreibbare Nutzungswege (Feature-Store, RAG, Serving, Observability) baut, liefert in 90–120 Tagen substanzielle Ergebnisse—souverän, DSGVO-konform, skalierbar. Wer mit Modellen anfängt, liefert Demos.

FAQ