Every enterprise buyer evaluating an AI platform eventually lands on the same two questions. Is it SOC 2 Type II attested? And can you sign a Business Associate Agreement under HIPAA? These are no longer nice-to-haves. They are the baseline that decides whether a vendor even makes it to a shortlist.
If you are building with AI, selling AI-powered software to regulated industries, or procuring one of these platforms for internal use, it helps to understand what these frameworks actually cover, where the major providers stand, and where the compliance burden quietly shifts back to you.
What SOC 2 and HIPAA Actually Cover
SOC 2 is an auditing framework from the AICPA that evaluates a vendor’s controls across five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. A Type I report says the controls are well designed on a given date. A Type II report, which is what enterprise buyers usually insist on, verifies those controls operated effectively over a period of six to twelve months.
HIPAA is a very different beast. It is US federal law governing protected health information, and there is no such thing as being “HIPAA certified.” You are either compliant or you are not, and the proof lives in your policies, risk assessments, Business Associate Agreements, and the evidence that backs them up. Any vendor that creates, receives, stores, or transmits PHI on behalf of a covered entity becomes a business associate, which means a BAA is mandatory before any real data flows.
The two frameworks overlap meaningfully. Access controls, encryption, monitoring, and incident response all appear in both. But HIPAA is narrower and stricter in scope, tied to PHI, while SOC 2 is broader and more flexible, focused on whether your security posture as a whole is sound.
Where the Major AI Providers Stand
The compliance posture across the leading enterprise AI platforms has matured quickly, but it is not uniform. A few patterns are worth knowing.
Anthropic holds SOC 2 Type II attestation and will sign BAAs with enterprise customers on the Claude API and Claude for Enterprise. The consumer Claude.ai product does not come with a BAA, which is a distinction many teams miss. Claude is also accessible through AWS Bedrock and Google Vertex AI, both of which operate under HIPAA-eligible cloud environments.
OpenAI offers BAAs through its enterprise and API agreements, with data retained briefly for abuse monitoring and not used for training under those contracts. As with Anthropic, the consumer product is a different story. ChatGPT Free, Plus, and Team are not covered by BAAs and should never touch PHI.
Microsoft Azure OpenAI Service inherits Azure’s broad compliance footprint, including SOC 2, HIPAA through BAAs, and a long list of regional certifications. For Microsoft-centric enterprises, this is often the path of least resistance.
Google Vertex AI supports HIPAA through Google Cloud’s BAA, carries SOC 2 and ISO 27001 attestations, and in 2025 became the first generative AI platform to achieve FedRAMP High authorization. Coverage varies model by model, so checking the specific model’s eligibility matters.
AWS Bedrock provides a HIPAA-eligible environment that covers Anthropic Claude, Meta Llama, Amazon Titan, and others, with the AWS BAA extending to covered services. Approval for PHI use tends to be the fastest of the major clouds.
The practical implication is that if you need to use a frontier model with PHI, routing through a hyperscaler such as Bedrock, Vertex AI, or Azure OpenAI is usually simpler than negotiating directly with the model provider. Pricing tends to be similar, and the compliance envelope is already in place.
The Shared Responsibility Trap
One of the most common and expensive misconceptions in this space is the idea that signing a BAA with a cloud provider or model vendor makes your application HIPAA compliant. It does not.
Every major provider operates on a shared responsibility model. The provider guarantees the security of the underlying infrastructure, the encryption of data in transit and at rest, and the integrity of the service itself. You remain responsible for identity and access management, audit logging, preventing PHI from leaking into system prompts or logs, enforcing the minimum necessary standard through role-based access, and ensuring that every downstream service that touches PHI also has a BAA in place.
A few failure patterns show up repeatedly in audits and incident reports. Clinicians using consumer chatbots with real patient data because “the company is HIPAA compliant.” Developers swapping in a second model provider without realising a new BAA is required. PHI ending up in application logs because nobody wrote the logging policy with the AI pipeline in mind. Vector databases used for retrieval-augmented generation that never got their own BAA signed.
None of these are failures of the AI platform. They are failures of the integration around it.
What Enterprise Procurement Actually Asks For
Compliance baselines for enterprise AI deployments in 2026 have hardened around a predictable set of requirements. SOC 2 Type II is effectively mandatory for any serious procurement conversation. HIPAA eligibility with a signed BAA is required for anything touching health data. ISO 27001 is increasingly requested as a baseline vendor qualification, and GDPR coverage is non-negotiable for anything with European exposure.
Beyond the certifications themselves, procurement teams are asking for specific operational capabilities. Complete, queryable audit trails of every model and agent action. Permission enforcement at the action level, not just at authentication. Explainability for higher-stakes automated decisions. Configurable data retention, ideally including zero-retention options for the most sensitive workloads.
These capabilities used to be differentiators. They are now table stakes, and vendors that cannot demonstrate them from the first proof of concept tend to get filtered out before technical evaluation even begins.
How to Approach It Practically
If you are building on top of these platforms, a few decisions will save you significant time and risk.
Start with the deployment model. Hyperscaler-mediated access (Bedrock, Vertex AI, Azure OpenAI) gives you the cleanest compliance story for regulated data, at the cost of slightly delayed access to new models. Direct API access is faster to adopt but carries more integration work if PHI is involved.
Get the BAA in place before any PHI goes anywhere near the system, not after. Check that it covers every service in the data path, including databases, monitoring tools, and third-party observability platforms. De-identify data before it reaches the model wherever you can; the safest PHI is PHI that the model never sees in identifiable form.
Treat evidence collection as a continuous process rather than an annual scramble. Modern compliance platforms can automate a large share of the work, pulling screenshots, monitoring configurations, and flagging drift in real time. Teams that adopt this approach routinely cut audit prep time from hundreds of hours to a fraction of that.
And if you are on the buying side, do not accept a vendor’s compliance claims at face value. Ask for the actual SOC 2 Type II report under NDA. Ask who the auditor was. Ask whether the certification covers the specific service or product you will be using, because compliance attested at the company level does not always extend to every individual offering.
The Direction of Travel
The enterprise AI landscape is converging on a shared expectation: security, compliance, and auditability are not bolted on after the fact. They are built into the platform, documented, independently verified, and continuously monitored. Vendors that treat this as overhead are losing ground to those that treat it as a product feature.
For teams deploying AI in healthcare, finance, public sector, or any other regulated space, the good news is that the infrastructure exists to do this properly. The harder work is the part that sits inside your own walls: the policies, the access controls, the logging discipline, and the engineering choices that decide whether your use of a compliant platform is itself compliant. That work does not go away no matter how strong the vendor’s certifications are.
