When should AI work stay local, and when can it use the cloud?

When AI tools start choosing between your computer and the cloud for you, the question gets very plain: which data is allowed to leave the room?

Perplexity describes the next step for Personal Computer as a hybrid local-server AI orchestrator. The idea is that a smaller local system decides which parts of a task should stay on the device, while heavier work can be routed to stronger cloud agents. Perplexity says the local inference version is coming in July, so this is not something every team can enable today. It is an early signal of where work AI is going.

Source: Perplexity, "The Data Center Moves to Your Machine"

For Hammer Automation readers, the point is not to wait for a perfect automatic router. The point is to write your own rule first. A local/cloud AI policy is a simple agreement about which tasks should run close to the user, which tasks may use cloud services, and which human must approve before sensitive material moves.

What "local first" means in practice

Local first does not mean everything must run on a laptop. It means the workflow starts with one question: is there raw data here that should not be sent onward?

That might be customer contracts, financial reports, student material, health-related details, HR notes, board documents, or files where nobody is quite sure who is allowed to read what. If the answer is yes, the AI work should either stay in an approved local environment, run inside a company-managed tool with the right data boundaries, or be changed, so the cloud model only receives a cleaned summary.

The important part is that this should not be decided inside the prompt every time. It belongs in the workflow.

The cloud is not forbidden, but it needs a reason

Cloud models are still useful. They can be better at hard analysis, longer reasoning, source search, coding, image work, and tasks where local hardware is not enough. But you should know why the cloud is being used.

A reasonable decision pattern looks like this:

• Run locally or in an approved internal environment when the task includes raw personal data, finance, student data, health information, contracts, or internal conflicts.
• Send work to the cloud when the task needs a stronger model and the material is anonymized, already approved for that tool, or safe to share under policy.
• Ask for human approval when the AI itself suggests moving a task from local processing to cloud processing.
• Log the decision when the workflow is repeated, customer-facing, or business critical.

This does not need to become a long document. One page is often enough to prevent the obvious mistakes.

Three vendor signals that make the policy more urgent

Perplexity's local/cloud routing is the clearest signal, but it is not the only one. Several vendors are moving AI from "answer in chat" toward "run work inside an environment with rules".

Google says in Gemini Enterprise release notes that Gemini 3 Pro Image and Gemini 3.1 Flash Image are now GA in the Gemini Enterprise app, but they are off by default and only available in the Global region. That is a reminder that model choice is also an admin and data question, not just a creative feature.

Source: Google Cloud, Gemini Enterprise release notes feed

OpenAI changed billing on June 2 for some container sessions: eligible sessions are billed per minute with a five-minute minimum instead of the full twenty-minute session rate. That sounds like a pricing detail, but for agent workflow design it means runtime, waiting time, and idle time belong in the design.

Source: OpenAI API changelog

Anthropic added two practical Claude Platform details the same day: the advisor tool can have its own max_tokens cap, and some refusal responses with no generated output are not billed. The signal is down-to-earth here too: cap what the tool can produce, measure cost, and build stop rules.

Source: Claude Platform release notes

A simple local/cloud AI policy

Start with seven lines. Write them for one real workflow, not for the whole organization's AI strategy.

• Data: Which data can appear in the task? Use examples, not abstract labels. "Customer contracts from Drive" is better than "confidential".
• Local rule: What must always stay local or inside an approved internal environment?
• Cloud rule: What may be sent to a cloud service, and under which conditions?
• Cleaning: Which fields, names, personal identifiers, amounts, or filenames must be removed before the AI gets cloud help?
• Approval: When should the user get a clear question before anything leaves the device or workspace?
• Region and admin: Is the model, feature, and data handling available in the right region with the right admin settings?
• Receipt: Where do you log the decision, cost, and result if the workflow runs again?

This is also a good first step for a Mindset Forge or Tool Forge session: pick one real workflow, such as meeting notes to tasks, customer material to quote draft, or finance file to summary, and draw where the data may move.

Quick answer: when should AI work stay local?

AI work should stay local when the task includes raw personal data, financial material, HR content, student or patient-like information, board documents, private files, or anything else where you cannot explain who is allowed to read it and why.

AI work may go to the cloud when the material is already approved for the tool, cleaned of sensitive details, needs a stronger model, and the user understands what is being sent. If you cannot answer those four points, it is better to pause than to hope the vendor default solves it.

Start with one workflow, not a policy workshop

Pick a recurring job that already causes friction. Maybe a weekly report. Follow-up after customer meetings. Research before a board meeting.

Then map the workflow:

• What does the AI read?
• What may the AI write?
• What must stay local?
• What may go to the cloud?
• When does the AI ask the human?
• Who owns the result?

If the map is hard to fill in, you have found the problem. Not that the AI is too advanced, but that the workflow has fuzzy boundaries. That is fixable. And it is much cheaper to fix before the agent starts moving data for you.