Deploying AI agents in finance, healthcare, or any regulated sector isn’t just a technical problem — it’s a compliance one. Here’s what the major frameworks actually demand from your AI infrastructure.
SOC 2, HIPAA, GDPR, and most other compliance frameworks were written in an era when software systems had clear, predictable boundaries. A system accessed data through defined APIs, executed known operations, and logged what it did in structured audit trails. Compliance teams knew how to evaluate these systems because the systems behaved consistently.
AI agents break every one of these assumptions. They access data dynamically, based on reasoning rather than hardcoded logic. They execute operations that weren’t anticipated at design time. And their behavior is emergent — it depends on the combination of model, prompt, context, and tool availability in ways that are genuinely difficult to predict in advance.
This doesn’t mean regulated industries can’t use AI agents. It means they need to think carefully about the infrastructure requirements that compliance actually imposes — and build accordingly.
SOC 2 is a framework for evaluating the security, availability, processing integrity, confidentiality, and privacy of a service organization’s systems. For AI agents, the most critical SOC 2 requirements translate into specific infrastructure demands.
Access controls. SOC 2 requires that access to systems and data be limited to authorized users and processes. For AI agents, this means every tool call must be subject to access controls that can be audited. It’s not enough to control who can start an AI session — you need to control what the agent can access at the tool call level, and prove it.
Audit trails. SOC 2 requires complete, tamper-evident logs of who accessed what data, when, and how. For AI agents, this means logging not just the query result but the full context: which agent made the call, what the LLM’s reasoning was, what parameters were passed, and what was returned. Partial logging doesn’t satisfy auditors.
Encryption and data handling. SOC 2 requires that data be encrypted in transit and at rest. For AI agents that query multiple systems and potentially cache results, this requirement extends to every intermediate state in the execution pipeline — including the agent’s working memory.
HIPAA’s Privacy and Security Rules impose strict requirements on systems that handle Protected Health Information (PHI). The most important for AI agents are the minimum necessary standard, the requirement for Business Associate Agreements, and access logging.
The minimum necessary standard is particularly challenging for AI agents. It requires that access to PHI be limited to the minimum amount necessary to accomplish a given purpose. For a human clinician, this is a judgment call they make consciously. For an AI agent, “minimum necessary” must be enforced by the infrastructure — which means the runtime layer must be able to scope data access to the specific query at hand, not just to a broad role.
Any vendor whose infrastructure processes PHI on your behalf must sign a Business Associate Agreement (BAA). If you’re using an AI runtime that touches PHI, that vendor must be willing to sign a BAA and must be able to demonstrate the technical controls that back it up.
GDPR’s requirements are centered on data subject rights and lawfulness of processing. For AI agents, the most operationally demanding requirements are the right of access, the right to erasure, and the requirement for lawful basis of processing.
When an AI agent queries personal data, that processing must have a lawful basis — consent, legitimate interest, contractual necessity, or legal obligation. This means your governance infrastructure needs to know why an agent is accessing personal data, not just that it is. Intent-based governance isn’t just a security feature for GDPR purposes — it’s a legal requirement.
The right to erasure (“right to be forgotten”) also creates a challenge for AI systems with persistent memory: if a user’s data is deleted from source systems, you must be able to ensure it’s also purged from any AI memory or cache layers that may have retained it.
The organizations that handle regulated AI deployments most successfully share one characteristic: they treat compliance as an infrastructure requirement from day one, not an audit exercise at the end. This means choosing runtime infrastructure that provides granular logging by default, enforces access controls at the tool call level, supports BAA agreements (for HIPAA), and can demonstrate data lineage for any AI-generated output.
The alternative — building an AI system first and trying to make it compliant later — is possible, but expensive and slow. Compliance retrofits are one of the most common reasons enterprise AI projects get stuck between pilot and production. The right moment to solve this is before you’re sitting across from an auditor.
