Von POC zu Produktion: Warum der Übergang so schwer ist – und wie souveräne KI-Architekturen ihn planbar machen

KI kennt dein Business nicht. Sie kennt keinen Takt in der Fertigung, keinen regulatorischen Audit in der Bahnindustrie, keine IT/OT-Trennung in der Produktion, keine Exportkontrollauflagen in der Verteidigung. Genau deshalb kippen so viele vielversprechende KI-POCs beim Schritt in die Produktion. Nicht, weil das Modell “schlecht” ist, sondern weil das System rundherum fehlt: Datenstrategie, Architektur, Betriebsmodell, Governance.

Wenn Sie KI ernsthaft in Ihr Kerngeschäft bringen wollen, müssen Sie technische Entscheidungen treffen, die über Modellwahl und Prompt-Engineering hinausgehen. Und Sie müssen sie unter realen Nebenbedingungen treffen: Latenzfenster, deterministische Reaktion, Auditierbarkeit, Vendor-Unabhängigkeit, on-premise-Betrieb. In diesem Beitrag zeige ich, warum der Übergang von POC zu Produktion hart ist, wie Sie ihn mit einer souveränen Architektur entkoppeln, und welche konkreten Muster sich in der Industrie bewährt haben.

Was am POC funktioniert, bricht in Produktion: sieben unsichtbare Anforderungen

Ein POC beweist in der Regel nur, dass ein Modell unter Laborbedingungen eine Aufgabe lösen kann. Produktion bedeutet: dieselbe Aufgabe unter wechselnden Daten, mit verteilten Systemen, in einer sicherheitskritischen oder kostengetriebenen Umgebung, reproduzierbar, auditierbar und betreibbar. Das sind andere Anforderungen.

  • Datenverfügbarkeit und Datenqualität in der Realität:
  • Produktionsdaten haben Ausreißer, Lücken, Kalibrierungsdrifts, Schichtwechsel-Effekte.
  • In der Fertigung sitzen Sensoren hinter OT-Segmentierungen; Daten kommen über OPC-UA, Modbus, proprietäre Protokolle oder sporadisch per Batch.
  • Ein POC mit handverlesenen CSVs sagt nichts über die spätere Verfügbarkeit, Latenz und Datenqualität aus.
  • Latenz, Durchsatz, Determinismus:
  • Visuelle In-line-Inspection mit 50–200 ms Budget hat andere Zwänge als eine Backoffice-Analyse mit 5 s Toleranz.
  • KI muss in bestehende Taktzeiten passen. Ein Modell, das im POC 400 ms braucht, lässt sich selten in 80 ms quetschen ohne Architekturänderung (Quantisierung, TensorRT, Pipeline-Parallelisierung).
  • Sicherheit und Compliance:
  • DSGVO, branchenspezifische Normen, Exportkontrolle, kundenspezifische Auflagen. Prompt-Logs, Trainingsdaten und Modellartefakte sind personenbezogen oder vertraulich.
  • Wer trifft wann welche Entscheidung? Wer hat welches Recht? Nachvollziehbarkeit über Jahre.
  • Skalierung und Kostenkontrolle:
  • POC läuft auf einer einzigen GPU. Produktion bedient 20 Werke in drei Ländern, 24/7. Kostentreiber sind nicht nur GPUs, sondern auch Netz, Speicher, Labeling, Observability.
  • Kosten pro Entscheidung sind eine reale Metrik. Bei Agenten zusätzlich Kosten pro Token.
  • Änderungsgeschwindigkeit und CI/CD:
  • Modelle altern. Daten driften. Sicherheitslücken in den Bibliotheken. Releases müssen reproduzierbar, testbar, rollback-fähig sein – über Daten, Modelle und Infrastruktur hinweg.
  • Beobachtbarkeit und Debugging:
  • Ohne Traces, Metriken und Logs, die bis zur Datenversion und zum Commit zurückführen, ist jede Fehlersuche ein Ratespiel.
  • Für LLM-Anwendungen zusätzlich: Prompt/Response-Kontrolle, Tool-Aufrufe, Policies, Redaktionsschritte.
  • Ownership und Betriebsmodell:
  • Wer besitzt das Modell? Wer betreibt es? Wer wird nachts geweckt? Ohne klare Ownership versanden Systeme zwischen IT, OT und Fachbereichen.

Datenstrategie vor KI-Strategie

Es ist ein verbreiteter Fehler, ein Modell auszuwählen, bevor die Datenfrage geklärt ist. Ohne saubere Datenarchitektur wird jede KI-Strategie zufallsgetrieben. Was bedeutet das konkret?

  • Datenlandkarte und Domänenabgrenzung:
  • Erstellen Sie eine Datenlandkarte: welche Systeme, welche Quellen (MES, ERP, SCADA, PLM), welche Sensordaten, welche Dokumente, welche Protokolle.
  • Definieren Sie Domänengrenzen. Ein Data Mesh-Ansatz kann sinnvoll sein, wenn Domänen eigenständig liefern können. Sonst zentralisieren Sie zu Beginn bewusst, um Reibung zu reduzieren.
  • Data Contracts und Schemas:
  • Maschinen-Event “Schraubvorgang_erfolgreich” braucht ein vertraglich zugesichertes Schema, Versionierung und SLAs (Latenz, Verfügbarkeit).
  • Verlagern Sie qualitative Diskussionen in überprüfbare Verträge, nicht in E-Mail-Threads.
  • Ingestion und Speicherung:
  • Streaming: Kafka mit Schema Registry (Avro/Protobuf) für Ereignisse; Debezium für CDC aus relationalen Systemen.
  • Batch: definierte Extraktionen aus ERP/MES mit Checksummen und Versionierung.
  • Speicherung: Lakehouse auf S3-kompatibler Storage (MinIO, Ceph) mit Iceberg/Delta; WORM-Buckets für Audit. On-premise, damit Daten die Fabrik/das Land nicht verlassen.
  • Versionierung und Lineage:
  • Datenversionierung mit LakeFS oder DVC; Metadaten plus lineage bis zur Rohquelle.
  • Ohne Dataset-Versionierung sind Modellmetriken nicht wiederholbar.
  • Qualität und Labeling:
  • Automatisierte Checks (Anteil fehlender Werte, Range-Checks, Drift-Statistiken) bei jeder Pipeline.
  • Labeling-Strategie: aktives Lernen, golden truth mit klaren Review-Flows, Inter-Annotator-Agreement. Für Vision: definierte Guidelines, QA-Loop im Prozess.
  • Feedback-Loop:
  • Bauen Sie den Rückkanal vom Betrieb ins Training ein: Fehlklassifikationen, Nutzerfeedback, Korrekturen fließen in den nächsten Release-Zyklus.

Eine Referenzarchitektur für souveräne KI in der Industrie

Wir sehen in der Praxis eine robuste, reproduzierbare Architektur mit klaren Schichten. Wichtig: “souverän” heißt, Sie kontrollieren Ausführung, Daten und Abhängigkeiten – fachlich und technisch. Kein US-Cloud-Zwang, Auditierbarkeit by design.

  • Infrastruktur und Orchestrierung:
  • Kubernetes on-prem (z. B. OpenShift, Rancher, kOps) mit GPU-Knoten; MIG-Partitionierung für Auslastung.
  • Container-Registry gespiegelt on-prem, Air-Gapped-Optionen für Defense/OT.
  • SPIFFE/SPIRE für Service-Identitäten, mTLS zwischen Diensten, OPA/Envoy für Policy Enforcement.
  • Datenebene:
  • Ingestion: Kafka, MQTT/OPC-UA-Bridges, dedizierte Konnektoren; Schema Registry mit Versionierung.
  • Lakehouse: Iceberg/Delta auf MinIO/Ceph; Partitionierung nach Zeit/Anlage/Produkt.
  • Governance: Katalog (Amundsen/DataHub), ABAC/RBAC auf Spalten-/Zeilenebene, Pseudonymisierung möglichst früh.
  • Feature- und Trainingsebene:
  • Feature-Store (Feast) getrennt in Offline/Online; Reproduzierbarkeit von Featuresets.
  • Training: Kubeflow, Ray oder Flyte für Pipelines; GPU-Workloads; reproduzierbare Environments (conda-lock, Nix, Container mit SBOM).
  • Modell-Registry: MLflow oder vergleichbar mit Model Cards, Artifaktverweisen, Genehmigungs-Workflows.