Observability und Governance sind Pflicht
LLM‑Systeme sind dynamisch: Prompts, Wissensbasis und Modelle ändern sich. Ohne Observability fliegen Sie blind. Was in die Telemetrie gehört:

  • Prompt, Kontext, Modellversion, Antwort, Nutzung der Tools – jeweils mit Pseudonymisierung sensibler Inhalte

  • Metriken wie Antwortzeit, Tokenverbrauch, Abdeckungsgrad, Anteil „keine ausreichende Grundlage“

  • Policy‑Events: Blockierte Ausgaben, PII‑Maskierungen, Rollenkonflikte

  • Drift‑Signale im RAG: Ähnlichkeitsverteilungen, Top‑K‑Trefferqualität, Quellenvielfalt

Für genau diese Ebene setzen wir als Produkt eine Plattform für LLM‑Agent Observability & Governance ein, die on‑prem betrieben werden kann. Wichtig ist unabhängig vom Tool: Keine Telemetrie darf das Rechenzentrum verlassen; Audit‑Exports müssen revisionssicher und lokal bleiben; das Policy‑Enforcement darf nicht abschaltbar sein.

3) Ein 12‑Wochen‑Fahrplan zu Ergebnissen

Drei Monate sind im Mittelstand ein praxisgerechtes Zeitfenster, um von einer klar umrissenen Problemstellung zu messbaren Resultaten zu kommen. Der Schlüssel: harte Kill‑Kriterien, minimal tragfähige Architektur und frühe, geschützte Tests im realen Prozess.

Woche 1–2: Problem schärfen, Baseline bauen

  • Geschäftsmetrik fixieren: z. B. Reduktion der Falsch‑Ausschuss‑Rate, Einsparung an Prüfzeit, Senkung der Mean‑Time‑to‑Resolution im Service.

  • Scope begrenzen: Ein Werk, eine Linie, ein Dokumentkorpus, ein Eingangs‑kanal. Keine Querschnitts‑Initiative.

  • Daten‑Snapshot sichern: 2–4 Wochen repräsentative Daten einfrieren (Bilder, Sensorik, Doks, Tickets).

  • Baseline definieren: Wie gut ist die heutige Heuristik/Mensch mit gleichem Daten‑Snapshot? Ohne Baseline ist jeder KPI wertlos.

  • Kill‑Kriterien festlegen: z. B. Wenn bis Woche 6 nicht >X% Genauigkeit im Offline‑Test erreicht sind, wird abgebrochen oder der Scope geschnitten.

Woche 3–4: Datenpipeline und Minimal‑Modell

  • Datenzugang: Technische Anbindung an Kameras/Sensoren/DMS/Mail; nur Leserechte, Audit‑Logs aktiv.

  • Labeling & Ground Truth: 300–1000 Beispiele kuratieren; klare Definitions‑guides, Inter‑Annotator‑Agreement messen.

  • Erstes Modell: Für CV/Anomalie einfache, robuste Architekturen; für LLM ein RAG‑Skeleton mit lokalem Embedding und minimalem Vektorspeicher.

  • Offline‑Evaluierung: Gegen die Business‑Metrik testen. Fehlerarten kategorisieren (z. B. Verwechslung ähnlicher Defekte, fehlende Quelle im RAG, falsche Extraktion).

Woche 5–6: Technische Schulden klein halten, Guardrails bauen

  • CI/CD für Modelle: Versionierung, reproduzierbares Training; klare Promotion‑Stufen (Dev -> Test).

  • Inferenz‑Service on‑prem: Containerisiert, Health‑Checks, Observability (Latenz, Fehler, Data Drift).

  • Sicherheitsbegrenzungen: Kein Internetzugang der Inferenz‑Container; Secrets im Secret‑Store; Read‑only auf Datenquellen.

  • Für LLM: Policy‑Layer (PII‑Maskierung, Rollenprüfung), Tool‑Schnittstellen mit striktem Schema, RAG‑Evaluation mit Quellen‑Coverage.

Woche 7–8: „Shadow Mode“ im Prozess

  • Live‑Signale aus der Linie/eingehenden Anfragen, aber keine automatischen Entscheidungen. Ergebnisse werden mitgeloggt, Menschen entscheiden wie bisher.

  • Gegenüberstellung: Abweichungen zur Baseline dokumentieren; Ursachenanalyse.

  • Verbesserungen aus Feedback: Aktives Lernen – gezielt schwierige Beispiele labeln, Prompts/Tools nachschärfen, RAG‑Korpus kuratieren (Doppelungen, veraltete Dokumente, fehlerhafte OCR).

Woche 9–10: Enger Pilot mit begrenztem Risiko

  • Gatekeeper‑Tests bestehen: Definierte Testbatterie muss die minimalen Qualitätskriterien treffen.

  • Teil‑Automatisierung: Z. B. bei Klassifikation mit sehr hoher Konfidenz; Rest im „Human‑in‑the‑Loop“.

  • Betriebsvereinbarung/Datenschutz: Dokumentation der Datenflüsse, Aufbewahrungsfristen, Betroffenenrechte. Audit‑Mechanismen zeigen.

Woche 11–12: Stabilisierung, Abnahme, Entscheidung

  • Reporting: Gegenüberstellung Zielmetrik vs Baseline, Kosten (HW‑Nutzung, Personentage), offene Risiken.

  • Betriebsübergabe: Run‑Books, Monitoring‑Dashboards, Alarmierung, Backup/Restore, Patch‑Prozess.

  • Go/No‑Go/Iterate: Entweder skaliert werden (mehr Linien/Standorte/Dokumente), oder fokussierte Iteration – oder Stop, wenn Business‑Wert nicht da ist.

4) Typische Stolpersteine – und wie man sie vermeidet

  • Zu große Modelle, zu wenig Daten: Ein mittelgroßes Modell mit sauberem RAG und gutem Prompt schlägt in Unternehmensanwendungen oft die „größten“ Modelle. Investieren Sie zuerst in Datenqualität und Kontextaufbau.
  • Unklare Eigentümerschaft: Wer trägt das System im Betrieb? Ohne klaren Owner auf Fach- und IT‑Seite scheitert jedes Projekt in der Übergabe.
  • Fehlen von Observability: Ohne Telemetrie können Sie keine Ursachenanalysen machen. Sammeln Sie Metriken von Tag 1 – on‑prem, auditierbar.
  • „Einmaliges POC‑Skript“: Einzelne Notebooks sind Feinde von Reproduzierbarkeit. Container, Versionskontrolle, definierte Artefakte – auch im POC.
  • Kein Plan für Modellevolution: Daten und Anforderungen ändern sich. Planen Sie regelmäßige Re‑Trainings/Re‑Indexierungen und Regressionstests fest ein.

5) Organisation: Warum der Mittelstand oft schneller ist – wenn man es richtig aufstellt

Kleinere, gut abgestimmte Teams können in wenigen Wochen liefern. Voraussetzungen:

  • Ein cross‑funktionales Kernteam (4–6 Personen): Domänenexpertin, Data/ML‑Engineer, Software‑Engineer, IT‑Security, Product/Process Owner. Alle mit Entscheidungsbefugnissen für den Pilot.

  • Einfache Beschaffung: Vorab geklärte „Standard‑Baukästen“ für Hardware (On‑Prem Compute), Storage, Kameras/Sensoren und Lizenzen, damit Woche 1 nicht in Bestellprozessen versandet.

  • Governance als Enabler, nicht als Bremse: Klare, wiederverwendbare Datenschutz‑Bausteine (PIAs, TOMs, Datenflussdiagramme), die auf neue Projekte übertragbar sind.

  • Erfolgskriterien wirtschaftlich definieren: Nicht Modell‑Akuratesse um ihrer selbst willen, sondern Taktzeit, Ausschuss, MTTR, Automatisierungsquote.

6) Konkrete Architektur‑Entscheidungen mit Trade‑offs

On‑prem vs. Cloud

  • On‑prem Vorteile: Datenhoheit, geringe Latenz, keine externen Telemetrie‑Pflichten, planbare Kosten, Unabhängigkeit von Drittstaatenrecht.

  • On‑prem Herausforderungen: Kapazitätsplanung (GPU/CPU), Betriebsverantwortung, Patching. Lösung: Standardisieren Sie auf wenige, gut beobachtbare Knoten; kapseln Sie Modelle in klaren Services.

  • Cloud Vorteile: Elastizität, schneller Start. In vielen mittelständischen KI‑Szenarien überwiegen jedoch Souveränitätsargumente. Wenn Cloud, dann mit strengen Datenminimierungs‑ und Verschlüsselungsstrategien innerhalb des gewünschten Rechtsrahmens.

Offene vs. proprietäre Modelle

  • Offene Modelle: + Kontrollierbarkeit, On‑prem‑Betrieb, Anpassbarkeit; – mehr eigenes MLOps.

  • Proprietäre Modelle: + oft bequemere Out‑of‑the‑box‑Qualität; – Abhängigkeit, Datenflüsse schwerer kontrollierbar, Lizenzfragen. In sensiblen Domains ist „offen + on‑prem“ meist das robustere Fundament.