A Regulated AI Guide for Executive Decision-Makers
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.
| Regime | Data constraint | Architectural requirement | Deployment model |
|---|---|---|---|
| HIPAA (45 CFR Part 164) — healthcare | Protected health information (PHI) may not be disclosed to a business associate without satisfactory assurance of safeguards (45 CFR 164.502(e)); the “minimum necessary” standard applies to every use and disclosure | PHI isolation; audit controls that record and examine system activity (45 CFR 164.312(b)); access controls; a business associate agreement with every vendor in the chain (45 CFR 164.504(e)) | On-premises, private cloud, or a BAA-covered cloud service |
| FedRAMP — government and defense | Controlled unclassified information (CUI) must be protected per NIST SP 800-171 in nonfederal systems; cloud services are categorized by FIPS 199 impact levels: Low, Moderate, and High | A FedRAMP authorization at the required impact level, built on the applicable NIST security control baseline, with continuous monitoring; FedRAMP 20x certification (Classes A through C finalized, Class D for High in planning) | FedRAMP-authorized cloud services, or on-premises with an internal authorization |
| NRC — nuclear | Digital software used in nuclear power plant safety systems must meet NRC regulatory requirements; NRC Regulatory Guide 1.172 describes an acceptable software requirement specification method for such software | A hard boundary between safety-critical and non-safety-critical systems; change control and verification for anything that touches safety functions | Plant-local compute; non-safety-critical AI kept behind a documented boundary from safety systems |
| ITAR / export control — defense | Defense articles and defense services are designated on the U.S. Munitions List under 22 CFR Part 120; persons engaged in manufacturing or exporting defense articles must register with the Directorate of Defense Trade Controls (22 CFR Part 122); exports and sales to certain countries are prohibited (22 CFR Part 126) | Access-controlled enclaves with US-person-only access, a technology control plan, and disclosure gates at every boundary crossing | On-premises in cleared facilities, or cleared classified cloud accredited to DoD CC SRG Impact Level 6 and ICD 503 |
Two notes on reading the table. First, the regimes do not consolidate into a single standard — they are different evidence systems. 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:
- Classify the data first. PHI, CUI, ITAR-controlled technical data, classified. The highest-class data in scope sets the baseline for the whole system.
- 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.
- Map each regime to architectural requirements. Data boundary, access control, audit logging, change control, personnel control. The table above is the mapping.
- 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.
- 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.
What to Demand From Any AI Vendor in a Regulated Environment
Ten questions that double as a pre-qualification checklist:
- 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.
- 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.
- 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.
- 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?
- Audit and lineage. Immutable logs of prompts, retrievals, and generations; who accessed what and when; model version tied to every output.
- 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.
- Separation from critical systems. A documented boundary from safety-critical or production OT systems, with a defined blast radius if the AI layer fails.
- Incident notification. Contractual breach-notification timelines that meet HIPAA deadlines, and evidence retention that survives a regulator’s lookback.
- Personnel. Vetting and backgrounding processes for anyone on the vendor side who can see the data or the models.
- 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
