HIPAA position and business associate agreements
Inference Analytics acts as a business associate to the covered entities it serves. We sign a BAA before any protected health information enters the platform, and our agreements extend to the subprocessors that can access PHI, including model providers reached through the platform.
- A BAA is executed before production access is granted — not after a pilot has already handled real data.
- Model providers are covered by agreements that contractually disable training on data submitted through the platform.
- The minimum necessary standard is applied at retrieval time, so a model receives only the context the task requires.
- We do not use customer PHI to train or improve models, our own or anyone else's.
No AI model is HIPAA-compliant in itself. What is compliant, or not, is the deployment around it. We describe the safeguards we implement and will evidence them; we do not describe any model as compliant.
Encryption and data protection
| Control | Implementation |
|---|---|
| In transit | TLS 1.2 or above for all connections, including to model provider APIs. |
| At rest | AES-256 for primary stores, vector stores, caches, backups and logs. |
| Derived data | Embeddings generated from PHI are treated as PHI and inherit the same encryption, access control and retention as their source. |
| Key management | Managed keys with documented rotation; keys are not shared across tenants. |
| Isolation | Customer data is logically isolated per tenant; no cross-tenant retrieval is possible. |
Identity, access and agent scoping
Access is governed on two independent axes: what a person may see, and what an agent may reach. The second is not derived from the first, which is what stops a broadly privileged builder from creating a broadly privileged agent.
- Single sign-on against the health system's identity provider, with role mapping maintained in that system rather than duplicated in ours.
- Role-based access control for platform functions, including who may promote an agent to production.
- Per-agent data scoping, configured centrally, restricting each agent to the minimum data and tools its function requires.
- Permission-aware retrieval, filtering at query time by the requesting user's entitlements rather than redacting after generation.
- Separation of duties between building an agent and approving its release.
Why the second axis matters in practice: no-code AI agents for healthcare.
Audit logging and retention
- Every prompt, retrieval, tool call, model call and output is logged with the requesting identity and timestamp.
- Logs are immutable and queryable, and can be exported for a named user and date range for compliance review.
- Retention schedules are defined per data class — prompts, outputs, embeddings, logs — and enforced automatically rather than by process.
- Deletion requests, including those touching derived data such as embeddings, follow a documented procedure with a completion record.
- On termination, customer data is returned in an agreed format and destroyed on a contractual timeline.
Data residency and subprocessors
Data residency is agreed per deployment and recorded in the contract. We maintain a current subprocessor list covering every party that can access customer data, and provide advance notice of changes to it.
Our subprocessor list, current certification scope and assessment dates, security architecture overview and standard BAA are provided under NDA during evaluation. Request them through the contact page and name the documents you need for your review.
Human oversight
Security controls bound what a system can reach. Oversight bounds what it can do unreviewed. Both are required, and we treat the second as a compliance control rather than a product preference.
- Agents do not make clinical decisions. Outputs that inform care are reviewed by a qualified human, and that reviewer is recorded.
- The review requirement is configured centrally and cannot be removed from inside the agent build interface.
- Agents do not write to the patient record; they work alongside the system of record.
- Every autonomy boundary is a configuration with an owner and a change history.
The full position, including how models are selected and reviewed: AI governance.
Frequently asked questions
Is Inference Analytics HIPAA compliant?
Inference Analytics operates as a business associate and implements the HIPAA administrative, physical and technical safeguards in the InferAgents platform core: PHI remains inside the compliance boundary, model providers are reached only at the API level under a BAA with training on submitted data disabled, data is encrypted in transit and at rest, access is enforced per user and per agent, and all activity is written to an immutable audit log. We sign a BAA before any PHI enters the platform.
Will you sign a business associate agreement?
Yes, and we execute it before production access is granted rather than after a pilot has handled real data. Our agreements extend to subprocessors that can access PHI, including the model providers reached through the platform.
Do you train models on our data?
No. We do not use customer protected health information to train or improve any model, ours or a provider's. Provider-side training on data submitted through the platform is contractually disabled, and we will show you the clause during evaluation.
Where is our data stored?
Data residency is agreed per deployment and recorded in the contract. Customer data is logically isolated per tenant, encrypted at rest with AES-256, and no cross-tenant retrieval is possible. Specific regions and hosting details are provided during evaluation.
Can we audit what the AI did?
Yes. Every prompt, retrieval, tool call, model call and output is logged with the requesting identity and timestamp, in an immutable and queryable store. For a named user and date range you can export the complete record, including which context was retrieved and which model answered.