Zum Inhalt springen
Decision-State-Infrastruktur
ende
Anwendungen

KI in kritischer Infrastruktur

KI IN KRITISCHER INFRASTRUKTUR

Was muss geklärt sein, bevor KI eine Entscheidung in kritischer Infrastruktur beeinflussen darf?

Ein KI-System kann technisch leistungsfähig, umfangreich validiert und gegen Cyberrisiken geprüft sein – und trotzdem noch keinen freigabefähigen Einsatz darstellen.

Denn eine Organisation gibt nicht einfach „die KI“ frei. Sie übernimmt Verantwortung für einen konkreten Einsatz: für eine bestimmte Systemversion, einen bestimmten Zweck und definierte Betriebsgrenzen. Sie muss wissen, welche Anforderungen gelten, welche Nachweise diese Anforderungen tatsächlich tragen, welche Unsicherheit verbleibt, welche Alternativen ernsthaft geprüft wurden, welche Einwände offen sind und wer für welchen Teil des Zustands Verantwortung und Freigabeauthority besitzt.

In diesem illustrativen Fall möchte ein europäischer Übertragungsnetzbetreiber ein hochgesichertes KI-System in die operative Netzsicherheitsanalyse einführen. Grid Security Advisor v4.7 analysiert angespannte Netzzustände und erzeugt priorisierte Kandidaten für mögliche Gegenmaßnahmen. Das System darf selbst keine Schalthandlung, keinen Redispatch und keine andere operative Maßnahme auslösen. Die operative Entscheidung verbleibt beim autorisierten menschlichen Netzführungspersonal.

Technisch ist das System weitgehend bereit. Viele Nachweise liegen vor. Mehrere Anforderungen sind erfüllt. Doch eine wesentliche Unsicherheit ist noch nicht ausreichend behandelt. Die dafür notwendige Evidence ist unvollständig. Eine zuständige Risk-Rolle hat die verbleibende Unsicherheit noch nicht übernommen. Und der beantragte grenzüberschreitende Einsatzumfang kann deshalb noch nicht abgeschlossen werden.

Der Zustand des KI-Systems ist nur ein Teil der Entscheidung.

Der Decision State entsteht erst, wenn Systemzustand, Anforderungen, Nachweise, Unsicherheiten, Alternativen, Verantwortung und Authority zu einem konsistenten Zustand zusammengeführt werden können.

I / DIE ENTSCHEIDUNG

Eine Einsatzfreigabe entscheidet über einen abgegrenzten Zustand – nicht über KI im Allgemeinen

01

Nicht das Modell wird freigegeben. Ein konkreter Decision Space wird freigegeben.

Nehmen wir einen illustrativen europäischen Übertragungsnetzbetreiber. Für diesen Fall nennen wir das betrachtete System Grid Security Advisor v4.7.

Das System unterstützt die operative Netzsicherheitsanalyse. Es verarbeitet einen definierten Netzzustand, relevante Topologieinformationen, geplante Nichtverfügbarkeiten, Prognosen, Contingency-Szenarien und weitere für den Einsatz freigegebene Inputs. Es erzeugt analysierte Risikohinweise und priorisierte Kandidaten für mögliche Gegenmaßnahmen. Es löst keine operative Aktion selbst aus.

Soll Grid Security Advisor v4.7 für den definierten operativen Sicherheitskontext freigegeben werden, sodass autorisiertes Netzführungspersonal seine Analysen und priorisierten Handlungsoptionen als Input für operative Sicherheitsentscheidungen verwenden darf?

Dimension

System

Gegenstand der Entscheidung

Grid Security Advisor v4.7

Dimension

Einsatzzweck

Gegenstand der Entscheidung

Operative Netzsicherheitsunterstützung

Dimension

Operating Boundary

Gegenstand der Entscheidung

Definierte nationale und grenzüberschreitend relevante Situationen

Dimension

AI-Rolle

Gegenstand der Entscheidung

Analyse und Priorisierung, keine operative Aktuation

Dimension

Requirements

Gegenstand der Entscheidung

Regulatorische, operative, Security- und interne Governance-Anforderungen

Dimension

Evidence

Gegenstand der Entscheidung

Nachweise, die diese Anforderungen für genau diesen Einsatz tragen

Dimension

Uncertainty

Gegenstand der Entscheidung

Bekannte und verbleibende Unsicherheit

Dimension

Alternatives

Gegenstand der Entscheidung

Ernsthaft geprüfte alternative Einsatzkonfigurationen

Dimension

Responsibilities

Gegenstand der Entscheidung

Rollen, die einzelne Zustände verantworten

Dimension

Authority

Gegenstand der Entscheidung

Rollen, die prüfen, akzeptieren oder final freigeben dürfen

Dimension

Conditions

Gegenstand der Entscheidung

Grenzen, Monitoring, Fallback und Change Trigger

Die Freigabe gilt also nicht abstrakt für „v4.7“. Sie gilt für einen spezifischen Decision Space.

02

Warum dieser Einsatz strategisch und institutionell relevant ist

Ein europäischer Übertragungsnetzbetreiber arbeitet nicht in einem gewöhnlichen Softwarekontext. Die EU System Operation Guideline verpflichtet TSOs unter anderem zur laufenden Bewertung des Systemzustands und zu Contingency Analyses. TSOs tragen Verantwortung für Operational-Security-Verletzungen und müssen Remedial Actions vorbereiten und aktivieren. Müssen solche Maßnahmen koordiniert werden, erfolgt dies mit anderen betroffenen TSOs.

Primärquelle: EU System Operation Guideline

Damit befindet sich Grid Security Advisor nicht an einer beliebigen Produktivschnittstelle. Sein Output kann eine menschliche Entscheidung beeinflussen, die sich auf Netzsicherheit, mögliche Gegenmaßnahmen und gegebenenfalls grenzüberschreitende Koordination bezieht.

Auch die Cybersecurity-Dimension ist wesentlich. Transmission System Operators gehören unter NIS2 im Elektrizitätssektor zu den Sectors of High Criticality.

Primärquelle: NIS2-Richtlinie

Hinzu kommt der AI Act. Annex III nennt KI-Systeme, die bestimmungsgemäß als Sicherheitskomponenten bei Management und Betrieb kritischer Infrastruktur einschließlich der Stromversorgung eingesetzt werden sollen. Ob ein konkretes System tatsächlich als Hochrisiko-System einzuordnen ist, hängt jedoch von seiner Zweckbestimmung und den anwendbaren Klassifikationsregeln des Artikels 6 ab.

Primärquelle: EU AI Act — konsolidierte Fassung vom 27. Juli 2026

Epistemis entscheidet diese rechtliche Einordnung nicht. Der regulatorische Kontext ist selbst Teil des Decision Space und muss durch die zuständigen Rechts-, Compliance- und Governance-Funktionen bestimmt werden.

03

Was den Decision State tatsächlich bildet

Ein Decision State besteht nicht nur aus einem Modell, einem Testbericht und einer Sammlung von Sign-offs. Für diesen Fall sind neun miteinander verbundene Zustandsdimensionen relevant.

Zustandsdimension

System- und Betriebszustand

Leitfrage

Welches System, welche Version und welche Betriebsgrenze sind tatsächlich Gegenstand der Entscheidung?

Zustandsdimension

Requirements State

Leitfrage

Welche regulatorischen, technischen, organisatorischen und internen Anforderungen gelten?

Zustandsdimension

Evidence State

Leitfrage

Welche Nachweise tragen welche entscheidungsrelevante Aussage – und für welchen Scope?

Zustandsdimension

Uncertainty State

Leitfrage

Welche Unsicherheit bleibt, wurde akzeptiert oder blockiert?

Zustandsdimension

Assumptions State

Leitfrage

Welche Annahmen müssen weiter gelten, damit die Entscheidung tragfähig bleibt?

Zustandsdimension

Alternatives State

Leitfrage

Welche ernsthaften Alternativen wurden betrachtet?

Zustandsdimension

Responsibility State

Leitfrage

Welche Rolle trägt Verantwortung für welchen Teil des Zustands?

Zustandsdimension

Authority State

Leitfrage

Wer darf welchen Zustand prüfen, akzeptieren oder freigeben?

Zustandsdimension

Conflict and Conditions State

Leitfrage

Welche Einwände, Bedingungen oder abweichenden fachlichen Positionen bleiben relevant?

Erst aus der Verbindung dieser Dimensionen entsteht ein geregelter Decision State.

Ein Deployment Decision State verbindet System- und Betriebszustand mit Requirements, Evidence, Unsicherheit, Annahmen, Alternativen, Verantwortlichkeiten, Authority und offenen Einwänden.
SYSTEM / OPERATING STATE
REQUIREMENTS
EVIDENCE
UNCERTAINTY
ASSUMPTIONS
ALTERNATIVES
RESPONSIBILITY
AUTHORITY
OBJECTIONS / CONDITIONS

Verbunden bei T0

Decision State v1

Das KI-System ist ein Input in den Decision State. Es ist nicht der Decision State selbst.

II / AKTUELLER DECISION STATE

Technische Reife kann gleichzeitig mit offenen Nachweisen, Unsicherheit und Authority bestehen

04

Der technische Zustand ist weitgehend geklärt

State

SYSTEM IDENTITY

Zustand

RESOLVED

State

MODEL / SYSTEM VERSION

Zustand

RESOLVED

State

DEPLOYMENT ENVIRONMENT

Zustand

RESOLVED

State

BASELINE PERFORMANCE

Zustand

RESOLVED

State

CYBERSECURITY REVIEW

Zustand

RESOLVED

State

HUMAN OVERSIGHT MODEL

Zustand

RESOLVED

State

OPERATOR TRAINING

Zustand

RESOLVED

State

FALLBACK PATH

Zustand

RESOLVED

State

DIRECT ACTUATION AUTHORITY

Zustand

NONE

State

CROSS-BORDER OPERATIONAL VALIDATION

Zustand

OPEN

Grid Security Advisor v4.7 ist eindeutig identifiziert. Die vorgesehene hochgesicherte Betriebsumgebung ist definiert. Das System besitzt keine direkte Aktuator-Authority. Baseline-Tests und die für diesen illustrativen Decision Space definierten Security-Prüfungen liegen vor. Soweit Pflichten nach Artikel 26 für Hochrisiko-KI-Systeme greifen, müssen Betreiber die menschliche Aufsicht Personen mit notwendiger Kompetenz, Ausbildung und Authority zuweisen.

Primärquelle: EU AI Act — konsolidierte Fassung vom 27. Juli 2026

Technisch sieht der Zustand damit weit fortgeschritten aus. Aber technische Reife ist nicht der Decision State.

05

Ein Requirement ist nicht erfüllt, nur weil ein passendes Dokument existiert

Requirement

Definierte Systemversion

Herkunft im illustrativen Decision Space

Interne AI-/Change-Governance

Zustand

RESOLVED

Requirement

Keine autonome operative Aktuation

Herkunft im illustrativen Decision Space

Interne Authority Boundary

Zustand

RESOLVED

Requirement

Wirksame menschliche Oversight

Herkunft im illustrativen Decision Space

AI Governance / anwendbarer regulatorischer Kontext

Zustand

RESOLVED

Requirement

Gesicherter Deployment-Kontext

Herkunft im illustrativen Decision Space

Security Policy

Zustand

RESOLVED

Requirement

Unabhängiger Fallback

Herkunft im illustrativen Decision Space

Critical-System-Policy

Zustand

RESOLVED

Requirement

Monitoring im Betrieb

Herkunft im illustrativen Decision Space

AI-/Operational-Governance

Zustand

RESOLVED

Requirement

Definierte Change Trigger

Herkunft im illustrativen Decision Space

AI Change Policy

Zustand

RESOLVED

Requirement

Ausreichende Assurance für grenzüberschreitenden Scope

Herkunft im illustrativen Decision Space

Deployment Requirement

Zustand

OPEN

Requirement

Akzeptierbare Residual Uncertainty

Herkunft im illustrativen Decision Space

Risk Governance

Zustand

OPEN

Eine Requirement ist nicht erfüllt, nur weil die Organisation auf ein Dokument mit passendem Titel verweisen kann. Sie muss bestimmen können, welcher Zustand die Requirement tatsächlich erfüllt.

06

Evidence ist nicht die Sammlung vorhandener Dokumente

Der Übertragungsnetzbetreiber kann bereits Model Documentation, technische Validation, Cybersecurity Assessments, ein Human-Oversight-Konzept, Training Records, ein Risk Register, einen Monitoring Plan, Change History und operative Unterlagen besitzen. Der Evidence State stellt eine andere Frage: Welche Aussage über diese konkrete Entscheidung wird durch welchen Nachweis tatsächlich getragen?

Entscheidungsbehauptung

Die freizugebende Version ist eindeutig

Maßgeblicher Nachweis

Versioniertes Deployment Package

Zustand

RESOLVED

Entscheidungsbehauptung

Baseline-Verhalten wurde bewertet

Maßgeblicher Nachweis

Validation Evidence

Zustand

RESOLVED

Entscheidungsbehauptung

Security Boundary wurde geprüft

Maßgeblicher Nachweis

Security Assurance

Zustand

RESOLVED

Entscheidungsbehauptung

Menschlicher Eingriff ist organisatorisch vorgesehen

Maßgeblicher Nachweis

Oversight Model + Training Evidence

Zustand

RESOLVED

Entscheidungsbehauptung

AI-unabhängiger Fallback ist definiert

Maßgeblicher Nachweis

Fallback Test / Procedure Evidence

Zustand

RESOLVED

Entscheidungsbehauptung

Verhalten im vollen grenzüberschreitenden Scope ist ausreichend abgesichert

Maßgeblicher Nachweis

Cross-Border Assurance

Zustand

INCOMPLETE

DOCUMENT EXISTS

≠

EVIDENCE COVERS THE DECISION

Ein Nachweis kann korrekt sein und trotzdem nicht den Scope abdecken, der tatsächlich zur Freigabe vorgeschlagen wird.

07

Strategische Entscheidungen warten nicht, bis jede Unsicherheit verschwunden ist

Die relevante Frage lautet nicht, ob noch Unsicherheit besteht. Sie lautet, welche Unsicherheit verbleibt, wie gut sie verstanden wird, wie wesentlich sie ist und ob sie in diesem Decision Space bewusst bestehen bleiben darf.

Unsicherheit

Verhalten in validierten nationalen Szenarien

Zustand

CHARACTERISED

Unsicherheit

Bekannte Modellgrenzen

Zustand

CHARACTERISED

Unsicherheit

Operator Automation Bias

Zustand

CONTROLLED / MONITORED

Unsicherheit

Zukünftige Drift

Zustand

RESIDUAL / MONITORED

Unsicherheit

Seltene Out-of-Distribution-Zustände

Zustand

CHARACTERISED WITH LIMITS

Unsicherheit

Verhalten in definierten grenzüberschreitenden Stresslagen

Zustand

MATERIAL UNCERTAINTY OPEN

SEAL setzt nicht voraus, dass keine Unsicherheit mehr besteht. Ein gültiger Decision State kann Restunsicherheit enthalten, wenn sie entsprechend den Regeln des Decision Space behandelt wurde und keine blockierende Unsicherheit offen bleibt.

08

Annahmen sind weder Fakten noch Evidence

Die Freigabe von Grid Security Advisor v4.7 kann auf Annahmen beruhen: Netzzustandsdaten bleiben innerhalb definierter Qualitätsgrenzen, autorisierte Datenquellen bleiben verfügbar, die AI bleibt advisory, menschliche Operatoren behalten operative Authority, der unabhängige Fallback bleibt verfügbar, es entsteht keine zusätzliche Aktuatorintegration und definierte Betriebsgrenzen bleiben intakt.

FACT

≠

EVIDENCE

≠

ASSUMPTION

Ein späterer Reviewer muss erkennen können, auf welchen Annahmen die ursprüngliche Freigabe beruhte. Wenn eine wesentliche Annahme später nicht mehr gilt, kann der Decision State nicht mehr derselbe Zustand sein.

09

Eine verantwortbare Entscheidung braucht echte Alternativen

Alternative

A / Full Deployment Scope

Zustand

CURRENT PROPOSAL

Alternative

B / Restricted Domestic Advisory Scope

Zustand

AVAILABLE

Alternative

C / Analysis without Action Ranking

Zustand

AVAILABLE

Alternative

D / Shadow Mode

Zustand

AVAILABLE

Alternative

E / Deployment Postponed

Zustand

AVAILABLE

Das Ziel ist nicht, jede denkbare Option aufzulisten. Relevant ist, welche Alternativen im Decision Space ernsthaft vorhanden waren, welche geprüft wurden und was jede Alternative an Evidence, Requirements, Unsicherheit und Verantwortung verändern würde.

Eine Entscheidung ist später schwer nachvollziehbar, wenn nur die gewählte Option sichtbar bleibt.

10

Verantwortung ist nicht dasselbe wie Freigabeauthority

Rolle

AI System Owner

Illustrative Verantwortung

Systemidentität, Version und Change Management

Rolle

Grid Security Engineering

Illustrative Verantwortung

Technische Netzsicherheitsbewertung

Rolle

Cybersecurity / CISO

Illustrative Verantwortung

Security Assurance

Rolle

AI Governance

Illustrative Verantwortung

Governance-Anforderungen und AI-spezifischer Kontext

Rolle

Enterprise Risk

Illustrative Verantwortung

Risk Position und Behandlung von Restunsicherheit

Rolle

Operations

Illustrative Verantwortung

Operative Verwendbarkeit und Prozessintegration

Rolle

Deployment Approval Body

Illustrative Verantwortung

Freigabe des definierten Deployment Scope

Rolle

Control-Room Operator

Illustrative Verantwortung

Konkrete operative Entscheidung im laufenden Betrieb

Information zu liefern, einen Zustand zu verantworten und finale Freigabeauthority zu besitzen, sind unterschiedliche Funktionen.

11

Contributor, Responsible Role und Approval Authority dürfen nicht vermischt werden

Ein Validation Team kann einen technischen Testbericht erstellen, ohne Authority für die Produktivfreigabe zu besitzen. Der CISO kann den Security State verantworten, ohne operative Netzführungsauthority zu besitzen. AI Governance kann Governance-Anforderungen beurteilen, ohne technische Netzsicherheitsauthority zu übernehmen. Ein Control-Room Operator kann im laufenden Betrieb operative Authority besitzen, ohne die grundsätzliche Produktivfreigabe von v4.7 erteilen zu dürfen.

CONTRIBUTION

≠

RESPONSIBILITY

≠

APPROVAL AUTHORITY

12

Authority ist selbst ein State

Authority Dimension

Technical Validation Authority

Zustand

VALID

Authority Dimension

Cybersecurity Authority

Zustand

VALID

Authority Dimension

AI Governance Authority

Zustand

VALID

Authority Dimension

Deployment Approval Authority

Zustand

VALID

Authority Dimension

Operational Use Authority

Zustand

VALID

Authority Dimension

Cross-Border Coordination Context

Zustand

CONDITIONALLY BOUND

Authority Dimension

Residual-Risk Acceptance Authority

Zustand

NOT YET EXERCISED

Eine Organisation kann alle relevanten Rollen formal benannt haben und dennoch keine autorisierte Übernahme der konkret verbleibenden Restunsicherheit besitzen. Auch das kann den Abschluss verhindern.

13

Einwände verschwinden nicht, nur weil später eine Entscheidung getroffen wird

Strategische Entscheidungen entstehen nicht immer im Konsens. Operations kann den vollständigen Scope unterstützen. Grid Security Engineering kann zusätzliche Cross-Border Assurance verlangen. Enterprise Risk kann die verbleibende Unsicherheit für unzureichend charakterisiert halten. AI Governance kann zusätzliche Monitoring- und Change-Bedingungen verlangen.

OPEN OBJECTION

RESOLVED OBJECTION

ACCEPTED CONDITION

NON-BLOCKING DISSENT

BLOCKING OBJECTION

Eine finale Freigabe darf nicht auslöschen, dass zum Zeitpunkt der Entscheidungsbildung eine begründete Gegenposition bestand.

14

Decision Space v1 lässt sich jetzt als vollständiger Entscheidungszustand beschreiben

Dimension

System / Operating State

Aktueller Zustand

MOSTLY RESOLVED

Dimension

Requirements

Aktueller Zustand

OPEN

Dimension

Evidence

Aktueller Zustand

INCOMPLETE

Dimension

Uncertainty

Aktueller Zustand

MATERIAL OPEN

Dimension

Alternatives

Aktueller Zustand

VISIBLE

Dimension

Responsibility

Aktueller Zustand

BOUND

Dimension

Authority

Aktueller Zustand

PARTIAL

Dimension

Objections

Aktueller Zustand

BLOCKING

Dimension

Finality

Aktueller Zustand

NOT AVAILABLE

III / WARUM DER STATE NICHT SCHLIESSEN KANN

Ein Blocker ist das kausale Ergebnis offener Decision-Space-Dimensionen

15

Der Blocker ist das Ergebnis mehrerer offener Zustände

CROSS-BORDER DEPLOYMENT ASSURANCE — OPEN

REQUIRED CROSS-BORDER EVIDENCE — INCOMPLETE

↓

MATERIAL UNCERTAINTY — NOT SUFFICIENTLY CHARACTERISED

↓

RESIDUAL-RISK POSITION — NOT YET ACCEPTED

↓

REQUIRED DECISION CONDITION — OPEN

↓

DECISION SPACE v1 — NOT FINALISABLE

Der Blocker ist kein einzelnes fehlendes Dokument. Er entsteht daraus, dass mehrere Dimensionen des Decision Space noch keinen zulässigen gemeinsamen Zustand bilden.

Wenn der aktuelle Decision State nicht schließen kann, kann SIMULATION zwei unterschiedliche Fragen untersuchen. BRIDGE kontrolliert, was in einen geregelten Decision Space zurückkehren darf, bevor eine neue SEAL-Prüfung möglich ist.

DECISION STATE v1

Vollständiger Deployment Scope

BLOCKER

Cross-Border Deployment Assurance offen

SIMULATION

01 / Current Space auflösen

  • Zusätzliche Evidence
  • Unsicherheit charakterisieren
  • Einwände auflösen
  • Authority ausüben

02 / Decision Space remodeln

  • Restricted Advisory
  • Analysis Only
  • Shadow Mode
  • Deployment verschieben

BRIDGE

Klassifikation · Evidence-Vererbung · Uncertainty Delta · Authority · Requirements · Residual Blocker

DECISION STATE v2

Restricted Advisory Deployment

SEAL CHECK

Sind alle erforderlichen Zustände dieses Decision Space aufgelöst?

16

Was SEAL an dieser Stelle ausdrücklich nicht sagt

  • 01SEAL sagt nicht, dass die AI unsicher ist.
  • 02SEAL sagt nicht, dass der Einsatz rechtswidrig ist.
  • 03SEAL sagt nicht, dass die Technologie nicht funktioniert.
  • 04SEAL verlangt nicht, dass sämtliche Unsicherheit verschwindet.

Die für Decision Space v1 definierten Voraussetzungen bilden noch keinen finalisierbaren gemeinsamen Zustand.

17

Ein Blocker ist kein totes Ende

Ein klassischer Approval Workflow könnte hier mit Pending oder Rejected enden. Aber keiner dieser Status erklärt, was sich präzise ändern müsste, damit wieder eine belastbare Entscheidung möglich wird. Hier beginnt SIMULATION.

  • 01SIMULATION genehmigt nichts.
  • 02SIMULATION löst die Engineering-Frage nicht selbst.
  • 03SIMULATION akzeptiert keine Residual Uncertainty.
  • 04SIMULATION besitzt keine Deployment Authority.
Wie SIMULATION, BRIDGE und SEAL Exploration von geregelter Finalität trennen

IV / WAS SICH ÄNDERN KÖNNTE

Ein blockierter Decision Space kann aufgelöst – oder bewusst neu modelliert werden

18

Pfad A: Den bestehenden Decision Space auflösen

Welche Zustände müssen sich ändern, damit Decision Space v1 unter seinen bestehenden Regeln abschließbar wird?

Evidence

Die fehlende Cross-Border Assurance muss durch die zuständigen Fachfunktionen erzeugt oder ergänzt werden.

Uncertainty

Die verbleibende wesentliche Unsicherheit muss ausreichend charakterisiert werden: wann sie entsteht, wie wesentlich ihre Auswirkungen sein können, ob relevante Grenzen erkannt oder signalisiert werden können und wo die validierte Betriebsgrenze liegt.

Requirements

Die offene Cross-Border-Assurance-Requirement muss tatsächlich erfüllt werden.

Verantwortung und Risk

Grid Security Engineering muss den technischen Zustand verantwortbar beurteilen können. Verbleibende Unsicherheit muss entweder weiter reduziert oder im anwendbaren Risk-Governance-Modell bewusst behandelt werden.

Authority und Einwände

Nur die zuständige Authority darf bestimmen, ob verbleibende Unsicherheit innerhalb der Regeln des Decision Space übernommen werden darf. Blockierende fachliche Einwände müssen sachlich aufgelöst werden oder blockierend bleiben.

19

Pfad B: Den Decision Space selbst verändern

Was verändert sich, wenn die Organisation nicht den ursprünglichen vollständigen Scope freigibt, sondern eine andere Einsatzentscheidung untersucht?

Candidate

Restricted Advisory Scope

Veränderte Entscheidung

Definierte grenzüberschreitend relevante Situationen werden ausgeschlossen.

Candidate

Analysis Only

Veränderte Entscheidung

Die AI darf Risiken und Contingencies hervorheben, aber keine Remedial-Action-Kandidaten priorisieren.

Candidate

Shadow Mode

Veränderte Entscheidung

Outputs werden erzeugt, dürfen in definierten kritischen Situationen aber noch nicht Teil der operativen Entscheidungsgrundlage werden.

Keine dieser Alternativen ist eine Empfehlung von Epistemis. SIMULATION untersucht ihre Konsequenzen.

20

Eine Alternative verändert den ganzen Decision Space

Dimension

System

Wirkung des Restricted Advisory Scope

v4.7 bleibt unverändert

Dimension

Intended Use

Wirkung des Restricted Advisory Scope

Engerer operativer Einsatz

Dimension

Requirements

Wirkung des Restricted Advisory Scope

Cross-Border Assurance kann außerhalb des neuen Scopes liegen

Dimension

Evidence

Wirkung des Restricted Advisory Scope

Bestehende nationale Evidence gewinnt höhere Relevanz

Dimension

Uncertainty

Wirkung des Restricted Advisory Scope

Definierte Cross-Border-Uncertainty fällt aus dem zulässigen Einsatz

Dimension

Neue Unsicherheit

Wirkung des Restricted Advisory Scope

Kann die Scope-Begrenzung zuverlässig durchgesetzt werden?

Dimension

Neue Evidence

Wirkung des Restricted Advisory Scope

Scope Enforcement und Out-of-Scope Detection müssen nachgewiesen werden

Dimension

Responsibility

Wirkung des Restricted Advisory Scope

Operations erhält zusätzliche Boundary-Verantwortung

Dimension

Authority

Wirkung des Restricted Advisory Scope

Der neue Scope benötigt eine separate Freigabe

Dimension

Monitoring

Wirkung des Restricted Advisory Scope

Scope-Verletzungen müssen erkennbar werden

Dimension

Blocker

Wirkung des Restricted Advisory Scope

Der v1-Blocker bleibt erhalten; v2 kann neue Blocker erzeugen

Eine Alternative verändert nicht nur das Ergebnis. Sie verändert die Struktur des Decision Space.

21

Decision Space v1 darf nicht rückwirkend verschwinden

Der ursprüngliche Zustand bleibt erhalten: Full Deployment Scope. Cross-Border Evidence unvollständig. Material Uncertainty offen. Residual Risk noch nicht übernommen. SEAL blockiert. Diese Historie darf nicht umgeschrieben werden, nur weil später ein engerer Einsatz möglich wird.

Ein veränderter Decision Space erhält einen neuen Zustand mit veränderten Requirements, Evidence, Unsicherheit, Verantwortlichkeiten, Authority-Fragen und möglicherweise neuen Blockern.

22

BRIDGE prüft die gesamte Zustandsänderung, nicht nur den ausgewählten Candidate

  • 01Scope — was ist erlaubt und was ausdrücklich ausgeschlossen?
  • 02Requirements — welche bleiben, welche entfallen, welche entstehen neu?
  • 03Evidence — welche Nachweise können übernommen werden, welche sind scope-spezifisch, welche neuen werden benötigt?
  • 04Uncertainty — was wurde entfernt, reduziert oder neu eingeführt?
  • 05Assumptions — welche bleiben gültig und welche neuen Annahmen entstehen?
  • 06Alternatives — warum wurde dieser Candidate weiterverfolgt?
  • 07Responsibility — haben sich verantwortliche Rollen verändert?
  • 08Authority — deckt die Approval Authority die neue Konfiguration ab?
  • 09Objections — welche Gegenpositionen bleiben?
  • 10Blocker — liegt ein alter Blocker tatsächlich außerhalb des neuen Scopes?

Es gibt weiterhin keinen direkten Pfad: SIMULATION → SEAL.

23

Decision Space v2 erhält seinen eigenen vollständigen Zustand

Dimension

System

Decision Space v2

Grid Security Advisor v4.7

Dimension

Intended Use

Decision Space v2

Restricted Advisory Deployment

Dimension

Cross-Border Use

Decision Space v2

Für definierte nicht validierte Situationen ausgeschlossen

Dimension

Requirements

Decision Space v2

Scope Enforcement, Human Oversight, Monitoring und Change Control

Dimension

Evidence

Decision Space v2

Baseline- und Security-Evidence bleibt; neue Scope-Enforcement-Evidence erforderlich

Dimension

Uncertainty

Decision Space v2

Neue Frage: Kann die Betriebsgrenze zuverlässig erkannt werden?

Dimension

Responsibility

Decision Space v2

Operations übernimmt zusätzliche Boundary-Verantwortung

Dimension

Authority

Decision Space v2

Geänderter Scope benötigt eine eigene verantwortliche Freigabe

Dimension

Conditions

Decision Space v2

Scope-Verletzungen, materielle Änderungen und definierte Monitoring-Ereignisse können eine Neubewertung auslösen

24

Auch Decision Space v2 ist nicht automatisch SEAL-fähig

SCOPE ENFORCEMENT — RESOLVED

OUT-OF-SCOPE DETECTION — RESOLVED

OPERATOR SIGNALLING — RESOLVED

MONITORING — RESOLVED

CHANGE TRIGGER — RESOLVED

RESPONSIBLE ROLES — BOUND

APPROVAL AUTHORITY — BOUND

MATERIAL UNCERTAINTY — CHARACTERISED

RESIDUAL UNCERTAINTY — GEMÄSS DECISION SPACE BEHANDELT

Ein engerer Decision Space ist keine Abkürzung zur Finalität. Seine eigenen erforderlichen Zustände müssen aufgelöst sein, bevor er SEAL-fähig werden kann.

V / CHANGE & RE-APPROVAL

Eine Entscheidung bleibt an den tatsächlich freigegebenen Systemzustand und Scope gebunden

25

Ein bestehender SEAL wächst nicht still mit dem System mit

Materielle Änderung

Neue Modell-/Systemversion

Mögliche Wirkung

Evidence Coverage kann sich ändern

Materielle Änderung

Neue Inputquelle

Mögliche Wirkung

Neue Datenrisiken oder Annahmen

Materielle Änderung

Neue Tool-/Retrieval-Komponente

Mögliche Wirkung

Verändertes Systemverhalten

Materielle Änderung

Erweiterter geografischer Scope

Mögliche Wirkung

Neue Operational Requirements

Materielle Änderung

Action Ranking statt Analyse

Mögliche Wirkung

Veränderte Decision Influence

Materielle Änderung

Höhere Automatisierung

Mögliche Wirkung

Geänderte Human Authority

Materielle Änderung

Geändertes Oversight-Modell

Mögliche Wirkung

Responsibility Shift

Materielle Änderung

Veränderte Security Boundary

Mögliche Wirkung

Neue technische Authority

Materielle Änderung

Neue Failure Mode

Mögliche Wirkung

Neue Material Uncertainty

Materielle Änderung

Materielle Drift

Mögliche Wirkung

Bestehende Assurance kann unzureichend werden

Materielle Änderung

Veränderte regulatorische Einordnung

Mögliche Wirkung

Andere Requirements

Ein bestehender SEAL ist keine automatische Authority für einen materiell veränderten Systemzustand oder Einsatzzweck.

VI / SPÄTERE PRÜFUNG

Bei T1 muss die Organisation den Entscheidungszustand erklären können, der bei T0 bestand

26

18 Monate später wird nicht nur gefragt, welche Version installiert war

Stellen wir uns vor, 18 Monate nach der Freigabe tritt eine schwere europäische Netzstörung auf. Damit ist noch nichts darüber gesagt, ob Grid Security Advisor beteiligt war oder das Ereignis verursacht hat. Aber die Organisation kann mit einer anderen Klasse von Fragen konfrontiert werden.

  • 01System — welche Version und Konfiguration waren tatsächlich freigegeben?
  • 02Requirements — welche regulatorischen und internen Anforderungen wurden bei T0 zugrunde gelegt?
  • 03Evidence — welche Nachweise trugen diese Anforderungen?
  • 04Uncertainty — welche wesentlichen Unsicherheiten waren bekannt, akzeptiert oder überwacht?
  • 05Assumptions — welche Annahmen trugen die Freigabe und galten sie noch?
  • 06Alternatives — welche anderen Konfigurationen wurden betrachtet und warum wurde dieser Scope gewählt?
  • 07Responsibility — wer verantwortete welchen Teil des Decision State?
  • 08Authority — wer durfte den Deployment Scope freigeben und wer durfte AI-Output operativ verwenden oder verwerfen?
  • 09Objections — welche Gegenpositionen waren bei T0 bekannt?
  • 10Change — was hatte sich seit der Freigabe verändert und hätte eine Neubewertung ausgelöst werden müssen?

Welcher geregelte Decision State bestand tatsächlich zu T0 – und war der Zustand bei T1 noch derselbe?

27

Ein Audit Trail allein beantwortet diese Frage nicht

Audit Trail kann zeigen

Wer was geändert hat

Decision State muss zusätzlich erklären

Warum der Zustand als ausreichend galt

Audit Trail kann zeigen

Wann ein Workflow abgeschlossen wurde

Decision State muss zusätzlich erklären

Welche Requirements galten

Audit Trail kann zeigen

Welche Version aktiv war

Decision State muss zusätzlich erklären

Welche Evidence die Entscheidung trug

Audit Trail kann zeigen

Welche Freigabeaktion ausgeführt wurde

Decision State muss zusätzlich erklären

Welche Unsicherheit bewusst übernommen wurde

Audit Trail kann zeigen

Action History

Decision State muss zusätzlich erklären

Alternatives, Einwände und Authority

Das ist der Unterschied zwischen Action History und Decision State.

28

Unterschiedliche spätere Leser benötigen unterschiedliche Sichten auf denselben Zustand

Reader

Operations

Zentrale Frage

Für welchen Scope durfte das System verwendet werden und welche Grenzen galten?

Reader

Grid Engineering

Zentrale Frage

Welche technische Assurance und welche offenen fachlichen Bedingungen lagen vor?

Reader

AI Governance

Zentrale Frage

Welche Requirements, Limits, Monitoring- und Change-Bedingungen galten?

Reader

CISO / Security

Zentrale Frage

Welche Security- und Authority-Boundaries waren gebunden?

Reader

Risk

Zentrale Frage

Welche Unsicherheit und Risk Position wurden übernommen?

Reader

Internal Audit

Zentrale Frage

Wie verlief v1 → Blocker → SIMULATION → BRIDGE → v2?

Reader

Management / Oversight

Zentrale Frage

Auf welcher Grundlage wurde Verantwortung übernommen?

Reader

Berechtigter externer Prüfer

Zentrale Frage

Welche zweckgebundene autorisierte Sicht belegt den historischen Decision State?

Wie spätere institutionelle Leser einen Decision State prüfen

29

Die reale Authority bleibt außerhalb von Epistemis

  • 01Epistemis betreibt kein Stromnetz.
  • 02Epistemis führt keine Contingency Analysis anstelle des TSO durch.
  • 03Epistemis wählt keine Remedial Actions.
  • 04Epistemis bestimmt nicht die physikalische Sicherheit einer Netzmaßnahme.
  • 05Epistemis klassifiziert ein KI-System nicht eigenständig rechtlich als Hochrisiko-System.
  • 06Epistemis ersetzt keine Cybersecurity-, Grid-Engineering-, Risk- oder Operational Authority.

Der EU AI Act trennt menschliche Aufsicht von abstrakter Governance. Artikel 14 verlangt für Hochrisiko-KI-Systeme wirksame menschliche Aufsicht; Artikel 26 verlangt, soweit diese Pflichten greifen, die Zuweisung an Personen mit notwendiger Kompetenz, Ausbildung und Authority.

Primärquelle: EU AI Act — konsolidierte Fassung vom 27. Juli 2026

Epistemis fügt keine neue fachliche Authority hinzu. Es bewahrt, welche Authority für welchen Zustand zuständig war und auf welcher geregelten Entscheidungsgrundlage diese Authority gehandelt hat.

30

Warum dieser Fall über klassische AI Governance hinausgeht

Organisationen in kritischer Infrastruktur besitzen bereits Engineering- und Grid-Management-Systeme, Operational-Security-Prozesse, Cybersecurity-Strukturen, AI-Governance-Regeln, technische Validation, Risk Management, Dokumenten- und Workflow-Systeme, Monitoring und Audit Logs.

NIST entwickelt derzeit ein eigenes AI RMF Trustworthy AI in Critical Infrastructure Profile. Das Projekt adressiert AI in hochkritischen IT-, OT- und ICS-Umgebungen und befindet sich weiterhin in Entwicklung; es ist keine regulatorische Vorgabe für diesen europäischen TSO-Fall.

Primärquelle: NIST AI RMF Trustworthy AI in Critical Infrastructure Profile — in Entwicklung

Das Problem liegt auf einer anderen Ebene: Wie werden Requirements, Evidence, Unsicherheiten, Annahmen, Alternativen, Rollen und Authorities einer konkreten Unternehmensentscheidung zu einem Zustand verbunden, der bei T0 verstanden und bei T1 rekonstruiert werden kann?

31

Der vollständige Epistemis-Mechanismus hinter diesem AI Deployment

  • 01Ein Blocker erklärt, warum der aktuelle Decision Space nicht schließen kann.
  • 02SIMULATION untersucht entweder, was zur Auflösung des bestehenden Spaces fehlt, oder was sich bei einer anderen regelgebundenen Entscheidung verändern würde.
  • 03BRIDGE prüft, welche Requirements, Evidence, Unsicherheiten, Rollen, Authorities und Bedingungen aus Exploration in einen geregelten Decision Space zurückkehren dürfen.
  • 04SEAL bindet nur einen Decision State, in dem die erforderlichen Voraussetzungen des Decision Space aufgelöst sind und kein blockierender Zustand offen bleibt.

Das ist keine AI-Compliance-Checkliste. Es ist Infrastruktur für den Zustand der Entscheidung selbst.

QUELLEN / METHODE

Quellen- und Methodenhinweis

Reale fachliche und regulatorische Grundlage

Die fachlichen Aussagen stützen sich auf die EU System Operation Guideline, NIS2, die konsolidierte Fassung des EU AI Act und die laufenden NIST-Arbeiten zum Critical Infrastructure AI RMF Profile. Das NIST-Profil befindet sich in Entwicklung und dient hier als technischer Referenzpunkt, nicht als regulatorische Vorgabe für einen europäischen TSO.

Primärquelle: EU System Operation GuidelinePrimärquelle: NIS2-RichtliniePrimärquelle: EU AI Act — konsolidierte Fassung vom 27. Juli 2026Primärquelle: NIST AI RMF Trustworthy AI in Critical Infrastructure Profile — in Entwicklung

Illustratives Szenario

Grid Security Advisor v4.7, sein Deployment Scope, technische Prüfungen, Requirements, Evidence States, Unsicherheiten, Annahmen, interne Rollen, Authority-Struktur, Einwände und alternative Deployment-Konfigurationen sind ein illustratives Epistemis-Szenario. Sie beschreiben keinen realen Kunden, kein reales TSO-Produkt und keinen offiziell vorgeschriebenen Approval-Prozess.

Epistemis-Modellierung

Decision Space, Decision State, Blocker, SIMULATION, BRIDGE, SEAL, v1/v2 und Evidence-Pack-Sichten sind Epistemis-Konzepte. Sie sind keine Terminologie des EU AI Act, von NIS2, der System Operation Guideline oder von NIST.

Welche strategische KI-Entscheidung müssten Sie später erklären können?

Ein Enterprise Pilot beginnt mit einer klar abgegrenzten haftungsrelevanten Entscheidung und bestimmt für diesen Decision Space die maßgeblichen Quellen, anwendbaren Anforderungen, Nachweisbedarfe, Annahmen, Unsicherheiten, Alternativen, verantwortlichen Rollen, Authority-Grenzen, Blocker, Change Trigger und späteren Lesersichten.

Diesen Decision Space im Enterprise Pilot besprechenWeitere Anwendungsfälle ansehen