Watch the explanation. Practice the skill.
Local, cloud and frontier: separate the questions
Trace deployment, capabilities and complete data destinations.
Captions appear here during playback.
Local, cloud and frontier: separate the questions
Trace deployment, capabilities and complete data destinations.
Video playback is unavailable. Read the descriptive transcript below, go directly to practice, or open the video file.
Illustrated teaching example • Fictional data · Reviewed 2026-10-03. Microsoft Mark · locally synthesized. On a small screen, use fullscreen for diagram details or read the transcript.
Read the descriptive transcript
0:00 · Three labels do not describe a whole system.
Local, cloud, and frontier are not three mutually exclusive categories. Local and cloud describe deployment aspects. Frontier is a changing capability label. Licensing, connectivity, tool permissions, and organizational authorization need their own checks. Start with a system map rather than a reassuring label.
What appears on screen
Capability ≠ Location ≠ Licensing ≠ Authorization
0:25 · Separate the dimensions.
Ask which capabilities the task needs, where inference runs, what the license allows, and where the supporting services send data. A downloaded model can still have license restrictions. A hosted model may use local tools. A strong model does not automatically make a workflow appropriate for sensitive information.
What appears on screen
Capability: Task-specific quality and modalities Deployment: Where inference and tools run Licensing: Terms for this model and use Authorization: Approved data and complete boundary
0:49 · A local model can have remote dependencies.
In this fictional configuration, the interface and model run locally. The retrieval step calls a remote embedding service, and traces are uploaded to a cloud logging service. The local model label therefore does not establish that all information stays on the device.
What appears on screen
Local interface Local model Remote embeddings Cloud traces Illustrated configuration · not a tested product
1:09 · Trace every information destination.
Make a record of inference, connectors, embeddings, storage, telemetry, identity, and operator access. Check what information each component receives and retains. Credentials, backups, and administration also matter. If a destination or retention policy is unknown, treat that as an unresolved part of the review.
What appears on screen
Inference + tools: Inputs, outputs and destinations Storage + logs: Retention, backups and access Identity: Credentials and operator privileges Unknown destination: Resolve before sensitive use
1:35 · Choose for the actual task.
For public fictional practice, a simple chat tool or paper example may be enough. For restricted organizational work, use only a workflow authorized for that data and purpose. Local hosting, a clearance, or a product logo alone does not confer authorization. Keep unresolved sensitive work out of training examples.
What appears on screen
Fictional practice: Use supplied examples; minimize setup. Restricted work: Verify the authorized complete boundary. Training is not organizational approval.
1:59 · Find the hidden remote service.
Pause and inspect the illustrated flow. Which parts are local, and which send information elsewhere? Draw the complete boundary, list the unknowns, and identify who must resolve them. A good answer includes embeddings and telemetry, not just the model endpoint.
What appears on screen
What must be checked before calling this workflow local-only? Embedding destination. Telemetry and storage. Network reach and authorization. Your evidence: a complete data-flow record.
Watching explains the example. Complete the lesson practice to check what you can do. Explore all visual lessons →