Where does our data go when we use an AI vendor?

It depends on the model. On a vendor platform, your data leaves your environment to be processed and often stored outside your control. In a forward-deployed engagement the system is built in your own cloud, so the data never has to leave your accounts.

What is the difference between data residency, retention, and training?

Residency is where the data physically lives. Retention is whether the vendor keeps a copy. Training is whether your data is used to improve a model. They are three separate questions, and a safe answer covers all three: your cloud, no retention, no training.

Why do enterprises care where AI runs?

Because data leaving your environment triggers data-processing agreements, residency and sovereignty checks, and subprocessor assessments, each a gate in procurement. Keeping the system and the data in your own cloud removes most of those gates rather than negotiating them.

Can an AI system run entirely in our own cloud?

Yes. The system, the models it calls, the prompts, and the data can all run on your infrastructure and identity. That is the default in a forward-deployed engagement, not a premium add-on.

Does your AI run in your cloud?

The short answer

Ask where the system runs and where the data lives before anything else. In a forward-deployed model both answers are your cloud: the system runs on your infrastructure, your data stays in your accounts, and it is never used to train a model. Residency stops being a negotiation because nothing leaves.

"Where does our data live?" is the question that quietly decides most enterprise AI purchases. It sounds like a compliance formality. It is really asking whether the whole engagement is safe, and most AI vendors answer it in a way that starts a negotiation instead of ending one.

The question behind the question

When a security or procurement team asks where your data goes, they are not collecting trivia. They are deciding how much of your risk register this vendor is about to occupy. "Our cloud" from a vendor means your data crosses into an environment you do not control, and every downstream question follows from that one fact.

Three properties, not one

"Where does it live" is actually three questions, and vendors blur them:

–Residency. Where the data physically sits, and under which jurisdiction.
–Retention. Whether the vendor keeps a copy after processing, and for how long.
–Training. Whether your data is used to improve a model, for you or anyone else.

A confident answer covers all three plainly: your cloud, no retention, no training. An answer that covers only one, or covers them in adjectives like "anonymized" and "enterprise-grade," is the tell that two of the three are unresolved.

Why it is the procurement gate

Every question in the review descends from where the data lives.

Data leaving your environment is what triggers the machinery: data-processing agreements, residency and sovereignty checks, subprocessor assessments, breach-notification chains. Each is a gate, and each takes weeks. Keeping the system and the data inside your own cloud does not pass those gates faster. It removes most of them, because the condition that opens them never occurs. That is the same logic as ownership as the security posture, applied to data specifically, and it is the first thing a vendor security review should establish.

How forward-deployed handles it

A forward-deployed engagement builds inside your infrastructure from the first day: your cloud, your identity and access controls, the model providers you already approve. The data stays in your accounts, the vendor keeps no copy after handover at handover, and it trains no model. Residency, retention, and training are answered by the architecture, not by a clause you have to trust. For an enterprise team, that is the difference between a months-long review and a short one. The full posture is on the enterprise page.