2) Event‑Streaming als Rückgrat

  • Ereignisgesteuerte Architektur mit genau definierten Zustandsübergängen. In sicherheitskritischen Teilen eher „at‑least‑once + Idempotenz“ statt „exactly‑once‑Magie“.

  • Backpressure‑Kontrolle und Flussgrenzen festlegen: Queuelängen, Retries, Dead‑Letter‑Queues, manuelle Interventionspfade.

  • Zeit als Erstbürger: Korrekte Zeitstempelung, Clock‑Drift‑Umgang, Replays für Forensik.

3) On‑Prem KI‑Stack (ML/LLM) ohne Abhängigkeit von externen Clouds

  • Datenhaltung: Versioniertes, lokal betreibbares Storage mit unveränderlichen Artefakten für Rohdaten, Features, Modelle und Evaluationsläufe.

  • Training/Feintuning: Lokale Rechencluster oder Workstations mit reproduzierbaren Umgebungen, deterministischen Seeds, konfigurierbaren Mixed‑Precision‑Pfaden.

  • Inferenz: Containerisierte, ressourcenkontrollierte Dienste mit definierten SLAs, lokalem Caching, Degradationsmodi und Request‑Budgetierung.

  • Retrieval‑Komponente: Eigene, on‑premise Vektorindizes und Dokumenten‑Pipelines, inklusive PII‑Filter, Klassifizierung und Lebenszyklusregeln.

  • Policy‑Ebene: Prompt‑ und Tool‑Policies als Code, signiert, versioniert, mit Freigabeworkflow.

4) Observability und Governance für KI/LLM

  • Vollständiges Telemetrie‑Schema: Prompt, Kontext, Tool‑Aufrufe, Modelle, Latenzen, Scores, Abweichung zur Goldreferenz, Policy‑Verletzungen – alles als Events.

  • Offline‑Evaluation: Shadow‑Runs, Vergleich alter/neuer Modelle/Policies an fixen Datensätzen, statistische Auswertung vor Rollout.

  • Richtlinienkontrolle: Automatisierte Guards (PII‑Schutz, Ausleitverbote, Tool‑Nutzung), Auditable Decisions, Rollback‑Pläne.

  • Plattformansatz: Genau hier setzen wir mit Alpi‑M an – Observability und Governance für LLM‑Agenten on‑premise, mit Datenhoheit. Wichtig ist: Die Plattform integriert in Ihr Event‑Schema und Ihre Freigabeketten, nicht umgekehrt.

5) Teststrategie und Quality Gates

  • Mehrschichtig testen:

  • Unit/Property‑Tests für deterministischen Code.

  • Vertrags‑Tests für Schnittstellen.

  • Szenario‑Tests mit synthetischen und realen Daten (inkl. Edge‑Cases).

  • Metamorphe Tests für ML (Invarianten trotz Transformationen).

  • Golden‑Baselines für LLM‑Ausgaben mit Toleranzen und Policy‑Checks.

  • Daten- und Modellvalidierung als Pipeline‑Schritte: Kein Modell ohne dokumentierten Evaluationsbericht in Produktion.

  • Metriken definieren, die der Betrieb versteht: Fehlerraten pro Szenario, Latenz‑SLOs, Datenvollständigkeit, Drift‑Indikatoren.

6) Air‑Gapped CI/CD und Betrieb

  • Artefakt‑Mirrors und interne Registries: Keine Builds aus dem Internet. Signierte Abhängigkeiten, reproduzierbare Builds, SBOM‑Prüfung.

  • Staging‑Ringe: Dev → Test → Vorproduktion → Produktion, mit formalen Freigaben und automatisierten, nachvollziehbaren Promotions.

  • GitOps für reproduzierbare Deployments: Konfiguration als Code, Rollback‑Fähigkeit, deklaratives Desired State Management.

  • Disaster Recovery und Forensik: Getrennte, unveränderliche Backups, Wiederherstellungstests, detaillierte Audit‑Logs.

Ökonomie und Risiko realistisch bewerten

„Buy ist billiger“ stimmt nur, wenn Integrations-, Governance- und Lebenszykluskosten ignoriert werden. Eigenentwicklung lohnt sich, wenn Sie die ökonomischen Hebel explizit machen.

  • TCO statt Lizenzkosten: Rechnen Sie Integrationsaufwand, Betrieb, Auditkosten, Rezertifizierungen, Schulungen, Ausfallkosten, EOL‑Migrationen ein.
  • Änderungskostenkurve: Je stärker Ihr Umfeld Änderungen kontrollieren muss, desto teurer werden Vendor‑Updates. Eigenentwicklung erlaubt, Änderungen zu bündeln und qualifiziert freizugeben.
  • Risiken bündeln: Bauen Sie nur das, was Sie differenziert – Domänenlogik, Integrationsadapter, Governance. Nutzen Sie bewährte Open‑Source‑Bausteine und kommerzielle Komponenten dort, wo sie substituierbar sind (z. B. OS, Container‑Runtime, generische Observability).
  • Exit‑Szenarien vor Einkauf definieren: Für jede zugekaufte Komponente ein dokumentierter Migrationspfad (Datenexport, API‑Äquivalenzen, Doppelbetrieb).

Fallvignetten (anonymisiert, Muster aus der Praxis)

Vignette 1: Visuelle Qualitätssicherung in der Fertigung
Ausgangslage: Ein Standard‑Vision‑System versprach „Plug‑and‑Play“. In der Linie stiegen Falsch‑Positiv‑Raten unter variierendem Licht stark an, Updates konnten nur online eingespielt werden, Latenz peakte zu Schichtwechseln.
Ansatz: Eigenes Inferenz‑Gateway nahe am Band, deterministische Pipeline mit fester Pre‑/Post‑Processing‑Zeit, lokales Modell‑Repository und Golden‑Set‑Evaluationsvorstufe. Backpressure‑Pfad mit Puffer und Degradationsmodus (visuelle Flagge, manuelle Inspektion). Ergebnis: Stabiler Durchsatz, auditierbare Änderungen, kontrollierter Offline‑Betrieb.

Vignette 2: Flottenintelligenz im Bahn‑Umfeld
Ausgangslage: SaaS‑Telemetrie‑Plattform kollidierte mit Datenhoheit, Update‑Zyklen unplanbar, KPI‑Reports nicht nachvollziehbar.
Ansatz: On‑prem Streaming‑Backbone, Edge‑Collector mit sicherem Puffer, Feature‑Berechnung als versionierte Jobs, einheitliches Schema, domänenspezifische Metriken. KI‑Modelle als ersetzbare Artefakte, Auswertungen reproduzierbar. Ergebnis: Verkürzte Diagnosezyklen, transparente KPI‑Ketten, Unabhängigkeit von Cloud‑Policy‑Änderungen.

Vignette 3: Wissensarbeit in abgeschotteten Netzen (LLM)
Ausgangslage: Bedarf an Dokumentenauswertung, aber keine externen LLM‑APIs erlaubt, strikte Audit‑Anforderungen.
Ansatz: On‑prem LLM‑Inferenz, Retrieval über lokale Indizes, strenge Policy‑Layer (kein Datenabfluss), vollständiges Prompt/Response‑Logging, Offline‑Evaluationssuiten für Policies. Ergebnis: Produktive Nutzung ohne Souveränitätsverlust, nachvollziehbare Entscheidungen.

Technische Ownership: Der unterschätzte Erfolgsfaktor

Eigenentwicklung scheitert nicht an Technik, sondern an unklarem Eigentum. Technische Ownership heißt:

  • Architekturentscheidungen sind dokumentiert, begründet und versioniert. Es gibt einen Ort und eine Person, die „Nein“ sagen darf.

  • Das Informationsmodell ist „owned“: Änderungen gehen durch ein Gremium mit Domänen‑ und QA‑Kompetenz.

  • Es gibt klare Eigentümer für Schnittstellen, Datenverträge, Pipelines, Betriebsprozesse und Incident‑Pfad. SLAs und Fehlerbudgets sind definiert.

  • Build‑Pipelines, Signaturen, Schlüsselmaterial, Registries – alles unter Ihrer Kontrolle. Keine kritische Abhängigkeit von externen Konten.

  • Änderungen folgen einem formalen Change‑Prozess mit Risikoabschätzung, Testnachweisen und Freigabe.

Eine kompakte Checkliste