The short answer
It should go wherever your rules say it can go and nowhere else. Build in your own environment by default. Where a third-party model is genuinely the right tool, you should be told which one, what leaves your network, what the provider retains and for how long — and sign that off before anything is built.
The default
Build in your environment. Your accounts, your storage, your credentials. Most automation touches no external model at all — it moves data between systems you already run and already trust, and there is no reason to introduce a third party to do it.
That default matters because it makes the exceptions visible. When something genuinely does need to leave your network, it should be a decision you made rather than an implementation detail you discover later.
The questions to ask before anything is built
Ask them of any consultant, any vendor, any tool.
- Which specific provider and model? Not “an AI” — a name and a version.
- What exactly leaves the network? The full document, or a field? Customer names, or an anonymised reference?
- Is it retained, and for how long? Enterprise and API tiers usually differ sharply from the consumer product of the same name. The difference is often the entire answer.
- Is it used for training? Frequently a setting rather than a fixed fact, and frequently set wrong by default.
- Which country does it sit in? This is the one that quietly breaks projects late.
- What happens if I want it deleted? And how would I confirm it was.
If those answers are not in writing before the build, they are not commitments.
When data cannot leave the country
Design for it from the start.
Residency is not a setting you switch on at the end — it changes which providers are available, which regions you deploy into, and sometimes whether a model is part of the design at all. Discovering that constraint in week six means redoing weeks one to five.
It is also survivable more often than people expect. Every major provider now offers regional deployment, and a good number of workflows do not need an external model in the first place. The constraint narrows the options; it rarely closes them.
The part people skip
Whoever builds your system should not be holding your credentials afterwards.
This gets waved through as a convenience and it is the single most common way a small business loses control of its own process. If access to your customer data depends on an external consultant’s account remaining active and their goodwill remaining intact, that is not an automation arrangement, it is a dependency.
Everything should run under accounts you own, in an environment you can reach, with keys you can rotate the day the engagement ends. If you cannot revoke someone’s access without breaking the system, the handover was never finished.
Last updated 18 August 2026 by Hugo, founder of Hugo Signal.
Bring me the process that wastes the most time.
A first call takes thirty minutes. You will leave it knowing whether automation is worth doing at all in your case.