Souveräne KI
Enterprise AI: 7 Punkte für IT-Verantwortliche | Xinity
Die Entscheidung, KI im Unternehmen einzusetzen, ist längst keine strategische Option mehr. Sie ist eine operative Notwendigkeit. Doch dieser Schritt wirft eine Frage auf, die weit über die Technologie hinausgeht: Wer kontrolliert eigentlich die Infrastruktur, auf der Ihre KI läuft?
Die EU-KI-Verordnung (EU AI Act) erlegt verbindliche Transparenzpflichten auf, DSGVO-Bußgelder erreichen bis zu vier Prozent des weltweiten Jahresumsatzes und unkontrollierte Schatten-KI untergräbt im Stillen jeden Compliance-Ansatz. Gleichzeitig dauert die Migration zu einer souveränen KI-Infrastruktur in der Praxis Tage, nicht Monate.
Dieser Artikel bietet IT-Entscheidungsträgern sieben konkrete Anhaltspunkte: von den rechtlichen Pflichten rund um die Datensouveränität über die reale Bedrohung durch Schatten-KI bis hin zu Open-Weight-Modellen, kalkulierbaren Infrastrukturkosten und prüfungssicherer Protokollierung.
Datensouveränität ist keine Option, sondern eine rechtliche Pflicht
Der rechtliche Rahmen ist bereits verbindlich und hat sich im Juli 2026 verschoben. Gemäß der Verordnung (EU) 2026/1744, dem Digitalen Omnibus zur KI, sind eigenständige Hochrisikosysteme gemäß Anhang III nun erst am 2. Dezember 2027 fällig und nicht wie ursprünglich am 2. August 2026. KI, die in regulierte Produkte gemäß Anhang I eingebettet ist, verschiebt sich auf den 2. August 2028.
Wichtiger als die verschobenen Termine sind jedoch diejenigen, die gleich geblieben sind:
Seit 2. Februar 2025 gelten die verbotenen Praktiken nach Artikel 5 und die Pflicht zur KI-Kompetenz nach Artikel 4. Letztere wurde am 27. Juli 2026 neu formuliert.
Seit 2. August 2026 gelten die Transparenzpflichten nach Artikel 50.
Ab 2. Dezember 2026, also in wenigen Wochen, gilt für bereits auf dem Markt befindliche Systeme eine maschinenlesbare Kennzeichnung nach Artikel 50 Absatz 2 sowie neue Verbote.
Wer seinen Compliance-Plan auf den Dezember 2027 ausrichtet, plant an der nächsten Frist vorbei.
Solange das Inference (die Modellausführung) auf Servern außerhalb der eigenen Kontrolle läuft, bleibt die Datensouveränität strukturell ungesichert – unabhängig davon, wozu sich ein externer Anbieter vertraglich verpflichtet.
Die finanziellen Folgen sind konkret. DSGVO-Verstöße kosten bis zu 4 % des weltweiten Jahresumsatzes. Unter dem AI Act drohen bis zu 7 % bei verbotenen Praktiken und bis zu 3 % bei Verstößen gegen die Pflichten für Hochrisikosysteme. Compliance ist keine vertragliche Frage mehr. Es ist eine architektonische. Siehe die vollständige Compliance-Übersicht.
Technisch bedeutet Datensouveränität Folgendes: Das Inference läuft ausschließlich auf Servern in Ihrem eigenen Netzwerk. Kein Prompt, keine Antwort und keine Metadaten verlassen Ihre Umgebung in Richtung einer externen API.
Schatten-KI ist das größte Compliance-Problem im Haus
In der Praxis entsteht das größte Compliance-Risiko nicht durch schlechte strategische Entscheidungen. Es entsteht durch die alltägliche Improvisation einzelner Teams.
Schatten-KI ist die nicht genehmigte Nutzung öffentlicher LLM-APIs durch Mitarbeiter, die keine konforme Alternative haben. Kein Genehmigungsprozess, kein Audit-Trail, keine Datenschutz-Folgenabschätzung. Das Ausmaß ist dokumentiert: Im PagerDuty 2026 Shadow AI Survey, durchgeführt von Wakefield Research unter 1.250 Büroangestellten in Unternehmen mit einem Umsatz von über 500 Millionen US-Dollar, gaben 66 % an, KI-Tools bei der Arbeit genutzt zu haben, obwohl sie glaubten, dass dies gegen die Unternehmensrichtlinien verstößt, und mehr als ein Drittel hatte Kundendaten in öffentliche KI-Modelle eingegeben. Der Data Breach Investigations Report 2026 von Verizon stellte fest, dass sich die Erkennungen von Schatten-KI innerhalb eines Jahres vervierfacht haben.
Das strukturelle Problem ist der Kontrollverlust. Jede Anfrage an einen externen Anbieter kann Kundendaten, Vertragsinhalte oder Patientenakten übertragen. Diese Daten können in Trainings-Pipelines einfließen, was eine nachträgliche Bereinigung schwierig oder unmöglich macht. Für die Speicherung stellt sich dieselbe Frage wie für die Verarbeitung: Wo Ihre KI-Daten tatsächlich liegen.
Verbote lösen das Problem nicht. Wenn man Teams ohne konforme Alternative lässt, weichen sie in den Untergrund aus. Die einzige effektive Antwort ist die Substitution: ein internes Angebot, das produktiv genug ist, um externe Dienste überflüssig zu machen. Organisationen, die intern souveränes Inference bereitstellen, entziehen der Schatten-KI strukturell den Nährboden, nicht über Richtlinien.
Open-Weight-Modelle machen Kontrolle real und überprüfbar
Das konforme interne Angebot muss selbst auditierbar sein. Hier scheitern proprietäre API-Modelle strukturell: Weder Modellgewichte noch Trainingsprozess noch Inference-Logik sind einsehbar. Für Sicherheitsteams in Banken, Krankenhäusern und Behörden bleibt ein Black-Box-Problem, das keine Zusicherung eines Anbieters lösen kann.
Open-Weight-Modelle lösen das Problem an der Wurzel. Sicherheitsteams prüfen das Modell selbst, anstatt sich auf die Dokumentation des Anbieters zu verlassen. Dies ist kein theoretischer Vorteil: Offene Modelle stehen proprietären Systemen in vielen produktiven Anwendungsfällen in nichts nach.
Für regulierte Umgebungen stellt Xinity spezifische Modelle bereit:
Qwen3.8 27B FP8 (Dense, 27B, Vision, 262K Kontext, Apache 2.0) für allgemeine Inference-Workloads
Qwen3.6 35B A3B (MoE, 35B gesamt / 3B aktiv, 262K Kontext, Apache 2.0) für gemischte Enterprise-Workloads
Ministral 3 3B (Dense, 3B, Vision, Apache 2.0) für hohe Anfragevolumina mit geringen Latenzanforderungen
EmbeddingGemma (CPU-fähig, Gemma-Nutzungsbedingungen) für RAG-Anwendungen mit strukturiertem Dokumentenzugriff
Bestehende Anwendungen erfordern in den meisten Fällen keine Codeänderungen, da die API OpenAI-kompatibel bleibt. Der Wechsel ist auf der Anwendungsebene unsichtbar und auf der regulatorischen Ebene entscheidend.
Die Migration zu souveränem Inference dauert Tage, nicht Monate
Der Wechsel erfolgt in drei Phasen: Hardware-Schnittstellenanalyse, Runtime-Installation und Live-Betrieb. Keine davon erfordert Cloud-Provisionierung oder externe Abhängigkeiten.
Phase 1: Die Hardware-Schnittstellenanalyse stellt fest, welche GPU-Infrastruktur bereits in Ihrem Rechenzentrum vorhanden ist und direkt genutzt werden kann. Bestehende Server werden inventarisiert und die Kapazitätsanforderungen mit den Zielmodellen abgeglichen. Wer bereits eine eigene Serverinfrastruktur betreibt, überspringt jeden Cloud-Bereitstellungsschritt.
Phase 2: Die Runtime-Installation erfolgt auf diesen bestehenden Servern, vollständig innerhalb Ihres eigenen Netzwerks. Während der Einrichtung verlassen keine Daten das Netzwerk, und der Installationsprozess selbst weist keine externen Abhängigkeiten auf.
Phase 3: Der Live-Betrieb beginnt nicht mit einer sofortigen vollständigen Umstellung. Der empfohlene Ansatz ist ein A/B-Routing mit 5 bis 10 % des echten Datenverkehrs, bevor komplett umgestellt wird. So können Sie Antwortqualität und Latenz im Vergleich zu Ihrer bestehenden API-Baseline überprüfen, bevor produktionskritische Workloads migriert werden.
Der entscheidende Unterschied liegt nicht in der Technologie. Er liegt am Ausgangspunkt: Wer seine eigene Hardware kontrolliert, kontrolliert auch den Zeitplan.
Den KI-Stack verstehen: Wo Kontrolle tatsächlich entsteht
Der KI-Stack umfasst Hardware, Betriebssystem und Treiber, Modell-Serving und Orchestrierung, Anwendungslogik sowie Benutzeroberflächen. Die meisten Organisationen kontrollieren bereits die Hardware-, Anwendungs- und Schnittstellenebenen. Die Serving-Ebene ist das, was den Unterschied ausmacht.
Die Serving-Ebene ist der einzige Punkt, an dem Zugriffsrechte, Richtlinien und Audit-Protokollierung über jedes Modell und jede Anwendung hinweg wirksam werden. Welches Modell auch immer darunter läuft und welche Anwendung auch immer darüber liegt: Wer diese Ebene kontrolliert, kontrolliert den gesamten Inference-Prozess.
Ein praktischer Vorteil: Intelligentes Routing auf dieser Ebene ermöglicht die Lastverteilung über mehrere GPUs, automatisches Failover und den Wechsel zwischen Modellen, ohne bestehende Anwendungen anpassen zu müssen. Neue Modellversionen werden im Stack ausgetauscht und die Anwendungsebene merkt nichts davon.
Diese Kontrolle aufzugeben, hat konkrete regulatorische Konsequenzen. Wer nur auf der Modell- oder Anwendungsebene arbeitet, kann nicht lückenlos nachweisen, welche Daten wann von welchem Modell verarbeitet wurden. Und die Transparenzpflichten nach Artikel 50 gelten seit August 2026, nicht erst ab der Frist für Hochrisikosysteme. Mehr zur Verortung der Ebenen: Den KI-Stack verstehen.
Governance beginnt nicht beim Modell. Sie beginnt auf der Ebene, die alles andere zusammenhält.
Von variablen Token-Kosten zu planbarer Infrastruktur
Per-Token-APIs skalieren die Kosten direkt mit dem Nutzungsvolumen, und die Preise ändern sich. Am 30. Juli 2026 senkte OpenAI den Preis für GPT-5.6 Luna um 80 % und für Terra um 20 %, drei Wochen nach dem Start dieser Modelle. Luna sank von 1 $ / 6 $ auf 0,20 $ / 1,20 $ pro Million Input- / Output-Token; Terra von 2,50 $ / 15 $ auf 2 $ / 12 $. Ein im Vergleich zu den Frühjahrstarifen genehmigtes Budget war im August hinfällig – in diesem Fall zugunsten des Kunden, aber die Richtung ist nicht der Punkt. Der Punkt ist, dass der Preis von jemand anderem festgelegt wird und sich ohne Ihr Zutun ändert.
Der Tarifsatz auf dem Papier ist auch nicht das, was Sie letztendlich bezahlen. Reasoning-Modelle erzeugen interne Denk-Token, die zu Output-Tarifen abgerechnet werden, unabhängig davon, ob Sie sie jemals sehen oder nicht. Dadurch liegen die effektiven Kosten bei denkintensiven Aufgaben etwa beim Drei- bis Zehnfachen des Basistarifs. Output-Token selbst kosten bei den meisten Anbietern das Drei- bis Sechsfache von Input-Token.
Für Krankenhäuser, Behörden und Banken, die jährlich planen und Budgets genehmigen lassen, ist diese Volatilität strukturell unvereinbar mit dem normalen Budgetprozess.
Eine On-Premise-Infrastruktur wandelt variable Betriebskosten in planbare Investitionskosten um. Hardware, Energie, Betrieb und Lizenzierung lassen sich einmalig kalkulieren. Ab einem bestimmten Anfragevolumen kippen die Gesamtkosten deutlich zugunsten einer eigenen Infrastruktur, da es keine Verhandlungen über Mengenrabatte, keinen Routing-Overhead und keine von einem externen Anbieter auferlegten Preisänderungen gibt.
Einkaufsteams und CFOs können ihre eigenen Token-Kosten mit On-Premise-Alternativen vergleichen und mit dem Xinity ROI-Rechner den Break-Even-Point für ihr spezifisches Anfragevolumen ermitteln.
Audit-Trails als regulatorischer Nachweis
Für Hochrisikosysteme fordert die EU-KI-Verordnung ab dem 2. Dezember 2027 lückenlose Aufzeichnungen gemäß den Artikeln 12 und 16. Die zentrale Frage lautet: Welches Modell hat wann aus welchen Eingaben welche Ausgaben erzeugt? Bei einer Prüfung fragen Behörden nicht nach Absichtserklärungen. Sie verlangen vollständige Inference-Protokolle.
Ein konformer Audit-Trail umfasst mindestens Folgendes:
Zeitstempel jeder Anfrage
Modellversion zum Zeitpunkt des Inference
Input-Hash
Generierter Output
Aufrufende Anwendung
Identität des anfragenden Nutzers oder Systems
Bei öffentlichen APIs liegt die technische Kontrolle über die Protokolldaten beim Anbieter. Ob und wie viel davon beim Kunden ankommt, variiert je nach Anbieter und ist vertraglich nicht standardisiert.
Konforme Audit-Trails lassen sich nicht nachträglich anbauen. Sie entstehen auf der Serving-Ebene, die jede Inference-Anfrage durchläuft, oder sie entstehen gar nicht. Diese Entscheidung wird beim Aufbau der Plattform getroffen.
Fazit: sieben Punkte, eine architektonische Entscheidung
Die Einführung von KI in regulierten Branchen ist keine Modell- oder Tooling-Entscheidung. Es ist eine Infrastruktur- und Compliance-Entscheidung.
Die zusätzlichen 16 Monate bis Dezember 2027 sind keine Atempause. Sie sind Vorbereitungszeit. Der nächste verbindliche Termin fällt in den Dezember 2026, nicht 2027.
Der konkrete nächste Schritt ist eine Hardware-Schnittstellenanalyse Ihrer bestehenden Infrastruktur. Sie beziffert, welche GPU-Kapazität bereits nutzbar ist, welcher Migrationspfad realistisch ist und ab welchem Anfragevolumen eine eigene Infrastruktur wirtschaftlicher ist als externe APIs.
Wer souveränes Inference ohne langfristige Bindung evaluieren möchte, kann dies im Rahmen eines 30-tägigen Pilotprojekts auf eigener Hardware tun. Echte Workloads, eigene Daten, eigene Infrastruktur. Bewerben Sie sich für einen Pilotplatz — das Programm steht Unternehmen ab 15 Mitarbeitern offen.
Für IT-Entscheidungsträger im DACH-Raum bietet das Sovereign AI Lab Meetup in Wien einen strukturierten Rahmen, um Architekturentscheidungen, regulatorische Anforderungen und Betriebsmodelle mit Fachkollegen zu vergleichen. Details unter Sovereign AI Lab.
Souveräne KI ist keine Frage des Vertrauens in einen Anbieter. Sie ist eine Frage der Architektur.
Ein erster Entwurf dieses Artikels wurde mit einem KI-Schreibwerkzeug erstellt. Er wurde anschließend von der Xinity-Redaktion, die die redaktionelle Verantwortung für den veröffentlichten Text trägt, überprüft, überarbeitet und auf Fakten geprüft. Regulatorische Daten wurden mit der Verordnung (EU) 2026/1744 und der EU-KI-Verordnung abgeglichen; Zahlen und Zitate wurden anhand der im Text verlinkten Primärquellen überprüft.