The default narrative is that regulated industries cannot ship AI. Healthcare is too risky. Financial services is too compliance-heavy. Supplements and wellness sit in a gray zone where one bad answer triggers an FTC review. So the regulated companies wait, watch the fast-moving consumer-tech world from a distance, and convince themselves AI is for someone else.

This is wrong. Regulated industries can ship AI. They just need to ship it differently. The companies doing it well are running customer support agents, internal assistants, document processing pipelines, and even patient-facing tools, with audit logs, guardrails, and human oversight baked in. The pattern is not "do not use AI." It is "use AI with the controls your industry actually requires."

The Three Things Regulated AI Has to Do Differently

1. Treat Every Interaction as Auditable

In healthcare and finance, regulators want to know what happened, when, why, and who saw what. AI interactions are no exception. From day one, every model call needs to log:

  • The full input (with PII redacted at write time)
  • The retrieval context the model saw
  • The full output
  • Any guardrail verdicts
  • Who saw the response, when, and what they did with it

This is the same AI observability layer a non-regulated company should have, applied with discipline. The difference is that the regulated company actually has to produce these logs on demand for an audit. Half-built observability gets caught the first time the auditor asks for the December 4th interaction at 3:17pm.

2. Build Guardrails for Domain-Specific Failures, Not Just Generic Ones

Generic content moderation catches profanity and obvious harm. Regulated industries have a different failure surface:

  • A healthcare chatbot giving medical advice it should not be giving
  • A financial assistant making a specific recommendation that triggers fiduciary duty
  • A supplement company chatbot making health claims that violate FTC rules
  • A bank's bot revealing account information across customer accounts

The fix is domain-specific pre-LLM classifiers and post-LLM judges. A pre-LLM classifier intercepts inputs that should never reach the model in the first place. A post-LLM judge reviews every response against a domain-specific rubric before it reaches the user. The right combination of both is what makes a regulated AI deployment shippable.

3. PII Redaction at the Earliest Possible Point

HIPAA, GDPR, and the financial regulators are unforgiving about PII handling. The pattern that works: redact PII before the LLM sees it, before embeddings are generated, before anything hits long-term storage. The redacted segments are kept separately with stricter access controls, only re-joined at the moment of presentation to an authorized user.

The wrong pattern: send raw PHI to the model and trust the model not to leak it. Even with a strong vendor agreement, sending unnecessary PII is operational risk that compounds over thousands of interactions.

What This Architecture Looks Like in Practice

A regulated AI deployment has six layers that a consumer one does not need:

  1. The redaction layer. Inbound text and audio are scanned for PII categories specific to the regulation (PHI for HIPAA, NPI for financial). Detected PII is replaced with tokens, stored separately, never sent to the model.
  2. The pre-LLM classifier. Inputs in restricted categories (medical advice requests, fiduciary recommendations, off-policy queries) get routed to a human or to a canned safe response.
  3. The model layer. The actual LLM call, with the redacted input and the appropriate retrieval context. Hosted in an environment that satisfies data residency and BAA requirements (your VPC, the vendor's compliant tier).
  4. The post-LLM judge. Every response evaluated against the domain rubric before reaching the user. Off-policy responses are rewritten, suppressed, or escalated.
  5. The presentation layer. PII tokens are re-resolved to the original values only for the authorized end-user. Other readers see redacted text.
  6. The audit log. Everything is captured, time-stamped, attributed to a user, and held in tamper-evident storage for the retention period the regulation requires.

This sounds heavy. In practice, after the first deployment, each layer is reusable across new use cases. The second AI feature in the same regulated company takes a quarter of the time the first one did.

Where We See Regulated AI Shipping Right Now

The use cases that are actually live in production at regulated companies:

  • Internal assistants for non-customer-facing employee tasks (policy lookups, drafting internal docs, summarizing internal calls). Lowest regulatory surface area, highest immediate productivity gain.
  • Customer support agents for billing, account status, and policy questions. The agent never gives medical or financial advice; it deflects to humans for those. Deflection rates of 30 to 60% are common.
  • Document processing. Extracting structured fields from intake forms, lab reports, lease documents, bank statements, insurance claims. The model parses; humans verify before any action.
  • Coaching and review. Recording call transcripts, surfacing patterns for compliance review, flagging risky language for follow-up. No customer-facing output, all internal.
  • Personalized communications. Drafting customer outreach grounded in customer data and templated against compliance-approved language. Humans approve before sending.

The companies winning here are not pushing the regulatory envelope. They are picking lower-risk use cases first, building the compliance infrastructure on those, and then expanding into higher-stakes deployments with the same architecture.

The Failure Modes to Avoid

Trying to Use a Public AI Tool Internally

Sending PHI or PII to a consumer AI tool with no enterprise agreement is a HIPAA violation waiting to happen, even if no harm occurs. The Enterprise tier of major providers with a signed BAA is the floor. Anything less puts the regulated company at uncapped liability.

Treating Compliance as a Final Review

If compliance only sees the AI deployment when you ask for sign-off two days before launch, you have already lost. The right pattern is compliance embedded from the design phase, with explicit sign-off at each architectural layer. The deployment is slower but actually ships.

Skipping the Human-in-the-Loop Phase

Every regulated AI deployment should start with humans approving outputs. Move to fully automated only when the audit data justifies it. The teams that go straight to auto-send create the conditions for the first compliance incident.

Underestimating Vendor Dependency

If your regulated AI deployment depends on a specific model from a specific vendor, you have inherited that vendor's compliance posture. Make sure the vendor's BAA, data residency, and audit cooperation match your obligations. Cheaper vendors often have weaker contractual protections.

How to Start

  1. Pick one internal use case. Policy lookups, document summarization, internal Q&A. Lowest stakes, fastest learning.
  2. Build the six-layer architecture for that one use case. Even if it feels like overkill, you are building reusable infrastructure.
  3. Run it with full audit logging for 60 days. Have compliance review the logs at day 30 and day 60.
  4. Use what you learned to scope the next use case. The next one will go three times faster.
  5. Move to customer-facing only after at least one internal use case is stable.

Frequently Asked Questions

Can we use Claude or ChatGPT in healthcare?

Yes, with the right tier and contract. Both Anthropic and OpenAI have HIPAA-eligible offerings on their enterprise tiers with signed BAAs. The contract structure matters more than the model.

What about financial services regulations?

Financial services AI deployments need to consider SEC, FINRA, and state-level regulators. The core architecture (audit logs, guardrails, PII redaction) applies. Specific use cases that touch fiduciary advice or material non-public information have additional restrictions and usually require a designated supervisor for compliance.

How do we handle PII redaction at scale?

Several specialized services handle this (Presidio, Tonic, in-house solutions). The redaction layer runs upstream of the model. For audio inputs, transcription happens first, then redaction on the transcript, then model interaction on the redacted text.

What about state-level regulations like CCPA?

The architecture handles them as a side effect. CCPA's right-to-deletion, right-to-portability, and disclosure requirements are easier to meet when you have full audit logs and structured data handling.

Is this overkill for a small regulated company?

The architecture scales down. A small healthcare practice still needs the six layers but can run them on lighter infrastructure. The discipline matters more than the scale of the deployment.

Regulated industries can ship AI. The companies that wait until "the rules are clearer" will lose three years of compounding to companies that ship now with the right architecture. Talk to us if you want a pressure-test on your deployment plan.