• Laufzeit/Container: Kubernetes-Distribution mit Hardening, für Edge auch K3s/MicroK8s; distroless-Container.
  • Artefakte: Self-hosted Git, Container-Registry, Artifact-Repository; signierte Builds (z. B. Cosign), SBOMs.
  • Datenebene: Postgres, Timeseries (z. B. TimescaleDB), MinIO für Objektspeicher on-prem.
  • Messaging/Streaming: Kafka/Redpanda/NATS, je nach Latenz- und Persistenzbedarf.
  • Observability: Prometheus/Grafana, OpenTelemetry, lokales Log-Management.
  • Identity/Security: Eigene PKI, Secret-Management, HSM wo nötig, Policies als Code.
  • ML/AI: ONNX Runtime, lokale Inferenzserver; eigene Eval/Red-Teaming-Harnesses; Feature- und Model-Registries on-prem.
  • UI/Client: Für Industrie HMIs robuste Cross-Plattform-Stacks (z. B. C++/Qt) oder Web mit kontrolliertem Runtime-Footprint.

Trade-offs offen ansprechen

  • Geschwindigkeit vs. Sorgfalt: Ein minimaler, aber regulatorisch tragfähiger Inkrement-Ansatz schlägt große Würfe. Schneiden Sie das Problem so, dass Sie in 8–12 Wochen reale Wertschöpfung im echten Betrieb zeigen – ohne Architekturprinzipien zu kompromittieren.
  • GPU-Hunger vs. Betriebssimpelheit: Lieber ein kleineres, gut kontrollierbares Modell on-prem als ein großes, kaum auditierbares in der Cloud. Optimierung (Quantisierung, Distillation) schlägt Rohleistung.
  • Standardisierung vs. Flexibilität: Standardisieren Sie die Betriebsplattform, nicht die Fachlogik. Heterogene Workflows brauchen Flex in der Anwendung, nicht in der Infrastruktur.

Fazit

„Souveränität ermöglicht Intelligenz“ ist kein Slogan, sondern eine harte technische Notwendigkeit in Defense, Fertigung, Bahn, Aviation und Co. Ohne Kontrolle über Daten, Modelle und Betrieb bleibt jede „KI“ ein Risiko mit kurzer Halbwertszeit. Build ist dort die solide Wahl – wenn Sie:

  • das Problem zuerst präzise schneiden,

  • Technical Ownership klar verankern,

  • souveräne Architekturpatterns anwenden,

  • Betrieb und Auditierbarkeit von Beginn an mitbauen,

  • und nur die Bauteile einkaufen, die Ihr Differenzierungskern nicht selbst erfinden muss.

So wird individuelle Entwicklung nicht zum Großprojekt, sondern zur belastbaren Plattform für langlebige, regulatorisch tragfähige Innovation.

FAQ

Wie starte ich, wenn mein Fachbereich bereits ein Cloud-Tool pilotiert?

  • Bewahren Sie die Lernergebnisse, aber wiederholen Sie die Evaluierung entlang Souveränität, Betrieb und Integration. Wenn der Pilot nicht deploybar ist, schneiden Sie ein kleines, on-prem-fähiges Inkrement zu und liefern Sie in der Realität – nicht in der Sandbox.

Ist Build immer teurer als Buy?

  • Kurzfristig oft ja, mittel- bis langfristig nicht zwingend. Rechnen Sie TCO inklusive Integrations-, Audit-, Betriebs- und Exit-Kosten. In regulierten Umgebungen gleichen sich die Mehrkosten häufig aus oder kippen zugunsten von Build, weil Buy aufwendige Umgehungen erfordert.

Wie verhindere ich, dass ein Build-Projekt im Technologiewald verloren geht?

  • Setzen Sie eine klare Architekturverantwortung, dokumentieren Sie Entscheidungen (ADR), definieren Sie Kill-Kriterien, liefern Sie in kurzen Inkrementen mit echtem Betriebskontakt und standardisieren Sie Ihre Betriebsplattform.

Welche Rolle spielt Open Source?

  • Eine große – wenn Sie Artefakte, Updates und Sicherheit unter eigener Kontrolle halten. Open Source ist kein Selbstzweck; wählen Sie Komponenten, die Sie reproduzierbar bauen, härten und auditieren können. Kommerzielle Bausteine sind dort sinnvoll, wo sie Portabilität und On-Prem-Betrieb nicht einschränken.

Wie gehe ich mit LLMs und Agenten in sensiblen Umgebungen um?

  • On-prem Inferenz und Governance sind der Standardpfad: Modelle lokal betreiben, domänenspezifisch evaluieren, Policies und Observability enforcing, keine externe Telemetrie. Agenten arbeiten mit klaren Tool-Berechtigungen, Human-in-the-Loop für irreversible Aktionen und vollständiger Auditspur.