Skip to content
Decision-state infrastructure
ende
Applications

AI in Critical Infrastructure

CRITICAL INFRASTRUCTURE AI

What must be resolved before AI can influence a critical-infrastructure decision?

An AI system can be technically capable, extensively validated and thoroughly reviewed for cybersecurity risk — and still not constitute an approvable deployment.

Because an organisation does not approve “the AI” in the abstract. It assumes responsibility for a particular use: a specific system version, a defined purpose and defined operating boundaries. It needs to know which requirements apply, which evidence actually supports those requirements, which uncertainties remain, which alternatives were seriously considered, which objections are still open, and who holds responsibility and decision authority for each relevant part of the state.

In this illustrative case, a European transmission system operator intends to introduce a high-security AI system into operational grid-security analysis. Grid Security Advisor v4.7 analyses stressed grid conditions and produces prioritised candidates for possible remedial actions. It cannot initiate switching, redispatch or any other operational action itself. Operational authority remains with authorised human control-room personnel.

Technically, the system is largely ready. Much of the evidence already exists. Several requirements have been satisfied. But one material uncertainty has not yet been sufficiently resolved. The evidence required to support it is incomplete. The competent risk function has not yet accepted the remaining uncertainty. And the proposed cross-border deployment scope therefore cannot yet be closed.

The state of the AI system is only one part of the decision.

The Decision State emerges only when system state, requirements, evidence, uncertainty, alternatives, responsibility and authority can form one coherent governed state.

I / THE DECISION

A deployment approval is a decision about a bounded state — not about AI in the abstract

01

It is not the model that is approved. It is a defined Decision Space.

Consider an illustrative European transmission system operator. For this case, we will call the system Grid Security Advisor v4.7.

The system supports operational grid-security analysis. It processes a defined grid state, relevant topology information, planned outages, forecasts, contingency scenarios and other inputs authorised for its intended use. It produces analysed risk signals and prioritised candidates for possible remedial actions. It does not execute operational actions.

Should Grid Security Advisor v4.7 be approved for the defined operational-security context so that authorised control-room personnel may use its analyses and prioritised action candidates as input into operational-security decisions?

Dimension

System

Subject of the decision

Grid Security Advisor v4.7

Dimension

Intended use

Subject of the decision

Support for operational grid-security decisions

Dimension

Operating boundary

Subject of the decision

Defined national and cross-border-relevant situations

Dimension

AI role

Subject of the decision

Analysis and prioritisation, no operational actuation

Dimension

Requirements

Subject of the decision

Regulatory, operational, security and internal governance requirements

Dimension

Evidence

Subject of the decision

Evidence supporting those requirements for this specific use

Dimension

Uncertainty

Subject of the decision

Known and remaining uncertainty

Dimension

Alternatives

Subject of the decision

Serious alternative deployment configurations

Dimension

Responsibilities

Subject of the decision

Roles responsible for individual states

Dimension

Authority

Subject of the decision

Roles permitted to assess, accept or approve specific states

Dimension

Conditions

Subject of the decision

Boundaries, monitoring, fallback and change triggers

Approval therefore does not apply to “v4.7” in isolation. It applies to a specific Decision Space.

02

Why this deployment is strategically and institutionally significant

A European transmission system operator does not operate in an ordinary software environment. Under the EU System Operation Guideline, TSOs perform contingency analysis, are responsible for managing operational-security violations and must design, prepare and activate remedial actions. Where operational-security violations require coordinated management, remedial actions are coordinated with other affected TSOs.

Primary source: EU System Operation Guideline

Grid Security Advisor therefore does not sit at an ordinary productivity interface. Its output can influence a human decision concerning grid security, potential remedial action and, in some circumstances, cross-border coordination.

Cybersecurity is equally integral to the context. NIS2 lists transmission system operators in the electricity subsector within Annex I — Sectors of High Criticality.

Primary source: NIS2 Directive

The EU AI Act adds another layer. Annex III covers AI systems intended to be used as safety components in the management and operation of critical infrastructure, including electricity supply. Whether a particular system is legally classified as high-risk still depends on its intended purpose and the applicable Article 6 classification conditions.

Primary source: EU AI Act — consolidated 27 July 2026

Epistemis does not determine that legal classification. The regulatory context is itself part of the Decision Space and must be established by the competent legal, compliance and governance functions.

03

What actually forms the Decision State

A Decision State is not simply a model, a validation report and a collection of sign-offs. For this case, nine connected state dimensions matter.

State dimension

System and operating state

Question

Which system, version and operating boundary are actually in scope?

State dimension

Requirements state

Question

Which regulatory, technical, organisational and internal requirements apply?

State dimension

Evidence state

Question

Which evidence supports which decision-relevant claim — and for which scope?

State dimension

Uncertainty state

Question

What remains uncertain, accepted or blocking?

State dimension

Assumptions state

Question

Which assumptions must remain true for the decision to remain valid?

State dimension

Alternatives state

Question

Which serious alternatives were considered?

State dimension

Responsibility state

Question

Which role is responsible for which part of the state?

State dimension

Authority state

Question

Who may assess, accept or approve which state?

State dimension

Conflict and conditions state

Question

Which objections, conditions or differing professional positions remain relevant?

Only when these dimensions are connected does a governed Decision State emerge.

A deployment Decision State combines the system and operating state with applicable requirements, evidence, uncertainty, assumptions, alternatives, responsibilities, authority and unresolved objections.
SYSTEM / OPERATING STATE
REQUIREMENTS
EVIDENCE
UNCERTAINTY
ASSUMPTIONS
ALTERNATIVES
RESPONSIBILITY
AUTHORITY
OBJECTIONS / CONDITIONS

Connected at T0

Decision State v1

The AI system is one input into the decision state. It is not the decision state itself.

II / CURRENT DECISION STATE

Technical readiness can coexist with unresolved evidence, uncertainty and authority

04

The technical state may already be largely resolved

State

SYSTEM IDENTITY

Status

RESOLVED

State

MODEL / SYSTEM VERSION

Status

RESOLVED

State

DEPLOYMENT ENVIRONMENT

Status

RESOLVED

State

BASELINE PERFORMANCE

Status

RESOLVED

State

CYBERSECURITY REVIEW

Status

RESOLVED

State

HUMAN OVERSIGHT MODEL

Status

RESOLVED

State

OPERATOR TRAINING

Status

RESOLVED

State

FALLBACK PATH

Status

RESOLVED

State

DIRECT ACTUATION AUTHORITY

Status

NONE

State

CROSS-BORDER OPERATIONAL VALIDATION

Status

OPEN

Grid Security Advisor v4.7 is unambiguously identified. The intended high-security operating environment is defined. The system has no direct actuation authority. Baseline tests and the security reviews defined for this illustrative Decision Space have been completed. Where Article 26 obligations for high-risk AI systems apply, deployers must assign human oversight to natural persons with the necessary competence, training and authority.

Primary source: EU AI Act — consolidated 27 July 2026

Technically, the deployment therefore appears advanced. But technical readiness is not the Decision State.

05

A requirement is not resolved merely because a related document exists

Requirement

Defined system version

Origin in the illustrative Decision Space

Internal AI / change governance

Status

RESOLVED

Requirement

No autonomous operational actuation

Origin in the illustrative Decision Space

Internal authority boundary

Status

RESOLVED

Requirement

Effective human oversight

Origin in the illustrative Decision Space

AI governance / applicable regulatory context

Status

RESOLVED

Requirement

Secure deployment context

Origin in the illustrative Decision Space

Security policy

Status

RESOLVED

Requirement

Independent fallback

Origin in the illustrative Decision Space

Critical-system policy

Status

RESOLVED

Requirement

Operational monitoring

Origin in the illustrative Decision Space

AI / operational governance

Status

RESOLVED

Requirement

Defined change triggers

Origin in the illustrative Decision Space

AI change policy

Status

RESOLVED

Requirement

Sufficient assurance for cross-border scope

Origin in the illustrative Decision Space

Deployment requirement

Status

OPEN

Requirement

Acceptable residual uncertainty

Origin in the illustrative Decision Space

Risk governance

Status

OPEN

A requirement is not satisfied simply because an organisation can point to a document bearing the right title. The organisation must be able to determine which state actually satisfies the requirement.

06

Evidence is not the inventory of documents that happen to exist

The transmission system operator may already hold model documentation, technical validation, cybersecurity assessments, a human-oversight design, training records, a risk register, a monitoring plan, change history and operational documentation. The Evidence State asks a different question: which claim about this particular decision is actually supported by which evidence?

Decision-relevant claim

The deployment version is unambiguous

Material evidence

Versioned deployment package

Status

RESOLVED

Decision-relevant claim

Baseline behaviour has been assessed

Material evidence

Validation evidence

Status

RESOLVED

Decision-relevant claim

The security boundary has been assessed

Material evidence

Security assurance

Status

RESOLVED

Decision-relevant claim

Human intervention is operationally established

Material evidence

Oversight model + training evidence

Status

RESOLVED

Decision-relevant claim

An AI-independent fallback exists

Material evidence

Fallback test / procedure evidence

Status

RESOLVED

Decision-relevant claim

Behaviour across the full requested cross-border scope is sufficiently supported

Material evidence

Cross-border assurance

Status

INCOMPLETE

DOCUMENT EXISTS

≠

EVIDENCE COVERS THE DECISION

Evidence can be valid and still fail to cover the scope actually being proposed for approval.

07

Strategic decisions do not wait until every uncertainty disappears

The relevant question is not whether uncertainty still exists. It is what uncertainty remains, how well it is understood, how material it is, and whether it may consciously remain within this Decision Space.

Uncertainty

Behaviour in validated national scenarios

Status

CHARACTERISED

Uncertainty

Known model limitations

Status

CHARACTERISED

Uncertainty

Operator automation bias

Status

CONTROLLED / MONITORED

Uncertainty

Future drift

Status

RESIDUAL / MONITORED

Uncertainty

Rare out-of-distribution conditions

Status

CHARACTERISED WITH LIMITS

Uncertainty

Behaviour in defined cross-border stress situations

Status

MATERIAL UNCERTAINTY OPEN

SEAL does not require the absence of uncertainty. A valid Decision State can contain residual uncertainty if it has been treated in the manner required by the Decision Space and no blocking uncertainty remains unresolved.

08

Assumptions are neither facts nor evidence

Approval of Grid Security Advisor v4.7 may rely on assumptions that grid-state data remains within defined quality bounds, authorised data sources remain available, the AI stays advisory, human operators retain operational authority, the independent fallback remains available, no additional actuation integration is introduced and defined operating boundaries remain intact.

FACT

≠

EVIDENCE

≠

ASSUMPTION

A later reviewer should be able to see which assumptions the original approval relied upon. If a material assumption later ceases to hold, the Decision State may no longer be the same state.

09

A responsible decision needs genuine alternatives

Alternative

A / Full Deployment Scope

State

CURRENT PROPOSAL

Alternative

B / Restricted Domestic Advisory Scope

State

AVAILABLE

Alternative

C / Analysis without Action Ranking

State

AVAILABLE

Alternative

D / Shadow Mode

State

AVAILABLE

Alternative

E / Deployment Postponed

State

AVAILABLE

The objective is not to create a catalogue of every imaginable option. The relevant state is which alternatives were seriously present within the Decision Space, which were examined, and what each alternative would change in evidence, requirements, uncertainty and responsibility.

A decision is difficult to reconstruct later if only the selected option remains visible.

10

Responsibility is not the same thing as approval authority

Role

AI System Owner

Illustrative responsibility

System identity, version and change management

Role

Grid Security Engineering

Illustrative responsibility

Technical grid-security assessment

Role

Cybersecurity / CISO

Illustrative responsibility

Security assurance

Role

AI Governance

Illustrative responsibility

Governance requirements and AI-specific context

Role

Enterprise Risk

Illustrative responsibility

Risk position and treatment of residual uncertainty

Role

Operations

Illustrative responsibility

Operational usability and process integration

Role

Deployment Approval Body

Illustrative responsibility

Approval of the defined deployment scope

Role

Control-Room Operator

Illustrative responsibility

Concrete operational decision during live use

Providing information, being responsible for a state and holding final approval authority are different functions.

11

Contributor, responsible role and approval authority must not collapse into one another

A validation team may produce a technical assessment without holding production-deployment authority. The CISO may be responsible for the security state without holding operational grid authority. AI Governance may assess governance requirements without taking over technical grid-security authority. A control-room operator may hold live operational authority without holding authority to approve v4.7 for production use.

CONTRIBUTION

≠

RESPONSIBILITY

≠

APPROVAL AUTHORITY

12

Authority is itself a state

Authority dimension

Technical Validation Authority

Status

VALID

Authority dimension

Cybersecurity Authority

Status

VALID

Authority dimension

AI Governance Authority

Status

VALID

Authority dimension

Deployment Approval Authority

Status

VALID

Authority dimension

Operational Use Authority

Status

VALID

Authority dimension

Cross-Border Coordination Context

Status

CONDITIONALLY BOUND

Authority dimension

Residual-Risk Acceptance Authority

Status

NOT YET EXERCISED

An organisation may have all relevant roles formally identified and still lack an authorised acceptance of the particular residual uncertainty that remains. That absence can itself prevent closure.

13

Objections do not disappear simply because a decision is eventually made

Strategic decisions do not always emerge from consensus. Operations may support the full scope. Grid Security Engineering may require additional cross-border assurance. Enterprise Risk may regard the remaining uncertainty as insufficiently characterised. AI Governance may require additional monitoring and change conditions.

OPEN OBJECTION

RESOLVED OBJECTION

ACCEPTED CONDITION

NON-BLOCKING DISSENT

BLOCKING OBJECTION

A final approval should not erase the fact that a reasoned dissent existed at the time the decision was formed.

14

Decision Space v1 can now be described as a complete decision state

Dimension

System / operating state

Current state

MOSTLY RESOLVED

Dimension

Requirements

Current state

OPEN

Dimension

Evidence

Current state

INCOMPLETE

Dimension

Uncertainty

Current state

MATERIAL OPEN

Dimension

Alternatives

Current state

VISIBLE

Dimension

Responsibility

Current state

BOUND

Dimension

Authority

Current state

PARTIAL

Dimension

Objections

Current state

BLOCKING

Dimension

Finality

Current state

NOT AVAILABLE

III / WHY THE STATE CANNOT CLOSE

A blocker is the causal result of unresolved Decision-Space dimensions

15

The blocker is the result of several unresolved states

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

The blocker is not one missing document. It emerges because several dimensions of the Decision Space do not yet form an admissible common state.

When the current Decision State cannot close, SIMULATION can examine two different questions. BRIDGE controls what may return into a governed Decision Space before any new SEAL check.

DECISION STATE v1

Full deployment scope

BLOCKER

Cross-border deployment assurance open

SIMULATION

01 / Resolve current space

  • Additional evidence
  • Characterise uncertainty
  • Resolve objections
  • Exercise authority

02 / Remodel Decision Space

  • Restricted advisory
  • Analysis only
  • Shadow mode
  • Postpone deployment

BRIDGE

Classification · evidence inheritance · uncertainty delta · authority · requirements · residual blockers

DECISION STATE v2

Restricted advisory deployment

SEAL CHECK

Are all required states resolved for this Decision Space?

16

What SEAL does not say at this point

  • 01SEAL does not say that the AI is unsafe.
  • 02SEAL does not say that the deployment is unlawful.
  • 03SEAL does not say that the technology does not work.
  • 04SEAL does not require all uncertainty to disappear.

The conditions defined for Decision Space v1 do not yet form a finalisable common state.

17

A blocker is not a dead end

A conventional approval workflow might stop here with Pending or Rejected. But neither status explains what precisely would need to change for a robust decision to become possible. This is where SIMULATION begins.

  • 01SIMULATION does not approve anything.
  • 02SIMULATION does not answer the engineering question itself.
  • 03SIMULATION does not accept residual uncertainty.
  • 04SIMULATION does not hold deployment authority.
See how SIMULATION, BRIDGE and SEAL separate exploration from governed finality

IV / WHAT COULD CHANGE

A blocked Decision Space can be resolved — or deliberately remodelled

18

Path A: Resolve the current Decision Space

Which states need to change for Decision Space v1 to become closable under its existing rules?

Evidence

The missing cross-border assurance must be generated or completed by the competent professional functions.

Uncertainty

The remaining material uncertainty must be characterised sufficiently: when it arises, how material its effects may be, whether relevant limits can be detected or signalled, and where the validated operating boundary lies.

Requirements

The open cross-border-assurance requirement must actually become resolved.

Responsibility and risk

Grid Security Engineering must be able to take responsibility for its technical state. Remaining uncertainty must either be reduced further or deliberately treated under the applicable risk-governance model.

Authority and objections

Only the competent authority may determine whether remaining uncertainty may be accepted under the rules of the Decision Space. Blocking professional objections must either be substantively resolved or remain blocking.

19

Path B: Remodel the Decision Space itself

What changes if the organisation does not approve the original full scope, but instead investigates a different deployment decision?

Candidate

Restricted Advisory Scope

Changed decision

Defined cross-border-relevant situations are excluded.

Candidate

Analysis Only

Changed decision

The AI may identify risks and contingencies but may not rank remedial-action candidates.

Candidate

Shadow Mode

Changed decision

Outputs are generated but may not yet form part of the operational decision basis in defined critical situations.

None of these alternatives is a recommendation from Epistemis. SIMULATION examines their consequences.

20

Changing an alternative changes the whole Decision Space

Dimension

System

Effect of Restricted Advisory Scope

v4.7 remains unchanged

Dimension

Intended use

Effect of Restricted Advisory Scope

Narrower operational use

Dimension

Requirements

Effect of Restricted Advisory Scope

Cross-border assurance may fall outside the new scope

Dimension

Evidence

Effect of Restricted Advisory Scope

Existing national evidence becomes more relevant

Dimension

Uncertainty

Effect of Restricted Advisory Scope

Defined cross-border uncertainty moves outside the permitted use

Dimension

New uncertainty

Effect of Restricted Advisory Scope

Can the scope boundary be enforced reliably?

Dimension

New evidence

Effect of Restricted Advisory Scope

Scope enforcement and out-of-scope detection must be demonstrated

Dimension

Responsibility

Effect of Restricted Advisory Scope

Operations acquires additional boundary responsibilities

Dimension

Authority

Effect of Restricted Advisory Scope

The new scope requires separate approval

Dimension

Monitoring

Effect of Restricted Advisory Scope

Scope violations must become observable

Dimension

Blocker

Effect of Restricted Advisory Scope

The v1 blocker remains preserved; v2 may create new blockers

An alternative does not merely change the outcome. It changes the structure of the Decision Space.

21

Decision Space v1 must not disappear retrospectively

The original state remains preserved: Full Deployment Scope. Cross-border evidence incomplete. Material uncertainty open. Residual risk not yet accepted. SEAL blocked. That history must not be rewritten simply because a narrower deployment later becomes possible.

A changed Decision Space receives a new state with changed requirements, evidence, uncertainty, responsibilities, authority questions and potentially new blockers.

22

BRIDGE examines the entire state transition, not just the selected candidate

  • 01Scope — what is permitted and what is explicitly excluded?
  • 02Requirements — which remain, which fall away, which are newly created?
  • 03Evidence — which evidence can be inherited, which is scope-specific, which new evidence is required?
  • 04Uncertainty — what was removed, reduced or newly introduced?
  • 05Assumptions — which remain valid and which new assumptions are required?
  • 06Alternatives — why was this candidate selected for further consideration?
  • 07Responsibility — have accountable roles changed?
  • 08Authority — does the approval authority cover the new configuration?
  • 09Objections — which dissenting positions remain?
  • 10Blockers — has a blocker genuinely moved outside the new scope?

There remains no direct path: SIMULATION → SEAL.

23

Decision Space v2 receives its own complete state

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

Excluded for defined non-validated situations

Dimension

Requirements

Decision Space v2

Scope enforcement, human oversight, monitoring and change control

Dimension

Evidence

Decision Space v2

Baseline and security evidence retained; new scope-enforcement evidence required

Dimension

Uncertainty

Decision Space v2

New question: can the operating boundary be recognised reliably?

Dimension

Responsibility

Decision Space v2

Operations assumes additional boundary responsibility

Dimension

Authority

Decision Space v2

Changed scope requires its own accountable approval

Dimension

Conditions

Decision Space v2

Scope violations, material changes and defined monitoring events may trigger reassessment

24

Decision Space v2 is not automatically sealable either

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 — TREATED ACCORDING TO THE DECISION SPACE

A narrower Decision Space is not a shortcut to finality. Its own required states must be resolved before it can become eligible for SEAL.

V / CHANGE & RE-APPROVAL

A decision remains bound to the system state and scope that were actually approved

25

An existing SEAL does not silently expand with the system

Material change

New model / system version

Possible consequence

Evidence coverage may change

Material change

New input source

Possible consequence

New data risks or assumptions

Material change

New tool or retrieval component

Possible consequence

Altered system behaviour

Material change

Expanded geographic scope

Possible consequence

New operational requirements

Material change

Action ranking added to analysis

Possible consequence

Greater decision influence

Material change

Increased automation

Possible consequence

Altered human authority

Material change

Changed oversight model

Possible consequence

Responsibility shift

Material change

Changed security boundary

Possible consequence

New technical authority

Material change

Newly discovered failure mode

Possible consequence

New material uncertainty

Material change

Material drift

Possible consequence

Existing assurance may no longer be sufficient

Material change

Changed regulatory classification

Possible consequence

Different requirements

An existing SEAL does not confer automatic authority over a materially changed system state or intended use.

VI / LATER REVIEW

At T1 the organisation must explain the state of the decision that existed at T0

26

Eighteen months later, the question is not merely which version was installed

Imagine that 18 months after approval, a major European grid disturbance occurs. That does not establish that Grid Security Advisor was involved or caused the event. But the organisation may face a different class of questions.

  • 01System — which version and configuration had actually been approved?
  • 02Requirements — which regulatory and internal requirements were used at T0?
  • 03Evidence — which evidence supported those requirements?
  • 04Uncertainty — which material uncertainties were known, accepted or monitored?
  • 05Assumptions — which assumptions underpinned the approval and were they still true?
  • 06Alternatives — which other configurations had been considered and why was this scope selected?
  • 07Responsibility — who was responsible for each relevant part of the Decision State?
  • 08Authority — who was authorised to approve deployment and who could use or disregard the AI output operationally?
  • 09Objections — which dissenting positions were known at T0?
  • 10Change — what had changed since approval and should reassessment have been triggered?

What governed Decision State actually existed at T0 — and was the state at T1 still the same state?

27

An audit trail alone cannot answer that question

Audit trail can show

Who changed what

Decision State must also explain

Why the state was considered sufficient

Audit trail can show

When a workflow completed

Decision State must also explain

Which requirements applied

Audit trail can show

Which version was active

Decision State must also explain

Which evidence covered the decision

Audit trail can show

Which approval action was performed

Decision State must also explain

Which uncertainty was consciously accepted

Audit trail can show

Action history

Decision State must also explain

Alternatives, objections and authority

That is the difference between Action History and Decision State.

28

Different later readers need different views of the same state

Reader

Operations

Central question

For which scope could the system be used, and what boundaries applied?

Reader

Grid Engineering

Central question

Which technical assurance and which open technical conditions existed?

Reader

AI Governance

Central question

Which requirements, limits, monitoring and change conditions applied?

Reader

CISO / Security

Central question

Which security and authority boundaries were bound?

Reader

Risk

Central question

Which uncertainty and risk position were accepted?

Reader

Internal Audit

Central question

How did v1 → blocker → SIMULATION → BRIDGE → v2 evolve?

Reader

Management / Oversight

Central question

On what basis was responsibility assumed?

Reader

Authorised external reviewer

Central question

Which purpose-appropriate authorised view evidences the historical Decision State?

See how later institutional readers examine a Decision State

29

Real authority remains outside Epistemis

  • 01Epistemis does not operate an electricity grid.
  • 02Epistemis does not perform contingency analysis in place of the TSO.
  • 03Epistemis does not select remedial actions.
  • 04Epistemis does not determine the physical safety of a grid measure.
  • 05Epistemis does not independently classify an AI system as high-risk under law.
  • 06Epistemis does not replace cybersecurity, grid-engineering, risk or operational authority.

The EU AI Act separates human oversight from abstract governance. Article 14 requires high-risk AI systems to support effective human oversight; Article 26 requires deployers to assign oversight to natural persons with the necessary competence, training and authority where those obligations apply.

Primary source: EU AI Act — consolidated 27 July 2026

Epistemis adds no new domain authority. It preserves which authority was responsible for which state, and on what governed decision basis that authority acted.

30

Why this case goes beyond conventional AI governance

Critical-infrastructure organisations already operate engineering and grid-management systems, operational-security processes, cybersecurity structures, AI-governance rules, technical validation, risk management, document and workflow systems, monitoring and audit logs.

NIST is currently developing a dedicated AI RMF Trustworthy AI in Critical Infrastructure Profile. The project addresses AI in high-stakes IT, OT and ICS environments and remains ongoing rather than being a regulatory requirement for this European TSO scenario.

Primary source: NIST AI RMF Trustworthy AI in Critical Infrastructure Profile — ongoing

The problem exists at another layer: how are the requirements, evidence, uncertainties, assumptions, alternatives, roles and authorities relevant to one specific enterprise decision connected into a state that can be understood at T0 and reconstructed at T1?

31

The full Epistemis mechanism behind this AI deployment

  • 01A blocker explains why the current Decision Space cannot close.
  • 02SIMULATION examines either what is missing to resolve the current Space or what would change if a different rule-bound decision were considered.
  • 03BRIDGE examines which requirements, evidence, uncertainties, roles, authorities and conditions from exploration may return into a governed Decision Space.
  • 04SEAL binds only a Decision State in which the required conditions of that Decision Space have been resolved and no blocking state remains open.

This is not an AI-compliance checklist. It is infrastructure for the state of the decision itself.

SOURCES / METHOD

Source and methodology note

Real regulatory and domain context

The domain statements are grounded in the EU System Operation Guideline, NIS2, the consolidated EU AI Act and NIST’s ongoing Critical Infrastructure AI RMF work. The NIST profile remains under development and is used here as a technical reference point, not as a regulatory requirement for a European TSO.

Primary source: EU System Operation GuidelinePrimary source: NIS2 DirectivePrimary source: EU AI Act — consolidated 27 July 2026Primary source: NIST AI RMF Trustworthy AI in Critical Infrastructure Profile — ongoing

Illustrative scenario

Grid Security Advisor v4.7, its deployment scope, technical reviews, requirements, evidence states, uncertainties, assumptions, internal roles, authority structure, objections and alternative deployment configurations are an illustrative Epistemis scenario. They do not describe a real customer, an actual TSO product or an officially prescribed approval process.

Epistemis modelling

Decision Space, Decision State, blocker, SIMULATION, BRIDGE, SEAL, v1/v2 and Evidence Pack views are Epistemis concepts. They are not terminology defined by the EU AI Act, NIS2, the System Operation Guideline or NIST.

Which strategic AI decision would your organisation need to explain later?

An Enterprise Pilot starts with one clearly bounded liability-relevant decision and defines the authoritative sources, applicable requirements, evidence needs, assumptions, uncertainties, alternatives, responsible roles, authority boundaries, blockers, change triggers and later reader views for that Decision Space.

Discuss this Decision Space in an Enterprise PilotExplore other applications