11) Schritt-für-Schritt-Vorgehen zum Start
- Woche 0–2: Zieldefinition und Metriken
- Welche Entscheidungen sollen unterstützt/automatisiert werden?
- Welche Latenzbudgets und Ausfallmodi sind akzeptabel?
- Baseline ohne KI: heutige Fehlerraten, Durchsatz, Bedieneraufwände.
- Woche 2–4: Datenzugang und Verträge
- CDC/ETL-Strecke definieren, Feature-Schema erstellen und versionieren.
- Inference-API als Vertrag festlegen, Mock-Service für frühe Integration.
- Woche 4–6: Minimum Viable Inference
- Inference Gateway als eigenständiger Dienst, Telemetrie eingebaut.
- Golden Datasets kuratieren, erste Offline-Evaluation gegen Baseline.
- Woche 6–8: Shadow Mode in Produktion
- Realverkehr, aber ohne Einfluss. Vergleiche, Drift, UI-Prototypen für Erklärungen.
- Woche 8–10: Hybridbetrieb und Canary
- Impact für Teilmenge aktivieren, Fallback-Policies scharf stellen, Alerting.
- Ab Woche 10: Betrieb, Iteration, Governance
- Regelmäßige Reviews, Re-Trainingsfenster, Modell-/Prompt-Versionierung, Security-Reviews, Audits.
Harte Entscheidungen und Trade-offs
- Präzision vs. Latenz: Nicht jedes Modell gehört in den Inline-Pfad. Für harte Echtzeit bleibt ML häufig nur beratend.
- Generalität vs. Wartbarkeit: Mehrere spezialisierte Modelle sind betrieblich günstiger als ein „Alleskönner“.
- Erklärbarkeit vs. Performance: In sicherheitskritischen Bereichen sind einfachere, erklärbare Modelle sinnvoll — oder zumindest muss die Erklärschicht robust sein.
- Edge vs. Zentrale: Rechenleistung am Rand spart Latenz, erhöht aber Wartungskomplexität. Faustregel: Nur das an den Rand, was wirklich Latenz-kritisch ist.
Souveränität als Designparameter
Wenn Daten das Betriebsgeheimnis sind, gehört die komplette KI-Wertschöpfungskette ins eigene Haus: Datenaufnahme, Feature-Build, Inferenz, Telemetrie, Governance. On-prem bedeutet nicht „Rückschritt“ — es bedeutet Kontrolle über Latenz, Sicherheit und Kosten. Mit einer sauberen Integrationsarchitektur sind moderne KI-Funktionen auch ohne Public Cloud praktikabel.
FAQ
Frage: Können LLMs praktikabel on-prem betrieben werden, ohne hyperskalige Cloud?
Antwort: Ja, sofern man Anwendungsfälle und Hardware passend wählt. Für RAG/Assistenz-Workflows reichen mittelgroße Modelle häufig aus, die auf Enterprise-GPUs oder starken CPUs laufen. Entscheidend sind ein schlanker Kontext (guter Retrieval-Index), deterministische Inferenz (strukturierte Ausgabe, konservative Sampling-Parameter) und eine Observability-/Governance-Schicht. Große Trainingsvorhaben sind on-prem selten sinnvoll; Inferenz und Feinabstimmung (LoRA/Adapter) dagegen schon.
Frage: Wie aktualisieren wir Modelle, ohne die Produktion zu stören?
Antwort: Modellversionen werden parallel bereitgestellt. Die Inference-API bleibt stabil; Routing entscheidet pro Anfrage (z. B. via Header/Policy), welches Modell antwortet. Golden-Set-Checks sind Gates in CI/CD. In Produktion erst Shadow, dann Canary. Caches sind versionsbewusst, und Rollbacks sind ein Einzeiler in der Routing-Policy. Telemetrie überwacht SLOs; bei Verstößen greift Auto-Rollback.
Frage: Was bedeutet KI-Integration für sicherheitskritische Zertifizierungen?
Antwort: Trennen Sie strikt zwischen sicherheitskritischem Kern und KI-Assistenz. Der Kern bleibt zertifiziert und deterministisch; KI läuft als nicht-sicherheitsrelevante Funktion mit definierten Grenzen und Fallback. Dokumentieren Sie Datenflüsse, Versionen, Policies und Testergebnisse. Für LLM-Agenten gilt: keine autonomen High-Impact-Aktionen ohne menschliche Freigabe. Audits verlangen Nachvollziehbarkeit — deshalb sind strukturierte Logs, Reproduzierbarkeit und Versionierung Pflicht.
Frage: Wie kalkuliere ich Hardware-Bedarf ohne Überprovisionierung?
Antwort: Starten Sie mit Latenzbudgets und Durchsatzprognosen pro Use Case. Messen Sie p50/p95 in Realverkehr (Shadow) und dimensionieren Sie auf p95 plus Sicherheitsaufschlag. Nutzen Sie Batch/Nearline für nicht-latenzkritische Anteile. Caches können den Bedarf stark senken, wenn Eingaben wiederkehren. Für GPU-Workloads: dedizierte Knoten und klare Scheduling-Policies; vermeiden Sie „GPU als Shared Playground“.
Frage: Was tun, wenn die Daten „schmutzig“ sind?
Antwort: Nicht warten, bis Daten „perfekt“ sind. Definieren Sie Feature-Verträge mit Validierungs- und Imputationsregeln. Führen Sie strenge Input-Validierung an der Inference-API ein (Range-, Typ- und Plausibilitätsprüfungen). Loggen Sie Verstöße und priorisieren Sie die größten Schmerzpunkte. Parallel dazu bauen Sie eine kuratierte Golden-Set-Pipeline auf. Nutzen Sie die Shadow-Phase, um Datenprobleme sichtbar zu machen, bevor Impact entsteht.
Fazit
Erfolgreiche KI-Integration in Bestandssoftware ist ein Architektur- und Betriebsprojekt — kein Modell-Showcase. Die Muster sind klar: Inferenz entkoppeln, Daten als Verträge behandeln, on-prem sauber betreiben, Migrationsleitern statt Big Bang, Qualität und Governance als First-Class-Citizens. Mit dieser Disziplin entstehen KI-Funktionen, die in rauen Industrieumgebungen bestehen — souverän, nachvollziehbar und wirtschaftlich.