• Daten dürfen Ihr Netz nicht verlassen oder müssen strikt segmentiert werden.
  • Es existieren Safety-/Zertifizierungsanforderungen mit Nachweispflichten.
  • Sie benötigen deterministische Builds/Deployments und auditierbare Modellpfade.
  • Lebensdauer > 5–10 Jahre mit planbaren Updates.
  • Edge-/Offline-Betrieb ist Kernanforderung.
  • Agenten/Modelle greifen auf produktionskritische Aktionen zu.
  • Sie können den Lieferanten nicht rechtlich/technisch zu Ihren Policies zwingen (Residency, Release-Kadenz, SBOM).

14. Wie man Build-Projekte gegen die üblichen Risiken absichert

  • Scope-Disziplin: Domänenschnitt klären, MVP entlang kritischer Pfade, klare „Non-Goals“.
  • Non-Functional-First: SLOs, Latenz, Offline-Verhalten, Security-Policies als Akzeptanzkriterien definieren.
  • Iterative Integration: Shadow/Canary obligatorisch, Feature-Flags, progressive Rollouts.
  • Governance früh verankern: SBOM, Signaturen, Auditlog, Repro-Builds ab Sprint 1.
  • Vertragsgestaltung: Abnahmen an nachweisbare NFRs knüpfen (z. B. reproduzierbarer Build in X Stunden, Recovery in Y Minuten), nicht nur Feature-Listen.
  • Wissenssicherung: Architekturdokumentation als Code, Runbooks, Übungen für Desaster-Recovery und Key-Rotation.

Schlussgedanke

In industriellen und sicherheitskritischen Umgebungen ist Build keine Romantisierung der Eigenentwicklung, sondern eine Konsequenz aus Anforderungen. Ohne Souveränität über Daten, Modelle und Betrieb bleibt KI entweder ein Spielzeug oder ein Risiko. Mit Souveränität wird sie ein belastbarer Teil Ihrer Wertschöpfung – und erst dann lohnt sich der Aufwand.

FAQ

Frage: Können wir nicht „Buy“ starten und später zu „Build“ wechseln?
Antwort: Ja, wenn Sie von Anfang an entkoppeln: eigene Datenhaltung, abstrahierte Schnittstellen, Evaluationsharness on-prem und ein Strangler-Migrationspfad. Ohne diese Vorkehrungen eskalieren Exit-Kosten schnell.

Frage: On-prem klingt teuer. Lohnt sich das wirklich?
Antwort: Rechnen Sie Gesamtbetriebskosten über die geplante Lebensdauer inklusive Freigabeprozessen, Ausfallrisiken, Exit-Kosten und Sicherheitsanforderungen. In regulierten Kontexten überwiegen planbare, interne Aufwände häufig die externen Volatilitäten von SaaS.

Frage: Wie behalten wir Austauschbarkeit bei, wenn wir selbst bauen?
Antwort: Durch Ports-and-Adapters, klare Domänenschnittstellen, Version Pinning und konsequente Nutzung offener Protokolle. Behandeln Sie jede externe Komponente als ersetzbar, und testen Sie den Tausch in CI/CD.

Frage: Wie testen wir ML/LLM-Systeme „sicherheitskritisch“?
Antwort: Klassische Unit-/Integrationstests ergänzen durch metamorphe Tests, OOD-/Drift-Erkennung, Golden-Set-Evaluation und Shadow/Canary-Deployments. Kritische Pfade brauchen Fail-Closed, Fallbacks und reproduzierbare Trainings-/Inferenzpipelines.

Frage: Müssen wir alles selbst entwickeln?
Antwort: Nein. Bauen Sie die Domänenschnittstellen, Governance und den Betrieb. Kaufen oder nutzen Sie austauschbare Komponenten (Vektorstore, Serving, Orchestrierung), aber behalten Sie Kontrolle über Code, Modelle, Datenflüsse und Deployments.