The HIPAA Playbook for AI & Accounting APIs: Zero Data Retention Architecture

Healthcare B2B SaaS companies are sprinting to build AI agents that can read and write to accounting systems. The financial incentives are impossible to ignore. Revenue Cycle Management (RCM) platforms, medical billing software, and practice management tools are all racing to deploy autonomous agents that can reconcile claims, generate invoices, and sync payment data directly to the general ledger.

If you are building a healthcare SaaS product that uses AI agents to interact with accounting systems like QuickBooks, Xero, or Oracle NetSuite, you face a highly specific engineering problem: giving a non-deterministic Large Language Model (LLM) write access to a double-entry general ledger without storing Protected Health Information (PHI) in your integration layer.

If you are shipping these AI agents for a healthcare customer, the safest architecture is zero data retention: a real-time pass-through between your agent and the accounting API, with no caching of payloads, no PHI sitting in middleware, and no logs storing line items that contain patient identifiers. Anything else expands your HIPAA blast radius and forces you to sign more Business Associate Agreements (BAAs) than you can defend in an audit.

Doing this in a healthcare context is an architectural minefield. When you connect your SaaS application to a hospital's accounting instance, the payloads you process will inevitably contain patient names, service dates, and treatment codes embedded in invoice line items.

This playbook walks senior PMs and engineering leaders through the architectural choices that actually matter when an LLM is calling a double-entry general ledger inside a healthcare workflow, building on our core principles for HIPAA-compliant AI agent integrations.

The high stakes of AI agents in healthcare accounting

The market pressure to ship AI features is genuine, not hype. Grand View Research values the global artificial intelligence in healthcare market at USD 36.67 billion in 2025, projecting it to reach USD 505.59 billion by 2033, growing at a massive 38.90% CAGR. Customers expect your software to automate tedious financial workflows, and AI agents are the obvious solution to reconcile claims, draft invoices, and sync payments without a human in the middle.

But the penalty for getting this wrong is brutal. According to IBM's 2025 Cost of a Data Breach Report, healthcare remains the most expensive industry at $7.42 million per breach globally - making it the most expensive industry for data breaches for 15 consecutive years. If you are a US-based SaaS, the math gets worse. The average cost of a U.S. breach hit $10.22 million, driven by regulatory fines and slower detection times.

Healthcare breaches also take the longest to identify and contain, averaging 279 days, nearly 6 weeks longer than the global average of 241 days. The financial damage is staggering, and the regulatory fallout from the Office for Civil Rights (OCR) can easily bankrupt a mid-stage SaaS company.

And the AI layer itself is now a primary attack surface. Unauthorized AI tools were involved in 20% of breaches - nearly all in companies without proper access controls or governance. If your agent stores tool-call payloads, your integration layer becomes a discoverable secondary copy of PHI that auditors, plaintiffs, and ransomware operators will all eventually find.

Your AI agents need to access financial data to do their jobs. They need to read Invoices, map them to Payments, and update Accounts. But the infrastructure sitting between your AI agent and the third-party accounting API must be designed with extreme paranoia. AI agent integrations in healthcare are not a feature decision, they are a compliance architecture decision. Treat them like one.

Why your integration layer is a HIPAA minefield

HIPAA's reach extends to anyone who touches PHI on behalf of a covered entity. That includes the unified API platform or embedded iPaaS sitting between your AI agent and the accounting system. HIPAA § 164.312 requires comprehensive audit trails that shadow AI makes unachievable.

If you pull data from an Electronic Health Record (EHR) system, you expect PHI. When you pull data from an accounting system, engineering teams often assume the data is purely financial. This is a dangerous assumption. The assumption that accounting data is "just financial" falls apart the second you connect to a real customer.

In healthcare, financial data and clinical data are deeply intertwined. Payloads from QuickBooks, Xero, or NetSuite in a healthcare context routinely contain:

• Patient names in Invoice.customer_name or Contact.display_name.
• Service descriptions in line items (e.g., "MRI Lumbar Spine - John Smith - 02/14").
• Specific CPT/HCPCS codes in Item.sku fields.
• Diagnosis hints embedded in memo fields and PO notes.
• Insurer details that, combined with claim numbers, become identifiable.

Under the Health Insurance Portability and Accountability Act (HIPAA), any combination of this data constitutes PHI. Any third-party vendor that handles PHI on behalf of a covered entity must sign a Business Associate Agreement (BAA). A BAA is a legally binding contract that governs how a business associate can access, use, and safeguard PHI.

The moment your integration middleware stores, caches, logs, or persists these accounting payloads, three things become true at once: your integration provider is handling PHI and must sign a BAA, your incident response scope expands to include integration logs, and any sub-processor your integration vendor uses (database, search cluster, caching layer) must also sign a BAA. More importantly, you have just expanded your attack surface. You now have a secondary database sitting outside your primary infrastructure that contains highly sensitive patient data.

This is where the "unified API" category gets dangerous. Many platforms quietly sync customer data into their own warehouses to power features like search, dedupe, and webhook fan-out. That design choice is fine for sales-tools telemetry. It is an unacceptable risk for a healthcare SaaS shipping an AI agent over an accounting ledger. To avoid this, you need to rethink how you connect to third-party APIs. You need to stop storing data in transit.

For a deeper walk-through of BAA scope and audit traps, see our HIPAA-compliant integrations guide.

Sync-and-cache vs. zero data retention architecture

There are two dominant patterns for unified APIs in 2026. The difference looks subtle on a product page and is enormous in a HIPAA audit. Most Unified API platforms and embedded iPaaS solutions were not built for healthcare. They were built for speed and convenience, relying heavily on a "sync-and-cache" architecture.

The Sync-and-Cache Anti-Pattern

Legacy unified APIs solve the problem of API normalization by brute force. They run background workers that constantly poll the third-party API (e.g., QuickBooks), pull down all the records, normalize them into a standard schema, and store them in their own managed databases (usually a massive multi-tenant Postgres cluster).

When your AI agent requests a list of invoices, it isn't talking to QuickBooks. It is querying the unified API's database.

Pros: fast reads, easier search, simpler webhook semantics.

Cons: This architecture inherently stores third-party data. It means PHI lives at rest on their servers, often in a different region than your customer's, and every record is a regulated asset. This forces you into complex BAA negotiations, requires strict data residency controls, and massively expands the blast radius of a potential breach. If the integration provider gets hacked, your customers' PHI is exposed.

The Zero Data Retention Pass-Through Architecture

Truto takes a radically different approach. Truto acts as a real-time pass-through proxy. It does not store customer payloads.

A request hits the platform, gets mapped to the underlying vendor's native API, the response comes back, gets normalized into a common schema, and is returned to your caller. The data is never written to disk. The only state the platform keeps is what is operationally required: integration configuration, OAuth credentials, and audit metadata about that a call happened - not what was in it.

flowchart LR
    A[AI Agent / Your App] -->|Unified request| B[Pass-through<br>Unified API]
    B -->|Mapped native call| C[QuickBooks /<br>Xero / NetSuite]
    C -->|Native response| B
    B -->|Normalized response| A
    B -.->|No payload<br>persistence| D[(No cache /<br>No data at rest)]

For HIPAA, the zero-retention model collapses your compliance surface area dramatically:

There is a real trade-off here, and we should be honest about it. Pass-through architectures push more load to the upstream API, which means rate limits hit faster and bulk operations are slower than reading from a local cache. For most healthcare workflows - which are event-driven and not analytics-heavy - that trade is worth it. If your use case is batch financial analytics across millions of historical transactions, a regulated data warehouse you control is the better fit. For agent-driven, transactional workflows, zero retention wins.

More on the trade-offs in real-time pass-through vs sync-and-cache.

Choosing an integration platform for enterprise compliance: the decision checklist

When enterprise buyers ask "which integration tools are best for SOC 2 and HIPAA compliance?", the answer depends less on which certifications a vendor holds and more on how their architecture handles your data. A SOC 2 Type II badge on a marketing page tells you the vendor passed an audit. It does not tell you whether your customers' PHI sits in their database for 90 days.

Three architectural categories dominate the integration platform market in 2026. Each carries a fundamentally different compliance profile.

Architecture comparison at a glance

Compliance risk quick-reference

One-line recommendations by buyer type

Healthcare SaaS (HIPAA-regulated, AI agents touching PHI): Default to a zero-storage pass-through. The compliance cost of caching PHI in a third-party platform will exceed the engineering cost of handling rate limits locally. Every cached payload is a breach notification you have to plan for.

Fintech / financial services (SOC 2, PCI, state privacy laws): Zero-storage is the fastest path through enterprise security reviews. If you also need batch analytics, pair it with a data warehouse inside your own infrastructure where you control encryption keys and retention policies.

Government / public sector (FedRAMP, CJIS, data sovereignty mandates): Self-hosted iPaaS in your own VPC is often the only option that satisfies data sovereignty requirements. If the mandate is that no data leaves the network boundary, cloud-hosted anything - including zero-storage proxies - may be disqualified. Budget for the platform engineering team required to operate it.

Internal ops / non-regulated workloads (CRM sync, marketing automation): Sync-and-cache is fine. The convenience of fast reads and pre-built search outweighs the compliance overhead when there is no regulated data in play. Just do not reuse this architecture for regulated workflows later without re-evaluating.

Architecting a pass-through unified accounting API

A pass-through unified accounting API has three jobs: authenticate to the upstream system, transform requests and responses between a common schema and the vendor's native format, and do all of that without persisting the payload. To make this work without writing integration-specific code for every accounting provider, you need a generic execution engine driven by declarative configurations. Here is how the moving parts fit together.

1. Declarative integration definitions, not bespoke code

The core trick is to treat each integration as configuration, not code. Truto handles 100+ third-party integrations without a single line of integration-specific code in its database or runtime logic. There is no if (provider === 'quickbooks') in the codebase.

Integration logic - base URLs, auth schemes, resource paths, pagination strategies - lives in JSON. Field mappings between the unified schema and the vendor's native fields live as JSONata expressions. The runtime is a generic engine that reads this configuration and executes it.

Why this matters for HIPAA: the smaller your runtime surface, the smaller your security audit. When integration behavior is data rather than code, breaking changes from QuickBooks or Xero do not require redeploying a service that has access to PHI. They are config updates.

{
  "resource": "accounting/invoices",
  "native": {
    "GET": "/v3/company/{{realmId}}/invoice",
    "POST": "/v3/company/{{realmId}}/invoice"
  },
  "mapping": {
    "request": "{ 'CustomerRef': { 'value': contact_id }, 'Line': line_items.{ 'Amount': amount, 'DetailType': 'SalesItemLineDetail' } }",
    "response": "{ 'id': Id, 'contact_id': CustomerRef.value, 'total_amount': TotalAmt, 'currency': CurrencyRef.value }"
  }
}

The response transformation runs entirely in memory on the request thread. Nothing is staged to disk. The unified record is built, returned, and garbage-collected.

2. A common accounting schema as the AI agent's contract

LLMs are bad at remembering that QuickBooks calls it CustomerRef while Xero calls it ContactID. Give them one schema. The Truto Unified Accounting API provides a standardized data model to interact with diverse financial platforms. It abstracts away provider-specific nuances, allowing programmatic systems and AI agents to manage the general ledger through a single schema.

When an AI agent wants to create an invoice, it sends a standardized POST request to the platform:

{
  "contact_id": "12345",
  "line_items": [
    {
      "description": "Consultation - Code 99213",
      "amount": 150.00,
      "account_id": "67890"
    }
  ]
}

The agent learns one mental model; the platform handles the dialect translation. This removes a real source of hallucination. When an agent has 50 candidate field names per provider, it guesses. When it has one consistent schema and a well-typed tool definition, it stops inventing endpoints.

3. Custom field passthrough

Reality check: healthcare accounting is full of custom fields. Patient MRN tagged on an invoice. Encounter ID on a journal entry. A pure standardized schema will lose these. The pragmatic pattern is to expose a custom_fields object on every unified resource that round-trips raw provider keys, so your agent can read and write them when needed without forcing a schema change.

For example, mapping a unified contact to a NetSuite customer with custom context might look like this in the configuration:

models:
  accounting/contacts:
    netsuite:
      request_mapping: |
        {
          "companyName": name,
          "email": email,
          "phone": phone,
          "subsidiary": { "id": context.subsidiary_id }
        }

The brutal reality of ERP integrations: NetSuite and QuickBooks

Building integrations in-house is painful—which is why we often compare using a platform to buying insurance for your integrations. Abstracting ERPs behind a unified API is an engineering nightmare that requires deep domain expertise.

Take Oracle NetSuite. It is a massive, highly customizable ERP. To interact with it reliably, you cannot just use standard REST endpoints. You often have to rely on SuiteQL (NetSuite's SQL-like query language) to fetch relational data efficiently. For certain tax rate calculations or legacy custom fields, you might even have to fall back to SOAP endpoints.

QuickBooks Online presents its own challenges. Its API is notorious for strict rate limits, complex OAuth refresh requirements, and bizarre pagination behaviors.

If you build this in-house, your engineering team will spend months writing custom handlers, dealing with undocumented edge cases, and maintaining brittle code paths.

By using a declarative unified API, you offload this complexity. The platform handles the SuiteQL query construction, the SOAP fallbacks, and the pagination abstraction automatically, all while maintaining the zero data retention guarantee. Learn more about connecting to complex ERPs in our guide on Zero Data Retention AI Agent Architecture: Connecting to NetSuite & SAP Without Caching.

Handling rate limits and auth securely

A common question from engineering leaders is: "If you don't cache data, how do you handle rate limits?"

It is a valid concern. If your AI agent aggressively polls an API, it will hit rate limits. Many sync-and-cache platforms hide this by serving stale data from their database. Two subsystems quietly leak PHI in most integration platforms: rate-limit retry queues and OAuth token refresh logs. Both need to be designed defensively.

Rate limits: pass 429s through, do not buffer payloads

The naive design is to catch upstream HTTP 429 responses, queue the original request, and retry with exponential backoff. That queue is a PHI store. Even if it lives in memory for thirty seconds, it is a regulated asset.

Truto does not magically absorb rate limits, nor do we cache requests to retry them later (which would require storing the payload). When an upstream API returns an HTTP 429 (Too Many Requests), Truto passes that error directly to the caller. We normalize the upstream rate limit information into standardized headers per the IETF specification:

• ratelimit-limit
• ratelimit-remaining
• ratelimit-reset

HTTP/1.1 429 Too Many Requests
ratelimit-limit: 500
ratelimit-remaining: 0
ratelimit-reset: 42

The calling application (your AI agent's execution framework) is responsible for reading these headers and deciding whether to wait, route to a different account, or surface a clean error to the user. Applying exponential backoff locally is the only architecturally sound way to handle rate limits without storing sensitive data in a middleware queue.

Secure OAuth token management

Authentication is another critical vector. OAuth tokens must be refreshed proactively to ensure API calls don't fail in production. OAuth refresh logic needs to run before every call without dragging PHI into telemetry.

Truto manages the entire integrated account lifecycle. The pattern is:

1. Cache the access token, refresh token, and expires_at per connected account.
2. Before each call, check expiry with a small buffer (e.g., 30 seconds).
3. If close to expiry, refresh and update expires_at.
4. Schedule a proactive refresh shortly before expiry to avoid cold-path latency (60 - 180 seconds before they expire).
5. On refresh failure, mark the account needs_reauth and fire a webhook to your app.

Critically, token management is completely decoupled from payload processing. Access tokens are stored securely, but the actual HTTP request bodies (which contain the PHI) are never logged or stored during the auth lifecycle. Log only the fact of a refresh - account ID, timestamp, success or failure code. Never log request/response bodies, even on error. A surprising number of breach reports trace back to debug logs that captured what should have been an opaque payload.

Handling webhooks without storing payloads

Accounting systems frequently send webhooks when records change (e.g., an invoice is paid). Processing webhooks securely is a major challenge for zero data retention architectures.

When a third-party webhook hits the platform, the system must verify the cryptographic signature to ensure the payload is legitimate. The platform supports HMAC, JWT, Basic Auth, and Bearer token verification formats.

This verification happens entirely in memory. The platform computes the signature over the incoming payload and compares it using constant-time algorithms to prevent timing attacks.

Once verified, the platform uses JSONata expressions to map the raw webhook payload into a unified event (e.g., mapping a QuickBooks Invoice.Updated event to a unified record:updated event for the accounting/invoices resource).

If the webhook payload only contains an ID, the platform can execute a real-time fetch to the third-party API to enrich the payload with the full unified data model, and then immediately stream that event to your application's webhook endpoint. The payload is held in memory just long enough to be transformed and delivered.

Deploying MCP servers for healthcare AI agents

LLMs are powerful, but they hallucinate. If you give an LLM raw API access without strict boundaries, it will invent field names, guess at pagination structures, and inevitably fail to construct valid JSON payloads for complex ERPs.

The solution is the Model Context Protocol (MCP). MCP is an open standard that allows developers to expose specific, well-defined tools to LLMs. For healthcare accounting workflows, MCP servers are where your agent meets your integration layer, which means they inherit all of the HIPAA constraints above and add a few of their own.

What goes wrong with naive MCP setups

Most AI tool platforms ship MCP servers that record full tool-call traces by default - inputs, outputs, intermediate reasoning. That telemetry is a goldmine for debugging. It is also a PHI cache nobody planned for. If you cannot disable retention on tool inputs and outputs, you cannot use that platform in a HIPAA workflow without a much wider BAA.

What a HIPAA-safe MCP architecture looks like

Instead of asking an AI agent to figure out the QuickBooks API, you provide it with an MCP tool called create_unified_invoice. The LLM only needs to understand the standardized, unified schema.

sequenceDiagram
    participant U as Healthcare User
    participant A as AI Agent (LLM)
    participant M as MCP Server
    participant P as Pass-through<br>Unified API
    participant Q as QuickBooks / Xero
    U->>A: "Reconcile last week's payments"
    A->>M: tool_call(list_payments)
    M->>P: GET /unified/accounting/payments
    P->>Q: Native API call
    Q-->>P: Native response
    P-->>M: Normalized response
    M-->>A: Tool result (in-memory only)
    A-->>U: Reconciliation summary
    Note over M,P: No payload<br>persistence at any layer

The Workflow & Design Rules:

1. User Prompt: A user asks the AI agent to "Generate an invoice for John Doe's consultation today and sync it to QuickBooks."
2. Tool Selection (Generated from Unified Schema): The LLM identifies that it needs to use the create_unified_invoice MCP tool. Tool definitions are generated from the unified schema, not hand-written per provider. This eliminates hallucinations.
3. Payload Generation: The LLM generates a JSON payload matching the unified accounting schema.
4. End-User Scoped Execution: The MCP server forwards this payload to the pass-through proxy. Each MCP session uses the connected user's tokens so all upstream audit logs attribute writes to a real person.
5. Transformation: The platform transforms the unified payload into QuickBooks' native format in memory.
6. API Call: The platform executes the request to QuickBooks.
7. Response & No Persistence: QuickBooks returns a success response, which is mapped back to the unified schema and returned to the agent. Tool-call telemetry records only the tool name, account ID, and outcome - never the payload.

Because the proxy acts as the execution engine, the LLM never has to deal with QuickBooks' OAuth tokens, rate limit variations, or specific field naming conventions. And because it uses a zero data retention architecture, the PHI contained in the invoice never touches a middleware database.

For patterns specific to ERP-grade workflows, see connecting AI agents to Xero and QuickBooks via MCP.

Model provider BAAs: what to require and why

The moment your AI agent sends a prompt containing PHI to an external LLM, that model provider becomes a business associate. HIPAA does not care whether the model is "just doing inference" or whether the provider claims not to train on your data. If PHI transits their infrastructure, they need a signed BAA before you can send a single token.

Most major providers offer BAAs, but with strict preconditions:

• OpenAI signs BAAs for API and ChatGPT for Healthcare customers. Coverage is endpoint-specific, and some features or modalities may be out of scope. By default, OpenAI may retain API inputs and outputs for up to 30 days to identify abuse, after which they are removed unless legally required. The BAA path is available to Enterprise customers and API users who have configured zero data retention and opted out of model training; standard ChatGPT tiers do not qualify.
• Anthropic signs BAAs for Claude API customers, typically routed through cloud providers like AWS Bedrock or Google Vertex where the parent cloud's BAA also applies.
• AWS Bedrock and Azure OpenAI rely on the parent cloud's BAA and require you to enable specific data-handling settings (no prompt logging, region pinning, customer-managed keys). On Azure OpenAI standard pay-as-you-go, abuse monitoring is enabled by default with data retained up to 30 days; ZDR is only available for managed customers on an Enterprise Agreement.
• Google Vertex AI offers a BAA for Gemini models under Google Cloud's HIPAA-eligible services list.

What to actually require in the BAA and its data processing addendum:

• Zero training on customer data. Explicit contractual prohibition on using prompts, completions, embeddings, or fine-tuning outputs to train, retrain, or evaluate models.
• Zero prompt retention beyond the request lifecycle. No 30-day abuse-monitoring logs by default, or if unavoidable, a documented exception with encrypted storage, named sub-processors, and no human review.
• Named sub-processors with pass-through BAA obligations. Every downstream cloud provider, moderation service, or logging system must be in scope.
• Fast breach notification. HIPAA's floor is 60 days from discovery, but you want a much shorter contractual window because your own notification clock starts before you learn about their incident.
• Region and data residency guarantees. Providers like OpenAI now offer in-region GPU inference and data residency at rest across multiple regions; require inference to run in a specified region with no silent failover.
• Right to audit. Annual security review rights, SOC 2 Type II reports, and penetration test summaries on request.
• Verifiable configuration. The ability to programmatically confirm that ZDR or equivalent controls are enabled on the account or project you are using, not just promised in an email.

When to avoid sending ePHI to an external LLM

Even with a BAA in place, the safest ePHI is the ePHI that never leaves your perimeter. There are workflows where sending patient data to an external model is the right call, and there are workflows where it is a compliance trap. A short decision framework:

Send to a BAA-covered external LLM when:

• The task requires frontier reasoning (complex multi-step reconciliation, ambiguous invoice matching) that smaller local models cannot handle reliably.
• The data can be minimized to what the model actually needs (line-item amounts and codes, not full patient records).
• Your BAA is current, ZDR is verifiable through account settings, and the specific endpoints you use are on the covered list.

Do not send to an external LLM when:

• The prompt would include full patient identifiers with no functional need (names, DOB, MRN, full address, insurance policy numbers).
• The task is deterministic enough for a rules engine or a smaller in-VPC model.
• You cannot verify retention settings programmatically for every call.
• Your customer's downstream BAA with you explicitly prohibits sub-processing to external AI vendors.
• The feature you want to use is outside BAA scope. Some newer OpenAI features like assistants and threads do not fall under the zero-retention API perimeter because they store state by the nature of the feature.

The default should be to redact first, then route to the smallest model that can do the job. External frontier models are for the residual set of tasks that genuinely need them.

Redaction and tokenization patterns before inference

The single highest-leverage control in a HIPAA AI stack is a redaction layer that sits between your application and the model provider. Its job is to strip or tokenize identifiers before the prompt leaves your infrastructure, and to reverse-map any tokens on the way back.

Common patterns:

1. Deterministic tokenization. Replace patient names, MRNs, and account numbers with opaque tokens (e.g., PATIENT_A7F3, MRN_9C21) using a keyed HMAC. The model sees PATIENT_A7F3 owes $150 for CPT 99213. The token-to-value mapping lives in your database, never in the prompt. On the response, replace tokens back to real values in your application layer.
2. Field-level redaction against a Safe Harbor list. HIPAA § 164.514(b)(2) lists 18 identifiers that must be removed to qualify data as de-identified. A redaction library that recognizes and strips those fields before the payload hits the LLM SDK is the cheapest way to reduce risk on unstructured memo fields.
3. Structural minimization. Do not send the whole invoice object. Send only the fields the model needs. If the model is matching line-item amounts to bank transactions, it does not need a patient name column at all.
4. Query-level redaction on retrieval. When an agent retrieves records via a tool call, apply a redaction transform at the tool boundary before the result is fed back into the LLM's context window. The unified API response can be filtered through a JSONata expression that nulls or tokenizes sensitive fields for the LLM path while the original response continues to your application for display.
5. Differential privacy for aggregate queries. For reporting-style prompts ("what was our average claim reimbursement last quarter?"), inject calibrated noise into aggregates or use bucketed responses so individual patients cannot be re-identified from repeated queries. This is only relevant when the LLM is doing analytics, not transactional writes.

# Illustrative redaction wrapper - conceptual, not production code
def redact_for_llm(record: dict) -> tuple[dict, dict]:
    token_map = {}
 
    def tokenize(value, kind):
        token = f"{kind}_{hmac_short(value)}"
        token_map[token] = value
        return token
 
    redacted = {
        "contact_id": tokenize(record["contact_id"], "CONTACT"),
        "line_items": [
            {
                "description": strip_phi(li["description"]),
                "amount": li["amount"],
                "cpt_code": li.get("cpt_code"),
            }
            for li in record["line_items"]
        ],
    }
    return redacted, token_map

Patient names, dates of service, diagnosis codes, medication names, insurance IDs, provider names, and facility details are the fields most commonly exposed in LLM pipelines, and indirect identifiers like age combined with condition and geography are a significant re-identification risk that standard tools underdetect. Your redaction rules need to cover both.

The redaction layer itself becomes a compliance-critical component. Log its decisions (what was redacted, not what the value was), version its rules, and test it against a corpus of realistic payloads before shipping.

Private and on-prem inference deployment options

For workflows that cannot tolerate any external inference, the next tier is running the model inside a perimeter you control. There are three practical deployment shapes in 2026:

1. Cloud-hosted, single-tenant inference in your VPC. Azure OpenAI with private endpoints, AWS Bedrock with VPC endpoints and customer-managed KMS keys, or Google Vertex AI with VPC Service Controls. The model provider still hosts the weights, but requests traverse private networking and never touch the public internet. A BAA is still required, but the sub-processor list is shorter and network egress is auditable.
2. Fully self-hosted open-weights models. Llama, Mistral, or Qwen models deployed on GPU instances inside your VPC or a hospital's on-prem cluster. No third-party BAA required for inference itself because no third party sees the traffic. Trade-off: you own model ops, security patches, guardrails, and evals. Cost per token is often higher at low utilization but cheaper at scale.
3. On-device / edge inference for point-of-care apps. For workflows where a clinician is drafting notes on a laptop or tablet, small models running locally (7B-13B parameter class) can handle summarization and structured extraction without any network egress. Useful as a first-pass filter before optionally escalating to a larger cloud model with already-redacted data.

Match the deployment to the workflow:

• Reconciling thousands of invoices overnight? Cloud-hosted single-tenant with redaction is usually the sweet spot.
• Drafting patient-billing narratives that reference clinical context? Self-hosted open weights, because prompt content is unavoidably PHI-heavy.
• Extracting structured fields from receipts on a mobile device? On-device inference, no network hop needed.

Retention, deletion, and secure cache policies for tool calls

Even with a strict pass-through architecture at the integration layer, the AI orchestration layer will accumulate state: tool-call inputs, tool-call outputs, model responses, and reasoning traces. Every one of those is a potential PHI store. Concrete policies:

• Default retention: zero. Tool-call payloads are transient. Hold them only for the lifetime of the request and evict on completion or timeout.
• If retention is required for debugging, cap it at 24 hours and store only in an encrypted store with tightly scoped access. Never let debug traces live in a general-purpose observability platform without a BAA.
• Retention buckets by data class. Metadata (tool name, account ID, latency, HTTP status) can live for 90 days for operational analytics. Payload bodies must be evicted immediately or never written at all.
• Deletion on demand. A customer-initiated deletion must purge tool-call history, cached tokens, and any redaction token maps for that patient within the timeframe specified in your BAA (typically 30 days, sometimes shorter under state privacy laws).
• Backup handling. Backups are the most-forgotten PHI store. If your tool-call telemetry is backed up nightly, deletion is not complete until the backup rotates. Document the maximum lag and disclose it in your DPA.
• Audit log redaction. Audit trails are required by HIPAA § 164.312(b), but the audit trail itself must not contain PHI. Log the actor, the action, the resource identifier, and the outcome. Do not log the payload. If a payload is needed for forensic reconstruction, store a hash and let the customer retrieve the original from the source system.
• Kill switches on model provider caches. If your provider offers ZDR or equivalent, enable it at the organization and project level, and test it. Retention controls should be configurable at both organization and project scope, with the ability to explicitly select zero data retention per project rather than inheriting defaults.

Sample contractual and technical clauses for BAAs with model vendors

Legal counsel will draft the final BAA, but a few substantive clauses are worth insisting on with any model vendor. Draft language you can bring to negotiations:

On training and derivative use:

Business Associate shall not use Protected Health Information, including prompts, completions, embeddings, and intermediate reasoning outputs, to train, retrain, evaluate, or improve any machine learning model, whether accessible to Covered Entity or to any other customer.

On retention:

Business Associate shall not persist PHI beyond the duration necessary to service the individual API request. Any abuse-monitoring or safety logs that incidentally capture PHI shall be encrypted at rest, access-restricted to a named list of personnel, excluded from human review, and deleted within seventy-two (72) hours of collection.

On sub-processors:

Business Associate shall maintain and publish a current list of sub-processors that may access PHI, shall notify Covered Entity at least thirty (30) days before adding any new sub-processor, and shall ensure each sub-processor is bound by contractual obligations no less protective than those in this Agreement.

On breach notification:

Business Associate shall notify Covered Entity of any Breach of Unsecured PHI without unreasonable delay and in no event later than twenty-four (24) hours after discovery.

On region and residency:

All inference requests and any incidentally logged data shall be processed and stored exclusively within the geographic regions designated in Exhibit A. Failover to any other region shall require prior written consent of Covered Entity.

On audit rights:

Covered Entity may request, no more than once annually, a copy of Business Associate's most recent SOC 2 Type II report, penetration test summary, and HIPAA Security Rule risk assessment. Business Associate shall respond within fifteen (15) business days.

Technical addendum clauses worth including:

• Zero Data Retention flag enabled at the account or project level, verifiable via API or admin console.
• API keys scoped to HIPAA-eligible endpoints only, with any non-eligible endpoint calls rejected server-side.
• Customer-managed encryption keys for any data at rest.
• Log export controls that prevent PHI from flowing into general observability tooling or third-party SIEMs without a separate BAA.
• Documented list of features and modalities that fall outside the BAA (for example, stateful assistant threads, web browsing tools, or hosted vector stores) so your engineers know what not to use.

These clauses are a starting point, not a substitute for legal review. Bring them to your counsel and to the vendor before you send a signed copy of anything.

The playbook in one page (Strategic Wrap-Up)

Building AI agents for healthcare finance is a high-reward endeavor, but the compliance risks are absolute. You cannot afford to treat your integration layer as an afterthought. If you rely on legacy sync-and-cache unified APIs, you are actively introducing PHI liabilities into your architecture. You are expanding your attack surface and complicating your BAA obligations.

If you take only the checklist from this guide, this is it:

• Default to zero retention. Pass-through unified APIs eliminate the largest HIPAA risk category in your integration layer. Audit any vendor that caches payloads, even "temporarily."
• Make integrations data, not code. Declarative JSON + JSONata mappings shrink your runtime surface area, your audit scope, and your time-to-fix when an upstream API changes.
• Unify the schema, preserve the customs. A single accounting schema for the LLM, plus a custom_fields passthrough for the patient identifiers your customers actually use.
• Pass 429s through; do not buffer. Normalize rate-limit headers, let the caller own backoff, and never let a retry queue become a PHI store.
• Refresh OAuth proactively; log metadata only. Tokens expire, payloads do not need to be in your telemetry.
• Treat MCP servers as part of the PHI perimeter. Disable tool-call payload retention. Use end-user OAuth. Generate tools from the unified schema to cut hallucinations.
• Redact before inference, and pick the smallest model that works. Tokenize identifiers, minimize fields, and reserve external frontier models for tasks that genuinely need them.
• Get BAAs that match your architecture - including with your model provider. If your design only touches metadata, your BAA scope should reflect that. If you are sending prompts to an external LLM, the model vendor is a business associate too.

The brutal honest version: zero data retention does not make you HIPAA compliant on its own. You still need access controls, encryption in transit, audit logs of who did what, breach notification procedures, and signed BAAs with every vendor in the path - including your model provider. What it does is collapse the parts of the system that have to participate in those programs, so a smaller team can defend a smaller perimeter. Stop building brittle, point-to-point accounting integrations in-house. Stop exposing your LLMs to raw, undocumented ERP endpoints. Standardize your inputs, enforce strict pass-through architectures, and protect your customers' data.