Most AI vendors selling into healthcare want one thing before anything useful happens: a copy of your data. Charts, claims, scheduling history, the free-text notes where the real signal lives. It flows out of your environment, into theirs, and from that moment forward your patients' protected health information is sitting in a system you do not run, cannot inspect, and will spend the next audit cycle trying to account for. We think that trade is backwards. The agent should go to the data. The data should not go to the agent.
The SaaS data problem
The standard SaaS pattern is extract, then process. You connect an integration, the vendor pulls records into their multi-tenant platform, and the work happens there. It is convenient, and for a lot of software it is fine. For PHI it quietly creates a second copy of your most regulated asset in an environment whose controls you have to take on faith.
That copy is not a footnote. It is a real expansion of your attack surface and your liability. Every place PHI lands is a place that can be breached, subpoenaed, mis-configured, or retained longer than anyone intended. When a vendor has your data, their incident becomes your breach notification. Their access review becomes your finding. You inherit the consequences of decisions you never saw made.
- You lose the ability to answer a basic auditor question: where, exactly, does this data live, and who can read it.
- You depend on the vendor's word about retention, deletion, sub-processors, and training. Most healthcare leaders cannot enumerate the sub-processors three layers down their AI vendor's stack.
- Offboarding becomes an act of faith. You can revoke a login, but you cannot prove the copies are gone.
The alternative: agents that run where the data already is
Segment360 builds and operates agentic AI inside your own cloud account, GCP, AWS, or Azure. The agents run in your tenant, in your VPC, against your data, under your logging. We do not stand up a separate platform and pull your records into it. There is no "our environment" for your PHI to live in, because the work happens in yours.
Concretely, that means the model and the orchestration sit next to the data they operate on. A note gets summarized, a recall list gets built, a follow-up gets drafted, all without that information crossing your network boundary. The output stays in your systems too. Nothing is copied out to us as a byproduct of the work, and nothing is retained on our side, because there is no our side in the data path.
How the boundary is actually enforced
"It runs in your cloud" is easy to say and easy to fudge. Here is what makes it real, control by control:
- Deployment in your tenant and VPC. The compute, the agents, and any intermediate state run inside infrastructure you own and pay for. Network egress rules are yours to set, and you can lock the workloads so they cannot phone home.
- No PHI copied to us. We operate the system, but the regulated data does not leave your boundary to do so. Our people work against your environment through controlled access, not by exporting your records into ours.
- Least-privilege, client-granted, revocable IAM. Every bit of access we hold is a role you create in your own identity system, scoped to exactly what the work requires and nothing more. You grant it. You can read it. You can pull it in one click without a support ticket or a waiting period.
- Full audit trail in your own logging. Because everything runs in your cloud, the record of what happened lands in your audit logs, Cloud Logging, CloudTrail, or Azure Monitor. You are not asking us for a report on our system. You are reading your own.
- A kill-switch you control. If you want the agents to stop, you do not file a request. You revoke the role or disable the workload, and the system halts because the access it depended on is gone. Control of the off button is the clearest test of who really owns the boundary.
- We sign a BAA. Operating on PHI means standing behind it contractually. We are a business associate, and we put that in writing.
Why this is a cleaner compliance boundary
The reason this architecture matters is not philosophical. It collapses a sprawling, vendor-dependent risk question down to something you can actually reason about. When your data never leaves, the scope of who-can-touch-PHI is defined by IAM roles you control, in an account you already audit, with logs you already keep.
That changes the nature of every hard conversation. A risk assessment stops being an investigation into someone else's infrastructure and becomes a review of permissions in your own. A breach question stops being "what does our vendor have" and becomes "what does our IAM allow," which you can answer from your console. Data residency, retention, and deletion stop being promises in a contract and become facts about systems you operate. The blast radius of working with us is bounded by access you can revoke, not by trust in a black box.
It also fits the principle behind everything we build. Signal Detection, Deep Exploration, and Strategic Resurfacing all run better when the agent can sit close to the full, current data rather than a stale extract someone shipped to a vendor last quarter. Keeping the work in your cloud is not only safer. It is how you see beyond the surface without making a copy of the surface first.
Compliance posture is set by architecture
We want to be precise here, because healthcare is exactly the place where vague claims do damage. The control objectives the major frameworks care about, such as least privilege, segregation of access, full auditability, data minimization, and a clear ownership boundary, are built into this architecture from the start, not bolted on later.
That is the direct consequence of running inside your cloud instead of pulling your data into ours. And because the controls live in your own account, you do not have to take anyone's word that they exist. You can see them, enforce them, and audit them directly, against your own logs and your own access policies. For the formal compliance picture, our Trust Center is the source of record.
What this asks of you
This model is not free of obligations on your side, and we would be lying to pretend otherwise. Running agents in your own cloud means you own the IAM hygiene, the network rules, and the logging configuration that make the boundary real. That is the point. The controls live where you can see and enforce them. In practice the lift is modest: a scoped role, a place for the workloads to run, and a logging destination you almost certainly already have. We do the standing-up and the operating. You keep the keys.
Where this leaves you
The fastest way to lose control of patient data is to let it leave the building. The simplest way to keep control is to never let it leave in the first place. That is the whole bet behind operating agents inside your own cloud: the regulated data stays put, the access is yours to grant and revoke, and the audit trail is one you already trust because you wrote it. It is a posture you can verify yourself, today, in your own account.
If you want to see what this looks like against your real environment rather than a slide, that is what the 5-day Diagnostic is for. We map a concrete agent to your data, your cloud, and your constraints, and you come out the other side knowing exactly where the boundary would sit before anyone touches a record.