Datenebene:

  • Objekt‑Storage on‑prem (S3‑kompatibel) für Rohdaten, Versionierung aktivieren.

  • Relationale DB für Metadaten (z. B. Postgres), Time‑Series DB für Sensorik.

  • Einheitliche Datenverträge: Schema, Qualitätsschwellen, Retention, Pseudonymisierung wo nötig.

Compute und Orchestrierung:

  • Containerplattform on‑prem (z. B. Kubernetes), klare Trennung von Dev/Stage/Prod.

  • GPU‑Nodes für Training/Inference, Kapazität planbar, No‑Internet‑Betrieb unterstützen.

  • Interne Registries für Container/Modelle, signierte Artifacts, reproduzierbare Builds.

MLOps‑Grundlagen:

  • CI/CD für Modelle und Pipelines, Promotion über Stages nur mit Freigabe und Tests.

  • Feature‑Pipelines als Code, Datenprofiling, Data‑Quality‑Gates vor dem Training.

  • Monitoring: Inferenzlatenz, Datendrift, Labeldichte, „unknowns“‑Quote, Outlier‑Rate.

  • Auditierbarkeit: Jede Vorhersage mit Modell‑Version, Daten‑Hash, Konfiguration.

LLM‑Stack on‑prem:

  • Inference Server mit quantisierten Gewichten, Throttling und Hard‑Token‑Limits.

  • Retrieval Layer mit Zugriffskontrolle, Sensitive‑Entity‑Redaktion im Log.

  • Guardrails: Output‑Filter, Werkzeug‑Aufrufe nur gegen Whitelist, Timeout‑ und Retry‑Policy.

  • Agent‑Governance: Pro Agent Tool‑Budget, erlaubte Aktionen, genehmigte Prompts/Personas, Telemetrie, Rollback.

Sicherheit und DSGVO ohne US‑Cloud

Grundsätze:

  • Datenverarbeitung bleibt im eigenen Rechenzentrum oder bei europäischem Hoster ohne US‑Rechtszugriff.

  • Privacy by Design: Minimierung, Pseudonymisierung, Zweckbindung pro Pipeline.

  • DPIA/DSFA für personenbezogene Use Cases, technische und organisatorische Maßnahmen dokumentieren.

  • Logdaten redigieren (PII), Rollenkonzepte und Need‑to‑know.

Praktische Maßnahmen:

  • Air‑gap oder kontrollierter DMZ‑Pfad, kein Modell‑Download aus dem Internet in Prod.

  • Secrets via Vault, keine Keys in Notebooks/Skripten.

  • Red‑Team für LLM‑Prompts: Jailbreak‑Tests, Injection‑Szenarien, Kontexteinschränkungen.

  • Lieferkette: SBOM für Container/Modelle, Dependency‑Scanning, regelmäßige Patches.

Build‑vs‑Buy und TCO im Mittelstand

  • Modelle: Für Startprojekte reichen oft robuste, lokal betreibbare Modelle. Proprietäre Cloud‑APIs vermeiden Lock‑in und Datenabfluss, sind aber einfacher zu starten. On‑prem bietet Kontrolle und planbare Kosten, erfordert jedoch Disziplin in Betrieb und Updates.
  • Infrastruktur: Eigene GPU‑Kapazität senkt langfristig Opex und gibt Souveränität. Alternativ: Co‑Location oder europäische Anbieter mit klarer Vertragslage.
  • Open‑Source‑Stack: Transparenz und Anpassbarkeit vs. eigener Wartungsaufwand. Wählen Sie Bausteine, die Ihr Team wirklich betreiben kann, nicht die „vollständigsten“ Tools.
  • Lizenzierung: Prüfen Sie Lizenztexte von Modellen/Bibliotheken gegen Ihre Nutzungsarten (kommerziell, Fein‑Tuning, Weitergabe).

Organisation: Wer macht was?

  • Product Owner aus der Linie (Produktion/Service) mit echter Entscheidungskompetenz und KPI‑Verantwortung.
  • ML Engineer für Feature‑Pipelines, Modelltraining, Evaluierung.
  • Software Engineer für Integrationen, APIs, Edge‑Apps, UI.
  • DevOps/Platform Engineer für Build/Deploy/Monitoring, Security.
  • Domänenexperte für Labeling, Akzeptanzkriterien, Grenzfälle.
  • Datenschutzbeauftragter/Informationssicherheit für DPIA, TOMs, Zugriffskonzepte.
  • QA/Testing für Datensätze, Testfälle, Regression.

Arbeitsmodus:

  • Zweiwöchentliche Demos an echter Linie/Daten, nicht in Slides.

  • Akzeptanzkriterien vorab als messbare Metriken definieren und beibehalten.

  • Feature Toggles und Ghost‑Mode für risikoarme Inbetriebnahme.

  • „Stop the line“‑Berechtigung: Wenn Metriken kippen, darf jeder den Rollback ziehen.

Evaluation, Monitoring, Fallbacks

  • Testharness: Fester Datensatz, deterministische Seeds, reproduzierbare Läufe, Base‑line verankert.
  • Offline‑Eval vor Prod‑Rollout; dann Shadow‑A/B mit echter Last.
  • Qualitätsmetriken je Use Case: z. B. FNR bei Defekterkennung, Lead‑Time bei PdM, Faithfulness/Hit‑Rate bei RAG.
  • Fallback‑Wege: Unsicherheits‑Schwellen, menschliche Überprüfung, klassische Regeln parallellaufen lassen.
  • Drift‑Management: Datenscans, Alarme, aktives Nachlabeln, kontrolliertes Re‑Training.

Typische Stolpersteine – und wie man sie vermeidet

  • Kamera/Beleuchtung vernachlässigt: Erst optische Stabilität, dann Modell‑Tuning.
  • Metrik‑Drift durch veränderte Datenerfassung: Datenverträge und Monitoring einführen.
  • RAG ohne Zugriffskontrolle im Retriever: Sicherheitskonzept von Anfang an.
  • Zu breite Ziele („Assistent für alles“): Einen Prozess, eine KPI, eine Station.
  • POC ohne Integration: Wenn es nicht in SPS/MES/CMMS rein‑ und rauskommt, ist es kein Ergebnis.
  • Keine Observability für LLM‑Agenten: Ohne Telemetrie, Tool‑Limits und Prompt‑Versionierung wird der Betrieb riskant.
  • Datenqualität überschätzt: Ein kleiner, sauberer Datensatz schlägt einen großen, inkonsistenten.

Ein 30/60/90‑Tage‑Plan für den ersten produktiven KI‑Use‑Case

Tage 0–30:

  • Problem und KPI festzurren, Datenquellen vertraglich/technisch öffnen.

  • Minimal‑Architektur on‑prem aufsetzen (Storage, Container, Registry).

  • Baseline‑Modell und erste Integrationspunkte (Ghost‑Mode).

  • Security‑Grundlagen: Secrets, Logging mit Redaktionen, Rollen.

Tage 31–60:

  • Metriken messen, Grenzfälle sammeln, aktives Lernen starten.

  • UI/Workflows für Operatoren/Techniker, Fallback‑Szenarien implementieren.

  • Evaluationsharness mit fixem Datensatz, Regressionstests in CI.

  • Audit‑ und Monitoring‑Dashboards produktionsnah.

Tage 61–90:

  • Kontrollierte Produktivschaltung mit eng gesetzten Rate‑Limits.

  • Schulung, Betriebshandbuch, SOPs; On‑Call/Incident‑Prozess.

  • Post‑Mortems für Fehlalarme/Fehlklassifikationen, Modell‑Update‑Policy.

  • Entscheidung: Skalieren auf zweite Station/Maschine oder vertiefen.

Mittelstand vs. Konzern – ein realistischer Vergleich

  • Vorteil Mittelstand:
  • Kürzere Wege zu den Anlagen und Experten, weniger Silos.
  • Mut zu pragmatischen Lösungen statt Konzern‑Framework‑Zwang.
  • Ownership der gesamten Kette möglich: vom Sensor bis zur UI.
  • Nachteil Mittelstand:
  • Begrenzte Plattformkapazität; Disziplin in Tool‑Auswahl ist Pflicht.
  • Abhängigkeit von Schlüsselpersonen; Dokumentation und Automatisierung priorisieren.
  • Hardwarebeschaffung kann bremsen; früh planen und Alternativen (Loaner‑GPUs, Co‑Location) parat haben.
  • Konsequenz:
  • Fokussierte Use Cases mit klarer Wirkung, robustem on‑prem Betrieb und guter Observability schlagen große Blaupausen.

Checkliste vor Projektstart

  • Ist die Ziel‑KPI messbar und akzeptiert?
  • Ist der Datenzugang geklärt – technisch, rechtlich, organisatorisch?
  • Gibt es einen klaren Integrationspunkt in den Prozess (lesen/schreiben)?
  • Sind Fallbacks und Unsicherheitsgrenzen definiert?
  • Stehen Monitoring, Logging, Audit und ein Basis‑Sicherheitskonzept?
  • Wer entscheidet bei Konflikten zwischen Genauigkeit, Latenz, Kosten?

FAQ