HIPAA compliance at B3IQ

Yes. NPC Labs, Inc. signs a Business Associate Agreement. Request one during onboarding or at contact@npclabs.org. It is executed as part of your purchase, before the machine is provisioned, and we do not knowingly accept PHI onto hosted hardware without it.

It is a negotiated document reviewed by both sides rather than a checkbox in a settings page, and it names the specific machines that may handle PHI. If PHI reaches a machine with no BAA in place, tell us: we will treat that as an incident rather than quietly leave it there.

You need one whenever a machine you own with us will create, receive, maintain, or transmit ePHI, and that holds even though we cannot read your workloads. 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 simply never touches PHI.

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 programme, and neither does any accreditor on its behalf. Every “HIPAA certified” badge on the internet is either self-issued or sold by a private company whose seal carries no regulatory weight. A vendor leading with one is telling you something, just not what they intended.

What HIPAA actually requires of a vendor is concrete: a signed Business Associate Agreement, safeguards that are genuinely implemented rather than described, and a customer who has done their own risk analysis. So the four questions worth putting to any infrastructure vendor, and our answers:

• Will you sign a BAA, and when? Yes, before the machine is provisioned.
• Who else’s workloads run on this hardware? The machine is yours alone, physically. B3IQ can direct inference to spare capacity on it; see the scope table below, which says so plainly rather than leaving you to find out.
• What do you store, and for how long? No prompt or completion content, ever. Request metadata for 90 days. Both are in the Privacy Policy, not just on this page.
• 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.

Most of what stalls a healthcare security review of a cloud vendor is shared infrastructure: whose other tenants sit on this host, what the hypervisor boundary is worth, which region the data actually landed in, who at the provider can read the volume. Owning the machine deletes that entire category of question rather than answering it.

The machine is a serial number in a rack you can visit. Eugene, 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.

Isolation is not a policy setting you have to trust. Every key on your account routes to your machines and nothing else, and that is enforced on our side on every single request: the router re-resolves your machine list from the database, drops any machine id you do not own, and refuses the request outright rather than falling through to anything shared. There is no shared pool for it to fall through to.

The evidence is already in the format an auditor wants. Completed work commits to a signed receipt carrying model identity, machine identity, and token count: hashes and counts, never the prompt or the output. You can hand it over without exposing anything the reviewer should not see.

None of this is exotic, but the order matters, and doing it at build time is far cheaper than retrofitting it onto a machine already in production.

1. Execute the BAA, and name the machines. The agreement lists the specific machines that may handle PHI. Do this before provisioning, not after; it is much easier than retrofitting an agreement onto hardware already in service.
2. Keep the machine in its dedicated mode. Dedicated is the default. Earn mode withdraws the machine from your own keys and reboots it for external marketplaces, so it is not a mode a PHI machine belongs in.
3. Turn on encryption at rest at build time. It is your hardware and your OS image, so the disk key is yours; we do not want a copy. Ask during the build and we will configure it with you rather than leaving you to retrofit it in production.
4. Decide who can reach the machine. Fleet SSH keys are set once at the org level; each machine's SSH lane can also be closed individually from its dashboard page, which refuses inbound SSH even where your fleet key is trusted. Support grants are diagnostics-scoped, expiring, and revocable, and you approve each one.
5. Encrypt the request body if the model is not enough. The private_transport path encrypts the request to your node's transport key, so the control plane relays ciphertext it cannot open. Worth it when your threat model includes us.
6. Keep PHI inside the reviewed path. Your application talks to your machines. The dashboard playground, the contact form, and support tickets are not part of that path; tell your team so before the first week, not after.
7. Do your own risk analysis. This is the part no vendor can do for you, and the part an auditor asks for first. Our job is to make the infrastructure answers easy; the analysis is yours.

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 Eugene, 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 meter and bill. 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. While your machine is online and has spare capacity, B3IQ can direct inference to it: that is how the network keeps utilisation up, and how a machine earns. That is other traffic running on your hardware; it is not access to your data, and it is not covered by your BAA. If your risk analysis requires the machine to serve nothing but your own workloads, raise it before provisioning and we will tell you honestly where that stands.
• Earn mode. Earn mode withdraws a machine from every B3IQ inference path (including your own keys), closes its SSH lane, and reboots it onto a separate encrypted volume so it can be rented on external GPU marketplaces. The renter has the machine, not us, and the earn volume cannot read your bare-metal disk. A machine that handles PHI stays in its dedicated mode.
• The hosted playground. The dashboard playground runs on your own machines, but it is a development tool rather than part of your reviewed application path. Do not paste PHI into it.
• Overflow to external providers. No account overflows to an outside provider today; the route exists in the platform but every dispatch path denies it. If it is ever enabled for an account, those requests leave our infrastructure under that provider's terms. It will not be enabled on an account under a BAA.
• The GPU marketplace. Not live in production. When it launches, renting capacity from or listing capacity to other operators is a multi-tenant arrangement by definition, and stays 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.

You own the machine, which means you own more of the stack than you would on a conventional cloud, and correspondingly more of the control. The split we work to:

Encryption at rest sits on your side because it is your hardware and your OS image. Ask us at build time and we will configure it with you, but the key is yours, and we do not want a copy.

Technical. Ownership is re-resolved server-side on every request, so a key cannot reach hardware outside your account even if it asks to. 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 authorised to reach raw prompt or output content.

Physical. Your hardware is a specific serial number in a specific rack in Eugene, Oregon, with 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. Our operating fee insures the machine at replacement value.

Administrative. Per-request metadata is retained for 90 days and then deleted automatically; aggregate counters derived from it identify no individual request. Stored private-job ciphertext is purged after roughly 30 days, leaving a billing skeleton behind. We do not train on your prompts or completions, we do not sell them, and no human reviews them.

B3IQ holds no SOC 2 or HITRUST report of its own today. The facility we host in holds its own attestations, and those are the facility's, not ours. We would rather tell you that than let a logo on a marketing page do the implying.

Confidential compute is not enabled. Our roadmap includes verified confidential execution backed by hardware attestation, and the routing layer is already fail-closed for it: a request asking for a verified confidential class matches no machine today rather than silently downgrading. Until the attestation verifier ships, the strongest privacy class we offer is encrypted transport to a machine you own.

Your machine is single-tenant hardware, not a single-workload appliance. Nobody else’s data lives on it and no other customer can route to it, but while it is online with spare capacity, B3IQ can direct inference to it. If your risk analysis needs the machine to serve your workloads and nothing else, say so before you buy and we will give you a straight answer about where that stands.

Bring your security questionnaire to the call. We would rather go through it line by line than have you take a page like this at face value.

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.

The Privacy Policy covers what we collect and retain across the whole service, and Private AI is the shorter version of why regulated teams buy the hardware. The privacy boundary and operator security pages go deeper on what each layer can see and how credentials are handled, and the HIPAA reference carries this material in a form you can send straight to a reviewer.

B3IQ is operated by NPC Labs, Inc. BAA requests, security questionnaires, and compliance questions go to the address below.