# HIPAA-Compliant AI on Infrastructure You Own

> Source: https://ibl.ai/resources/capabilities/hipaa-compliant-ai


*A signed BAA is the contract. The architecture is what HIPAA auditors actually test. Run AI inside your perimeter, with audit logs in your SIEM and full source-code ownership.*

Most healthcare organizations start their AI procurement with the right opening question: will the vendor sign a Business Associate Agreement. The answer needs to be yes — but it is not where HIPAA-aligned AI ends.

HIPAA's Security Rule applies to every system that touches Protected Health Information, and an AI inference endpoint touches PHI the moment a prompt does. The auditable surface is technical: data residency, audit chain, integrity, transmission security, authentication, and continuity.

ibl.ai is the platform layer that converts a BAA from a signature into a defensible HIPAA posture — running on your infrastructure, logging to your SIEM, with your choice of model per workload and the source code in your repository.

## The Challenge

Single-vendor SaaS AI deployments give covered entities legal cover via a BAA, but they put PHI on someone else's infrastructure, audit logs on someone else's dashboard, and continuity on someone else's roadmap. The mismatch is the source of most failed HIPAA-AI audits.

The pattern repeats across hospitals, health systems, payers, and life-sciences companies: a BAA is signed, the deployment runs, the audit arrives, and the auditor asks for evidence in a format the vendor's dashboard cannot produce. The architecture has to support the audit — not the contract.

## How It Works

1. **Deploy the Platform Inside Your Perimeter:** ibl.ai deploys in your VPC, your data center, or your air-gapped environment. The complete source code is yours. No telemetry leaves your network. Your identity, networking, and audit systems are the platform's identity, networking, and audit systems.
2. **Route PHI Workloads to a Local Open-Weights Model:** For PHI-heavy workloads — clinical documentation, medical coding, member services with patient context — the platform routes prompts to a local model (Llama, Mistral, Qwen, Phi) running on your GPUs. No external API call. No BAA needed for that hop.
3. **Route Non-PHI Workloads to a Frontier Model Under a BAA:** When frontier quality matters and PHI is not involved, the platform routes to ChatGPT Enterprise, Claude via Bedrock, or Gemini via Vertex AI — under the respective BAA. The platform captures the prompt and response in your audit log before and after the external hop.
4. **Log Every Prompt, Response, and Model Invocation to Your SIEM:** The audit layer writes structured events to your SIEM — Splunk, Elastic, Sentinel, Datadog — with user identity, timestamp, prompt reference, model identifier, and response reference. Your audit-of-record is the ground truth, not a vendor dashboard.
5. **Enforce Workforce Governance at the Platform Layer:** Identity is federated to your IdP. Role-based access controls map to your IAM. DLP integration flags PHI-shaped content leaving the sanctioned path. Training and attestation flows are first-class workflows, not bolt-on policy.
6. **Maintain Continuity Independent of Any Single Vendor:** Because the platform code is yours and the model is per-workload-selectable, vendor changes do not stall clinical AI. A deprecated model is a routing change, not a re-procurement. A vendor outage is a per-workload fallback, not an institutional incident.

## Features

### Self-Hosted Inference for PHI Workloads

Open-weights models run on your GPUs, inside your perimeter. PHI prompts never leave the covered entity. No external API call, no BAA needed for the inference path.

### BAA-Aware Frontier Routing

Frontier models reachable through ChatGPT Enterprise, Claude on Bedrock, and Gemini on Vertex AI — each under its own BAA — with the platform's audit layer capturing the prompt and response locally first.

### Audit Logs in Your SIEM

Every prompt, response, and model invocation written to your audit-of-record SIEM in your format, on your retention schedule, with structured fields for user, timestamp, model, and content reference.

### Identity Federated to Your IdP

Single sign-on through your existing identity provider (Okta, Azure AD, Ping, Shibboleth). No shadow accounts. Every AI session is identity-bound for HIPAA accountability.

### Role-Based Access Mapped to Your IAM

Granular RBAC mirrors your organization's data-access policies. Clinicians, residents, administrators, and developers each see the scope appropriate to their role — enforced at the platform level, not at the workflow level.

### DLP-Compatible Workforce Guardrails

Browser-level and platform-level guardrails detect PHI-shaped content moving toward unsanctioned AI tools. Shadow usage becomes a visible signal in your security operations, not a hidden risk.

### Full Source-Code Ownership

The complete platform code ships with the deployment. Your security and compliance teams inspect, modify, and extend it. No vendor lock-in if priorities, regulations, or vendor terms change.

## With vs. Without

| Aspect | Without | With |
|--------|---------|------|
| Where PHI Is Processed | PHI prompts are processed on the vendor's inference infrastructure, even under a BAA. Data-residency commitments depend on the vendor's region selection and disclosure. | PHI workloads route to a local open-weights model running on customer GPUs inside the covered entity. PHI never leaves the perimeter for the inference path. |
| Audit Log Ownership | Audit logs live on the vendor's infrastructure, in the vendor's format, on the vendor's retention schedule. Evidence production for HIPAA audits depends on vendor cooperation. | Logs are written to the customer's SIEM in the customer's audit-of-record format, on the customer's retention schedule. Evidence production is a SIEM query, not a vendor ticket. |
| BAA Scope | A single vendor's BAA covers a single inference path. Multi-model strategies require multiple BAAs, each with separate scope and separate evidence. | Local-model inference needs no BAA; BAA-covered frontier routing is selected per workload. The platform's audit layer unifies evidence across all paths. |
| Workforce Governance | Sanctioned-path adoption depends on the vendor's UX. Shadow usage in personal accounts is invisible to the vendor and the institution. | Sanctioned path is identity-bound through the customer IdP. Shadow usage is a visible DLP and SIEM signal, not a hidden audit risk. |
| Vendor Continuity | Vendor pricing changes, model deprecation, or terms updates can interrupt clinical workflows. Mitigation is re-procurement. | Vendor changes are routing changes. The platform code is owned by the customer; the model is per-workload-selectable; continuity does not depend on any single vendor. |
| Model Choice | Single-vendor SaaS locks the institution to one vendor's roadmap. PHI workloads, marketing, and developer tools share the same inference path. | Frontier models for frontier-quality non-PHI workloads; local open-weights models for PHI workloads. Different models, one governance layer. |
| Air-Gapped Deployment Option | Air-gapped deployment is rare in SaaS AI. Strict residency or segmentation requirements often disqualify the vendor entirely. | Air-gapped deployment is a supported topology. Local-model inference on isolated networks satisfies the strictest residency and Part 2 requirements. |

## FAQ

**Q: Is ibl.ai itself HIPAA compliant?**

ibl.ai signs a Business Associate Agreement for engagements where ibl.ai personnel access customer environments containing PHI. For the platform deployment itself, HIPAA compliance is a property of how the customer configures and runs the platform — ibl.ai ships the architecture and tooling that make HIPAA-aligned configurations the default, including local-model inference, SIEM-integrated audit logging, identity federation, and air-gapped deployment topology.

**Q: Do I still need vendor BAAs if I use ibl.ai?**

Yes, for any workload that routes to an external frontier model — ChatGPT Enterprise, Claude on Bedrock, Gemini on Vertex AI — you need the BAA from that vendor (OpenAI, AWS, or Google respectively). Workloads that route to a local open-weights model running on your GPUs need no external BAA, because no third party processes the inference. ibl.ai's platform makes the routing decision per workload, and the audit layer records which path each prompt took.

**Q: Where do audit logs go?**

Audit logs are written to the customer's SIEM and audit-of-record storage. Supported integrations include Splunk, Elastic, Microsoft Sentinel, Datadog, Sumo Logic, and any syslog- or webhook-capable system. The customer defines the retention policy and the storage location. ibl.ai does not retain or transmit customer audit logs.

**Q: Can ibl.ai be deployed air-gapped for the strictest PHI workloads?**

Yes. The platform supports air-gapped deployment in isolated networks with no external connectivity. Local-model inference runs on customer GPUs in the air-gapped zone, audit logs write to local storage, and identity federation works through the customer's air-gapped IdP. This topology supports the strictest residency, segmentation, and 42 CFR Part 2 commitments.

**Q: How does ibl.ai handle 42 CFR Part 2 records?**

42 CFR Part 2 records (substance-use-disorder treatment) require consent-bound access patterns stricter than baseline HIPAA. The platform supports per-record ABAC policies, consent-tracked retrieval, and air-gapped inference for Part 2-covered workflows. Audit logs capture the consent context at the prompt level, satisfying the evidence requirements for Part 2 examinations.

**Q: Can clinicians and staff use ibl.ai through familiar interfaces like Epic or Cerner?**

Yes. ibl.ai integrates with major EHR/EMR systems via FHIR R4, HL7 v2, and direct connectors to Epic, Cerner, Meditech, and Athena. AI agents can be invoked inline within clinical workflows, with the audit chain captured at the platform layer regardless of which UI the clinician used.

**Q: What is the typical first deployment scope for a HIPAA covered entity?**

A common first scope is one PHI-heavy workflow (clinical documentation, medical coding, or member-services triage) deployed with a local open-weights model on customer GPUs, plus one non-PHI workflow (research literature, internal drafting) routed to a BAA-covered frontier model. This delivers the build-and-buy posture — production-grade platform, source code in the customer's repository, governance unified across both paths — within four to eight weeks.

**Q: How does this compare to running ChatGPT Enterprise or Microsoft Copilot for healthcare?**

ChatGPT Enterprise and Microsoft Copilot are managed SaaS products. Their BAA covers the inference path on the vendor's infrastructure. ibl.ai is a self-hosted platform that runs inside the covered entity, supports local-model inference for PHI workloads, captures audit logs in the customer's SIEM, and ships the source code to the customer. The two postures are complementary for many institutions: use the SaaS product for low-sensitivity tasks under its BAA; use ibl.ai for PHI workloads and unified governance.