Which Compliance Frameworks Actually Apply to Your AI Agent (SOC 2, HIPAA, GDPR)

Quick answer

SOC 2 applies to essentially any B2B AI agent handling customer data, since it's a general security-and-availability attestation most enterprise buyers now require regardless of industry; HIPAA applies only if the agent touches protected health information as part of a covered entity's or business associate's data flow; GDPR applies if the agent processes personal data of anyone in the EU/UK, regardless of where your company is based. The mistake is assuming one covers the others — they govern different things, and an agent can be subject to all three, one, or none depending on what data it touches and whose it is.

SOC 2: the baseline most B2B buyers will require anyway

SOC 2 isn't a legal requirement in the way HIPAA or GDPR are — it's a voluntary attestation of security controls that has become a de facto purchasing requirement for enterprise SaaS buyers, AI agents included. If your agent is being sold into mid-market or enterprise accounts, expect a SOC 2 report to come up in procurement regardless of industry, which makes it worth treating as a baseline expectation rather than an optional differentiator, and it overlaps significantly with the security guardrails any production agent handling customer data needs anyway.

HIPAA: only when the agent touches protected health information

HIPAA applies specifically when an agent processes protected health information (PHI) on behalf of a covered entity (a healthcare provider, insurer, etc.) or as their business associate — an AI agent for a general SaaS product with no healthcare data flowing through it isn't subject to HIPAA just because health-adjacent topics come up. The trigger is the specific data type and the specific relationship to a covered entity, not the industry label alone; a fintech or HR product that happens to store some wellness-related data may need to check this more carefully than it assumes.

GDPR: governed by whose data, not where your company is

GDPR applies based on whether the agent processes personal data belonging to individuals in the EU or UK — not based on where your company is incorporated or where your servers sit. A US-based SaaS company with EU customers or EU end users interacting with its agent is subject to GDPR's requirements (right to access, right to deletion, data minimization) regardless of the company's own location, which is a common point of confusion for companies assuming compliance is only a concern for EU-headquartered businesses.

Map data flow to frameworks before mapping frameworks to features

The right sequence is data first, framework second: identify exactly what personal data types the agent touches (health data, EU resident data, payment data, general PII) and trace where each type flows through the system, then determine which frameworks that specific data flow triggers. Building compliance controls before doing this mapping tends to produce either wasted effort on frameworks that don't apply or gaps in the ones that do — this mapping exercise is also the groundwork that should inform the security guardrails an agent needs before it ever touches sensitive data.

Compliance requirements shape architecture, not just paperwork

Each framework implies specific technical requirements that need to be designed in, not bolted on afterward — GDPR's right to deletion means the agent's memory, logs, and any embeddings or fine-tuning data derived from a person's data all need to be traceable and purgeable; HIPAA's minimum-necessary-access principle means the agent's data scoping needs to be genuinely narrow, not just documented as narrow. Treat the relevant framework's specific technical requirements as architecture inputs during the system design and modernization phase, not a checklist applied after the agent is built.

Vendor and sub-processor compliance matters as much as your own

If your agent relies on a third-party LLM API or other AI vendor, their compliance posture becomes part of your compliance posture — a HIPAA-covered workflow needs a Business Associate Agreement with any vendor touching PHI, and GDPR requires appropriate data processing agreements with sub-processors. This is a concrete line item to verify when evaluating any AI vendor or agency, not an assumption to leave unconfirmed until an audit or a customer's security questionnaire forces the question.

FAQ

Do I need SOC 2 certification before my first enterprise customer, or can I get it during the sales process? Many companies start the SOC 2 process once serious enterprise deals are in the pipeline, since the audit period (typically 3-12 months for a Type II report) means starting early avoids it becoming a deal blocker later — starting reactively after a deal stalls on it is the more common and more painful path.

If my company isn't in the EU, can I ignore GDPR? No — GDPR applies based on whether you process personal data of individuals located in the EU/UK, not based on your company's location, so any EU end users interacting with your agent bring GDPR requirements regardless of where you're incorporated.

Can one AI agent be subject to SOC 2, HIPAA, and GDPR all at the same time? Yes — a healthcare SaaS company serving EU patients, for example, would need to satisfy all three simultaneously, since they govern different things (general security posture, health data specifically, and EU personal data specifically) rather than being mutually exclusive.

Is a compliance framework something the AI vendor handles, or something we're still responsible for? Both, contractually defined — using a compliant vendor doesn't automatically make your own use of their product compliant; responsibility is typically shared and needs to be spelled out in the vendor agreement (BAAs for HIPAA, DPAs for GDPR).

Accelate maps a client's actual data flow to the frameworks it triggers before writing a line of agent code, because "we're generally compliant" isn't an answer that survives a real security questionnaire.