Qualität und Sicherheit:

  • Starten Sie mit „Fehler-Fenstern“ aus der Historie; definieren Sie, welche Alarme wirklich zu Handlungen führen.

  • Metriken: Vorwarnzeit, Präzision der Alarme, Belastung der Mannschaft (Alarm-Fatigue).

  • Betriebsregeln: „Don’t surprise Ops“ – jede neue Alarmklasse geht erst in Shadow-Mode.

Wo Sie am Anfang nicht starten sollten

  • „Unternehmensweiter KI-Chatbot“ ohne klares Rechte- und Haftungskonzept.

  • Vollautomatisierte Closed-Loop-Steuerungen ohne vorgelagerte SOTIF-/FMEA-Betrachtung.

  • Greenfield-„KI für alles im ERP“: erst gezielte Satellitenfunktionen bauen, nicht das Herzsystem anfassen.

  • Reine Datenplattform-Projekte ohne klaren ersten Produktinkrement.

3. Architekturmuster für Datensouveränität ohne US-Cloud
Das Betriebsmodell entscheidet. Drei praxistaugliche Muster:

Muster A: Streng on-prem, ggf. air-gapped

  • Artefaktspiegel: Eigene Container-/Model-Registry (z. B. Harbor), SBOM und Signaturen.

  • Orchestrierung: k3s/RKE2 oder klassisches Kubernetes je nach Teamreife; GitOps (Argo CD/Flux).

  • Keine ausgehenden Verbindungen zur Laufzeit; Updates über geprüfte Offline-Pakete.

  • IAM: On-Prem SSO (Keycloak), feingranulare Rollen; Audit-Logs zentral.

Muster B: On-Prem mit kontrolliertem Egress

  • Training/Inference on-prem; Telemetrie in interne Observability-Stacks.

  • Selektive Updates aus kuratierten Quellen via Proxy, mit Scans und Freigaben.

Muster C: Hybrid mit EU-Cloud für Nicht-Geheimschutz-Daten

  • Strikte Trennung: Sensibles on-prem; unkritisches Preprocessing/Experimentieren in EU-Rechenzentren.

  • Datendiäten: Nur pseudonymisierte, minimierte Slices verlassen das Werk.

  • Reproduzierbarkeit: Gleiche Container/Configs on-prem und in der Cloud.

Querschnittsthemen

  • Reproduzierbarkeit: Infrastructure-as-Code, versionierte Datasets/Features, deterministische Seeds, Modellkarten mit Training-Commit und Hyperparametern.

  • Sicherheit: Least Privilege für Dienste, signierte Artefakte, Secrets über Vault-Mechanismen, Netzwerk-Policies.

  • Modelle: Offene Modelle werden intern gespiegelt; keine Direktaufrufe externer Foundation-APIs für sensible Daten.

  • Datenschutz: Datenminimierung, Protokollierung, Rechteprüfung vor Inferenz. Wo möglich, PII-Redaktion in Vorverarbeitung.

4. 12-Wochen-Fahrplan: Von Null zu produktivem Pilot

Woche 0–2: Problem-Sprint

  • Stakeholder-Interviews am Band/Arbeitsplatz, Walkthrough des realen Prozesses.

  • Formulierung der Akzeptanzkriterien: z. B. „Reduziert Fehlalarme gegenüber heutiger Regel um X, maximal Y verpasste Fehler im Shadow-Mode“.

  • Dateninventur und Risikoanalyse (Berechtigungen, Exportwege, Aufbewahrungsfristen).

  • Festlegen des Betriebsmodells (A/B/C), Bill of Materials, Rollen.

Woche 2–4: Thin-Slice-Architektur und Baselines

  • Aufsetzen der minimalen Plattform: Git, Container-Registry, CI-Pipeline, Observability (Logs/Metrics/Traces), Zugriffsmanagement.

  • Erstellen der Baseline: für CV einfache klassische Verfahren gegen ML vergleichen; für RAG reines Keyword-BM25 gegen Embeddings; für Maintenance robuste Schwellwerte gegen ML.

  • UX-Prototyp am echten Arbeitsplatz/System, Feedback sammeln.

Woche 4–8: Iteration mit echten Daten

  • Annotation/Labeling-Runden mit Fachexperten, aktives Lernen zur Datenauswahl.

  • Hartes Negative-Mining: jene Fälle einsammeln, in denen das Modell scheitert.

  • Integration in die Zielumgebung (UI-Panel, API, Dashboard), damit Shadow-Mode möglich ist.

  • Evaluationssuite fixieren: Golden Set, Metriken, Regressionschecks.

Woche 8–12: Shadow-Mode und Härtung

  • Betrieb in Shadow-Mode am echten Prozess, tägliche Auswertungen.

  • Guardrails aktivieren: Fallback-Pfade, Unsicherheits-Schwellen, Notausschalter.

  • Betriebsdokumentation, Onboarding der Mannschaft, Übergabeplan inkl. Update-/Rollback-Prozeduren.

  • Entscheidung Go/No-Go für produktiven Einsatz und Skalierung.

Team und Rollen (schlank)

  • 1 Tech Lead/Owner: Architektur, Schnittstellen, Qualität.

  • 1–2 ML/Software Engineers: Datenpipelines, Modelle, Integration.

  • 1 Domänenexperte aus dem Fachbereich: tägliche Entscheidungen, Labels, Akzeptanz.

  • Optional: IT/OT-Vertreter für Netzwerk/Deployment.

5. Hardware- und Kostenüberlegungen—pragmatisch

  • Trainings-/Experimentierstation: Solide Workstation mit einer mittelgroßen GPU und ausreichend RAM/SSD. Reicht für die genannten Erstprojekte oft aus.

  • Edge-Inferenz: Industrie-PC mit dedizierter, gemäß Umgebung ausgewählter Beschleunigerkarte oder optimiertem CPU-Stack. Achten Sie auf thermische Bedingungen, Staubschutz und Wartbarkeit.

  • Quantisierung und Kompression: Für Inferenz häufig sinnvoll (z. B. INT8), wenn Qualitätsverlust akzeptabel ist. Messen, nicht raten.

  • Speicherkonzept: Rohdaten getrennt von Trainings-/Inferenzartefakten; Vektorindizes und Modellartefakte regelmäßig sichern; Restore testen.

  • Lizenz- und Wartungskosten transparent machen: GPU-Treiber, Container-Orchestrierung, Observability-Stack, Annotation-Werkzeuge.

6. Qualität, Sicherheit, Compliance – wie in der Produktion

  • Evaluation:

  • Offline: Festes Golden Set, reproduzierbare Messung pro Commit/Release.

  • Online: A/B oder Shadow-Mode, Canary-Releases, klare Abbruchkriterien.

  • Guardrails:

  • CV: Unsicherheitsbereiche definieren, Pflicht zur menschlichen Bestätigung.

  • RAG/LLM: Quellenpflicht, Antwortgrenzen, Tool-Aufruf-Whitelist, Temperatur niedrig, Eskalation bei fehlender Evidenz.

  • Auditierbarkeit:

  • Versionierung von Daten, Modellen, Prompts.

  • Vollständige Traces von Inferenz und Agentenentscheidungen.

  • Unveränderliche Logs mit Aufbewahrungsfristen.

  • Datenschutz:

  • Datenminimierung am Eingang, Pseudonymisierung wo möglich.

  • Zweckbindung dokumentieren; Zugriff nach Rollen; DSFA bei personenbezogenen Szenarien prüfen.

  • Betrieb:

  • Kill-Switch je Service.

  • Rollback geübt, nicht nur dokumentiert.

  • Verantwortlichkeiten schriftlich (wer darf deployen, wer darf Daten freigeben, wer genehmigt Modellwechsel).

7. Warum der Mittelstand hier oft schneller ist als der Konzern

  • Kürzere Entscheidungswege: Der Meister, der die Schraube täglich sieht, sitzt wirklich mit am Tisch.

  • Brownfield-Stärke: Bestehende Linien, Werkzeuge, Spezifika – dort lebt das Differenzierungswissen.

  • Fokussierte Inkremente: Eine Linie, eine Station, ein Dokumentenraum – und dann skaliert man das Muster.

Die Kehrseite:

  • Jede zusätzliche Plattformkomponente ist realer Betriebsaufwand. Deswegen: minimaler Stack, maximal reproduzierbar. Lieber ein k3s-Cluster gut beherrschen als fünf Spezialprodukte halb.

8. Governance und Observability für LLM-gestützte Prozesse
Wenn Sprachmodelle anfangen, Werkzeuge aufzurufen (Dateisystem, Suchindizes, Service-APIs), steigt das Risiko. Ohne Observability und Governance sind Sie im Blindflug.