A Regulated AI Guide for Executive Decision-Makers

The AI project was approved, and then the compliance office sat down at the table. The model has to read clinical notes, controlled unclassified information, or export-controlled technical data, and the regime governing that data does not accept the answer “it is hosted somewhere safe.” From that point on, every decision, from hosting to model refresh, has to survive an inspection that may come years later.

Regulated AI is artificial intelligence deployed under a binding compliance or security regime — HIPAA in healthcare, FedRAMP in federal government, NRC requirements in nuclear, and export control in defense. The model itself is rarely the constraint; the deployment must be provable to an auditor, a regulator, or both. For an executive, that distinction reframes the buying conversation: the question is not “how capable is the model?” but “what can this system prove, to whom, and under which authority?”

What “regulated AI” means

In this guide, “regulated AI” is an AI system operating under a binding compliance or security regime. A regime becomes binding when a body of law, regulation, or accreditation requires specific controls and produces specific evidence: a signed contract (a HIPAA business associate agreement), an authorization (FedRAMP), an accepted engineering basis (NRC), or an export-control determination (ITAR). Four properties separate regulated AI from general enterprise AI:

• A named data class. The system touches protected health information, controlled unclassified information, classified data, or export-controlled technical data. The data class — not the workload — drives the design.
• A named authority. HHS, the FedRAMP PMO, the NRC, and the State Department’s Directorate of Defense Trade Controls each enforce their own evidence expectations.
• Auditability as a requirement. Logging, lineage, and access review exist to be inspected, not for IT convenience.
• A deployment posture that follows the data. On-premises, private cloud, or air-gapped, chosen to keep the data class inside a boundary the authority accepts.

The concept sits on the same axis as sovereign AI — data, compute, and models under organizational control — but regulated AI is defined by the obligations it must satisfy, not by ownership alone.

The major regimes and what each forces on architecture

The four regimes below dominate US deployments in hard industries. The table maps each regime to the data constraint it imposes, the architectural requirement that follows, and the deployment model that satisfies it.

Two notes on reading the table. First, the regimes do not consolidate into a single standard — they are different evidence systems. How the governance frameworks that sit on top of these regimes layer onto each other is covered in AI governance frameworks. A FedRAMP authorization does not satisfy HIPAA, and a business associate agreement does not satisfy export control. Second, the deployment model column is an outcome, not a menu item: the data class determines the boundary, and a vendor can only offer it as a property of the platform.

FIPS 199, the NIST standard for security categorization of federal information and information systems, is the basis for those impact levels: it assigns Low, Moderate, or High impact values across the three security objectives of confidentiality, integrity, and availability.

How sovereign deployment satisfies each constraint

Sovereign deployment — data, models, and compute under the organization’s direct control, on-premises or air-gapped — is the architectural answer that fits all four regimes. It is an answer, not a substitute: each regime still requires its own evidence.

HIPAA. On-premises keeps PHI inside the covered entity’s own network, the simplest way to keep the information under the organization’s control. The contract still does the liability work: a business associate agreement is required with every outside party that touches PHI, including a vendor’s support engineers if they can see it.

FedRAMP. A FedRAMP authorization attaches to a cloud service, not to a building. The FedRAMP marketplace lists certified cloud services, authorizing agencies, and recognized assessors; a government buyer who cannot use an authorized service must run on-premises and manage the authorization internally. FedRAMP 20x, a new approach to cloud security assessment and authorization, changes the certification mechanics for new services — but the impact-level categorization, and the control work it carries, moves in-house rather than disappearing.

NRC. Separation is the whole game. The agency’s own framework already splits the plant: digital software used in safety systems is held to a strict engineering standard — NRC Regulatory Guide 1.172 sets the acceptable software requirement specification method for that software — while non-safety-critical plant IT runs under ordinary corporate controls. AI in a nuclear environment lands on the non-safety side of that boundary. In April 2021, the NRC published a public comment request on the use of artificial intelligence and machine learning tools in US commercial nuclear power operations — a sign the agency is still shaping the rules, and an argument for conservative architecture.

ITAR. Export control is a people-and-data problem, not a compute problem. The system must sit inside a boundary where only authorized US persons can reach the data, and every model update that crosses that boundary must be a logged, controlled event. Cleared cloud shows the pattern at scale: AWS describes Secret Cloud as designed and accredited to the Department of Defense Cloud Computing Security Requirements Guide Impact Level 6 and ICD 503 — accreditation to a classified impact level, not generic hosting.

The common thread: sovereignty supplies the boundary; the regime supplies the evidence. Buying “on-prem” without the evidence — the agreement, the authorization, the engineering basis, the control plan — is the most common compliance failure in regulated AI.

A decision framework for your architecture

Five steps, in order:

1. Classify the data first. PHI, CUI, ITAR-controlled technical data, classified. The highest-class data in scope sets the baseline for the whole system.
2. List the binding regimes. Industry and data type together determine the list: a defense prime’s shop-floor vision system touches ITAR, a hospital’s clinical assistant touches HIPAA, and a national lab’s forecasting tool may touch FedRAMP and CUI.
3. Map each regime to architectural requirements. Data boundary, access control, audit logging, change control, personnel control. The table above is the mapping.
4. Design to the most restrictive constraint. One architecture that satisfies the hardest regime usually satisfies the others. If any data is ITAR-controlled, the enclave is ITAR-scoped, and the remaining workloads run inside it or are excluded from it.
5. Buy the evidence, not just the software. Business associate agreements, FedRAMP authorizations, NRC-accepted engineering bases, ITAR technology control plans. A vendor that cannot produce the evidence does not have the capability, however capable the model is. A practical playbook for putting AI agents into production in regulated settings is in deploying AI agents in regulated industries.

What to demand from any AI vendor in a regulated environment

Ten questions that double as a pre-qualification checklist:

1. Data boundary. Where does every byte go, including telemetry, logs, and model updates? For an on-prem or air-gapped deployment, require the network diagram and a written zero-egress statement.
2. Contract posture. A signed business associate agreement before PHI touches the system; a FedRAMP authorization at the required impact level before CUI does; an ITAR-compatible access and disclosure plan before controlled technical data does.
3. Model provenance. Where do the weights come from, what were they trained on, and what license governs redistribution? In an air-gapped environment that is a supply-chain question, not a curiosity.
4. Update path. How do models, dependencies, and patches get refreshed on a network that cannot reach the internet? What review and approval governs each update?
5. Audit and lineage. Immutable logs of prompts, retrievals, and generations; who accessed what and when; model version tied to every output.
6. Access control. Identity and role-based access at the application level, not just the network level; US-person-only access for ITAR scope; cleared personnel handling for classified scope.
7. Separation from critical systems. A documented boundary from safety-critical or production OT systems, with a defined blast radius if the AI layer fails.
8. Incident notification. Contractual breach-notification timelines that meet HIPAA deadlines, and evidence retention that survives a regulator’s lookback.
9. Personnel. Vetting and backgrounding processes for anyone on the vendor side who can see the data or the models.
10. Exit. Data deletion, model deletion, and verified erasure, on the contract’s timeline.

Where each industry lands

This guide maps the regimes; the industry pages apply them. Private AI for healthcare covers PHI handling, business associate agreement chains, and the deployment models a hospital system can actually operate. Sovereign AI for defense covers ITAR, cleared facilities, classified cloud, and what accreditation means in a procurement. Nuclear AI covers the safety-critical and non-safety-critical boundary and what the NRC expects of AI in a plant environment. Government AI covers FedRAMP impact levels, CUI handling, and how authorization decisions get made.

Bottom line

Regulated AI is not a product category; it is a deployment discipline. The regimes do not negotiate, the evidence requirements are not optional, and the architecture that satisfies the most restrictive constraint in the estate usually satisfies the rest. If the buying conversation starts with the data class and ends with the evidence, model selection becomes what it should be: a detail.

A working demonstration of how a sovereign deployment is structured against these constraints is available at Shakudo’s demo.

Last verified: 2026-09-05