KI kennt dein Business nicht: Warum viele KI-Initiativen an der Realität scheitern – und wie Sie es besser machen

Praktische KI in Industrieunternehmen scheitert selten an „schlechten Modellen“. Sie scheitert an falsch gestellten Problemen, an fehlender Datenstrategie, an nicht adressierten nicht-funktionalen Anforderungen und an Souveränitätsfragen, die erst in späten Projektphasen sichtbar werden. Der Rest ist Hype. Dieser Text argumentiert aus Sicht eines Engineers: Problem zuerst, Architektur und Daten danach, erst dann Model-Choice. Und: Souveränität ist kein Compliance-Häkchen, sondern ein Designprinzip.

These klar vorweg: KI kennt Ihr Business nicht. Große Sprachmodelle, Bildmodelle oder Agenten sind leistungsfähig – aber generisch. Der Mehrwert entsteht, wenn Sie Ihr Domänenwissen, Ihre Prozesse, Ihre Messgrößen und Ihre Sicherheitsanforderungen in die Systemarchitektur einbetten. Wer diese Klammer auslässt, produziert schnell teure POCs ohne Produktionstauglichkeit.

Businesslogik schlägt Modelgröße

Sprachmodelle können Code schreiben, Dokumente zusammenfassen und Workflows anstoßen. Bildmodelle finden Kratzer auf Bauteilen. Keines dieser Modelle kennt aber Ihre Prüfvorschriften, Ihre Toleranzfenster, Ihre Haftungsrisiken oder die Eigenheiten Ihrer Datenentstehung. Das ist keine Schwäche der Modelle, sondern eine Architekturverantwortung.

Was daraus folgt:

  • Formulieren Sie das Ziel als Systemverhalten, nicht als Modellleistung.

Beispiel: „Reduziere ungeplante Stillstände um X Ereignisse pro Zeitraum bei Konstanten A/B“ ist ein Systemziel. „Erhöhe AUC auf dem Validationsset“ ist ein Modellziel. Beides hängt zusammen, aber nur das Systemziel trägt ROI.

  • Erzwingen Sie Invarianten in der Architektur, nicht in Prompt-Texten.

In Produktion müssen Mindestanforderungen wie „keine PII ausgeben“, „bei Ambiguität eskalieren“ oder „Liefertermine nie halluzinieren“ durch Policies, Validierer und Tooling abgesichert werden – nicht durch wohlmeinende Hinweise im Prompt.

  • Bauen Sie die Brücke zwischen Domänenlogik und Modell.

Beispiele: Regel-Engines als negative/positive Filter vor der Modellentscheidung, Constraint Decoding für Output-Formate, semantische Validatoren, die Domänenmetriken messen und Entscheidungen verwerfen, wenn Vertrauensgrenzen unterschritten werden.

Datenstrategie vor KI-Strategie

Wer beginnt mit „Welches Modell nehmen wir?“, baut auf Sand. Ohne stabile, auditierbare Datenflüsse lassen sich keine reproduzierbaren Ergebnisse erzielen – und keine Skalierung. Eine tragfähige Datenstrategie enthält mindestens:

  • Datenverträge und Semantik

Definieren Sie, welche Felder es gibt, wie sie entstehen, welche Einheiten gelten, welche Wertebereiche legitim sind. Maschinen- und Sensorwelten leiden häufig an impliziten Annahmen, die erst im Training brechen.

  • Herkunft, Versionierung, Reproduzierbarkeit

Jeder Trainingslauf, jede Auswertung muss auf einen eindeutig versionierten Datenstand referenzieren. Praktikabel: DVC/Datenschichten mit Content-Addressing, Hashes im Feature-Store, unveränderliche Artefakt-Registries.

  • Datenqualitäts-SLAs

Metriken wie Lückenrate, Jitter, Zeitstempel-Toleranzen, Label-Drift oder OCR-Fehlerraten gehören als rote Linien in die Pipeline. Beispiel: Ein RAG-System mit 5% fehlerhafter OCR halluziniert nicht – es referenziert falsche Inhalte. Ohne Sichtbarkeit wird das übersehen.

  • Ereignisorientiertes Sammeln statt statischer Dumps

Für Industriewelten bewährt sich ein Event-Log-Ansatz (z. B. Kafka/Redpanda): Rohereignisse aus Maschinen, Bedienaktionen, Störungsmeldungen fließen als Ereignisse ein; abgeleitete Sichten (Features, Trainingsdaten) entstehen deterministisch daraus. Das vereinfacht Audits und Rückrechnungen.

  • Label- und Feedback-Ops

Definieren Sie, wie Ground Truth entsteht: Wer darf labeln? Wie wird Qualität gemessen (Inter-Annotator Agreement)? Wie fließen Operator-Feedback oder Kundenkorrekturen kontrolliert in Re-Trainings ein? Ohne diesen Kreislauf veralten Modelle unbemerkt.

Vom POC zur Produktion: Warum der Übergang so schwer ist

Ein POC beantwortet: „Kann ein Modell das prinzipiell?“ Produktion verlangt: „Darf, soll und wird es das – zuverlässig, sicher, auditierbar und mit akzeptablen Kosten?“ Die harten Probleme liegen in nicht-funktionalen Anforderungen:

  • Latenz, Durchsatz, Ressourcenbudget

Ein CV-Modell, das offline in 200 ms inferiert, kann auf der Linie 24/7 unter Last scheitern. Ein LLM-Agent, der 20 Tool-Calls macht, blockiert Ihre Orchestrierung. Budgetieren Sie compute, Memory und IO gegen Zielmetriken, nicht gegen Best-Case.

  • Sicherheitszonen und Netzwerkgrenzen

Air-Gap-Umgebungen im Verteidigungs- oder OT-Umfeld erzwingen andere Architekturen als Internet-verbundene SaaS-Systeme. Modell-Serving, Vektorsuche, Feature-Stores und Observability müssen ohne US-Cloud-Abhängigkeit lauffähig sein.

  • Versionierung von Daten, Modellen, Prompts und Policies

Jede Produktivantwort eines LLM oder jede CV-Entscheidung muss rückführbar sein: Welcher Datensatz, welches Modell, welche Prompt-Version, welche Policy, welche Tools? Ohne diesen Pfad ist Audit faktisch unmöglich.

  • Fallbacks und Degradationspfade

Was passiert, wenn die Confidence sinkt, ein Tool ausfällt oder die Latenz überschritten wird? Produktionssysteme brauchen deterministische Fallbacks: Stop-the-line, Human-in-the-loop, konservative Defaults.

  • Change-Management

Neue Modellversionen sind Prozessänderungen. Rollout-Strategien (Shadow, Canary), Freigabeprotokolle und Rückrollbarkeit sind Pflicht. „Model by email“ endet im Chaos.

Beispielarchitekturen, die sich in der Praxis bewähren

On-Prem LLM/RAG-Stack für dokumentenzentrierte Prozesse:

  • Ingestion-Pipeline: Dateiwächter, OCR (z. B. Tesseract/docTR), Parser für Office/PDF, Extraktion von Strukturen (Tabellen, Überschriften).

  • Normalisierung: Chunking mit strukturellen Heuristiken, Metadaten-Anreicherung (Quelle, Gültigkeitsbereich, Klassifikation), PII-Erkennung und Schwärzung vor Indexierung.

  • Embeddings und Index: Lokale Embedding-Modelle, Vektorindex (pgvector, Qdrant) plus klassischer Index für Volltext/Filter.

  • Retrieval-Orchestrierung: Query-Umschreibung, Facettierung nach Gültigkeit, Diversifizierung der Evidenzen, Score-Fusion.

  • Generation und Guardrails: Lokales LLM-Serving (z. B. vLLM/Triton), strikte Output-Formate, Zitationspflicht, Policy-Checks vor Freigabe, optionale menschliche Freigabe.

  • Governance: Prompt-/Tool-/Policy-Versionierung, Event-Logging, PII-Redaktion, Audit-Export.