HIPAA
What it is: The Health Insurance Portability and Accountability Act, a federal law establishing privacy and security requirements for protected health information.
What it does: HIPAA requires covered entities — healthcare providers, health plans, clearinghouses — and their business associates to protect PHI through administrative, physical, and technical safeguards. The Privacy Rule governs disclosure; the Security Rule governs electronic PHI specifically. The operative question for AI deployments is whether a prompt containing patient information constitutes a disclosure. HHS Office for Civil Rights has taken the position, in guidance issued in 2024, that it does: when a covered entity sends a query containing PHI to an external AI system, that transmission is a disclosure to a business associate, triggering BAA requirements regardless of whether the AI vendor stores the data.
Who's behind it: HHS Office for Civil Rights enforces HIPAA. OCR investigates complaints and conducts audits; penalties range from $100 to $50,000 per violation, with annual caps by violation category.
What makes it distinct: The BAA is the operational constraint, and "HIPAA compliant" is not a legal status. An AI vendor can describe itself as HIPAA-ready, HIPAA-aligned, or HIPAA-capable — none of those phrases carries legal weight. What matters is whether the vendor will execute a BAA and whether their technical architecture can actually support the safeguards the BAA requires. A vendor whose model training pipeline ingests customer prompts to improve the model cannot execute a meaningful BAA, because the training use is a secondary disclosure the covered entity hasn't authorized.
GLBA
What it is: The Gramm-Leach-Bliley Act, a federal law requiring financial institutions to protect the privacy and security of customer financial information.
What it does: GLBA's Safeguards Rule, updated by the FTC in 2023, requires financial institutions to implement a written information security program with specific technical controls. Two pressures bear on AI deployments specifically: the Safeguards Rule's requirement to assess risks from service providers who handle customer data, and the interagency guidance on AI in financial services — issued jointly by the OCC, FDIC, Federal Reserve, NCUA, and CFPB in 2023 — which establishes expectations for explainability in AI-driven credit and underwriting decisions. GLBA itself doesn't mandate explainability, but the interagency guidance makes clear that institutions using AI for adverse action decisions must be able to generate specific reasons, not statistical correlations.
Who's behind it: The FTC enforces GLBA for most non-bank financial institutions. Banking regulators — OCC, FDIC, Federal Reserve — enforce equivalent requirements for supervised banks through examination authority.
What makes it distinct: GLBA creates a model governance obligation that most AI vendors aren't designed to meet. A financial institution using a third-party LLM for loan decisioning needs to explain, in terms a consumer can understand, why a specific decision was made. A model that produces a probability score without traceable feature attribution doesn't satisfy that requirement. Choosing between a black-box model, an interpretable model, and an LLM with structured output is, for a GLBA-covered institution, a compliance decision as much as an architectural one.
FedRAMP
What it is: The Federal Risk and Authorization Management Program, a government-wide framework for authorizing cloud services used by federal agencies.
What it does: FedRAMP establishes a standardized security authorization process based on NIST SP 800-53 controls, tiered by impact level: Low, Moderate, and High. Moderate authorization covers systems where compromise would have serious adverse effects; High covers systems where compromise would have severe or catastrophic effects. FedRAMP Moderate is the practical floor for most civilian agency AI use cases; FedRAMP High is required for systems handling sensitive law enforcement, financial, or health data in federal contexts. Agencies are generally prohibited from using cloud services that lack FedRAMP authorization or an active authorization-in-process designation.
Who's behind it: GSA's FedRAMP Program Management Office manages the authorization process. The Joint Authorization Board — composed of DoD, DHS, and GSA — grants provisional authorizations that agencies can then leverage through the "authorize to operate" process.
What makes it distinct: FedRAMP is a procurement gate before it's a compliance framework. An AI vendor without FedRAMP authorization cannot be in the conversation for most federal deployments, regardless of how strong their security posture is. The authorization process takes an average of 14 to 18 months for Moderate and longer for High, which means the vendor landscape for FedRAMP-authorized AI is significantly narrower than the commercial AI market. The distinction between "FedRAMP Authorized" and "FedRAMP Ready" is material: Ready means the vendor has completed a readiness assessment, not that they've achieved authorization. Agencies cannot use FedRAMP Ready services under the standard ATO process.
SOC 2
What it is: A voluntary auditing standard developed by the American Institute of Certified Public Accountants, based on the Trust Services Criteria for security, availability, processing integrity, confidentiality, and privacy.
What it does: SOC 2 provides independent third-party attestation that a service organization has controls in place for one or more Trust Services Criteria. Type I reports attest to control design at a point in time; Type II reports attest to operating effectiveness over a period, typically six to twelve months. The AICPA released supplemental guidance in late 2024 on applying Trust Services Criteria to AI systems, and a growing number of auditors are including AI-specific control sections — covering model governance, training data provenance, and output monitoring — in Type II engagements. This is genuinely unsettled: there is no standardized AI control section yet, and what one auditor includes another may not.
Who's behind it: The AICPA sets the framework. Audits are conducted by licensed CPA firms; there is no government enforcement mechanism. Buyers require SOC 2 reports contractually, not legally.
What makes it distinct: SOC 2 is the most buyer-driven and the most flexible of the four regimes. There is no regulatory mandate to achieve SOC 2 — buyers require it because it provides independent evidence of control effectiveness that vendor-completed security questionnaires don't. For AI vendors, a SOC 2 Type II report covering AI-specific controls is increasingly a commercial expectation in enterprise sales cycles, but the absence of a standardized AI control section means buyers need to read the report's scope carefully rather than treating the attestation as a uniform signal.
Comparison: Three Axes Across Four Regimes
Trait-led analysis across the three axes — trigger, architecture constraint, and evidence requirement — is the right structure here, not scenario mapping or clustering by sector. The profiles covered per-regime mechanics; this section shows where the regimes converge and diverge on each dimension simultaneously, which is the view an AE needs when a buyer operates in more than one regulated space.
What triggers applicability
HIPAA and GLBA trigger on data type and institutional category: if you're a covered entity handling PHI, HIPAA applies; if you're a financial institution handling customer financial information, GLBA applies. Neither requires a specific technology deployment to activate — they apply to the institution and extend to any vendor that handles covered data. FedRAMP triggers on the buyer's identity: if the buyer is a federal agency, FedRAMP applies to any cloud service they procure. SOC 2 triggers on contract: it applies when a buyer requires it as a condition of vendor selection. HIPAA and GLBA are non-negotiable for the institutions they cover; FedRAMP is non-negotiable for federal buyers; SOC 2 is negotiable in principle but practically non-negotiable in enterprise sales.
What architecture decisions it constrains
HIPAA constrains data flow: specifically, whether PHI leaves the covered entity's environment and under what terms. An on-premises or private-cloud AI deployment with no external data transmission avoids the BAA trigger; a SaaS AI deployment that processes patient queries does not. GLBA constrains model design: specifically, whether the model can produce traceable, human-readable explanations for adverse decisions. An LLM that outputs a recommendation without feature attribution creates GLBA exposure for a financial institution using it for credit decisions. FedRAMP constrains vendor selection: the architecture decision is made before the deployment, at the point of procurement. High-impact deployments require vendors with High authorization, which eliminates most of the commercial AI market. SOC 2 constrains control documentation: the architecture must be auditable, with evidence of control design and operating effectiveness that a CPA firm can attest to.
What evidence it requires from an AI deployment
HIPAA requires a signed BAA and documentation that the vendor's technical controls satisfy the Security Rule's safeguards. GLBA requires documentation of the vendor risk assessment and, for AI-driven decisioning, evidence that the model can produce adverse action reasons that satisfy FCRA requirements. FedRAMP requires an Authority to Operate letter from the agency, based on the vendor's existing FedRAMP authorization package. SOC 2 requires a Type II report from a licensed CPA firm, covering the Trust Services Criteria relevant to the buyer's risk concerns. The evidence timelines differ significantly: a BAA can be executed in days; a FedRAMP authorization takes months to years; a SOC 2 Type II report requires at least six months of observation period.
Field Language Guide
| Don't say | Do say | Why it matters |
|---|---|---|
| "Our AI vendor is HIPAA compliant." | "Our AI vendor will execute a BAA and their architecture supports the Security Rule's technical safeguards." | "HIPAA compliant" has no legal definition; a BAA is the operative requirement and buyers' counsel will ask for it |
| "We're working toward FedRAMP." | "We have FedRAMP Ready designation and an active authorization-in-process with [agency sponsor]; projected authorization is Q3 2026." | "Working toward" signals no timeline; agencies need a specific authorization status to begin procurement |
| "FedRAMP Moderate covers most federal use cases." | "FedRAMP Moderate covers most civilian agency use cases; your specific data classification determines whether High is required." | Moderate is not a universal floor; misclassifying a High-impact system creates ATO risk for the agency |
| "SOC 2 certified" | "SOC 2 Type II attested, covering Security and Availability criteria, with a 12-month observation period ending [date]." | Type I and Type II are materially different; scope and period matter; "certified" is not the correct term for SOC 2 |
| "The model can explain its decisions." | "The model produces feature-level attribution for each output, which can be mapped to FCRA adverse action reason codes." | Explainability is a spectrum; GLBA and FCRA require specific, consumer-legible reasons, not statistical summaries |
| "Sending prompts to the AI doesn't count as a disclosure." | "We need to review whether the prompts contain PHI; if they do, the vendor needs to be a business associate under a signed BAA." | HHS OCR's 2024 guidance treats PHI in prompts as a disclosure; assuming otherwise creates enforcement exposure |
| "We have FedRAMP High." | "We have FedRAMP High authorization; the specific controls in our authorization package cover [relevant system boundary]." | High authorization applies to a defined system boundary; buyers need to confirm their use case falls within it |
| "Our SOC 2 covers AI." | "Our most recent Type II report includes an AI governance section covering model training controls, output monitoring, and data provenance; I can share the relevant sections." | AI control sections in SOC 2 are not standardized; buyers need to see the actual scope, not a summary claim |
| "GLBA doesn't really apply to AI." | "GLBA's Safeguards Rule applies to any service provider handling customer financial data, including AI vendors; the interagency AI guidance adds model governance expectations on top of that." | Framing GLBA as inapplicable to AI is incorrect and will surface in the buyer's legal review |
| "You can use this for federal deployments." | "This deployment requires confirming the vendor's FedRAMP authorization level matches your system's impact classification before procurement can proceed." | Procurement without confirmed authorization creates legal and security risk for the agency |
| "The BAA is standard." | "The BAA needs to reflect how this specific AI vendor handles PHI — training data use, subprocessor chains, and breach notification timelines are the sections that typically require negotiation." | Standard BAA language often doesn't address AI-specific data flows; gaps create liability |
| "SOC 2 is basically the same as FedRAMP for commercial buyers." | "SOC 2 is buyer-driven attestation; FedRAMP is a government authorization program with legal procurement implications. They address different risk questions." | Conflating them signals unfamiliarity with both frameworks to a technically literate buyer |
Callout: Okta Concept Mapping
IDAM analog: The federation trust agreement
A Business Associate Agreement under HIPAA does structurally similar work to a SAML federation trust agreement: it establishes the terms under which a downstream processor can handle sensitive data, defines what the data can be used for, and creates accountability for what happens when something goes wrong. The analogy is useful in a buyer conversation — both instruments formalize a trust relationship between a data source and a data consumer. It breaks at enforcement: a federation trust agreement is technically enforced at the protocol layer, meaning an IdP won't release attributes to an SP that isn't in the metadata. A BAA is legally enforced after the fact, through OCR investigation and civil penalties. A healthcare buyer who understands federation will sometimes assume that a BAA provides the same kind of real-time control that attribute release policies do. It doesn't. The BAA governs what the vendor is permitted to do; it doesn't prevent them from doing something else.