Pragmatische KI im Mittelstand: Wo der Einstieg Sinn macht (und wo nicht), wie Sie DSGVO-konform ohne US‑Cloud liefern, und was in 3 Monaten realistisch ist

Wenn Mittelständler über KI nachdenken, ist die wichtigste Frage nicht, welche Modelle „State of the Art“ sind, sondern welches konkrete technische Problem sich mit vertretbarem Aufwand robust lösen lässt. Der zweite Punkt ist die Souveränität: Wo liegen Daten, wer hat Zugriff, und wie bleibt das System betreibbar – auch ohne US‑Cloud und ohne Abhängigkeit von Dritten? Dieser Artikel richtet sich an CTOs, VP Engineering und Leiter Digitalisierung im industriellen Mittelstand und beschreibt pragmatische Einstiegspfade, belastbare Architektur-Patterns und einen 12‑Wochen‑Plan, der Ergebnisse statt PowerPoint produziert.

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

Gute Startkandidaten im Mittelstand haben drei Eigenschaften:

  • Klare fachliche Zielgröße: Fehlerquote, Durchsatz, Ausfallzeit, Ticket‑Durchlaufzeit, First‑Time‑Fix‑Rate.

  • Beherrschbares Scope: Ein klar abgegrenzter Prozessschritt oder Maschinentyp; kein „unternehmensweiter Assistent“.

  • Datenzugang ohne Großbaustelle: Bereits vorhandene Bild-, Sensordaten oder Dokumente, die rechtssicher nutzbar sind.

Vier bewährte erste Anwendungsfälle:

  • Visuelle Qualitätskontrolle: Klassifikation/Segmentierung von Defekten auf Produktbildern. Vorteil: Daten liegen oft bereits vor, Feedbackschleife am Band ist messbar, Evaluationsmetriken sind klar (Precision/Recall).

  • Prädiktive Instandhaltung: Anomalieerkennung auf Vibrations-, Strom- oder Telemetriedaten ausgewählter Aggregate. Vorteil: Hoher Nutzen bei einzelnen, kritischen Assets; Start mit Überwachung (Early Warning), nicht gleich mit automatischen Abschaltungen.

  • Dokumenten-Q&A für interne Teams: LLM‑gestützte Suche in Handbüchern, Wartungsanweisungen, Normen. Vorteil: Kein generatives „freies Texten“, sondern Retrieval‑Augmented‑Generation (RAG) mit klarer Quellenanzeige; gut on‑prem betreibbar.

  • Workflow‑Automatisierung im Backoffice: Klassifikation und Extraktion in wiederkehrenden Dokumenten (Lieferscheine, Prüfberichte), Weiterleitung mit Regelwerk. Vorteil: Kombinierbar mit bestehenden DMS/ERP‑Schnittstellen.

Wovon Sie am Anfang lieber die Finger lassen:

  • „Unternehmensweiter KI‑Assistent“ für alle Use Cases zugleich. Zu unscharf, zu viele Stakeholder, zu wenig messbare Zielgrößen.

  • Vollautonome Agenten, die Systeme steuern, bevor Metriken, Guardrails und Rückfallebenen existieren.

  • Projekte ohne klaren Eigentümer in der Linie. KI „nebenbei“ funktioniert nicht – auch im Mittelstand braucht es Verantwortlichkeit und Betriebsdisziplin.

Checkliste für Ihren ersten Use Case:

  • Zielmetrik definiert? (z. B. 90% korrekte Dokumentenklassifikation)

  • Wer entscheidet „Go/No‑Go“ anhand dieser Metrik?

  • Datenzugang geklärt? (rechtlich und technisch, inkl. Export aus Maschinen/DMS)

  • Minimaler Bedienfluss skizziert? (Wer sieht was, wann, wie wird Feedback gegeben?)

  • Rückfallebene vorhanden? (Was passiert bei Ausfall/Fehlalarm?)

2) DSGVO‑konforme KI ohne US‑Cloud: Architektur‑Patterns, die sich bewährt haben

Viele Mittelständler wollen oder müssen ohne US‑Cloud auskommen. Das ist kein Showstopper, sondern primär eine Architekturfrage. Die folgenden Bausteine haben sich in sicherheitskritischen Branchen und Fertigung bewährt:

Basiskomponenten on‑prem (oder EU‑Sovereign‑Cloud):

  • Kubernetes‑Cluster als Laufzeitumgebung mit isolierten Namespaces pro Anwendung.

  • Eigenes Container‑Registry (z. B. in GitLab/Harbor), nur signierte Images; Offline‑Mirror für Abhängigkeiten.

  • Objekt‑Storage wie MinIO (S3‑kompatibel) für Trainingsdaten, Artefakte und Embeddings; Postgres für Metadaten.

  • Secret‑Management (Kubernetes Secrets/Sealed Secrets), RBAC und Netzwerksegmentierung (NetworkPolicies).

  • Observability‑Stack: Prometheus/Grafana für Metriken, Loki/Elasticsearch für Logs, OpenTelemetry‑Traces bei Bedarf.

  • Reproduzierbarkeit: MLflow oder DVC für Experimente/Artefakt‑Versionierung; GitOps (ArgoCD/Flux) für Deployments.

Computer Vision Pipeline (Beispiel visuelle Qualitätskontrolle):

  • Datenerfassung: Bilder aus Kamera/Zeilenkamera, Synchronisierung in den Objekt‑Storage, Metadaten in Postgres.

  • Labeling: Eigenes Labeling‑Tool on‑prem oder Open‑Source (z. B. CVAT) im isolierten Netz; definierte Label‑Guidelines.

  • Training: Containerisierte Trainingsjobs auf dedizierten GPUs; reproducible env (Conda/Poetry + Dockerfile, deterministische Seeds soweit sinnvoll).

  • Model Registry: Versionierte Modelle (z. B. MLflow Model Registry), signierte Artefakte, Freigabeprozess.

  • Inferenz‑Serving: On‑prem Deployment mit KServe/BentoML/Seldon; CPU‑Fallback‑Pfad wo Latenz es zulässt.

  • Qualitätssicherung: Offline‑Eval mit festen Testsets und Metriken; Online‑Monitoring für Drift, Score‑Verteilung, False‑Positive‑Rate.

LLM‑RAG‑Stack (für Dokumenten‑Q&A und Prozessassistenz):

  • Modelle: Open‑Weight‑LLMs (z. B. Llama‑/Mistral‑Familie) on‑prem, quantisiert wenn sinnvoll (4‑8‑bit) für effiziente Inferenz; Embeddings mit offenen Modellen.

  • Retrieval: Vektor‑Suche in pgvector (Postgres), OpenSearch oder Milvus; Chunking‑Strategie und Metadaten‑Filter (Anlagentyp, Revisionsstand, Sprache).

  • RAG‑Flow: Dokumenten‑Pipeline (Konvertierung, OCR, Chunking, Embedding), dann orchestriertes Prompting mit Quellenzitat; Antwort wird geloggt inkl. Prompt/Hyperparameter.

  • Guardrails: PII‑Erkennung/Redaktion vor Prompting, erlaubte Tool‑Aufrufe (Allowlist), maximale Kontextlänge, Antwortlängen‑Limits, sichere Funktionsexekution mit Timeouts.

  • Governance: Versionierte Prompts, reproduzierbare Pipelines, vollständige Audit‑Logs, RBAC auf Datenkollektionen. LLM‑spezifische Observability (z. B. Halluzinations‑Proxies, Retrieval‑Hitrate, Tool‑Fehlerquoten) ist zwingend.

Souveränität und Lieferkette:

  • Keine Abhängigkeit von externen API‑Anbietern für Produktionsdaten; Modelle und Artefakte lokal versionieren und signieren.

  • Offline‑Updates: Registries spiegeln, Security‑Patches geplant einspielen, SBOMs prüfen, Ingress strikt minimieren.

  • Datenklassifizierung und Mandantentrennung: Produktionsdaten getrennt von Test/Dev; Zugriff nur über Service‑Accounts mit minimalen Rechten.