Titel: KI kennt dein Business nicht – warum die meisten Projekte scheitern und wie Sie mit souveräner Architektur in Produktion kommen

Kurzfassung für Ungeduldige:
Die meisten KI-Projekte scheitern nicht am Modell, sondern an schlecht formulierten Problemen, ungeklärten Datenverantwortlichkeiten und fehlender Produktionsreife. In Europa kommt ein vierter Zwang hinzu: Souveränität. DSGVO, EU AI Act und NIS2 erzwingen Kontrolle über Daten, Modelle und Lieferketten. Wer in 2026 produktive KI will, baut problemgetrieben, datengetrieben und souverän: erst Datenstrategie, dann Modell; erst Architektur, dann Cloud; erst Betrieb, dann POC. Dieser Beitrag zeigt die konkreten Muster, Architekturen und Trade-offs, mit denen Industriefirmen in DACH, Benelux und Nordics heute belastbare KI-Systeme bauen.

Hinweis zur Faktengrundlage:
Dieser Beitrag stützt sich auf in Europa geltende Regularien (DSGVO/GDPR, EU AI Act, NIS2), etablierte Engineering-Praktiken in industriellen IT/OT-Umgebungen sowie Erfahrungen aus produktiven Industrieprojekten. Wo Zahlen üblich wären, konzentrieren wir uns bewusst auf überprüfbare Architekturprinzipien statt Schätzwerte.

1) Problem first: KI kennt Ihr Business nicht
Modelle optimieren Zielfunktionen. Ihr Business hat jedoch operative Zwänge, Sicherheitsauflagen, Lieferketten, Wartungsfenster, Betriebsräte und Haftungsfragen. Ohne präzise Problemdefinition optimiert die KI zuverlässig das Falsche.

So formulieren Sie ein KI-Problem, das produktionsfähig ist:

  • Geschäftsobjekt und Entscheidung definieren: Beispiel Fertigung – “Entscheidung: Stoppe Linie X innerhalb von 2 Sekunden bei Defektklasse D mit Falsch-Positiv-Rate < 0,5%”.

  • Nichtfunktionale Anforderungen zuerst: Latenz, Verfügbarkeit, Auditierbarkeit, Erklärbarkeit, Datenschutz (PII), Sicherheitsklassifizierung (z. B. Safety Integrity Level), Exportkontrollen.

  • Datenfluss spezifizieren: Welche Sensoren/Kameras/IT-Systeme? Datenfrische? Datenvolumen pro Minute? Datenlokation (Werk, Land, Netzwerkzone)?

  • Betriebsintegration festlegen: Wer reagiert wie auf welches KI-Signal? Welche Failover-Strategie? Wie Rollback? Wie Alarmierung?

  • Akzeptanzkriterien messbar machen: Welche Off-/Online-Metriken entscheiden Go/No-Go? Wie oft und womit wird reevaluiert?

Die Antipatterns kennen wir alle:

  • Laborsieg: 99% Accuracy in Jupyter, 0% Nutzen in der Linie, weil die SPS keinen neuen Inputkanal hat.

  • KPI-Illusion: “Wir haben ein Modell produktiv”, zählt aber nicht, wenn niemand darauf vertraut und es im Bypass hängt.

  • Tech-First: “Wir brauchen LLMs”, obwohl ein deterministischer Parser und ein Suchindex das Problem robuster lösen.

2) Datenstrategie vor KI-Strategie
Ohne belastbare Datenlogistik keine belastbare KI. Nicht mehr Data Lake vs. Data Mesh ist die Frage – sondern: Haben wir formalisierte Datenverträge und Verantwortlichkeiten, die eine reproduzierbare, revisionssichere KI-Pipeline ermöglichen?

Was in Industriekontexten funktioniert:

  • Datenverträge (Data Contracts): Produzent und Konsument vereinbaren Schema, Qualität (z. B. Nullraten, Gültigkeitsbereiche), Latenz, Verfügbarkeit, Eigentümer, Eskalationspfade. Versioniert und testbar.

  • Domänenspezifische Ontologien: Ein “Defekt” in Werk A ist nicht automatisch ein “Defekt” in Werk B. Semantik gehört ins Datenmodell, nicht in implizite Notebooks.

  • Lineage und Reproduzierbarkeit: Jedes Vorhersageergebnis rückverfolgbar zu Modellversion, Feature-Set, Hyperparametern, Trainingsdaten-Snapshot, Code-Commit und Build-Umgebung. Ohne diese Kette ist Audit und Root-Cause-Analysis Glückssache.

  • PII- und Geheimschutz-by-Design: Klassifizieren Sie Daten (öffentlich/intern/vertraulich/streng vertraulich). Definieren Sie Transformationen (Masking, Pseudonymisierung) und scheiden Sie PII früh ab. Trennen Sie Feature-Pipelines physisch/logisch.

  • Qualitäts-SLAs: Metriken wie Drift, Missing Values, Sensor-Kalibrierungsfehler sind Betriebsmetriken – nicht nur Data-Science-Kuriositäten. Sie gehören ins Monitoring mit Alarmen und Tickets.

Werkzeuge und Muster:

  • Versionierung: LakeFS oder DVC für Datensnapshots; Git für Code; ein Modell-Registry (z. B. MLflow, KServe-ModelMesh oder ein internes Artefakt-Repository).

  • Validierung: Great Expectations oder pandera für datenvertragsbasierte Checks in CI/CD.

  • Zugriff: ABAC/RBAC, fein granular, technisch durchsetzbar (z. B. via OPA/Rego Policies). Schlüsselmaterial in KMS/HSM, nicht in Umgebungsvariablen.

3) Souveräne KI in Europa ist kein “Nice-to-have”
Drei regulatorische Tatsachen bestimmen den Spielraum:

  • DSGVO/GDPR: Personenbezug, Rechtsgrundlagen, Zweckbindung, Datenminimierung, Betroffenenrechte, Datenschutz-Folgenabschätzung bei hohem Risiko.

  • EU AI Act: Risikoklassen, Anforderungen an Datenqualität, Dokumentation, Monitoring, Transparenz; Hochrisiko-Systeme unterliegen strengen Pflichten.

  • NIS2: Erhöhte Sicherheitsanforderungen, Risiko- und Incident-Management, insbesondere für Betreiber wesentlicher Dienste/Industrien.

Dazu kommen:

  • Lieferkettensicherheit (Software Supply Chain): Nachvollziehbarkeit von Modellen, Trainingsdaten, Bibliotheken; Signaturen und SBOMs für Modelle sind der neue Standard.

  • Datenresidenz und Zugriffshoheit: Cloud-Angebote unter außereuropäischer Gesetzgebung bergen Zugriffsrisiken; viele öffentliche Auftraggeber und regulierte Industrien verlangen explizite Souveränität (Residenz + Jurisdiktion + Betriebsverantwortung).

Konsequenz für Ihre Architektur:

  • On-Premise- oder streng souveräne Cloud-Deployments als Default. Hybrid nur, wenn Datenklassifizierung dies erlaubt – dann mit klaren Verträgen und technischem Enforcing.

  • Keine Abhängigkeit von US-Cloud-Ökosystemen, wenn Daten- oder Modellzugriffsrisiken nicht tragbar sind. Das betrifft auch Telemetrie- und Observability-Tools.

  • Modellwahl mit Blick auf Lizenz, Reproduzierbarkeit, Langfristpflege. Open-Model-Ökosysteme (mit lokalem Feintuning/Adaptern) sind in regulierten Umgebungen oft die praktikablere Option gegenüber reinen API-Blackboxes.

4) Vom POC zur Produktion: der echte Härtetest
POCs gewinnen in drei Monaten Vertrauen. Produktion hält in drei Jahren Audits stand. Die Lücke dazwischen ist MLOps, Security und Change-Management.