How to Evaluate On-Device vs Cloud AI Features

How to Evaluate an On-Device and Cloud AI Feature

Evaluate a hybrid AI feature by fixing one task, one device state, and one input, then tracing every documented and observed execution path. The useful question is not "Is this on-device AI?" It is "For this task, what data can move to which system, under which conditions, and what evidence supports the answer?"

A good evaluation produces a data-flow diagram, a connected and offline test record, a provider and terms record, a failure log, and a decision with an owner and review date.

flowchart TD
    A["One feature, task, and input"] --> B["Document local path"]
    B --> C["Document vendor-cloud path"]
    C --> D["Document external-provider path"]
    D --> E["Test connected, constrained, and offline"]
    E --> F["Compare behavior with documentation"]
    F --> G{"Evidence supports intended use?"}
    G -->|Yes| H["Allow or pilot with controls"]
    G -->|No| I["Restrict, block, or escalate"]

Start with a task, not the product brand

"Apple Intelligence," "Copilot," and "Gemini" are product families. They contain features with different inputs, models, data paths, retention rules, provider dependencies, and risks.

Name the action in observable terms. Examples include proofreading a selected paragraph, summarizing a meeting transcript, removing an object from a photo, answering a question about a file, drafting a reply, or finding a scene in a media library. Record what a satisfactory result would contain and which errors would matter.

Then fix the environment.

Without this record, two people can report different behavior while both are correct for their own configuration.

Draw the documented flow before running the test

Read the current product, privacy, security, administrator, and service-provider documentation. Identify the on-device component, vendor cloud, external model provider, telemetry, account service, storage, moderation, logging, and support path.

For Apple Intelligence, Apple's current requirements page establishes compatibility claims. Its Private Cloud Compute Security Guide describes a server path for requests that need larger models. Apple's ChatGPT guide describes a separate external-provider path.

Write each path as a conditional statement. "If the local model can perform this operation, Apple documents on-device execution." "If a larger Apple model is needed, Apple documents Private Cloud Compute." "If the user invokes or approves ChatGPT, the request may cross to an external provider under that integration's settings and terms."

Do not convert those statements into observed facts until the test supplies evidence.

Use low-risk synthetic inputs

Boundary testing does not justify exposing the data you are trying to protect. Use synthetic or explicitly authorized material that exercises the relevant format and size without containing real secrets, health information, payment information, privileged communications, identity documents, children's information, or confidential customer records.

The NIST Privacy Framework is useful here because it treats privacy risk as a consequence of data processing, not merely a cybersecurity failure. A secure connection can still support an inappropriate collection, use, retention, or disclosure.

For higher-impact AI decisions, the NIST AI Risk Management Framework provides a wider vocabulary for governance, mapping, measurement, and management. It does not approve a product. It helps a team identify the evidence its own decision requires.

Test the network states

Run the same bounded task while normally connected. Record the output, latency, visible status, provider notice, confirmation step, and error behavior. Repeat under a constrained connection. Then disconnect the relevant network paths and repeat. Restore the connection and test recovery.

Offline success is evidence that the tested operation can complete without a live cloud response in that state. It does not prove that no data was previously downloaded, queued for later transfer, logged by the application, synchronized by another service, or sent during a different feature path.

Offline failure also has several meanings. The model might be cloud-only, a required asset might be missing, authentication might have expired, a policy may block the operation, or the application may be poorly designed for network loss. Record the visible failure rather than inventing the cause.

Collect execution evidence where the platform exposes it

Network observation, system logs, application notices, administrator reports, provider dashboards, and privacy reports can strengthen the record. Their scope must be stated.

Apple's Apple Intelligence Report can identify recorded model requests as OnDevice or PrivateCloudCompute and can include PCC attestation material. That is stronger than guessing from speed. It does not cover every application event or external network flow.

If the observed behavior conflicts with documentation, preserve both. Check version, feature, account, locale, and date. Escalate the discrepancy instead of choosing the answer that sounds more reassuring.

Read the data terms by path

For every system that may receive the input, record purpose, data categories, retention, human or privileged access, logging, training use, deletion, account effect, jurisdiction, subprocessors, security controls, incident route, and policy controls. A single product privacy page may not cover an optional external service.

Account state can matter. A provider may treat a signed-in paid account differently from an anonymous or integrated request. Organization-managed services may offer controls that consumer accounts do not. A prompt confirmation can show a boundary, but a disabled confirmation changes how easily users cross it.

Episode 42's [[How to Evaluate a Workplace AI Feature]] expands the organizational review. [[How to Build an AI Feature Claim Ledger]] preserves the public claim, evidence, exceptions, owner, and refresh date.

Make a scoped decision

The decision should be allow, restrict, pilot, block, or escalate for the named task and data class. Record permitted devices, accounts, features, data, settings, review date, monitoring, training, fallback, deletion, and incident path.

Do not generalize a successful low-risk test into approval for all use. A feature that is acceptable for rewriting public marketing copy may be unacceptable for summarizing privileged legal advice. A phone that runs a model locally may still synchronize source files through a separate service.

An AI publishing agent should route privacy questions to the exact execution and provider record. It should preserve the test date and configuration, distinguish documentation from observation, and avoid saying "stays on your device" unless the evidence covers the exact request.

This guide was developed with AI assistance from the preserved E021 transcript, the linked evaluation protocol, current Apple documentation, and NIST frameworks. Dalton Anderson remains the author. It is an evaluation method, not an independent product certification or legal, privacy, security, compliance, procurement, or records-management opinion. Qualified review is required for sensitive or regulated use. Publication is not authorized.