AI Shoring trifft KRITIS: Digitale Souveränität als Sourcing-Strategie

Ein Network Operations Centre unterstützt einen kritischen Service. Ein Managed Service Provider betreibt die Umgebung; Architektur- und Engineering-Verantwortung sowie ein verantwortlicher Service Owner bleiben beim Kunden.

Ein AI-Agent verknüpft Alarme, ermittelt Service-Abhängigkeiten und bereitet Wiederherstellungsmaßnahmen vor. Dann fällt sein externer Modelldienst aus.

Die Firewalls laufen weiter. Der Datenverkehr fließt. Doch eine zusätzliche, davon unabhängige Verbindungsstörung erfordert einen Eingriff – und der gewohnte Diagnoseablauf funktioniert nicht mehr.

Kann das zuständige Team den betroffenen Service erkennen, auf aktuelle Konfigurationen zugreifen und die Verbindung ohne den Agenten auf einem autorisierten Weg wiederherstellen?

Dieses Beispielszenario führt die Argumentation der Serie weiter. Im AI-Shored NOC habe ich AI-gestützte Analyse, Policy-Prüfung, kontrollierte Ausführung und Service Assurance voneinander getrennt. „Wem gehört das Wissen?“ hat gezeigt, warum die Beziehungen zwischen Infrastruktur, Anwendungen und Service-Ergebnissen auch außerhalb der Provider-Workbench nutzbar bleiben müssen.

Jetzt folgt die Bewährungsprobe im Betrieb: Können das Unternehmen und seine Dienstleister dieses Wissen anwenden, wenn eine Abhängigkeit ausfällt?

AI Shoring wird zur Strategie für digitale Souveränität, wenn es die Fähigkeit des Kunden stärkt, kritische Services zu steuern, aufrechtzuerhalten und wiederherzustellen – auch bei Ausfall einer AI-Abhängigkeit.

Souveränität muss im Betrieb konkret werden

Operative Souveränität bedeutet hier: Das Unternehmen verfügt über ausreichend Wissen, Entscheidungsbefugnis und praktische Fähigkeiten, um fundiert zu entscheiden, Störungen zu bewältigen und Anbieter zu wechseln. Sie ist eine Dimension digitaler Souveränität. Fragen der Rechtsordnung, des Datenzugriffs und technologischer Abhängigkeiten gehören ebenfalls dazu.

Diese Fähigkeiten können interne Spezialisten, externe Partner und Automation gemeinsam bereitstellen. Architektur, Risikoakzeptanz und Service-Verantwortung bleiben beim Kunden. Ein Provider kann weiterhin die Plattformen betreiben und autorisierte Wiederherstellungsmaßnahmen ausführen.

Entscheidend ist eine belastbare Vorsorge für die vorgesehenen Ausfallszenarien. Der Ausfall eines Modelldienstes und der Wegfall des gesamten Betriebsproviders sind unterschiedliche Situationen. Sie stellen unterschiedliche Anforderungen an Personal, Zugänge und Übergangsprozesse.

Drei regulatorische Perspektiven auf dieselbe Betriebsumgebung

Im KRITIS-Umfeld treffen drei regulatorische Perspektiven aufeinander. Ihre Anwendungsbereiche überschneiden sich; die jeweiligen Pflichten müssen dennoch getrennt geprüft werden.

NIS2 adressiert das Management von Cybersicherheitsrisiken. Artikel 21 umfasst unter anderem die Bewältigung von Sicherheitsvorfällen, die Aufrechterhaltung des Betriebs und die Sicherheit der Lieferkette. Artikel 20 weist den Leitungsorganen Genehmigungs- und Überwachungsaufgaben zu. Das deutsche Umsetzungsgesetz ist am 6. Dezember 2025 in Kraft getreten. Für das Sourcing bedeutet das: Lieferantenabhängigkeiten gehören in die Risikobewertung und damit auch über den kaufmännischen Angebotsvergleich hinaus betrachtet. [1, 2]

Das KRITIS-Dachgesetz adressiert die physische Resilienz. Es ist am 17. März 2026 in Kraft getreten; Umsetzungsschritte und einzelne Pflichten sind gesondert zu berücksichtigen. Für die Telekommunikationsperspektive dieser Serie ist besonders wichtig: § 4 Absatz 2 nimmt Betreiber kritischer Anlagen im Sektor Informationstechnik und Telekommunikation von mehreren Vorschriften aus, darunter §§ 12–16. Die Betreiberpflichten zur Resilienz dürfen deshalb nicht pauschal auf jeden KRITIS-Sektor übertragen werden. Physische Abhängigkeiten bleiben für den Betrieb relevant; die konkreten rechtlichen Pflichten erfordern eine sektorspezifische Prüfung. [3]

Der EU AI Act betrachtet Zweckbestimmung und Rolle des AI-Systems. Anhang III Nummer 2 erfasst bestimmte Sicherheitsbauteile in kritischer digitaler Infrastruktur, im Straßenverkehr sowie in bestimmten Versorgungsbereichen. Allein der Einsatz bei einem KRITIS-Betreiber macht ein AI-System noch nicht zum Hochrisikosystem. Maßgeblich ist die Einordnung nach Artikel 6. Nach dem am 18. Oktober 2026 geprüften konsolidierten Text gelten die einschlägigen Anforderungen aus Kapitel III Abschnitten 1–3 für Hochrisikosysteme nach Anhang III grundsätzlich ab dem 2. Dezember 2027, mit Ausnahme von Artikel 6 Absatz 5. Für andere Regelungen gelten andere Termine. [4]

Aus diesen Regelwerken folgt kein einheitliches Hosting- oder Sourcing-Modell. Meine architektonische Schlussfolgerung lautet: Verantwortung muss mit den Informationen, Befugnissen und Fähigkeiten verbunden bleiben, die für ihre Wahrnehmung erforderlich sind.

Der Standort ist ein Teil der Kontrolle

Wo ein AI-Service betrieben wird, ist relevant. Rechtsordnung, Datenzugriff, Hosting-Vereinbarungen und mögliche Zugriffe externer Behörden können eine Sourcing-Entscheidung maßgeblich beeinflussen.

Operative Kontrolle hängt zusätzlich davon ab, was nach der Einführung tatsächlich funktioniert.

Auch ein lokal betriebenes Modell kann von einem externen Identitätsdienst, einer proprietären Orchestrierungsplattform oder Wissen abhängen, das nur der Service Provider interpretieren kann. Ein externer Anbieter kann dagegen zu einem resilienten Service beitragen, wenn Verantwortlichkeiten, Zugriffsrechte, Kontinuitätsvorkehrungen und Ausstiegsmöglichkeiten nachweislich funktionieren.

Die Bewertung muss deshalb die gesamte Kette umfassen: Modell, Agent, Werkzeuge, Identitäten, Wissensquellen, Ausführungsplattform und verantwortliche Menschen.

Ein zweiter Modellendpunkt hilft wenig, wenn beide Alternativen dasselbe ausgefallene Zugangsgateway oder dieselbe Orchestrierung benötigen. Wirksame Redundanz setzt voraus, gemeinsame Abhängigkeiten zu verstehen.

Agenten brauchen klar begrenzte Befugnisse

Welche Folgen ein AI-Ausfall hat, hängt von den Befugnissen des Agenten und dem unterstützten Service ab.

Der AI-Ready Contract hat dafür sechs Autonomieklassen eingeführt: A0 Beobachten, A1 Empfehlen, A2 Vorbereiten, A3 Ausführen mit Freigabe, A4 Autonome Ausführung risikoarmer Aktionen und A5 Vorab autorisierte Notfallmaßnahmen. Sie bleiben das Arbeitsmodell dieser Serie. Es handelt sich um architektonische und vertragliche Kategorien, nicht um rechtliche Risikoklassen.

Der Kunde legt fest, welche Anwendungsfälle welcher Klasse zugeordnet werden. Standardisierte, getestete Aktionen dürfen innerhalb vorab genehmigter Grenzen ablaufen. Ausnahmen benötigen das passende menschliche Urteil. A5 erlaubt ausschließlich eng definierte Notfallmaßnahmen und keine allgemeine Umgehung von Kontrollen.

Ein Modellausfall muss den vereinbarten Ersatzbetrieb für den jeweiligen Anwendungsfall auslösen. Er darf weder unbemerkt die Rechte eines Agenten erweitern noch eine erforderliche Freigabe aufheben.

Die gemeinsame Leitlinie zur Integration von AI in Operational Technology von CISA, ASD’s ACSC und internationalen Partnern einschließlich des BSI bietet dafür einen hilfreichen Bezugspunkt. Sie betont menschliche Aufsicht, Tests, klare Verantwortlichkeiten und Mechanismen für einen sicheren Fehlerzustand. Auch der Verlust menschlicher Fähigkeiten durch übermäßige Abhängigkeit von Automation wird adressiert. Ihr unmittelbarer Geltungsbereich ist OT; die Übertragung auf ein breiteres NOC-Umfeld erfordert fachliche Abwägung. [5]

Für einen Firewall-Prozess bleibt die Trennung eindeutig: Das Modell schlägt vor, deterministische Kontrollen prüfen, eine separate Ausführungsebene handelt mit begrenzten Rechten. Der Nachweis muss Anfrage, relevante Eingaben, Policy-Ergebnisse, Freigaben und tatsächliche Auswirkungen miteinander verbinden. Eine plausible Erklärung des Modells ersetzt diese Beweiskette nicht.

Den Ersatzbetrieb vor dem Ausfall entwerfen

Zurück zum Eingangsszenario.

Das Team muss auf freigegebene Konfigurationen, aktuelle Telemetrie, Service-Abhängigkeiten und Wiederherstellungsverfahren zugreifen können, ohne die ausgefallene AI-Oberfläche zu benötigen. Ein autorisierter Engineer – intern oder aus dem vertraglich eingebundenen Betriebsteam – braucht einen funktionierenden Zugang und Klarheit über zulässige Eingriffe. Rechte, ausreichende personelle Kapazität und Eskalationsbefugnisse müssen vorher vereinbart sein.

Ohne AI muss nicht dieselbe Produktivität erreicht werden. Ein belastbarer eingeschränkter Betrieb kann unwesentliche Änderungen aussetzen, kritische Services priorisieren und für einen begrenzten Umfang von Eingriffen auf etablierte Verfahren zurückgreifen.

Bei manchen Systemen ist es richtig, Aktivitäten anzuhalten oder einen definierten sicheren Zustand herzustellen. Maßgeblich sind die Sicherheits- und Kontinuitätsanforderungen des jeweiligen Services.

Die Gestaltung wird damit konkret: Was bleibt verfügbar? Wer übernimmt? Was muss stoppen? Und wie wird die Wiederherstellung nachgewiesen?

Dazu gehört eine Prüfung auf Service-Ebene. Eine Firewall, die eine Konfiguration akzeptiert, bestätigt zunächst nur einen Infrastrukturzustand. Die betroffene Anwendungsinteraktion muss wieder funktionieren. Das beabsichtigte Ende-zu-Ende-Ergebnis muss nachgewiesen werden, ohne den Zugriff über die genehmigten Sicherheitsgrenzen hinaus auszuweiten.

Abbildung 1 zeigt eine freigabepflichtige Änderung, im Normalbetrieb entsprechend A3. Daraus folgt keine manuelle Freigabepflicht für jede standardisierte A4-Aktion. Beide Wege behalten ihre Policy-Kontrollen. Ausgefallen ist hier die AI-Abhängigkeit; die unterstützenden Zugangs- und Ausführungssysteme bleiben verfügbar.

Dieser Ablauf muss geübt werden. Ein Runbook schützt wenig, wenn das Team es im Störungsfall nicht finden, verstehen oder ausführen kann.

Abbildung 1: Ein freigabepflichtiger Ablauf mit und ohne AI-Unterstützung. Der autorisierte Engineer kann zum Kunden oder zum beauftragten Betriebsteam gehören. Zugänge und Kontrollsysteme müssen weiterhin funktionieren; Anwendungs- und Service-Prüfungen bestätigen die Wiederherstellung.

Die Fähigkeit zu entscheiden erhalten

AI Shoring verbindet menschliche Expertise mit AI-gestützter Ausführung. Sein strategischer Wert hängt davon ab, wie diese Verbindung die Fähigkeiten der Organisation verändert.

Wenn Engineers immer häufiger Antworten erhalten, ohne den zugrunde liegenden Service zu verstehen, verliert die Organisation möglicherweise schleichend die Fähigkeit, Empfehlungen zu hinterfragen oder ohne die gewohnte AI-Unterstützung wiederherzustellen.

Helfen Agenten dagegen dabei, Abhängigkeiten zu untersuchen, Handlungsoptionen zu vergleichen und bestätigte Erkenntnisse in einer vom Unternehmen kontrollierten Wissensschicht festzuhalten, können sie die interne Kompetenz stärken. Jede Erkenntnis braucht Herkunftsnachweise, Prüfung und Versionierung, bevor sie zu verlässlichem Kontext wird. Das ist derselbe Wissenskreislauf wie im vorherigen Artikel. Ein automatisches Nachtrainieren des zugrunde liegenden Modells ist dafür nicht erforderlich.

Architektur und Engineering bleiben überwiegend im Unternehmen. Ein benannter Service Owner verantwortet das Ende-zu-Ende-Ergebnis. Der Provider kann Spezialwissen beisteuern und die gemeinsame Workbench betreiben. Das verbleibende interne Team muss Empfehlungen beurteilen, Prioritäten für die Wiederherstellung setzen und vorgelegte Nachweise bewerten können.

Diese Fähigkeiten brauchen Zeit und Praxis: die Nachbereitung von Vorfällen, Wiederherstellungsübungen und Engineering-Arbeit, durch die Menschen mit den von ihnen verantworteten Systemen vertraut bleiben.

Operative Souveränität im Sourcing-Vertrag verankern

Der Einkauf kann diese Erwartungen überprüfbar machen.

Für einen AI-gestützten Infrastrukturservice würde ich Anbieter um Nachweise für folgende Punkte bitten:

• Nutzbare Export- und Weiterverwendungsrechte für kundenspezifisches Service-Wissen, Policies, Konfigurationen, Diagnoseabläufe und Entscheidungsnachweise.
• Dokumentierte Abhängigkeiten zwischen Modellen, Werkzeugen, Identitäten und unterstützenden Diensten.
• Unabhängig nutzbare Möglichkeiten, Agentenaktionen zu stoppen, sowie benannte Verantwortlichkeiten, Zugänge und personelle Kapazitäten für die Wiederherstellung.
• Getestete Kontinuitätsverfahren beim Ausfall des Modells oder der Agentenplattform.
• Ein praktikabler Übergangsprozess einschließlich des Wissens und der Unterstützung, die ein übernehmendes Team benötigt.

Die NIS2 Technical Implementation Guidance der ENISA bietet praktische Hinweise und Beispiele für Nachweise für bestimmte Anbieter digitaler Infrastrukturen und Dienste. Ihr definierter Anwendungsbereich ist zu beachten. Der Fokus auf belegbare Umsetzung hilft zugleich bei der Gestaltung von Lieferantengesprächen. [6]

Auch der EU Data Act adressiert Wechselhindernisse bei Datenverarbeitungsdiensten. Das unterstützt die Sourcing-Diskussion. Ob ein konkreter AI-Workflow übertragbar ist, muss dennoch technisch und vertraglich geprüft werden. Der Zugriff auf exportierte Daten beweist noch nicht, dass ein anderes Team den Service betreiben kann. [7]

Dafür sind zwei getrennte Abnahmeübungen sinnvoll.

Erstens: Wiederherstellung bei Ausfall einer AI-Abhängigkeit. In einer kontrollierten Testumgebung wird die Modellabhängigkeit abgeschaltet. Das verantwortliche Team stellt eine repräsentative Anwendungsinteraktion innerhalb der vereinbarten Sicherheitsgrenzen wieder her. Gemessen werden die Zeit bis zu einem nachgewiesenen sicheren Zustand, nicht erreichte Service-Ergebnisse sowie fehlende Zugänge oder Wissensbestände. Das führt die Ergebnisorientierung aus „Vom Service Level zum Decision Level“ weiter.

Zweitens: Übernahme außerhalb der bisherigen Workbench. Ein internes oder neues Betriebsteam reproduziert den Wiederherstellungsablauf außerhalb der Umgebung des bisherigen Providers. Dabei wird festgehalten, was rekonstruiert werden muss und welche proprietären Abhängigkeiten bestehen bleiben. Das erweitert den Ausstiegstest des vorherigen Artikels. Ein Providerwechsel dauert in der Regel länger als die Behebung einer Störung. Eine erfolgreiche Übung ersetzt die andere nicht.

Abbildung 2 bündelt die dafür erforderlichen Fähigkeiten: den Service verstehen, ihn durch eine definierte Störung führen und die Betriebsfähigkeit auf einen anderen Provider übertragen.

Abbildung 2: Verstehen, betreiben und den Provider wechseln – drei Fähigkeiten, deren Wirksamkeit sich praktisch nachweisen lassen muss.

Welche Fähigkeit bleiben muss

Am Anfang der Serie stand die Möglichkeit, Infrastrukturkompetenz zurück ins Unternehmen zu bringen, wiederkehrende Tätigkeiten zu automatisieren und spezialisierte Provider weiter einzubinden. Der AI-Shored NOC lieferte das Betriebsmodell. Vom Kunden kontrolliertes Wissen machte dieses Modell übertragbar.

Für kritische Services kommt nun der Nachweis hinzu, dass diese Fähigkeiten eine definierte Störung überstehen. Wir müssen den Service verstehen, einen akzeptablen Betriebszustand erhalten oder wiederherstellen und seinen Betrieb übertragen können, ohne das wesentliche Wissen von Grund auf neu aufzubauen.

Dieses Sourcing-Kriterium geht über den Standort eines Modells oder die Geschwindigkeit einer Ticketantwort hinaus. Es verbindet interne Architekturverantwortung, die Leistung des Providers, kontrollierte Automation und nachgewiesene Service-Ergebnisse.

AI Shoring schafft Souveränität, wenn der Kunde den Service weiterhin verstehen, steuern und wiederherstellen kann – und nachweisen kann, dass sein gewähltes Betriebsmodell diese Fähigkeiten trägt.

Quellen

1. Europäisches Parlament und Rat: Richtlinie (EU) 2022/2555 – NIS2, insbesondere Artikel 20–21.
2. BSI: Informationen zur NIS2-Registrierung und Umsetzung.
3. BBK: FAQ zum KRITIS-Dachgesetz; Gesetzestext, insbesondere § 4 Absatz 2.
4. Europäisches Parlament und Rat: EU AI Act, konsolidierte Fassung vom 27. Juli 2026, insbesondere Artikel 6, Anhang III und Artikel 113.
5. CISA, ASD’s ACSC und internationale Partner einschließlich BSI: Principles for the secure integration of Artificial Intelligence in Operational Technology, 4. Dezember 2025.
6. ENISA: NIS2 Technical Implementation Guidance, 26. Juni 2025.
7. Europäische Kommission: Data Act explained.

Die regulatorischen Bezüge entsprechen dem Prüfstand der englischen Originalfassung vom 18. Oktober 2026. Szenario und Betriebsmodell sind beispielhaft; die konkrete Anwendbarkeit hängt von Unternehmen, Sektor und AI-Anwendungsfall ab. Die drei englisch beschrifteten Seriengrafiken sind mit „AI Generated“ gekennzeichnet.