Wenn man maschinelles Denken als Grundlage für operative Wertschöpfung einsetzen möchte (sprich: tief in seine Geschäftsprozesse integriert) redet man de facto über strategisch relevante Infrastruktur. Diese unterliegt anderen Anforderungen an Risikomanagement als z.B. Assistenzsysteme à la Copiloten oder Chatbots.
Bei strategisch relevanter Infrastruktur ist es im Sinne Business Continuity wichtig, sie auch bei exogenen Schocksituationen unterbrechungsfrei betreiben zu können, um den Geschäftsbetrieb nicht zu gefährden (bis hin zu existenziellen Risiken).
Die geopolitische Lage macht es (bedauerlicherweise) erforderlich, sich mit diversen Aspekten der geoökonomischen Instrumentalisierung von digitalen Abhängigkeiten zu befassen. Das Thema ist ernst — aber es gibt keinen Grund, in Defätismus zu verfallen. Wichtig ist ein strukturierter, ganzheitlicher Ansatz und ein möglichst nüchterner, analytischer Blick auf das Thema.
Souveränität und Resilienz sind aber keine Dogmata. Es wäre unrealistisch und unseriös, Souveränität und Resilienz mit vollständiger Autonomie zu verwechseln bzw. gleichzusetzen. Es geht um die systematische Bewertung von ökonomischen und juristischen Risiken und deren strukturelle, möglichst dauerhafte Absicherung bzw. die Fähigkeit für deren proaktives Management.
Digitale Infrastrukturen sind für viele Unternehmen geschäftskritisch.
Unerwartete Preiserhöhungen können Wertschöpfung massiv einschränken.
Hier eine kurze, allgemeinverständliche Beschreibung.
Es geht um Marktposition, Wettbewerbsfähigkeit.
Wenn die Supply Chain bricht, wäre die Nutzung maschinellen Denkens bereits nach kurzer Zeit durch ausbleibende Security Patches akut gefährdet. Damit das nicht passiert, treffen wir Vorkehrungen für die operative und strategische Absicherung der Supply Chains.
Die Wahl der Compute-Plattform ist ein äußerst sensibler Punkt, weil er maßgeblichen Einfluss auf verschiedene Risikoklassen hat. Gerade wenn maschinelles Denken in Kernprozesse integriert werden soll, sind Wahlfreiheit und Portierbarkeit strategische Lebensversicherungen.
Je nachdem, in welchen Prozessen und Bereichen Sie maschinelles Denken einsetzen wollen, hat der Schutz von Geschäftsgeheimnissen und die Beachtung von Compliance-Vorschfriften rund um Endkundendaten einen besonders hohen Stellenwert.
Zentrales Risiko: Ausbleibende Updates durch Instrumentalisierung in geopolitischen oder geoökonomischen Konflikten (z.B. über die Verhängung von Ausfuhrkontrollen). Ausbleibende Updates können, mit Blick auf fehlende Security Patches, sehr schnell zur de facto Unbetreibbarkeit der Plattform führen.
Open Source per se ist kein Garant für Resilienz. Projekte ohne klare Governance-Strukturen, mit kleinen oder fragmentierten Communities und ohne langfristige Wartungsperspektive können erhebliche operative Risiken bergen – insbesondere im Hinblick auf Updates, Security Patches und regulatorische Anforderungen.
Sprachmodelle gehören ebenfalls in diese Kategorie, weil sie de facto auch „nur“ Software sind (Inference-Server, Modell-Bibliotheken, Modell-Gewichte).
Vorsätzliche Einschränkung von Software-Updates und/oder Zugängen.
Gerade die LLM-Inference bei Closed Source Modellen kann ein erhebliches Risiko für Preiserhöhungen bergen.
Für Querschnittskomponenten des embraceable-Stacks setzen wir auf Open Source Komponenten, die drei klaren Kriterien entsprechen müssen: unabhängige, transparente Projekt-Governance, große, globale Communities und permissive Lizenzen.
Für alle zentralen Dienste der CCU haben wir die vollständige und alleinige Hoheit. Für alle Komponenten existieren granulare SBOMs. Es existieren Prozesse für Vulnerability- & Provenance-Management (mit Blick auf die Supply Chain Integrity).
Weitergehende Aspekte (wie z.B. SBOM, Vulnerability Management, Supply Chain Integrity) besprechen wir gerne bilateral.
Die Wahl des konkreten Sprachmodells für die LGU ist eine Abwägung aus Performance und Risikoaspekten.
Gleichzeitig können Compliance-Anforderungen die Offenlegung von Trainingsdaten erforderlich machen.
Aus diesem Grund ist der embraceable-Stack auf maximale Wahlfreiheit bzgl. LLM designed.
Damit können Kunden nach ihren eigenen Kriterien frei entscheiden.
Proprietäre Modelle von OpenAI, Anthropic, Google et al., entweder über die Anbieter-native API oder Hyperscaler Model Foundries.
Modell-Bibliotheken und Gewichte sind offen, Trainingsdaten nicht. Llama 3.3., Qwen 3, entweder als Inference-as-a-Service oder selbst gehostet.
Inklusive Offenlegung Trainingsdaten wie z.B. Olmo 3.1.
Zentrales Risiko: je nachdem, welchen Anbieter / Betreiber man wählt, fallen die eigenen Daten unter den Gültigkeitsbereich des US Cloud Acts. Gerade bei sensiblen und/oder juristisch heiklen Daten bestehen große ökonomische und haftungsrelevante Risiken.
Außerdem ist man dem Risiko einseitiger Preiserhöhungen ausgesetzt. Hinzu kommt eine neue Risikoklasse durch geopolitische Instrumentalisierung von Abhängigkeiten z.B. durch Exportsteuern auf Daten, Zugangsbeschränkungen, Verschlechterung von SLAs, etc.
Portierbarkeit ist eine entscheidende Eigenschaft, um im Falle ungeplanter exogener Schocks die eigene Reaktions- und Handlungsfähigkeit zu gewährleisten. In geopolitisch bewegten Zeiten avanciert Portierbarkeit zum heimlichen Star.
Wir möchten dabei keine Anbieter ausschließen, sondern geben die Wahlfreiheit, den Anbieter & Betreiber der Compute-Plattform nach dem eigenen Risikoprofil auszuwählen — und im Bedarf geänderter Randbedingungen schnell und unkompliziert zu wechseln.
Der Zugriff ausländischer Dienste aus Geschäftsgeheimnisse kann eine Bedrohung der Marktposition bis hin zum Verlust der Wettbewerbsfähigkeit sein.
Die Verletzung von Compliance-Richtlinien zum Schutz sensibler Endkundendaten kann emfpindliche Strafen nach sich ziehen.
Unangemessene, einseitige Periserhöhungen oder Leistungsbeschränkungen können als Druckmittel in geopolitischen Auseinandersetzungen eingesetzt werden.
Sämtliche Komponenten des embraceable-Stacks sind durchgängig containieriert. Wir setzen durchgängig auf Kubernetes aus Container Orchestrator. Sie haben damit eine maximal breite Auswahl unterschiedlicher Compute-Plattformen.
Um volle Portierbarkeit zu gewährleisten, vermeiden wir konsequent anbieter-spezifisches PaaS. Sämtliche Querschnitts-Komponenten stammen aus qualifizierten Open Source Projekten. So können wir vollständige Ende-zu-Ende Portierbarkeit der Compute-Plattform in Tagen statt Wochen oder Monaten gewährleisten.
Zentrales Risiko: Die Hoheit über sensible Daten hat weitreichende Auswirkungen auf die Absicherung der eigenen Marktposition und Wettbewerbsfähigkeit (durch wirksamen Schutz von Betriebsgeheimnissen).
Darüber hinaus gibt es vielfältige Compliance-Vorschriften, die eine lokalisierte Verarbeitung und Speicherung von Endkundendaten verlangen, unter teilweise empfindlichen Strafen bei Nicht-Erfüllung.
Der Verstoß gegen strenge Compliance-Auflagen kann weitreichende Folgen haben.
Der Abfluss von Geschäftsgeheimnissen kann existensbedrohende Ausmaße annehmen.
Durch die Wahlfreiheit auf Infrastruktur-Ebene können Sie eine vollständig verwaltete Compute-Plattform wählen, die außerhalb des Einflussbereiches des US Cloud Acts liegt — oder alternativ ihre eigene Compute-Plattform nutzen (OnPremise).
Wir verwenden, ganz grundsätzlich, keine Kundendaten für das Training von Modellen. Je nach Wahl der LGU-Option können Sie einen Anbieter wählen, der keine Inferenzdaten (Prompt und dgl.) speichert. Wir beraten Sie zu den Optionen.
Weitergehende Aspekte (wie z.B. die Ausgestaltung von von Zugriffsrechten durch Administratoren und Umgang mit Telemetriedaten) besprechen wir gerne bilateral.
Für Querschnittskomponenten des embraceable-Stacks setzen wir auf Open Source Komponenten, die drei klaren Kriterien entsprechen müssen: unabhängige Governance, große, globale Communities und permissive Lizenzen.
Für Querschnittskomponenten des embraceable-Stacks setzen wir auf Open Source Komponenten, die drei klaren Kriterien entsprechen müssen: unabhängige Governance, große, globale Communities und permissive Lizenzen.
Für Querschnittskomponenten des embraceable-Stacks setzen wir auf Open Source Komponenten, die drei klaren Kriterien entsprechen müssen: unabhängige Governance, große, globale Communities und permissive Lizenzen.
Für Querschnittskomponenten des embraceable-Stacks setzen wir auf Open Source Komponenten, die drei klaren Kriterien entsprechen müssen: unabhängige Governance, große, globale Communities und permissive Lizenzen.
