Most teams handling regulated workloads run into the same wall the first time they need a current-data answer from a local LLM. The local model has no internet. The cloud model has internet but cannot see the client data. The team’s options look like a forced trade: ship the data to the cloud model, or live without current data.
The trade is not forced. Separate retrieval from synthesis. Run the retrieval on a model with web access against the public-data part of the problem. Save the results to a local file. Then synthesize against the local file using a model that has the proprietary context but no access to the open web. Neither model ever sees both halves of the workload.
The Pattern
The mechanic is straightforward.
Phase one is retrieval. A web-enabled tool runs a small number of targeted queries against the open web. The output is plain text written to a local file. The queries do not contain anything sensitive: they are public questions about public-data topics (competitor landscape, current versions of open-source projects, recent regulatory guidance, what is at the top of a specific subreddit this month). The model behind the retrieval sees only the public queries. It writes only to the local file.
Phase two is synthesis. The synthesis model reads the local file along with whatever proprietary context the synthesis requires (client data, biosequences, internal proposal drafts, internal-only knowledge bases). It never touches the open web. The local file is the only “fresh” data it sees, so the raw web fetches never reach the model doing the integration.
The two phases never overlap. The retrieval model never sees the proprietary data. The synthesis model never sees the open internet. The local file is the only connection between them, and it is plain text that you can read.
The Compliance Case
The same architecture answers the compliance question for regulated bio, federal, and IP-sensitive workloads. The compliance team’s worry is not “can the model help us.” It is “does the model see data it should not see.” A web-enabled cloud model that gets handed proprietary context for an integrated query sees both, and the compliance team is right to flag it.
A split pipeline with public retrieval on one side and synthesis on the other answers the compliance question by construction. The web-connected model only ever saw public queries. The synthesis model only ever saw the file that model wrote, plus the proprietary context, and it never had web access of its own. Retrieval and synthesis stay separated, so the model reaching out to the open internet is never the same model holding the sensitive data.
The audit trail is also legible. The cloud-side requests are logged and contain only public information. The synthesis side runs against a model with no web access of its own, and its only inputs are the local file and the context you choose to hand it. The integration point is a plain-text file you can inspect, version-control, and redact if needed.
When This Pattern Fails
The pattern fails when the retrieval and synthesis cannot be cleanly split. If the synthesis requires the model to issue follow-up queries against the public data based on what the proprietary context says, the two phases are interleaved and you cannot separate them cleanly without exposing one side to the other.
In practice this is rare. Most workloads that look interleaved actually decompose into a public-question phase and a proprietary-integration phase if you spend a few minutes restructuring the brief. The cases that genuinely require interleaved retrieval are usually research workflows (e.g., literature search that depends on partial results to refine the next query), not consulting deliverables.
The pattern also fails when the synthesis model is too small to do the integration job. The synthesis model has to be capable enough for the integration task, which is a different constraint than network access.
Why This Is Cheaper Than the Alternative
Dispatching a single web-enabled cloud agent against an integrated brief costs roughly what a long cloud dispatch costs, which is non-trivial. The split pipeline costs a few short web queries plus one local synthesis dispatch. On token economics it usually works out cheaper, and the bigger win is the privacy property rather than the dollars.
The compounding benefit is that the local-file output of the retrieval phase is reusable. If next month you need the same competitor landscape against a different proprietary context, the retrieval already ran. Refresh the file with one or two new queries, run the synthesis against the new proprietary context, done. The fresh-data phase amortizes across uses.
The Framing
Cloud LLMs with web access are convenient because they collapse two jobs into one dispatch. The convenience comes with a compliance cost and a privacy cost that both bill in proportion to how sensitive the proprietary context is.
Splitting retrieval from synthesis trades the convenience for control. The control is what regulated workloads need. For the right shape of task, it is the version regulated workloads can actually put into production.