Four Compliance Regimes Your Buyer Already Knows, and Where AI Breaks Each One

HIPAA, GLBA, FedRAMP, and SOC 2 show up in the accounts you're already selling into. You've positioned identity against all four. The regimes themselves are stable. The applicability triggers, architecture constraints, and evidence requirements now include scenarios with no clean analog in your existing compliance conversations. The sentence that buys you credibility: "Have you determined whether your AI vendor is in scope for [regime], and what that means for your architecture?"

HIPAA

What it is: The federal law governing the privacy and security of protected health information (PHI).

What it does: Requires covered entities and their business associates to safeguard PHI through administrative, physical, and technical controls, and restricts how PHI can be used and disclosed.

Who's behind it: HHS Office for Civil Rights (OCR) enforces the Privacy and Security Rules. Congress enacted the statute; OCR writes the implementing rules and brings enforcement actions.

What makes it distinct: HIPAA is technology-agnostic in a way that turns out to be ruthlessly effective against AI. The only question it asks: did PHI leave the building? A clinician pasting a patient diagnosis into a chatbot prompt is, under the existing framework, a disclosure to the AI vendor. That vendor needs a Business Associate Agreement (official HHS FAQ, primary source for BA scope definitions).

GLBA

What it is: The federal law requiring financial institutions to explain data-sharing practices and safeguard sensitive customer information.

What it does: The Safeguards Rule requires financial institutions to maintain a security program protecting customer financial data. Separately, ECOA and Regulation B (15 U.S.C. § 1691(d); 12 C.F.R. § 1002.9) require creditors to state specific reasons when they deny credit.

Who's behind it: The FTC enforces the Safeguards Rule for non-bank financial institutions. OCC, FDIC, and the Federal Reserve supervise banks. The CFPB had been issuing interpretive guidance on AI-driven credit decisions but withdrew 67 guidance documents in May 2025 (90 Fed. Reg. 20,084), including Circular 2022-03 on adverse action requirements for complex algorithms and Circular 2023-03. The underlying statutes survived the withdrawal.

What makes it distinct: Explainability. When a model denies a loan, Regulation B requires the creditor to state the principal reasons in specific, actionable terms. "The model scored you below threshold" doesn't satisfy the statute. Black-box models and adverse action notices are structurally incompatible, and nobody has resolved that tension cleanly yet.

FedRAMP

What it is: The federal program that standardizes security assessment and authorization for cloud services used by government agencies.

What it does: Establishes security control baselines (Low, Moderate, High) that cloud service providers must implement and have independently assessed before agencies can procure them.

Who's behind it: GSA runs the program. The FedRAMP Board sets priorities. The CIO Council has pushed GSA to prioritize AI cloud authorizations (GSA announcement, August 2025).

What makes it distinct: FedRAMP authorization attaches to the cloud service. The model running on that service is a separate matter. Individual LLMs don't appear in the FedRAMP Marketplace as independently authorized offerings. Authorization attaches to the serving infrastructure and the services built on it.

SOC 2

What it is: A voluntary attestation framework based on the AICPA's Trust Services Criteria, covering security, availability, processing integrity, confidentiality, and privacy.

What it does: A CPA firm examines whether a service organization's controls meet the Trust Services Criteria over a defined period (Type II) or at a point in time (Type I), then issues a report that procurement teams use for vendor risk assessment.

Who's behind it: The AICPA defines the criteria. CPA firms perform the examinations. No regulator mandates SOC 2, but enterprise and agency procurement teams treat it as table stakes.

What makes it distinct: SOC 2 covers whatever the vendor puts in scope. And that's where it gets interesting. The Trust Services Criteria (AICPA, primary authority for TSC scope) haven't been formally updated for AI. If a buyer asks whether a vendor's SOC 2 covers their AI system, the honest answer is: it depends entirely on what the vendor chose to include.

Comparison Strategy

I'm organizing this dimension-led rather than regime-by-regime. You walk into a meeting and the buyer raises one of these three questions. You need to know how it plays across whichever regime governs that account. Clustering by dimension serves that moment better than memorizing four separate profiles.

Applicability Triggers: When Does AI Put You in Scope?

HIPAA triggers when PHI is involved. A prompt containing a patient's name and diagnosis submitted to an AI system is a disclosure to the AI vendor under the Privacy Rule's definition of disclosure as any release of PHI to persons outside the entity. OCR's March 2024 tracking technology guidance (official HHS/OCR guidance document, primary source) establishes the operative framework: tracking technology vendors that receive PHI are business associates and require BAAs. The functional analysis maps directly to AI vendors. OCR hasn't issued AI-specific guidance on this point, but the existing framework leaves little interpretive daylight. No BAA, no permissible use.

GLBA triggers when AI touches customer financial information or drives credit decisions. The Safeguards Rule applies to the data regardless of what processes it. The adverse action requirement under ECOA/Reg B triggers when AI contributes to denying or changing the terms of credit. The CFPB's specific interpretive circulars on AI adverse action (Circular 2022-03 and Circular 2023-03) were withdrawn in May 2025 (confirmed by GAO-25-107197, official GAO report), but the statute hasn't changed. Institutions still owe specific reasons for adverse actions, even when AI made the call.

FedRAMP triggers when a federal agency wants to use a cloud service. The AI complication: FedRAMP 20x, the accelerated authorization pathway announced by GSA in March 2025, is processing AI cloud services, but authorization attaches to the infrastructure, not the model. Google's FedRAMP documentation (official Google Cloud documentation, primary source for vendor architecture) states this plainly: individual LLMs aren't independently authorized, and for self-deployed open-source models, security is the customer's responsibility. As of May 2026, OpenAI holds FedRAMP 20x Moderate for ChatGPT Enterprise and API Platform (listed on the FedRAMP Marketplace for corroboration). Google's Vertex AI services, including Generative AI on Vertex AI, hold FedRAMP High (also listed on the FedRAMP Marketplace). If the model isn't served through authorized infrastructure at the right impact level, the agency can't use it.

SOC 2 doesn't trigger the way regulatory regimes do. It triggers when a buyer's procurement or security team requires it. The real AI question is whether the vendor's SOC 2 report covers AI-related controls or just the underlying infrastructure. The AICPA has issued nonauthoritative guidance on AI use but has not formally incorporated AI criteria into the Trust Services Criteria (AICPA, primary authority). Audit firms like Moss Adams and Schellman (specialist SOC 2 practitioners, secondary corroboration) confirm the gap: a vendor's SOC 2 might be completely silent on model behavior, training data handling, and output monitoring.

Architecture Constraints: What Can't You Build?

HIPAA's minimum necessary standard (45 CFR 164.502(b)) constrains how much PHI an AI system can access. An AI agent scheduling a follow-up appointment doesn't need the full patient chart. But most AI systems are designed to ingest broad context to perform well. You need to limit what PHI reaches the model before the prompt. Data filtering upstream of the model is an architecture decision. It has to happen before the prompt hits the model.

GLBA's constraint is explainability. If you can't explain why the model denied a loan in specific, actionable terms, you can't use that model for credit decisioning under Reg B. The GAO's May 2025 report (official GAO report, the strongest single public source on the current AI financial services regulatory landscape) found that some banks' risk assessments didn't capture risk factors unique to AI models, and that regulators themselves need to clarify expectations. The Treasury Department's December 2024 report (official Treasury publication) flagged model opacity as a systemic risk, noting that "black box" systems make it "challenging for firms to explain decision-making processes." The architecture implication is blunt: opaque models are a regulatory liability for any decision requiring adverse action notices.

FedRAMP constrains where the workload runs. The model must be served through FedRAMP-authorized infrastructure at the appropriate impact level. You cannot take an authorized cloud platform, deploy an unauthorized open-source model on it, and call the result authorized. Google's FedRAMP implementation guidance is explicit:

For self-deployed models, your ATO assessment must cover that model infrastructure separately.

SOC 2 constrains what you can claim in vendor risk assessments. If your SOC 2 report doesn't include AI-specific controls, a sophisticated buyer will notice the gap. The constraint is indirect but real: organizations building AI services are increasingly expected to include model monitoring, data provenance, and output controls in their system description. AI governance enters SOC 2 through the SOC 2+ mechanism, where organizations voluntarily map controls to additional frameworks like ISO 42001 or NIST AI RMF alongside the base examination.

Evidence Requirements: What Do You Need to Show?

HIPAA requires risk analysis documentation, BAAs with AI vendors, access logs, and breach notification procedures. The proposed Security Rule update (January 2025 NPRM published in the Federal Register, primary source; not finalized as of May 2026 and subject to the administration's regulatory freeze) would tighten requirements and remove the distinction between "required" and "addressable" safeguards. AI-specific evidence that has no traditional equivalent: documentation that AI vendors are prohibited from using PHI for model training, and that prompts containing PHI are logged and auditable.

GLBA requires a written information security program, vendor oversight documentation, and adverse action notices with specific reasons for credit decisions. AI-specific evidence: model risk management documentation per OCC's updated April 2026 guidance (OCC News Release 2026-29, issued jointly with the Federal Reserve and FDIC; primary source, very recent), model validation records, and documentation showing the institution can reconstruct why a specific decision was made. The GAO found that OCC reviewers flagged banks for providing "limited information on their efforts to evaluate bias and fair lending issues associated with AI."

FedRAMP requires the full security package (SSP, SAR, POA&M) at the appropriate impact level. Under FedRAMP 20x, evidence must be machine-readable (OSCAL format) and continuously generated rather than periodic snapshots. AI-specific evidence: the authorization boundary must clearly delineate which models are served through the authorized infrastructure and which are customer-deployed. Nextgov/FCW reported (credible specialist press) that KPI standards development for 20x Low and Moderate is delayed, so expect the specific evidence requirements to keep evolving through FY26.

SOC 2 requires whatever the service organization puts in scope. Same flexibility, same problem. A SOC 2 Type II report on a platform that runs AI but scoped only to infrastructure controls will show clean opinions on security and availability while saying nothing about model behavior. AI-specific evidence showing up in forward-looking reports: training data provenance, model evaluation records, output monitoring, bias testing. These appear in SOC 2+ reports mapped to ISO 42001 or NIST AI RMF, and they sit outside the base TSC examination.

How to Say This in the Field

The line between useful and reckless in compliance conversations is thinner than you think. Everything below is designed to surface the right question for the buyer's compliance team to answer. You are not the compliance team.

Don't say	Do say	Why it matters
"You'll need a BAA with your AI vendor."	"Has your team confirmed whether your AI vendor will sign a BAA that explicitly addresses prompt data and model training?"	Surfaces the question without giving compliance advice.
"Prompts with PHI are disclosures under HIPAA."	"OCR's tracking technology guidance treats third-party data receipt as a disclosure. Has your privacy office evaluated whether that applies to your AI vendor?"	Frames it as their team's determination, backed by a specific HHS document.
"Your AI vendor needs to be FedRAMP authorized."	"Which AI services in your environment have FedRAMP authorization at the impact level you need, and does that cover the specific models or just the platform?"	Surfaces the model-vs-infrastructure gap without overstepping.
"FedRAMP 20x makes this faster now."	"Some AI vendors have come through the 20x pathway at Moderate. Is your agency looking at Moderate or High for this workload?"	Shows you know the program without claiming procurement expertise.
"You need explainable AI for lending."	"OCC's updated model risk management guidance applies to AI models. Has your compliance team mapped AI-driven decisions against adverse action notice requirements?"	Points to the specific regulatory instrument.
"The CFPB requires specific reasons for AI denials."	"The CFPB withdrew Circular 2022-03 and its other AI-related guidance last May, but the underlying Reg B requirement for specific reasons hasn't changed. Is your team tracking how that shakes out?"	Shows you know the withdrawal happened and which circulars were affected. Most sellers won't.
"Your vendor has SOC 2, so you're covered."	"Does their SOC 2 scope include the AI system, or just the hosting infrastructure? There's a meaningful difference."	Prevents the buyer from assuming coverage they don't have.
"SOC 2 doesn't cover AI yet."	"The base Trust Services Criteria don't include AI-specific controls, but some vendors are adding AI governance through SOC 2+ mappings to ISO 42001. Worth asking what's in scope."	Accurate and actionable without overstating the gap.
"AI compliance is really complicated right now."	"The evidence requirements for AI don't map cleanly to what you're used to on the identity side. Training data provenance and model cards have no traditional equivalents. Has your team started defining what documentation they'll require from AI vendors?"	Specific about what's different instead of vaguely anxious.
"We can help you with compliance."	"Identity is one layer of the compliance picture. We can speak to how authentication, authorization, and lifecycle management map to these requirements. For AI-specific controls, that's a conversation for your compliance team and your AI vendors."	Draws the line between what you sell and what you don't.

What You're Carrying Into the Room

AI has expanded the surface area of regimes your buyer already understands. PHI shows up in prompts now, not just databases. Credit decisions come from models that can't always explain themselves. Federal agencies need to distinguish between an authorized platform and an authorized model. SOC 2 reports may cover everything except the AI system generating the risk.

Your job is to be the person in the room who knows these questions exist, who can name the specific guidance document or regulatory instrument behind each one, and who can point the buyer at the right team to get answers. That's worth more than a clean slide deck.