Titel: Pragmatische KI im Mittelstand: Wo Sie starten sollten, wie Sie souverän bleiben – und warum kleinere Teams im Vorteil sind

Einführung

Wenn mittelständische Industrieunternehmen über KI sprechen, landet die Diskussion oft zu schnell bei Modellen und GPU-Größen. Das ist der falsche Einstieg. Der richtige Einstieg beginnt mit der Frage: Welches konkrete technische Problem wollen wir in einem klar abgegrenzten Prozessschritt unter realen Randbedingungen lösen – und lässt sich der Nutzen in 12 Wochen messen?

Aus Projekten in Bereichen wie Fertigungsprüfung, Bahn-Fleet-Intelligence, Bauvermessung, Textil-Predictive-Maintenance oder einem Cloud-basierten Training für Piloten sehen wir immer wieder dieselben Muster: Souveränität ist die Voraussetzung für belastbare Intelligenz. Konkret heißt das: Daten bleiben unter Kontrolle (DSGVO-konform, ohne Abhängigkeit von US-Clouds). Die Lösung ist integriert und betreibbar (on-prem oder kontrolliert hybrid). Und die Architektur folgt dem Prozess – nicht dem Hype.

In diesem Beitrag skizzieren wir einen praxisnahen Fahrplan:

  • Wo der Einstieg Sinn macht (und wo nicht)

  • Ein minimales, aber tragfähiges Architektur-Blueprint für datensouveräne KI on-prem

  • Ein 12-Wochen-Fahrplan bis zu messbaren Ergebnissen

  • Trade-offs bei LLMs, Computer Vision und Edge-Inferenz

  • Governance, Observability und DSGVO in der Praxis – ohne US-Cloud

  • Warum der Mittelstand bei KI oft schneller ist – und welche Stolpersteine Sie vermeiden sollten

1) Wo der Einstieg Sinn macht – und wo nicht

Gute Ersteinsatzfelder im Mittelstand haben drei Eigenschaften:

  • Datenzugang ist beherrschbar: Sie kommen an die relevanten Daten ohne monatelange ERP- oder IT-Großprojekte. Beispielquellen: Kamerastreams, SPS/MES-Daten via OPC UA/MQTT, Wartungsprotokolle, technische Handbücher als PDFs.

  • Der Prozess ist scharf umrissen: Wenige Schnittstellen, klare Betreiber, messbare Metriken. Ein Werk, eine Linie, ein Maschinentyp, ein Dokumentkorpus.

  • Der Nutzen ist nah am Kerngeschäft: Ausschussreduktion, kürzere Stillstände, weniger Fehlteile, schnellere Einarbeitung von Personal.

Bewährte Erstprojekte

  • Visuelle Qualitätsprüfung/Assembly-Fehlererkennung: Edge-Kamera, minimale Latenz, mensch-in-the-loop für Grenzfälle. Vorteil: Direkter KPI (False-Reject-Rate, Durchsatz).

  • Dokumentenassistenz für Instandhaltung und Montage: Retrieval-augmented Generation (RAG) auf eigenen Handbüchern, SOPs und Störungsberichten. Vorteil: Kurze Time-to-Value, gut eingrenzbar, kein Abfluss sensibler Daten nötig.

  • Predictive Maintenance für einen eng definierten Aggregat-Typ: Ein Maschinentyp, definierte Sensoren, Ziel “Frühwarnung X Stunden vor Ausfall” – nicht “alles vorhersagen”.

  • Flotten-/Anlagenintelligenz light: Konsolidierte Sicht auf Telemetriedaten mit einfachen Anomalie-Detektoren statt „End-to-End-Data-Lake“.

Projekte, die als Erstprojekt selten funktionieren

  • Chatbots „für alles“: Unklare Zielgruppe, diffuses Wissensuniversum, schwierige Erfolgsmessung.

  • Konzernweite Data-Lake-Programme: Für Mittelstand überdimensioniert, hoher Overhead, Nutzen spät.

  • Unklare Optimierer („Plant Scheduling mit KI“), wenn die Eingangsdaten volatil oder nicht digitalisiert sind.

  • Safety-/Zulassungskritische Autonomie ohne Vorlauf: Erst Simulation/Shadow-Mode aufbauen, dann schrittweise Freigabe.

Ein einfacher Eignungs-Score (0–2 je Kriterium)

  • Datenzugriff in 4 Wochen lösbar

  • Erfolgsmessung in 12 Wochen möglich

  • Ein Stakeholder-Team (Fachbereich + IT + Betrieb)

  • Sicherheits-/DSGVO-Risiko beherrschbar

  • Integration ohne Big-Bang

Ab 7 Punkten: guter Kandidat für den Start.

2) Architektur-Blueprint für datensouveräne KI on-prem

Das Ziel ist nicht „State of the Art“, sondern „State of Done“: So wenig Bausteine wie nötig, so robust wie möglich. Ein bewährtes Minimal-Setup:

Datenebene

  • Ingestion:

  • Industriell: OPC UA, MQTT, S7, CSV-Drops aus MES/ERP, Fileshares.

  • Dokumente: Filecrawler für PDFs/DOCX, Metadaten-Extraktion, OCR nur wo nötig.

  • Storage:

  • Zeitreihen: Postgres/TimescaleDB – reicht in 90 % der Mittelstandsfälle.

  • Objekt-Store: MinIO on-prem für Artefakte, Bilder, Modelle.

  • Vektorsuche: pgvector in Postgres, bevor man Milvus/Weaviate evaluiert. Weniger bewegliche Teile, leichter zu betreiben.

Modellebene

  • Computer Vision: ONNX Runtime oder TensorRT für Inferenz. Training initial in einer kontrollierten EU-Cloud oder on-prem Workstation; Artefakte wandern in den on-prem Objekt-Store.

  • LLM/RAG:

  • Modellhosting: vLLM/text-generation-inference für 7–13B Modelle, ggfs. quantisiert. Für schmale Q&A-Lasten sind 7B-Modelle plus gutes Retrieval oft ausreichend.

  • Retrieval: RAG-Pipeline mit pgvector, Dokumentensplitter, Embeddings (lokal generiert).

  • Keine Calls in externe US-APIs für produktive Systeme. Daten und Prompt/Completion-Logs bleiben on-prem.

  • Agenten: Tool-Use strikt allow-listen (z. B. nur ERP-Teilelookup, DMS-Suche). Observability/Guardrails on-prem betreiben. Für diesen Baustein setzen wir in Projekten auf eine Klasse von Plattformen wie Alpi-M (LLM-Agent Observability & Governance), um Prompt-Flows, Tool-Aufrufe, Redaktionsregeln und Audit-Trails zentral zu erzwingen.

Betriebsebene

  • Orchestrierung: Starten Sie mit Docker Compose oder k3s statt „Voll-Kubernetes“. Wichtig ist reproduzierbarer Betrieb, nicht Feature-Overflow.

  • CI/CD: GitLab on-prem, Artefakt-Registry, Infrastructure as Code für reproduzierbare Deployments.

  • Identity: Keycloak für SSO/Rollen, damit keine Schatten-Accounts entstehen.

  • Monitoring/Logs: Prometheus/Grafana, Loki. Metriken für Modelle (Latenz, Fehlerraten) neben Systemmetriken.

  • ML-Assets: Git + DVC (Data Version Control) oder MLflow on-prem; beides reicht für Versionierung und Reproduzierbarkeit.

Netzwerk- und Sicherheitsprinzipien

  • Datenflüsse minimal und gerichtet: Edge -> Zentrale; keine unnötigen Rückkanäle.

  • Air-Gap-fähig planen: Updates per signierten Artefakten, kein Zwang zu Internetzugang.

  • Protokollierung: Alle Modellversionen, Trainingsdaten-Snapshots, Prompt-/Antwort-Logs (pseudonymisiert wo nötig) versionieren.

Drei typische Deployment-Patterns

  • Edge-only Vision: Kamera + Jetson/Industrie-PC, inference lokal, nur Metadaten ins Werknetz. Niedrigste Latenz, höchste Souveränität.

  • Zentrales on-prem Cluster: Mehrere Fachanwendungen teilen sich GPU/CPU-Ressourcen; Identity, Monitoring, Vektor- und Objektspeicher zentral.

  • Hybrid-Entwicklung, on-prem Betrieb: Training/Prototyping in EU-Cloud, produktive Inferenz on-prem. Produktionsdaten bleiben im Haus; nur synthetische/annotierte Samples verlassen das Werk.

3) 12 Wochen bis zu messbaren Ergebnissen

Ziel: Ein System, das in der Produktion/Operation „Shadow Mode“ läuft, messbare Metriken liefert und einen klaren Go/No-Go erlaubt. Beispiel-Fahrplan: