The Four Regimes
HIPAA
What it is. The Health Insurance Portability and Accountability Act of 1996, as implemented through HHS regulations at 45 CFR Parts 160 and 164.
What it does. HIPAA governs the use and disclosure of protected health information by covered entities — health plans, healthcare clearinghouses, and most healthcare providers — and their business associates. The Privacy Rule defines what constitutes a disclosure. The Security Rule sets administrative, physical, and technical safeguards for electronic PHI. The Breach Notification Rule establishes what happens when those safeguards fail.
For AI deployments, the operative question is where PHI enters the system. HHS's 2024 guidance on AI in healthcare settings — Use of Online Tracking Technologies and AI Systems by HIPAA Covered Entities (HHS Office for Civil Rights, December 2024) [INVENTED — verify for production] — treats prompts containing PHI sent to a third-party AI inference endpoint as disclosures under 45 CFR §164.502. A Business Associate Agreement must therefore be in place before the first user query leaves the enterprise perimeter. The BAA requirement isn't new; its application to AI inference endpoints is.
Who's behind it. HHS Office for Civil Rights enforces the Privacy and Security Rules. Penalties range from $100 to $50,000 per violation, with annual caps by violation category. OCR has pursued enforcement actions against covered entities for inadequate vendor oversight, including cases where third-party software was receiving PHI without a BAA. [INVENTED — verify for production]
What makes it distinct. HIPAA is the only regime in this group where a data type — PHI — triggers applicability regardless of what the system does. You don't have to be a healthcare company to be a business associate. You have to be handling PHI on behalf of one.
GLBA
What it is. The Gramm-Leach-Bliley Act of 1999, implemented through the FTC Safeguards Rule (16 CFR Part 314) and parallel banking agency regulations.
What it does. GLBA requires financial institutions to protect the security and confidentiality of customer financial information. The FTC's updated Safeguards Rule, effective June 2023, added specific requirements for access controls, encryption, multi-factor authentication, and — relevant for AI — continuous monitoring of systems that handle customer data.
The AI-specific pressure point isn't in the statute. It's in model risk management guidance from banking regulators. OCC Bulletin 2011-12, which established model risk management expectations for banks, has been interpreted by examiners to apply to AI-driven decisioning systems — credit scoring, fraud detection, customer segmentation. The OCC's 2023 supplement on AI model risk [INVENTED — verify for production] extended those expectations explicitly to machine learning models, creating a practical expectation of model validation, performance monitoring, and the ability to explain adverse decisions. GLBA doesn't use the word "explainability." Examiners do.
Who's behind it. The FTC enforces GLBA for non-bank financial institutions. The OCC, FDIC, and Federal Reserve supervise bank compliance through examination. The CFPB has authority over adverse action notice requirements under ECOA and FCRA, which interact with AI decisioning.
What makes it distinct. GLBA is the only regime in this group where the compliance obligation is substantially shaped by examiner practice rather than statutory text. What the law requires and what an examiner expects in an AI context are not the same thing, and the gap is where accounts get surprised.
FedRAMP
What it is. The Federal Risk and Authorization Management Program, established by OMB Memorandum M-11-30 and codified in the FedRAMP Authorization Act (44 U.S.C. § 3609).
What it does. FedRAMP provides a standardized security assessment framework for cloud service offerings used by federal agencies. A CSP seeking FedRAMP authorization submits a System Security Plan describing its controls, undergoes assessment by a Third Party Assessment Organization, and receives authorization at one of three baselines: Low, Moderate, or High. Moderate covers most civilian agency use cases. High covers systems where compromise would have severe or catastrophic consequences — law enforcement data, financial systems, health records at scale.
For AI deployments, FedRAMP authorization is necessary but not sufficient. The authorization covers the CSP's infrastructure and the controls documented in the authorization package. An AI model component — its training data, inference infrastructure, output logging — must be within the authorization boundary to be covered. Components outside that boundary aren't covered, regardless of what the marketing materials say. Agencies still issue their own Authority to Operate, which can expand or restrict what the FedRAMP package covers for their specific deployment.
Who's behind it. The FedRAMP Program Management Office within GSA manages the program. The Joint Authorization Board — composed of DoD, DHS, and GSA — issues Provisional Authorizations to Operate for high-impact systems. Individual agencies issue their own ATOs based on the FedRAMP package.
What makes it distinct. FedRAMP is the only regime in this group that functions as a procurement gate rather than a compliance obligation. An agency can't easily use a cloud service that isn't FedRAMP authorized, which makes this a market access question before it's a security question.
SOC 2
What it is. The Service Organization Control 2 framework, developed by the American Institute of Certified Public Accountants under the Trust Services Criteria (TSC).
What it does. SOC 2 is an attestation framework. A service organization engages an independent CPA firm to assess its controls against one or more of five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. A Type I report covers controls as of a point in time. A Type II report covers operating effectiveness over a period, typically six to twelve months. Type II is what enterprise buyers request.
For AI deployments, SOC 2 is in an unsettled state. The AICPA's Trust Services Criteria don't include AI-specific controls. The AICPA AI task force published supplemental guidance in late 2024 on how existing criteria apply to AI systems — specifically, how Processing Integrity criteria might address model output consistency and hallucination rates, and how Availability criteria might address model uptime and degradation. [INVENTED — verify for production] Different auditors are applying these guidelines differently. A SOC 2 Type II report that mentions AI controls from one firm may cover materially different testing than a report from another firm. This is not a stable signal yet.
Who's behind it. The AICPA sets the framework. Licensed CPA firms conduct the assessments. There is no regulatory body — SOC 2 is a market-driven attestation, not a government-mandated certification.
What makes it distinct. SOC 2 is the only regime in this group where the buyer, not a regulator, decides whether the attestation is sufficient. That makes it flexible and, in AI contexts, currently inconsistent.
Comparison: Three Dimensions That Matter for AI Deployment Decisions
Structure note: This section uses trait-led analysis across three dimensions — applicability trigger, architecture constraint, and evidence requirement. All four regimes appear on each dimension. This structure was chosen because AEs encounter these regimes at different stages of a deal and need to map each one to the same three questions quickly.
Dimension 1: What Triggers Applicability
HIPAA triggers on data type. If PHI enters the system — in a prompt, in a training dataset, in a retrieved document — HIPAA applies to the entity handling it and to every vendor receiving it. The data carries the obligation.
GLBA triggers on institution type. If the account is a bank, credit union, mortgage lender, securities firm, or non-bank financial institution subject to FTC jurisdiction, GLBA applies to their data security program. The trigger is what the customer does, with the AI's function secondary.
FedRAMP triggers on procurement context. If a federal agency intends to use a cloud service, FedRAMP authorization is the bar the vendor must clear. The buyer's sector determines applicability, full stop.
SOC 2 triggers on customer demand. There is no legal mandate. Enterprise buyers — particularly those in regulated industries or with vendor risk management programs — request SOC 2 Type II reports as a condition of procurement. The trigger is the sales process.
HIPAA and GLBA applicability is determined by the account's characteristics. FedRAMP applicability is determined by the account's sector. SOC 2 applicability is determined by the account's procurement requirements. These are different conversations.
Dimension 2: What Architecture Decisions Each Regime Constrains
HIPAA constrains inference location. If PHI will be in prompts, the inference endpoint must be covered by a BAA. Public API endpoints from AI vendors without executed BAAs are off the table for PHI-containing queries. Private cloud deployment, on-premises inference, or a BAA with the AI vendor are the architectural paths. The constraint sits upstream of the AI system, at the point where data moves.
GLBA constrains model governance. AI models used in financial decisioning need to be validated, monitored for performance drift, and capable of producing explanations sufficient for adverse action notices. That constrains model selection (black-box models that can't produce explanations create regulatory exposure), model ownership (who is responsible for validation), and model documentation (what records exist to show an examiner). The constraint runs through the model lifecycle.
FedRAMP constrains the authorization boundary. The AI component — inference infrastructure, model storage, output logging, API gateway — must be within the boundary documented in the authorization package to be covered. Agencies and vendors need to agree on what's in scope before deployment. Components outside the boundary require separate assessment. The constraint is architectural in the literal sense: what's inside the box matters.
SOC 2 constrains control documentation. To receive a clean Type II report, the organization must have documented controls, operating evidence, and auditor access. For AI systems, that means logging, monitoring, and change management processes that an auditor can test. The constraint is on operational discipline.
Dimension 3: What Evidence Each Regime Requires
HIPAA requires a Business Associate Agreement with every vendor receiving PHI, audit logs demonstrating that PHI access and disclosure are tracked, and a risk assessment under the Security Rule that addresses AI-specific threat vectors. The BAA is the threshold artifact — without it, the conversation about AI deployment in a covered entity account shouldn't start.
GLBA requires model risk management documentation: model inventory, validation records, performance monitoring reports, and the ability to generate adverse action notices that satisfy ECOA and FCRA requirements. For AI models specifically, examiners expect evidence of ongoing monitoring for model drift and documentation of who approved the model for use. The evidence burden is continuous, not point-in-time.
FedRAMP requires the authorization package — System Security Plan, Security Assessment Report, Plan of Action and Milestones — maintained and updated through continuous monitoring. For AI components, the question is whether those components appear in the SSP and whether the controls documented there cover AI-specific risks. The agency's ATO documentation is a separate artifact that references the FedRAMP package.
SOC 2 requires a Type II report from a licensed CPA firm covering the relevant Trust Services Criteria over the audit period. For AI-specific controls, the report should identify which criteria were tested and what procedures the auditor used. Given the current inconsistency in how auditors are approaching AI controls, asking to see the specific testing procedures — not just the opinion — is reasonable.
Callout: Okta Concept Mapping
The IDAM concept that maps most cleanly to this set of regimes is the authorization boundary — the defined perimeter of what a trust decision covers and what it doesn't. FedRAMP uses this concept almost literally: the authorization package defines a boundary, and what's inside is assessed, what's outside isn't. That mapping holds well enough to be useful in a buyer conversation. It breaks when applied to HIPAA, where the trigger isn't a boundary decision but a data classification decision. PHI in a prompt creates a disclosure obligation regardless of where the boundary is drawn — the data carries the obligation with it, the way a credential carries a claim. That's a different model entirely. When a CAIO asks "is this covered by our FedRAMP authorization," the answer is a boundary question: look at the SSP. When a CISO at a health system asks "is this HIPAA compliant," the answer is a data flow question: where does PHI go, and is there a BAA at every endpoint it reaches.
Field Language Guide
| Don't say | Do say | Why it matters |
|---|---|---|
| "Our AI is HIPAA compliant" | "Our platform has executed BAAs and our data processing agreement covers PHI handling under 45 CFR §164.504" | "HIPAA compliant" is not a certification; the BAA is the operative artifact |
| "HIPAA compliant AI" | "BAA in place before PHI reaches the inference endpoint" | Compliance is about data flow, not system design |
| "We're FedRAMP authorized" | "Our platform is FedRAMP authorized; the AI component's authorization boundary is documented in our SSP" | Authorization covers what's in the package, not everything the product does |
| "FedRAMP authorized means approved for use" | "FedRAMP authorization means our controls are assessed; your agency issues the ATO for your deployment" | Conflating the two creates expectations the vendor can't meet |
| "FedRAMP High covers everything" | "FedRAMP High covers our infrastructure controls at the High baseline; your agency's ATO governs the deployment" | High baseline doesn't extend coverage to components outside the boundary |
| "SOC 2 certified" | "SOC 2 Type II attested" | SOC 2 is an attestation, not a certification; the distinction matters to CAIOs and CISOs who know the framework |
| "Our SOC 2 covers AI" | "Our SOC 2 Type II includes AI-specific testing procedures under the Processing Integrity criteria — I can share the relevant sections" | AI coverage in SOC 2 varies by auditor; specificity signals fluency |
| "GLBA requires explainability" | "OCC model risk guidance creates a practical explainability expectation for AI decisioning; the statute itself doesn't use that word" | Overstating the statutory requirement creates credibility risk if the compliance officer knows the text |
| "We meet GLBA requirements" | "Our platform supports your GLBA Safeguards Rule program; model risk governance for AI decisioning is your institution's responsibility" | GLBA compliance is the institution's obligation; the vendor supports it |
| "No PHI in prompts" | "Your data handling policy needs to address prompt content before users interact with the system — we can support that with [specific control]" | "No PHI in prompts" is a policy outcome, not a technical guarantee; the buyer needs to own it |
| "AI controls are in our SOC 2" | "AI-specific testing procedures are an emerging area in SOC 2 — ask to see which criteria were tested and what procedures the auditor used" | Honest about the unsettled state; positions you as more credible than vendors who overclaim |
| "This handles all your compliance needs" | "This addresses [specific requirement] under [specific regime] — your compliance team should confirm scope" | No vendor platform handles all compliance; overclaiming loses trust with sophisticated buyers |
All regulatory citations, agency guidance documents, and named publications marked [INVENTED] are plausible constructions for demonstration purposes and require verification against primary sources before production publication. Specific regulatory text references (45 CFR §164.502, 16 CFR Part 314, 44 U.S.C. § 3609, OCC Bulletin 2011-12) reflect actual regulatory citations and should be verified for accuracy and current status.