Für Tech·Vertiefung

Souveräne KI für Tech-Teams — Vertiefung

Stack-Architektur konkret: was austauschbar bleibt, wo die operative Komplexität liegt, welche Bibliotheken das Tooling tragen.

Souveräne KI ist für Tech-Teams keine Compliance-Übung, sondern eine Architektur-Disziplin. Open Weights, EU-Inferenz und auditierbare Pipelines lassen sich produktiv betreiben — in Latenz, Kosten und Performance vergleichbar mit kommerziellen APIs. Diese Seite zeigt, wo die technischen Trennlinien zwischen marketing-souverän und juristisch souverän liegen, und welche Stack-Entscheidungen den Unterschied tragen.

Was sich für Engineering-Teams gerade verschiebt

Die letzten 18 Monate haben die Praxis verändert. Open-Weight-Modelle wie Llama 3.x, Mistral Large, Qwen 2.5, Teuken-7B und EuroLLM erreichen für nicht-Frontier-Aufgaben — Zusammenfassen, Klassifikation, Code-Assistenz, Frage-Antwort über interne Daten — Qualität, die noch 2023 nur kommerzielle Spitzenmodelle lieferten. Quantisierung auf INT8 oder FP8 senkt die Hardware-Schwelle weiter; ein 70B-Modell läuft auf einer einzelnen H100, ein 30B-Modell auf einer A100. Die Frage ist nicht mehr, ob Open-Weight produktiv tragfähig ist, sondern unter welchen Constraints sich was lohnt.

Parallel hat der Inferenz-Stack einen Reifesprung gemacht. vLLM, SGLang und TensorRT-LLM bieten OpenAI-kompatible APIs mit Continuous Batching und Speculative Decoding; durchgehende Tokens-pro-Sekunde-Werte erreichen kommerzielle Größenordnungen. Auf Infrastruktur-Seite stehen europäische Anbieter — Stackit, OVHcloud, IONOS, Scaleway, AI-Factories nach EuroHPC-Initiative — mit GPU-Kapazität bereit. Co-Location für eigene H100/H200-Cluster ist bei mittlerer Auslastung über drei Jahre häufig günstiger als Pay-per-Token.

Was Engineering hier zu liefern hat, ist nicht 'mehr Souveränität', sondern eine Architektur-Disziplin, die Modell-, Daten- und Vertrags-Schichten austauschbar hält. OpenAI-kompatible Inferenz-API als Lingua franca, offene Vektor-Formate (pgvector, Qdrant), versionierte Modell-Pipelines mit deterministischem Replay — das ist nicht teurer als ein Hyperscaler-Lock-in, sondern die Vorbedingung dafür, dass ein Wechsel im Stresstest tatsächlich funktioniert. Souveränität wird damit zu einem messbaren Engineering-Outcome, nicht zu einem Compliance-Etikett.

Drei Spannungsfelder, die Souveränität konkret machen

Inferenz-Ökonomie und GPU-Verfügbarkeit

Eigene GPU-Inferenz lohnt sich erst ab kontinuierlicher Auslastung. Spot-Verfügbarkeit für H100 und H200 in Europa ist 2025 limitiert; Reservierungs-Verträge mit Stackit, OVHcloud oder Co-Location-Anbietern brauchen Vorlauf. Ohne realistische Volumen-Schätzung fährt das Projekt entweder zu teuer (überdimensioniert) oder zu langsam (Kapazitäts-Bottleneck unter Peak-Last).

Stack-Komplexität versus Plug-and-Play-API

Frontier-APIs liefern fertiges Routing, Filtering, Rate-Limiting und Logging — alles in einer Zeile. Souveräner Self-Host bedeutet, diese Schichten selbst zu bauen oder zu integrieren: vLLM-Cluster, OpenAI-kompatible Fassade, Observability-Stack, Modell-Versionierung. Underestimated wird typischerweise der operative Footprint, nicht die Modell-Performance.

Modell-Wechselbarkeit als Code-Disziplin

Migrationskosten zwischen Modellen sind selten linear. Prompt-Templates, Tool-Calling-Schemata und Inferenz-Parameter sind oft modell-spezifisch optimiert. Ohne Abstraktion über die OpenAI-API hinaus — Prompt-Versionierung, Eval-Suiten, Output-Schemata — wird ein 'einfacher Modell-Tausch' zum Quartalsprojekt.

Die vier Säulen souveräner KI

Auf dieser Ebene sind die vier Säulen vertraut. Interessant wird die Trennlinie zwischen marketing-souverän und juristisch souverän — und welche Architektur-Muster den Unterschied tragen.

Modell

Lizenz, Trainings-Provenienz, Migrationspfad — was hält im Audit?

Die Modell-Auswahl entscheidet, ob Sie zwischen Anbietern wechseln können oder nicht. Closed-Source-APIs wie GPT-4o oder Claude bieten exzellente Performance, aber keinen Audit-Pfad zu Trainings-Daten und keine Migrations-Garantie für Ihre Prompts und Fine-Tunes. Open-Weight-Modelle (Mistral Large, Llama 3.x, Teuken-7B, Qwen) lassen sich quantisiert auch auf moderaten GPUs betreiben — ein H100 reicht für 70B-Modelle in INT8. Praxis: Die meisten Souveränitäts-Strategien fahren zwei Geschwindigkeiten. Frontier-API für unkritische Aufgaben (Code-Assist, Marketing-Drafting), Open-Weight selbst gehostet für regulierte und vertrauliche Workloads. Die Gretchen-Frage im Audit ist nie 'welches Modell', sondern 'wie schnell können Sie wechseln'.

Daten

Auftragsverarbeitung, Subprocessor-Kette, technische und vertragliche Schutzschichten

Daten-Souveränität wird im Auftragsverarbeitungs-Vertrag entschieden, nicht im Marketing. Achten Sie auf drei Punkte: erstens die vollständige Subprocessor-Kette — listet der Anbieter US-Subprocessoren oder verbleibt die Verarbeitung in der EU? Zweitens das Trainingsverbot — wird ihre Eingabe zur Modell-Verbesserung verwendet, ja oder nein, vertraglich? Drittens die Verschlüsselung — wer hält die Schlüssel? 'Customer-managed encryption' bei US-Anbietern hilft gegen Mit-Mandanten, nicht gegen den CLOUD Act. Hardware-gestützte Schlüsselverwahrung (HSM) in EU-eigener Hand ist die einzige technische Schutzschicht, die unabhängig vom Vertragspartner trägt.

Betrieb

Auswahlkriterien für souveräne Inferenz-Plattformen

'Europäischer Anbieter' ist Stufe eins, 'unter ausschließlich europäischer Jurisdiktion' ist Stufe zwei. Letzteres bedeutet: keine US-Muttergesellschaft, kein US-Cloud im Backend, keine Service-Level-Vereinbarung, die im Konfliktfall nach US-Recht ausgelegt wird. Realistische Stack-Optionen für GPU-Inferenz: Stackit (Schwarz-Gruppe), OVHcloud, IONOS, Scaleway, deutsche AI-Factories nach EuroHPC-Initiative. Für hochvertrauliche Workloads ist Co-Location die robusteste Variante — eigene Hardware in einem zertifizierten Rechenzentrum, eigener Hypervisor, eigenes Netzwerk-Segment. Klingt teuer, ist bei mittlerer GPU-Auslastung über drei Jahre oft günstiger als Pay-per-Token.

Governance

EU AI Act, Risikoklassifizierung, interne Verantwortlichkeiten

Der EU AI Act gilt seit 2024 und wird bis Mitte 2026 vollständig wirksam. Für Hochrisiko-KI (Personalentscheidungen, Kreditwürdigkeit, kritische Infrastruktur) verlangt er ein dokumentiertes Risikomanagement nach Artikel 9, Datenqualitäts-Maßstäbe nach Artikel 10, technische Dokumentation nach Artikel 11 und menschliche Aufsicht nach Artikel 14. Praktisch heißt das: Sie brauchen eine KI-Inventur, eine Risikoklassifizierung pro Anwendung, ein Verfahren für Betroffenenrechte und eine benannte verantwortliche Person mit Eingriffsbefugnis. Verträge mit Modell-Anbietern müssen die nötigen Audit-Rechte gewähren — sonst können Sie die Compliance-Pflicht nicht erfüllen, selbst wenn Sie wollten.

Spektrum der KI-Souveränität

Von vollständiger Abhängigkeit zu vollständiger Kontrolle – wo steht Ihre Organisation?

← Hohe AbhängigkeitHohe Souveränität →
Level 1
1

Volle Abhängigkeit

Proof of ConceptsNicht-kritische AppsSchnelle Experimente
OpenAI ChatGPT API
Google Gemini API
AWS Bedrock APIs
Anthropic Claude API
Keine Datenkontrolle
Kein Modell-Eigentum
Externe Infrastruktur
Vendor Lock-in
Level 2
2

Hybride Kontrolle

Regulierte BranchenMittelständische UnternehmenCompliance-Anforderungen
Azure AI on VMs
AWS SageMaker
Google Vertex AI
Lokales Modell-Hosting
Teilweise Datenkontrolle
Begrenzte Anpassbarkeit
On-Premises-Option
Anbieterabhängigkeit
Level 3
3

Verwaltete Souveränität

BehördenFinanzdienstleistungenKritische Infrastruktur
Oracle Cloud@Customer
Microsoft Cloud for Sovereignty
OVHcloud KI-Dienste
Regionale Cloud-Anbieter
Datensouveränität
Lokale Jurisdiktion
Compliance-zertifiziert
Geteilte Infrastruktur
Level 4
4

Vollständige Souveränität

Verteidigung & GeheimdiensteGroßkonzerneStrategische KI-Fähigkeiten
On-Premises-Infrastruktur
Open-Source-Modelle (Llama etc.)
Eigene Trainingspipelines
Selbstverwaltete Infrastruktur
Vollständige Kontrolle
Keine Abhängigkeiten
Alles anpassbar
Hohe Komplexität
Der passende Level hängt von Ihrer Risikotoleranz und den strategischen Anforderungen ab. Die meisten Unternehmen benötigen Level 2–3. Kritische Anwendungen erfordern möglicherweise Level 4.

Praxisbeispiele für tech

RAG-Pipeline auf souveränem Stack

KontextEngineering-Team baut eine Retrieval-Augmented-Generation-Pipeline für interne Dokumentation und Frage-Antwort über Confluence, Wikis und Code-Bases.

SouveränEmbeddings, Vektorspeicher und LLM-Inferenz vollständig in EU-Kontrolle. OpenAI-kompatible Schnittstelle nach außen, damit Anwendungs-Code stabil bleibt.

BeispielOpen-Source-Embedding (BGE-M3, multilingual-e5-large), Qdrant oder pgvector als Speicher, Llama-3.3-70B oder Mistral Large quantisiert auf vLLM-Cluster — alles auf europäischer GPU-Infrastruktur, deterministische Reproduzierbarkeit über Modell-Versions-Pinning.

Code-Assistenz für interne Code-Bases

KontextEntwicklungs-Team will KI-Assistenz im IDE, ohne proprietären Code an externe APIs zu schicken.

SouveränCode verlässt die eigene Infrastruktur nicht, Modell-Vorhersagen werden lokal oder im eigenen Cluster generiert, IP-Risiko bleibt kontrolliert.

BeispielDeepSeek-Coder, Qwen 2.5-Coder oder StarCoder-Derivat als Backend, OpenAI-kompatible API für IDE-Plug-ins (Continue, Cursor self-hosted), Inference-Server auf eigener GPU-Hardware oder souveräner Cloud.

Klassifikation und Annotation in großem Volumen

KontextDatenpipelines brauchen automatische Klassifikation, Annotation oder Extraktion von strukturierten Feldern aus Texten — Tausende Dokumente pro Stunde.

SouveränDaten verlassen die Kontrolle nicht, Modell-Wechsel ist möglich ohne Daten-Migration, Inferenz-Kosten skalieren mit eigenem Hardware-Budget.

BeispielKleine, spezialisierte Open-Weight-Modelle (Phi-3.5, Llama-3.2-3B) als Batch-Inferenz auf eigener GPU, Embeddings für semantische Suche, Versionierung von Klassifikations-Schemata in Git.

Häufige Fragen

Welche Inferenz-Engine passt zu welchem Workload?
vLLM ist der breite Standard für Produktion mit Continuous Batching und PagedAttention — Latenz und Throughput in derselben Pipeline. SGLang punktet bei strukturierten Prompts und Constraint-Decoding (JSON-Schema, RegEx-Matching). TensorRT-LLM liefert die schnellsten TPS-Werte auf NVIDIA-Hardware, ist aber engineering-aufwendiger. llama.cpp und Ollama sind richtig für Edge oder Single-Node-Workloads. Faustregel: vLLM als Default, SGLang für strukturiertes Output, llama.cpp für CPU-Edge.
Wie wird ein Modell-Wechsel ohne Quartalsprojekt möglich?
Vier Disziplinen: Erstens OpenAI-kompatible Fassade über alle Backends — Anwendungs-Code muss nicht wissen, ob das Backend GPT-4o, Llama 3.3 oder Mistral Large ist. Zweitens versionierte Prompts mit Eval-Suite, sodass Regression beim Wechsel sofort sichtbar wird. Drittens abstrahiertes Tool-Calling-Schema (z. B. via JSON-Schema-Validation) statt modell-spezifischer Funktion-Definitionen. Viertens dokumentierte Sampling-Parameter pro Workload. So wird ein Wechsel zu einer Konfigurations-Änderung statt zu einem Refactor.
Welche Beobachtungs- und Eval-Praktiken sind realistisch?
Observability: Prometheus-Metriken auf Token-Throughput, Tail-Latency, GPU-Utilization, Queue-Length pro vLLM-Worker. Logs mit Eingabe-Hash, Modell-Version, Sampling-Seeds. Eval: regelmäßige Smoke-Tests gegen einen kuratierten Goldstandard (200 bis 500 Beispiele pro Workload), automatisiertes A/B-Vergleichen vor jedem Modell-Update. Tools: Langfuse, Phoenix oder Eigenbau auf OpenTelemetry. Wichtig: Eval ist Engineering-Code, nicht Data-Science-Notebook.
Wann lohnt Co-Location gegenüber souveräner Cloud?
Bei kontinuierlicher GPU-Auslastung über 60 Prozent und Drei-Jahres-Horizont ist Co-Location oft 30 bis 50 Prozent günstiger als gleichwertige Cloud-Reservierung. Voraussetzung: vorhandene Server-Operations-Reife, Vertrauensnetzwerk für Hardware-Beschaffung (NVIDIA-Lead-Times), redundantes Networking. Souveräne Cloud bleibt richtig für Burst-Workloads, frühe Phasen und Teams ohne Ops-Team. Mischmodell: Baseline auf Co-Location, Burst-Kapazität auf souveräner Cloud.
Wie integriert sich AI-Act-Logging in einen modernen Inferenz-Stack?
Logging-Pflichten aus Artikel 12 verlangen Lebensdauer-Protokolle. Praktisch: strukturiertes Logging via OpenTelemetry mit Eingabe-Hash, Modell-Versions-ID, Sampling-Parametern und Ausgabe-Hash; Sink in EU-only Object-Storage mit Object-Lock; Rotation und Aufbewahrung dokumentiert. Replay-Fähigkeit: Modell-Snapshot in einer Registry (z. B. lokale OCI-Images), Sampling-Determinismus durch fixed seed bei Audit-relevanten Inferenzen. Für Hochrisiko-Workloads: zusätzliche Daten-Lineage von Source bis Output.

vLLM erreicht mit Continuous Batching und PagedAttention bei einer H100 für Llama-70B-Quantization Throughput-Werte von 1.500 bis 3.000 Tokens/s je nach Workload.
Quelle: vLLM Project Benchmarks 2024

EU-AI-Act-Artikel 12 verlangt automatisches Logging über die gesamte Lebensdauer eines Hochrisiko-Systems mit Replay-Fähigkeit.
Quelle: EU AI Act, Artikel 12

Praxisleitfaden · 22 Seiten · PDF

Souveräne KI in der Praxis.

Eine Ausarbeitung für Entscheider: EU AI Act, CLOUD Act, Architektur-Optionen und Vertragsbausteine für die nächsten 18 Monate. Direkt im Postfach, ohne Sales-Anruf.

Ihre E-Mail-Adresse nutzen wir ausschließlich für die Zustellung des Praxisleitfadens und gelegentliche Updates zu souveräner KI. Abmeldung jederzeit per Link in jeder E-Mail. Mehr in unserer Datenschutzerklärung.