Europäische Industrieunternehmen brauchen Souveränität. Nicht aus Prinzip, sondern aus Risiko- und Kostenlogik:

  • Rechtliche Risiken: Personenbezug, Betriebsgeheimnisse, Lieferketten- und Exportthemen. Ein ungeprüfter Drittlandtransfer kann Projekte stoppen – oder Jahre später sehr teuer werden.

  • Wirtschaftliche Risiken: Vendor Lock-in und Preisschwankungen. Betriebsmodelle müssen TCO-kalkulierbar bleiben.

  • Operative Risiken: Abhängigkeit von externer Verfügbarkeit und API-„Policy Drift“ (geänderte Nutzungsbedingungen, Rate Limits).

Technisches Zielbild für souveräne KI (on-prem/sovereign cloud):

  • Rechenebene: Kubernetes-Cluster mit separaten Pools für CPU/GPU. Scheduling mit Ressourcenquoten, Fairness, Preemption Policies. Container-Images deterministisch gebaut (SBOM, reproducible builds).

  • Speicher: Objekt-Storage (MinIO) mit Bucket-Policies, Versionierung, WORM sofern nötig. Block-/File für Low-Latency (Ceph).

  • Datenverarbeitung: Spark/Flink for batch/stream, Airflow/Kestra für Orchestrierung. Data Contracts durchgesetzt via CI.

  • Identität & Policy: Keycloak (OIDC), Vault (Secrets), OPA/Gatekeeper (Policies as Code), Netzwerksegmente (Zero Trust, mTLS).

  • ML/MLOps: MLflow (Registry), Feast (Feature Store), Prometheus/Grafana (Monitoring), EFK-Stack (Logs).

  • LLM-spezifisch:

  • Modelle: In-house gehostete LLMs (z. B. Llama, Mixtral) mit quantisierten Inferenzen (INT8/FP16 je nach Latenz/Präzision).

  • RAG: On-prem Vektorindex, striktes Retrieval-Fenster, Document-Access-Policies bis auf Attributebene.

  • Agenten: Tool-Use nur via freigegebene Adapter mit Sidecar-Policy. Jede Aktion ist zweiphasig: Plan -> Review -> Commit. Kein direkter Zugriff auf produktive Systeme ohne Gate.

Observability & Governance für LLM/Agenten ist Pflicht:

  • Telemetrie: Jede Prompt-/Tool-Call-Kette als Event-Log mit Korrelation-ID. Metriken: Halluzinationsrate (über Benchmarks), Retrieval-Hitrate, Policy-Violations, Tool-Success-Rate.

  • Policies als Code: Verbote (z. B. keine PII-Ausgaben), PII-Detektoren, Regex/NLP-basierte DLP, Rate Limits pro Identität, Kontextfensterbegrenzung.

  • Reproduzierbarkeit: Prompt- und Kontextversionierung, deterministische Seeds, Modellhashes. Ohne das ist Root-Cause-Analysis unmöglich.

  • Human-in-the-Loop: Risikobasierte Freigaben; bei Score > Threshold muss ein Mensch bestätigen. Audit-Logs sind exportierbar.

Teil 4: Von POC zu Produktion – warum der Übergang hart ist

Der Bruch verläuft entlang dieser Kanten:

1) Notebook -> Service

  • POC: Jupyter, manuelles Feature-Engineering, ad-hoc Daten.

  • Produktion: Wiederholbare Pipelines, Tests, Container, CI/CD.

  • Umsetzung: Test-Pyramide für ML (Unit-Tests auf Transformationslogik, Data-Contract-Tests, Offline-Evals gegen Holdout, E2E-Tests mit synthetischen Störungen). Packaging mit Poetry/uv, Images mit pinned Dependencies.

2) Offline-Metrik -> Online-Servicequalität

  • POC: ROC-AUC sieht gut aus.

  • Produktion: SLA/SLOs (Latenz p95, Availability, Freshness, Degradation-Strategy). Beispiel: Fällt die Inferenz aus, greift heuristische Fallback-Regel, damit die Linie nicht steht.

3) Statische Daten -> Driftende Realität

  • POC: Snapshot-Daten.

  • Produktion: Rolling-Window-Training, Data-Quality Gates, Canary/Shadow.

  • Umsetzung: Shadow-Inferenz über echte Live-Daten, keine Entscheidungen. Vergleich gegen produktives Modell, Signifikanztests. Bei Stabilität -> Canary mit 5% Traffic -> Ramp-up.

4) Einzelteam -> Betriebsschnittstellen

  • POC: Ein Data-Scientist, ein Domänenexperte.

  • Produktion: Betrieb/IT, Security, Datenschutz, Betriebsrat.

  • Umsetzung: RACI-Klärung, Change-Management, Runbooks, 24/7-Bereitschaft dort, wo der Business-Impact es erfordert.

Eine praxistaugliche Übergangs-Checkliste:

  • Problem: Explizite Kostenfunktion, Decision Boundary, Trust-Kriterien.

  • Daten: Vertraglich fixiert, Qualitätstests automatisiert, Lineage nachvollziehbar.

  • Modell: Versioniert, reproduzierbar, mit Offline-Eval gegen geschäftsrelevante Metriken.

  • Service: Containerisiert, Observability (Logs/Metrics/Traces), Fallbacks.

  • Sicherheit/Compliance: Policies implementiert, Audits bestanden.

  • Rollout: Shadow -> Canary -> General Availability, mit Rollback-Plan.

Teil 5: Entscheidungsrahmen – nicht alles bauen, aber das Richtige besitzen

  • Cloud vs. On-Prem:
  • Wenn Datenhoheit, Latenz, oder rechtliche Klarheit Pflicht sind: On-Prem oder souveräne Cloud. Rechnen Sie TCO inklusive Egress, Langläufer-Inferenz und erwarteter Skalierung. Cloud ist exzellent für variable Forschungslasten; Produktion mit planbaren Lasten ist on-prem oft berechenbarer.
  • Feinabstimmung vs. Retrieval (RAG):
  • Domänensprache und Stil -> Fine-Tuning sinnvoll.
  • Volatile Faktenlage, Dokumentenwissen -> RAG. Oft reicht Instruct-Feintuning plus gutes Retrieval.
  • Edge vs. Zentrale:
  • Safety-kritische kurze Pfade -> Edge.
  • Analyse und Fleet-Learning -> Zentrale.
  • Build vs. Buy:
  • Differenzierende Fähigkeiten (z. B. domänenspezifische Prüfalgorithmen) bauen.
  • Undifferenzierte Capabilities (CI/CD, Observability, Policy-Rahmen) integrieren, aber so, dass Sie die Daten und Policies besitzen.

Teil 6: Minimal Viable AI – ein Blueprint, der hält

Wählen Sie eine einzige Entscheidung mit hohem Hebel:

  • Beispiel Fertigung: „Stoppe Linie automatisch, wenn Defektklasse A mit P(FEHLER) > 0,98 detektiert wird – sonst menschlicher Review in < 30 s.“

  • So schneiden Sie:

1) Daten: 3 repräsentative Linien, 3 Schichten, 4 Wochen – mit Label-Workshop zur einheitlichen Semantik. Data Contract mit Bildauflösung, Licht-Setup, Takt.
2) Metriken: Cost-weighted Precision/Recall, Latenz p95, Review-Zeit, False-Stop-Kosten.
3) Architektur: Kamera -> Edge-Inferenz (INT8-Quantisierung, TensorRT) -> Event an Kafka -> Gate-Service (Rules + Model Score) -> SPS-Adapter (OPC UA Method Call) -> Audit-Log.
4) Governance: Kein Export von Rohbildern aus der Zone; Pseudonymisierung, Retention 30 Tage, Rollenrechte in Keycloak.
5) Betrieb: Shadow für 2 Wochen, dann Canary 10%, wöchentlicher Drift-Report. Kill-Switch definiert.
6) Erfolgskriterium: Reduktion Fehlteile um X, < Y Fehlstopps/Monat, < Z s Reviewzeit. Wenn verfehlt: Ursachenanalyse mit Telemetrie, nicht Bauchgefühl.

LLM-/Agenten-spezifische Ergänzung:

  • Use-Case: Techniker-Support. RAG auf freigegebenen Wartungshandbüchern, Tool-Adapter für Ersatzteil-Suche. Policy: Kein freier Webzugriff, keine PII-Ausgabe. Observability: Jede Tool-Kette geloggt, Halluzinations-Bench regelmäßig, Feedback-Knopf im UI. Human-in-the-Loop für Bestellungen > Schwellenwert.

Teil 7: Was Sie morgen tun können