• Use Case: Werkstatt-Ingenieure stellen Anfragen zu Bauteilen, Varianten, Drehmomenttabellen, Änderungsständen. Ziel: korrekte, auditierbare Antworten mit Quellverweis in <1,5 s.
  • Pipeline:

1) Intake: CAD-PDFs, Montageanleitungen, Änderungsmitteilungen; OCR/Layout-Parsing; semantisches Chunking mit Abschnitts-IDs
2) Embeddings: On-Prem Embedding-Modell (z. B. deutsch/technikorientiert), periodisches Re-Embedding bei Revisionswechsel
3) Index: Hybrid BM25 + Vektor; Felder: Teilnummer, Revision, Gültigkeitszeitraum, Sicherheitsfreigabe
4) Retrieval: Top-k hybrid + Cross-Encoder-Rerank; Filter nach Revision/Variante/Standort
5) LLM: On-Prem Inferenz; Prompt mit striktem Antwortschema und Quellenzitaten
6) Guardrails: Wenn Konfidenz/Abdeckung zu niedrig: keine Antwort, stattdessen verlinkte Dokumentstelle + Eskalation
7) Observability: Trace mit Quellen, Score, Antwortzeit, Prompt-/Model-Version; PII-Redaction

  • Betriebsanforderungen:
  • Latenzbudget Aufteilung: Retrieval 400 ms, Rerank 250 ms, LLM 600 ms, Rest 250 ms
  • Caching: Semantisches Cache für wiederkehrende Fragen; Warm-Cache pro Schichtstart
  • Schema-Validierung: JSON-Ausgabe mit Pflichtfeldern; Parser-Fallbacks

Feintuning vs. RAG vs. Klassisches ML: Wann was?

  • Starten Sie mit RAG, wenn Wissen primär in Text/Dokumenten steckt und sich ändert. Vorteile: schnelle Aktualisierbarkeit, geringere Datenanforderungen, bessere Auditierbarkeit (Quellen).

  • Feintuning (Adapter/LoRA), wenn das Modell in Ihrer Domänensprache besser parieren muss (z. B. spezifische Fehlermeldungen, enges Format). Voraussetzung: kuratierte, qualitativ hochwertige Trainingsdaten; klare Evaluierung. Achten Sie auf Lizenz und Reproduzierbarkeit.

  • Klassische ML, wenn Daten strukturiert und Ziel deterministisch ist: Vision-basierte Defekterkennung, Zeitreihen-Anomalien, Predictive Maintenance. Hier zählen robuste Datenpipelines, Feature-Stores, wiederholbare Trainingsläufe, statt Prompts.

Kosten- und Latenzdisziplin: harte Budgets statt Hoffnung

  • GPU-Planung: Kapazität in Token/s und Durchsätzen statt in „Anzahl User“. Batch- und Prefill/Decode-Optimierungen nutzen.

  • Quantisierung: 4/8-Bit (z. B. AWQ/GPTQ) für Latenz/Kostensenkung, wenn Qualitätsverlust tragbar ist.

  • Caching: Prompt- und KV-Cache; semantische Antwortcaches mit Gültigkeitsfenstern.

  • Fallback-Ökonomie: Für niedrige Kritikalität kleinere Modelle, für hohe Kritikalität robustere Pfade (oder Mensch-in-der-Schleife).

Security- und Compliance-first, nicht „später“

  • Policy Enforcement: zentraler Policy-Engine-Layer (z. B. OPA-ähnliche Prinzipien) für Toolzugriffe, Datenfilter, Ausführungsgrenzen.

  • Audit-Trails: Unveränderliche Logs (WORM), signierte Ereignisse, nachvollziehbare Freigaben.

  • Evaluierung als Gate: Kein produktiver Agent ohne dokumentierte Evals, Red-Teaming und Abnahmekriterien.

  • Lieferketten-Sicherheit: SBOM, signierte Container, reproduzierbare Builds, gesperrte Registries.

Konkrete Übergangs-Checkliste: POC → Produktion
Gate 0 – Problem

  • Geschäftsentscheidung, Metriken, Toleranzen, Risiken, Nichtziele

  • Baseline ohne KI und wirtschaftlicher Zielkorridor

Gate 1 – Daten

  • Datenprodukte, Verträge, Eigentümer

  • Lineage, Qualität, Zugriff, Zweckbindung

Gate 2 – Architektur

  • RAG/ML-Design, On-Prem-Deployments, Security-Zonen, Egress-Politik

  • Betriebskonzepte: SLOs, Observability, Runbooks

Gate 3 – Modell & Eval

  • Modellwahl, Lizenzen, Registry

  • Gold-Datasets, Evaluierungsmetriken, Red-Teaming, Akzeptanzschwellen

Gate 4 – Governance

  • Policy-Engine, Guardrails, HI/LOA (Human-in-/out-of-the-loop) je Risikostufe

  • Audit- und Freigabemechanismen

Gate 5 – Inbetriebnahme

  • Canary/Shadow-Phase, Monitoring/Alerting

  • Rollback-Strategie, Ownership im Betrieb, Iterationsplan

Was Sie weglassen sollten

  • POCs auf Public-LLM-APIs mit produktiven Daten, wenn Souveränität/DSGVO relevant ist

  • Unstrukturierte Dokumentenindizes ohne Metadaten/Versionen

  • Agenten mit Write-Berechtigung in Produktivsysteme ohne Policy-/Approval-Layer

  • „Wir messen später“ – ohne Evals/Tracing sind Sie blind

Die Rolle von Observability & Governance
LLMs sind probabilistische Systeme. In regulierten Domänen brauchen Sie:

  • Vollständige Nachvollziehbarkeit: Warum kam diese Antwort zustande? Welche Quellen? Welche Prompt-/Modellversion?

  • Steuerbarkeit: Wer darf was ausführen? Unter welchen Bedingungen? Mit welcher Freigabe?

  • Schutzmechanismen: Redaction, Output-Validierung, Fallbacks, Circuit-Breaker

  • Kontinuierliche Qualitätssicherung: Regressionsevaluierungen bei jedem Modell-/Prompt-Update

In unseren Projekten setzen wir dafür eine dedizierte Plattformschicht ein, die LLM-Interaktionen sichtbar macht, Richtlinien durchsetzt und auf Premises betrieben wird. Ohne diese Schicht ist Produktion eine Wette.

Starten – aber richtig

  • Woche 1-2: Use-Case-Selektion mit klaren Metriken und Nichtzielen; Systeminventar; Datenprodukt-Definition

  • Woche 3-4: Minimaler RAG- oder ML-Prototyp auf produktionsnaher Architektur (on-prem), mit Observability von Tag 1

  • Woche 5-6: Evaluierung auf Gold-Set, Guardrails, Policy-Layer; Kosten-/Latenz-Budgets schließen

  • Woche 7+: Canary, Shadow, harte Gates; danach inkrementelle Ausweitung auf weitere Domänen

Mein Fazit
KI kennt Ihr Business nicht. Ihre Daten, Ihre Prozesse, Ihre Risiken definieren die Architektur – nicht das Modell-Du-jour. Wer Souveränität, Datenprodukte, Governance und Betrieb von Anfang an ernst nimmt, bringt KI in Produktion – sicher, auditierbar, wirtschaftlich. Souveränität ermöglicht Intelligenz.

FAQ

1) Brauche ich wirklich On-Prem? Oder reicht eine EU-Cloud?

  • Es hängt von Datenklassifizierung, Vertragslage und Risikoappetit ab. Wenn Sie streng regulierte oder verteidigungsnahe Daten verarbeiten, ist On-Prem meist gesetzt. In weniger kritischen Szenarien kann eine EU-Cloud funktionieren – aber nur mit egress-Kontrolle, klaren Datenflüssen und ohne Abhängigkeit von US-LLM-APIs, wenn Datenbindung/Souveränität das erfordert.

2) Welche Modelle machen on-prem Sinn für deutsch/technische Domänen?

  • Für Retrieval-lastige Anwendungsfälle: solide Mid-Size-Modelle mit starkem Deutsch-Support und guter Inferenz-Performance auf Ihrer Hardware, kombiniert mit hochwertigem Retriever/Reranker. Für Embeddings: domänentaugliche Modelle, die on-prem lizenziert sind. Fokus weniger auf Modelgröße, mehr auf Kontexte, RAG-Qualität, Reranking und Guardrails.

3) Wann sollte ich feintunen statt „nur“ RAG zu bauen?

  • Feintuning lohnt sich, wenn (a) ein enges, wiederkehrendes Aufgabenformat mit klaren Qualitätsmetriken vorliegt, (b) ausreichend kuratierte Trainingsdaten verfügbar sind und (c) die Betriebslast Feintuning- und Re-Deploy-Zyklen trägt. Starten Sie mit RAG; feintunen Sie gezielt für Lücken (z. B. sehr spezielle Fehlermeldungen oder streng formatierte Ausgaben).