Archetyp B: Zustandsüberwachung und Anomalieerkennung für rotierende Maschinen

  • Problem: Lagerschäden, Unwucht, Fehljustage frühzeitig detektieren, ohne tausende gelabelte Ausfallfälle.

  • Daten: Schwingungen/Schall (z. B. 1–10 kHz Sampling), Stromaufnahme, Temperatur. Historie von Wochen/Monaten reicht für Start.

  • Architektur:

  • Sensor → Edge-Gateway (OPC UA/MQTT) → Stream (Kafka/Redpanda) → Time-Series DB (InfluxDB/Timescale)

  • Feature-Pipeline: Zeit- und Frequenzfeatures (RMS, Kurtosis, Bandpower, Spektralpeaks)

  • Modelle: Unsupervised Anomaly Detection (Isolation Forest, One-Class SVM) oder Autoencoder; pro Maschine/Typ getrennt

  • Alarmierung: Schwellen dynamisch, Hysterese, Debounce; Ticketsystem-Integration

  • Trade-offs:

  • Ohne gelabelte Ausfälle sind Alarme „anomal“ und nicht „diagnostisch“ – akzeptieren und mit Domänenwissen mappen (Anomaliecode → Prüfprozedur)

  • Datenqualität (Sensorbefestigung, Drift) ist oft limitierend. Investieren Sie früh in Sensormontage-Standards.

  • Deliverables nach 12 Wochen:

  • Live-Anomalie-Score pro Maschine mit begründetem Schwellenkonzept

  • MTTD-Verbesserung quantifiziert an historischen Events

  • Minimaler Diagnose-Playbook: „Bei Anomalie X → Messung Y, Inspektion Z“

Archetyp C: LLM-gestützte Wissensarbeit: Technische Wissenssuche (RAG) für Service/Engineering

  • Problem: Wartungspläne, Schaltpläne, Normen und Störungsberichte sind verteilt; Suchen kostet Zeit; Antworten müssen nachvollziehbar sein.

  • Daten: PDFs, CAD-Exports, Confluence/SharePoint-Daten – lokal synchronisiert; Metadaten (Gültigkeit, Version).

  • Architektur:

  • Ingestion: Parser (PDF, DOCX, CAD-Text), domänenspezifisches Chunking (z. B. pro Kapitel/Bauteil)

  • Embeddings lokal (BGE/E5-Klasse); Vektor-DB (Qdrant); Retrieval mit Hybrid-Suche (BM25 + Vektor)

  • LLM-Serving On-Prem (vLLM) mit 7–13B-Klasse Modell; Prompt-Template mit Zitatenpflicht (Quellenliste)

  • Guardrails: Tool-Use nur weißgelistet; Antwort nur aus Zitaten; „Keine Quelle → Keine Antwort“

  • Observability: Prompt-/Tool-Logs; Halluzinations-Benchmarks (Antwort mit/ohne Quellen)

  • Trade-offs:

  • Kleine LLMs sind günstiger und einfacher on-prem, aber brauchen starkes Retrieval und strikte Prompting-Policies

  • Dokumentversionierung kritisch: „Gültig ab/bis“ muss im Chunk landen, sonst entsteht veraltetes Wissen

  • Deliverables nach 12 Wochen:

  • Produktiver Such-Assistant mit Quellenangaben

  • Evaluations-Set mit 50–100 realen Fragen, Metriken: Hit Rate@k, Antwort mit Quelle

  • Rechte- und Rollenmodell (z. B. Mandant Werk A/B, Rolle Service vs. Engineering)

4) Warum Mittelstand oft schneller ist – wenn man richtig organisiert

  • Kürzere Entscheidungswege: Nutzen Sie das, indem Sie einen „Product Owner KI“ benennen, der Budget und Abnahmebefugnis hat.
  • Direkter Zugang zum Shopfloor: Binden Sie 1–2 erfahrene Facharbeiter pro Linie ein. Ihre 2 Stunden pro Woche sparen später Wochen an Fehlentwicklung.
  • Schlanke Governance: On-Prem reduziert Datenschutzabstimmung. Dafür: klare Policies, automatische Checks (z. B. Outbound-Traffic blockiert, SBOM vorhanden), und ein leichtgewichtiger Freigabeprozess.
  • Iteration statt Masterplan: Monatliche, nicht jährliche Roadmaps. Erfolgreiche Mittelständler liefern Teilnutzen im 1. Quartal und erweitern entlang messbarer Outcomes.

Organisationspattern:

  • Wöchentliches Tech/Domain-Sync (30 Minuten): offene Datenprobleme, Ground Truth, Drift

  • Zwei Umgebungen reichen zunächst: Integration (INT) und Produktion (PRD); vermeiden Sie „Test-Wildwuchs“

  • Akzeptanzkriterien als If-Then: „Wenn FP-Rate > 5% in Schicht 3, dann Rollback auf Modell v0.9“

5) LLM-Agenten on-prem: Observability und Governance sind Pflicht, nicht Kür

Sobald LLMs Tools nutzen (z. B. ERP-Abfragen, Ticketanlage), sind sie Agenten. Ohne Observability sind Sie blind für Kosten, Fehler und Sicherheitsvorfälle.

Minimal-Set für produktionsreife Agenten:

  • Prompt-/Tool-Registry: Versionierte Systemprompts, Tool-Schemas, Rollout-Matrix

  • Token-Level-Metriken: Tokens in/out, Latenz, Cache-Hit-Rate – je Endpoint, je Mandant

  • Audit-Trail: Wer hat was gefragt, welches Dokument wurde zitiert, welcher Tool-Call wurde ausgeführt – unter RBAC, revisionssicher

  • Policy Engine:

  • Keine externen HTTP-Calls

  • Maximaler Tool-Fanout

  • PII-Leak-Prevention (Regeln und Klassifizierer)

  • Replay & Offline-Test: Produktions-Traces als Testfälle in CI; Regressionen erkennen, bevor Sie deployen

  • Halluzinationsbudget: Fail-Closed bei fehlenden Quellen, definierte Fallback-Dialoge

Ohne diese Bausteine wird ein LLM „gefühlt nützlich“, aber betrieblich unvertretbar. Gerade on-prem sind diese Komponenten implementierbar, weil Sie volle Kontrolle über Metriken und Logs haben.

6) Infrastruktur pragmatisch planen: Kapazität, Kosten, Upgrades

  • Hardware-Start:
  • Ein kompakter Inferenz-Server (z. B. 2× L4 oder A4000/A4500-Klasse) deckt 7–13B LLMs in int4-Quantisierung und mehrere CV/AD-Modelle parallel ab.
  • Edge-Geräte bei Bild-/Signalverarbeitung verringern Netzlast; rollen Sie Modelle per Container-Image aus.
  • Kapazitätsplanung:
  • LLM-Kapazität in Tokens/Sekunde planen. Beispiel: 13B int4 auf L4 ≈ ausreichend für dutzende parallele kurze Anfragen mit Prompt-Caching.
  • CV/Signal-Modelle in FPS oder Maschinenzahl rechnen. Puffer für Updates und Retraining einplanen.
  • Software:
  • Kubernetes sinnvoll ab 2–3 Knoten oder wenn mehrere Teams/Workloads. Sonst: Docker-Compose + klare Namensräume reicht am Anfang.
  • Updates offline: Artifakt-Mirror, signierte Bundles, Change-Log, Rollback-Plan.
  • TCO:
  • Ein sauberer On-Prem-Stack spart wiederkehrende API-Kosten und verringert Compliance-Aufwand. Betrieb erfordert DevOps-Disziplin. Rechnen Sie Betreuungsanteile explizit (z. B. 0,5–1,0 FTE für 1–2 Cluster).

7) Vorgehensmodell: 12 Wochen von Problem zu Pilot

  • Woche 1–2: Problem-Präzisierung und Datenkontrakt
  • Zielmetrik(en) definieren, Messbarkeit klären
  • Datenquellen inventarisieren; minimaler Datenextrakt; Datenschutz-Checklisten
  • Erfolgskriterien schriftlich fixieren (Cutoffs, FP/FN, Latenz, Kostenziele)
  • Woche 3–4: Baseline und Architektur
  • Baseline-Modell (klassisch/regelbasiert oder vortrainiertes Modell ohne Fine-Tuning) als Vergleich
  • Zielarchitektur in Infra-as-Code (Terraform/Ansible) und CI/CD-Pipeline
  • Observability früh aktivieren (Metriken, Logs, Traces)
  • Woche 5–8: Iteration am realen Prozess
  • Active Learning/Labeling-Loop
  • Domänenspezifische Heuristiken ergänzen (z. B. Masken, Zonen, Spektralbänder)
  • Sicherheitshärtung: Outbound-Block, Secrets, RBAC, Audit-Logs
  • Woche 9–10: Pilotbetrieb
  • Shadow Mode oder A/B gegen manuellen Prozess
  • Drift-Monitoring und Fallback-Strategien testen
  • Nutzerfeedback strukturiert erfassen (Fehlermeldungen mit Kontext)