Governance und Audit: Wer hat was wann warum freigegeben?
Ohne Cloud brauchen Sie eine on-prem Governance-Schicht, die Artefakte, Entscheidungen und Änderungen nachvollziehbar macht.

  • Daten- und Modellabstammung:

  • Datasets mit Content-Hashes versionieren (z. B. mit DVC/Git LFS on-prem). Keine stillen Reuploads von „fast gleich“.

  • Trainingskonfigurationen, Seeds, Preprocessing als Code, nicht als Excel.

  • Modellkarten mit Risikoklassen, Betriebsgrenzen (OAT – Operational Acceptance Tests) und Testberichten.

  • Freigabe-Workflow:

  • Zwei-Personen-Regel für Produktionsfreigaben, differenziert nach Risiko (z. B. reine OEE-Optimierung vs. Qualitätsentscheidungen).

  • Shadow-Mode-Phase verpflichtend: Modell entscheidet, aber nur im Log – Gegenüberstellung mit goldenem Referenzsystem.

  • Entscheidungs-Audit:

  • Für jede produktive Entscheidung: Eingangsmetadaten, Modellversion, Konfiguration, Latenz, Konfidenz, Boundary-Flags. Kein Vollbild-Logging, nur gezielte Slices (Privacy, Speicherbudget).

  • Für LLM/Agenten: Prompt-, Kontext- und Output-Logs mit Redaktionsfilter, Rollen- und Berechtigungsbezug. Agenten-Tools nur innerhalb definierter Ressourcen-Scopes. (Hierfür setzen wir on-prem Governance/Lifecycle-Management ein; Details auf Anfrage → alpitype.de/leistungen/)

Observability ohne Internet: Metriken, Logs, Traces lokal
Telemetrie muss lokal sein, aber genauso zuverlässig wie in der Cloud:

  • Metriken:

  • p50/p95/p99-Latenzen je Pipeline-Stufe, Frame-Drop-Raten, Queue-Längen, GPU/CPU-Auslastung, Speicherdruck, Temperatur.

  • Drift-Indikatoren: Score-Verteilungen über Zeit, Konzept- und Daten-Drift-Proxy-Metriken.

  • Logs:

  • Strukturiert, mit stabilen Schlüsseln. Tagesrotation, lokale Retention mit Backpressure (niemals das Dateisystem volllaufen lassen).

  • Ereignis-IDs korreliert mit Artefakt-Hashes und Audit-Einträgen.

  • Tracing:

  • Leichtgewichtiges, stichprobenbasiertes Tracing für Latenzspitzen. Sampling adaptiv, damit unter Stress das System nicht kollabiert.

  • Infrastruktur:

  • On-prem Prometheus/Loki/Tempo oder vergleichbare Stacks. Zugriff über Bastion, keine Direktverbindungen von außen.

  • Zeit: Eine belastbare Zeitquelle in der OT (lokaler Time-Server, klare Strategie für Ausfall; monotone Uhren für Metriken).

Latenz- und Determinismus-Fallen, die Projekte aus der Kurve tragen
Erfahrungspunkte, die in der Praxis die meiste Zeit kosten:

  • Treiber-Drift:

  • Unterschiedliche Minor-Versionen von GPU-Treibern vs. Inferenz-Engines sorgen für inkonsistente Kernel-Auswahl. Lösung: zielgerichtete Kompatibilitätsmatrix, keine „Wildcard“-Deployments.

  • „Kleinkram“ in Summe:

  • 2 ms extra im Camera-Stack, 3 ms in der Farbkonvertierung, 4 ms im Preprocessing – schon ist das 16-ms-Fenster weg. Jedes Stück messen und budgetsieren.

  • Garbage Collection:

  • Python GC an der falschen Stelle und Ihr p99 springt auf 200 ms. Entweder kritische Pfade in C++ oder GC-Strategie explizit steuern, Objekte vorwärmen.

  • Speicherfragementierung:

  • Langlaufende Prozesse ohne Pre-Allocation fragmentieren GPU/Host-Speicher. Periodischer, koordinierter Warm-Restart des Inferenz-Containers ist oft pragmatischer als heldenhafte Optimierung.

  • Dateisystem-Überraschungen:

  • SSDs drosseln unter Hitze oder nach TBW-Auslastung. Telemetrie auf Verschleiß ausrichten, lokale Ringpuffer statt ungezügeltem Append.

Rollout-Strategien in abgeschotteten Werken: A/B geht selten, Shadow immer
Durchsatz und Sicherheitsüberlegungen lassen kein „echtes“ A/B zu. Funktionierende Muster:

  • Shadow-Mode:

  • Neues Modell läuft parallel, trifft Entscheidungen, aber nur ins Log. Bewertung gegen Prozess-Outcome und Altsystem, klare Akzeptanzkriterien vorab.

  • Canary nach Zellen:

  • Nicht nach Hosts, sondern nach Produktionszellen: erst die am wenigsten kritische Linie, dann hochrisikoreiche Stationen. Jede Stufe mit definierten Metrik-Gates und manueller Abnahme.

  • Feature-Gates:

  • Konfigurierbare Schalter für neue Heuristiken oder Schwellen. Ein Deployment kann damit risikolos getestet werden, ohne neues Bundle.

  • Hard Stop vs. Soft Degradation:

  • Im Fehlerfall: Entweder sauberer Bypass oder degradierter Betrieb (z. B. geringere Bildrate). Wischiwaschi führt zu schwankender Qualität.

Schnittstelle zur SPS: Schwarzer Kanal für KI, deterministische Schicht für Safety
KI bleibt immer nicht-sicherheitsgerichtet. Die Kopplung muss das respektieren:

  • Prinzip:

  • KI liefert Vorschlag + Konfidenz + Zustandsflags. Eine deterministische Schicht (regelbasiert, verifizierbar) übersetzt das in Aktionsvorschläge für die SPS.

  • Handshake:

  • Explizite Gültigkeitsfenster, Heartbeat, Sequence-IDs. Bei Ausfall oder Timeout schaltet die SPS auf definiertes Verhalten (z. B. manueller Prüfbahnhof).

  • Fehlerbilder testen:

  • Noise, Delay, Stotter-Frames, Ausfall des Kamera-Threads – alles in HIL-Tests simulieren. Nicht erst an der Linie.

LLM-Agenten in der OT: Egress-Kontrolle, Retrieval-Scope, Audit
Auch in abgeschotteten Werken tauchen LLM-Anwendungen auf (z. B. Störungsleitfäden, Schicht-Report-Assistenten). Die Risiken sind andere als bei CV:

  • Datenzugriff:

  • Retrieval strikt auf lokale, freigegebene Wissensbasen begrenzen. Kein „Herumstöbern“ in SMB-Shares – Tools der Agenten haben harte Scopes.

  • Egress-Null:

  • Standardmäßig kein Outbound. Selbst Telemetrie geht nur in lokale Stores. Modelle on-prem gehostet, keine US-Cloud-Abhängigkeit.

  • Prompt- und Tool-Audit:

  • Jede Agentenaktion protokollieren: Prompt, Kontext, verwendete Tools, Resultate, abgelehnte Aktionen. Redaktionsfilter für personenbezogene Daten.

  • Policies als Code:

  • Guardrails nicht in UI-Klickorgien, sondern als versioniertes Regelwerk. Änderungen laufen durch denselben Freigabeprozess wie Modell-Updates.

  • Governance:

  • Ein zentrales, on-prem Observability- und Policy-System für Agenten-Interaktionen beschleunigt Incident-Analysen dramatisch. Genau dafür setzen wir in Projekten eine lokale Governance-Plattform ein (→ alpitype.de/leistungen/).