4) Vom POC in die Produktion: Warum der Sprung so schwer ist
Ein POC entspricht maximal TRL 3–4 (funktioniert im Labor). Produktion ist TRL 7–9 (funktioniert verlässlich im Feld, auditierbar, wartbar). Die Lücke ist groß.

Die härtesten Gräben:

  • Nicht-stationäre Welt: Ihre Datenverteilung ändert sich durch Saison, Lieferantenwechsel, neue Sensoren, neue Dokumentvorlagen. Das zerbricht jede statische POC-Annahme.

  • Prozessintegration: Ein Modell ist nur ein Teil der Entscheidungsschleife. Es braucht Inputvalidierung, Businessregeln, Ausnahmehandling, Fallbacks, UI/UX, Schulungen, Change Management.

  • SLOs und Haftung: „85% Genauigkeit“ ist keine Betriebszusage. Was zählt, sind SLOs: False-Alarm-Rate, verpasste Fehler, Latenz, Erklärbarkeit, MTTR – pro Use Case.

  • Sicherheit: Prompt Injection, Datenexfiltration über Tools, Poisoning, adversariale Inputs. Ohne Policies, Sandboxing und Red-Teaming landen Sie im Blindflug.

Ein stabiler Übergangsplan:

  • Thin-slice Use Case: Ein eng geschnittener Pfad von Ende zu Ende (z. B. nur ein Anlagentyp, nur ein Fehlermuster, nur eine Schicht). Messen Sie den End-to-End-Wert, nicht Modell-Accuracy in Isolation.

  • Gates statt Meilensteine: Reifegrade mit klaren Eintrittskriterien (Data Readiness, Offline-Scorecards, Shadow-Prod, Canary, Safety-Case, Audit-Playbooks). Kein Gate, kein Go.

  • Shadow → Assisted → Autonomy: Erst parallel bewerten (Shadow), dann mit Mensch-in-der-Schleife (Assisted), erst zuletzt Teilautomatisierung (Autonomy). Für jeden Schritt: explizite Risikomatrix und Freigabekriterien.

  • Observability und Governance als Produkt:

  • Telemetrie: pro Entscheidung Prompt/Kontext/Tool-Calls/Antwort/Ergebnisbewertung, korreliert mit Datenversion & Modell-Hash.

  • Policy-Engine: PII-Filter, Tool-Use-Whitelists, Kostenbudgets, Halluzinations-/Faktencheck-Regeln.

  • Replay/Sandbox: Reanalyse von Vorfällen, A/B-Tests, Sig-Regression-Checks vor Rollout.

  • Drift-/Leak-Detektion: Distribution-Drift, Prompt-Pattern-Anomalien, potenzielle IP/PII-Leaks, Tool-Misuse.

  • Audit-Artefakte: signierte Logs, Export für Compliance-Prüfungen.

5) Architektur-Blueprints, die in der Praxis tragen
Es gibt keine Einheitsarchitektur. Aber es gibt wiederkehrende Muster, die im DACH-Kontext robust sind.

Blueprint A: On-Prem LLM mit Retrieval und Tools in regulierter Umgebung

  • Ziel: Dokumentenassistenz, Wartungs- und Qualitätsleitfäden, Ticket-Triage.

  • Komponenten:

  • Ingest: asynchrone Pipeline (File watcher → OCR → Parser → Chunker → Embeddings). Parser deterministisch und versionsverwaltet.

  • Vektorspeicher: On-Prem (Qdrant/Milvus/pgvector), Mandantentrennung pro Werk/Abteilung.

  • LLM: lokal gehostet, deterministische Konfigurationen (Top-p/Temperature), LoRA für Domäne.

  • Tools: strikt gekapselt (z. B. SAP/Maximo-Connectoren, Wissens-API, Genehmigungsworkflow). Jede Tool-Funktion mit Input-/Output-Schemata (Pydantic), Rate Limits, Simulation-Modus.

  • Policy-/Observability-Layer: Prompt-Logging, Tool-Use-Logging, Kosten- und Sicherheitsrichtlinien, Replay.

  • Trade-offs: Höherer Initialaufwand, dafür Kontrolle, Auditierbarkeit und stabile Latenz.

Blueprint B: Edge-Computer Vision für Fertigung/Schiene

  • Ziel: Defekterkennung, visuelle Montageprüfung, Flotteninspektion.

  • Komponenten:

  • Daten: versionierte Datasets (Iceberg/Delta), Label-Qualitätssicherung, aktives Lernen (Inferenz → Unsicherheiten → Label-Queue).

  • Modelle: Leichte Backbones, quantisiert, ONNX/TensorRT; Domänenadaption via distillation.

  • Deployment: Edge-Boxen mit K8s/K3s, GPU Operator, OTA-Updates signiert, Blau/Grün-Rollouts.

  • Monitoring: Performance per Station, Drift via Embedding-Shift, Thermal/Power-Health der Edge-Geräte.

  • Rückfall: Regelbasierte Kontrollen, manuelle Inspektion, Stop-the-line-Policy.

  • Trade-offs: Harter Lifecycle- und Gerätebetrieb, dafür geringe Latenz, Datenschutz, Ausfallsicherheit bei Netzabbrüchen.

Blueprint C: Hybrid-Trainings-Cluster mit souveränem Lakehouse

  • Ziel: Periodische Retrainings, Feature Engineering, Batch-Evaluierungen.

  • Komponenten:

  • Storage: S3-kompatibel On-Prem, Versionskontrolle (Iceberg/Delta), Zugriff via ABAC.

  • Compute: On-Prem GPU/CPU-Cluster (Slurm oder K8s), optional Bursting in EU-Sovereign-Cloud mit Data-Egress-Policies.

  • MLOps: Feature Store, Model Registry, CI/CD (Train → Validate → Pack → Scan → Sign → Stage → Canary → Promote).

  • Security: Supply-Chain-Signing (Sigstore/Cosign), SBOMs, reproduzierbare Builds.

  • Trade-offs: Mehr Eigenbetrieb, aber planbare Kosten und klare Datenhoheit.

6) Metriken, die wirklich den ROI treiben
Verabschieden Sie sich von generischen „Accuracy“-Siegen. Messen Sie entlang der Entscheidungsschleife:

  • Entscheidungs-SLOs: Falsch-Positiv-/Falsch-Negativ-Rate dort, wo sie wirtschaftlich wehtun. Beispiel: Fehlteile nicht erkennen vs. unnötige Ausschleusungen.

  • TTFR/TTMP/MTTR: Time to First Result (erster messbarer Geschäftsnutzen), Time to Model in Production (vom Code zum auditierbaren Service), Mean Time to Remediation (von Anomalie zur stabilen Korrektur).

  • Unit Economics: Kosten pro verlässlicher Entscheidung, inkl. Datenpflege, Annotation, Infrastruktur, Support.

  • Betriebsstabilität: Prozent uptime bei OT-Constraints, Degradationspfade, Anteil automatisch gelöster Fälle vs. eskaliert.

7) Organisationsprinzipien für nachhaltige KI
Architektur ohne Organisation wirkt nicht.

  • Product Ownership für Use Cases: Ein/e PO verantwortet Ende-zu-Ende-Wert, nicht „das Modell“.

  • Kleine, interdisziplinäre Teams: Data, Software, Domäne, Security. Gemeinsame Definition of Done: inkl. Telemetrie, Tests, Dokumentation.

  • Change Management fest einkalkulieren: KI verändert Rollen und Abläufe. Ohne Schulung, Feedbackkanäle und klare Verantwortlichkeiten kippen Akzeptanz und Wert.

  • Sicherheitsdenken wie in Safety-Critical: Threat Modeling (Prompt/Tool/Data), Red-Teaming, regelmäßige Drills, Incident-Playbooks.

8) Eine klare Position zur Cloud-Frage

  • Technologie folgt Risiko und Wert, nicht umgekehrt. Für experimentelle, unkritische Use Cases ist die Cloud ein legitimer Beschleuniger. Für Kernprozesse mit IP/PII/Regulatorik ist On-Prem oder souveräne EU-Infrastruktur der Default.

  • „Wir starten in der Cloud und ziehen später um“ ist oft teurer als ein sauber geplantes On-Prem-Design mit klaren Schnittstellen. Planen Sie Portabilität ab Tag 1: Containerisierung, offene Protokolle, keine proprietären Vektor- oder Feature-APIs als Single Point of Failure.