KI im Mittelstand: Wo der Einstieg Sinn macht (und wo nicht), wie Sie in 12 Wochen Ergebnisse liefern – ohne Souveränität zu verlieren

Der deutsche Mittelstand hat zwei Eigenschaften, die bei KI-Projekten den Unterschied machen: extrem hohes Domänenwissen und kurze Entscheidungswege. Was fehlt, sind oft die richtigen technischen Leitplanken, um aus Ideen in wenigen Monaten robuste Software zu machen – souverän, auditierbar und ohne Abhängigkeit von US‑Clouds. Dieser Beitrag ist bewusst unaufgeregt: keine Fantasiezahlen, keine One‑Size‑Fits‑All‑Lösungen. Stattdessen konkrete Muster, Architekturen und Checklisten aus Projekten, die in Werkshallen, Leitständen und sicherheitskritischen Umgebungen laufen.

Problem zuerst: Woran Sie erkennen, ob ein KI‑Vorhaben reif ist

Bevor Technologie ins Spiel kommt, prüfen Sie fünf Basics. Wenn eines davon fehlt, ist ein KI‑Pilot meist vorprogrammiert schwierig – unabhängig davon, welches Modell oder welcher Anbieter gewählt wird.

  • Datennähe: Zugriff auf die relevanten Rohdaten mit ausreichender Qualität und zeitnaher Verfügbarkeit. Kein “Wir exportieren mal CSVs vom Lieferanten in sechs Wochen”.
  • Prozess-Stabilität: Der Zielprozess ist stabil genug, dass Verbesserungen messbar sind. Wer jede Woche Arbeitsanweisungen ändert, bekommt kein sauberes Baseline-vs.-KI‑Delta.
  • Integration machbar: Ein realistischer Integration‑Punkt zurück ins operative System existiert (MES, ERP, DMS, Ticketing). Ein Dashboard ohne “Actuation” bringt selten ROI.
  • Entscheider greifbar: Ein benannter Product Owner auf Fachseite mit Mandat, schnelle Entscheidungen zu treffen (Scope, Akzeptanzkriterien, Deadlines).
  • Messbare Metriken: Vorab definierte Qualitäts- und Erfolgsmetriken (z. B. Reduktion Falsch-Positiv‑Raten, Durchlaufzeit, MTTR, OEE‑Beitrag).

Wenn Sie hier nicken können, lohnt es sich weiterzugehen. Wenn nicht, investieren Sie zuerst in Erschließung und Prozessklarheit – das ist keine verlorene Zeit, sondern reduziert Projekt‑Risiko um Größenordnungen.

Wo der Einstieg Sinn macht – und wo nicht

Sinnvoll für die ersten 3–6 Monate sind Use‑Cases mit:

  • Klarem Datenpfad: Kamerastreams, OPC‑UA‑Signale, Logfiles, Tickets – keine “Dark Data”.
  • Niedriger Integrationskomplexität: Ein System, ein Owner, ein klarer Nutzerkreis.
  • Hohem Wiederholungsgrad: Viele gleichartige Entscheidungen, um Modelle zügig zu trainieren und zu bewerten.

Bewährte Einstiege im Mittelstand:

  • Computer Vision in der Qualitätssicherung: Bauteil‑, Lack‑ oder Textiloberflächenprüfung, Vollständigkeitskontrolle, visuelle Montagefehler.
  • Zustandsüberwachung und Anomalieerkennung: Vibrations- oder Stromsignale von Motoren, Pumpen, CNC‑Aggregaten.
  • Dokumenten- und Wissenszugriff mit LLMs: Technische Handbücher, Wartungsprotokolle, Materialdatenblätter, Normen – als präzise, geprüfte Antworten statt Volltextsuche.

Weniger geeignet für den Einstieg:

  • Stark verteilte Endanwender‑Szenarien ohne klare Governance (z. B. “alle Teams bekommen jetzt ChatGPT‑Accounts und machen irgendwas mit Prompts”).
  • Prozesse mit geringer Datenbasis und hoher regulatorischer Last, die zunächst umfangreiche Freigaben erfordern.
  • “Moonshots” ohne messbaren Zwischenwert in < 12 Wochen.

Architektur-Muster, die in der Praxis funktionieren

1) Visuelle Qualitätsprüfung auf dem Shopfloor

Ziel: Inline‑Erkennung von Defekten oder Montagefehlern bei variierender Beleuchtung, mit restriktiven Netzwerkanforderungen.

  • Edge‑First: Inferenz am Band auf x86‑Industrie‑PC mit GPU oder industriellem ARM‑Gerät. Keine Kamera‑Streams in die Cloud.
  • Datenpfad: Kamera → lokaler Framebuffer → Preprocessing (Entzerrung, Normalisierung) → Inferenz (ONNX/TensorRT) → Ergebnis via OPC‑UA/MQTT an SPS/MES.
  • Modellstrategie: Start mit robusten klassischen Verfahren als Baseline (Template Matching, Morphologie), parallel Deep‑Learning‑Backbone (z. B. Segmentierung) – Champion/Challenger‑Setup.
  • Betriebsmodell: GitOps für Konfigurationen, versionierte Modelle, Blue/Green‑Rollout Zelle für Zelle. Rückkanal für Nutzerfeedback (falsch erkannt/richtig erkannt).
  • Robustheit: Beleuchtungs‑Kalibrierung, station‑spezifische Domänenadaption, Datenaugmentation aus realen Betriebsbedingungen.

2) Prädiktive Instandhaltung via Zeitreihen

Ziel: Frühe Anomalien erkennen, ohne tausende gelabelte Ausfälle zu brauchen.

  • Konnektivität: OPC‑UA oder Feldbus‑Gateway → Timeseries‑Datenbank (lokal) → Streaming‑Features (RMS, Kurtosis, Spektralmerkmale).
  • Modellstrategie: Unüberwachte oder schwach überwachte Verfahren (Isolation Forest, One‑Class SVM, Autoencoder) kombiniert mit regelbasierten Guardrails aus Domänenwissen.
  • Drift-Handling: Gleitende Baselines pro Maschine, kontrollierte Anpassung an Verschleiß vs. echte Störungen.
  • Integration: Alerts in bestehende Ticketsysteme, nicht in yet‑another‑Dashboard. Akzeptanz steigt, wenn der Meister die Warnung dort sieht, wo er ohnehin arbeitet.
  • Erklärbarkeit: Feature‑Beiträge und Rohsignatur beilegen, so dass Instandhalter plausibilisieren können.

3) Wissenssysteme mit LLM und RAG – DSGVO- und on‑prem‑fähig

Ziel: Genaue, überprüfbare Antworten auf betriebliche Fragen, ohne Daten nach außen zu geben.

  • Datenpipeline: DMS/Confluence/Share → Extraktion → Chunking → Embeddings → Vektorindex (on‑prem, z. B. PostgreSQL mit pgvector oder eine eigenständige On‑Prem‑Engine).
  • Retrieval‑Augmented Generation: Strikte Trennung zwischen Retrieval und Generierung, Quellenbelege immer zurückgeben, Zitationspflicht erzwingen.
  • Zugriffskontrolle: SSO‑Integration, rollenbasierte Filter bereits im Retrieval (Row‑Level‑Security), nicht erst im UI.
  • Modelle: Lokale Inferenz oder EU‑gehostete Modelle mit klaren Datenverarbeitungsgrenzen. Für sensible Inhalte On‑Prem‑LLMs mit quantisierten Gewichten sind praktikabel, sofern Prompts/Antworten im Haus bleiben.
  • Governance: Protokollierung von Prompts/Antworten, Feedback‑Schleife, Halluzinations‑Quoten, red‑teaming von Prompt‑Injection. In produktiven Umgebungen hilft dedizierte Observability/Governance‑Software, die ohne US‑Cloud auskommt.

On‑Premise vs. Cloud: Souveränität ist kein “Nice‑to‑Have”

Für den Mittelstand ist Souveränität kein politisches Statement, sondern Risikomanagement und Betriebssicherheit:

  • Datenflüsse kontrollieren: Edge/On‑Prem‑Inferenz vermeidet, dass Produktions- oder Personen‑Daten externe Dienste verlassen. Das reduziert juristische Komplexität und technische Angriffsfläche.
  • Ersatzteil statt Blackbox: Setzen Sie auf Architekturen, die Sie mit eigenem Team betreiben können. Containerisierte Dienste, reproduzierbare Deployments, offene Schnittstellen, Export‑/Exit‑Wege.
  • LLM‑Sicherheit: Prompt‑Injection, Tool‑Abuse, Datenexfiltration – diese Themen erfordern Policies und technische Schranken. On‑Prem lässt sich konsequent härten: Allowlists für Tools, strenge Output‑Filter, keine “surfen‑gehenden” Agents ohne Proxy‑Kontrolle.