KI im Mittelstand: souverän, pragmatisch, in 90 Tagen lieferfähig

Viele mittelständische Industrieunternehmen stehen gerade an derselben Stelle: Es gibt klare Pain Points in Produktion, Service oder Engineering, es gibt Daten – aber es gibt auch strenge Anforderungen an Datensouveränität und Compliance. Die Frage ist nicht “Welche KI ist die beste?”, sondern: “Welches konkrete Problem lösen wir zuerst, mit welcher Architektur, und wie behalten wir technische und rechtliche Kontrolle?”

Dieser Beitrag beschreibt einen praxisnahen Weg für den Einstieg, benennt bewusst No‑Gos, legt eine souveräne Zielarchitektur dar (ohne US‑Cloud-Abhängigkeit) und skizziert drei Projektmuster, die in 3 Monaten sichtbare Ergebnisse liefern. Zum Schluss ein kompakter 90‑Tage‑Plan, eine Beschaffungs-Checkliste und eine FAQ.

Wo der Einstieg in KI im Mittelstand Sinn macht – und wo nicht

Gute Einstiegs-Use-Cases haben vier Eigenschaften:

  • Digitaler Fußabdruck: Es existieren bereits Daten im Prozesslauf (Bilder, Zeitsignale, Textdokumente, Maschinendaten via OPC UA, SQL, CSV). Daten müssen nicht perfekt sein, aber zugänglich.

  • Klare Erfolgsmessung: Es gibt eine Metrik, die Domänenexpertinnen und -experten akzeptieren (z. B. Reduktion von Nacharbeit, Erstlösungsquote im Service, Minuten pro Ticket, FPY in der Linie).

  • Begrenzter Wirkraum: Das System muss nicht “alles” verstehen. Besser: klar abgegrenztes Teilproblem mit kontrollierbarer Komplexität und stabiler Schnittstelle.

  • Rückkopplung: Es gibt Menschen im Loop, die Rückmeldungen geben und so Modelle kontinuierlich verbessern.

Schlechte Einstiegs-Use-Cases:

  • Safety-kritische Entscheidungen ohne redundante Absicherung. Wenn ein Fehler Menschen oder hohe Sachwerte gefährdet, brauchen Sie erst eine robuste Architektur mit Absicherungen, Simulation, Fail‑Safes – kein schneller POC.

  • “Generative KI für alles” ohne Daten- oder Prozessfundament. Ein Chatbot ohne Wissensbasis und Governance wird Erwartungen reißen.

  • Projekte ohne Ground Truth. Wenn niemand beurteilen kann, was “richtig” ist, können Sie nicht verbessern.

  • Reine Technologieprojekte (z. B. “Wir wollen mal LLMs ausprobieren”) ohne eindeutig monetarisierbaren Pain. Das versandet.

Ein Wort zur Erwartungshaltung:

  • Einfache Baselines schlagen oft Hype-Technik. Bevor Sie ein Transformer‑Modell trainieren, prüfen Sie, was ein gut getunter Klassifikator, ein Regelwerk oder ein Schwellenwert leisten.

  • KI ist Software plus Daten. Ohne Versionierung, Tests, Observability und Deployment-Disziplin wird auch das beste Modell schnell obsolet.

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

Wenn Datensouveränität nicht verhandelbar ist, dann muss die Architektur das technisch erzwingen – nicht nur vertraglich festschreiben. Das ist kein Showstopper, sondern ein Gestaltungsprinzip.

Souveräne Zielarchitektur (High-Level)

  • Datenebene

  • Ingestion über etablierte Protokolle (OPC UA für Maschinen, SFTP/HTTPS für Dokumente).

  • Speicherung in on‑prem Datenbanken/Dateisystemen mit Verschlüsselung at rest (z. B. LUKS, dm‑crypt) und strikter Segmentierung.

  • Datenklassifizierung (personenbezogen, geheim, intern) als Metadatum am Objekt; technische Durchsetzung via IAM und Netzwerksegmentierung.

  • Modelle und Laufzeit

  • Model Registry on‑prem (z. B. MLflow Model Registry, selbst gehostet) mit Freigabeprozess.

  • Inferenz on‑prem oder an der Edge (z. B. Industrie-PC, Jetson) als containerisierte Services ohne Outbound‑Egress.

  • Keine Telemetrie nach außen; Builds reproduzierbar, SBOM vorhanden, signierte Container.

  • Applikationsebene

  • Microservice- oder modulare Architektur, API‑Gateway mit Request‑/Response‑Auditing.

  • RBAC bis auf Feld- und Endpunkt-Ebene.

  • Observability und Governance

  • Vollständige Nachvollziehbarkeit: Datenversion, Modellversion, Feature‑Pipelines, Entscheidungserklärbarkeit.

  • Audit-Logs für Zugriff, Prompt/Antwort bei LLM‑Systemen, Feedback‑Events.

  • Netz und Sicherheit

  • Default‑deny Firewall, egress control, DNS sinkhole. Nur freigegebene Repos/Registries erreichbar.

  • Secrets-Management on‑prem (z. B. HashiCorp Vault, passender KMS).

  • Lifecycle

  • ADRs (Architecture Decision Records), wiederholbare Deployments (IaC), Testumgebungen on‑prem.

  • Patch- und CVE‑Prozess für alle Third‑Party‑Komponenten.

Konkrete technische Muster für LLM‑Anwendungen unter Souveränitätsvorgaben

  • Modellwahl: Bevorzugt lokal betreibbare Modelle (z. B. Llama‑Familie, Mistral‑Varianten) in quantisierten Builds für CPU/GPU. Kein automatischer Outbound.

  • Wissensintegration: Retrieval Augmented Generation mit lokalem Vektorstore (z. B. pgvector, Qdrant) und strikt kuratiertem Dokumentenindex. Keine Voll‑Fine‑Tunes auf vertraulichen Daten, wenn Inferenzziel dominiert; stattdessen Adapter/LoRA on‑prem falls nötig.

  • Halluzinationskontrolle: Antwort-Templates, Toolformer-/ReAct‑Patterns mit striktem Output‑Schema; Confidence‑Scoring; Fallback‑Flows.

  • PII/Secret‑Hygiene: Vorinferenz‑Filter (Regex/NER) zur Schwärzung sensibler Felder, Postinferenz‑Scanner auf Ausgaben; Whitelist‑Prompts.

Zwei organisatorische Punkte

  • Recht folgt Technik: Ein AV‑Vertrag allein macht aus einer Cloud kein souveränes System. Erzwingen Sie Souveränität durch Architektur (kein Egress, eigenes Hosting, vollständige Kontrolle über den Software‑Lieferweg).

  • Lieferkette: Verbieten Sie Binärartefakte ohne SBOM und Signatur. Führen Sie ein Zulassungsverfahren für Modelle, Pipelines, Container ein.

Drei pragmatische KI‑Projekte, die in 3 Monaten Ergebnisse liefern

1) Visuelle Qualitätsprüfung an einer Engpass‑Station

  • Problem: Menschliche Sichtprüfung ist variabel und teuer; kleine Fehler rutschen durch.

  • Daten: 1–3 Kameras, 200–1000 Beispielbilder, einfache Annotation (OK/NOK, Bounding Boxes optional).

  • Architektur:

  • Edge‑Rechner an der Station (Industrie‑PC, Jetson), Kamera per GigE/USB.

  • Pipeline: Capture -> Preprocessing (Entzerrung, Normalisierung) -> Inferenz (Segmentierung/Klassifikation) -> Entscheidung -> Rückmeldung an SPS/MES.

  • On‑prem MLOps: Git, DVC oder einfache Artefaktablage, Model Registry, automatisierte Tests mit Referenzbildern.

  • Modellstrategie:

  • Start mit klassischen Bildvergleichen/Template Matching für stabile Geometrien.

  • Für variable Teile: leichtgewichtige CNN/ViT‑Klassifikation; bei wenig Fehlermustern: One‑Class/Anomaly (Rekonstruktionsfehler per Autoencoder).

  • Erfolgsmessung:

  • False‑Positive/Negative‑Raten in realem Takt.

  • Durchsatz und Auslösesperre pro Schicht.

  • Fallstricke und Gegenmaßnahmen:

  • Beleuchtung: Feste Beleuchtung/Hauben, Bildnormalisierung.

  • Drift: Wöchentliche Re‑Evaluation, Model Cards pro Freigabe.