Pragmatische KI im Mittelstand: Wo der Einstieg Sinn macht, wie Sie souverän bleiben, und welche Projekte in 12 Wochen liefern
Souveränität ermöglicht Intelligenz. Dieser Satz ist im industriellen Mittelstand kein Marketing – er ist eine Architekturanforderung. Wer Datenhoheit, Lieferketten und regulatorische Risiken ernst nimmt, kann KI nicht als „API im Internet“ einkaufen. Gleichzeitig ist KI kein Selbstzweck. Sie ist nur dann sinnvoll, wenn ein konkretes Problem damit schneller, robuster oder günstiger gelöst werden kann als mit klassischer Software oder Prozessänderungen.
Dieser Artikel richtet sich an CTOs, VP Engineering und Leiter Digitalisierung im Mittelstand. Er skizziert, wo KI-Projekte im industriellen Kontext wirklich tragen, wie Sie DSGVO-konform ohne US-Cloud starten, und welche Projektmuster in 12 Wochen messbare Ergebnisse liefern. Keine Hypes, kein „wir automatisieren alles“. Stattdessen: Architekturen, Trade-offs und Vorgehensweisen aus Projekten in Fertigung, Bahn, Bau, Textil und sicherheitskritischen Umgebungen.
1) Entscheidung: Wann lohnt sich KI – und wann nicht?
Bevor Sie Modelle, Frameworks oder Hardware auswählen, klären Sie drei technische Fragen:
- Signal: Haben Sie Daten mit brauchbarem Signal-zu-Rauschen-Verhältnis zum Zielkriterium?
- Bilddefekte mit klaren Merkmalen, vibrationstypische Vorboten von Lagerschäden, wiederkehrende Textdokumente: gut geeignet.
- Stark variable Prozesse ohne klare Labels, reine „Wunschfragen“ an ein Chatbot-Frontend: schlechte Ausgangslage.
- Geschlossene Wirkungsschleife: Können Ergebnisse innerhalb des Prozesses ausgewertet und verbessert werden?
- Beispiel: Visuelle Endprüfung → Ausschussquote messbar → Modell iterativ nachschärfen.
- Beispiel: Wissenssuche für Techniker → Tickets schließen schneller → messbare Durchlaufzeitverbesserung.
- Souveränität: Lässt sich die Lösung ohne Abfluss personenbezogener oder schutzbedürftiger Daten betreiben?
- Wenn Nein: Architektur anpassen (On-Prem, Pseudonymisierung, Air-Gap), oder Projekt verwerfen.
Pragmatische 3×3-Regel für den Einstieg:
- 3 Datenquellen maximal (z. B. Kamerastream, ERP-Fehlercode, Hand-Etikettierung).
- 3 Metriken, die in Euro oder Zeit übersetzbar sind (z. B. Ausschusskosten, Mean Time to Repair, First-Time-Fix-Rate).
- 3 Monate bis zum Pilot mit Produktionsnähe (nicht nur Notebook-Demo).
Wenn Sie diese Bedingungen nicht plausibel beantworten können, ist klassische Automatisierung, Prozessanalyse oder ein gezieltes Datenerhebungsprojekt oft sinnvoller als sofortige KI.
2) Datensouveränität und DSGVO – ohne US-Cloud, ohne Friktion
Technisch bedeutet Souveränität: Daten verlassen Ihre Kontrollzone nicht; Verarbeitung ist nachvollziehbar; Modelle, Prompts und Entscheidungen sind auditierbar.
Erprobte On-Prem-Muster:
- Infrastruktur-Basis:
- Kubernetes auf Bare Metal oder VM-Cluster
- Objekt-Storage S3-kompatibel (MinIO)
- Container-Registry (Harbor)
- Auth/SSO (Keycloak)
- Secrets-Management (HashiCorp Vault)
- Monitoring/Logging (Prometheus, Grafana, Loki)
- ML/MLOps:
- Experiment- und Modellverwaltung (MLflow oder DVC)
- Feature Store (Feast, optional – im Mittelstand häufig zu schwergewichtig, starten Sie leichtgewichtig mit klaren Feature-Pipelines)
- Job-Orchestrierung (Argo Workflows oder Airflow, je nach Teampräferenz)
- LLM und Retrieval:
- Model Serving On-Prem: vLLM oder Text Generation Inference (TGI)
- Vektordatenbank On-Prem: Qdrant oder Weaviate
- Embeddings: lokal laufende Modelle (z. B. E5/BGE-Klasse); Quantisierung (int8/int4) für kleinere GPUs
- Dokument-Indexierung: Chunking mit Domänen-spezifischen Regeln (z. B. technische Normen, Schaltpläne → strukturierte Splits)
- Datenfluss und Schutz:
- PII- und Geheimnisschutz: Pseudonymisierung/Maskierung als dedizierte Pipeline vor jeglicher Modellnutzung
- Rollen- und Mandantentrennung auf Namespace-Ebene in Kubernetes
- Ausgehenden Traffic standardmäßig blockieren; Air-Gapped Updates per signiertem Paket
- Vollständiges Prompt-/Response-Logging unter Zugriffskontrolle; SBOMs (SPDX) für alle Container-Images
- Governance:
- Prompt-Registry mit Versionsführung (Git)
- Policy-Checks vor Deployment (z. B. kein externer Endpunkt, keine Telemetrie)
- Reproduzierbare Builds, signierte Modelle, Hash-Prüfung beim Laden
Damit können Sie LLM-gestützte Workflows, Bild-/Zeitreihen-Modelle und klassische ML-Pipelines betreiben, ohne Daten an US-Clouds zu übermitteln. DSGVO bleibt prozessual – es braucht Verarbeitungsverzeichnis, Auftragsverarbeitungsverträge intern/extern, Löschkonzepte. Technisch unterstützt Sie die oben skizzierte Architektur.
3) Drei Projektmuster, die in 12 Wochen Ergebnisse liefern
Archetyp A: Visuelle Qualitätssicherung/Fehlerdetektion
- Problem: Manuelle Sichtprüfung ist inkonsistent und teuer. Leichte Kratzer, Fehlausrichtungen, fehlende Teile sollen robust erkannt werden.
- Daten: 5–20k Bilder reichen oft für einen robusten Start, ergänzt durch synthetische Daten/Augmentation. Label-Qualität > Datenmenge.
- Architektur:
- Kamera-Input → Edge-Inferenz (NVIDIA Jetson Xavier/Orin oder x86 + GPU) → Inferenz-Service (ONNX Runtime/TensorRT) → Ergebnis-API
- Modelle: Objekt-/Defektdetektion (YOLOv8/RT-DETR), für komplexere Fehler Segmentierung (U-Net-Variante) oder SAM-basierte Vorsegmentierung mit regelbasiertem Postprocessing
- Datenhaltung: Rohbilder in MinIO; Labels in JSON/COCO; Trainingsjobs über Kubernetes; Modell-Registry via MLflow
- Trade-offs:
- Domänendrift (neue Chargen, Beleuchtung) erfordert kontinuierliches Re-Labeln kleiner Batches; daher: Active Learning einplanen
- Edge-Inferenz minimiert Latenz und Netzlast, erhöht aber Rollout-Komplexität (Over-The-Air Updates; Versionierung)
- Deliverables nach 12 Wochen:
- Basismodell mit >90% Recall auf definierten Fehlerklassen (Zielwerte domänenspezifisch)
- Edge-fähiger Container mit Telemetrie (nur technische Metadata, keine PII)
- Metrik-Dashboard (False-Positives/-Negatives pro Linie/Schicht)
- Nachbeschaffungs- und Labeling-Runbook (Wann retrain? Wie viel?)