Datenstrategie vor KI-Strategie: KI kennt dein Business nicht
These:
KI kennt dein Business nicht. Sprachmodelle sind generisch, Ihr Betrieb ist es nicht. Wer heute „erstmal ein LLM anschließt“ und später über Daten, Souveränität und Produktionstauglichkeit nachdenkt, scheitert zuverlässig am Übergang vom POC zum Betrieb. Wenn Sie in DACH/Europa arbeiten, mit sensiblen Fertigungs-, Bahn-, Defence- oder Lieferketten-Daten, gilt umso mehr: Souveränität ermöglicht Intelligenz. Erst die saubere Problemformulierung, dann die Datenprodukte, dann die Architektur – und erst am Ende die Modellauswahl.
Worum es wirklich geht
KI ist kein Selbstzweck. Sie ist ein Automatisierungsmittel in konkreten Entscheidungs- und Wertschöpfungsketten. Das Engineering-Problem lautet selten „Wie nutze ich die neueste Model-API?“, sondern:
- Welche Entscheidung will ich schneller, robuster oder günstiger treffen?
- Welche Eingangsdaten habe ich heute verlässlich? In welcher Qualität? Mit welchen Zugriffsbeschränkungen?
- In welcher Laufzeit, mit welchem Fehlertoleranzfenster, mit welchem Audit-Anforderungsprofil?
- Welche Nebenbedingungen gelten: DSGVO, ITAR-ähnliche Exportrestriktionen, Luft-/Bahn-spezifische Safety Cases, Werksnetzwerke ohne Internet?
Ohne diese Leitplanken kann kein Modell – so stark es auch sein mag – das gewünschte Ergebnis liefern.
Datenstrategie vor KI-Strategie
„Wir haben Daten“ ist kein Datenprodukt. Bevor Sie „KI“ sagen, definieren Sie:
1) Datenprodukte statt Datenhaufen
- Ausgangslage: Systeminventar (MES, SCADA, ERP, PLM, DMS, Flotten-Telemetrie, Ticketsysteme)
- Ziel: stabile, versionierte, dokumentierte Datenprodukte mit klaren Eigentümern
- Vertragsförmige Schemas (Avro/Protobuf/JSON Schema)
- Datenqualitäts-SLAs (Vollständigkeit, Frische, Dublettenrate, Ausreißerquoten)
- Semantik und Geschäftsbegriffe (Glossar, Ontologie, eindeutige Kennungen)
- Lineage: woher kommt welches Feld, welche Transformationslogik?
2) Zugriff und Souveränität
- Zugriff: RBAC/ABAC über Identity-Provider, technische Service-Identitäten, least privilege
- Zweckbindung: Welche Modelle dürfen welche Felder zu welchem Zweck nutzen?
- DSGVO: Datenminimierung, Pseudonymisierung, Löschkonzepte; Auditierbarkeit aller Zugriffe
- Speicherort: On-Premises oder EU-Sovereign-Cloud; keine unkontrollierten Exfiltrationen zu US-APIs, wenn Datenlage das verbietet
3) Operative Eigenschaften
- Änderungsmanagement: Versionierung, Contract-Testing zwischen Datenerzeugern und KI-Verbrauchern
- Observability: Metriken über Latenzen, Backfills, Fehlerraten; reproduzierbare Snapshots für Trainings/Evals
- Kostenmodelle: Datenvolumina, Rechenlast, GPU-Bedarf, Growth-Kurven
Ohne diese Grundlagen verläuft jede „KI-Strategie“ in Experimenten, die in der Produktion nicht tragfähig sind.
Architektur: Von POC zu Produktion – ohne Überraschungen
Der gefährlichste POC ist der, der „funktioniert“, aber keine Produktionspfade hat: Public-API, keine Datenverträge, kein Logging, keine Guardrails. Besser: Planen Sie Produktion vom ersten Tag – mit klaren Gates.
Ein belastbares Muster für industrielle LLM-/ML-Systeme:
1) Ingestion und Vorverarbeitung
- Quellen: DMS (PDF, CAD-Exporte), Sensorik (Zeitreihen), Tickets, E-Mails, Wikis
- Verarbeitung:
- OCR (bei Scans), Layout-Parsing (Tabellen/Schaltpläne), Strukturerhalt (Überschriften, Abschnitte)
- Chunking mit semantischen Grenzen (Kapitel, Abschnitte, Tabellenzeilen)
- Metadaten-Pflege: Gültigkeitsbereich, Version, Sicherheitsfreigaben
- Qualität: Validierung gegen Schemas; fehlertolerante Pipelines (Dead-Letter-Queues)
2) Speicherung
- Dokumente: Objektspeicher on-prem (z. B. S3-kompatibel, WORM-fähig für Audit)
- Indizes:
- Volltext (BM25) für präzise Keyword-Suchen
- Vektorindex (z. B. pgvector/Milvus) mit Mandantenfähigkeit und Verschlüsselung
- Optional: Graph-Beziehungen (z. B. Bauteil/Variante/Revision)
3) Modellschicht
- Retrieval-augmented Generation (RAG) statt blindem Modellwissen
- Retriever: Hybrid (BM25 + Vektor), Domain-Reranking (Cross-Encoder)
- LLM-Laufzeit: On-Prem Inferenz (z. B. vLLM/TensorRT-LLM), niedrige Latenzen, feste Kostenkontrolle
- Prompt-Orchestrierung: versionierte Templates, strukturierte Ausgaben (JSON-Schema), strikte Constraints
- Alternative/Nebenpfade:
- Klassische ML (Vision, Zeitreihen) für deterministische Subprobleme (Defekterkennung, Ausfallprognose)
- Adapter-/LoRA-Feintuning nur, wenn RAG nicht reicht und Daten wirklich vorliegen
4) Tooling/Agentik (kontrolliert)
- Funktionsaufrufe mit klaren Verträgen: idempotent, Side-Effect-Grenzen, Timeouts, Dry-Run-Modus
- Event-getriebene Integration (Kafka/NATS) statt ad-hoc-Skripte
- Policy-Layer: Welche Rolle darf welche Tools ausführen? Welche Parameter? Unter welchen Bedingungen?
5) Governance & Observability
- Tracing: Eingaben, abgerufene Kontexte, Modell-/Prompt-Version, Token-Nutzung
- Redaction: PII-/Geheimnis-Filter vor Persistenz von Traces
- Guardrails: Blacklists/Regex/Parser, Schema-Validatoren, Safety-Filter; Fallback-Strategien und Circuit-Breaker
- Evals: Gold-Datasets, Regressionstests, Szenarien (Knowledge-Groundedness, Halluzinationen, Tool-Fehler)
- Audit: Unveränderliche Logs, nachvollziehbare Entscheidungen, Freigabe-Workflows
6) Betrieb
- Paketierung: Container mit signierten Artefakten (SBOM, Lizenz-Prüfung)
- Deployment: Kubernetes on-prem, Network Policies, egress deny by default; Air-Gap-fähig
- SLOs: Antwortzeiten, Fehlerraten, Verfügbarkeiten; Burn-in-Phase mit Shadow Traffic
- Drift Detection: Daten-/Leistungsdrift, Re-Index-/Retrain-Cadence, Rollbacks (Canary)
Souveränität ist eine Architektureigenschaft
„On-Prem“ ist kein Dogma, sondern eine Funktion Ihrer Risiko- und Regulierungslandschaft. In vielen europäischen Industrien ist sie nicht verhandelbar. Konkrete Designentscheidungen:
- Modelldependenzen: Bevorzugen Sie Modelle, die on-prem lizenziert und betrieben werden dürfen. Prüfen Sie Lizenztexte auf Nutzungs- und Weitergaberechte. Halten Sie eine Modellregistry mit Freigabestati.
- Datenflusskontrolle: Zero-Trust im internen Netz; egress-Kontrollen per Namespace/Service; kein Implizit-Traffic zu Drittanbietern.
- Air-Gap-Strategien: Offline-Updates von Modellen/Embeddings; Artefakt-Signing; reproduzierbare Builds.
- Geheimnismanagement: HSM/Secrets-Vault; Rotationspläne; Trennung von Daten- und Steuerungsnetz.
Und: Souveränität muss auch für LLM-Agenten gelten. Ein Agent, der unkontrolliert Aufträge in ERP, PLM oder Ticketingsystemen ausführt, ist ein Risiko. Observability und Governance sind nicht „nice to have“, sie sind Betriebsvoraussetzung. Wir setzen in Projekten eine dedizierte Observability- und Governance-Schicht ein, die LLM-Interaktionen, Tool-Aufrufe, Policies und Freigaben nachvollziehbar macht – und zwar on-prem.
RAG richtig bauen: Ein industrielles Blueprint
Beispiel „Technische Dokumentation in der Fertigung“: