The Regulated AI Operating Envelope

SECTOR INTELLIGENCE WHITE PAPER

Governing Healthcare Intelligence and Energy Dependency as One Enterprise Risk System

Glenn E. Daniels II, Touch Stone Publishers
Publication date: August 31, 2026

Executive Summary

This white paper makes one specific argument: a healthcare enterprise has not governed a material AI system when it has validated the model but cannot prove that the surrounding workflow, infrastructure, decision rights, and evidence remain inside approved boundaries. Model assurance without operating-system assurance creates a control record that is technically detailed and institutionally incomplete.

The failure mechanism is Approval Drift. A system receives approval for one model, population, workflow, human review, and infrastructure configuration. The model may remain unchanged while data sources, prompts, thresholds, users, vendors, cloud regions, recovery procedures, or operating pressure change around it. Each adjustment appears manageable inside one function. Their combined effect moves the live system beyond the evidence on which approval depended.

Healthcare and energy meet inside this failure mechanism. The U.S. Food and Drug Administration's lifecycle-oriented guidance treats context, bounded change, validation, and impact assessment as material to AI-enabled medical products. The U.S. Department of Energy reported that data centers consumed approximately 4.4 percent of U.S. electricity in 2023 and projected a range of 6.7 to 12 percent by 2028. The U.S. Government Accountability Office added the necessary qualification: the share attributable specifically to generative AI remains unclear. The evidence does not support a universal claim that AI creates an energy crisis. It does establish that infrastructure dependency and uncertainty belong inside the assurance case for AI-dependent operations.

Boards currently receive the relevant facts through separate channels. Clinical and quality leaders report model performance. Technology leaders report availability and security. Finance reports cloud cost. Operations reports workflow outcomes. Compliance reports regulatory status. The enterprise can therefore accumulate five competent component reviews without producing one defensible statement that the assembled system remains fit for its approved purpose.

Three governing arguments organize the analysis.

First: approval must attach to an operating envelope, not to a model in isolation. The approved object is the full decision system: purpose, population, data, model, interface, user, infrastructure, human intervention, escalation, and evidence. A change to any material element can reopen the assurance decision even when the algorithm itself does not change.

Second: infrastructure is part of clinical assurance when service continuity affects the regulated purpose. Compute, network, power, cooling, cloud region, vendor concentration, and recovery are not secondary technology details. They define whether the system can perform safely, continuously, and economically under the conditions management represented to the board.

Third: governance becomes defensible only when accountability and evidence survive the people who created the system. Delaware oversight doctrine supports reasonable information systems and upward reporting within an officer's sphere of responsibility. It does not establish automatic AI liability. The practical governance response is nonetheless clear: assign authority, define red flags, preserve challenge, document exceptions, and renew the evidence before temporary assumptions become permanent approvals.

The paper introduces the CLEAR Operating Envelope. CLEAR requires management to prove five conditions: Context, Lifecycle, Energy and infrastructure, Accountability, and Record. It converts fragmented reviews into one renewable governance file and gives the board a precise basis for deciding whether a system should scale, remain restricted, receive additional investment, or exit.

This is not a vendor-selection paper or a general warning about AI. It is a working standard for boards, executive teams, health systems, regulated manufacturers, utilities, and infrastructure-dependent enterprises. The reader will leave with a defined failure mechanism, an integrated assurance framework, the contents of a defensible governance record, four evidence cases, and a 90-day board action protocol.

1. AI Risk Becomes Governable Only When Clinical Decisions and Physical Dependencies Are Reviewed Together

The central problem is not that healthcare organizations lack AI policies or that energy organizations lack load forecasts. The problem is that enterprise governance separates the decision logic from the physical system on which that logic depends. An AI-enabled clinical workflow may be evaluated for accuracy, bias, cybersecurity, and regulatory status while its cloud concentration, power dependency, cooling constraint, and recovery design remain buried in technology or vendor records. The board receives assurance about the model without receiving assurance about the operating envelope.

This separation is structurally unsound. A healthcare AI system does not create value when a model exists. It creates value when data is lawfully available, infrastructure is reliable, the model performs within a defined context, authorized people can intervene, changes remain controlled, and evidence of those conditions can be produced. Failure in any one of those layers can invalidate the intended use of the whole system.

The FDA's January 2025 draft guidance for AI used to support regulatory decision-making for drug and biological products illustrates the importance of context. It describes a risk-based credibility assessment framework tied to a particular context of use. The document is draft guidance, expressly nonbinding, and not for implementation. Its value is therefore directional rather than compulsory. It shows that a model is not credible in the abstract. Credibility is evaluated for the specific role, scope, evidence, and decision in which the model is used.

The FDA's August 2025 final guidance for predetermined change control plans provides a more concrete example for AI-enabled device software functions. A plan can describe defined modifications, the methods used to develop, validate, and implement them, and an assessment of their impact. FDA reviews such a plan as part of an applicable marketing submission so that specified modifications may occur without a separate submission for every change, provided the authorized conditions are satisfied. This is controlled adaptability, not unrestricted autonomy.

Energy constraints change the same risk equation. DOE's Lawrence Berkeley National Laboratory analysis found that U.S. data centers used about 176 terawatt-hours in 2023, or 4.4 percent of total U.S. electricity, and projected 325 to 580 terawatt-hours by 2028. The wide range is itself governance evidence. It means capital plans, interconnection assumptions, and operating-cost forecasts are exposed to significant uncertainty. GAO added the essential qualifier that estimates for data centers should not be silently converted into estimates for generative AI alone.

GOVERNING EVIDENCE

• FDA's January 2025 credibility framework for drug and biological-product decisions is draft, nonbinding guidance tied to a particular context of use.
• FDA's August 2025 guidance on predetermined change control plans for AI-enabled device software functions is final guidance.
• DOE reported data-center electricity use of approximately 4.4 percent of total U.S. electricity in 2023.
• DOE projected a range of 6.7 to 12 percent by 2028, reflecting substantial planning uncertainty.
• GAO stated that the portion of data-center electricity attributable specifically to generative AI is unclear.
• European Commission transparency rules applying from August 2, 2026 cover defined AI interactions and categories of generated or manipulated content, not every AI output without distinction.

The governance gap appears when management presents each fact independently. The clinical committee receives model metrics. The audit committee receives risk summaries. The technology committee receives uptime and cybersecurity data. The finance committee receives energy and cloud spend. No committee receives the integrated statement: this system is operating inside its approved clinical, technical, financial, and physical boundaries.

Three Transfers That Conventional Governance Misses

The first transfer is from model risk to workflow risk. An AI model can perform within its validated range while the surrounding workflow creates failure. A user may rely on the output for a purpose outside the approved context, an interface may hide a material limitation, or a staffing change may remove the human review on which the validation depended. The system risk therefore sits in the relationship among model, data, interface, user, and decision, not in the model alone.

The second transfer is from software economics to infrastructure economics. AI programs are often approved through software budgets and evaluated through labor savings, throughput, or service improvement. The operating cost subsequently appears through cloud consumption, network traffic, storage, specialized compute, resilience, and vendor concentration. An investment case that separates model value from infrastructure cost can show a positive return while the total operating system consumes more capital and creates more concentration risk than management disclosed.

The third transfer is from technical monitoring to fiduciary information. Engineers can monitor drift, latency, failure rates, and incidents without producing information that allows an officer or board committee to discharge its oversight role. Fiduciary reporting requires translation: which boundary was crossed, what consequence became possible, who had authority to act, what response occurred, and whether the remaining risk fits the approved appetite. Telemetry becomes governance only after it is connected to a decision.

These transfers create a recurring pattern. Every functional team can perform its assigned work competently while the enterprise remains unable to prove that the assembled system is controlled. That is the difference between component assurance and operating-system assurance.

Exhibit 1: The Regulated AI Dependency Chain

Layer	Governing question	Typical evidence	Failure if reviewed alone
Intended decision	What judgment or action does the system support?	Context-of-use statement, clinical or operational purpose	Purpose is stated without proving fitness
Data	What inputs are permitted and representative?	Lineage, quality tests, population analysis, access record	Good data is assumed to remain stable
Model	What performance is required within the approved context?	Validation, thresholds, limitations, drift measures	Model metrics substitute for workflow safety
Workflow	How do people interpret, challenge, override, and escalate outputs?	Procedures, training, override logs, decision rights	Human oversight exists on paper but not in operation
Infrastructure	What compute, network, power, cooling, and vendor conditions are required?	Architecture, capacity, resilience, recovery tests	Technical availability is not translated into service continuity
Governance record	What can the enterprise prove before and after a failure?	Approvals, changes, exceptions, incidents, renewal decisions	Activity exists but accountability cannot be reconstructed

The dependency chain changes the unit of governance. The object requiring approval is not the algorithm, contract, or application. It is the complete decision system operating inside a defined set of clinical, technical, physical, and organizational conditions.

STRUCTURAL DEFINITION: APPROVAL DRIFT

Approval Drift occurs when changes to data, workflow, users, interfaces, infrastructure, vendors, thresholds, or human intervention move a live AI system beyond the evidence and conditions on which its original approval depended.

2. Existing Controls Protect Components but Leave the Assembled System Ungoverned

Most organizations begin with one of four control approaches. Each contributes something useful. None produces the integrated assurance required for regulated AI operations.

The first approach is model-centric validation. Management tests accuracy, sensitivity, specificity, calibration, hallucination rates, or other performance measures. This work is indispensable because poor model performance can harm patients, distort regulated evidence, or produce unreliable operational decisions. The limitation is that model-centric validation often assumes the surrounding data, workflow, infrastructure, and human response system will behave as designed. That assumption belongs in the evidence record, not outside it.

The second approach is policy-centric governance. The organization adopts principles for responsible AI, assigns an executive sponsor, establishes prohibited uses, and creates an inventory. These controls establish expectations and ownership. They fail when the inventory describes an application without defining its operating boundaries, dependencies, change pathways, and evidence requirements. A policy can prohibit unsafe conduct. It cannot prove that a deployed system remained inside its approved envelope.

The third approach is technology-centric resilience. Infrastructure teams monitor availability, latency, incident response, cybersecurity, cloud concentration, and disaster recovery. These disciplines are mature compared with many AI governance programs. Their limitation is translation. A service can meet a technical uptime objective while failing a clinical requirement. It can recover within the contracted period while the interruption still creates an unacceptable patient-safety or regulatory consequence.

The fourth approach is compliance mapping. Counsel and compliance teams map the system against statutes, regulations, guidance, contracts, and sector standards. This reduces obvious legal gaps and helps management identify applicable obligations. It fails when compliance is treated as a static checklist for a system that changes through retraining, configuration, data drift, vendor updates, workflow redesign, or expanded use.

The strongest contrary position argues that integrating these disciplines creates excessive governance cost. Under this view, a health system should govern clinical safety, a cloud provider should govern infrastructure, a utility should govern power reliability, and counsel should govern legal interpretation. Distributed expertise is more efficient than a central AI control structure, and adding a cross-sector board framework risks slowing useful innovation.

That position is correct about expertise and wrong about accountability. CLEAR does not centralize technical decisions in the boardroom. It centralizes the evidence that the relevant decisions were made, connected, escalated, and reviewed. Distributed execution remains necessary. Fragmented assurance does not.

The integration deficit.

The weakness in current approaches is not the absence of control activity. It is the absence of a common decision object. Model validation evaluates one object, cybersecurity evaluates another, business continuity evaluates another, and legal review evaluates another. Each function can issue a qualified approval without establishing whether the qualifications are mutually compatible.

Consider a clinical model approved for a defined population and workflow. The technology team may move the service to a new region for resilience. The data team may replace an input feed. The vendor may update a model endpoint. Operations may reduce the review step to improve throughput. Each change can appear reasonable within one function. Together they can create a system that no longer matches the evidence on which the original approval rested.

The same problem appears in energy planning. A data-center connection request can be technically feasible, financially attractive to the developer, and consistent with a utility's interconnection process. The combined portfolio may still create uncertainty about generation, transmission, rate allocation, water, backup generation, and local resilience. Component decisions do not automatically produce a sound system decision.

Exhibit 2: What Each Control Approach Sees and Misses

Control approach	What it does well	What remains unseen	Required connection
Model validation	Measures performance against specified tests	Workflow, infrastructure, user behavior, cumulative change	Tie validation to context, workflow, and renewal triggers
Responsible AI policy	Establishes principles, prohibited uses, and sponsorship	Proof that a live system remained inside approved boundaries	Convert principles into system-specific operating limits
Cybersecurity and resilience	Protects confidentiality, integrity, availability, and recovery	Whether technical recovery restores safe regulated service	Translate system metrics into clinical and operational consequences
Legal and compliance review	Maps obligations and documents interpretations	Operational drift after approval	Link legal scope to change events and evidence renewal
Vendor management	Allocates contractual duties and monitors service commitments	Enterprise accountability for the assembled system	Map vendor controls to internal owners and fallback decisions
Financial approval	Tests budget, return, and capital requirements	Assurance cost, concentration, peak demand, failure response	Price the complete operating envelope and adverse scenarios

This integration requirement does not justify a new committee for every technology. It justifies one shared record that existing committees can interrogate from their own responsibilities. The audit committee can examine evidence and exceptions. The technology committee can examine architecture and resilience. The clinical or quality committee can examine context, validation, and patient consequence. The full board can examine whether those views reconcile.

The false comfort of human oversight.

Organizations frequently answer autonomy risk with the phrase “human in the loop.” The phrase carries little assurance without four additional facts: which person, reviewing what information, with what authority, under what time constraint. A nominal reviewer who lacks relevant expertise, receives an opaque output, or cannot stop the workflow is not a control. The person is a procedural decoration.

Effective human oversight must be designed as a decision function. The reviewer needs a defined trigger, sufficient information to challenge the system, authority to override or suspend it, and a record of the action. The organization also needs to test whether workload, alert frequency, and production pressure allow the reviewer to perform the role in practice.

That test matters across both sectors. A clinician facing alert fatigue and an energy operator facing excessive alarms share the same governance failure: the formal escalation path exists, but the operating environment prevents meaningful intervention. CLEAR treats the human role as part of the system's validated envelope rather than as a general assurance phrase.

FRICTION POINT: THE FALSE HANDOFF

A healthcare organization cannot transfer the full consequence of an AI failure by assigning infrastructure to a cloud vendor, validation to a model developer, and clinical judgment to a practitioner. Contracts allocate duties and remedies. They do not eliminate the enterprise's responsibility to understand whether the assembled system is fit for its intended use.

The same distinction governs fiduciary analysis. Delaware law recognizes oversight obligations for directors and, within their spheres of responsibility, officers. Officers must make good-faith efforts to establish relevant information systems and respond to or report red flags. Caremark claims remain difficult for plaintiffs, and liability depends on facts such as bad faith, mission-critical risk, reporting failures, ignored warnings, and the fiduciary's actual responsibilities. The doctrine supports disciplined reporting. It does not justify the categorical claim that an AI error automatically creates personal liability.

3. CLEAR Defines the Boundaries Management Must Prove

The CLEAR Operating Envelope converts fragmented control activity into one reviewable governance system. CLEAR stands for Context, Lifecycle, Energy and infrastructure, Accountability, and Record. Each dimension produces a defined decision, an owner, evidence, escalation thresholds, and a renewal date.

Context.

Context defines what the system is permitted to do. The record identifies the intended users, affected populations, input data, output, decision supported, degree of autonomy, required human judgment, prohibited uses, and conditions that invalidate performance. A diagnostic-support model used by trained clinicians in one workflow does not inherit credibility when moved to a consumer interface, a different population, or a different clinical purpose.

Context also prevents the phrase “AI system” from becoming too broad to govern. A model used for administrative routing presents a different risk from a model that supports a treatment decision. A forecasting model used for internal capacity planning presents a different risk from an automated control affecting energy dispatch. Materiality determines the depth of assurance.

A complete context record answers five tests. The purpose test states the decision the system supports. The population test states who or what is affected. The authority test states whether the output advises, recommends, decides, or executes. The reliance test states what human judgment remains necessary. The boundary test states which uses are prohibited even when technically possible. These tests turn scope from a description into an enforceable control.

Lifecycle.

Lifecycle defines how the system may change. The organization records approved modifications, validation methods, monitoring measures, implementation controls, rollback conditions, and cumulative-change limits. FDA's predetermined change control plan is a regulated example of the broader principle. A governed system specifies the change envelope before the change occurs.

Lifecycle control also distinguishes model change from system change. A model may remain constant while the data source, prompt structure, user interface, threshold, workflow, or human review step changes. Any of these can alter the system's risk. Change control therefore attaches to the operating configuration, not merely to the model version.

The lifecycle record should classify changes before they occur. Routine changes remain inside preapproved limits and require documented verification. Material changes require renewed validation and accountable approval. Emergency changes require a time-limited exception, compensating controls, and retrospective review. Prohibited changes cannot be introduced without redefining the context of use and reopening the approval.

This classification eliminates a common ambiguity. Teams no longer debate whether a change is “small” based on technical effort. They evaluate whether it alters the system's decision, affected population, evidence basis, infrastructure dependency, human control, or risk consequence.

Energy and infrastructure.

Energy and infrastructure define the physical and digital conditions required for the system to perform its intended function. The record includes cloud region, critical vendors, compute capacity, power and cooling dependencies, network requirements, recovery objectives, fallback procedures, and cost thresholds. For high-consequence healthcare uses, management must translate technical availability into clinical continuity.

The energy dimension also requires portfolio analysis. A single deployment may represent a modest load. Hundreds of models, imaging workflows, data pipelines, and autonomous agents can create a different cost and resilience profile. Management should report marginal demand, peak exposure, vendor concentration, and the cost of operating through disruption rather than presenting average cloud spend as the complete economic picture.

Healthcare and energy leaders also need a shared definition of criticality. A short service interruption may be financially tolerable in an administrative workflow and clinically unacceptable in a diagnostic or monitoring workflow. A backup architecture may meet a general recovery objective while failing the time window in which a regulated decision must occur. Infrastructure assurance becomes meaningful only when the technical recovery target is derived from the service consequence.

The energy record should therefore contain both demand and dependency. Demand states how much compute, storage, network, power, and cooling the portfolio uses under ordinary and peak conditions. Dependency states which vendors, regions, interconnections, facilities, and recovery paths must remain available. Demand determines capacity. Dependency determines fragility.

Accountability.

Accountability defines who decides, who operates, who validates, who can stop the system, who receives incidents, and who reports material red flags upward. The record should identify one accountable executive for the operating outcome while preserving distinct independent roles for clinical validation, security, compliance, and audit.

The board's role is not to approve model parameters. Its role is to approve the risk appetite, reporting architecture, escalation thresholds, and management accountability for material systems. The board must also verify that the assigned owner has the authority, information, and resources required to act.

Accountability requires separation as well as ownership. The executive responsible for realizing the system's value should not be the only person determining whether the system remains safe and compliant. Clinical validation, risk, security, compliance, and internal audit require sufficient independence to challenge the deployment. The operating owner decides within the approved envelope. An independent function tests whether that envelope is complete and whether management remained inside it.

Escalation should be based on consequences and boundaries rather than technical severity alone. A low-volume anomaly can be material if it affects a protected population, a regulatory submission, or a public disclosure. A high-volume technical event can remain operational if safe fallback procedures work. The escalation rule must connect the signal to the enterprise consequence.

Record.

Record defines what the organization must be able to prove. The evidence package includes approvals, system purpose, data lineage, validation results, change history, monitoring performance, incidents, overrides, exception decisions, vendor attestations, and retirement status. Retention periods should reflect regulatory, contractual, litigation, patient-safety, and learning requirements.

The record protects more than legal defensibility. It permits the organization to learn which controls worked, which thresholds failed, and which operating assumptions became stale. Without that evidence, every incident becomes an isolated event instead of institutional learning.

The record also establishes an institutional memory that survives personnel and vendor changes. A new executive should be able to understand why the system was approved, which assumptions carried the decision, what changed, which exceptions were accepted, and when the evidence must be renewed. Governance that exists only in the knowledge of the original team expires when that team changes.

Exhibit 3: CLEAR Minimum Evidence Standard

Dimension	Minimum approval evidence	Renewal trigger	Board-level exception
Context	Intended decision, population, autonomy, human role, prohibited uses	New use, population, user, or decision authority	Use expands before evidence is renewed
Lifecycle	Change classes, validation method, monitoring, rollback, cumulative limits	Model, data, interface, workflow, or threshold change	Material change enters production without approval
Energy and infrastructure	Capacity, critical dependencies, resilience, recovery, cost thresholds	Region, vendor, architecture, demand, or recovery change	Critical service lacks a tested fallback
Accountability	Owner, independent reviewers, stop authority, escalation and committee path	Reorganization, outsourcing, new material consequence	No single executive can order suspension
Record	Evidence index, approvals, exceptions, incidents, retention and renewal dates	Evidence expiry, incident, material authority change	Management cannot reconstruct the approval basis

The five dimensions operate as one control. Strength in four cannot compensate silently for failure in the fifth. A well-validated model without accountable stop authority remains ungoverned. A resilient architecture without a defined clinical context remains ungoverned. An extensive record without current evidence remains ungoverned.

TOUCH STONE LAW: THE LAW OF THE OPERATING ENVELOPE

An AI system is governed only when the enterprise can prove where it may operate, how it may change, what it depends on, who can stop it, and what evidence survives its decisions.

The CLEAR Governance File

The framework becomes operational through five controlled records. These records form the minimum governance file for every material system.

The Context Authorization states the approved decision, population, users, data, autonomy, human role, prohibited uses, and invalidating conditions. It prevents a successful test in one setting from becoming silent permission for use elsewhere.

The Controlled Change Plan classifies routine, material, emergency, and prohibited changes. It states the evidence, approval, monitoring, rollback, and cumulative-change rules for each class.

The Dependency and Continuity Record identifies critical vendors, cloud regions, compute, network, power, cooling, capacity, recovery, and safe fallback. Technical recovery targets are translated into clinical and operational consequences.

The Accountability and Escalation Resolution names the accountable executive, independent challenge functions, stop authority, red-flag thresholds, and committee path. “Management” and “the AI committee” are not accepted as assignments of personal accountability.

The Evidence and Renewal Ledger links approvals, lineage, validation, monitoring, incidents, overrides, exceptions, and retirement decisions. Every material assumption receives a renewal date or event trigger. Approval without renewal becomes a permanent answer to a temporary question.

The file is not a second document repository. It is an index to controlled evidence held by the functions that produce it. Its purpose is to let an executive, director, auditor, regulator, or successor reconstruct the decision without depending on the memory of the original team.

4. Implementation Converts Policy into a Renewable Evidence System

Implementation begins with material systems, not the entire software estate. The board or executive risk committee should require management to identify AI systems whose failure can affect patient safety, regulatory submissions, public disclosures, critical operations, material capital commitments, or enterprise resilience. This creates a risk-based portfolio rather than an undifferentiated inventory.

Phase One: establish the portfolio and decision rights.

Within 30 days, management identifies material healthcare and energy-dependent AI systems, assigns an accountable executive, and documents the current context of use. The chief medical, technology, information, risk, compliance, and operations officers contribute within their spheres. The audit or risk committee approves the materiality criteria and escalation architecture.

The completion record includes the system inventory, materiality rationale, accountable owner, committee assignment, and unresolved ownership conflicts. Success is not measured by the number of systems catalogued. It is measured by whether every material system has an owner with authority to intervene.

Phase Two: define the CLEAR envelope.

Within 60 days, each material system receives a CLEAR record. Management defines operating boundaries, approved changes, infrastructure requirements, decision rights, stop conditions, and evidence retention. Existing technical, clinical, and compliance documents should be linked rather than copied when the source remains controlled and accessible.

The completion record includes the approved operating envelope and its evidence index. Exceptions receive an owner, expiry date, compensating control, and escalation threshold. A system with an unresolved high-severity gap remains restricted to an explicitly approved use or is suspended.

Phase Three: instrument and test.

Within 90 days, management connects monitoring to the approved boundaries. Tests should cover model performance, data drift, unauthorized use, infrastructure disruption, vendor failure, cost excursions, change-control failure, and human escalation. High-consequence systems require an exercise proving that authorized personnel can stop, isolate, revert, or safely degrade the system.

The completion record includes test results, failed controls, remediation owners, retest evidence, and residual-risk acceptance. The board receives exceptions and trends rather than raw technical telemetry.

Phase Four: integrate board reporting.

Quarterly reporting should show the number and materiality of systems inside and outside their approved envelopes, significant changes, incidents, overrides, infrastructure constraints, unresolved exceptions, and evidence overdue for renewal. Reporting must preserve sector context. A healthcare safety exception and an energy-capacity exception are not interchangeable merely because both concern AI.

The board should require management to explain cross-sector dependencies. If clinical expansion depends on a new data-center region, a power contract, or a concentrated model provider, that dependency belongs in the same decision record as the clinical benefit and regulatory pathway.

The governance record at completion.

Each implementation phase must end with a controlled record rather than a presentation alone. The portfolio record establishes scope and ownership. The envelope record establishes permitted operation and change. The test record establishes whether controls function under adverse conditions. The board record establishes which exceptions were accepted, remediated, restricted, or escalated. Together, these records allow a later reviewer to reconstruct the basis for the enterprise's decision.

The record should distinguish facts from management judgment. A measured service interruption, an observed model-performance decline, and an expired validation artifact are facts. A decision that the remaining risk fits the enterprise's tolerance is judgment. Combining those categories in one status color weakens accountability because it prevents the board from seeing where evidence ends and discretion begins.

Evidence also needs an expiration rule. Model performance, population fit, infrastructure capacity, vendor concentration, and regulatory status change on different cycles. The organization should assign a renewal period to each material assumption and trigger an earlier review after a significant modification, incident, use expansion, or change in controlling authority. An approval without a renewal condition becomes a permanent answer to a temporary question.

Financial architecture.

The investment case for regulated AI should include five cost classes: acquisition, integration, assurance, infrastructure, and failure response. Acquisition covers licenses and model access. Integration covers data, interfaces, workflow redesign, and migration. Assurance covers validation, monitoring, audit, documentation, and regulatory work. Infrastructure covers compute, storage, network, power-related exposure, redundancy, and recovery. Failure response covers investigation, operational interruption, remediation, notification, litigation support, and replacement.

Management should compare those costs with measured value inside the same context of use. Clinical time saved in one workflow cannot justify a different high-risk deployment without a separate analysis. Energy savings based on average utilization cannot justify a capacity commitment that depends on peak demand. The financial model must preserve the conditions under which both cost and value were measured.

The board does not need false precision. Scenario ranges are more credible when material variables remain uncertain. A base case, capacity-constrained case, regulatory-change case, vendor-failure case, and do-nothing case reveal whether the proposal remains viable when its operating assumptions move. The capital decision improves because uncertainty becomes visible rather than buried in a single return estimate.

Exhibit 4: Decision Rights for a Material Regulated AI System

Decision	Accountable role	Required challenge	Board or committee visibility
Approve context of use	Business or clinical executive	Clinical, legal, risk, data, and security review	Material uses and prohibited boundaries
Approve material change	Same accountable executive within delegated authority	Independent validation and change-control review	Changes exceeding approved appetite
Accept temporary exception	Executive named in the risk policy	Compliance and risk concurrence, with expiry	All high-severity exceptions
Suspend or revert system	Named operating executive with delegated stop authority	Immediate notification, later independent review	Material service, safety, or reporting events
Renew operating envelope	Accountable executive and independent assurance owner	Evidence freshness and performance review	Systems renewed, restricted, or retired

The table is not a universal reporting structure. It is a minimum decision architecture. A regulated manufacturer, health system, utility, data-center operator, or diversified enterprise will assign different titles. The test is whether each decision has one accountable owner, an independent challenge function, and a visible escalation path.

The management dashboard must report boundaries, not activity.

Most AI dashboards emphasize counts: use cases, models, incidents, training completions, or policy attestations. Counts demonstrate activity. They do not establish control. A useful executive dashboard reports the condition of the operating envelopes.

Management should report the proportion of material systems with current context approvals, the number operating under exceptions, changes awaiting validation, critical infrastructure dependencies without tested fallback, evidence approaching expiry, red flags not closed within tolerance, and systems whose benefit no longer justifies their assurance cost. Each measure connects to a decision management or the board can make.

The dashboard should also show movement. A system that remains green for six quarters without an evidence renewal may be less controlled than a system that reports and resolves several well-detected exceptions. Static status can hide stale assurance. Trend, exception age, and renewal discipline reveal whether the governance system is working.

Scenario testing before scale.

The base case assumes the model, vendor, infrastructure, regulatory interpretation, and human workflow perform as planned. Boards should not approve scale from that case alone. The capacity-constrained case tests whether power, compute, network, or specialized workforce limits the deployment. The vendor-failure case tests portability, fallback, data access, and continuity. The regulatory-change case tests whether evidence and architecture can be adapted without rebuilding the program.

The adverse-use case tests whether the system can be applied outside its intended context through ordinary user behavior, interface ambiguity, or pressure for productivity. The do-nothing case tests whether retaining the current process creates a greater clinical, financial, or operational risk than controlled deployment. This last case prevents governance from becoming an automatic argument for delay.

Scenario testing changes the approval conversation. Management no longer asks whether the AI initiative should proceed in the abstract. It asks which operating boundaries make the initiative acceptable, which dependencies require investment, and which conditions require restriction or exit.

5. The Strongest Evidence Favors Bounded Adaptation and Measured Infrastructure Assumptions

Case Example One: FDA predetermined change control plans.

FDA's final August 2025 guidance demonstrates how an institution can permit change without abandoning control. The framework asks a sponsor to identify planned modifications, methods for developing and validating them, implementation controls, and impact assessment. FDA can evaluate the plan within the marketing submission rather than treating every future change as unknowable.

The governance lesson extends beyond medical-device submissions without converting guidance into a universal legal command. Organizations can define bounded changes, required evidence, stop conditions, and monitoring before a model update reaches production. This approach reduces the false choice between freezing an AI system and allowing unrestricted adaptation.

The lesson also reveals why generic AI policies are insufficient. A principle such as “maintain human oversight” does not specify which changes are permitted, what evidence is required, who approves implementation, or when a system must revert. A controlled change plan does.

The deeper lesson is institutional. FDA did not resolve adaptability by declaring that learning systems are either permanently fixed or freely self-modifying. The agency established a structure for describing planned changes and the evidence needed to control them. That structure preserves innovation inside a reviewable boundary.

For enterprise leaders, the transferable practice is to separate three categories. A preauthorized change remains within the envelope and follows specified validation. A material change reopens approval because it alters the evidence basis or consequence. An emergency change operates under a temporary exception with an expiry and retrospective review. The categories create decision velocity without sacrificing traceability.

Case Example Two: U.S. data-center electricity planning.

DOE's 2024 U.S. Data Center Energy Usage Report provides a second governance case. The estimate that data centers may consume 6.7 to 12 percent of U.S. electricity by 2028 is not a precise forecast. It is a scenario range shaped by equipment shipments, operating practices, cooling demand, and other uncertainties. The range demonstrates the cost of treating infrastructure as an invisible externality of AI strategy.

GAO's qualification matters equally. Data centers support many workloads, and the portion of their electricity attributable to generative AI is unclear. A board should therefore reject both extremes: the claim that AI has no material physical constraint and the claim that every projected data-center load is caused by AI. Capital decisions require system-specific measurement and scenario analysis.

For healthcare organizations, this becomes an operational-continuity issue. Imaging, clinical analytics, digital diagnostics, research computing, and administrative agents can depend on remote infrastructure. The board needs assurance about what occurs when capacity is constrained, costs spike, a region fails, or a vendor changes service conditions. A continuity plan that restores servers without restoring safe clinical workflow is incomplete.

The scenario range also demonstrates disciplined uncertainty. A projection of 6.7 to 12 percent is too wide to support a single deterministic capital conclusion, but it is highly useful for stress testing. Utilities and large users can examine interconnection, generation, transmission, cost, and resilience under several demand cases. The correct board response is not to select the most convenient endpoint. It is to identify which decisions remain sound across the range.

GAO's attribution warning prevents a second error. Data-center demand reflects AI and non-AI workloads, and generative AI's specific share is uncertain. A credible enterprise estimate therefore begins with its own measured portfolio, workload growth, architecture, and location. National estimates provide context. They do not replace enterprise telemetry.

Case Example Three: Delaware officer oversight.

Delaware decisions addressing officer oversight provide a governance analogue rather than an AI-specific holding. The courts have stated that officers have oversight duties within their areas of responsibility and must address or report relevant red flags. They have also emphasized the demanding standard for Caremark liability.

The practical lesson is disciplined information architecture. An organization should identify which officer receives which AI risk signals, what crosses the escalation threshold, how upward reporting occurs, and what record proves the response. The paper does not claim that Delaware courts have declared every algorithm mission-critical or that an AI failure establishes bad faith. Those conclusions exceed the decisions.

The distinction between legal doctrine and governance design protects the quality of both. Boards do not need an AI-specific court ruling before establishing useful reporting systems for material AI risks. They also should not describe prudent governance as a settled legal mandate when the authority does not say that. CLEAR uses the doctrine as a design signal: relevant information must reach the responsible officer, red flags require action or escalation, and the record must show good-faith oversight.

Case Example Four: European Union transparency rules.

The European Commission states that transparency rules applying from August 2, 2026 help people recognize certain AI interactions and specified AI-generated or manipulated content. The scope matters. The rules do not support the blanket claim that every use of AI requires identical public labeling. They distinguish categories such as interactions with AI, deepfakes, emotion recognition, biometric categorization, and certain public-interest text without human review or editorial control.

The operating lesson is metadata discipline. An organization cannot make an accurate disclosure decision at publication if it did not preserve how an asset was created, altered, reviewed, and approved. Content provenance is therefore not a final communications task. It is part of the production system.

This case also connects healthcare and energy. A regulated organization can use AI for internal analysis, public information, customer interaction, or decision support, with different disclosure and risk implications. The context record determines which rule and control applies. A universal label or universal exemption would both be structurally weak.

What the evidence does not establish.

The current evidence does not establish that officers are automatically personally liable when an AI system fails. It does not establish that every healthcare AI application falls under the same FDA pathway. It does not establish that generative AI alone will consume the projected national data-center share. It does not establish that all AI-generated material must receive the same public label.

These exclusions increase the paper's practical value. Governance built on exaggerated legal or economic claims will lose credibility when counsel, regulators, operators, or investors challenge it. Governance built on precise scope can survive scrutiny and adapt as controlling authority develops.

6. The Board Should Require Five Decisions Within One Quarter

At the next scheduled meeting, the board should commission a 30-day material-system inventory. The accountable executive should identify AI systems affecting patient safety, regulatory evidence, public reporting, critical infrastructure, or material capital allocation. Success means every material system has a named owner, defined committee oversight, and a documented context of use.

Within 60 days, management should submit CLEAR Operating Envelopes for the highest-consequence systems. The audit or risk committee should test whether each record covers context, lifecycle, energy and infrastructure, accountability, and evidence. Success means no material deployment relies on an unrecorded use expansion, unidentified infrastructure dependency, or ambiguous stop authority.

Within 90 days, internal audit or another independent assurance function should observe an operating-envelope exercise. The test should include one model-performance failure, one infrastructure disruption, one unauthorized change, and one red-flag escalation. Success means the organization detects the condition, reaches the assigned decision-maker, executes the approved response, and preserves evidence.

At each quarterly review, the board should receive an exception-led report. The report should state which systems moved outside approved boundaries, which changes occurred, which dependencies became concentrated, which evidence expired, and which remediation dates slipped. Success means the board can distinguish controlled innovation from unmanaged expansion.

The final action is portfolio-level capital alignment. Finance, technology, clinical leadership, and operations should connect model growth plans to compute, power, resilience, workforce, validation, and compliance costs. Success means the investment case includes the cost of operating safely, not merely the cost of acquiring the model.

Exhibit 5: The 90-Day Board Protocol

Timing	Required decision	Accountable owner	Evidence delivered	Success criterion
Day 30	Which AI systems are material?	CEO or delegated enterprise risk executive	Risk-based portfolio and ownership map	Every material system has an owner and committee path
Day 45	What is each system permitted to do?	Clinical or business executive	Context-of-use and prohibited-use record	Scope is specific enough to test and enforce
Day 60	Which changes and dependencies require renewed approval?	Technology and quality leadership	Lifecycle and infrastructure envelope	Material changes cannot enter through routine operations
Day 75	Can the enterprise detect, stop, and recover?	Operating owner with risk and security	Exercise results and remediation record	Stop, fallback, escalation, and evidence preservation work
Day 90	Which systems scale, remain restricted, or exit?	Executive committee with board oversight	Integrated value, risk, capacity, and assurance case	Capital follows proven operating envelopes

Twelve Questions That Expose Weak Assurance

CLEAR dimension	Board question	Weak answer signal
Context	What exact decision does the system support?	“It improves productivity”
Context	Which population, user, or workflow is outside approval?	No prohibited-use statement
Lifecycle	Which changes can occur without renewed approval?	“The vendor handles updates”
Lifecycle	What cumulative change would invalidate the original evidence?	Only model versions are tracked
Energy and infrastructure	Which physical or vendor dependency can interrupt the intended service?	General uptime percentage
Energy and infrastructure	What happens at peak demand or regional failure?	Recovery is described without service consequence
Accountability	Who has unilateral authority to stop or revert the system?	A committee must convene first
Accountability	Which red flags reach the responsible officer and board committee?	Technical incidents are reported without thresholds
Record	Can management reconstruct why the system was approved?	Evidence is distributed across email and vendor portals
Record	When does each material assumption expire?	Approval has no renewal date
Economics	Does the return include assurance, infrastructure, and failure-response cost?	License cost is treated as total cost
Portfolio	Which system would management retire first if capacity tightened?	Every initiative is described as strategic

Weak answers do not automatically require cancellation. They require a decision about restriction, evidence, ownership, investment, or timing. The board's contribution is to prevent ambiguity from masquerading as acceptance.

The board record.

Minutes should record the decision and its basis, not reproduce technical presentations. The record should identify the material systems reviewed, operating boundaries approved, exceptions accepted, evidence relied upon, management owner, independent challenge, renewal date, and conditions that require earlier escalation. This establishes a durable decision history without forcing the board into operational management.

The board should also record dissent and uncertainty. A range of credible outcomes is not a governance failure. Concealing the range behind one forecast is. The record should show which uncertainties were accepted, which were reduced through evidence, and which were assigned a trigger for reconsideration.

Conclusion: The Next Standard Will Be Proof of Controlled Operation

Healthcare AI and energy infrastructure are not separate strategic themes once the enterprise depends on intelligent systems for regulated decisions. They are coupled layers of one operating system. The board that evaluates the model without its physical dependencies receives incomplete assurance. The board that evaluates power and cloud capacity without the clinical context receives incomplete economics.

The CLEAR Operating Envelope corrects that separation. It does not ask directors to become model validators, utility planners, or regulatory specialists. It requires the enterprise to connect those disciplines into a decision record that states where the system may operate, how it may change, what it depends on, who can intervene, and what can be proven afterward.

The next governance advantage will not come from adopting the largest number of AI tools. It will come from expanding intelligent operations without allowing decision velocity to outrun evidence, infrastructure, or accountability.

The durable legacy of this work is an operating record that successors can inherit, test, and improve. It is built from conviction before a failure, not built in response to litigation, patient harm, service disruption, or regulatory intervention after those events have already defined the facts.

References

1. U.S. Food and Drug Administration. “Considerations for the Use of Artificial Intelligence To Support Regulatory Decision-Making for Drug and Biological Products.” Draft Guidance, January 2025. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/considerations-use-artificial-intelligence-support-regulatory-decision-making-drug-and-biological

2. U.S. Food and Drug Administration. “Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions.” Final Guidance, August 2025. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/marketing-submission-recommendations-predetermined-change-control-plan-artificial-intelligence

3. U.S. Food and Drug Administration. “Guiding Principles of Good AI Practice in Drug Development.” 2026. https://www.fda.gov/about-fda/artificial-intelligence-drug-development/guiding-principles-good-ai-practice-drug-development

4. U.S. Department of Energy. “DOE Releases New Report Evaluating Increase in Electricity Demand from Data Centers.” December 20, 2024. https://www.energy.gov/articles/doe-releases-new-report-evaluating-increase-electricity-demand-data-centers

5. U.S. Government Accountability Office. “Artificial Intelligence: Generative AI's Environmental and Human Effects.” GAO-25-107172, April 22, 2025. https://www.gao.gov/products/gao-25-107172

6. European Commission. “AI Act Enters into Force.” August 1, 2024. https://commission.europa.eu/news-and-media/news/ai-act-enters-force-2024-08-01_en

7. European Commission. “Artificial Intelligence.” Updated August 14, 2026. https://commission.europa.eu/topics/artificial-intelligence_en

8. Delaware Court of Chancery. Opinion discussing officer oversight obligations within the officer's sphere of responsibility and upward reporting of red flags. https://courts.delaware.gov/Opinions/Download.aspx?id=384430

Research Status and Limitations

Research verified through August 30, 2026. This paper relies primarily on inspected government, regulatory, and judicial sources. It intentionally excludes the supplied venture-capital concentration figures, trust percentages, Blackstone portfolio figure, railroad transaction narrative, GDP-gap claim, and categorical claims of automatic executive liability because direct, sufficiently scoped support was not established during this review. Legal conclusions are governance analysis, not legal advice.