KI im Mittelstand: Wo der Einstieg Sinn macht (und wo nicht) – souverän, on‑prem, in 90 Tagen nutzbar

Der Mittelstand hat andere Rahmenbedingungen als Konzerne: kleine, schlagkräftige Teams, belastbares Domänenwissen, überschaubare Budgets. Genau hier funktioniert KI – wenn Sie nicht mit Technologiefeuerwerk starten, sondern mit einem klar umrissenen Problem, einem schlanken Betriebsmodell und der Prämisse: Ihre Daten bleiben unter Ihrer Kontrolle. Dieser Beitrag bündelt praktische Architekturentscheidungen, typische erste Projekte für 90 Tage und klare No‑Gos aus Projekten mit industriellen Mittelständlern.

1) Wo der Einstieg Sinn macht – und wo nicht

Gute Startkandidaten haben vier Eigenschaften:

  • Datennähe: Sie haben heute schon Zugriff auf die relevanten Datenströme (Kamera, Sensorik, Dokumente, Ticketsystem), ohne erst monatelang Schnittstellenverträge zu verhandeln.

  • Enger Problemzuschnitt: Ein klarer, messbarer Werttreiber (z. B. weniger Nacharbeit, kürzere Suchzeiten in Handbüchern, weniger Stillstände).

  • Kurze Entscheidungsschleife: Ergebnisse lassen sich mit realen Nutzerinnen und Nutzern schnell verproben und in den Alltag integrieren.

  • Souveräne Betriebsfähigkeit: Lösung kann on‑prem laufen, ohne US‑Cloud, ohne dauerhafte Internetabhängigkeit, ohne Datenabfluss.

Typische „erste“ Use Cases, die diese Kriterien erfüllen:

  • Visuelle Qualitätsprüfung mit vorhandenen Kameras: Anomalieerkennung oder spezifische Fehlerklassen auf Bauteilen, Montagefehler am Band, Etikett-/OCR‑Prüfung.

  • Wissenszugang in Service und Instandhaltung: Retrieval‑Augmented‑Generation (RAG) auf Handbüchern, Prüfanweisungen, Schaltplänen, um Fragen wie „Drehmoment für XYZ bei Revision B?“ in Sekunden zu beantworten – offline, on‑prem.

  • Vorausschauende Instandhaltung auf bestehenden Sensoren: Vibrations-/Stromsignale aus SPS/OPC UA, Anomalieerkennung statt „Big Data“-Orchester.

  • Planungsassistenz in eng umrissenen Nischen: Terminierung auf begrenzte Ressourcen mit realen Restriktionen, heuristisch plus ML‑Korrekturen anstatt „KI macht gesamte Produktionsplanung“.

Wovon Sie als Erstprojekt die Finger lassen sollten:

  • „KI‑Strategie‑Chatbot für die ganze Firma“: Unklare Nutzergruppen, unklare Domäne, hohe Governance‑Last.

  • Vollautomatisierung von SAP/ERP‑Prozessen via LLM‑Agenten: Zu viele Seiteneffekte, hohe regulatorische Implikationen, schwergängige Freigaben.

  • Projekte, die erst neue Sensorik, große Datenplattformen oder Prozessumbauten brauchen: Erst „Datenzugang heute“ sichern, dann iterativ erweitern.

  • Seltene, sicherheitskritische Ereignisse (z. B. 1 Fehler auf 100.000) als Start: Labels fehlen, Ground Truth schwer, Risiko hoch. Dort zunächst regelbasiert, später ML als Zusatz.

2) Architekturentscheidungen für den Mittelstand: robust, wartbar, souverän

Ziel ist eine Architektur, die ein kleines Team betreiben kann, auditierbar bleibt und ohne US‑Cloud funktioniert. Ein bewährtes „klein aber komplett“-Pattern:

  • Datenerfassung:
  • Maschinen/SPS: OPC UA lesen (z. B. via Edge‑Gateway), in MQTT/Kafka übersetzen.
  • Kameras: RTSP/GenICam Streams; Bild-/Videoframes zeitlich mit Produktionsereignissen korrelieren.
  • Dokumente: Fileshares, SharePoint On‑Prem, PLM/ALM‑Exporte; extrahieren in Text+Struktur (PDF, CAD‑Begleitdokumente, CSV).
  • Persistenz:
  • Rohdaten: On‑prem S3‑kompatibel (MinIO) oder NAS. Versioniert, immutable Buckets für Trainingsdaten.
  • Metadaten/Transaktionsdaten: Postgres als Arbeitspferd.
  • Vektorindex für RAG: Postgres mit pgvector oder OpenSearch mit Vector‑Plugin – einfach zu betreiben, replizierbar.
  • Feature- und Modellverwaltung:
  • Artefakt- und Modellversionierung: Git + DVC für Datensnapshots, MLflow für Modell-/Experimenttracking. Keine Magie, aber reproduzierbar.
  • CI/CD: GitLab CI oder Jenkins auf eigenem Runner. Einfache Pipelines: Training → Evaluierung → Modellregistrierung → Staging‑Deployment.
  • Inferenz und Dienste:
  • Containerisiert (Docker). Für kleine Setups: Docker Compose oder k3s statt „voll‑fettes“ Kubernetes. Wenige klar geschnittene Services:
  • Inferenzdienst (CV/LLM)
  • API/Adapter (REST/gRPC) zur Produktions‑IT
  • UI/Operator‑Frontend
  • LLM on‑prem: vLLM für performantes Server‑Inferencing; alternativ llama.cpp für Edge/CPU‑nahe Szenarien. Embeddings on‑prem (z. B. deutsche/bilinguale Modelle), kein externer API‑Call.
  • Observability & Qualität:
  • Logs/Traces/Metriken: OpenTelemetry → Prometheus → Grafana. Dashboards für Datenlatenz, Fehlerraten, Modell‑KPIs (Precision/Recall, Antwortlatenzen).
  • Datadrift/Outlier‑Monitoring: Distributionen gegen Trainingsbaseline, Alarme bei Drift, Sampling‑Queues für Re‑Labeling.
  • Sicherheit & Souveränität:
  • Netzwerksegmentierung: Edge → Inferenz → UI getrennt, nur ausgehende Verbindungen, kein Telefonieren „nach Hause“.
  • Secrets/Keys: Vault oder OS‑eigen; Audit‑Logs für Modellauswahl, Prompt‑Konfiguration, Parameteränderungen.
  • Offline‑Updates: Modelle/Container über signierte Artefakte einspielen; Paketquellen gespiegelt.

Trade‑offs, die Sie bewusst treffen sollten:

  • Vektorstore: pgvector reicht bis zig Millionen Embeddings und ist für kleine Teams einfacher als ein separater Suchcluster. Wenn Sie komplexe Ranking/Hybrid‑Suche brauchen, steigen Sie später auf OpenSearch/Elasticsearch um.

  • Orchestrierung: k3s statt „großem Kubernetes“ reduziert Wartung. Wenn Sie 2‑3 Dienste haben, ist Compose oft die schnellere Wahl.

  • GPU‑Beschaffung: Für Erstprojekte reicht eine Workstation (z. B. 1× High‑End‑GPU). Edge‑Modelle (Quantisierung) auf CPU/Jetson, zentrale LLMs/Großmodelle auf der Workstation.

3) Datensouveränität: DSGVO-konforme KI ohne US‑Cloud

Souveränität ist kein Marketingbegriff, sondern eine Betriebsentscheidung. Drei Grundprinzipien haben sich im Mittelstand bewährt:

  • Datenminimierung und Zweckbindung an der Quelle:
  • Loggen Sie nur, was Sie brauchen. LLM‑Chat‑Protokolle enthalten häufig personenbezogene Daten (Namen, E‑Mails, Tickets). Vor der Persistenz: PII‑Maskierung/Hashing, Retention‑Policies.
  • Für CV‑Anwendungen in Hallen: Gesichter und personenbezogene Merkmale vermeiden/verdecken; Kamerawinkel und Bildausschnitte so wählen, dass Personen nicht erfasst werden.
  • On‑prem‑Betrieb als Default:
  • Inferenzserver, Vektorstore, Artefakt‑Registry in Ihrem Netz.
  • Kein „Call‑Home“ der genutzten Open‑Source‑Komponenten; Telemetrie deaktivieren; Container/Modelle aus geprüften, internen Registern.
  • Vendor‑Auswahl nach Auditierbarkeit:
  • Keine Blackbox‑APIs für Kerndomänenentscheidungen. Sie müssen Prompts, Modelle, Datenflüsse auditieren können.
  • „Bring your own key“ oder „EU‑Region“ löst nicht die Frage der Souveränität. Entscheidend ist: Wo laufen Rechenprozesse? Wer hat operativen Zugriff? Was verlässt Ihr Netz?