2) Lineage, Katalog, Zugriff

  • Data Catalog: OpenMetadata/Amundsen o. ä. zur Durchgängigkeit von Quelle → Feature-Code → Modell → Service. Pflicht für Auditierung unter AI Act: technische Dokumentation, Logging, Nachvollziehbarkeit.

  • Zugriff: ABAC/RBAC politisch sauber (OPA/Gatekeeper), Protokollierung jeder Abfrage. Pseudonymisierung/Anonymisierung, wo möglich. Dies ist kein “nice to have” – es ist Ihr Verteidigungsring bei Audits und Security Incidents (ENISA: Threat Landscape AI).

3) Datenräume und Interoperabilität

  • Industrie-Datenräume (Gaia-X/Catena-X) sind kein Selbstzweck. Technisch entscheidend sind Interoperabilität (IDS-Konnektoren, EDC), Nutzungsrechte und Durchsetzung (Usage Control). Der Data Act stärkt Ihre Position – nutzen Sie sie, bevor Sie Lieferanten-Schnittstellen bauen, die Sie in zwei Jahren bereuen.

4) Privacy- und Compliance-by-Design

  • Klassifizieren Sie Daten früh (personenbezogen, geschäftskritisch, exportkontrolliert). Legen Sie Transformationspfade fest (Masking, Tokenization, Differential Privacy – falls nötig).

  • Entscheiden Sie pro Use Case, wo Daten bleiben: Edge, Fabrik, Rechenzentrum, souveräne Cloud. Dokumentieren Sie die Risikoabwägung (NIST AI RMF: Govern/Map). Das ist später Ihr Nachweis.

Teil 3: Souveräne KI – Architekturprinzipien für Europa

“Souveränität ermöglicht Intelligenz” ist keine Parole. Es ist ein Architekturprinzip:

  • Datenlokalität zuerst: Rohdaten verlassen die Control Boundary nicht. Modelle kommen zu den Daten, nicht umgekehrt.
  • Offene, portierbare Modelle: Präferieren Sie Modelle, die on-prem laufen (z. B. Mistral-, Llama-Familie). Für proprietäre GPAI nur, wenn Datenklassen, Verträge und Technik (z. B. Tenant-Isolation, Customer-Managed Keys, EU-Region, dedizierte Inferenz-Cluster) die Risiken tragbar machen.
  • Retrieval-augmented statt blind-generativ: RAG mit lokalem Vektorindex (FAISS, HNSW, pgvector). Unternehmenswissen bleibt intern, Quellen werden zitiert (Context Attribution), um die Nachvollziehbarkeit zu sichern.
  • Auditability-by-default: Jede Inferenz ist ein Ereignis erster Klasse: Prompt, Kontext, Tool-Calls, Antwort, Policy-Entscheid, Metriken. Loggen Sie strukturiert (OpenTelemetry-Spans für LLM/Agenten). AI Act verlangt Logging; Observability spart Ihnen später Millionen.
  • Supply-Chain-Härtung: SBOMs für Modelle/Container, signierte Artefakte (Cosign), isolierte Build-Pipelines, reproduzierbare Trainings-Runs. ENISA warnt explizit vor Supply-Chain-Angriffen in KI.

Konkrete On-Prem-Topologie (bewährt in Industrieprojekten):

  • Netzwerkzonen: Inferenz-Cluster (K8s + GPU Operator) in einer streng segmentierten Zone, getrennt von Trainings-Workloads. Zugriff via API-Gateway mit mTLS. Keine ausgehenden Verbindungen ohne explizite Egress-Policies.

  • Geheimnisse/Schlüssel: HSM/TPM-gestützt, Customer-Managed Keys, strikte Rotation. Zugriff über kurzlebige Token (SPIFFE/SPIRE).

  • Artefaktverwaltung: Interne Registries (Harbor), Model Registry (MLflow/clearML) mit Signaturen. Keine Pulls aus dem Internet.

  • Observability: Metriken (Prometheus), Traces (OpenTelemetry), Events (Audit-Log, WORM-Storage). LLM/Agenten-Traces sind Pflicht, nicht Kür.

Teil 4: Von POC zu Produktion – warum der Übergang so schwer ist und wie er gelingt

Die Härte liegt nicht im Training, sondern in der Operationalisierung. Ein belastbarer Pfad hat vier Phasen:

Phase A: Problem und Baselines

  • Geschäftsprozess zerlegen: Wo exactly entsteht Wertverlust? Beispiel Fertigung: Fehlklassifizierte Bauteile → Nacharbeit → Overtime.

  • Akzeptanzkriterien definieren: “Senke die False-Reject-Rate um 30% bei gleichbleibender False-Accept-Rate < 0,5%.” Ohne diesen Satz wird es beliebig.

  • Baselines erheben: Heuristiken, regelbasierte Systeme als Null-Linie. Häufig schlagen sie fancy Modelle im TCO – und das ist ein gutes Ergebnis.

Phase B: Daten- und Modell-Architektur

  • Feature-Pipelines produktionsnah bauen: Dieselben Transformationsschritte in Training und Inferenz (Feature Parity). Keine Notebook-only-Logik.

  • Evaluationsharness aufsetzen: Offline-Tests mit festen Testsets, Stresstests (Out-of-Distribution), Metamorphe Tests (z. B. Einheitenwechsel, Rauschen).

  • Guardrails definieren: Eingabefilter (Schema, PII-Blocker), Ausgabefilter (Safety-Klassifikatoren), Policies für Tool-Aufrufe und externe Aktionen.

Phase C: Integrierter Betrieb (Shadow → Canary → Rollout)

  • Shadow-Mode: Modell entscheidet parallel zum Menschen/System, ohne zu wirken. Messen, nicht hypen.

  • Canary: 1–5% des Traffics, klare Abort-Kriterien, automatische Rollback-Mechanismen. Logging auf Vollgas.

  • Rollout: SLOs etablieren (Latenz, Throughput, Genauigkeit), Wochenberichte an Business Owner. Ab hier beginnt ROI-Realität.

Phase D: Nachhaltigkeit (Drift, Kosten, Änderungen)

  • Drift-Detektion: Data Drift (PSI, KS-Test), Concept Drift (Konfidenz, Performance-Metriken), Prompt/Tool-Drift bei Agenten. Alarmierung ab Schwellwerten, Retraining-Backlog mit Priorisierung.

  • Kostensteuerung: Batching, KV-Caches, Quantisierung (INT8/FP8), LoRA/Adapter statt Voll-Fine-Tuning, Offline-Reranking. Modell-Wahl ist eine Kostenfrage – täglich.

  • Change Management: Jede Modelländerung ist ein Release mit Version, Dokumentation, Evaluationsreport. AI Act verlangt Nachvollziehbarkeit; NIST RMF nennt “Measure/Manage” – machen Sie es zur Routine.

Spezialfall LLM-Agenten in der Industrie
Der Sprung von “LLM als Helferlein” zu “LLM-Agent an produktiven Schnittstellen” ist technisch und regulatorisch ein Weltenwechsel:

  • Unvorhersehbarkeit: Tool-Chains und Pläne variieren. Ohne strukturierte Traces (z. B. OpenTelemetry-Semantik für LLM/Tool-Aufrufe) lässt sich Verhalten nicht auditieren.

  • Sicherheitsfläche: Prompt Injection, Jailbreaks, Datenexfiltration, Halluzinationen mit realen API-Effekten. ENISA listet genau diese Angriffe.

  • Governance: Policies-as-Code (z. B. OPA) erzwingen, was ein Agent darf: “Darf nie Bestellungen auslösen > 5.000 €”, “Darf nur in Testsystemen schreiben, bis SLA X erfüllt.”

  • Evaluierung: Neben klassischen Benchmarks braucht es szenariobasierte E2E-Tests mit simulierten Gegenparteien, Red-Teaming und Ablaufanalysen. Log-Pflicht für AI Act-konforme Dokumentation.

Ein On-Prem-Governance-Stack für Agenten enthält mindestens:

  • Tracing/Observability für LLM/Agenten (Prompts, Kontext, Tool-Calls, Antworten, Policies, Scores)

  • Evaluations-Workflows (Regressionstests, Sicherheits- und Qualitäts-Batterien)

  • Policy-Enforcement in der Pipeline (vor Ausführung externer Aktionen)

  • Daten- und Modell-Katalog mit Lineage

  • Rollen- und Rechteverwaltung mit lückenlosem Audit-Log

Teil 5: Architektur-Trade-offs, die man nicht outsourcen kann