Redaktions- und Quellenhinweis
Dieser Beitrag wurde mit Unterstützung von Künstlicher Intelligenz recherchiert und formuliert sowie redaktionell geprüft und eingeordnet. Grundlage sind Veröffentlichungen der Europäischen Kommission, des Bundesministeriums für Digitales und Staatsmodernisierung, des BSI, der Datenschutzkonferenz und der EU-Rechtsrahmen. Der Artikel überträgt öffentliche Souveränitätskonzepte auf Unternehmensprojekte; er ersetzt keine Rechts-, Datenschutz- oder Beschaffungsberatung im Einzelfall.
⚡ In 30 Sekunden
- Digitale Souveränität heißt bei KI nicht, jede Technologie selbst zu entwickeln. Sie heißt, Abhängigkeiten zu kennen, bewusst zu wählen und im entscheidenden Moment handlungsfähig zu bleiben.
- Der Serverstandort ist nur eine Ebene. Ebenso wichtig sind Datenzugriff, Modellwechsel, offene Schnittstellen, Schlüsselkontrolle, Vertragsrechte, Betriebswissen und die Lieferkette.
- Open Source kann Wechsel- und Gestaltungsfähigkeit erhöhen, garantiert sie aber nicht. Fehlende Kompetenzen, spezialisierte Hardware oder proprietäre Betriebsbausteine können neue Abhängigkeiten schaffen.
- Nicht jeder Use Case benötigt maximale Souveränität. Je höher möglicher Schaden, Kritikalität und Irreversibilität, desto stärker müssen technische und organisatorische Kontrolle sein.
- Der beste Praxistest ist ein geprobter Exit: Kann das Unternehmen Daten, Prompts, Evaluationen und Betriebswissen exportieren und den Dienst mit vertretbarem Aufwand ersetzen?
Executive Summary für Entscheider
Digitale Souveränität entsteht im Zusammenspiel von Architektur, Verträgen, Kompetenzen und Governance. Die wirtschaftlich sinnvolle Zielgröße ist nicht maximale Unabhängigkeit, sondern kontrollierbare Abhängigkeit: Ein interner Schreibassistent kann mit einem sauber geregelten SaaS-Dienst auskommen. Eine KI, die Geschäftsgeheimnisse verarbeitet oder Kunden- und Produktionsprozesse steuert, braucht stärkere Portabilität, eigene Evaluationen und einen belastbaren Ausweichpfad.
Was Unternehmen jetzt konkret tun sollten
- Kritikalität vor Technologie klären: Schaden, Datenarten, Ausfalltoleranz, Irreversibilität und regulatorische Rolle des KI-Systems dokumentieren.
- Den gesamten Stack prüfen: Nicht nur Modell und Cloud betrachten, sondern auch Datenbanken, Embeddings, Identitäten, Schlüssel, Agentenwerkzeuge, Protokolle und Supportketten.
- Exit als Abnahmekriterium definieren: Exportformate, Fristen, Kosten, Löschung und Wiederanlauf bei einem anderen Anbieter vertraglich und technisch testen.
- Wissen außerhalb des Anbieters sichern: Prompts, Systemlogik, Evaluationsfälle, Richtlinien, Konfigurationen und Betriebsdokumentation im eigenen Verantwortungsbereich halten.
- Souveränität risikobasiert staffeln: Basis-, Standard- und erhöhte Anforderungen festlegen, statt jede Anwendung in die teuerste Betriebsform zu zwingen.
Digitale Souveränität entscheidet über Handlungsfähigkeit
Digitale Souveränität entscheidet bei KI-Projekten nicht darüber, ob Unternehmen Cloud nutzen dürfen – sondern ob sie bei Ausfällen, Preisänderungen oder Anbieterwechseln handlungsfähig bleiben.
Viele Projekte starten mit einem Chatdienst oder einer Modell-API. Erst vor dem Produktivbetrieb wird sichtbar, welche Prompts, Protokolle, Vektordaten und Betriebskenntnisse beim Anbieter oder Implementierungspartner gebunden sind. Dann wird aus einer bequemen technische Entscheidung eine strategische Abhängigkeit.
Das Bundesministerium für Digitales und Staatsmodernisierung beschreibt für große Sprachmodelle drei strategische Ziele: Wechselmöglichkeit, Gestaltungsfähigkeit und Einfluss auf Anbieter. Die Europäische Kommission geht in ihrem Cloud Sovereignty Framework noch breiter vor und bewertet 48 Kriterien in acht Bereichen – von strategischer und rechtlicher Souveränität über Daten, Betrieb, Lieferkette und Technologie bis zu Sicherheit, Compliance und Nachhaltigkeit.
Der Souveränitäts-Stack für KI-Projekte
Eine KI-Anwendung besteht nicht nur aus einem Modell. Ein RAG-Assistent kann beispielsweise Dokumentenspeicher, Parser, Embedding-Modell, Vektordatenbank, Sprachmodell, Identitätsdienst, Monitoring und externe Werkzeuge kombinieren. Wer nur den Modellanbieter bewertet, übersieht einen großen Teil des Lock-in-Risikos.
| Ebene | Kernfrage | Belastbarer Nachweis |
|---|---|---|
| Zweck und Kritikalität | Welche Folgen haben Ausfall, Fehlentscheidung oder Kontrollverlust? | Schutzbedarfs- und Wirkungsanalyse, definierte Ausfalltoleranz |
| Daten | Wer kann Eingaben, Trainingsdaten, Embeddings, Logs und Ausgaben lesen, nutzen oder löschen? | Datenflussplan, Löschtest, Zugriffsnachweise, Schlüsselkonzept |
| Modell | Können Modell, Version oder Anbieter ersetzt und Ergebnisse neu validiert werden? | Modellregister, eigene Testfälle, dokumentierter Austauschversuch |
| Anwendung und Schnittstellen | Sind Prompts, Werkzeuge, Workflows und Richtlinien portabel oder proprietär gebunden? | versionierte Konfiguration, offene Formate, dokumentierte APIs |
| Infrastruktur und Rechtsraum | Wo wird verarbeitet und welcher Rechtsordnung unterliegen Anbieter und Unterauftragnehmer? | Vertrags- und Subprozessorenprüfung, Region- und Jurisdiktionsnachweis |
| Betrieb und Kompetenzen | Kann das Unternehmen das System überwachen, absichern, ändern und notfalls übernehmen? | Runbooks, Rollen, internes Know-how, Notfall- und Wiederanlauftest |
| Lieferkette und Wirtschaftlichkeit | Welche kritischen Komponenten, Lizenzen, Hardware- oder Supportleistungen haben keine Alternative? | Komponentenregister, Lizenzprüfung, Exit-Kosten und Ersatzoptionen |
Diese Ebenen hängen zusammen. Ein offen verfügbares Modell kann auf einer proprietären GPU- und Orchestrierungsumgebung schwer portierbar sein. Eine europäische Cloud kann einen nicht-europäischen Modellendpunkt aufrufen. Ein lokaler Betrieb schützt Datenflüsse, schafft aber neue Abhängigkeit von wenigen internen Spezialisten.
Vier Betriebsmodelle – und ihre typischen Zielkonflikte
| Betriebsmodell | Typischer Vorteil | Typische Souveränitätslücke | Sinnvoll, wenn … |
|---|---|---|---|
| KI-SaaS als fertige Anwendung | schnellster Nutzen, geringer Betriebsaufwand | geringe Kontrolle über Modell und Produktlogik | Daten und Prozesswirkung begrenzt sind und ein Ersatzprodukt realistisch ist |
| Eigene Anwendung mit externer Modell-API | Kontrolle über Oberfläche, Datenlogik und Integration | Abhängigkeit von Modell-API, Preis und Anbieterregeln | Modellzugriff abstrahiert und Datenfluss vertraglich geklärt ist |
| Portables Modell auf gemanagter Infrastruktur | mehr Modell- und Datenkontrolle bei ausgelagertem Betrieb | Bindung an Cloud-, GPU- und Orchestrierungsdienste | ein AI-/Plattformteam vorhanden ist, aber kein vollständiger Eigenbetrieb gewünscht wird |
| Eigenbetrieb auf kontrollierter Infrastruktur | höchste technische und betriebliche Kontrolle | höchste Betriebs-, Sicherheits- und Kompetenzlast | Ausfall oder externer Zugriff besonders kritisch wäre und die Organisation den Betrieb beherrscht |
Keines dieser Modelle ist pauschal überlegen. Entscheidend sind möglicher Schaden, Reversibilität und verfügbare Kompetenzen.
Souveränität nach Risiko staffeln
| Stufe | Geeignet für | Mindestanforderungen |
|---|---|---|
| Basis | unkritische, gut reversible Assistenzfunktionen | freigegebene Nutzung, Datenregeln, regulärer Export, Kündigungsrecht, manueller Ersatzprozess |
| Standard | produktive KI in wichtigen Geschäftsprozessen | entkoppelte Modellschicht, eigene Evaluationen, Datenflussplan, zentrale Identitäten, Monitoring und erprobter Export |
| Erhöht | sensible, regulierte oder betriebsentscheidende Systeme | Jurisdiktions- und Lieferkettenprüfung, kundenseitig kontrollierte Schlüssel, technische Limits, getesteter Wechsel, vertieftes Red Teaming |
Die Einstufung folgt Wirkung und Schaden, nicht allein der Unternehmensgröße. Ein kleines Medizintechnikunternehmen kann höhere Anforderungen haben als ein Großunternehmen mit einem internen Textassistenten.
1. Datensouveränität: mehr als „Daten bleiben in Europa“
Der physische Speicherort ist wichtig, beantwortet aber nicht alle Kontrollfragen. Unternehmen müssen klären:
- Werden Eingaben oder Ausgaben für Training, Qualitätssicherung oder Missbrauchserkennung weiterverwendet?
- Welche Metadaten, Protokolle und Zugriffe entstehen bei Anbieter und Unterauftragnehmern?
- Wer hält die Schlüssel, und könnte der Anbieter Daten technisch entschlüsseln?
- Lassen sich Daten, Embeddings, Fine-Tuning-Artefakte und Backups nach Vertragsende nachweisbar löschen?
Das Cloud Sovereignty Framework der EU-Kommission behandelt deshalb nicht nur den Ort der Verarbeitung. Es fragt unter anderem nach wirksamer Kontrolle kryptografischer Zugriffe, Auditierbarkeit, irreversibler Löschung und Drittstaatenbezug.
Datensouveränität ist nicht gleich Datenschutzkonformität. Die Datenschutzkonferenz empfiehlt, Datenschutz über Design, Entwicklung, Einführung, Betrieb und Monitoring hinweg mitzudenken. Ein in Deutschland betriebener Dienst kann dennoch rechtswidrig eingesetzt werden; ein externer Dienst ist nicht automatisch unzulässig.
2. Modellsouveränität: austauschbar ist nicht identisch
Ein Modellwechsel ist kein einfacher Steckertausch. Antwortstil, Tokenisierung, Sicherheitsfilter, Werkzeugaufrufe, Latenz und Kosten verändern sich; ein neues Embedding-Modell kann sogar die Neuindexierung des Dokumentbestands erfordern.
Modellsouveränität setzt daher zwei Dinge voraus:
- Technische Entkopplung: Die Anwendung nutzt eine klar definierte Modellschicht statt anbieterspezifische Funktionen im gesamten Prozess zu verteilen.
- Eigene Bewertungskompetenz: Das Unternehmen besitzt repräsentative Testfälle und kann feststellen, ob ein Ersatzmodell für den konkreten Prozess genügt.
Eine API-Abstraktion ohne Evaluation schafft nur theoretische Portabilität. Umgekehrt kann ein proprietäres Modell ausreichend souverän genutzt werden, wenn der Use Case unkritisch ist, Datenflüsse beherrscht werden und ein realistischer Ausweichpfad existiert.
3. Technologische Souveränität: offen heißt noch nicht unabhängig
Open-Source-Software und Open-Weight-Modelle können Auditierbarkeit, Anpassbarkeit und Anbieterwechsel erleichtern. Sie sind deshalb wichtige Bausteine. Drei Prüfungen bleiben trotzdem nötig:
- Rechte: Erlaubt die konkrete Lizenz Nutzung, Veränderung, Weitergabe und kommerziellen Betrieb?
- Vollständigkeit: Sind nur Gewichte verfügbar oder auch Code, Dokumentation, Tokenizer und Evaluationswerkzeuge?
- Betriebsfähigkeit: Gibt es Hardware, Fachpersonal, Sicherheitsupdates und Support, um die Lösung langfristig zu tragen?
Open Source verlagert Verantwortung. Fehlen Betriebsfähigkeit und Kompetenzen, ersetzt ein Unternehmen den Anbieter-Lock-in lediglich durch Personal-, Hardware- oder Integrationsabhängigkeit.
4. Betriebssouveränität: Wer kann am Montagmorgen handeln?
Selbst gehostete Software hilft wenig, wenn nur ein externer Dienstleister die Architektur versteht. Ein souveräner Betrieb braucht mindestens:
- dokumentierte Deployment- und Wiederanlaufverfahren,
- kontrollierte Identitäten, Rollen und Schlüssel,
- Monitoring sowie geregelte Patch- und Versionsprozesse,
- klare Verantwortliche und eine Alternative für kritische Komponenten.
Die entscheidende Frage lautet nicht „Könnten wir den Quellcode bekommen?“, sondern „Könnten wir das System unter Zeitdruck sicher weiterbetreiben oder ersetzen?“
5. Vertragliche Souveränität: Ein Exit braucht Rechte und Technik
Der EU Data Act stärkt die Wechselmöglichkeiten bei Datenverarbeitungsdiensten. Verträge müssen unter anderem Export, Übergangsfristen, Wechselunterstützung und Löschung regeln; ab dem 12. Januar 2027 dürfen grundsätzlich keine Wechselentgelte mehr verlangt werden. Der Data Act erleichtert den Wechsel wirtschaftlich und vertraglich, garantiert aber weder technisch identische Funktionen noch eine verlustfreie Migration komplexer KI-Workflows.
Unternehmen sollten deshalb bereits bei der Beschaffung festlegen, welche Artefakte herausgegeben werden müssen:
- Eingaben und Ausgaben einschließlich notwendiger Metadaten,
- Systemprompts, Vorlagen und Richtlinien,
- RAG-Dokumente, Chunks, Metadaten und Berechtigungen,
- Fine-Tuning-, Evaluations- und Konfigurationsartefakte, soweit verfügbar,
- Audit-, Kosten- und Betriebsprotokolle.
Ein Vertrag ohne technische Exportprobe bleibt eine Hoffnung. Eine Exportfunktion ohne vertragliches Nutzungsrecht bleibt ein Risiko.
Praxisbeispiel: Der RAG-Assistent eines Maschinenbauers
Hypothetisches, aber realistisches Szenario: Ein mittelständischer Maschinenbauer entwickelt einen Assistenten für Servicetechniker. Der Pilot durchsucht Handbücher, Wartungsberichte und kundenspezifische Anlagenakten über eine Modell-API und eine gemanagte Vektordatenbank. Vor dem Produktivstart werden vier Probleme sichtbar:
- In Wartungsberichten stehen Kunden- und Maschinendaten, deren Verarbeitung und Löschung nicht durchgängig dokumentiert sind.
- Die Anwendung nutzt proprietäre Funktionen des Modellanbieters direkt in mehreren Workflows.
- Es gibt keine eigenen Testfälle, mit denen ein alternatives Modell fachlich bewertet werden könnte.
- Prompts und Indexkonfiguration liegen teilweise nur in der Umgebung des Implementierungspartners.
Eine vollständige Rückverlagerung ins eigene Rechenzentrum wäre nicht zwingend die beste erste Maßnahme. Ein risikogerechter Standardpfad:
- Dokumente, Berechtigungen und Vektorspeicher verbleiben in einer kontrollierten europäischen Umgebung.
- Der Modellzugriff wird über eine eigene, klar dokumentierte Schnittstelle geführt.
- Prompts, Tool-Schemata und Konfigurationen werden versioniert im Verantwortungsbereich des Unternehmens gespeichert.
- Service, Datenschutz und Informationssicherheit testen veraltete Dokumente, falsche Berechtigungen und gezielte Prompt Injection.
- Ein zweites Modell wird in einem wiederholbaren Austauschtest bewertet.
- Vertraglich werden Export, Löschung, Subprozessoren, Modelländerungen und Fristen für den Exit geregelt.
Der Maschinenbauer nutzt weiterhin externe Infrastruktur und Modelle, kann seine Abhängigkeit aber begrenzen und bei Bedarf wechseln. Genau das ist praktische Souveränität.
Der Fünf-Fragen-Schnellcheck
Ein Projektteam sollte vor der nächsten Architektur- oder Beschaffungsentscheidung fünf Fragen beantworten können:
- Ausfall: Welcher Geschäftsprozess steht, wenn Modell oder Anbieter 30 Tage nicht verfügbar sind?
- Daten: Können wir alle relevanten Daten und Artefakte vollständig exportieren und nachweisbar löschen lassen?
- Wechsel: Haben wir ein Ersatzmodell oder einen Ersatzdienst mit eigenen Testfällen tatsächlich geprüft?
- Kontrolle: Wer kontrolliert Identitäten, Schlüssel, Protokolle, Prompts und Richtlinien?
- Kompetenz: Können eigene Mitarbeitende Architektur, Qualität, Sicherheit und Exit fachlich beurteilen?
Zwei oder mehr unbeantwortete Fragen sind kein automatisches Stoppsignal. Sie zeigen aber, dass der Pilot Souveränitätsschulden aufbaut, die vor einer breiten Produktivsetzung bewertet und bewusst akzeptiert oder reduziert werden müssen.
Schnellcheck intern einsetzen
Übernehmen Sie diese fünf Fragen in den nächsten Architekturentscheid, Beschaffungsvermerk oder Projekt-Gate. Dokumentieren Sie zu jeder Antwort Nachweis, Verantwortlichen und offene Maßnahme. So wird aus dem Schnellcheck ein wiederholbares Steuerungsinstrument.
Souveränitätsschulden bewusst begrenzen
Ein Pilot darf Abkürzungen nehmen. Problematisch wird es, wenn Betriebswissen nur beim Dienstleister liegt, Workflows nicht exportierbar sind, Datenflüsse unklar bleiben oder niemand den Exit finanziert. Solche Souveränitätsschulden müssen im Projektregister sichtbar sein, einen Eigentümer und einen Entscheidungstermin haben.
Zusätzliche Kontrolle ist allerdings nicht kostenlos: Abstraktionsschichten verzögern neue Modellfunktionen, Multi-Provider-Architekturen erhöhen den Testaufwand und Self-Hosting bindet Fachkräfte. Deshalb ist maximale Souveränität kein Standardziel. Entscheidend ist die Frage:
Welche Abhängigkeit könnte unsere Handlungsfähigkeit ernsthaft beeinträchtigen – und welche Kontrolle ist diesen Schaden wert?
Auch die bewusste Akzeptanz einer Abhängigkeit kann souverän sein, wenn Nutzen, Laufzeit, Restschaden und Notbetrieb dokumentiert sind.
Was der EU AI Act mit Souveränität zu tun hat – und was nicht
Seit August 2026 gelten weitere zentrale Teile des EU AI Act, darunter Transparenzpflichten für bestimmte Systeme. Die meisten Anforderungen für Hochrisiko-KI-Systeme gelten jedoch erst zu späteren Stichtagen des aktualisierten Umsetzungszeitplans. Unternehmen müssen deshalb ihren konkreten Use Case, ihre Rolle und den jeweiligen Pflichtenkatalog prüfen.
Compliance und Souveränität überschneiden sich, sind aber nicht identisch:
- Ein rechtskonformes KI-System kann stark von einem einzigen Anbieter abhängen.
- Ein selbst gehostetes, offenes System kann gegen Datenschutz- oder AI-Act-Pflichten verstoßen.
- Gute Souveränitätsarchitektur erleichtert Compliance, weil Datenflüsse, Verantwortlichkeiten, Versionen und Kontrollen sichtbar werden.
Die regulatorische Prüfung fragt: Dürfen und beherrschen wir diesen Einsatz? Die Souveränitätsprüfung ergänzt: Bleiben wir auch morgen noch entscheidungs- und handlungsfähig?
Ein realistischer 90-Tage-Plan
| Zeitraum | Ziel | Maßnahmen |
|---|---|---|
| Tage 1–30 | Abhängigkeiten sichtbar machen | Projekte und Anbieter erfassen; Daten, Endpunkte, Unterauftragnehmer und Rechtsräume dokumentieren; Ausfallwirkung bewerten; Souveränitätsschulden zuweisen |
| Tage 31–60 | Zielniveau und Beschaffung schärfen | Projekte einstufen; Export, Löschung, Artefaktrechte, Modelländerungen, Support und Exit verbindlich regeln |
| Tage 61–90 | Wechsel und Wiederanlauf testen | Daten und Konfiguration exportieren; einen Workflow mit Ersatzmodell prüfen; Qualitäts-, Sicherheits- und Berechtigungslücken bewerten |
Der wertvollste Output dieser 90 Tage ist kein allgemeines Souveränitätslabel. Es ist eine priorisierte Liste kritischer Abhängigkeiten mit belastbaren Entscheidungen: reduzieren, absichern, akzeptieren oder ersetzen.
Rollen: Wer digitale Souveränität im Projekt verantwortet
Souveränität darf nicht als zusätzliche Checkbox bei Datenschutz oder Einkauf enden. Die Verantwortung ist verteilt:
| Rolle | Verantwortung |
|---|---|
| Business Sponsor | akzeptiert Nutzen, Restabhängigkeit und Ausfallrisiko |
| Product Owner | hält Use Case, Wirkung, manuelle Alternative und Qualitätsgrenzen zusammen |
| AI-/Plattformteam | entkoppelt Komponenten, versioniert Artefakte und ermöglicht Tests |
| Informationssicherheit und Datenschutz | prüfen Datenflüsse, Zugriff, Protokollierung, Löschung und Angriffsszenarien |
| Einkauf und Legal | sichern Rechte, Transparenz, Wechsel, Support und Exit vertraglich ab |
| Fachbereich | liefert reale Testfälle und entscheidet, wann ein Ersatz fachlich genügt |
Ohne Sponsor bleibt der Exit unfinanziert. Ohne Fachbereich ist Modellportabilität nur technisch. Ohne Plattformwissen wird Open Source zur neuen Abhängigkeit. Souveränität entsteht erst, wenn diese Perspektiven in einer gemeinsamen Entscheidung zusammenkommen.
Weiterführende Artikel auf AI-Fabrik
- Soofi S im Unternehmen: Wie souverän ist Europas neues KI-Modell?
- EU Cloud Sovereignty Framework: Was Unternehmen jetzt wissen müssen
- Datenschutz & KI-Recht: DSGVO, EU AI Act & Datensouveränität
- KI-Kennzeichnung ab August 2026: Was Unternehmen nach Artikel 50 jetzt umsetzen müssen
Fazit: Souverän ist, wer wechseln, gestalten und weiterarbeiten kann
Digitale Souveränität ist weder ein Herkunftssiegel noch ein Plädoyer gegen Cloud oder proprietäre Modelle. Unternehmen müssen wechseln, selbst gestalten und genügend Einfluss auf Anbieter behalten können. Datenstandort, Open Source und europäische Infrastruktur helfen nur, wenn Verträge, Architektur, Kompetenzen und Betrieb gemeinsam realen Handlungsspielraum schaffen.
Der nächste Schritt ist deshalb kein pauschaler Technologiewechsel. Wählen Sie das wichtigste produktive KI-Projekt aus und führen Sie einen dokumentierten Exit-Test durch. Was sich dabei nicht exportieren, erklären, ersetzen oder weiterbetreiben lässt, ist die tatsächliche Souveränitätslücke.
Quellen
- Bundesministerium für Digitales und Staatsmodernisierung: Digitale Souveränität und große Sprachmodelle in der Bundesverwaltung, Studie des Kompetenzzentrums Öffentliche IT/Fraunhofer FOKUS, November 2025.
- Bundesministerium für Digitales und Staatsmodernisierung: Deutschland und Frankreich präsentieren gemeinsame Definition von digitaler Souveränität, Juni 2026.
- Europäische Kommission: Sovereign Cloud Framework explained, 1. Juni 2026.
- Europäische Kommission: Cloud Sovereignty Framework – Implementation Guidance, 2026.
- EUR-Lex: Verordnung (EU) 2023/2854 – Data Act, insbesondere Kapitel VI zum Wechsel zwischen Datenverarbeitungsdiensten.
- Datenschutzkonferenz: Orientierungshilfe zu empfohlenen technischen und organisatorischen Maßnahmen bei der Entwicklung und beim Betrieb von KI-Systemen, Version 1.0, Juni 2025.
- BSI: AI Cloud Service Compliance Criteria Catalogue (AIC4), Kriterien für die Sicherheit cloudbasierter KI-Dienste über den Lebenszyklus.
- Europäische Kommission: Zeitplan zur Umsetzung des EU AI Act, abgerufen am 18. August 2026.
