Skip to content

HIPAA compliance at B3IQ. We sign the BAA.

Healthcare teams can run AI on hardware they own, in a US facility they can name.

Last updated October 3, 2026

Before handling PHI

Execute the BAA

Before provisioning, not after: the agreement lists the specific machines that may handle PHI.

Agree on workload scope

Confirm operational workload isolation before provisioning, and keep PHI inside the reviewed path.

Review your setup

Dedicated mode, encryption, access controls and your own risk analysis are part of the deployment review.

Four questions to put to any vendor

Will you sign a BAA, and when?

Yes, before the machine is provisioned. NPC Labs, Inc., which operates B3IQ, signs it as part of your purchase.

Who else’s workloads run on this hardware?

Your customer key reaches only your machines. A separate B3IQ-directed routing path exists; see what the BAA covers. Confirm operational workload isolation before provisioning.

What do you store, and for how long?

Request metadata, for 90 days. From your application, no readable prompt or completion content: a private job is held only as ciphertext we cannot decrypt, then purged after about 30 days.

What can you prove to my auditor?

A named facility, a specific serial number, and signed per-request receipts carrying model and machine identity with no content in them.

This page describes how the service works; it is not legal advice, and it does not decide for you whether HIPAA applies to what you are building.

Signing the BAA

Request the BAA during onboarding or at contact@npclabs.org. We do not knowingly accept PHI onto hosted hardware without one.

It is a negotiated document reviewed by both sides, not a checkbox in a settings page. If PHI reaches a machine with no BAA in place, tell us: we will treat that as an incident.

You need one whenever a machine you own with us will create, receive, maintain, or transmit ePHI. HHS guidance on cloud computing treats a provider of “no-view” services (one that maintains ePHI it has no ability to decrypt) as a business associate. Encryption reduces the risk; it does not remove the relationship. Two cases fall outside it: a machine shipped to your own facility, which sits under your physical controls and never has us maintaining your ePHI, and a machine that never touches PHI.

On the ordinary hosted gateway, the routing edge and control plane can see prompt and completion content in memory, but do not store it. For private_transport jobs, B3IQ's routing layers relay ciphertext they cannot decrypt. The node operator can see content on both paths because the model must process it. Encrypted transport is not confidential execution. Read the privacy boundary.

What HIPAA actually asks of a vendor

Three concrete things: a signed Business Associate Agreement, safeguards that are in place, and a customer who has done their own risk analysis.

No government body certifies, endorses, or approves any product, vendor, or cloud service as HIPAA compliant. The Department of Health and Human Services runs no certification program, and neither does any accreditor on its behalf. Every “HIPAA certified” badge is either self-issued or sold by a private company whose seal carries no regulatory weight.

Why owned hardware clears a review faster

Owned hardware gives your reviewer a specific server and hosting arrangement to assess. The review still needs to cover who can access the machine, which workloads can run on it, and where request content is visible.

The machine is a serial number in a rack you can visit. Oregon: name it in your data-flow diagram, or come see it. If your policy will not allow that, take ship-to-you and put it in your own building.

Your customer key routes only to machines you own. That boundary is checked server-side on every request. It does not establish that all other workloads or operator access are excluded; confirm those separately before provisioning, as what the BAA covers sets out.

Setting up a machine for PHI

None of this is exotic, but the order matters.

  1. Execute the BAA, and name the machines

    Before provisioning, not after: the agreement lists the specific machines that may handle PHI.

  2. Keep the machine in its dedicated mode

    Dedicated is the default; leave it there. Earn mode is outside the BAA.

  3. Turn on encryption at rest at build time

    Your hardware, your OS image, your disk key: we do not want a copy. Ask during the build and we will set it up with you.

  4. Decide who can reach the machine

    Set fleet SSH keys once for your org, close the SSH lane on machines that do not need it, and approve each support grant yourself.

  5. Encrypt the request body if the model is not enough

    Use the private_transport path when your threat model includes us: the request is encrypted to your node’s transport key.

  6. Keep PHI inside the reviewed path

    Before the first week, tell your team which surfaces sit outside it; the scope list below names them.

  7. Do your own risk analysis

    No vendor can do it for you, and it is the first thing an auditor asks for.

What the BAA covers, and what it does not

Coverage attaches to your machines and the path to them. It stops where the product deliberately involves somebody else’s hardware or somebody else’s traffic.

In scope under an executed BAA

  • Your hosted machine. The specific server you own, in its rack in our Oregon facility, including physical security, power, networking, and the on-site engineering that maintains it.
  • Routing to your own machines. Every key on your account reaches your machines and nothing else. This is not a setting you turn on: the router resolves your machine list server-side on each request, drops any machine id you do not own, and refuses the request outright if none of your machines can serve it. There is no shared pool to fall through to.
  • Encrypted private jobs. The private_transport path, where the request body is encrypted to your node’s transport key and B3IQ relays ciphertext it holds no key for.
  • Usage metadata and receipts. Request identifiers, timestamps, model, machine, token counts, latency, and status: the records we keep to measure usage. They carry no prompt or completion text.
  • Remote access to the machine. The per-machine SSH lane and any scoped, expiring support grant you approve for diagnostics.

Not in scope: keep PHI out of these

  • B3IQ-directed workloads. A separate routing path exists for B3IQ-directed workloads, outside your BAA. Serving inference produces no per-request earnings. Customer-key scoping does not establish operational workload exclusivity: if your risk analysis requires all other workloads to be excluded, confirm that isolation with B3IQ before provisioning.
  • Earn mode. Renting the machine out on external GPU marketplaces instead. It withdraws the machine from every B3IQ inference path (including your own keys), closes its SSH lane, and reboots it onto a separate encrypted volume for the renter. The renter has the machine, not us, and the earn volume cannot read your bare-metal disk.
  • The hosted playground. The dashboard playground runs on your own machines, but it is a development tool, not part of your reviewed application path. Do not paste PHI into it.
  • The GPU marketplace. Renting capacity from other operators, or listing yours to them, is multi-tenant by definition, so it is outside the BAA.
  • b3iq.org itself. The marketing site, the analytics on it, and the “Book a call” form are ordinary web surfaces. Do not put patient information in a contact form.

Shared responsibility

You own the machine, so you own more of the stack than on a conventional cloud, and more of the control.

B3IQ is responsible for

  • Physical security of the facility and your rack
  • Power, cooling, networking, and 24/7 monitoring
  • Keeping the machine patched and healthy at the platform layer, on request
  • Routing your keys only to hardware you own, enforced per request
  • Keeping readable prompt and completion content out of our datastores
  • Access controls and audit logging on our own systems
  • Reporting security incidents affecting your ePHI

You are responsible for

  • Deciding whether HIPAA applies to your workload at all
  • Your own risk analysis and workforce training
  • Encryption at rest, OS hardening, and user access on the machine
  • Which models you run and what you send them
  • Keeping PHI out of the playground, contact forms, and support tickets
  • BAAs with your own downstream vendors and clients
  • Retention and disposal of anything your application stores

Safeguards

Technical
  • Private jobs use an X25519 key exchange to the node’s transport key with AEAD encryption, and streaming responses bind a sequence number and final-frame flag into each frame’s authenticated data, so truncated, reordered, dropped, or replayed frames are detected.
  • API keys and tokens are stored only as hashes.
  • IP addresses and user agents appear in admin audit logs only as hashes, with the IP under a keyed HMAC.
  • The per-machine SSH lane can be closed from the dashboard, which then refuses inbound SSH even where your fleet key is trusted elsewhere.
  • Support grants are diagnostics-scoped, expiring, revocable, and are not authorized to reach raw prompt or output content.
Physical
  • The Oregon facility runs N+1 power, 24/7 on-site engineering, and physical security.
  • The facility operator maintains its own physical-security and availability attestations, which we can provide during a security review.
  • Managed Hosting insures the machine at replacement value while it is racked in our facility.
Administrative
  • Per-request metadata is deleted automatically after 90 days; aggregate counters derived from it identify no individual request.
  • Stored private-job ciphertext is purged after about 30 days, leaving only a billing record behind.
  • We do not train on your prompts or completions, we do not sell them, and no human reviews them.
  • Everyone with access to B3IQ systems completes security awareness training.
  • Our written security policy set is available on request.

Compliance and assurance

Our SOC 2 Type II audit is underway with A-LIGN. We expect the report in 2027. The full list, including our completed HECVAT, is on the Security page.

Incidents

Under an executed BAA we will report security incidents affecting your ePHI to you without unreasonable delay, and cooperate with your own breach-assessment obligations. Report anything you see to contact@npclabs.org; if it concerns a specific machine, include its identifier from the dashboard and nothing else. Do not send PHI in the report.

Contact

BAA requests, security questionnaires, and compliance questions go to the address below.

NPC Labs, Inc.1801 N. 16th AvePhoenix, Arizona 85007United Statescontact@npclabs.org

Talk through the BAA with us.

Next: Accessibility at B3IQ