Titel: Pragmatische KI im Mittelstand: Wo der Einstieg Sinn macht (und wo nicht) – souverän, on‑prem, lieferfähig in 3 Monaten

Wenn wir mit mittelständischen Industrieunternehmen sprechen, hören wir selten „Wir wollen KI“, sondern eher: „Wir haben ein Qualitätsproblem an Linie 3“, „Unsere Instandhaltung reagiert zu spät“ oder „Unser Dokumentenfluss frisst uns auf“. Richtig so. Problem zuerst, nicht Technologie zuerst. Aus dieser Perspektive erkläre ich, wo KI im Mittelstand heute sinnvoll einsetzbar ist, wo man besser noch wartet, wie man ohne US‑Cloud und DSGVO‑konform startet – und warum kleinere Unternehmen hier oft im Vorteil sind. Unser Leitmotiv: Souveränität ermöglicht Intelligenz. Wer die Kontrolle über Daten, Modelle und Betrieb behält, baut Systeme, die zuverlässig wirken statt zu beeindrucken.

Wo der Einstieg Sinn macht – und wo nicht

Sinnvoll sind Anwendungsfälle mit vier Eigenschaften:

  • Eng umrissener Scope und messbares Ziel. Beispiel: „Reduziere Pseudoausschuss an Station X um 20 %“ oder „Automatisiere 60 % der Eingangsrechnungs-Triagen“.

  • Daten liegen bereits vor oder sind mit vertretbarem Aufwand erschließbar. „Vertretbar“ heißt: Wochen, nicht Jahre.

  • Operativer Hebel. Ein BI‑Report ist nett, eine automatisierte Entscheidung oder Beschleunigung in der Linie ist wertschöpfend.

  • Sicherheits- und Compliance-Risiko ist beherrschbar. Kritische Entscheidungen bleiben menschlich abgesichert oder sind mit robusten Guardrails umgesetzt.

Typische schnelle Treffer im Mittelstand:

  • Visuelle Qualitätsprüfung: Klassifikation von Defekten mit Kameras; auch „Second Opinion“-Systeme, die dem Werker Hinweise geben, bevor ein Teil weiterläuft.

  • Dokumentenautomatisierung: Extraktion und Triagierung von Bestellungen, Lieferscheinen, Spezifikationen; semantische Suche in Wartungsunterlagen.

  • Instandhaltung: Anomalieerkennung in Sensordaten, einfache Prädiktoren für „nächste 30 Tage“-Ausfälle, RAG‑Assistenten (Retrieval-Augmented Generation) für Störungssuche.

  • Produktionsplanung nahe Echtzeit: Engpass-Erkennung, Szenario-What‑ifs auf Basis von Ist‑Daten und Regeln; KI unterstützt, ersetzt aber nicht die Planungslogik.

Wovon rate ich zum Start ab?

  • Sicherheitskritische Entscheidungen ohne doppelten Boden. Ein LLM, das Prozessparameter direkt ändert, ist ein No‑Go ohne harte Freigabemechanismen.

  • „Wir haben keine Daten, aber bauen erstmal die Plattform“. Bauen Sie das kleinste, produktionsnahe Datensammelstück, das einen konkreten Use Case nährt.

  • Generalistischer Chatbot „für alles“. Starten Sie eng, domänenspezifisch, mit evaluierten Datasets.

  • Großer Modell-Trainingsansatz ohne klare Differenzierung. Feintuning lohnt sich erst, wenn RAG und geschicktes Prompting nicht mehr reichen.

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

Ohne saubere Daten- und Betriebsgrenzen wird KI im Mittelstand zur Compliance-Falle. In kritischen Industrien (Defense, Railway, Fertigung) sehen wir praktikable Muster, die auch für kleinere Teams handhabbar bleiben:

Deployment-Modelle

  • On‑prem Kubernetes-Cluster: Ein Bare‑Metal- oder VM‑Cluster im eigenen Rechenzentrum. Vorteil: volle Daten- und Netzwerkhoheit, determinierbare Latenz. Nachteil: Planung und Sizing erfordern Know-how.

  • Edge + Zentrale: Inferenz nahe der Maschine (Edge‑GPU/CPU), zentrale Dienste (Vektordatenbank, Governance) on‑prem. Vorteil: geringe Latenz, weniger Bandbreite.

  • EU‑Private Cloud ohne US‑Bezug: Möglich, wenn Datenklassifizierung das zulässt. Für viele Mittelständler bleibt on‑prem der souveränere Standard.

Datenflüsse sauber trennen

  • Inferenz vs. Training. Sensible Daten müssen nicht zwangsläufig zum Modelltraining verlassen. Oft reicht RAG: Dokumente bleiben intern, das Modell generiert nur auf Basis abgerufener Snippets.

  • Datenminimierung. Speichern, was Sie für Audit und Verbesserung brauchen – nicht mehr. Maskieren Sie nicht benötigte Personen- oder Auftragsbezüge.

  • Logging als Sicherheitsfeature. Prompt-, Retrieval- und Action-Logs mit Hashing/Signatur schaffen Nachvollziehbarkeit ohne Datensumpf.

Modellauswahl und -betrieb

  • Open‑Weight‑Modelle on‑prem. Für viele Sprach- und Vision‑Aufgaben gibt es leistungsfähige Modelle, die sich offline betreiben lassen. Feintuning nur, wenn klarer Mehrwert.

  • RAG als Default. Erst Kontext, dann Generierung. Verzahnen Sie Vektorsuche mit strikten Quellenangaben; antworten ohne Quelle aggressiv abbrechen („Ich weiß es nicht“ ist besser als Halluzination).

  • Guardrails und Policies. Maximale Antwortlänge, zulässige Aktionen, Whitelists für Tools, harte Abbrüche bei Policy‑Verstößen.

Identität, Zugriff, Audit

  • RBAC pro Use Case, nicht pro Team. Rollen und Rechte an messbaren Aufgaben ausrichten. Maschinenzugriffe getrennt von Benutzerzugriffen.

  • Offline‑Evaluationssuites. Jede Modell‑ oder Prompt‑Änderung gegen einen fixen Goldstandard laufen lassen, bevor Produktion berührt wird.

  • Reproduzierbarkeit. Modelle, Tokenizer, Embeddings, Prompts versionieren; „Prompt-as‑Code“ wie Anwendungslogik behandeln.

Trade-offs offen adressieren

  • On‑prem kostet mehr Vorarbeit, reduziert aber Betriebsrisiko und Compliance-Aufwand. Cloud spart Anlauf, erhöht Vendor‑Lock‑in. Für sensible Industrie‑Workloads empfehle ich On‑prem als Default.

  • Größeres Modell ≠ besser. Für fokussierte Aufgaben liefern kleinere Modelle mit gutem Kontext oft die robusteren Ergebnisse bei besserer Latenz und niedrigeren Hardwarekosten.

Pragmatische KI in 3 Monaten: Vorgehensmodell

Ein Projekt, das in 12 Wochen Resultate liefert, braucht Disziplin und klare Schnitte. Bewährt hat sich:

Wochen 0–2: Scoping und Messgrößen

  • Eine Problemhypothese, ein KPI, eine harte Go/No‑Go‑Schwelle. Beispiel: „Top‑1‑Trefferquote bei Dokumentenretrieval ≥ 85 %, ansonsten Abbruch oder Iteration“.

  • Datenzugriff klären: 2–3 Datenquellen, Minimal‑ETL, eindeutiges Datenmodell.

  • Non‑funktionale Anforderungen: Latenzbudget, Datenschutzklasse, Abnahmeprozess.

Wochen 3–6: Technischer Prototyp

  • Ende‑zu‑Ende‑Pfad: Ingest → Preprocessing → Modell/LLM → Ausgabe → Logging.

  • Offline‑Eval bauen: 50–200 repräsentative Fälle mit Ground Truth.

  • Erstes RAG/CLF‑Baseline‑Modell. Kein Feintuning, solange Baseline nicht ausgereizt.

Wochen 7–10: Pilot in echter Umgebung

  • Integrierte Schnittstellen (MES/ERP/CMMS), Auth, Rechte.

  • Guardrails und Fail‑safes (Abbruch bei Unsicherheit, Eskalation an Mensch).

  • Alarme, Dashboards, Prompt/Tool‑Tracing. Beobachtbarkeit ist Pflicht.

Wochen 11–12: Härtung und Übergabe

  • Lasttests, Recovery‑Drills, Backup/Restore.

  • Dokumentation: Betriebshandbuch, Security‑Konzept, Evaluationsbericht.

  • Entscheidung: Betrieb aufnehmen, erweitern oder stoppen.

Warum der Mittelstand oft schneller ist als Konzerne