AI for medical software — without giving your data away
We build AI into medical and healthcare products using open-weight models on private, SOC 2 Type II-attested infrastructure. Your PHI stays inside your boundary and never trains a third-party model — designed under the same regulatory frameworks that govern medical-device software.
Why medical teams can’t use public AI APIs
The objection to consumer LLM services is threefold — and each one has a concrete architectural answer.
PHI leaves your boundary
Public LLM APIs send your prompts — and any patient data in them — to a third party you do not control.
We run open-weight models inside infrastructure you control or that is contractually isolated (self-hosted, VPC, or a single-tenant endpoint), so sensitive data stays within a defined boundary.
Your data trains their model
With many consumer AI services, prompts and outputs can be used to improve the vendor’s model.
Open-weight models you host — or vendors with explicit no-training defaults — mean your prompts and PHI are never folded into a public model.
Uncontrolled retention
You can’t prove what was stored, for how long, or who could see it.
We design for zero or known retention, encryption in transit and at rest, least-privilege access, and access logging — an auditable, defensible chain.
Private by architecture, not by promise
We deploy open-weight models where your data-privacy posture demands — and we’re model-host-agnostic, so you’re never locked to one vendor.
Self-hosted / on-prem
Open weights run inside infrastructure you or we control. PHI never leaves the boundary to any inference SaaS. Maximum control.
VPC / private connectivity
HIPAA-eligible managed platforms (e.g. AWS Bedrock via PrivateLink) under a signed BAA, with no public internet exposure.
Dedicated / single-tenant
Logically isolated inference (e.g. Fireworks AI dedicated workloads, Azure OpenAI, Together) with no cross-tenant access.
The same open-weight models can run on SOC 2-attested inference (e.g. Fireworks AI, Together AI) or, for projects that involve PHI, on HIPAA-eligible platforms under a Business Associate Agreement (AWS Bedrock, Azure OpenAI) — or fully self-hosted with vLLM. PHI never trains a public model in any of these configurations.
Built under medical-device frameworks
AI in a regulated product is not a bolt-on. We build AI features under the same regulatory frameworks that govern medical-device software — so the model is part of a validated, auditable system, not an unmanaged black box.
Read: the IEC 62304 lifecycleIEC 62304
The medical device software lifecycle — AI features are software items developed under the same controlled process.
ISO 14971
Risk management for the AI’s failure modes, with AAMI CR34971 guidance for applying it to AI/ML.
Good Machine Learning Practice
The 10 GMLP principles (FDA / Health Canada / MHRA): representative data, independent test sets, human-AI performance, monitoring.
FDA TPLC & PCCP
Total-product-lifecycle thinking, and architecting change management to fit a Predetermined Change Control Plan (final guidance, Dec 2024).
Private AI for Medtech: FAQ
Does our patient data (PHI) leave our environment or train a public AI model?
No. We run open-weight models on private or dedicated infrastructure — self-hosted or in a logically isolated, BAA-backed deployment — so prompts and PHI stay inside a controlled boundary and are not used to train any third-party model.
Are you "HIPAA compliant"?
HIPAA compliance is an organizational obligation, not a product feature — no software or vendor is "HIPAA certified." For engagements that involve PHI, we build on HIPAA-eligible infrastructure (such as AWS Bedrock or Azure OpenAI) with the required Business Associate Agreements in place, and design to support your HIPAA program.
Is your infrastructure SOC 2 certified?
SOC 2 is an independent auditor’s attestation, not a certification. We build on SOC 2 Type II-attested infrastructure — meaning controls were verified as operating effectively over a defined period — and can provide the relevant reports under NDA where applicable.
How do you keep an AI model from "hallucinating" in a clinical setting?
We treat the model as part of the device’s mechanism of action: we constrain scope to the intended use, keep a human in the loop on clinical decisions, validate against representative data, and monitor for data drift after deployment — following FDA lifecycle guidance and Good Machine Learning Practice.
How is the AI validated and verified?
We apply medical-device V&V: risk management under ISO 14971, software lifecycle process under IEC 62304, independent training and test data, testing under clinically relevant conditions, and post-deployment performance monitoring per GMLP.
Will we be locked into one AI vendor?
No. Our designs are model-host-agnostic: the same open-weight models can run on a HIPAA-eligible managed platform under a BAA (AWS Bedrock, Azure OpenAI, Fireworks, Together) or fully self-hosted — so you can change hosts or bring it in-house.
Can changes to the AI be made without a new FDA submission?
For regulated devices, FDA’s Predetermined Change Control Plan (finalized December 2024) lets manufacturers pre-authorize defined future modifications in the initial submission. We architect change management to fit a PCCP: description of modifications, modification protocol, and impact assessment.
What can you give our auditors or security team?
Encryption in transit and at rest, least-privilege access controls, access logging, documented data-handling and retention, references to the underlying infrastructure’s SOC 2 Type II attestation, and — for PHI engagements — Business Associate Agreements across the subcontractor chain.
Have a private AI use case?
Tell us what you’re trying to build. We’ll map a deployment that keeps your data inside your boundary and fits your regulatory program.
Start the Conversation