KI im Mittelstand: Wo der Einstieg Sinn macht, wie Sie souverän bleiben, und was in 3 Monaten realistisch lieferbar ist

Der Mittelstand tickt anders als Konzerne: kleine, schlagkräftige Teams, viel Domänenwissen, wenig Geduld für Luftschlösser. Genau deshalb sollte ein KI-Projekt nicht mit einem „wir brauchen auch KI“ starten, sondern mit einer klaren technischen Schmerzstelle. Was stört den Betrieb heute? Welche Entscheidungen hängen zu oft am Bauchgefühl? Wo frisst Nacharbeit Zeit? KI ist dann sinnvoll, wenn sie ein konkretes, messbares Risiko oder einen Engpass adressiert – und wenn Architektur, Betrieb und Governance zur Realität eines mittelständischen Unternehmens passen: überschaubare Budgets, vorhandene IT/OT-Infrastruktur, DSGVO-Konformität, keine Abhängigkeit von US-Clouds.

Im Folgenden skizzieren wir praxistaugliche Einstiege, Anti-Pattern, architektonische Blaupausen und einen 12‑Wochen-Fahrplan, der vom ersten Workshop bis zur produktionsnahen Pilotierung reicht. Alles aus der Perspektive von Engineering und Betrieb – nicht aus dem Marketing.

1) Problem zuerst: Vier typische Einstiegsszenarien im Mittelstand

  • Visuelle Qualitätskontrolle: Menschliche Sichtprüfungen sind variabel, ermüden und skalieren schlecht. Klassische Bildverarbeitung kommt an Grenzen, wenn Teile variieren oder Beleuchtung schwankt. Ziel: Fehlerquote und Nacharbeit senken, ohne den Takt zu brechen.
  • Zustandsüberwachung und Anomalieerkennung: Maschinenausfälle kosten Disposition, OEE und Nerven. Sensorik ist vorhanden (Vibration, Temperatur, Stromaufnahme), aber wird kaum systematisch ausgewertet. Ziel: Anomalien früh erkennen, Wartung planbar machen.
  • Dokumenten- und Wissenszugriff: Service und Instandhaltung ertrinken in PDFs, E‑Mails, ERP-Notizen. Gesucht ist eine Antwortenmaschine, die projektspezifisch, nachvollziehbar und offline funktioniert. Ziel: Zeit zur Informationssuche reduzieren, Erstlösungsquote erhöhen.
  • Planungs- und Dispositionsentscheidungen: Kapazitäts- und Auftragsplanung wird oft mit Excel und Bauchgefühl gelöst. Kleine Verbesserungen in Rüstfolgen oder Variantenmix lohnen sich. Ziel: Durchsatz stabilisieren, WIP senken, Liefertermintreue verbessern.

Diese vier Szenarien haben zwei Dinge gemeinsam: 1) Es gibt bereits Daten oder Prozesse, an die man andocken kann. 2) Ein funktionierender Prototyp ist in Wochen erreichbar – ohne komplette Neuausrichtung der IT.

2) Drei Muster, die in 3 Monaten Ergebnisse liefern

A) Visuelle Prüfung am Randgerät (Edge CV)

  • Architektur:

  • Kamera(s) am Band, Beleuchtung fixiert.

  • Inferenz auf einem Industrie-PC direkt an der Linie (x86 mit iGPU/GPU, oder Jetson).

  • Modellklassen: Kombination aus robuster klassischer Bildverarbeitung (OpenCV, geometrische Checks) und leichtgewichtigen Detektoren/Klassifikatoren (z. B. ein quantisiertes YOLO für Detektion, kleiner CNN/ResNet-Variante für Klassifikation), je nach Varianz der Teile.

  • Laufzeitumgebung: Containerisiert (Docker/Podman), Orchestrierung lokal (Systemd/K3s), Updates signiert und offline einspielbar.

  • Schnittstellen: Digital I/O oder OPC‑UA zur SPS, REST/WebSocket zum HMI.

  • Engineering-Tricks:
  • Datenerfassung mit „goldenem Pfad“: 1–2 Wochen systematisches Sammeln mit fixierter Beleuchtung, definierter Teilelage, Markierung von Fehlerklassen, die tatsächlich betriebsrelevant sind.
  • Augmentierung statt Datenschwemme: Licht, leichte Rotation, kleine Verdeckungen synthetisch variieren.
  • Hybridansatz: Wo Regeln genügen (z. B. Lageprüfung), explizite Algorithmen nutzen; ML nur für variable Fehlerbilder. Das reduziert Drift- und Erklärbarkeitsprobleme.
  • Trade-offs:
  • Edge-Inferenz minimiert Latenz und Datentransfer, braucht aber robusten Updateprozess und Hardwarepflege.
  • Cloud-Inferenz fällt wegen Souveränität und Latenz häufig aus. On-Prem‑Cluster ist Option, wenn viele Linien versorgt werden.

B) Anomalieerkennung auf Zeitreihen

  • Architektur:

  • Datenerfassung per OPC‑UA/MQTT oder über vorhandene Historians.

  • Feature-Pipeline mit Schiebefenstern, FFT/Statistikmerkmalen.

  • Modelle: Unüberwacht (Isolation Forest, One‑Class SVM, Autoencoder) für Startphasen; überwachte Modelle erst, wenn genug Label vorhanden.

  • Laufzeit: On-Prem Service (Python/C++), Inferenz als gRPC/REST, Zustellung von Alarmen in vorhandene Systeme (E‑Mail, MS Teams, Andon-Leuchten).

  • Engineering-Tricks:
  • Konzentrieren auf signifikante Ausfälle und deren Vorläufer; ein guter „Recall“ bei moderatem False‑Positive‑Rate ist wichtiger als perfekte Klassifikation exotischer Fehler.
  • Driftmonitoring: Verteilungsverschiebungen auf Kanalebene erkennen, nicht nur Modellmetriken tracken.
  • Feedbackschleife: Jede Rückmeldung des Instandhalters (wahr/falsch) wird als Label, um das Modell iterativ zu schärfen.
  • Trade-offs:
  • Unüberwachte Modelle starten schneller, liefern aber unscharfe Erklärungen. Ergänzen durch erklärbare Features (z. B. Spitzenwerte, RMS).
  • Samplingrate vs. Rechenbudget: Lieber gezielte Kanäle in hoher Frequenz als „alles“ in 1 kHz.

C) On-Prem RAG für technische Dokumente

  • Architektur:

  • Indexierung von PDFs, CAD‑Notizen, Instandhaltungstickets in einem lokalen Vektorindex (z. B. Qdrant/Milvus/Weaviate).

  • Embeddings: Selbstgehostete Modelle (z. B. bge/e5‑Familie) – kein externer API‑Call.

  • LLM-Inferenz lokal: Mittelgroßes Modell (z. B. 7–13B Parameter) quantisiert, deutschfähig, mit strikter Begrenzung auf Retrieved Context. Optional Tool‑Aufrufe (z. B. ERP‑Leserechte) über definierte Adapter.

  • Sicherheitslayer: Authentifizierung/Autorisierung (Keycloak), Auditlog jeder Abfrage (Query, verwendete Dokumentpassagen, Antworten).

  • Engineering-Tricks:
  • Chunking domänenspezifisch (technische Dokus anders als Rechtstexte): Zeichnungen, Tabellen, Bildunterschriften separat behandeln.
  • Strukturiertes Outputformat (JSON mit Feldern wie Quelle, Gültigkeitsbereich, Konfidenz) statt Freitext.
  • Guardrails: Nur aus dem Index zitierte Inhalte erlauben, keine Halluzinationen. Antworten, die keine Evidenz finden, sollen „weiß nicht“ zurückgeben.
  • Trade-offs:
  • Kleinere lokale Modelle sind kontrollierbarer, erfordern aber sorgfältige Retrieval-Qualität. Höhere Modellgrößen bringen selten linearen Mehrwert für domänenspezifische Fragen, kosten aber massiv Ressourcen.

3) Was Sie sich sparen können: Anti-Pattern

  • „Wir bauen erst die perfekte Datenplattform“: Das dauert Monate. Besser: Datenpfad pro Use Case Ende‑zu‑Ende aufbauen und verallgemeinern, wenn der erste Wertbeweis steht.
  • „Ein Chatbot löst unser Wissensproblem“: Ohne RAG, Rechtekonzept und Audit ist das nur ein Demotool. Produktionsreife heißt: Quellenangaben, Zugriffstrennung, Protokollierung, Offline-Fähigkeit.
  • „Wir trainieren ein riesiges Modell von Grund auf“: Unrealistischer Aufwand. Feinabstimmung (LoRA/PEFT) eines vorhandenen Modells oder reine Inferenz reicht in 95 % der Fälle.