Operative Muster zur DSGVO‑Konformität:

  • Rollenrechte strikt: Wer darf Modelle/Pipelines ändern? Wer darf Logs/Prompt‑Historien sehen?

  • Zweckbindung dokumentieren: Für jeden Datensatz (z. B. Hallenkamera 12) ist klar, wofür er genutzt wird, wie lange er gespeichert bleibt, wer Zugriff hat.

  • Nachvollziehbarkeit: Jede Modellversion, jeder Promptwechsel, jede Konfigurationsänderung ist im Audit‑Log. Für LLM‑Assistenten zusätzlich: Safety‑Filter (PII‑Redaktion, Policies), Prompt‑Injection‑Schutz, Ausstiegsbedingungen („Don’t Execute“-Gates), um ungewollte Aktionen zu verhindern.

4) Drei 90‑Tage‑Projekte, die realistisch Nutzen liefern

A) Wissensassistent für Service/Instandhaltung (RAG on‑prem)
Ziel: Techniker finden Antworten in Sekunden statt in Minuten – offline, DSGVO‑konform.

  • Woche 1–2: Datenaufnahme
  • Sammeln: PDF‑Handbücher, Prüfanweisungen, Änderungsmitteilungen, Tickets (ohne PII), FAQ‑Dokumente.
  • Parser bauen: PDF → Text + Struktur (Abschnitte, Tabellen), einfache Normalisierung (Einheiten, Synonyme).
  • PII‑Redaktion für Chat‑Kanal festlegen.
  • Woche 3–4: Index & Embeddings
  • Chunking nach semantischen Abschnitten (z. B. 300–800 Tokens), Titel/Hierarchie als Kontext.
  • Embeddings on‑prem erzeugen; Vektorstore (pgvector) aufsetzen; Metadaten (Bauteil, Revision, Gültigkeitsdatum) indexieren.
  • Woche 5–6: Retrieval‑Evaluierung
  • 50–100 echte Fragen aus Tickets/Field‑Service, Gold‑Antworten durch Domänenexperten kuratieren.
  • Metriken: Hit‑Rate@k, Antwortqualität per human rating; Iteration von Prompts, Reranker optional.
  • Woche 7–8: UI & Rechte
  • Schlanke Web‑App: Fragefeld, Quellenanzeige mit Abschnitt/Seitenzahl.
  • Rollen: Nur Service/Qualität; Logging mit Pseudonymisierung.
  • Woche 9–10: Pilot in einer Linie/einem Team
  • Begleitendes Shadow‑Logging (welche Fragen fehlen?), Feedback‑Buttons, wöchentliche Verbesserungsrunde.
  • Woche 11–12: Härtung
  • Offline‑Updateprozess, Monitoring (Antwortlatenz, Fehlerrate), Backup/Restore, Schulung.

Betrieb:

  • LLM‑Inference on‑prem (z. B. 7–13B‑Klasse, quantisiert), vLLM oder llama.cpp je nach Hardware.

  • Antwortgenerierung strikt „grounded“: Nur mit zitierten Quellen, „I don’t know“-Fallback.

B) Visuelle Anomalieerkennung für Qualitätsprüfung
Ziel: Fehler schneller erkennen, menschliche Prüfer entlasten, ohne 10.000 gelabelte Fehlerbilder.

  • Woche 1–2: Datenpipe
  • Kamerastream anbinden, Bildfrequenz definieren, Trigger am Takt.
  • Gold‑Sample‑Set „Gutteile“ sammeln (mehrere hundert reichen oft), konsistente Beleuchtung/Sicht.
  • Woche 3–4: Baselines & Modell
  • Unüberwachtes Verfahren (z. B. Autoencoder/Student‑Teacher/Embedding‑Vergleich) mit Gutteilen trainieren.
  • Segmentierte Heatmaps für „wo ist die Abweichung“ generieren.
  • Woche 5–6: Metriken & Threshold
  • Labeling von 200–500 Stichproben mit echten Prüfern; definieren, wie teuer False Positives/Negatives sind.
  • Schwellen je Bauteil/Variante kalibrieren.
  • Woche 7–8: Edge‑Deployment
  • Inferenz auf Edge‑PC/Jetson nahe der Kamera; API an Prüftisch/HMI anbinden.
  • Latenzziel: stabil im Takt der Linie.
  • Woche 9–10: Schulung & SOP
  • Klarer Bedienerfluss bei Unsicherheiten; Feedback‑Klick für Nachlabeln/Verbesserung.
  • Woche 11–12: Stabilisierung
  • Drift‑Monitoring (Beleuchtung, Kamerawechsel), Re‑Training‑Fenster und Versionierung.

C) Vorausschauende Instandhaltung „light“ auf bestehenden Sensordaten
Ziel: Frühwarnungen vor Anomalien ohne Komplettumbau.

  • Woche 1–2: Signalaufnahme
  • OPC UA‑Nodes/MQTT‑Topics definieren, Zeitstempel synchronisieren, Samplingraten prüfen.
  • Baseline‑Dashboards für RMS, Kurtosis, Temperatur.
  • Woche 3–4: Regelbasiert starten
  • Domänenbasierte Schwellen/Heuristiken implementieren; Alarme visualisieren, „Alarmmüdigkeit“ vermeiden.
  • Woche 5–6: ML‑Layer
  • Unüberwachtes Modell pro Aggregat (One‑Class/Autoencoder) – Ziel: „anders als normal“.
  • Backtesting mit historischen Daten (wenn vorhanden).
  • Woche 7–8: Pilot & Feedback
  • In einem Werk/Anlage pilotieren, Alarme und tatsächliche Befunde korrelieren.
  • Woche 9–12: Härtung
  • Alarm‑SLA, Störfallprotokoll, geplante Re‑Trainings. Integration in CMMS (Ticket automatisch vorkonfigurieren).

Hardware‑Skizze für 90‑Tage‑Setups:

  • 1× Inferenz‑Workstation im Serverraum (z. B. starker GPU‑Beschleuniger, 128 GB RAM)

  • 1–2× Edge‑Kompaktrechner/Jetson an Kamera/Anlage

  • 1× Storage (S3‑kompatibel oder NAS, 16–32 TB nutzbar)

  • Netzsegment mit restriktiven Firewalls, VLAN für KI‑Dienste

  • USV und basale Monitoring‑Sensorik (Temperatur, Platte)

5) Mittelstand vs. Konzern: Warum Sie schneller sein können

  • Zugriff auf Domänenwissen: Ihre Meisterinnen, Prüfer, Disponentinnen sind greifbar. Nutzen Sie wöchentliche 30‑Minuten‑Reviews mit genau diesen Personen. Entscheidungen entstehen im Betrieb, nicht im Steering‑Komitee.
  • Schlanke Governance: Sie brauchen Reproduzierbarkeit und Audit‑Logs – nicht 20 Freigabestufen. Ein Mini‑MLOps‑Prozess mit MLflow, Git, signierten Releases reicht, wenn er konsequent gelebt wird.
  • Fokus auf eine Wertstrom‑Zelle: Statt „Enterprise‑Plattform“ erst ein Produkt in einer Linie, dann ausrollen. So bleiben Randbedingungen stabil, und die Lernkurve wird nicht verwässert.
  • Architekturstil „wenige, starke Services“: Monolith mit klaren Schichten ist oft besser als zehn Microservices, die ein Zwei‑Personen‑Team kaum im Griff behält.

6) Qualitätssicherung: Metriken, die den Betrieb interessieren

  • Metriken mit Geschäftssinn:
  • Visuelle Prüfung: False Negative‑Quote gewichtet nach Fehlerkosten; Review‑Zeit pro Eskalation.
  • RAG‑Assistent: Top‑k‑Hit‑Rate, Nutzerzufriedenheit, Zeitersparnis pro Ticket, Anteil „I don’t know“ (zu hoch → Coverage‑Problem).
  • PdM: Vorwarnzeit vs. tatsächlicher Befund, Verhältnis „echte Störung“ zu „Alarm“.
  • Akzeptanzkriterien vor dem Pilot definieren:
  • „Go‑Live, wenn FN < X% bei Fehlerklasse A und Durchsatz ≥ Y Bilder/Takt.“
  • „Assistent ersetzt Suchzeit ≥ 50% bei 80% der Anfragen in Bereich Z, mit Quellenangabe.“
  • Testen im Schattenbetrieb:
  • Erst parallel zum bestehenden Prozess mitloggen und bewerten; erst bei stabiler Qualität in Entscheidungen eingreifen.
  • Canary‑Rollouts:
  • Neue Modellversionen an 10% der Nutzer/Anlagen; Monitoring auf KPIs; automatisches Rollback bei Regressionen.

7) Fallstricke und Anti‑Patterns