Phase 3: Skalierung und Produktlinienfähigkeit

  • Bausteine extrahieren: Auth, Telemetrie, ETL, RAG, Inferenz-Gateway, Policy-Gateway.

  • Betriebsdokumentation, Runbooks, SRE-Praktiken, Übungs-Drills (Restore, Rollback).

  • Kosten- und Kapazitätsplanung: GPU/CPU-Zuteilung, Scheduling, Batch- vs. Streaming-Pfade.

Was das für Teams bedeutet: Technical Ownership oder scheitern

Ohne technisches Eigentum an Architektur, Code und Betrieb geben Sie de facto Steuerung und Haftung an Dritte ab – während Sie die Verantwortung behalten. Technical Ownership heißt nicht „alles selbst machen“, sondern:

  • Eine klare, dokumentierte Architektur- und Entscheidungsautorität.

  • Ein Team, das Artefaktketten versteht und reproduzieren kann.

  • Eine Toolchain, die Souveränität, Sicherheit und Auditierbarkeit durchsetzt – automatisch.

Wenn Sie LLM-Agenten produktiv einsetzen, ist Observability und Governance keine Option, sondern Sicherheitsgurt. Jeder Tool-Aufruf, jedes Retrieval, jede Antwort gehört unter Aufsicht – mit Policies, die Fehlverhalten verhindern, bevor es teuer wird.

Fazit

Build vs. Buy ist im industriellen Kontext vor allem eine Frage des Betriebsmodells. Wenn Datenhoheit, deterministische Latenz, Offline-Fähigkeit und tiefe Integration geschäftskritisch sind, kaufen Sie mit SaaS ein Fremdbetriebsmodell, das Ihre Randbedingungen verletzt. Dann ist individuelle Entwicklung nicht Luxus, sondern Risikominimierung.

Die gute Nachricht: Mit einer wiederverwendbaren Architektur, klarer Technical Ownership und Governance-by-Design wird Build kalkulierbar. Nutzen Sie Standardbausteine dort, wo sie robust sind, kapseln Sie Ihre Domänenlogik, und bauen Sie die Observability so, dass jede Entscheidung reproduzierbar bleibt. Das ist der Unterschied zwischen einem Showcase und einem System, das Ihren Betrieb trägt.

FAQ

1) Wie erkenne ich früh, dass ein SaaS-Produkt unsere Souveränitätsanforderungen verletzt?

  • Prüfen Sie, ob irgendeine Form von Telemetrie oder Control-Plane-Verkehr das Netz verlässt. Fordern Sie eine vollständige Datenflussbeschreibung, inklusive Metadaten und Update-Pfade. Wenn der Anbieter das nicht liefern kann oder will, ist das ein klares Signal gegen den Einsatz.

2) Ist „on-prem“ immer teurer als SaaS?

  • Nicht zwingend. Die Kosten verschieben sich: weniger Lizenz- und mehr Betriebs-/Engineering-Aufwand. In regulierten Umgebungen fallen bei SaaS oft Zusatzaufwände für Workarounds, Audits und Integrationsbrücken an. Rechnen Sie Total Cost of Ownership über den vollen Lebenszyklus, inklusive Risiken durch Downtime, fehlende Auditierbarkeit und Vendor-Abhängigkeiten.

3) Wie gehe ich mit Legacy-Systemen um, ohne den Betrieb zu stören?

  • Strangler-Fig-Pattern: Ziehen Sie die Schnittstellen vertraglich nach außen, kapseln Sie Legacy über Adapter, führen Sie neue Komponenten parallel ein und verschieben Sie Traffic schrittweise. Backwards-kompatible Schnittstellen, Contract-Tests und Canary-Verfahren sind Pflicht.

4) Welche Mindestanforderungen sollte eine on-prem LLM-Architektur erfüllen?

  • Vollständige Daten- und Artefaktkontrolle: lokaler Vektorindex, dokumentierte RAG-Pipeline, versionierte Prompts. Policy-Gateway vor jedem Modell-Endpoint, Observability auf Agentenebene (Tool-Use, Kontext, Antworten). Reproduzierbarkeit durch Hashes und signierte Artefakte sowie klare Freigabeprozesse für risikobehaftete Aktionen.

5) Wie verhindere ich, dass ein Build-Projekt aus dem Ruder läuft?

  • Enge, messbare Inkremente statt Big-Bang. SLOs und Abort-Kriterien definieren. Technische Ownership mit Entscheidungsmandat etablieren. Standardisierte Tooling-Bausteine (CI/CD, Observability, Policy-as-Code) früh fixieren. Und: Entscheidungen dokumentieren (ADRs), damit das Team auch in zwölf Monaten noch versteht, warum es so ist, wie es ist.