Where the model came from and where your data goes are two different questions

The question used to arrive from the technology side of the house. This year it is starting to arrive from the other direction: a due-diligence questionnaire from a limited partner with a new section on AI and data handling, a compliance function asking where, precisely, the firm's AI tools send client data, a non-executive who has read something alarming about Chinese models and wants reassurance before the next board meeting.

I have spent twenty years inside large organisations watching how questions like this get handled, and this one usually arrives as a single anxious lump: whose model is this, and where does our data go?

Those are two different questions. They have different answers, different owners and different remedies, and most of the bad AI procurement decisions I have watched over the past two years trace back to treating them as one.

The encouraging part is that separating them takes about a page. Once they are separated, most of the anxiety resolves into a placement decision a leadership team can defend in the LP meeting, in the audit, and in front of its own engineers.

What is the difference between model provenance and data residency?

Provenance asks where the model came from: which lab trained the weights, in which jurisdiction, under what licence, with what visibility into how it was built. Residency asks where the model runs: whose infrastructure performs the work, and therefore where your data travels when the model processes it. The first is a question about the artefact. The second is a question about your boundary.

They are independent. A model with impeccable Western provenance can process your data on infrastructure you will never see. A model of foreign origin can run entirely inside your own cloud account and send nothing anywhere. Every combination of the two exists and is commercially available today.

The market has collapsed them into a single question, usually phrased as "is it safe", and the collapse does real damage in both directions. I have watched a compliance function spend weeks interrogating the nationality of a model's training lab while the same firm's client data flowed daily through a third-party API nobody had mapped. I have watched the opposite too: a blanket ban on open-weight models, imposed on origin grounds, applied to a design in which no data would ever have left the building. Both decisions felt rigorous. Both were answers to the wrong axis.

Weights are files, and files do not send data anywhere

An open-weight model is, in the end, a very large file. Run that file on infrastructure inside your own boundary, your own cloud tenancy or your own hardware, and it sends nothing back to the people who made it: not your prompts, not your documents, not usage telemetry. That holds whatever the file's origin. A Chinese-origin open model running on European hardware inside your boundary sends nothing to China, for the same reason a spreadsheet does not post itself back to its author when you open it.

What remains of the provenance question at that point is real, but it is a different kind of question. Licence terms need reading by someone qualified to read them. Alignment is partly opaque: you cannot fully inspect how a model was trained to behave, so you test the behaviour you care about rather than trusting the label. And there are optics, which I will come to, because for some firms they decide the matter on their own.

What does not remain is a data-flow problem. If someone tells you a locally run open model is leaking data abroad by virtue of its birthplace, they are describing a machine that does not exist. I am not recommending foreign-origin models for regulated work; for most of the firms we advise I would counsel against them, for reasons that have nothing to do with data flow. The point is precision. A board that bans the file while ignoring the boundary has not reduced its risk. It has relocated its attention.

A Western frontier API is still a residency decision

The conflation cuts the other way as well, and this direction is the expensive one, because it hides inside what feels like the safe choice.

When your teams use a frontier model through the vendor's own API, your data leaves your boundary. It is processed on the vendor's infrastructure, in the vendor's tenancy, under a contract. The provenance could not be more reassuring, and the residency position is still this: our client data is processed on somebody else's computers. For most firms and most classes of data that is fine, and I want to be plain about it. The contracts are real, the security work at the major labs is serious, and treating every vendor API as a breach in waiting is its own kind of carelessness.

But "fine for most data" is a conclusion you are entitled to only after you have asked the question for each class of data you hold, and many firms have never asked it once. Fund accounting records, LP personal data, portfolio-company financials inside a live deal window: whether those may be processed outside your boundary, and under what terms, is a decision your regulator and your investors expect you to have made deliberately. "The model is American" is not an answer to that question. It was never the question.

Where should a regulated firm actually run AI workloads?

A regulated firm can run AI workloads in one of four places, ordered by how much of the data boundary the firm controls, and for most the realistic centre of gravity is the third.

The first is the hosted open-weight API: capable open models served cheaply from someone else's cloud. The second is the frontier API: the strongest models available, on the vendor's infrastructure, under contract. Both are perfectly defensible for work on data that is cleared to travel, and both are residency decisions in the sense that matters, because in both your data leaves.

The third is the same frontier capability running inside your own boundary. The hyperscaler platforms, AWS Bedrock and Google Vertex being the recognisable routes, serve frontier models inside your own cloud account and region, with contractual commitments that your data is not used for training. The reason this tier matters is not technical elegance. It is that the boundary it creates is one your auditors already understand: a named cloud account, in a chosen region, inside controls you already attest to every year. For private equity, fintech and legal work it is the realistic default. You pay a modest premium, the newest releases arrive slightly later, and what you buy is an answer that survives the second question in the meeting.

The fourth, genuinely sovereign inference, means open weights on infrastructure you control. It is real, and it is narrow. You buy it for the boundary, never for the bill: the economics only make sense at high, sustained volume, and running model-serving infrastructure is a serious operations discipline, easy to underestimate and hard to staff. Some data genuinely should never leave, and the workloads that touch it belong here. Most firms hold far less of that data than they think.

Two cautions about the ladder. Price picks a model within a tier; it must never pick the tier. And before price moves anything anywhere, the boring housekeeping comes first: my co-founder Andy has written about the five things to do before you switch AI models, and every one of them pays for itself before any new trust decision is required.

Optics are a third axis, and they belong on the record

There is a version of this analysis that stops at the technical truth, and it tends to get its author into trouble, so let me add the axis the engineering conversation usually leaves out.

For a fund that answers to limited partners, "we run a Chinese model" can be reputationally wrong even where it is technically clean. The data flows nowhere, the licence is workable, and the sentence still lands badly in a room whose trust you cannot afford to spend. I have given the same advice more than once, in almost exactly these words: defensible on paper, indefensible in the LP meeting, do not do it.

The governance rule that follows is easy to state. Provenance and residency are explicit, recorded decisions, taken for each class of data, by somebody with the authority to take them, and neither is ever left as a silent default inside a routing layer or a supplier's configuration. In my experience boards will forgive a considered decision that ages badly. What they will not forgive is discovering that a decision this visible was made by nobody, on no particular date, for no reason anyone wrote down.

What does a clean answer look like?

A clean answer takes the shape of a single table. Your classes of data down the side. Two questions across the top: may this class leave our boundary, and under what terms; and separately, whose weights are we comfortable running on it, and who signed that off. Each class placed on the map above, with a name and a date against the placement. That single artefact is worth more in a diligence exercise than any amount of vendor reassurance, because it shows the two questions were separated and actually decided.

We answered them for our own agent fleet before advising anyone else. Most of our own workloads run against a frontier vendor under contract, and that is a recorded residency decision, made with our eyes open, not an accident of whichever tool arrived first. The point is not where we landed. The point is that the decision exists, in writing, and we can defend it line by line.

The honest version of the effort involved: building that table takes one focused sitting and a leadership team willing to be specific. What follows it, the contracts, the VPC plumbing, the evaluation gates that make any later move safe, is real work, measured in months. But that sitting comes first, it costs nothing, and it converts one anxious question into two answerable ones. That is the moment this stops being a source of board-level worry and becomes what it should have been all along: a placement decision, owned, dated and written down.