KI im Mittelstand: Von der Idee zum produktiven System in 90 Tagen – ohne US‑Cloud und ohne Hype

Wenn ich heute als CTO oder Leiter Digitalisierung in einem mittelständischen Industrieunternehmen eine KI-Initiative starte, habe ich drei harte Randbedingungen:

  • Kleine, stark belastete Teams. Niemand hat Zeit für „KI-Labs“, die nach 12 Monaten eine bunte PowerPoint zeigen.

  • Datensouveränität. Produktionsdaten, Lieferantendaten, interne Dokumentation – alles geschäftskritisch und oft personenbezogen. US‑Clouds sind politisch oder vertraglich oft ein No-Go.

  • Erwartungsmanagement. Vorstand und Fachbereiche erwarten in Monaten, nicht in Jahren, sichtbaren Nutzen.

Dieser Artikel ist eine technische Handlungsanleitung. Kein Hype, keine Allgemeinplätze. Wir gehen konkret vor: Wo der Einstieg sinnvoll ist (und wo nicht), wie Sie eine DSGVO-konforme, on-premise-fähige Architektur aufsetzen, welche Projekte in 90 Tagen Ergebnisse liefern, und warum der Mittelstand gegenüber Konzernen oft im Vorteil ist – wenn er die richtigen Architekturentscheidungen trifft.

1) Wo der Einstieg Sinn macht (und wo nicht)

Guter KI-Startpunkt im Mittelstand bedeutet: klare Metrik, vorhandene Daten, begrenzte Integrationskomplexität. Drei Kategorien, die wir immer wieder erfolgreich sehen:

  • Visuelle Qualitätssicherung

Typischer Scope: Defekterkennung an einer Linie, Oberflächeninspektion, Vollständigkeitsprüfung in der Montage.
Voraussetzungen: Kameras (bestehend oder neu), stabile Beleuchtung, wenige Dutzend bis ein paar Tausend Beispielbilder.
Integrationsweg: Kamera-Stream auf Edge-Knoten, On-Device-Inferenz, Ergebnis an MES/PLC per OPC UA oder REST.
Metrik: FP/FN-Rate, Nacharbeitsquote, Taktzeit-Impact.

  • Zeitreihenbasierte Zustandsüberwachung

Typischer Scope: Vibrationen, Stromaufnahme, Temperaturverläufe – einfache Anomaliedetektion statt perfekter Restlebensdauerprognose.
Voraussetzungen: Sensor-Daten mit Minuten- bis Sekundenauflösung, mindestens einige Wochen Verlauf.
Integrationsweg: Gateways via MQTT/OPC UA, Speicherung in Timeseries-DB on-prem, Modelle offline trainieren, online inferieren.
Metrik: Frühwarnzeit, Reduktion ungeplanter Stopps, Anzahl „False Alarms“.

  • Dokumentengetriebene Assistenz

Typischer Scope: Wartungsleitfäden, Störungsdatenbanken, interner Wissenszugang für Service/Produktion.
Voraussetzungen: PDFs, Handbücher, Tickets – idealerweise schon versioniert (DMS/Share).
Integrationsweg: Retrieval-Augmented Generation (RAG) mit offenem LLM on-prem, Zugriff über Browser/Terminal.
Metrik: Zeitersparnis pro Ticket, First-Fix-Rate, Zufriedenheit der Techniker.

Antipatterns für den Start:

  • „Wir bauen erst einen Data Lake und dann Use Cases.“ In der Praxis verbrennen Sie 6–12 Monate. Besser: Datenpipelines gezielt pro Use Case, wiederverwendbar konzipiert.

  • „Wir machen End-to-End-Agenten, die alles automatisieren.“ Ohne Prozesszerlegung und Guardrails riskant. Starten Sie mit Assistenz und klaren Freigabeschritten.

  • „Wir geben alle Daten in eine API und ‚sehen mal‘.“ Ohne Datenklassifizierung und Governance entsteht Shadow-IT und Compliance-Risiko.

2) Datensouveränität in der Praxis: DSGVO-konforme KI ohne US‑Cloud

Souveränität heißt: Sie kontrollieren Speicherort, Zugriff, Modellverhalten und Audit. Architekturprinzipien, die sich bewährt haben:

  • Datenhaltung on-prem oder in EU-eigentümergeführten Clouds

Praktisches Setup on-prem:

  • Objekt-Storage: MinIO (S3-kompatibel) mit Server-Side-Encryption.
  • Datenbanken: Postgres/TimescaleDB; für Vektorsuche pgvector oder eine dedizierte Vektordatenbank, wenn nötig.
  • Secrets und Identity: Vault/Sealed Secrets; SSO via Keycloak (OpenID Connect).
  • Container-Orchestrierung: Kubernetes (k3s für Edge, K8s im RZ).
  • Modell- und Pipeline-Governance
  • Model Registry: Versionierung, lineage, Freigabeprozesse (z. B. MLflow Model Registry oder ein internes Artifact-Repo).
  • Feature Store: Wiederverwendbarkeit von Merkmalen (z. B. Feast).
  • Reproduzierbarkeit: Train-/Infer-Pipelines als Code (Argo Workflows oder Airflow), GitOps-Deployment (Argo CD).
  • Datenschutz by Design
  • PII-Reduktion am Ingress: Pseudonymisierung/Maskierung vor Persistierung (Regex + NER; definierte Policies).
  • Datenminimierung: Nur Merkmale speichern, die für die Metrik nötig sind; Rohdaten-Retention mit Fristen.
  • Zweckbindung: Pro Use Case eine Datendomäne, eindeutige Consent-/Rechtsgrundlage dokumentiert (in Abstimmung mit Datenschutz).
  • Netzwerksicherheit und Isolierung
  • Zero-Trust-Grundsatz: Service-zu-Service-MTLS, least privilege, kein „flat network“ zwischen OT und IT.
  • Air-gapped Trainingszonen, kontrollierte Artefaktübergabe (signierte Modelle, SBOMs).
  • Ausgehende Verbindungen für LLMs standardmäßig blockieren, nur definierte RAG-Quellen whitelisten.
  • Auditierbarkeit
  • Vollständige Nachvollziehbarkeit: Datenversionen, Feature-Versionen, Modell-Hash, Training-Config, Inferenz-Logs.
  • Für LLMs: Prompt/Response-Logging mit PII-Redaktion, Entscheidungspfade, Quellenzitate bei RAG.

Diese Muster vermeiden US‑Cloud-Abhängigkeiten und lassen sich mit Standard-Hardware im Rechenzentrum oder auf Edge-Knoten deployen (GPU/TPU je nach Workload, häufig genügen 1–2 GPUs pro Standort für den Start).

3) Ein 90‑Tage‑Plan, der Ergebnisse liefert

Phase 0 (Woche 0–1): Problem- und Metrikdefinition

  • Business-Metrik festlegen: z. B. -20% Nacharbeit, +15% First-Fix-Rate, -30 Minuten pro Störungsfall.

  • Technische Metrik ableiten: Precision/Recall, Mean Time to Detect, Antwortqualität in Benchmarks.

  • Scope abgrenzen: genau eine Linie, genau ein Maschinentyp, genau ein Dokumentkorpus.

Phase 1 (Woche 1–3): Datenzugang und Baseline

  • Zugriff klären: OPC UA/MQTT für Sensorik; Kamerastreams; DMS/Share für Dokumente.

  • Dateninventur: Volumen, Formate, Lücken; PII-Klassifizierung.

  • Baseline bauen: Heuristik, klassische Methoden (z. B. Schwellwerte), damit Verbesserungshebel messbar sind.

Phase 2 (Woche 3–6): Modell-MVP und Edge-Infrastruktur

  • CV: Von Klassifikation/Detektion starten; ONNX-Export; Int8-Quantisierung testen.

  • Zeitreihen: Erst Anomaliedetektion, dann ggf. Prognosen; Sliding Windows; einfache Features (RMS, Kurtosis, FFT-Peaks).

  • LLM/RAG: Dokumente extrahieren (PDF->HTML), Chunking mit semantischen Grenzen, Vektorspeicher aufsetzen; offenes LLM on-prem serven.

  • Edge/On-prem: k3s/K8s-Cluster, MinIO, Postgres, MLflow; Observability (Prometheus/Grafana, Loki) aufsetzen.

Phase 3 (Woche 6–9): Integration in den Prozess

  • UX vor Industriekunst: Einfache Weboberfläche oder HMI-Plugin; klare Ampelzustände; Feedback-Button für Operator.

  • Rückkanal bauen: Labels/Feedback landen in einem dedizierten Topic/DB, werden versioniert.

  • Safety: Fallback-Modus, Konfidenzschwellen, Escalation-Path.