Your AI Works in the Cloud. Your Job Might Not.

The assistant worked beautifully upstairs. Then the job went two floors underground.

Picture Dana, a building-services technician, heading into a plant room to inspect an air-handling unit. The controller has a faded label, and it is not a model she knows well. Her phone has an assistant that could help read the label, find the matching documentation and draft a note for the job record.

At the bottom of the stairs, the mobile signal disappears.

The phone still has a camera. Dana still has a job to do. What happens to the assistant?

That depends on decisions made well before she reached the stairs: where the model runs, where the information lives, and what else the application needs before it can do anything useful. An architecture diagram rarely draws the basement.

A fictional job, not a deployment case study. Dana, the building and the equipment are invented to explore the design choices. The assistant is helping with information and records, not authorising repairs or controlling machinery.

Three places to do the thinking

Before we get into the architecture, here is what those terms mean for Dana. A model is the AI software doing the processing: reading the photograph, interpreting a request or drafting an answer. It has to run on a computer somewhere.

On her phone — on-device AI. The phone does the processing itself. It is not simply showing an answer that came back from somewhere else. With suitable hardware, an installed model and the right application, some tasks can work without an external connection.

In the building — site-edge AI. The phone sends the request to a server or appliance nearby, such as one at the same site. This is one form of edge computing: bringing the processing closer to where the information is collected or the work happens. Dana still needs a working connection to that server, perhaps through the building's Wi-Fi.

In a provider's data centre — cloud AI. The phone sends the request over a network to a hosted service, which processes it and sends an answer back. The cloud still involves computers; they are somewhere else. It can provide access to more compute without putting that hardware on every phone or at every site.

The distinction is where the work is being done. Looking at an answer on a phone does not tell us where it was produced.

You will sometimes see on-device processing included under the broader term edge computing. For this story, I will call the phone on-device, the nearby shared server site edge, and the remotely hosted service cloud.

None of those names tells us whether the answer is correct, the information is private or the job can continue without a connection. That depends on how the whole thing has been built.

I would rather find that out before anyone is standing in front of the equipment.

On her phoneOn-device AI

In the buildingSite-edge AI

In a provider’s data centreCloud AI

Follow the job, not just the model

Dana's request sounds simple: help me identify this controller and record what I found. Underneath it are at least five different tasks.

1. Read the label. Capture a usable image and extract the text. Poor light and a damaged label can defeat a capable model.
2. Identify the equipment. Match that text against a maintained catalogue. A plausible model number is not a verified identity.
3. Find the right document. Retrieve an authorised procedure for that equipment and configuration, with enough information to know whether it is current and applicable.
4. Draft the observation. Turn Dana's notes into a useful description she can check.
5. Record the work. Save the note and photograph, then have the business's job system accept the update.

Those tasks do not all have to run in the same place. They also do not all need AI. A catalogue lookup, a version check or a reliable upload queue may matter more than another model call.

Recognising text on a phone is one candidate to test. The equipment catalogue might be synced to that phone, available over the building network or reachable only through a hosted service. The approved procedure may live somewhere else again.

This is where “we have a local model” stops being a complete answer. Can it reach the information it needs? Is Dana allowed to use it? And what happens when the answer is uncertain?

The useful unit of design is the job and its dependencies, not the model in isolation.

Now take the connection away

First, which connection? Mobile coverage, the building's Wi-Fi, the site's internet link and access to the cloud service are different things. Losing one does not necessarily mean losing all of them.

For this example, Dana cannot reach the hosted assistant from the plant room. A site-based alternative is available only if the local network still connects her phone to it.

If the application needs an answer from the remote cloud service, it cannot answer that request while the service is unreachable. Dana might still capture a photograph or save a note locally, but only if the application supports it. Offline capability has to be part of the design.

This is familiar territory in field-service software. Microsoft's Field Service mobile documentation describes access to work data after an administrator configures offline capabilities. It also distinguishes that from its refreshed mobile experience, which currently does not support offline work. The lesson is to check the actual application and configuration, rather than assume that “mobile” means “works without a signal”.

If the model runs on the nearby site-edge server, some work could continue over the local network. But the model, the relevant catalogue, the documents and the required access checks all need to be available. A login service or document store reached through the internet can still interrupt a supposedly local job.

AWS Outposts provides one documented example of that distinction: software already running at the site can continue during a disconnection, while management functions and services that depend on its remote cloud infrastructure are affected. That is a property of that architecture, not a rule that every edge server loses local management when the internet drops.

If the model runs on Dana's phone itself, it could help with tasks supported by that device and its available information. It cannot retrieve a procedure that was never downloaded. It cannot make an expired copy current by summarising it confidently. Recognition and drafting still need to be checked, especially when an incorrect equipment identity could send someone to the wrong instructions.

And the record? An offline application might hold a durable local copy and queue it for synchronisation. That is valuable. It is still different from the job system having received and accepted the update. Someone needs to handle failures, duplicates and conflicting changes when the connection returns.

“Saved on the phone” and “recorded against the job” should not be two labels for the same unverified promise.

The information has to travel too

The model's location is only part of the privacy decision.

A phone can process an image locally while its application sends logs or backups elsewhere. A site server can call a hosted service. A cloud service may operate in an approved location under specific controls. The words local and cloud tell me where to start asking questions, not whether the design is acceptable.

For Dana's job, I would want to know what the photo contains, where it can go, who can access it, how long it is retained and what happens to the copy waiting on her phone. If the image includes a person or identifying information, the privacy question changes. Commercial and site-security restrictions may matter even where personal information is absent.

Australian organisations covered by the Privacy Act also need to consider the rules for overseas disclosure of personal information. The OAIC's guidance explains the reasonable-steps requirement, alongside exceptions and the distinction between using an overseas service and disclosing information to it. That needs to be assessed for the actual arrangement; it is not a blanket ban on cloud processing.

Dana should not have to resolve all of that from a plant room. The organisation should have decided the permitted data routes, device protections and access rules before offering her the assistant.

Someone has to keep it working

The model bill is the visible part. The operating responsibilities are easier to leave off the slide.

On a small screen, scroll the comparison sideways. These are design questions, not capability guarantees.

These are questions for this fictional design, not measured comparisons or guarantees. The application and its dependencies decide the answer.

An existing supported phone might make a small trial straightforward. A mixed fleet can make standardisation harder. A site service introduces equipment and lifecycle work, whether you own the hardware or buy it as a managed service. A hosted model moves some of that responsibility to a provider, but it does not manage the whole job on your behalf.

There is no universal cheapest option in that list. I would compare the cost and effort of completing the useful job, including the occasions when something fails, rather than just the cost of the model answering.

Saved on the phoneWaiting to sync

Accepted by the job systemReceipt confirmed

Decide what can wait, and what must stop

For Dana, I would investigate a design that lets her capture the photo and draft an observation without an external connection. Identification assistance could be useful if it has been tested on the actual devices and makes uncertainty clear. It should not guess its way into a maintenance instruction.

The correct documents could be prepared ahead of a visit, with explicit version and freshness rules. If a required check cannot be completed, the equipment cannot be identified confidently or the available procedure is unsuitable, that part of the work waits or follows the authorised human escalation route.

The application could hold the record safely and synchronise it later, making the difference between pending and accepted visible to Dana and the team.

That might produce a mixed design: some processing on the phone, some information available from the site, and a hosted service for other tasks. A fully local design might also be appropriate. So might a cloud-first design for work that can safely wait. The choice follows the job, the risks and the operating requirements.

Then I would test the awkward bits: lose the signal, make a dependency unavailable, present a poor image, let a cached document expire, and check what happens when the queued record is finally sent. Does the application make its limits clear? Can the person continue, ask for help or stop safely?

That takes the network article's question a little further. We need to know what work we are making dependent on a connection, but also which parts genuinely need that connection and which we could design differently.

Another model on a phone is interesting. A person who can still do useful, authorised work when the connection drops is the outcome worth designing for.

If the next job went two floors underground, which parts would keep working—and would that be by design or by luck?

Optional sources and related reading

Public documentation checked on 8 November 2026. Features and limitations describe the cited products; they do not demonstrate Dana’s fictional job working.

• AWS — edge inference, including on-device processing
• Cisco — processing close to the source
• Android Developers — Gemini Nano, local processing and device constraints
• Microsoft Learn — Foundry Local
• Microsoft Learn — Field Service mobile and configured offline capabilities
• AWS — Outposts network-disconnection behaviour
• OAIC — APP 8 cross-border disclosure guidance, including limits and exceptions

Earlier VNI articles:

• AI Is Leaving the Screen. What Happens When It Comes to Work?
• The Network Still Matters. AI Just Makes It Harder to Ignore.