Titel: KI im Mittelstand: Wo der Einstieg wirklich Sinn macht (und wo nicht) – souverän, DSGVO-konform und in 90 Tagen messbar

Einleitung – Das Technikproblem vor dem Hype
Viele Mittelständler sitzen heute auf zwei gegensätzlichen Anforderungen: Sie wollen produktive KI nutzen, aber dürfen keine sensiblen Daten in US‑Clouds bewegen. Gleichzeitig sind Teams klein, Budgets pragmatisch und jede neue Komponente muss sich in bestehende IT und Produktionsprozesse einfügen. Der Kern des Problems ist daher nicht “KI einführen”, sondern: Welche konkrete Aufgabe löse ich, mit welcher Architektur, auf welcher Hardware – so, dass Datenschutz, Auditierbarkeit und langfristige Wartbarkeit stimmen?

Dieser Beitrag richtet sich an CTOs und Leiter Digitalisierung, die KI nicht als Experiment, sondern als Betriebsmittel denken. Die folgenden Empfehlungen basieren auf typischen Projekten in Industrieumgebungen aus Bereichen wie Fertigung, Bahn, Bau und Textil – mit Fokus auf On‑Premise-Betrieb, Datensouveränität und reproduzierbarer Software-Engineering-Praxis.

Wo der Einstieg Sinn macht: Drei belastbare Muster
Es gibt drei Einsatzmuster, die im Mittelstand mit vertretbarem Aufwand und klarer Architektur schnell Wirkung zeigen. Sie sind bewusst eng geschnitten, damit sie innerhalb eines Quartals messbare Ergebnisse liefern.

1) Dokumentenintelligenz für Service, Qualität und Einkauf (RAG statt Bauchgefühl)
Typische Frage: Wie finde ich in Tausenden PDFs (Handbücher, Prüfberichte, Spezifikationen) zuverlässig die richtige Information – ohne Cloud?

Technikmuster:

  • Datenquellen: Fileshares, SharePoint, DMS. Lesend anbinden, keine proprietären Exportformate voraussetzen.

  • Vorverarbeitung: OCR (für Scans), Chunking nach Überschriften/Absätzen, Erhalt von Kontext (Dokumenten-ID, Kapitel, Seitenzahl).

  • Embedding und Index: On‑Prem Vektordatenbank (z. B. Qdrant, Milvus) mit 512–1024 Token Chunks, Metadatenfilter (z. B. Werk, Sprache, Gültigkeitsdatum).

  • Abfrage: Retrieval-Augmented Generation (RAG) mit lokalem LLM (8–13B Parameter) oder klassischen Suchoperatoren plus Antworterzeugung. Keine sensiblen Daten verlassen das Werk.

  • Governance: Versionierte Indizes (Index v1, v2…), Audit-Logs für jede Antwort (Prompt, Quellen, Modellversion), Rollback-fähig.

Warum das funktioniert:

  • Kein Fine-Tuning nötig, minimiert Risiko. Domänenwissen liegt in den Dokumenten, nicht im Modell.

  • Datensouveränität: Alle Komponenten On‑Prem; externe Telemetrie und Outbound-Verbindungen standardmäßig blockiert.

  • Kostenkontrolle: Ein einzelner GPU-Server reicht oft für Piloten; Skalierung über Sharding und Batch-Indexing.

Kennzahlen:

  • Präzision der Antwortquellen: Wie oft verweist das System auf die korrekte Stelle?

  • Time-to-Answer gegenüber manueller Suche.

  • Abdeckung: Anteil relevanter Dokumente im Index.

2) Visuelle Qualitätsprüfung mit hybrider Pipeline (klassische Bildverarbeitung + leichtes ML)
Typische Frage: Können wir häufige Fehler (Kratzer, Fehlbohrungen, Lötfehler) am Band früher erkennen – ohne Produktionsstillstand?

Technikmuster:

  • Erfassung: Bestehende Industriekameras; wenn möglich synchron zum Takt, gute Beleuchtung statt “mehr KI”.

  • Vorverarbeitung: Bildnormalisierung, Maskierung relevanter Regionen (ROI), klassische Filter für einfache Regeln (Kanten, Hough, Morphologie).

  • Modell: Leichtgewichtiges CNN oder Segmentierung für komplexe Defekte, optional One-Class-Modelle für Anomalien, quantisiert für Edge-Einsatz.

  • Entscheidung: Regel-Engine kombiniert heuristische Checks mit ML-Score, Schwellenwerte pro Produktvariante.

  • Deployment: Edge-Inferenz am Band (Industrie-PC mit GPU/TPU), Updates via GitOps-Flow, reproduzierbare Container.

  • Governance: Golden Dataset, kontinuierliche Stichprobenprüfung, Traceability von Bild zu Entscheidung.

Warum das funktioniert:

  • Hybride Ansätze vermeiden Overkill: Klar deterministische Regeln bleiben Regeln; ML kümmert sich um schwer Abbildbares.

  • Edge-Betrieb entlastet das Netzwerk und wahrt Souveränität.

  • Iterative Verbesserung: Neue Defekttypen können gezielt nachtrainiert werden.

Kennzahlen:

  • False-Positive-Rate (unnötige Ausschussmeldungen).

  • False-Negative-Rate (übersehene Defekte).

  • Zykluszeit pro Bild, Stabilität über Schichten/Beleuchtungen.

3) Zustandsüberwachung und Anomalieerkennung an Maschinen
Typische Frage: Können wir Wartungsfenster besser planen und Ausfälle vermeiden – ohne komplexe Data-Lakes?

Technikmuster:

  • Datenerfassung: Schwingung, Stromaufnahme, Temperatur; zeitlich synchronisiert; Samplingraten an Maschine angepasst.

  • Feature-Engineering: Spektralanalyse, Zeit-Frequenz-Merkmale, einfache Statistiken (RMS, Kurtosis).

  • Modelle: Unüberwachte Anomalieerkennung (Autoencoder, Isolation Forest) pro Maschinentyp; optional überwachte Modelle bei vorhandenem Labelbestand.

  • Edge vs. Zentrale: Vorverarbeitung Edge-nah, Modellentscheidung zentral oder am Edge je nach Latenzanforderung.

  • Alerts: Ampellogik mit Hysterese; Integration in bestehende Leitstände/MES.

  • Governance: Drift-Monitoring, Modelllebenszyklus mit Freigaben und Rückrolls.

Warum das funktioniert:

  • Start ohne große Labeldaten möglich.

  • Domänenwissen der Instandhaltung kann als Regel-Schranke eingebaut werden.

  • Schrittweise Skalierung Maschine für Maschine.

Kennzahlen:

  • Vorwarnzeit vor bestätigtem Ausfall.

  • Anteil “nützlicher” Alerts.

  • Datenabdeckung pro Maschine.

Wo Sie nicht anfangen sollten (und warum)

  • Generische “KI-Assistenten für alles”. Ohne eng begrenzten Prozesskontext werden Halluzinationen und Erwartungshaltung die Akzeptanz ruinieren.

  • Vollautomatische Entscheidungen in sicherheitskritischen Prozessen. Beginnen Sie mit Assistenzsystemen mit Mensch-in-der-Schleife, sammeln Sie Evidenz, dann schrittweise automatisieren.

  • ERP/PLM-Großintegration als Erstprojekt. Legacy-Kopplungen sind der größte Zeitfresser. Starten Sie entkoppelt; integrieren Sie, wenn das Nutzenprofil klar ist.

  • Eigenes “Foundation Model” trainieren. Unnötig teuer, schwer zu warten. Nutzen Sie vortrainierte Open-Source-Modelle und fokussieren Sie auf RAG oder schmale Adaptionen.

  • “Cloud-first” aus Gewohnheit, wenn Datensouveränität Pflicht ist. Minimieren Sie späteres Re‑Hosting. Wenn Souveränität Nichtverhandelbar ist, dann planen Sie on-premise von Tag 1.

Datensouveränität und DSGVO ohne US-Cloud: Architekturvarianten
Ihr Ziel: Verarbeitungs- und Speicherort kontrollieren, Datenflüsse auditieren, personenbezogene Daten minimieren und Zweckbindung technisch durchsetzen. Drei praxistaugliche Betriebsmodelle:

  • Reines On-Premise im Werk
  • Infrastruktur: Virtualisierung (z. B. VMware, Proxmox) oder Kubernetes (K3s/K8s) auf eigener Hardware.
  • Netz: Segmentiertes VLAN, keine Outbound-Internetverbindungen; Updates via zertifizierte Artefakt-Repositories.
  • Vorteile: Maximale Kontrolle, Air-Gap-fähig.
  • Trade-offs: Eigenbetrieb erfordert Monitoring, Patching, Kapazitätsplanung.