AI agents in regulated industries: HIPAA / MAS / DPDP guardrails

Shipping LLM agents into regulated environments — healthcare under HIPAA, financial services under MAS or FCA, any industry under DPDP or GDPR — is qualitatively different from shipping them into unregulated environments. The “move fast and iterate” pattern that works for consumer or B2B SaaS agents fails the first regulator audit. The remediation cost is high.

The good news: the architectural patterns that satisfy regulators in 2026 are knowable. Most of them are not specific to AI; they are specific to systems that touch regulated data. Layering them onto an LLM agent is engineering, not invention.

This post is the practical guardrails playbook.

The common ground across regimes

HIPAA, MAS TRMG, FCA, DPDP, and GDPR-derived regimes share four expectations for any system touching regulated data:

1. Data residency. Regulated data lives in specified jurisdictions. Cross-border flows require documented legal basis.
2. Audit logging. Every access to regulated data is logged with actor, action, resource, timestamp. Logs are retained per regime requirements (often 3–7 years) in immutable storage.
3. Access control. Role-based access with periodic review. MFA on production access. Justified-access logging for sensitive data classes.
4. Incident response. Documented breach detection, classification, notification timelines.

These four are necessary regardless of whether the system uses AI. The agent-specific guardrails layer on top of these.

The agent-specific guardrails

Six controls we ship as standard for agents in regulated industries:

1. PHI / PII filtering at the LLM boundary.

Regulated data does not leave the BAA / DPA boundary. For LLM calls, this means:

• The LLM provider must be under BAA (HIPAA) / DPA (GDPR/DPDP) / equivalent contractual cover.
• Inputs to the LLM are filtered for any data classes not covered by the contractual scope.
• Outputs from the LLM are scanned before being persisted or actioned.

For HIPAA, our default is Anthropic via AWS Bedrock (BAA covered) or Anthropic direct with BAA. For MAS and DPDP, we use the same providers with the appropriate regional deployment.

2. Deterministic decision boundary for regulated outcomes.

The agent can recommend, but the binding decision must be deterministic and traceable. “The LLM decided to deny coverage” is not an answer a regulator will accept. The agent’s output is an input to a deterministic decision function; the function (rule-based, signed off by counsel) makes the binding decision.

This pattern preserves the agent’s value (synthesising context, drafting recommendations) while keeping the decision auditable.

3. Per-call observability with content traceability.

Every LLM call is traced with:

• Input (or hash of input for high-sensitivity).
• Prompt version (every prompt is versioned and immutable).
• Model + parameters.
• Output (or hash of output).
• Downstream actions taken.
• Timestamp + actor.

Traces land in immutable storage with the same retention as other audit data. Regulators asking “what did the system do on March 14 at 2:15pm?” get an answer.

4. Eval harness with regulated-domain test cases.

The eval harness includes test cases representing regulatory edge cases: PHI in unexpected places, customer requests for deletion, decisions adjacent to protected categories. Every prompt change runs through the harness; regressions block deployment.

This is not consumer-grade evaluation. It is compliance-grade evaluation. The investment is meaningful and non-optional.

5. Human-in-the-loop for high-stakes decisions.

Some decisions in regulated environments must have human review:

• Healthcare: any decision affecting clinical care.
• Financial services: any decision involving customer money or credit.
• Legal: any decision affecting filings or representations.
• Insurance: any decision on coverage or claims.

The agent drafts. The human approves. The audit trail captures both the agent’s recommendation and the human’s decision.

6. Per-tenant data isolation enforced at the prompt layer.

The agent must not include cross-tenant data in prompts. This is a stronger guarantee than application-layer isolation; it requires the prompt-construction code to be auditable for tenant boundary correctness. We use typed prompt-builders that enforce this at compile time.

Regime-specific overlays

Specific overlays per regulatory regime:

HIPAA. Anthropic via AWS Bedrock (or direct with BAA), AWS for everything else (HIPAA-eligible services only), no PHI in CloudWatch logs without redaction, audit log retention 6 years.

MAS TRMG (Singapore). AWS ap-southeast-1 deployment, MAS-aligned outsourcing contracts with all sub-processors, RTO/RPO documented and tested per critical-system designation, audit log retention 5+ years.

DPDP (India). Data principal rights workflows (access, correction, deletion), consent capture and storage, breach notification automation aligned to DPDP timelines, age verification for under-18 users.

FCA (UK). Operational resilience requirements, third-party-risk register, incident response within FCA timelines, customer outcome reporting.

GDPR / EU. Standard SCCs for any third-country transfers, Article 30 record of processing activities, DPIA for high-risk processing.

These overlays are additive to the core six guardrails. They are not optional in their respective jurisdictions.

Common architectural mistakes

Five we see most often:

1. PHI in Sentry / Bugsnag stack traces without filtering.
2. LLM calls to providers without BAA / DPA cover.
3. Audit logs in mutable storage (deletable by application code).
4. Prompts assembled with cross-tenant data accidentally included.
5. Eval harness that doesn’t include compliance edge cases.

All five are preventable in the original architecture. All five are expensive to remediate after deployment.

What we ship

For agent engagements in regulated industries, our default deliverables include:

• The six guardrails above, in code.
• The regime-specific overlays for the client’s jurisdiction.
• Documented compliance evidence kit aligned to the regulatory framework.
• Eval harness with compliance edge cases.
• Operational runbooks for incident response and regulatory inquiry.

We work with the client’s regulatory counsel on the policy and contractual layer. The architecture is designed to make their job tractable.

---

Read more: /agents/ · /sectors/healthcare · /sectors/financial-services · /sectors/legal