Beispiel LLM‑RAG für Service‑Technik:

  • Problem: Lange Suchzeiten in Wartungshandbüchern; Wissensinseln.

  • Lösung: On‑prem RAG mit offenen Modellen, strikter Dokumentenkorpus (nur freigegebene Handbücher/Normen), Quellenzitate obligatorisch, Prompts versioniert.

  • Technische Besonderheit: PII‑Redaktion, Zugriffsrechte pro Produktlinie, Tool‑Aufrufe nur in Sandbox, detaillierte Observability der Retrieval‑Hitrate und Antwortannahme durch Nutzer.

8) Entscheidungsbaum: Startklar in 10 Fragen

  • Können wir das Problem in einer messbaren Zielmetrik ausdrücken?
  • Haben wir Zugriff auf ausreichende, rechtssichere Daten?
  • Gibt es eine nicht‑KI‑Baseline, die wir schlagen müssen?
  • Ist der Scope klein genug für 12 Wochen?
  • Wer ist fachlicher Owner mit Entscheidungsrecht?
  • Kennen wir die Rückfallebene im Betrieb?
  • Können wir on‑prem deployen (oder in souveräner EU‑Cloud) mit RBAC, Logging, Observability?
  • Haben wir eine minimale MLOps‑Basis (Versionierung, CI, Registry)?
  • Ist Governance geklärt (Datenschutz, Audit, Freigaben)?
  • Gibt es klare Kill‑Kriterien, falls das Ziel verfehlt wird?

Praktische Tool‑ und Architektur‑Empfehlungen zum Loslegen

  • Infrastruktur: Kubernetes, GitLab/Harbor Registry, MinIO, Postgres, Keycloak, Prometheus/Grafana, Loki.
  • MLOps: MLflow oder DVC, GitOps (ArgoCD/Flux), KServe/BentoML/Seldon.
  • CV: Standardarchitekturen mit Transfer‑Learning; Labeling mit CVAT; reproduzierbare Trainingscontainer.
  • LLM/RAG: Offene LLMs on‑prem, Embeddings mit offenen Modellen, pgvector als Start, strikte Prompt‑ und Tool‑Governance.
  • Sicherheit: Signierte Container, SBOM‑Prüfung, Secrets‑Management, Netzwerk‑Policies, Audit‑Logs.
  • Betriebsdisziplin: Versionierte Prompts/Modelle, Canary/Shadow‑Rollouts, feste Metriken im Monitoring.

Fazit

Für den Mittelstand ist KI kein Prestigeprojekt, sondern ein weiterer Baustein industrieller Software, der dieselben Ansprüche an Robustheit, Sicherheit und Nachvollziehbarkeit erfüllen muss wie jede andere produktive Anwendung. Wenn Sie problemgetrieben starten, on‑prem Souveränität als Architekturprinzip ernst nehmen und in 12‑Wochen‑Takten mit harten Go/No‑Go‑Kriterien arbeiten, sind belastbare Ergebnisse realistisch – ohne Hype und ohne Cloud‑Abhängigkeit.

FAQ

Frage: Brauchen wir zwingend GPUs on‑prem, um zu starten?
Antwort: Für produktive CV‑ und LLM‑Inferenz ist eine GPU in der Regel sinnvoll. Für Prototypen können kleine Modelle auf CPU genügen. Planen Sie frühzeitig Kapazität und Batch‑Größen; Quantisierung hilft, die Hürde zu senken.

Frage: Können wir LLM‑Use Cases DSGVO‑konform ohne US‑Cloud betreiben?
Antwort: Ja. Setzen Sie auf offene Modelle on‑prem, RAG mit klar definiertem Korpus, PII‑Redaktion, strikte Zugriffskontrollen und vollständige Audit‑Logs. Externe APIs mit personenbezogenen oder vertraulichen Daten vermeiden Sie dadurch vollständig.

Frage: Wie vermeiden wir „Modell‑Drift“ und Qualitätsabfall im Betrieb?
Antwort: Mit festen Testsets, kontinuierlichem Online‑Monitoring (Score‑Verteilungen, Fehlerraten, Retrieval‑Hitraten), Feedbackschleifen im UI und geplanten Re‑Trainingsfenstern. Jeder neue Modellstand wird gegen dieselben Benchmarks evaluiert und versioniert ausgerollt.

Frage: Was kostet der Aufbau einer minimalen MLOps‑Plattform?
Antwort: Der größte Aufwand ist Engineering‑Zeit für saubere Pipelines, Sicherheit und Betrieb. Open‑Source‑Bausteine reduzieren Lizenzkosten deutlich. Starten Sie bewusst klein: eine Registry, ein Object‑Store, ein Tracking‑System, ein Serving‑Framework – und Disziplin in Versionierung und Rollout.

Frage: Woran scheitern KI‑Projekte im Mittelstand am häufigsten?
Antwort: An unklarem Scope, fehlenden Zielmetriken, Datenzugangshürden und mangelnder Betriebsreife. Gegenmittel sind ein klarer 12‑Wochen‑Plan mit Kill‑Kriterien, frühe Integration in die Zielumgebung und eine minimale, aber saubere Plattformbasis mit Observability und Governance.