CI-AIGAF

About this publication

Publication status and use

CI-AIGAF v1.0 is an independent governance and assurance framework developed by the Institute for Technology Stewardship for AI-enabled capabilities used in or materially affecting critical infrastructure and essential services.

This Public Framework Specification is the reader-facing expression of the frozen CI-AIGAF v1.0 architecture. It condenses the Master Framework and eighteen final Practice Specifications. Where this document summarizes or interprets a Practice, the standalone Practice Specification remains the controlling technical source for detailed Tasks, Implementations, assurance claims, decision rules, evidence requirements, artifacts, and crosswalks.

Reader Orientation — Start Here

You do not need to learn eighteen Practices before understanding CI-AIGAF. Begin with one question: what is this exact AI-enabled service permitted to do, on what evidence, within what conditions, and what happens when those conditions stop being true?

The detailed Practice profiles are a reference layer. A first-time reader can understand the framework architecture before using those profiles.

Back to contents

Executive Summary

AI governance often asks whether a system is accurate, safe, secure, fair, compliant, explainable, or trustworthy. Critical infrastructure adds another question that is more operational and often more consequential: what is the AI system actually permitted to do, on what evidence, under what conditions, with what independent protections, and what happens when the evidence or conditions stop being true?

CI-AIGAF is designed around that permission problem. It treats machine operational authority as a bounded organizational decision rather than a property that arises automatically from technical capability, model access, tool availability, supplier claims, or successful testing. The framework connects mission requirements, technical controls, assurance claims, evidence quality, counterevidence, residual risk, formal authorization, runtime monitoring, authority degradation, recovery and reauthorization into one traceable governance chain.

The framework contains eighteen Practices grouped into six domains. Practices retain a NIST-style Practice–Task–Implementation grammar for operational usability, but CI-AIGAF extends that grammar through assurance and authority. Each consequential implementation can be traced to a control objective, assurance claim, argument, evidence, evidence-quality evaluation, counterevidence or defeaters, residual risk, independent challenge, decision, authority effect, continuous-assurance signals, invalidation triggers and reauthorization conditions.

CI-AIGAF does not assume that deployment equals authorization or that human-in-the-loop language is sufficient. Human oversight counts as a control only where people have the information, competence, authority, time and practical means to intervene. Where credible time-to-harm is faster than demonstrated human intervention, immediate protection must be carried by independent, reliably enforceable safeguards.

Formal authorization is centralized in Practice 13. Other Practices contribute requirements, assurance evidence, blockers, specialist conditions, supportable ceilings, runtime responses and recommendations. P13 alone formally issues, restores, expands, restricts, suspends or withdraws the Operational Authority Envelope (OAE).

Back to contents

Contents at a Glance

Back to contents

1. Why CI-AIGAF Exists

1.1 The governance gap appears at the point of permission

Critical-infrastructure organizations already govern safety, cyber risk, operations, identity, change, suppliers, resilience and emergency response. AI introduces new uncertainty, but the central governance problem is not simply that AI is probabilistic. The harder problem appears when AI capability is allowed to influence or execute consequential action. At that point, the organization is transferring or delegating operational discretion.

CI-AIGAF therefore distinguishes between what an AI system can do, what it has demonstrated under evidence, and what the organization has actually authorized it to do. These states may overlap, but they must not be silently collapsed.

Enlarge

1.2 The governed object is the AI-enabled service

CI-AIGAF does not govern the model in isolation. The governed object is the AI-enabled service: model, data, knowledge and retrieval sources, prompts and configuration, tools and interfaces, identity and permissions, infrastructure and cloud dependencies, supplier services, human roles, monitoring, fallback, emergency controls, operational procedures, affected populations and connected systems.

This service-level view is necessary because a model can appear technically healthy while the surrounding authorization case has failed. Identity can broaden, a tool can change, retrieval sources can drift, fallback can become unavailable, an operator role can disappear, a supplier can alter a service, or cross-sector dependency can make a previously local action systemically unsafe.

Enlarge

1.3 What CI-AIGAF adds

• An explicit authority model that separates capability, evidence and permission.
• A canonical evidence-to-authority chain rather than a control checklist alone.
• Evidence-quality dimensions that require representativeness, fidelity, independence, currency and provenance to be considered explicitly.
• Counterevidence and defeaters as first-class governance objects.
• A formal Assurance Validity Envelope (AVE) and Operational Authority Envelope (OAE).
• Continuous assurance tied to material change and authority degradation.
• A human-oversight feasibility test that accounts for time-to-harm and machine-speed protection.
• A systemic-risk Practice for common-mode failure, scarcity and cross-sector cascades.

Back to contents

2. Framework Identity, Scope and Non-Goals

CI-AIGAF stands for Critical Infrastructure AI Governance and Assurance Framework. It is intended for AI-enabled capabilities that can materially influence the safety, continuity, reliability, rights, accessibility, privacy, equity, security or public-interest performance of essential services.

Publication architecture — The Master Framework is the frozen normative architecture and controlling framework baseline. The Master Book is a separate, expanded practitioner and worked-case companion; it does not replace the Master Framework or the final Practice Specifications and may be released on its own maturity cycle.

2.1 In-scope AI-enabled capabilities

• Administrative or advisory AI whose outputs can materially influence critical operations.
• AI/ML embedded in operational technology, network management, safety, maintenance, planning, allocation or assurance.
• Generative AI and AI-generated operational artifacts such as code, configurations, procedures, policies and queries.
• Automated and agentic systems with tool use, delegated identity, memory, dynamic dependency selection or multi-agent coordination.
• AI supplied as products, components, APIs, managed services, cloud services or embedded capabilities.
• System-of-systems and cross-sector interactions where local AI action can propagate into other essential services.

2.2 Non-goals

• CI-AIGAF is not a substitute for law or competent-authority interpretation.
• It does not create a presumption of conformity under the EU AI Act or any other legal regime.
• It does not replace detailed cybersecurity, functional-safety, sector engineering, privacy or business-continuity standards.
• It does not treat implementation completeness as proof of acceptable risk.
• It does not assume that a “human in the loop” label establishes meaningful oversight.
• It does not bind its internal numbering to the numbering of any external framework.

Back to contents

3. Architecture and Foundational Rules

3.1 Canonical chain

Enlarge

The chain is designed to prevent three common failures: controls existing without a claim about what they prove; evidence existing without a boundary on where it remains valid; and permission being granted without a traceable explanation of why the evidence justifies that permission.

3.2 Seven architectural planes

Enlarge

3.3 Twelve foundational rules

Back to contents

4. Operational Authority, Consequence and Assurance Classification

CI-AIGAF uses three linked lenses: the authority requested of AI, the potential consequence of failure or misuse, and the assurance posture needed to support the requested authority in that consequence context. These are governance classifications, not claims of mathematical precision.

Enlarge

4.1 Operational Authority tiers

4.2 Consequence tiers

4.3 Assurance classes

Back to contents

5. R0 and Lifecycle Gates G0-G9

CI-AIGAF places an applicability pre-gate before the operational lifecycle. This reduces a common failure mode in which legal status, sector role, affected populations or external obligations are discovered only after the system has already been designed or deployed.

Enlarge

Back to contents

6. Assurance Claims, Evidence, EQ1-EQ9 and Defeaters

6.1 Claims first, evidence second

CI-AIGAF treats evidence as support for explicit assurance claims rather than as a volume of documentation. A claim states what must be true for the proposed operational authority to be justified. The argument explains why the evidence supports the claim. Evidence quality then constrains how much authority that support can carry.

Enlarge

6.2 Evidence quality dimensions

6.3 Counterevidence and defeaters

A credible assurance case records evidence that weakens a claim, not only evidence that supports it. Defeaters include failed tests, unexplained behavior, contradictory results, unsupported assumptions, monitoring blind spots, supplier opacity, fallback weakness, human-readiness gaps and changed conditions. Defeaters are resolved, bounded, accepted as residual risk, or treated as blockers. They are not silently averaged away.

6.4 Independent challenge

The stronger the requested authority and consequence, the stronger the need for independent challenge. CI-AIGAF uses independent challenge to test claim logic, evidence realism, missing scenarios, correlated failure, optimistic assumptions and organizational incentives before formal authorization.

Back to contents

7. AVE, OAE and Specialist Conditions Objects

7.1 Assurance Validity Envelope (AVE)

The AVE is a P13 assurance-case object describing the conditions under which the accepted claims and evidence remain valid. It is about the validity of the justification, not direct machine permission.

7.2 Operational Authority Envelope (OAE)

The OAE is the enforceable operational structure defining what the AI-enabled capability may and may not do. P03 defines the operational structure and enforceable constraints; P13 formally issues or changes the OAE. The OAE must remain within the conditions supported by the AVE.

Enlarge

7.3 Authority degradation

CI-AIGAF does not require authority to be treated as simply “approved” or “revoked.” Where evidence weakens or conditions change, pre-authorized runtime controls may warn, restrict, contain, fail safe, or move the service to a known fallback state. Restoration or expansion of formal authority returns to P13.

Enlarge

Back to contents

8. The Six Domains as One Operating System

The domains are not six sequential phases. They are concurrent assurance responsibilities that contribute to one authorization case. A supplier change in Domain III may invalidate continuity evidence in Domain IV, privacy conditions in Domain V, systemic assumptions in Domain VI and ultimately the P13 authority decision in Domain I.

Enlarge

Back to contents

9. Public Profiles of Practices P01-P18

How to use the profiles: begin with the “authority implication” for the Practice, then read its Tasks as the work needed to support, constrain or challenge the authorization case. You do not need to implement every Practice at the same depth for every use case.

The following profiles are intentionally more detailed than a marketing summary but shorter than the standalone Practice Specifications. Canonical Task wording is taken from the frozen Master Framework. Artifact examples are taken from the corresponding final Practice Specification. “Principal interfaces” and “authority implication” are public-reader synthesis and should be read alongside the controlling Practice text.

What must the AI achieve, what evidence will count, and does the integrated case justify the requested authority?

The Practice profiles that follow are public summaries of the frozen final specifications. They preserve canonical Task wording but omit implementation-level detail that remains in the standalone technical documents.

P01 — Establish Requirements for Success

Requirements, Baselines, Evidence and Authorization Preconditions

CI-AIGAF-P01 establishes the requirements, success criteria, operational baselines, evidence expectations, and acceptance logic that must exist before an AI-enabled capability can be evaluated for consequential operational use. It is a foundation Practice: later Practices may add controls, tests, and evidence, but they should not silently redefine what success means after evaluation has begun.

The Practice applies to AI systems, AI-enabled functions, agentic systems, general-purpose AI assistants whose outputs can enter operational workflows, and AI-generated operational artifacts where a consequential decision or action can reach a critical-infrastructure service directly or through a human-mediated path. Its focus is not limited to models; the governed object is the AI-enabled service, including relevant data, software, tools, interfaces, infrastructure dependencies, human roles, safety constraints, and fallback paths.

Public implementation questions (interpretive)

• What authoritative requirements and conflicts have been resolved before testing begins?
• What are the normal, stressed, degraded and fallback baselines?
• Were TEVV criteria and evidence requirements fixed before results were known?
• Which protected floors may not be traded away by optimization?
• What is claimed, what is demonstrated, and what is actually requested for authorization?

Principal interfaces: P02, P03, P04, P12, P13 and all Practices that consume requirements or protected floors.

Technical source: CI-AIGAF-P01, v1.0 Final Practice Specification.

How reliably may the system operate, what may it do, and can unsafe action be prevented, contained, overridden and recovered?

The Practice profiles that follow are public summaries of the frozen final specifications. They preserve canonical Task wording but omit implementation-level detail that remains in the standalone technical documents.

P02 — Define Robustness, Resilience, and Quality-of-Service Expectations

Operating Envelopes, Service Floors, Fallback, TEVV, Continuous Assurance and Reauthorization

CI-AIGAF-P02 establishes the dependable operating conditions under which an AI-enabled capability may influence a critical-infrastructure service. It translates the requirements and baselines established in Practice 1 into measurable operating margins, resilience controls, testable fallback, scenario-based assurance evidence, continuous monitoring signals, and predetermined authority responses.

The Practice deliberately distinguishes model robustness from service resilience. A model may remain statistically accurate while the service fails because of stale telemetry, queueing, cloud loss, operator overload, schema change, control-loop coupling, insufficient fallback capacity, or an upstream dependency. Conversely, a model can degrade without the service failing if independent constraints, fallback and human or deterministic recovery paths preserve the protected service floor.

Public implementation questions (interpretive)

• What service-level operating envelope is supported, beyond model accuracy alone?
• What happens under overload, dependency loss, drift and component variance?
• Is fallback genuinely independent, sufficiently capable and long-lasting?
• What monitoring signal would show that resilience evidence has stopped being valid?
• What authority response is pre-authorized when robustness or fallback degrades?

Principal interfaces: P01, P03, P04, P11, P13.

Technical source: CI-AIGAF-P02, v1.0 Final Practice Specification.

P03 — Govern Automated and Agentic Operational Authority

Operational Authority Envelopes, Independent Enforcement, Dynamic Delegation, Cumulative Action, Continuous Assurance and Reauthorization

Practice 3 applies whenever AI can directly execute consequential actions, materially influence a consequential human decision, generate artifacts likely to enter an operational path, invoke tools or services, delegate work to other agents, obtain or exercise machine credentials, manipulate shared resources, or alter the conditions under which essential services are delivered.

The Practice therefore applies to more than autonomous controllers. A general-purpose assistant that drafts a configuration, incident runbook, software patch or customer-impact decision can fall within the governed decision-action surface when its output is promoted into consequential use. Likewise, a vendor-managed service can be within scope even when the organization does not control the underlying model, because the organization still controls whether and how the service is granted operational influence.

Public implementation questions (interpretive)

• Which decisions and actions are consequential, and what can the AI reach directly or indirectly?
• What is explicitly permitted, conditional, emergency-only or prohibited?
• Can high-consequence boundaries be enforced independently of the AI being governed?
• How are identity, tools, delegation, memory and cumulative action bounded?
• What happens automatically when observability, enforcement or dependency conditions degrade?

Principal interfaces: P04, P05, P10, P12, P13, P18.

Technical source: CI-AIGAF-P03, v1.0 Final Practice Specification.

P04 — Engineer Emergency Avoidance, Override, Recovery, and Situation Awareness

Intervention Readiness, Machine-Speed Protection, Attention Governance, Independent Control, Recommissioning and Reauthorization

P04 applies when AI can influence or execute actions whose consequences may require urgent prevention, restriction, override, containment, degraded operation, emergency coordination or recovery. It covers automated control, agentic workflows, AI-generated operational artifacts used by people or machines, decision support that materially shapes intervention, and AI embedded in critical digital or cyber-physical operating environments.

The governed object is the emergency intervention system surrounding the AI-enabled service: people, roles, controls, safety wrappers, emergency states, independent monitoring and communications, alarms, supervision capacity, local/manual access, fallback, drills, evidence, state confirmation and authority restoration.

Public implementation questions (interpretive)

• Can the claimed human actually detect, understand, decide, access and intervene before harm?
• What is the measured end-to-end intervention-time budget?
• Which hazards require machine-speed independent protection?
• Can emergency control survive loss of the primary network, identity path, telemetry or cloud?
• What evidence is required before AI authority is recommissioned after an incident?

Principal interfaces: P03, P09, P11, P13.

Technical source: CI-AIGAF-P04, v1.0 Final Practice Specification.

What is acting, what may it access, where did it come from, what changed, and can every consequential action be attributed?

The Practice profiles that follow are public summaries of the frozen final specifications. They preserve canonical Task wording but omit implementation-level detail that remains in the standalone technical documents.

P05 — Implement Identity and Access Management for AI Agents, Systems, and Tools

Identity and Access Management for AI Agents, Systems and Tools

AI agents and sub-agents, including ephemeral task or session instances.

AI services, model services, orchestration components, plugins, tools and machine-to-machine execution paths.

Public implementation questions (interpretive)

• Does every consequential AI entity have a distinct accountable identity?
• Are credentials purpose-bound, least-privilege, time-bounded and revocable?
• Can delegation or capability inheritance exceed the parent authority ceiling?
• Are privilege use and identity anomalies visible continuously?
• Can emergency disablement work under degraded operating conditions?

Principal interfaces: P03, P07, P10, P13.

Technical source: CI-AIGAF-P05, v1.0 Final Practice Specification.

P06 — Govern External AI Supply Chain and Third-Party Risk

Supplier Assurance, Material Change, Dataflow, Concentration and Exit Governance

P06 governs the operational assurance area expressed by its canonical Tasks. It is designed to produce evidence and conditions that can be used by the integrated CI-AIGAF authorization case rather than to function as a stand-alone compliance checklist.

Public implementation questions (interpretive)

• What external AI and nth-party dependencies are critical to the service?
• What supplier evidence is required before dependence is created?
• Do contracts provide audit, evidence, update, incident, continuity and exit rights?
• How will unannounced supplier change be detected and governed?
• What concentration, substitution, portability and exit risks remain?

Principal interfaces: P07, P11, P18, P13.

Technical source: CI-AIGAF-P06, v1.0 Final Practice Specification.

P07 — Manage Internal AI Supply Chain, Configuration, and Provenance

Configuration Truth, Data/Knowledge Lineage, Controlled Change and Revalidation

P07 governs the operational assurance area expressed by its canonical Tasks. It is designed to produce evidence and conditions that can be used by the integrated CI-AIGAF authorization case rather than to function as a stand-alone compliance checklist.

Public implementation questions (interpretive)

• Is there one authoritative inventory of AI deployments, use cases and configurations?
• Can data, knowledge, retrieval and memory provenance be traced bidirectionally?
• Does the running configuration match the configuration represented by assurance evidence?
• Which changes are material and require revalidation before promotion?
• Can the organization roll back to a validated configuration bundle?

Principal interfaces: P05, P06, P10, P12, P13.

Technical source: CI-AIGAF-P07, v1.0 Final Practice Specification.

Can the organization detect, understand, preserve evidence, respond, continue service, recover and learn?

The Practice profiles that follow are public summaries of the frozen final specifications. They preserve canonical Task wording but omit implementation-level detail that remains in the standalone technical documents.

P08 — Incorporate AI-Aware Incident Analysis and Response

Recognize, Stabilize, Preserve, Investigate, Recover, Recommission and Learn

P08 governs the operational assurance area expressed by its canonical Tasks. It is designed to produce evidence and conditions that can be used by the integrated CI-AIGAF authorization case rather than to function as a stand-alone compliance checklist.

Public implementation questions (interpretive)

• What counts as an AI incident, anomaly, near-miss or control failure?
• Can the organization preserve enough evidence to reconstruct decision and action chains?
• Are attack, non-adversarial risk, interaction and unknown causes kept distinct during triage?
• Which runtime containment actions are pre-authorized?
• What evidence is required before recommissioning and formal authority restoration?

Principal interfaces: P10, P11, P17, P13.

Technical source: CI-AIGAF-P08, v1.0 Final Practice Specification.

P09 — Provide Calibrated AI Risk Training and Workforce Readiness

Competence, Qualification, Human-AI Reliance, Intervention and Skill Sustainment

P09 governs the operational assurance area expressed by its canonical Tasks. It is designed to produce evidence and conditions that can be used by the integrated CI-AIGAF authorization case rather than to function as a stand-alone compliance checklist.

Public implementation questions (interpretive)

• Which roles are materially affected by AI and what decision rights do they hold?
• What competence is required for ordinary use, challenge, override, incident and recovery?
• Does training address over-trust and under-trust rather than only tool familiarity?
• Can operators still perform manual/fallback functions after prolonged automation?
• What evidence shows that competence is current across shifts, sites, languages and suppliers?

Principal interfaces: P03, P04, P08, P11, P13.

Technical source: CI-AIGAF-P09, v1.0 Final Practice Specification.

P10 — Establish Multi-Tiered AI Logging, Evidence, and Audit Capabilities

Decision-Level Evidence, Integrity, Correlation, Reconstruction and Continuous Assurance

Predictive, optimization, generative, retrieval-augmented, embedded, autonomous and agentic AI used in IT, OT, ICS and cyber-physical environments.

AI-generated or AI-modified operational artifacts, including code, configuration, procedures, plans, queries and decision-support outputs.

Public implementation questions (interpretive)

• What must be logged at decision and execution level for the requested authority?
• Can logs reconstruct prompt/context/tool/identity/guardrail/action chains where needed?
• Are time, provenance and integrity strong enough for forensic and assurance use?
• How are privacy/confidentiality constraints balanced with evidence needs?
• Does loss of logging or correlation capability automatically reduce permissible authority?

Principal interfaces: P03, P08, P13, P14, P17.

Technical source: CI-AIGAF-P10, v1.0 Final Practice Specification.

P11 — Maintain AI-Aware Mission Continuity and Disaster Recovery

Minimum-Service Continuity, Independent Fallback, Recovery Integrity and Evidence-Based Recommissioning

Planned and unplanned AI restriction, suspension, isolation, provider withdrawal, cloud loss, identity/control-plane loss, data/RAG corruption, model uncertainty, tool/orchestration failure and evidence-plane degradation.

Normal, constrained, deterministic-safe, manual/legacy, recovery/shadow and recommissioned operating states.

Public implementation questions (interpretive)

• Which essential functions depend on AI and what minimum service must survive AI loss?
• What dependencies and shared failure domains can defeat continuity plans?
• Are manual, degraded and alternate operating modes actually resourced and exercised?
• Can data, models, configurations and state be restored coherently?
• What prevents service recovery from being mistaken for automatic restoration of AI authority?

Principal interfaces: P04, P06, P16, P18, P13.

Technical source: CI-AIGAF-P11, v1.0 Final Practice Specification.

Can the organization validate what AI creates, understand consequential decisions, and control information use and inference?

The Practice profiles that follow are public summaries of the frozen final specifications. They preserve canonical Task wording but omit implementation-level detail that remains in the standalone technical documents.

P12 — Validate AI-Generated Operational Logic and Artifacts

Requirements, Independent Verification, Representative Validation, Controlled Promotion and Lifecycle Assurance

P12 governs the operational assurance area expressed by its canonical Tasks. It is designed to produce evidence and conditions that can be used by the integrated CI-AIGAF authorization case rather than to function as a stand-alone compliance checklist.

Public implementation questions (interpretive)

• Which AI-generated artifacts can directly or indirectly reach operational execution?
• Were requirements and test oracles defined before generation?
• What deterministic verification and representative operational validation are required?
• Are generation, verification, approval, promotion and deployment authorities separated?
• What happens when a generated artifact drifts from documentation or the running environment changes?

Principal interfaces: P03, P07, P10, P13.

Technical source: CI-AIGAF-P12, v1.0 Final Practice Specification.

P13 — Maintain an Integrated AI Assurance Case and Formal Authorization Decision

Claim-Argument-Evidence Integration, Evidence Sufficiency, Residual Risk, Bounded Authority, Continuous Assurance and Reauthorization

CI-AIGAF-P13 requires organizations to assemble, evaluate, challenge, authorize, maintain and retire an integrated body of assurance for each consequential AI deployment. It applies before initial production authorization, when authority increases, after material change, following serious incidents or near misses, when evidence expires or becomes unreliable, and whenever law, mission need, risk tolerance or operating assumptions materially alter the decision basis.

The governed object is not the model alone. The assurance case covers the AI-enabled operational service and the exact authority requested: model and configuration, data and knowledge sources, tools, identities, permissions, orchestration, safeguards, interfaces, human roles, fallback, suppliers, dependencies, affected services and populations, operating conditions, monitoring, recovery and the time period for which the evidence remains credible.

Public implementation questions (interpretive)

• What exact authority is being requested and by whom?
• What top-level claims must be true for that authority to be justified?
• Where are evidence limitations, counterevidence, uncertainty and dissent recorded?
• What does independent challenge say the organization may be overlooking?
• What AVE and OAE are justified, and what conditions force degradation or reauthorization?

Principal interfaces: All Practices; sole formal authorization engine.

Technical source: CI-AIGAF-P13, v1.0 Final Practice Specification.

P14 — Establish Explainability, Interpretability, and Operational Decision Transparency

Explanation Contracts, Decision Windows, Fidelity, Protected Disclosure and Operational Actionability

Predictive, optimization, generative, embedded, autonomous and agentic AI; AI-generated operational artifacts; and AI embedded in larger products or managed services.

Immediate operator cues, operational rationales, engineering diagnostics, assurance explanations, incident/audit evidence and affected-party/public-safe explanations.

Public implementation questions (interpretive)

• Who needs an explanation, for what decision, consequence and time window?
• Is the explanation faithful enough to support the claimed operational or accountability use?
• Does it communicate uncertainty, evidence limits, alternatives and guardrail state?
• Can users comprehend and act on it under realistic operating pressure?
• What security, privacy or confidentiality limits constrain explanation content?

Principal interfaces: P03, P04, P10, P17, P13.

Technical source: CI-AIGAF-P14, v1.0 Final Practice Specification.

P15 — Govern AI Privacy, Sensitive Inference, and Purpose Limitation

Purpose-Bound Data and Inference Authority, Privacy Engineering, Correctability and Continuous Reauthorization

Training, fine-tuning, evaluation, retrieval, prompts, embeddings, vector stores, memory and model-resident information.

Telemetry, sensors, voice/video/location, customer/workforce/device/service data, generated summaries and derived operational information.

Public implementation questions (interpretive)

• What data and sensitive inferences are created, linked or exposed across the AI-enabled service?
• Is processing bounded to an authorized purpose and are secondary uses controlled?
• How are proxy inference, group privacy, memory and retrieval governed?
• What testing covers memorization, extraction, re-identification and leakage?
• Which privacy conditions constrain the authority P13 can support?

Principal interfaces: P07, P10, P16, P17, P13.

Technical source: CI-AIGAF-P15, v1.0 Final Practice Specification.

Who bears the consequences, can affected parties obtain practical review/remedy, and can local AI action cause wider systemic harm?

The Practice profiles that follow are public summaries of the frozen final specifications. They preserve canonical Task wording but omit implementation-level detail that remains in the standalone technical documents.

P16 — Assure Fair, Accessible, and Equitable Delivery of Essential Services

Distributional Service Assurance, Functional Equivalence, Essential-Service Floors and Burden-Shifting Governance

AI that predicts, prioritizes, allocates, schedules, routes, restores, denies, restricts, prices, inspects, communicates, authenticates, detects fraud, allocates maintenance or otherwise influences an essential-service outcome.

Customers, workers, contractors, communities, facilities, organizations, public-interest users and dependent sectors directly or indirectly affected by the service.

Public implementation questions (interpretive)

• Which populations, geographies and service pathways can be differently affected?
• What baseline inequities already exist before AI is introduced?
• What distributional, accessibility and worst-case requirements are protected floors?
• Could optimization shift burden onto less visible groups or locations?
• What production disparity would trigger remediation, restriction or reauthorization?

Principal interfaces: P11, P15, P17, P18, P13.

Technical source: CI-AIGAF-P16, v1.0 Final Practice Specification.

P17 — Establish Stakeholder Engagement, Contestability, Notification, and Redress

Affected-Party Participation, Actionable Notice, Correction, Qualified Human Review, Effective Remedy and Public Accountability

AI-enabled decisions or actions that materially affect essential-service access, safety, priority, restoration, price, inspection, enforcement, eligibility, routing, staffing, resource allocation or another material interest.

Direct, indirect, cumulative, emergency, worker, community, customer, supplier, regulator and dependent-sector impacts.

Public implementation questions (interpretive)

• Who is affected and who is missing from engagement or representation?
• When must people receive proactive or event-triggered notice?
• Can affected parties correct data, context or facts and obtain timely human review?
• Are grievance and emergency channels actually accessible and protected from retaliation?
• Do case patterns feed back into assurance and reauthorization rather than ending at complaint closure?

Principal interfaces: P08, P14, P15, P16, P13.

Technical source: CI-AIGAF-P17, v1.0 Final Practice Specification.

P18 — Manage Cross-Sector Interdependencies, Common-Mode Failure, and Cascading AI Risk

Cross-Sector Interdependencies, Common-Mode Failure and Cascading AI Risk

AI-enabled essential functions whose failure, output, optimization, action, shared provider or restoration sequence can affect another organization, operator, sector, population or public authority.

Upstream, downstream, reciprocal and hidden dependencies across physical infrastructure, communications, compute, data, identity, time, suppliers, workforce, logistics, finance/market, geography and governance/coordination.

Public implementation questions (interpretive)

• Which essential functions and sectors depend on the same AI, cloud, identity, data, workforce or suppliers?
• What local actions can propagate through feedback, scarcity or common-mode failure?
• Where are systemic authority boundaries and shared-resource budgets set?
• Have joint scenarios and recovery-sequencing conflicts been exercised?
• Which systemic decisions cannot be delegated because evidence does not uniquely determine the acceptable allocation of harm or scarcity?

Principal interfaces: P06, P11, P16, P13.

Technical source: CI-AIGAF-P18, v1.0 Final Practice Specification.

Back to contents

10. How the Practices Connect

CI-AIGAF is designed as an integrated assurance system. The most important interfaces are not editorial cross-references; they are evidence and authority handoffs. The following public map summarizes eight seams frozen during release reconciliation.

Enlarge

Back to contents

11. Worked Authorization Examples

The Master Book contains five end-to-end worked cases. The table below summarizes their differing outcomes. The examples are explanatory and non-normative; they demonstrate the framework reasoning under stated facts. No outcome creates a precedent for another system, sector or authority request, which must be decided on its own evidence and operating conditions.

Enlarge

11.1 Condensed example: bounded agentic network optimization

A network-optimization agent is permitted to execute a constrained set of low-level optimization actions across a defined network domain. The use case is not authorized merely because the agent performs well in simulation. The assurance case must establish requirements and protected service floors, representative behavior under congestion and degraded telemetry, identity and tool constraints, non-bypassable action limits, cumulative-action budgets, rollback, operator readiness, logging and incident/continuity capability. P13 then issues an OAE that limits the action set, geography, resources, rate, sequence, duration, delegation and fallback behavior. Runtime signals watch not only model performance but also enforcement health, telemetry quality, cumulative action, human-supervision capacity and dependency state. A material change to topology, tool permissions, model version or fallback availability triggers validity review and can automatically reduce the authority before targeted reassurance and reauthorization.

11.2 Condensed example: machine-speed grid stabilization

A grid-stabilization service requests authority to make bounded corrective adjustments when frequency or voltage conditions can deteriorate faster than an operator can detect, diagnose, authorize and actuate a response. CI-AIGAF does not remove human accountability: people still define the protected operating envelope, approve the authority, review evidence and own recovery. It does, however, reject nominal human oversight as the immediate safeguard where the demonstrated intervention chain is slower than credible time-to-harm. Conditional authority therefore depends on independently enforceable machine-speed protections such as deterministic operating limits, rate and resource bounds, non-bypassable interlocks, rapid isolation, safe-state transitions and continuously tested fallback. The authorization record must identify the timing evidence, safeguard independence, failure assumptions, stop conditions and the human decisions that remain authoritative. If telemetry, interlock health, fallback availability or intervention readiness leaves the validated envelope, runtime controls narrow or suspend the authority and formal restoration returns to P13.

Enlarge

11.3 Condensed example: cross-sector autonomy deferred

A proposed cross-sector orchestration capability seeks authority to coordinate telecom load, energy availability and cloud resource allocation during regional stress. Local optimization can create cross-sector scarcity and cascading effects. P18 therefore requires dependency mapping, shared-concentration analysis, propagation and common-mode scenarios, scarcity governance, coordination triggers and recovery sequencing. Where evidence does not uniquely determine who should bear scarcity, or where multi-party institutional authority is missing, the governance result is not “approve with more monitoring.” P13 can defer A4 authority. The system may remain in a lower authority mode while human institutions retain adjudication of high-consequence scarcity and priority conflicts.

Back to contents

12. Practical Adoption Path

For a first implementation, do not translate the framework into eighteen independent projects. Select one real AI-enabled service, define the authority being requested, identify the consequence context, and build one traceable evidence-to-authority path. Use Appendix D as the minimum authorization evidence-pack anchor, then increase depth, realism and independence according to the requested authority and consequence.

1. Run R0: establish intended purpose, organizational role, sector/jurisdiction overlays, affected interests and unresolved legal questions.
2. Establish mission and requirements through P01: success criteria, baselines, protected floors, evidence plan and acceptance preconditions.
3. Classify requested authority, consequence and assurance posture; identify applicable Practices and accountable owners.
4. Build or acquire only where the organization can obtain sufficient identity, provenance, supplier rights, configuration control, fallback and evidence access.
5. Generate representative assurance evidence and record counterevidence, uncertainty, evidence-quality limitations and unresolved risk.
6. Construct the integrated P13 assurance case; conduct independent challenge; formally decide the AVE and OAE.
7. Complete G6 operational readiness: people, logging, monitoring, incident response, continuity, emergency control, communications and rollback.
8. Operate under continuous assurance. Treat material change, near-miss, monitoring degradation and control impairment as authority-relevant events.
9. Degrade, contain or pause according to pre-authorized response when conditions leave the validated envelope.
10. Reassure only what changed; return formal authority restoration or expansion to P13; archive and learn when the capability is retired.

12.1 Illustrative 30/60/90-day adoption sequence

This sequence is an implementation aid, not a fixed certification timetable. High-consequence systems may require longer evidence generation, joint exercises, supplier remediation, legal review or staged authority increases.

12.2 Proportionate adoption profile

A minimum viable implementation is not permission to ignore applicable Practices. It is a staged way to establish the complete authorization spine at proportionate depth, beginning with one consequential service. Depth, independence and evidence realism increase with requested authority, consequence and uncertainty.

Scaling rule — No profile waives an applicable legal, safety, security, rights or essential-service obligation. Where a Practice is not applicable, record the rationale; where it is applicable, scale its evidence and independence to the decision weight it must carry.

Back to contents

13. External Alignment and Source-Status Discipline

CI-AIGAF is intentionally independent. It uses external law, standards and frameworks as crosswalks and evidence sources while keeping internal Practice and Task identifiers stable. External renumbering or revision should therefore trigger crosswalk maintenance rather than automatic redesign of CI-AIGAF.

13.1 NIST AI RMF

The frozen v1.0 release maps CI-AIGAF outcomes to NIST AI RMF functions/categories/subcategories where aligned. NIST alignment supports interoperability; CI-AIGAF’s evidence-to-authority, AVE/OAE, invalidation and reauthorization architecture remains an Institute for Technology Stewardship design.

13.2 NIST critical-infrastructure profile work

The August 2026 Trustworthy AI in Critical Infrastructure material used during the build is explicitly a Community of Interest discussion draft and is not official guidance. CI-AIGAF treats it as an external alignment input, not as a certification basis or source of authority.

13.3 EU AI Act and complementary EU law

CI-AIGAF v1.0 includes operational-support crosswalks to relevant AI Act obligation families and complementary critical-infrastructure/cyber-resilience law. These mappings are implementation aids, not legal conclusions, and the framework does not create a presumption of conformity. Organizations should verify the current consolidated legal text, role, system classification, sector law and competent-authority interpretation at point of use.

13.4 ISO/IEC, IEC and sector standards

Practice specifications reference management, risk, resilience, security, safety and sector standards where they provide useful implementation or evidence anchors. CI-AIGAF does not reproduce licensed standards and does not claim conformance to them merely by referencing their concepts.

Back to contents

14. Framework Governance, Release and Citation

CI-AIGAF v1.0 is architecture-frozen. Maintenance may correct defects, improve crosswalks, clarify wording, update external references or add implementation resources without silently changing the core authority architecture. Changes to the six-domain/eighteen-Practice structure, P13 authorization ownership, AVE/OAE architecture, evidence-to-authority chain, EQ1-EQ9 or material-change/reauthorization model would require explicit architecture-governance treatment.

14.1 How to cite

Recommended framework citation: Institute for Technology Stewardship (2026), CI-AIGAF v1.0: Critical Infrastructure AI Governance & Assurance Framework — Public Framework Specification, Version 1.0.

When citing a technical requirement or implementation detail, cite the relevant standalone Practice Specification and identifier (for example, CI-AIGAF-P03, P03-T02, or a specific P03-T02-Ixx implementation) rather than relying only on this public summary.

14.2 Feedback and implementation learning

Public use should generate feedback on operational feasibility, evidence burden, cross-sector transferability, ambiguity, missing failure modes, and where authority logic is difficult to implement in legacy or resource-constrained environments. Such feedback is valuable even where it does not immediately change the frozen architecture; it can improve implementation resources, crosswalks, sector overlays and future major versions.

Framework home: technologystewardship.org

Back to contents

Appendix A. Practice Quick-Reference Matrix

Back to contents

Appendix B. Evidence Quality Dimensions EQ1-EQ9

Back to contents

Appendix C. Material-Change Catalogue MC-01-MC-12

Back to contents

Appendix D. Minimum Authorization Evidence Pack

The exact evidence pack is risk- and context-dependent. The following public checklist captures the common categories reflected across the frozen Master Framework and Practice set. It is not a substitute for the detailed evidence requirements of applicable Practices.

• R0 applicability, role and obligation record.
• Defined AI-enabled service boundary, intended purpose and accountable owner.
• Requested authority tier, consequence tier and assurance-class rationale.
• Mission/service requirements, protected floors and prohibited outcomes.
• Baseline and TEVV evidence under representative normal, stressed, degraded and fallback conditions.
• Assurance claims, arguments, evidence references and EQ1-EQ9 assessment.
• Counterevidence, defeaters, assumptions, uncertainty and residual risk.
• Identity, access, delegation, configuration and provenance evidence.
• Independent enforcement, fallback, emergency intervention and human-feasibility evidence where relevant.
• Logging, incident response, continuity and recovery readiness.
• Privacy, explanation, equity/accessibility, contestability/remedy and systemic-risk conditions where applicable.
• Independent challenge and dissent record.
• P13 authorization decision, AVE and OAE.
• Runtime signals, thresholds, material-change triggers, degradation responses and reauthorization conditions.

Back to contents

Appendix E. Glossary of Core CI-AIGAF Terms

End of public framework specification

For implementation depth, use the eighteen final standalone CI-AIGAF Practice Specifications P01-P18 issued in the CI-AIGAF v1.0 Technical Release Package. The Master Book is the separate expanded practitioner and worked-case companion. This public document makes the architecture inspectable without requiring a reader to begin with the full technical corpus.

Back to contents

Authorizing AI in Critical Infrastructure

Who decides what AI may do, on what evidence, and when permission must be withdrawn

A board-level narrative for accountable owners who must fund, approve and remain answerable for consequential AI-enabled services.

PUBLIC COMPANION | CI-AIGAF VERSION 1.0