AI Sovereignty Starts with Data Sovereignty

15. Oktober 2026
Author: Thomas Conrad, CEO, beON consult GmbH

Warum der Standort Ihres KI-Modells nur der Anfang ist

 Zu wissen, wo ein KI-Modell betrieben wird, ist ein guter Anfang: auf eigener Infrastruktur, in einer souveränen Cloud oder in einem regionalen Rechenzentrum. Echte AI-Souveränität entsteht dadurch jedoch noch nicht.

Die entscheidende Frage lautet:

Können Sie die Daten, auf denen Ihre KI basiert, durchgängig kontrollieren – und sie bei Bedarf ohne zeit- und kostenintensives Re-Engineering migrieren?

 

Für viele Unternehmen lautet die Antwort heute noch: nein.

Eine souveräne KI-Architektur muss mehr leisten, als Daten innerhalb einer bestimmten Region zu halten. Sie muss Unternehmen in die Lage versetzen, die gesamte Kette hinter einem KI-Ergebnis zu kontrollieren: Datenquellen, Kopien, Zugriffe, Modelle, Workloads, Provider und die Möglichkeit, eine Plattform wieder zu verlassen.

 

Der Standort des Modells ist nicht gleich Souveränität

In vielen Diskussionen über souveräne KI steht zunächst die Frage im Mittelpunkt:

    • Läuft das Modell in Europa?
    • Wird es in einer Sovereign Cloud betrieben?
    • Bleiben die Daten im regionalen Rechenzentrum?
    • Wird ein privates oder selbst betriebenes LLM eingesetzt?

Diese Fragen sind relevant. Sie beantworten jedoch nur einen Teil des Problems.

Denn auch ein Modell, das in der eigenen Infrastruktur oder in einer souveränen Cloud läuft, kann von Daten abhängen, die:

    • aus nicht kontrollierten Quellen stammen,
    • in mehreren Kopien verteilt sind,
    • außerhalb der vorgesehenen Region verarbeitet werden,
    • an einen bestimmten Plattformanbieter gebunden sind,
    • nur mit proprietären Formaten oder Schnittstellen genutzt werden können,
    • bei einem Plattformwechsel aufwendig neu integriert werden müssten.

Souveränität ist deshalb keine reine Standortfrage. Sie ist eine Frage der Kontrolle über das gesamte System hinter einem KI-Ergebnis.

 

Wenn Zentralisierung die Souveränität schwächt

Ein zentraler Lakehouse- oder Data-Lake-Ansatz kann viele Vorteile bieten: einheitliche Datenzugriffe, zentrale Governance, bessere Analysefähigkeit und eine gemeinsame Grundlage für AI-Anwendungen.

Doch die Zentralisierung aller Daten ist nicht automatisch gleichbedeutend mit mehr Kontrolle.

Mit jeder zusätzlichen Datenkopie entstehen neue Fragen:

    • Verlässt die Kopie eine genehmigte Region?
    • Wer ist für diese Kopie verantwortlich?
    • Welche Zugriffsrechte gelten dort?
    • Wie aktuell und vollständig ist der Datenbestand?
    • Wie lässt sich die Kopie wieder löschen oder zurückführen?
    • Wie aufwendig wäre ein Wechsel der zugrunde liegenden Plattform?
    • Was passiert mit den darauf aufbauenden Agenten, APIs und Dashboards?

Ein zentraler Speicherort kann die technische Abhängigkeit sogar erhöhen. Wenn Daten, Semantik, Vektorspeicher, Orchestrierung und Anwendungen eng an eine Plattform gekoppelt sind, wird ein späterer Wechsel teuer und riskant.

Zentralisierung kann Kontrolle erhöhen – sie kann aber auch neue Abhängigkeiten schaffen. Entscheidend ist die Architektur.

 

Ein anderer Ansatz: der Governed AI Data Layer

Ein AI Data Layer verfolgt einen anderen Ansatz. Er legt nicht zwingend alle Daten physisch an einem Ort ab, sondern bildet eine verwaltete, logische Schicht über verteilten Datenquellen.

AI-Anwendungen greifen dadurch nicht direkt auf die physische Infrastruktur einzelner Systeme zu. Sie nutzen stattdessen:

    • logische Datenprodukte,
    • einheitliche Semantik,
    • definierte Datenzugriffsregeln,
    • Governance- und Policy-Informationen,
    • nachvollziehbare Datenflüsse,
    • kontrollierte Schnittstellen zu SAP- und Non-SAP-Quellen.

Die zugrunde liegenden Daten können sich dabei verändern, verschoben oder in die eigene Umgebung zurückgeführt werden, ohne dass die darüber liegenden Anwendungen vollständig neu entwickelt werden müssen.

Das betrifft beispielsweise:

    • AI-Agenten,
    • APIs,
    • RAG-Anwendungen,
    • Dashboards,
    • Automatisierungs- und Workflow-Lösungen.

Der entscheidende Vorteil ist die Entkopplung:

AI-Anwendungen werden von der physischen Infrastruktur entkoppelt, während Datenkontrolle, Semantik und Governance erhalten bleiben.

Das bedeutet nicht, dass Daten niemals bewegt werden dürfen. Im Gegenteil: Daten können sich bewegen, wenn es fachlich, regulatorisch oder wirtschaftlich sinnvoll ist.

Die eigentliche Frage lautet:

Wer entscheidet, wann, warum und unter welchen Bedingungen die Daten bewegt werden?

Das ist der eigentliche Test für AI-Souveränität.

 

Die sieben Dimensionen souveräner AI-Architekturen

Eine belastbare Bewertung sollte nicht nur den Modellstandort betrachten. Sie sollte mindestens die folgenden Dimensionen abdecken:

  1. Kontrolle über die Quelle
    Wissen Sie, aus welchen Systemen und Datenquellen Ihre KI gespeist wird? Sind Eigentümer, Verantwortlichkeiten und Qualitätsanforderungen eindeutig definiert?
  2. Datenresidenz
    Können Sie nachvollziehen, wo sich die Originaldaten, Kopien, Backups und abgeleiteten Datenprodukte befinden?
  3. Zugriff und Nutzung
    Sind Rollen, Berechtigungen und Zugriffskontexte über SAP-, Non-SAP- und AI-Systeme hinweg konsistent durchgesetzt?
  4. Kopien und Datenprodukte
    Wissen Sie, welche Kopien, Embeddings, Vektoren und abgeleiteten Datenprodukte existieren – und können Sie deren Nutzung kontrollieren?
  5. Wiederverwendung
    Können Daten sicher für unterschiedliche AI-Anwendungen genutzt werden, ohne jedes Mal neue, proprietäre Kopien und Integrationen aufzubauen?
  6. Platzierung von Workloads
    Können Sie abhängig von Sensibilität, Latenz, Kosten und Regulierung entscheiden, wo Datenverarbeitung und AI-Workloads ausgeführt werden?
  7. Portabilität und Exit
    Können Sie Daten, Modelle und Workloads zwischen Plattformen verschieben oder zurück in die eigene Umgebung führen, ohne die darüber liegenden Anwendungen neu zu bauen?

Diese Dimensionen machen sichtbar, ob eine Architektur tatsächlich souverän ist – oder nur souverän wirkt, weil das Modell an einem bestimmten Standort betrieben wird.

 

Der EU Data Act macht Portabilität zur Architekturfrage

Die regulatorischen Anforderungen an Datenkontrolle und Portabilität steigen. Der EU Data Act stärkt unter anderem die Möglichkeit, Daten und Cloud-Dienste zwischen Anbietern zu wechseln. Ab dem 12. Januar 2027 sollen für den Wechsel zwischen Cloud- und vergleichbaren Datenverarbeitungsdiensten keine Wechselentgelte mehr erhoben werden.

Damit wird Portabilität zu mehr als einer kommerziellen Frage.

Unternehmen müssen prüfen:

    • Sind Datenformate und Schnittstellen portabel?
    • Können Workloads in einer anderen Umgebung betrieben werden?
    • Sind Semantik und Policies dokumentiert und übertragbar?
    • Welche proprietären Services werden heute genutzt?
    • Was passiert mit RAG-Pipelines, Vektorspeichern und AI-Agenten bei einem Plattformwechsel?
    • Wie viel Re-Engineering wäre für eine Migration erforderlich?

Der Wegfall von Wechselgebühren reduziert eine finanzielle Hürde. Er löst jedoch nicht automatisch die technische Abhängigkeit.

Ein kostenfreier Plattformwechsel hilft wenig, wenn die Migration Jahre dauert oder zentrale Anwendungen neu entwickelt werden müssen.

Portabilität muss deshalb von Anfang an als Architekturprinzip berücksichtigt werden – nicht erst, wenn ein Anbieterwechsel unmittelbar bevorsteht.

 

Was bedeutet das für SAP-zentrierte Unternehmen?

SAP ist in vielen Unternehmen das Rückgrat kritischer Geschäftsprozesse. Gleichzeitig liegen relevante Informationen häufig auch in:

    • Non-SAP-Anwendungen,
    • Dokumenten und Wissensdatenbanken,
    • CRM- und Servicelösungen,
    • MES- und LIMS-Systemen,
    • IoT- und Maschinendaten,
    • Data-Lake- und Analytics-Plattformen,
    • ITSM- und Betriebsdaten.

Eine souveräne AI-Architektur muss diese Quellen verbinden können, ohne sie unkontrolliert zu kopieren oder Anwendungen an eine einzelne Plattform zu binden.

Für SAP-zentrierte Unternehmen bedeutet das beispielsweise:

    • SAP-Berechtigungen auch für AI-Zugriffe berücksichtigen
    • SAP- und Non-SAP-Daten über kontrollierte Schnittstellen verbinden
    • RAG auf Unternehmensdaten mit Quellenangaben und Zugriffskontrolle betreiben
    • AI-Agenten von physischen Datenplattformen entkoppeln
    • SAP Business AI nutzen, wenn sie fachlich und wirtschaftlich überzeugt
    • offene oder souveräne Technologien einsetzen, wenn Datenhoheit, Flexibilität, Reifegrad oder Kosten dies erfordern
    • Exit- und Migrationsoptionen bereits im PoC berücksichtigen

So entsteht keine isolierte AI-Insel, sondern eine integrierte und möglichst portable Intelligence Layer über und zwischen bestehenden SAP- und Non-SAP-Systemen.

 

Sechs Fragen zur Bewertung Ihrer AI-Souveränität

Unternehmen können ihren aktuellen Stand mit sechs einfachen Fragen überprüfen:

  1. Kontrollieren wir die Datenquellen, Kopien und abgeleiteten Datenprodukte, auf denen unsere KI basiert?
  2. Können wir den vollständigen Datenfluss – einschließlich Embeddings, Vektorspeichern und Backups – nachvollziehen?
  3. Werden bestehende Rollen, Berechtigungen und Governance-Regeln auch in AI-Anwendungen durchgesetzt?
  4. Können wir Daten und Live-Kontext aus verteilten SAP- und Non-SAP-Quellen sicher nutzen?
  5. Können wir Modelle, Provider, Plattformen und Workloads abhängig von Anforderungen flexibel wechseln?
  6. Können wir Daten und Workloads migrieren oder zurückführen, ohne Agenten, APIs und Dashboards neu zu entwickeln?

Wenn mehrere Fragen nicht eindeutig beantwortet werden können, besteht wahrscheinlich eine Lücke zwischen technischer Kontrolle und tatsächlicher Souveränität.

 

Die Perspektive von beON

beON unterstützt SAP-zentrierte Enterprise-Kunden dabei, AI-Architekturen nicht nur sicher zu betreiben, sondern langfristig kontrollierbar und erweiterbar zu gestalten.

Unser Ansatz verbindet:

  • AI- und Architekturstrategie,
  • SAP- und Non-SAP-Integration,
  • Governed AI Data Layer,
  • souveräne und self-hosted AI,
  • portable Modell- und Provider-Schichten,
  • Security, Governance und Auditierbarkeit,
  • produktionsnahe PoCs mit realen Daten,
  • definierte Migrations- und Exit-Optionen.

Dabei gilt:

SAP, wenn SAP fachlich und wirtschaftlich überzeugt.
Offene oder souveräne Technologien, wenn Datenhoheit, Flexibilität, Reifegrad oder Kosten dies erfordern.

Wir betrachten nicht nur, wo ein Modell läuft. Wir analysieren das gesamte System hinter dem KI-Ergebnis: Daten, Zugriffe, Kopien, Workloads, Modelle, Plattformen und Betriebsprozesse.

 

Fazit: Souveränität ist eine Architekturentscheidung

AI-Souveränität beginnt nicht mit der Wahl eines privaten LLMs und endet nicht mit dem Hosting in einer Sovereign Cloud.

Sie entsteht durch die Fähigkeit,

  • Daten und ihre Nutzung zu kontrollieren,
  • Datenflüsse und Kopien transparent zu machen,
  • AI-Anwendungen von der physischen Infrastruktur zu entkoppeln,
  • Modelle und Provider begründet zu wechseln,
  • Workloads flexibel zu platzieren,
  • Daten bei Bedarf zu verschieben oder zurückzuführen,
  • und dies ohne vollständiges Re-Engineering der darüber liegenden Anwendungen.

Nicht entscheidend ist, dass Daten niemals bewegt werden.
Entscheidend ist, dass Sie selbst bestimmen, wann und wie sie bewegt werden.