KI-Architektur für KMU: 5 Ansätze zur Provider-Unabhängigkeit

Compute-Autarkie für KI-Workloads, bereitgestellt über einen eigenen GPU-Cluster, ist für viele kleine und mittelständische Unternehmen wirtschaftlich nicht tragbar. Doch es gibt weitere Optionen, sich zumindest teilweise von der vollständigen Abhängigkeit zu befreien. Ein Baustein hierfür ist eine Architektur, die Abhängigkeiten von einzelnen Modelllen oder Providern strukturell reduziert.

Architektur für souverän(er)en KI-Betrieb

Souveränität wird oftmal auf die Hardware reduziert. Doch das ist zu kurz gegriffen. Für die Maximierung und Sicherstellung der eigenen Handlungsfähigkeit ist der Schutz der Unternehmensdaten und die Verlässlichkeit von (KI-) Systemen in relevanten Abläufen ebenso entscheidend.

Was eine produktionsreife KI-Architektur ausmacht

Wenn jemand von „KI-Integration" spricht, meint er oder sie eventuell: Aufruf eines Modell-Endpoints, die generierte Antwort kommt zurück, weiter geht’s im bestehenden Prozess. Das funktioniert — bis es dann doch nicht mehr so funktioniert wie gewünscht.

„Architektur" meint hier etwas Präziseres: die Gesamtheit der Komponenten, die zwischen Geschäftsprozess und Modell sitzen und darüber entscheiden, ob ein Provider-Wechsel lediglich eine Konfigurationsänderung ist oder ein risikoreiches Notfallprojekt. Eine produktionsreife KI-Architektur besteht aus mehreren Ebenen — exemplarisch:

LLM-Gateway / Adapter-Layer

Alle Modellaufrufe laufen durch eine eigene Zwischenschicht mit einheitlicher Schnittstelle (das OpenAI-kompatible API-Format hat sich pragmatisch durchgesetzt). Provider — ob Anthropic, Mistral, OpenAI, Azure oder ein lokales Modell — werden zu austauschbaren Plug-ins. Einen Workspace von Anthropic auf Mistral umzustellen ist dann eine Konfigurationsänderung im Gateway, kein Code-Umbau in der Geschäftslogik.

Guardrails

Gilt für jede LLM-Integration — unabhängig davon, ob ein Agent im Spiel ist. Input- und Output-Validierung, bevor Anfragen das Modell erreichen bzw. Antworten das System verlassen: Schema-Validierung strukturierter Outputs (Pydantic / JSON Schema), PII-Erkennung (personenbezogene Daten wie Namen, E-Mail-Adressen, IBANs) und -Redaktion vor dem API-Aufruf, Budget-Gates (maximale Token-Kosten pro Anfrage).

Agent Harness (nur bei agentischen Systemen relevant)

Ein Agent Harness ist das Software-Gerüst, das ein Modell erst zum handlungsfähigen Agenten macht — abgeleitet vom englischen „Geschirr/Gurtzeug". Es besteht aus drei kanonischen Schichten (Vgl. Databricks , DataCamp ): Tools & Skills (Schnittstellen zur Umgebung: Browser, Dateisystem, Shell, APIs), Memory & Kontext (persistenter Speicher, oft vektorbasiert, damit der Agent über Sitzungen hinweg nicht den Faden verliert) und Kontrolle & Sicherheitsrichtlinien (Ausgabenfilter, Token-Limits, Tool-Sperren, Human-in-the-Loop vor kritischen Aktionen). Entscheidend: Autonomie ist keine Eigenschaft des Modells selbst, sondern wird erst durch das Harness ermöglicht — und begrenzt. Ohne Harness kein kontrollierter Agentenbetrieb.

Workflow-Orchestrierung

Die Ablaufsteuerung mehrstufiger Prozesse — sequenzielle Schritte, parallele Branches, Event-Chains, bedingte Übergaben. Das gilt für klassische Automatisierungspipelines genauso wie für agentische Systeme. Im agentischen Kontext kommt hinzu: Übergaben zwischen verschiedenen Agenten (Multi-Agenten-Systeme), koordiniertes Tool-Calling, geteilte Zustände. Das Harness definiert, was ein Agent kann; die Orchestrierung definiert, wann welcher Schritt oder Agent in welcher Reihenfolge aktiv wird. Frameworks wie LangGraph, CrewAI oder Tools wie n8n arbeiten auf dieser Ebene; entscheidend ist, dass Fallback-Strategien vor dem Produktiveinsatz definiert sind.

Observability / Tracing

Jede Modell-Anfrage erzeugt einen hierarchischen Trace — bestehend aus Spans für den eingehenden Request, den Provider-Call, etwaige Guardrail-Checks und Tool-Calls. Jeder Span erfasst: Modell-ID, Prompt-Hash, Token-Verbrauch (Input/Output), Latenz, Kosten, Nutzer-ID, Session-Kontext. Das ermöglicht in der Praxis vier Dinge, die ohne Tracing nicht messbar sind: Cost-Attribution (welcher Use Case, welche Abteilung verursacht welche Kosten), Drift-Monitoring (verändert sich die Antwortverteilung über Zeit bei gleichem Input?), Eval-Sets (regressionsfeste Testfragen mit erwarteten Antworten, die bei jedem Deployment laufen) und Anomalie-Erkennung (ungewöhnliche Token-Spitzen, fehlerhafte Agenten-Loops). Ab August 2026 ist Logging und Nachvollziehbarkeit für Hochrisiko-KI-Systeme unter dem EU AI Act regulatorische Pflicht — keine Empfehlung. Tools wie Langfuse (self-hosted, DSGVO-konform), LangSmith oder Mastra Studio decken diese Anforderungen ab.

Logging / Protokollierung (konzeptuell von Observability zu trennen)

Observability dient der operativen Transparenz und Kostensteuerung — Logging im regulatorischen Sinne ist etwas anderes. Art. 12 EU AI Act schreibt vor, dass Hochrisiko-KI-Systeme mit automatischen Protokollierungsfunktionen ausgestattet sein müssen, die drei Zwecken dienen: Risikoerkennung, Beobachtung nach dem Inverkehrbringen, und Überwachung des Betriebs. Die Norm ISO/IEC DIS 24970:2025 (referenziert durch EN 18229-1) konkretisiert: Protokolleinträge müssen Fehlerdetails, Fallback-Mechanismen, Zeitstempel, Komponenten-IDs und Nutzer-IDs enthalten — und mit den Designentscheidungen und Datenflüssen des Systems verknüpft sein. Kurz: Wer Observability-Tooling hat, hat noch kein AI-Act-konformes Logging — beides braucht eine bewusste Architekturentscheidung.

Authentifizierung und Zugriffskontrolle

SSO-Anbindung (Entra ID, Keycloak, Okta via OIDC) ist Pflicht, keine Option. Dazu kommt Row-Level-Security im Retrieval-Layer: Ein Mitarbeiter darf nur die Dokument-Chunks sehen, auf deren Quelldokument er auch im Originalsystem Zugriff hat.

Integration in die Kern-Geschäftslogik

Prompts sind Konfiguration, nicht Hardcode. Credentials und Modell-Auswahl liegen in der Datenbank, nicht im Deployment-Artefakt. Das bedeutet: ein Modellwechsel erfordert kein neues Release, sondern nur ein Update in der Datenbank.

Diese Aufzählung ist nicht vollständig im Sinne einer universellen Architektur — sie soll das Prinzip verdeutlichen: Architektur ist ein entscheidender Hebel für einen souveränen Betrieb von KI-Anwendungen oder Agenten. Die Architektur bestimmt nicht nur die Sicherheit, sondern ist auch entscheidend für das Design von Kontrollmechanismen, für Kostenminimierung, die Skalierung von Anwendungen und die Reproduzierbarkeit von Ergebnissen. Letztlich entscheidet nicht nur das Modell die Qualität eines KI-Systems, sondern die Architektur. Ein LLM-Endpoint alleine macht noch keine Anwendung!

Gerade in der Architektur liegt der Wert der Lösung. Hier bietet sich für Europa ein erheblicher Gestaltungskorridor. Die Anwendungsebene (gepaart mit guten technischen Ansätzen) bietet Möglichkeiten, Werte zu etablieren, die für die Souveränität einerseits und die Innovation am Standort andererseits entscheidend sind. Sascha Lobo verwies in seinem Podcast auf das Land der KI-Tüftler und das damit verbundene Potenzial.

Für ein souveränes Europa ist es wichtig, dass wir die neuen Technologien nicht durch eine zu enge Fokussierung auf Rechenzentren definieren und nicht den nicht erreichbaren Paritäten hinterherjagen, sondern dass wir gleichermaßen wieder kompetent „Tüftler" werden, Innovation vorantreiben und Wertschöpfungsketten aufbauen. Im Bereich KI sind die Deutschen etwa bisher gute Anwender. D.h. so schlecht sieht es mit der Adaption gar nicht aus. Noch stärker sollten wir uns im Bereich des Experimentierens, Probierens, Ausbauen versuchen. Denn dafür haben wir im Grunde gute Voraussetzungen.

Reminder: Jurisdiktion vor Serverstandort

Die juristische Einordnung — Vertragspartner, Muttergesellschaft, Delaware Flip, Cloud Act — hat Teil 1 bereits behandelt. Und aus dieser jursitischen Ebene ergibt sich eine Konsequenz für die Architektur-Ebene: Ein EU-Rechenzentrum allein ist keine Souveränitätsgarantie und schätzt nicht vor Datenabfluss. Trotzdem (und auch aufgrund der Betrachtung aus Teil 2 ) kann die Wahl eines US-Anbieters mit Standort in der EU und starkem Vertragswerk für unkritische Workloads vertretbar sein. Maßgeblich ist, dass man sich des Risikos bewusst ist, dieses getragen und dokumentiert wird.

Die BSI-Präsidentin Claudia Plattner empfiehlt kurzfristig pragmatisch: Es gehe darum, „möglichst viele Kontrollmechanismen einzubauen“ –> Genau das ist der Auftrag der Architektur-Governance. Die folgenden Ansätze fokussieren auf einen konkreten Teilaspekt: Provider-Abhängigkeit reduzieren. Sie sind keine vollständige Architektur — die Komponenten aus dem vorherigen Abschnitt (Guardrails, Agent Harness, Observability, Logging, Auth) sind die Grundlage, auf der diese Ansätze aufsetzen. Welche Ansätze relevant sind, hängt vom Use-Case-Typ ab — nicht jeder Ansatz ist für jeden Anwendungsfall sinnvoll. Protokolle z. B. sind nur bei agentischen Systemen relevant, RAG nur bei wissensbasierten Use Cases.

Ansatz 1: Inferenz-Gateway (Provider-Agnostik)

Bevor über eine Anwendung direkt openai.chat.completions oder anthropic.messages aufgerufen wird, wird die Anfrage gewrapped. Es liegt typischerweise eine eigene Abstraktionsschicht zwischen der eigentlichen Anwendung und der Ansteuerung des Inferenz-Providers. Technisch kann dies über OpenAI-kompatiblen Proxies wie LiteLLM, OpenRouter self-hosted oder einer eigenen Thin API umgesetzt werden.

Funktionen eines Gateways sind z.B.:

• Einheitliches Request-/Response-Format
• Routing-Regeln (Modell A für Task X, Modell B für Task Y)
• Authentifizierung und Autorisierung
• Rate-Limiting und Token-Budgets pro Nutzer (oder Abteilung)
• Zentrales Logging für Audit-Zwecke
• Fallback-Handling bei Timeout oder HTTP 403

Hinweis: Gleiche Prompts liefern bei einem Modellwechsel unterschiedliche Outputs. Ein Modell- oder Providerwechsel erfordert daher Regressionstests auf repräsentativen Datensätzen. Wie stabil die Antworten sein müssen, hängt vom Anwendungsfall ab — man kann nicht garantieren, dass die Qualität identisch bleibt, aber durch solche Tests gewinnt man Kontrolle über die Ergebnisqualität. Wenn es rein um die Ansteuerung eines anderen API-Endpunkts geht, reichen Unit-Tests.

Ansatz 2: Semantic Routing

Welches Modell für welchen Anwendungsfall antworten sollte, kann aufgrund von Kosten, Compliance, Latenz und weiteren Faktoren entschieden werden. Man kann diese Entscheidungen auch dynamisch treffen — zur Laufzeit, pro Anfrage. Ein vergleichsweise kleines, günstiges Modell (lokal oder über eine EU-API) klassifiziert eingehende Anfragen und routet sie an den geeigneten Inferenz-Endpunkt:

Die obige Tabelle ist eine vereinfachte Darstellung. In der Praxis kann das Routing deutlich feingranularer ausfallen — basierend auf mehreren Signalen pro Anfrage: Komplexität, Domain, Sprache, Modality (Text/Bild/Code), PII-Erkennung, Jailbreak-Verdacht, Kontextlänge. Projekte wie der vLLM Semantic Router zeigen, wie sich diese Signale zu einer Control Plane für LLM-Routing zusammensetzen lassen: Routing-Logik wird aus dem Anwendungscode herausgezogen und als konfigurierbare Policy formuliert. Das ermöglicht capability-aware Selection — Anfragen werden nach Aufgabenprofil, Risiko und Qualitätsanforderungen geroutet, nicht pauschal auf ein einziges Modell geleitet. Governance-Funktionen (PII-Filter, Jailbreak-Erkennung, Hallucination-Checks) laufen direkt im Request-Pfad, am selben Layer, das die Routing-Entscheidung trifft.

Ein weiterer Effekt: Token Economy. Premium-Modelle, lange Kontextfenster und Tool-Calls werden nur für Anfragen reserviert, die sie tatsächlich brauchen. Semantic Caching — das Wiederverwenden bereits berechneter Antworten bei semantisch ähnlichen Anfragen — reduziert Kosten und Latenz zusätzlich, ohne die Qualität zu senken.

Ergänzend empfiehlt sich Context Compression (z. B. LLMLingua-ähnliche Verdichtung): Relevante Passagen statt vollständiger Dokumente im Prompt. In vielen RAG-Szenarien reduziert das den Token-Verbrauch um 40–70 % — weniger Kosten, weniger Datenexposition. Das ist nicht kosmetisch: RAG-Systeme sind extrem Token-hungrig — für jede Anfrage landen oft hunderte Seiten Text im Prompt. Ohne Routing und Compression feuert man diese vollen Kontexte an teure Frontier-Modelle (Claude Opus, GPT-4) — die Token-Kosten explodieren. Ein Gateway mit Semantic Routing erkennt, ob eine einfache Frage vorliegt (→ kleines Modell, ggf. gecachte Antwort) oder eine komplexe Synthese (→ Frontier-Modell, aber mit komprimiertem Kontext).

Ansatz 3: Offene Protokolle — MCP, A2A und ANP

Offene Protokolle sind inzwischen ein wichtiger Bestandteil der Architektur — aber sie sind kein automatischer Souveränitätsgewinn. Wer proprietäre Integrationen baut — sei es Tool-Calling direkt auf die OpenAI Function Calling API oder Agenten-Kommunikation über herstellerspezifische Formate — koppelt seine Geschäftslogik an einen einzelnen Provider. Offene Protokolle entkoppeln auf der Transport- und Schnittstellenebene: Die Integrationsschicht bleibt stabil, auch wenn das Inferenz-Backend wechselt. Doch zwei Aspekte werden oft übersehen:

• Semantische Abhängigkeiten bleiben bestehen. Ein MCP-Tool definiert seine Schnittstelle über natürlichsprachliche Beschreibungen und JSON-Schema-Felder. Diese sind unconstrained — das Modell wählt Tools basierend auf Texten, die interpretierbar sind. Ein Modellwechsel kann das Tool-Selection-Verhalten verändern, selbst wenn die MCP-Spezifikation identisch bleibt. Offene Protokolle lösen das Paritätsproblem nicht, sie verlagern es.
• Sicherheitsrisiken durch die Angriffsfläche. MCP vergrößert die Angriffsfläche erheblich. Die OWASP MCP Top 10 dokumentiert Risiken von Tool Poisoning über Prompt Injection bis hin zu Supply-Chain-Angriffen — allein im ersten Quartal 2026 wurden über 30 CVEs gegen MCP-Infrastruktur gemeldet. Eine akademische Analyse zeigt, dass MCPs Architektur die Attack-Success-Rate um 23–41 % gegenüber vergleichbaren Non-MCP-Integrationen erhöht. Die Authentifizierung ist in der MCP-Spezifikation explizit optional — ein Internet-Scan im Juli 2025 fand 1.862 öffentlich erreichbare MCP-Server ohne Authentifizierung.

Die Konsequenz: Offene Protokolle sind ein Architektur-Baustein, kein trendiger Selbstzweck. Sie reduzieren möglicherweise den Provider-Lock-in auf der Protokollebene, erfordern aber eigene Governance — Tool-Attestierung, Authentifizierung, Schema-Validierung und Audit-Logging.

Drei Protokolle sind gerade im Kontext von KI-Agenten relevant:

MCP (Model Context Protocol)

Initiiert von Anthropic (2024) — MCP standardisiert, wie Agenten auf Tools zugreifen — Datenbanken, Dateisysteme, APIs. OpenAI, Google und Microsoft haben MCP inzwischen adoptiert; es hat sich als De-facto-Standard durchgesetzt.

Strategischer Wert: Tool-Integration bleibt auch dann stabil, wenn das Inferenz-Backend wechselt. Zudem können bestehende Systeme über MCP-Tools in Agenten-Systeme integriert werden, ohne dass diese selbst umgeschrieben werden müssen.

Was MCP nicht leistet:

• Prompts und Tool-Calling-Verhalten, Kontextgrößen und die Qualität der Antworten unterscheiden sich zwischen Modellen — daran ändert ein MCP-Ansatz nichts.
• MCP ist kein Ersatz für Daten-Governance — wer MCP an ein ERP mit personenbezogenen Daten hängt, hat das Datenschutzproblem nur verschoben und nicht gelöst
• Reifegrad: Das Ökosystem wächst, Enterprise-Standardisierung ist noch im Fluss — nicht alle MCP-Implementierungen sind gleich sicher oder stabil.

Trotzdem gilt: Eine interne MCP-Tool-Bibliothek (ERP-Read, Ticket-System, Dokumenten-Index) ist langfristig oft pragmatischer als ein Finetuning auf ein einzelnes Modell — das beim nächsten Release ohnehin überholt ist.

A2A (Agent-to-Agent)

Veröffentlicht von Google im April 2025 — A2A ist ein horizontales Protokoll: Es definiert, wie ein Agent Teilaufgaben an einen anderen Agenten delegiert, Statusrückmeldungen erhält und Ergebnisse übernimmt. Während MCP die vertikale Frage beantwortet („Welche Tools und Daten kann dieser Agent nutzen?"), beantwortet A2A die horizontale Frage („Welcher Agent soll diese Aufgabe übernehmen, und wie koordinieren wir das?"). In der Praxis arbeiten beide Protokolle zusammen: Ein Orchestrator-Agent delegiert via A2A an einen spezialisierten Agenten, dieser wiederum nutzt MCP, um auf Datenquellen und Tools zuzugreifen.

Technisch basiert A2A auf etablierten Web-Standards — JSON-RPC 2.0 über HTTPS , Server-Sent Events (SSE) für Streaming, Push-Notifications für asynchrone Workflows. Jeder A2A-fähige Agent veröffentlicht eine sogenannte Agent Card unter /.well-known/agent-card.json — ein JSON-Dokument, das Name, Fähigkeiten, unterstützte Modalitäten (Text, Dateien, Audio) und Authentifizierungsanforderungen beschreibt. Aufgaben durchlaufen einen definierten Task-Lifecycle : submitted → working → input-required → completed/failed/canceled/rejected.

Die Linux Foundation hostet A2A seit Dezember 2025 unter dem Agentic AI Foundation (AAIF) -Dach, co-gegründet von OpenAI, Anthropic, Google, Microsoft und AWS. Im August 2025 fusionierte IBMs konkurrierendes ACP (Agent Communication Protocol) freiwillig in A2A — damit gibt es praktisch keine Alternative mehr. Stand April 2026 unterstützen über 150 Organisationen A2A, darunter Salesforce, SAP, ServiceNow, Workday und PayPal (Produktionseinsatz). Das SDK-Ökosystem umfasst Python, JavaScript, Java, Go und .NET.

ANP (Agent Network Protocol)

ANP geht einen Schritt weiter als A2A: Statt Agenten-Koordination mit zentralem Orchestrator fokussiert sich ANP auf dezentrale Peer-to-Peer-Kommunikation — relevant für Szenarien, in denen Agenten sich autonom finden, authentifizieren und verständigen, ohne eine zentrale Vermittlungsinstanz. Die Protokoll-Architektur besteht aus drei Schichten:

• Identity & Secure Communication Layer: Basierend auf W3C DID (Decentralized Identifiers) — Agenten authentifizieren sich dezentral über die did:wba-Methode (Web-Based Agent), ohne eine zentrale Certificate Authority. End-to-End-Verschlüsselung ist integraler Bestandteil.
• Meta-Protocol Layer: Agenten verhandeln zur Laufzeit, welches Anwendungsprotokoll sie für die Kommunikation verwenden — mit 0-RTT-Negotiation beim Erstkontakt und konsensbasierter Aushandlung für wiederkehrende Verbindungen.
• Application Protocol Layer: Die Agent Description Protocol (ADP) ermöglicht es Agenten, ihre Fähigkeiten strukturiert zu beschreiben und über einen Discovery-Mechanismus gefunden zu werden — basierend auf Semantic-Web-Standards.

ANP ist damit das ambitionierteste der drei Protokolle — es zielt auf das „HTTP der Agent-Internet-Ära" ab. Der Reifegrad ist jedoch niedriger als bei MCP und A2A: Die Spezifikation (v1.0, Mai 2025) ist weitgehend abgeschlossen, aber das Ökosystem und die Produktionsadoption befinden sich noch in einem frühen Stadium.

Über alle drei Protokolle hinweg gilt: Sie reduzieren Provider-Lock-in auf Transport- und Schnittstellenebene — ersetzen aber nicht die eigene Governance. Wer offene Standards einführt, ohne Authentifizierung, Tool-Attestierung und Schema-Validierung zu konfigurieren, tauscht Provider-Abhängigkeit gegen neue Angriffsvektoren. Für mich gilt auch die Wichtigkeit des Tüftelns, was die sinnvolle Ausnutzung neuer Protokolle betrifft. Denn es ist wichtig, dass man die neuen Technologien nicht nur theoretisch kennt, sondern auch praktisch anwendet und testet.

Ansatz 4: Modell-Destillation und Edge AI

Die Antwort auf den VRAM-Bedarf von Frontier-Modellen lautet auch: Spezialisierung. Ein Mittelständler benötigt in der Regel keine Universal-Intelligenz, die Physik-Examen besteht, 30 Sprachen beherrscht und ausgefallene Rezepte kennt. Gefragt sind spezialisierte Modelle, die für spezifische Unternehmensdaten optimiert sind.

Das Vorgehen ist hybrid und trennt bewusst zwischen Destillationsphase und Produktivbetrieb:

1. Wissensdestillation mit Frontier-Modellen: Ein großes Modell (via europäischer Cloud) wird genutzt, um Unternehmensdaten aufzubereiten, Synthesen zu erstellen und Trainingsdaten zu generieren. Die sensiblen Rohdaten verlassen dabei nicht das Unternehmen — das Frontier-Modell verarbeitet vorbereitete, anonymisierte oder synthetische Daten.
2. Transfer in kleine lokale Modelle: Das destillierte Wissen wird in Modelle der 8B- bis 14B-Parameter-Klasse (z. B. Llama-3-Derivate oder Mistral) übertragen — durch Finetuning oder Instruction-Tuning auf den generierten Trainingsdaten. Diese Modelle sind als Open Weights kostenlos verfügbar — aber „Open Weights" ist nicht gleich „Open Source": Die Modellgewichte können heruntergeladen und lokal ausgeführt werden, doch kommerzielle Nutzung und Finetuning sind oft an Lizenzbedingungen geknüpft (z. B. Metas Llama-Lizenz mit Nutzungsschwellen und Acceptable-Use-Policy). Eine rechtliche Prüfung der Lizenzbedingungen vor dem produktiven Einsatz ist Pflicht.
3. Lokaler Produktivbetrieb: Diese stark quantisierten, hochspezialisierten Modelle erfordern keine Rechenzentren. Ein System mit 64 GB Unified Memory (Apple M-Serie, AMD AI-Workstation) kann 8B/14B-Modelle performant, vollständig lokal und zu 100 % datensouverän ausführen — kein GPU-Cluster, kein CapEx in Serverinfrastruktur.

Für das Finetuning bietet Mistral eigene Dienste an. Der Ansatz trennt sauber: Frontier-Leistung für die Destillationsphase, lokale Souveränität im Produktivbetrieb.

Ansatz 5: RAG mit portabler Daten-Schicht

Für wissensbasierte Use Cases (interne Suche, Dokumentenanalyse, Compliance-Assistenten) ist die Portabilität der Datenschicht entscheidend. RAG-Systeme bestehen aus mehreren Schichten, die jeweils unabhängig austauschbar sein müssen:

• Rohdaten bleiben im Unternehmen (SharePoint, Dateisystem, DMS) — kein Vendor-Lock-in auf Speicherebene
• Embeddings in exportierbarem Format (pgvector, Qdrant, Weaviate — mit dokumentiertem Schema)
• Chunking-Metadaten versioniert und reproduzierbar

Was oft übersehen wird: Das Embedding-Modell ist selbst eine Lock-in-Schicht. Vektor-Embeddings verschiedener Provider sind nicht untereinander kompatibel — der Vektorraum hängt am jeweiligen Modell. Unterschiedliche Modelle produzieren zudem unterschiedlich dimensionierte Vektoren (z. B. OpenAI text-embedding-3-small: 1.536 Dimensionen, Cohere embed-v3: 1.024, MiniLM: 384). Das bedeutet: Ein Modellwechsel erfordert nicht nur ein Re-Embedding des gesamten Korpus, sondern auch einen neuen Vektor-Index — andere Dimensionen, andere Index-Struktur. Für einen Mittelständler mit 10.000–100.000 Dokumenten ist das in Stunden machbar; für Large Enterprises mit Millionen Dokumenten kann es Wochen bedeuten. Wenn der Provider ein Embedding-Modell deprecated und ein neues einführt — wie OpenAI mit dem Wechsel von text-embedding-ada-002 auf text-embedding-3-small/large — werden bestehende Vektoren langfristig ungültig.

Praktische Maßnahmen für Portabilität:

• Embedding-Versionierung: Jedes Embedding dokumentiert Modell-ID, Modell-Version und verwendete Parameter — ohne diese Metadaten ist ein Korpus nicht reproduzierbar
• Abstraktion des Embedding-Pipelines: Eine eigene Schnittstelle für Embedding-Operationen, die den konkreten Provider verbirgt — analog zum Inferenz-Gateway aus Ansatz 1
• Periodische Evaluierung: Regelmäßiger Benchmark alternativer Embedding-Modelle auf repräsentativen Test-Queries, um den Switch-Aufwand realistisch einschätzen zu können
• Dual-Index-Strategie (für hochkritische Korpora): Parallel-Indexierung mit einem Zweitprovider während der Migrationsphase, um Ausfallzeiten zu vermeiden

Mit dieser Disziplin ist ein Provider-Wechsel ein Re-Embedding-Job, kein Neuaufbau der Wissensbasis. Ohne sie ist jeder Wechsel ein Migrationsprojekt — mit unbekanntem Zeitaufwand und dem Risiko, dass die Retrieval-Qualität während der Übergangsphase abfällt.

Einordnung: Use-Cases und architektonische Maturität

Die fünf Ansätze sind Werkzeuge für Provider-Unabhängigkeit — nicht eine kumulative Leiter, bei der „mehr Ansätze = souveräner". Welche Ansätze relevant sind, hängt vom Use-Case-Typ ab. Welche Architektur-Komponenten (Guardrails, Harness, Observability, Logging, Auth) zusätzlich nötig sind, hängt vom Reife-Grad der Gesamtarchitektur. Beide Dimensionen sind unabhängig voneinander zu bewerten.

Use-Case-Typen und relevante Ansätze

Protokolle (Ansatz 3) sind nur bei agentischen Systemen sinnvoll — ein Chatbot ohne Tool-Zugriff braucht kein MCP. Destillation (Ansatz 4) ist eine Modell-Strategie, kein Add-on auf Routing. RAG (Ansatz 5) ist nur bei wissensbasierten Use Cases relevant. Die Ansätze nicht-kumulativ zu denken, sondern nach Use-Case-Typ zu wählen, ist der Schlüssel zu einer Architektur, die weder über- noch unterdimensioniert ist.

Architektur-Reife

Unabhängig vom Use-Case-Typ gibt es eine zweite Dimension: Wie reif ist die Gesamtarchitektur? Hierbei geht es um die Komponenten aus dem Abschnitt „Was eine produktionsreife KI-Architektur ausmacht" — nicht um die Anzahl der eingesetzten Ansätze.

Ein System kann den Reife-Grad „Produktiv" mit lediglich dem Ansatz 1 (Gateway) nur erreichen, wenn die Architektur-Komponenten (Guardrails, Observability, Logging) vollständig implementiert sind. Umgekehrt macht Ansatz 3 (Protokolle) ohne Agent Harness und Guardrails keinen Sinn. Reife bemisst sich nach der Vollständigkeit der Architektur, nicht nach der Anzahl der Ansätze.

Beispiele zur Orientierung

Ad-hoc (siehe Reifegrad / Tabelle oben) ist nicht per se naiv — für einen internen FAQ-Chatbot mit öffentlich verfügbaren Daten kann „Basis" bewusst ausreichend sein. Problematisch wird es, wenn dieselbe Architektur unbemerkt auf kritische Prozesse ausgeweitet wird (Shadow AI in Fachabteilungen). “Produktiv” ist der Default-Zielgrad für geschäftskritische KI: vollständige Architektur mit allen relevanten Komponenten, Provider-Wechsel ist als Konfigurationsänderung möglich, drift-Monitoring und Auditierbarkeit sind gewährleistet.

Messbare Souveränität: Drei KPIs

Eine Strategie ohne Metriken ist oft nur ein Glaubensbekenntnis.

Migration Time to Inference (MTTI)

Definition: Die vergangene Zeit vom Auftreten eines Provider-Ausfalls bis zur Wiederherstellung der produktiven Workflows auf einem alternativem Inferenz-Backend (alternative Konfiguration).

Zielwert: < 48 h für geschäftskritische Prozesse — nur erreichbar mit vorbereitetem Fallback, automatisiertem Gateway und abgelegten Regressionstests.

Messung: Halbjährlicher Chaos-Drill (Provider absichtlich deaktivieren, Runbook ausführen, Zeit stoppen).

Inferenz-Volatilität (IV)

Definition: Standardabweichung der Inferenz-Kosten pro 1.000 Anfragen über drei Quartale, normalisiert auf vergleichbares Aufgabenvolumen.

Interpretation: Hohe IV = Abhängigkeit von einem Tarifmodell oder unkontrolliertem Token-Wachstum. Senkung durch Routing, Compression und Budget-Caps.

Data-Ingestion-Portabilität (DIP)

Definition: Anteil der Wissensbasen, die innerhalb von 5 Arbeitstagen auf ein anderes Embedding-Modell migrierbar sind — mit dokumentiertem Skript und ohne manuelle Neuannotation.

Ziel: > 80 % der produktiven RAG-Quellen.

Der 4-Schritte-Umsetzungsfahrplan

Vorausgesetzt: Es existiert bereits Klarheit über den KI-Einsatz im Geschäftsmodell und erste Prozessbetrachtungen haben stattgefunden.

Step 1 — Inventarisierung

• Alle KI-Use-Cases erfassen (inkl. Shadow AI) und nach Kritikalität priorisieren
• Für jeden Use Case: Schichtenmodell skizzieren, aktuellen Provider und Datenflüsse dokumentieren
• Verträge prüfen: Training-Opt-out, Sub-Processors, Exit-Klauseln

Step 2 — Entkopplung Tier-1

• Inferenz-Gateway für die 3–5 kritischsten Prozesse einrichten
• Mindestens 2 Provider angebunden und einmal vollständig getestet
• RAG-Quellen und Daten auf portable Formate standardisieren

Step 3 — Routing & Governance

• Semantic-Routing-Regeln produktiv schalten
• Logging und Audit für AI-Act-relevante Systeme (ab 2. August 2026 Pflicht)
• MTTI-Drill #1 durchführen

Step 4 — Optimierung

• IV und Token-Budgets reviewen
• Kontext-Kompression und Caching implementieren
• Fine-Tunes nur dort, wo DIP und MTTI es erlauben
• Entscheidung: EU-Premium für welche Tiers dauerhaft budgetieren?

Hinweis zum Ziel: Nicht Token-Maximierung, sondern maximaler Impact pro eingesetztem Token. Wer Prompts auf Länge optimiert statt auf Präzision, zahlt zweimal — einmal in Kosten, einmal in Qualität.

Regulatorische Umsetzung in Deutschland

Der Bundestag beschloss am 11. Juni 2026 das KI-Marktüberwachungs- und Innovationsförderungsgesetz (KI-MIG) als deutsches Durchführungsgesetz zum EU AI Act. Die Bundesnetzagentur (BNetzA) wird zur zentralen Koordinierungsstelle für KI-Marktaufsicht. Das BMDS betont einen innovationsoffenen Ansatz mit KI-Reallaboren als Sandbox-Instrument.

Das Bündel aus EU AI Act, NIS2 und DORA macht Souveränität zu einer Audit-Frage: Kann das Unternehmen nachweisen, welches Modell welche Daten wann verarbeitet hat? Wer das nicht lückenlos dokumentieren kann, fällt spätestens beim NIS2-Audit durch.

Der Souveränitäts-Stack im Überblick

Die Konsequenz für die IT-Strategie ergibt sich aus drei Ebenen — und zeigt, wo Architektur-Entscheidungen tatsächlich Hebel bieten:

Ein EU-Modell auf EU-Cloud böte maximalen Schutz gegen regulatorische Risiken und Datenzugriff (Ebene 1 & 2) — aber noch keinen Schutz gegen globale Hardware-Lieferketten-Schocks (Ebene 3, siehe Teil 2 ). Strategisch denkende Unternehmen sichern sich deshalb physische Compute-Kontingente frühzeitig: langfristige Bare-Metal-Leasing-Verträge oder dedizierte On-Premises-Inferenz-Nodes binden die Rechenleistung lokal, bevor die globale Lieferkette im Ernstfall reißt.

Fazit: Architektur vor Modellwahl

KI-Souveränität 2026 ist weder „alles in die EU-Cloud" noch „Frontier im Keller". Für den Mittelstand ist die Situation ernst, aber gestaltbar: Geopolitisches Risiko (Fable-Sperre) und ökonomische Realität (VRAM-Kosten) führen zur gleichen Konsequenz.

Architektur vor Modellwahl. Messbarkeit vor Marketing. Ehrliche Trade-offs statt Souveränitäts-Mythen.

Die operative Frage für die Geschäftsführung lautet nicht, ob man US-Technologie nutzt — das tun die meisten in irgendeiner Form. Sie lautet: Wissen wir, welche Prozesse bei einem Provider-Ausfall in welcher Zeit auf welcher Schiene weiterlaufen — und haben wir das im letzten Jahr getestet?

Wenn nicht, ist das die eigentliche Lücke. Und der erste Schritt ist keine Investitionsentscheidung, sondern ein Inventar.

Sind Ihre KI-Use-Cases bereits inventarisiert? Oder steht der Aufbau eines Inferenz-Gateways auf der Agenda? Wenn Sie Unterstützung bei der Umsetzung brauchen, lassen Sie uns sprechen.

Die anderen Teile der Artikel-Serie finden sich im Überblicksartikel zur KI-Souveränität 2026 .

Stand: Juni 2026. Zahlen zu Modell-Specs und Preisen sind Schätzungen auf Basis öffentlicher Angaben — vor Investitionsentscheidungen eigenes TCO-Modell rechnen.