
Ship your product. Skip the year of becoming a regulated data company.
You have the product and the model. What stands between them and a real patient is a compliance operation you did not set out to build. It already exists here: BAAs executed, PHI held compliantly, device data flowing, and everything your product sends checked before it reaches anyone.
None of this is your product. All of it is required.
The first patient is where a health product stops being a software problem. Everything below has to exist before that happens, none of it is what you are differentiated on, and all of it has to keep existing afterwards as the rules move.
- +A BAA with every model provider you touch
- +PHI held somewhere a hospital's security review will accept
- +SOC 2, and then keeping it
- +Device data arriving clean, from hardware you did not build
- +A policy on what your product may say to a patient
- +An audit record that still answers questions a year later
It is roughly a year and a team, and at the end of it you are running a regulated data business alongside the product you meant to build.
Bring the part that is actually yours.
Your model
A trained model goes into your own registry as ONNX, versioned and content-hashed on upload, enabled per program. It executes inside our boundary rather than pulling data into yours, so patient data never reaches your infrastructure. Signal processing arrives the same way, as signed WASM.
Your agent's behaviour
You author what it does: the prompt, the trigger, the data it sees, the rules it cannot break. There is nothing to deploy and no second compliance environment to run. BAAs with the model providers are already executed.
Your product
Your app, your brand, your users. The SDK goes into the app you already ship, or you use ours if a patient-facing surface is not what you want to build.
One honest distinction. A model is portable and genuinely moves: upload it and it runs. An agent is not a file, here or anywhere else, so what moves is the behaviour you define rather than a container you hand over. In practice that means less work, not more.
Your code runs where the data already is.
Patient data is captured, held and governed on our side of the boundary, and your model executes there rather than receiving an export. That is the mechanism behind never taking custody: there is no copy of the patient data in your environment to secure, to breach, or to explain to someone's security review. What comes back is your model's output, carrying the version that produced it, delivered wherever the program needs it.
YOUR DEVICES
CLINICAL SYSTEMS
SIGNAL CAPTURED
GOVERNED ENVIRONMENT
YOUR MODEL RUNS IN-PLACE
CHECKED BEFORE IT SENDS
INTO YOUR PRODUCT OR THE EHR
YOUR DEVICES
CLINICAL SYSTEMS
ReflectProprietary models on the rails, in production.
Reflect is building skin intelligence, predicting and preventing breakouts by understanding how skin changes over time. Skin data is complex, deeply personal, and requires privacy-first handling from the start. Using AnyBio, Reflect uploaded their proprietary ML models, ran them on AnyBio-structured image data, and integrated the SDK, without standing up the regulated pipeline themselves. Their models run on the rails in production today.

What this does not do for you.
It does not make an unvalidated model validated, and it does not decide your regulatory path. If what you are building is a medical device, it is still a medical device running here, and that is your clearance to hold. What changes is that you are not also building the data operation underneath it while you sort that out.
It also does not turn wellness-grade data into clinical-grade data. Where a signal came from travels with it, and the lane it belongs in travels with it too. The line between those lanes is drawn here, and it is enforced rather than described.
Tell us what you are building. We will tell you what you would not have to.
Bring the product you have and the model if you have one. We will walk through what runs here, what stays yours, and what you would otherwise be spending the next year on.
