Pragmatische KI im Mittelstand: Wo der Einstieg Sinn macht (und wo nicht) – souverän, on‑prem, ohne US‑Cloud

Der Mittelstand hat keine Zeit für Hype. Wenn KI eingeführt wird, muss sie ein konkretes Produktions- oder Serviceproblem lösen, in bestehende IT/OT-Strukturen passen und rechtlich sauber sein – ohne Datenabfluss in US‑Clouds. Dieser Beitrag richtet sich an CTOs, VP Engineering und Leiter Digitalisierung im industriellen Mittelstand und beantwortet drei Fragen:

  • Welche Probleme eignen sich für einen KI‑Einstieg – und welche nicht?

  • Wie bringen wir in 12 Wochen ein erstes System in die Produktion, on‑prem, DSGVO‑konform?

  • Welche Architekturbausteine und organisatorischen Muster funktionieren in der Praxis?

Der Blick ist bewusst technisch und problemorientiert. Es geht nicht um „KI ist wichtig“, sondern um Architekturen, Trade-offs und Betrieb.

Womit anfangen – und womit explizit nicht

Gute Startpunkte haben gemeinsam:

  • Das Problem existiert heute spürbar (Qualitätskosten, Stillstände, Suchaufwand, Nacharbeit).

  • Datenzugang ist möglich (Sensorik, Bilder, Dokumente) ohne monatelange IT-Hebearbeiten.

  • Es gibt eine kontrollierte Schnittstelle in den Prozess (Lesen/Schreiben), um Wirkung zu zeigen.

  • Das Fehlerbild ist messbar: Es gibt akzeptierte KPIs und Toleranzgrenzen aus der Linie.

  • Die Lösung kann mit klaren Fallbacks neben dem bestehenden Prozess laufen.

Typische sinnvolle Einstiege:

  • Visuelle Qualitätsprüfung an einer klar abgegrenzten Station (Bauteil X, Merkmal Y).

  • Anomalieerkennung an Rotating Equipment (Vibration/Temperatur), erst unsupervised, dann verfeinern.

  • Technische Wissenssuche über Montage- und Service-Dokumente (RAG – Retrieval Augmented Generation) mit lokalem LLM.

  • Ticket- oder Vorfalls-Triage (Klassifikation, Duplikaterkennung) in Service/After-Sales.

Wovon wir abraten für den Einstieg:

  • „Unternehmensweiter KI‑Assistent“ ohne klare Business‑Schnittstelle, der überall ein bisschen helfen soll.

  • Seltene Safety‑kritische Ereignisse ohne ausreichende Datenbasis und ohne Simulationsmöglichkeit.

  • Projekte, die erst ein neues Data Lakehouse, fünf neue Tools und drei Prozesse erfordern, bevor irgendetwas läuft.

  • POCs nur auf PowerPoint‑Niveau, ohne Integration in die reale IT/OT‑Umgebung.

Drei Projekte, die in 12 Wochen Ergebnisse liefern

1) Visuelle Qualitätsprüfung an einer Station

Ziel: Falsch‑Negativ‑Rate für Defekte senken und Prüfzeit stabilisieren.

Datenlage:

  • 1–3 Kameras an einer Station, kontrollierte Beleuchtung.

  • 1–5k Bilder aus realer Linie, minimal gelabelt (OK/NOK). Falls keine Labels: schwache Labels mit Prozessdaten (z. B. Nacharbeit) koppeln.

Architektur grob:

  • Edge‑Inference auf IPC mit GPU‑Beschleunigung.

  • Inferenz‑Service als Container, lokale Model-Registry, Konfig via Git.

  • Bildablage on‑prem, Zugriff via SMB/NAS oder S3‑kompatibles Storage.

  • Integration in SPS/MES via OPC UA oder REST für Rückmeldung/Stop/Andon.

Vorgehen in 12 Wochen:

  • Woche 1–2: Datensichtung, Kameraprüfung, Golden Sample definieren, Labeling‑Policy.

  • Woche 3–4: Baseline Modell (klassische Bildverarbeitung + CNN), Metriken fixieren (Precision/Recall, FPR/FNR).

  • Woche 5–6: Edge‑Deployment im Ghost‑Mode (nur beobachten), Latenz und Stabilität testen, Drift-Monitoring aktivieren.

  • Woche 7–8: Human‑in‑the‑Loop (Operator bestätigt Grenzfälle), aktives Lernen für neue Defekt‑Varianten.

  • Woche 9–10: Fallback‑Design (bei Unsicherheit -> Handprüfung), Alarmierung, Audit‑Logs.

  • Woche 11–12: Abnahme mit Produktion, Schulung, Monitoring-Dashboards, Change‑Freeze.

Besonderheiten Mittelstand:

  • Ein sauberer Licht- und Kamera‑Mount ist oft wichtiger als das nächste „State of the Art“‑Modell.

  • Tolerieren Sie 5–10% Unklar‑Klasse am Anfang und optimieren Sie mit Human‑in‑the‑Loop.

2) Predictive Maintenance für drehende Aggregate

Ziel: Frühwarnzeit vor Ausfällen schaffen und Inspektionsintervalle datenbasiert anpassen.

Datenlage:

  • Vibrationssensorik (AE, Beschleunigung) und Temperatur, 1–5 Hz bis kHz, abhängig von Aggregat.

  • Historie von Störungen/Nacharbeit wünschenswert, aber nicht zwingend.

Architektur grob:

  • Zeitreihenaufnahme on‑prem (TSDB), Feature‑Extraktion (z. B. Spektralmerkmale) als Batch‑Jobs.

  • Unsupervised Anomalie‑Modelle für Start (z. B. Rekonstruktion/Clustering) plus robuste Schwellen.

  • Ereignis‑Pipeline in CMMS/Ticketing, klare Befundtexte, keine Blackbox‑Signale.

  • Edge‑ oder Zellen‑nahe Verarbeitung, um Netzwerkabhängigkeit zu reduzieren.

Vorgehen in 12 Wochen:

  • Woche 1–2: Sensorik‑Check, Datenpfad und Zeitstempel‑Konsistenz sicherstellen.

  • Woche 3–4: Feature‑Baseline, einfache Schwellen, Alarm‑Fatigue vermeiden (konservative Trigger).

  • Woche 5–6: Unsupervised‑Modell anlernen, Rekonstruktionsfehler als Score, Drift‑Detektor aktivieren.

  • Woche 7–8: Ghost‑Mode gegen Wartungslog, Precision/Lead‑Time messen.

  • Woche 9–10: Integration CMMS, differenzierte Schweregrade, Rückmeldeschleife mit Instandhaltung.

  • Woche 11–12: SOP für Alarmklassifikation, Review Zyklen, Monitoring der Modellgüte.

Besonderheiten Mittelstand:

  • Lieber zwei solide Sensoren sauber montiert und kalibriert als zehn halbgare Messpunkte.

  • Starten Sie unsupervised; supervised Klassifikatoren erst, wenn belastbare Labels vorhanden sind.

3) Wissenssuche für Montage/Service (RAG mit lokalem LLM)

Ziel: Technische Fragen zu Varianten, Drehmomenten, Prüfvorschriften schneller beantworten, ohne proprietäre Cloud‑Dienste.

Datenlage:

  • Unstrukturierte Dokumente: PDFs, CAD‑Ableitungen, Bilder, interne Wikis, E‑Mails.

  • Berechtigungen oft fein granuliert (Arbeitsvorbereitung vs. Service vs. Lieferant).

Architektur grob:

  • On‑prem Vektorindex für Text/Tabellen/Bilder, periodische und eventbasierte Indizierung.

  • LLM‑Inference on‑prem (Containerisiert), Prompt‑Templates je Use‑Case, Abruf mit Kontextfenster.

  • Zugriffskontrolle auf Dokumentebene (ABAC), Berechtigungen schon im Retriever erzwingen.

  • Observability/Governance: Pro Prompt Versionierung, Tool‑Calls, Datenherkunft, Redaktions‑Workflows.

Vorgehen in 12 Wochen:

  • Woche 1–2: Korpus definieren, Datenqualität (OCR, Tabellen) heben, Zugriffsklassen klären.

  • Woche 3–4: Retriever‑Baseline, Chunking‑Strategie, Domain‑Synonymlexikon, Passage‑Scoring evaluieren.

  • Woche 5–6: LLM‑Antwort mit Zitaten, keine Halluzinationen durch „Answer only from provided context“-Policy.

  • Woche 7–8: Evaluationssatz aus echten Fragen, Metriken: Retrieval‑Hit@k, Faithfulness, Antwortzeit.

  • Woche 9–10: Integration mit DMS/AD, Audit‑Logs, PII‑Redaktion, Prompt‑Hardening.

  • Woche 11–12: Pilot mit Service‑Team, Feedbackschleifen, Eskalationspfad zu menschlichen Experten.

Besonderheiten Mittelstand:

  • Domänensprache ist Gold. Ein überschaubares Synonym‑ und Abkürzungsverzeichnis bringt oft mehr als ein größeres Modell.

  • Ohne Zugriffskontrolle im Retriever (nicht erst im LLM) entstehen Leaks durch Side‑Channels.

On‑prem Architekturbausteine für datensouveräne KI