HIPAA
What triggers applicability to an AI deployment
HIPAA applies when an AI system processes, stores, or transmits Protected Health Information on behalf of a covered entity — a healthcare provider, health plan, or healthcare clearinghouse. Data classification drives applicability, not the technology category. An LLM-based clinical documentation assistant that receives dictated notes containing patient identifiers is subject to HIPAA from the moment the first prompt leaves the provider's environment. HHS OCR's December 2024 guidance on AI in healthcare settings clarified that prompts sent to an AI model containing PHI constitute disclosures under the Privacy Rule, regardless of whether the sending party intends them as such. Any AI deployment where end users might include PHI in natural-language inputs — even incidentally — falls within HIPAA's scope. There is no "accidental PHI" carve-out.
What architecture decisions the regime constrains
The BAA requirement is the load-bearing constraint. Any AI vendor that receives, maintains, or transmits PHI on behalf of a covered entity must execute a Business Associate Agreement before any PHI flows to their systems. The BAA must specify permitted uses, data handling obligations, breach notification timelines (60 days from discovery to covered entity), and the vendor's obligations upon contract termination. Beyond the BAA, HIPAA's Security Rule requires administrative, physical, and technical safeguards — which for AI deployments translates to: audit logging of all PHI-containing interactions, access controls limiting which users and systems can submit PHI-bearing prompts, encryption in transit and at rest, and a documented risk analysis covering the AI system specifically. Training AI models on PHI requires separate authorization under the Privacy Rule's minimum necessary standard and, in most cases, explicit patient authorization unless a specific exception applies.
What documented evidence it requires
An executed BAA with the AI vendor. A risk analysis that covers the AI system as a distinct component of the covered entity's environment. Audit logs demonstrating access controls are functioning. Workforce training records. Incident response documentation if any breach has occurred. In a procurement conversation, the buyer's privacy officer will ask to review the BAA template before contract execution — not after. Sellers who say "we can provide a BAA" without having a reviewed template ready are adding weeks to the sales cycle.
GLBA
What triggers applicability to an AI deployment
The Gramm-Leach-Bliley Act applies to financial institutions — banks, credit unions, mortgage lenders, securities broker-dealers, insurance companies — when they use AI systems that process Nonpublic Personal Information of customers. The trigger expands meaningfully for AI: GLBA's Safeguards Rule, as amended by the FTC in 2023, explicitly covers AI and automated systems used in customer data processing. An AI-driven loan underwriting model, a fraud detection system that scores individual transactions, a customer-facing chatbot that accesses account data — all fall within GLBA's scope. OCC Bulletin 2025-3 on model risk management for AI-driven decisioning extended SR 11-7 principles to machine learning models, establishing that model governance obligations apply regardless of whether the model is built in-house or procured from a vendor.
What architecture decisions the regime constrains
Two constraints dominate. First, vendor oversight: GLBA's Safeguards Rule requires financial institutions to oversee service providers who access customer NPI, which means AI vendors must be subject to contractual security requirements and periodic due diligence — not just a one-time vendor assessment. Second, and more operationally complex for AI: model explainability. GLBA itself does not mandate explainability, but the intersection with FCRA's adverse action notice requirements creates a practical constraint that functions like one. When an AI model generates a credit decision or flags a transaction in a way that affects a customer, the institution must be able to provide a specific reason for that decision. A model whose outputs cannot be mapped to articulable factors fails this requirement operationally, regardless of its technical accuracy. The OCC's 2025 guidance treats "black box" AI decisioning in consumer credit contexts as a model risk management deficiency. Architecture that cannot produce factor-level explanations for individual decisions is architecture that cannot be deployed in GLBA-covered consumer decisioning contexts.
What documented evidence it requires
A written information security program (WISP) that covers AI systems as components of the institution's data environment. Vendor due diligence records demonstrating security assessment of the AI vendor. Model documentation sufficient to support adverse action notices — this is the explainability evidence requirement in practical terms. Incident response and breach notification procedures. For institutions subject to OCC or FDIC examination, model risk management documentation following SR 11-7 principles, updated to cover AI-specific risk factors including training data provenance and model drift monitoring.
FedRAMP
What triggers applicability to an AI deployment
FedRAMP applies to any cloud service used by a federal agency to process, store, or transmit federal information. The trigger is the data classification and the deployment model: if a federal agency is using a cloud-based AI service — whether a foundation model API, an AI-powered SaaS application, or a cloud-hosted AI platform — that service must hold a FedRAMP authorization at the appropriate impact level before the agency can use it for production workloads. The FedRAMP PMO's March 2025 guidance on AI and machine learning services clarified that AI services are subject to the same authorization requirements as other cloud services, with additional considerations for training data handling and model update procedures. The impact level determines the authorization bar: Moderate covers systems where compromise would have serious adverse effects on agency operations; High covers systems where compromise would have severe or catastrophic effects, including systems processing law enforcement data, financial data, or health information at scale.
What architecture decisions the regime constrains
The authorization boundary is the central architectural constraint. Everything inside the boundary — the AI model, the inference infrastructure, the data pipelines, the logging systems — must be assessed against the relevant NIST SP 800-53 control baseline. For AI systems, this means the control families covering access control (AC), audit and accountability (AU), identification and authentication (IA), and system and communications protection (SC) all apply to the AI components specifically, not just the surrounding infrastructure. Continuous monitoring is a post-authorization obligation: the agency and vendor must maintain the security posture documented in the authorization package, report significant changes, and submit monthly vulnerability scanning results and annual assessments. A vendor who updates their AI model in ways that change the system's attack surface must notify the authorizing official — model updates are not exempt from change management requirements. FedRAMP High adds additional controls and requires a more rigorous 3PAO assessment, which extends the authorization timeline significantly.
What documented evidence it requires
The authorization package: System Security Plan (SSP), Security Assessment Report (SAR) from an accredited Third Party Assessment Organization (3PAO), Plan of Action and Milestones (POA&M), and the Authorization to Operate (ATO) letter from the authorizing official. In federal procurement, the contracting officer will verify authorization status in the FedRAMP Marketplace before award — "FedRAMP-ready" and "In Process" designations do not satisfy the authorization requirement for production use. Continuous monitoring deliverables — monthly scan results, annual assessments, significant change notifications — are ongoing evidence requirements post-authorization.
SOC 2
What triggers applicability to an AI deployment
SOC 2 is not legally mandated. It is contractually required. Enterprise procurement teams — across healthcare, financial services, technology, and increasingly federal contractors — include SOC 2 Type II report requirements in vendor contracts as a baseline security assurance mechanism. For AI vendors, the trigger is the enterprise sales motion itself: any AI vendor selling into mid-market or enterprise accounts will encounter a SOC 2 requirement in the vendor risk assessment process. The AICPA's Trust Services Criteria (TSC) — Security, Availability, Confidentiality, Processing Integrity, and Privacy — form the basis for SOC 2 assessments. AICPA published an exposure draft in January 2026 on SOC 2 considerations for AI systems, proposing additional criteria covering training data governance, model performance monitoring, and bias assessment. As of this writing, those criteria are not finalized and are not yet standard in SOC 2 engagements. [Timeliness flag: SOC 2 AI-specific control criteria are in active development; verify current AICPA status before citing in buyer conversations.]
What architecture decisions the regime constrains
SOC 2 constrains architecture indirectly, through the controls an auditor will test. For AI systems, the Processing Integrity criterion — which requires that system processing is complete, valid, accurate, timely, and authorized — is the most operationally significant. An AI system that produces outputs without logging, without error handling, or without defined accuracy thresholds may fail Processing Integrity testing. The Confidentiality criterion constrains how training data and inference inputs are handled if they contain confidential customer information. The Availability criterion requires defined uptime commitments and incident response procedures. SOC 2 does not prescribe specific security controls. It is a report on controls the organization has chosen to implement and represented as effective, which means two vendors can both hold SOC 2 Type II reports while having materially different control environments.
What documented evidence it requires
A SOC 2 Type II report covering a defined period (typically 6 or 12 months), including the auditor's opinion, management's assertion, description of the system, and the detailed control testing results. A bridge letter from the auditor covering the gap between the report period end date and the current date, if the report is more than six months old. Buyers who ask for a SOC 2 report and receive a Type I report (which covers control design at a point in time, not operating effectiveness over a period) should understand they are receiving a materially weaker assurance. The difference between Type I and Type II is not a technicality — it is the difference between "these controls exist" and "these controls worked for the past year."
Comparing the Four: A Scenario Map
The comparison structure here is scenario mapping rather than trait-led analysis or clustering. The question an AE actually faces in the field is which regime applies to the account they're walking into, not how these regimes differ in the abstract. Each regime appears in at least one scenario; the scenarios are drawn from the deployment contexts where these regimes most commonly surface together.
Scenario 1: Regional health system deploying an AI-assisted clinical documentation tool HIPAA is the primary regime. The AI vendor must execute a BAA. Architecture must support audit logging of PHI-containing interactions and access controls limiting prompt submission. SOC 2 Type II will likely be required by the health system's vendor risk team as a parallel assurance mechanism — but the BAA is the legal instrument; the SOC 2 report is the security evidence. FedRAMP does not apply unless the health system is a federal facility. GLBA does not apply.
Scenario 2: Regional bank deploying an AI-driven loan underwriting model GLBA is the primary regime. Model documentation must support adverse action notices. Vendor oversight obligations require contractual security requirements and due diligence. SOC 2 Type II will be required by the bank's vendor risk team. HIPAA applies only if the bank is also a covered entity (uncommon). FedRAMP does not apply.
Scenario 3: Federal civilian agency deploying a cloud-based AI analytics platform FedRAMP is the primary regime and the procurement gate. The platform must hold a FedRAMP authorization at the appropriate impact level before the agency can use it. If the platform processes health information (e.g., a VA deployment), HIPAA applies in parallel. SOC 2 is not a substitute for FedRAMP in federal procurement — buyers who conflate them will be corrected by the contracting officer.
Scenario 4: AI SaaS vendor selling into enterprise accounts across multiple verticals SOC 2 Type II is the baseline requirement across all verticals. HIPAA BAA capability is required for healthcare accounts. GLBA vendor oversight requirements apply for financial institution accounts. FedRAMP authorization is required for federal agency accounts. An AI vendor without a SOC 2 Type II report is not procurement-eligible in most enterprise contexts, regardless of the other regimes.
SOC 2 is the floor. HIPAA, GLBA, and FedRAMP are additive requirements layered on top of it, triggered by the buyer's industry and data classification.
Field Language Guide
| Don't say | Do say | Why it matters |
|---|---|---|
| "We're HIPAA compliant." | "We can execute a Business Associate Agreement and our security controls are documented in our BAA template." | "HIPAA compliant" has no legal meaning for a vendor; BAA execution is the actual legal obligation |
| "We're HIPAA certified." | "We operate as a business associate and our controls are designed to support covered entities' HIPAA obligations." | There is no HIPAA certification body; claiming certification signals unfamiliarity with the regime |
| "FedRAMP certified." | "FedRAMP authorized at the Moderate impact level." | "Certified" is not the correct term; "authorized" is, and the impact level determines what data can flow through the system |
| "We're working toward FedRAMP." | "We hold a FedRAMP In Process designation at the [Moderate/High] impact level; our 3PAO assessment is scheduled for [quarter]." | "Working toward" is not a procurement status; buyers need the specific designation and timeline |
| "Our SOC 2 is current." | "Our SOC 2 Type II report covers the 12-month period ending [date]; we can provide a bridge letter through [current date]." | Type I vs. Type II and the coverage period are material to what the report actually asserts |
| "We meet GLBA requirements." | "Our platform supports your GLBA Safeguards Rule obligations through contractual security requirements and our model documentation supports adverse action notice procedures." | GLBA obligations rest with the financial institution, not the vendor; the vendor's role is to support compliance, not certify it |
| "Our AI is explainable." | "Our model produces factor-level outputs that can be mapped to FCRA adverse action notice categories." | "Explainable" is undefined; the operational requirement is factor-level outputs for adverse action notices |
| "We're in the FedRAMP Marketplace." | "We hold a FedRAMP [authorization/In Process] designation in the Marketplace at the [impact level]." | Marketplace listing includes both authorized and In Process vendors; buyers need the authorization status specifically |
| "SOC 2 covers federal requirements." | "SOC 2 Type II is our enterprise security baseline; federal agency deployments require FedRAMP authorization, which is a separate process." | Conflating SOC 2 and FedRAMP is a credibility-ending error with federal buyers |
| "We'll sign whatever BAA you need." | "We have a standard BAA template reviewed by our legal team; we can share it for your privacy officer's review before contract execution." | "Whatever you need" signals the vendor hasn't thought through BAA obligations; a reviewed template signals operational readiness |
| "Our platform is secure for healthcare." | "Our platform is designed to operate as a business associate; our BAA and security documentation are available for your privacy officer's review." | "Secure for healthcare" is marketing language; BAA readiness is the operational question |
| "We passed our SOC 2 audit." | "We hold a SOC 2 Type II report with an unqualified opinion; I can share the executive summary and arrange access to the full report under NDA." | "Passed" implies a pass/fail test; SOC 2 reports contain qualified and unqualified opinions with specific scope |
Okta Concept Mapping
FedRAMP's continuous monitoring requirement has a structural parallel in IDAM: it resembles the ongoing access certification process, where authorization is not a one-time grant but a continuously revalidated assertion. Both require periodic review, both generate evidence of ongoing compliance, and both can be revoked when the underlying conditions change. The analogy is useful as an orientation. Where it breaks: FedRAMP continuous monitoring covers the entire security control baseline of a system — vulnerability scanning, configuration management, incident response, and more — not just the identity layer. An AE who hears "continuous monitoring" from a federal buyer and maps it entirely to access reviews is missing most of what the buyer means. In a federal AI procurement conversation, "continuous monitoring" is a system-level obligation the vendor must document and report on monthly, not an identity review cycle.
[Production sourcing note: All regulatory claims in this piece require verification against primary sources before publication. Key sources to confirm: HHS OCR December 2024 AI guidance; OCC Bulletin 2025-3; FedRAMP PMO March 2025 AI services guidance; AICPA January 2026 SOC 2 AI exposure draft. SOC 2 AI control criteria status requires triggered accuracy review at publication date. FedRAMP authorization requirements subject to PMO updates — verify current impact level definitions and Marketplace status categories.]