Pragmatische KI im Mittelstand: Wo der Einstieg Sinn macht, wie Sie souverän bleiben – und was Sie bewusst weglassen sollten

Aus Sicht eines mittelständischen Industrieunternehmens ist die erste KI-Initiative kein Technologieproblem, sondern ein Engineeringproblem: Wo bringt KI im Prozess wirklich einen messbaren Hebel, wie integrieren wir sie in bestehende Systeme – und wie behalten wir die volle Souveränität über Daten, Modelle und Betrieb? Wer hier klar priorisiert und pragmatisch vorgeht, kann in drei Monaten ein nutzbares Ergebnis liefern. Wer stattdessen „KI“ als Selbstzweck verfolgt, verheddert sich schnell in POCs ohne Produktionsreife oder gerät in eine teure Cloud-Abhängigkeit, die weder DSGVO-konform noch beherrschbar ist.

Dieser Beitrag richtet sich an CTOs, VP Engineering und Leiter Digitalisierung im DACH-Mittelstand. Er liefert ein konkretes Vorgehensmodell, technische Architektur-Patterns für datensouveräne KI und klare Grenzen, wo Sie besser nicht starten.

Wo der Einstieg wirklich Sinn macht

Vier Einstiegspunkte, die sich in mittelständischen Projekten besonders bewährt haben:

1) Visuelle Qualitätsprüfung/Fehlerdetektion

  • Problem: Wiederholte Fehlerklassen, die menschliche Prüfer ermüden oder übersehen; hoher Ausschuss oder Nacharbeit.

  • Warum KI hier funktioniert: Das Setup ist kontrollierbar (Kamera, Beleuchtung, definierte Merkmale), das Feedback ist binär (ok/nicht ok), der Nutzen ist unmittelbar messbar (FP/FN-Rate, Taktzeit).

  • Start klein: Ein Produkt, eine Station, 1–2 Kamera-Positionen. Ziel: In 8 Wochen ein Modell, das im Schattenmodus (keine Eingriffe) stabil Fehler detektiert und sauber geloggt wird.

  • Integration: Inference am Rand (Edge) nahe der Linie, Ergebnis via OPC UA/MQTT an SPS/MES. Immer mit deterministischem Fallback (regelbasierter Prüfschritt oder menschliche Freigabe).

  • Technikmuster: Industrietaugliche Kamera, reproduzierbare Beleuchtung; Edge-Rechner mit NVIDIA RTX/Industrial GPU oder Intel iGPU+OpenVINO; Triton Inference Server oder ONNX Runtime; Versionierung der Datensätze und Modelle.

2) Zustandsüberwachung und prädiktive Instandhaltung

  • Problem: Ungeplante Stillstände, teure Lagerhaltung für Verschleißteile, starre Wartungsintervalle.

  • Warum KI hier funktioniert: Sensorik (Schwingung, Strom, Temperatur, Zählerstände) ist oft bereits vorhanden oder kostengünstig nachrüstbar; Anomalieerkennung ist robust, auch ohne perfekte Label.

  • Start klein: Ein Aggregat, ein klarer Ausfallmodus, 4–6 Wochen Datensammlung. Erst Anomalieerkennung, später spezifische Fehlerklassifikation.

  • Integration: Streaming in ein Timeseries-System on-prem; Benachrichtigungen in bestehende Wartungstools.

  • Technikmuster: OPC UA/Kafka/MQTT als Datenpfad; TimescaleDB/InfluxDB; Modelltraining offline, Inferenz nahe der Quelle (Edge) für niedrige Latenz.

3) Dokumenten- und Wissensarbeit mit RAG (Retrieval-Augmented Generation)

  • Problem: Technische Teams verschwenden Zeit mit der Suche in Handbüchern, Wartungsprotokollen, Normen; Wissen sitzt in PDFs, SharePoint, Netzlaufwerken.

  • Warum KI hier funktioniert: RAG nutzt Ihr internes Wissen, keine Halluzinationen ins Blaue. On-Prem-LLMs sind ausreichend gut für präzise, quellengestützte Antworten.

  • Start klein: Ein Bereich (z. B. Instandhaltung eines Maschinentyps), 500–2000 Dokumente, klare Evaluationsfragen. Antworten immer mit Quellenangabe.

  • Integration: Zugriffskontrolle über das bestehende AD/LDAP, vollständige Audit-Logs. Keine Daten verlassen das Firmennetz.

  • Technikmuster: Embedding-Modell on-prem, Vektorspeicher (pgvector/Qdrant), RAG-Pipeline, LLM-Inferenz lokal (z. B. 7B–13B Modelle, ggf. quantisiert). Evaluierung mit vorab definiertem Fragensatz.

4) Prozessüberwachung auf Basis von Kennzahlen

  • Problem: Unerklärliche Abweichungen in Taktzeit, Energieverbrauch, Ausschussquote.

  • Warum KI hier funktioniert: Zeitreihen-Anomalieerkennung erfordert keine aufwendigen Labels und liefert frühzeitige Warnungen.

  • Start klein: Eine Linie, 10–20 Signale, 4 Wochen Datenhistorie. Ziel: Präzise Alarme statt Alarmflut.

  • Integration: Visualisierung im bestehenden Dashboard, Maßnahmen mit dem Schichtleiter abgestimmt.

  • Technikmuster: Feature-Skalierung, gleitende Fenster, robuste Schwellenlogik, Alarm-Suppression.

Wo der Einstieg nicht lohnt (noch nicht)

  • Safety-kritische Regelkreise in Echtzeit: Wenn das System bei Fehlentscheidung Menschen gefährdet oder Anlagen zerstört, beginnen Sie nicht mit einem lernenden Modell im Loop. Erst Monitoring, dann Entscheidungsunterstützung, sehr spät (wenn überhaupt) Autonomie.
  • Hohe Varianz, kein Standardprozess: Wenn jeder Auftrag Unikat-Charakter hat und sich Merkmale kaum wiederholen, fehlt die Datengrundlage für verlässliche Muster.
  • „Erstmal Datensee bauen“: Ein Data Lake ohne konkrete Fragestellung führt zu hoher Komplexität ohne schnellen Nutzen. Datenakquise muss vom Use Case getrieben sein.
  • „KI ersetzt Fachkräfte“: Gute KI entlastet Fachkräfte von repetitiven Tätigkeiten. Wo Domänenwissen fehlt, wird das System instabil.
  • Kein Owner: Wenn niemand im Betrieb Verantwortung für die KPI und das Nachsteuern übernimmt, bleibt es beim Prototypen.

Architektur-Patterns für datensouveräne KI

Das Ziel ist klar: DSGVO-konforme, vollständig on-prem betriebene Systeme, die ohne US-Cloud auskommen und auditierbar sind. Vier Muster, die sich wiederholen:

1) On-Prem LLM mit RAG und Funktionsaufrufen

  • Komponenten:

  • Dokumentenaufnahme: Dateifreigaben, DMS/ECM, E-Mail-Gateways. Vorverarbeitung (OCR, Layout-Parsing).

  • Embeddings: On-prem Embedding-Modell, kein externer Dienst. Chunking mit Domänenregeln.

  • Vektor-Datenbank: Selbst gehostet (z. B. PostgreSQL mit pgvector oder Qdrant).

  • LLM-Inferenz: Lokales Modell (7B–13B für deutsche/englische Fachtexte oft ausreichend). Quantisierung möglich für CPU/kleine GPUs.

  • RAG-Orchestrierung: Query-Rewriting, Dokumentauswahl, Antwort mit Zitaten. Optional: Funktionsaufrufe in interne Systeme (z. B. SAP-Read, Ticket anlegen).

  • Governance: Prompt-/Kontext-Versionierung, Protokollierung, Rollenkonzepte, Datenschutz (PII-Redaktion) vor Persistenz.

  • Betriebsmodell: Containerisiert (OCI), Kubernetes oder schlanker Orchestrator; GitOps für reproduzierbare Deployments; Air-Gap-fähige Updates via Registry-Mirror.

2) Visuelle Prüfung am Edge

  • Komponenten:

  • Sensorik: Industriekameras, deterministische Triggerung, stabile Beleuchtung.

  • Inferenz: Edge-Rechner mit GPU oder beschleunigter CPU; Inference-Server (z. B. Triton, OpenVINO).

  • Kommunikationspfad: Ergebnisse via OPC UA/MQTT an SPS/MES, inklusive Konfidenzwert und Bild-Hash.

  • Rückkopplung: Beschriftungstool on-prem, Golden Dataset, geplanter Re-Train-Zyklus (monatlich/vierteljährlich).

  • Fallback: Wenn Konfidenz unter Schwellwert, automatische Überleitung in manuelle Prüfung. Keine Blockade der Linie.