AI Phone Videos Must Show Where the Feature Runs

The most attractive shot in an AI phone launch film is often the one most likely to change the product claim. A person states a need, the screen produces a polished result immediately, and every wait, download, network, account, region and prototype condition disappears.

That is not automatically deceptive. The edit may simply compress a real operation for pace. But the audience no longer sees “this feature completes the task under these conditions.” It sees “this phone itself can always complete the task instantly.” From a production perspective, the problem did not begin in the edit suite. It began before the storyboard was approved, when the team failed to define whether the feature runs on-device, in the cloud or through a hybrid path—and which conditions the shot must preserve.

Before an AI phone film enters storyboarding, the most useful document is therefore not a futuristic mood board. It is a feature truth sheet. For every demonstrated function, it records where the feature runs, which device supports it, what software and model state it requires, whether it depends on a network or account, what the input is, how the interaction unfolds, how the output appears and which limits must remain visible in the image or copy.

This article does not review any particular phone, and it does not present manufacturer documentation as testing performed by ONCE. On 6 October 2026, we checked current Android and Google ML Kit documentation for on-device generative AI, Apple and Samsung support pages, US Federal Trade Commission guidance on advertising claims, and Shenzhen's public policy for AI terminals. We then translated those technical and claim conditions into a pre-production method.

An AI feature is not one filming object. It is an execution path

Shenzhen's 2025–2026 action plan for AI terminals describes the AI phone as a full stack of chip, operating system, model or agent and application ecosystem. For a production team, that framing surfaces a fact that visual language often hides: the result seen on screen may come from the phone's hardware, a remote service, or a combination of local and cloud processing.

The three paths create different filming decisions:

• On-device: input, inference and output are primarily processed locally. The feature may work offline and reduce the need to send data away from the device, but performance can still vary with hardware, software, model version and resource state.
• Cloud: network access, account state, server availability, region and service terms may be conditions of use. A close-up of the phone must not quietly imply that the hardware alone produced the result.
• Hybrid: some steps run locally and others remotely. Different features—or different modes of one feature—may follow different routes. Production should document the specific task rather than label the entire product “on-device AI.”

Android's Gemini Nano documentation says the model can run on-device through AICore and also notes that inference speed depends on device hardware. Google ML Kit's GenAI overview distinguishes streaming from non-streaming output, lists device and model support differences, and notes that different base-model versions can return different outputs from the same prompt. Its Prompt API setup guide requires a feature-status check: a feature may be unavailable, downloadable, downloading or available.

Those developer terms do not have to appear in the finished film, but they belong in production preparation. Without them, an on-set failure can be misdiagnosed as a network problem when the model is not present; a backup handset can then produce a different result and be blamed on an incorrectly reset prompt. Under schedule pressure, a team may substitute a prerecorded screen without documenting whether it represents approved UI, a concept visualisation, or an output actually generated by the device shown.

Build the feature truth sheet before writing “one sentence, instant result”

A feature truth sheet does not have to become a complicated technical specification. Its purpose is to attach every product claim to a reproducible device condition.

Apple's current support page separates device, OS, storage, device and assistant language, region and account conditions, and says some server-based features have usage limits. Samsung's US support page distinguishes on-device and cloud-based features, identifies functions that require a network, account or specific software, and warns that availability varies by device and software version. Manufacturer pages change, so a real campaign must still use the feature matrix approved by the brand on the shoot date. The durable conclusion is narrower: an AI feature is not an abstract benefit independent of configuration.

Once the truth sheet exists, the script line “AI completes it in one second” becomes a set of useful questions:

1. Does one second mean the first feedback appears, or the final result is complete?
2. Was the model already downloaded, the account signed in and the network stabilised before the take?
3. Does cutting the wait change only pace, or the audience's understanding of performance?
4. If the result comes from the cloud, does the shot imply that the chipset completed it alone?
5. If the feature is limited to particular languages, regions or versions, does the claim keep the necessary qualification?

A feature shot should preserve five connected pieces of evidence

We recommend structuring an AI demonstration as trigger, device state, interaction, result and limit. This does not force every shot into one continuous take. It means that the final edit should preserve the causal relationship between the product action and the result.

1. Trigger: who asked for what?

Make the input identifiable. A voice-assistant film should not retain only the performer's speaking expression. An image-generation film should not begin with the final picture. A translation film should not omit the source language. The trigger shows the problem the feature solves instead of merely showing a beautiful screen.

2. Device state: why can this phone run the feature now?

The film need not turn a settings page into an instruction manual, but the production record must identify the handset, OS, app, model, network, account and feature-switch state. If a network is essential, the shot and copy should not imply equivalent offline operation. If on-device processing is the proposition, the brand's technical team should confirm that the demonstrated path is genuinely local. A glowing animation is not proof of execution location.

3. Interaction: the hand, sound and UI should represent the same action

Phone films often combine a filmed hand, screen capture, replacement UI and designed sound. Layering is not the problem. The question is whether all layers describe the same approved path. Keep a real-operation master take, an isolated screen recording, a clean handset plate and the key finger-action close-ups. Any replacement UI should use approved assets and align touch position, scroll speed, status bar, time and animation state.

4. Result: separate first feedback, generation and final output

Google ML Kit's documentation separates streaming and non-streaming results. The first returns output incrementally; the second waits for completion and returns a single result. Compressing progressive generation into an instantaneous completion changes what viewers may infer about speed and consistency. Time can be compressed, but the edit should avoid uninterrupted action, sync sound or “real-time” language that creates performance the product did not show. A clear on-screen note may be needed.

5. Limit: a qualification is part of the claim, not decorative legal copy

For the US market, the FTC's advertising guidance says objective claims need substantiation and qualifying information should be clear, conspicuous and close to the claim. That is not a legal conclusion for every market, but it gives production teams a useful test. If a qualification is buried at the end, set too small or flashed too quickly after the audience has already formed a different understanding, it has not meaningfully corrected the shot.

Separate product truth, interaction truth and visual imagination

An AI phone film needs imagination, but imagination should not carry the burden of performance proof. Production can divide its material into three layers.

Product truth covers industrial design, materials, buttons, camera modules, display proportions and demonstrably available features. It normally depends on an approved unit, controlled live action and official UI assets. ONCE's e-commerce product-video solution shows how product actions, materials and use conditions can be organised into visible evidence. Published work can illustrate content structure; it does not prove the technical path of a new AI function.

Interaction truth covers the causal continuity between touch or voice input, state feedback and output. It may combine the filmed handset, screen capture and UI compositing, but every layer should use the same version, the same feature path and a traceable approval record.

Visual imagination covers data movement, space, mood and conceptual worlds. AIGC, CGI, particles and light can make invisible computation perceptible, but they should not invent where data is processed, how fast it works or how privacy is protected. For hybrid live-action and generated scenes, ONCE's AIGC commercial-production approach explains why approved assets or live action should anchor precise product appearance and operation.

All three layers can coexist in one film, but they require different acceptance tests. Product truth is checked against the approved device; interaction truth is checked against the same execution path; visual imagination is checked for metaphors that could be mistaken for performance facts.

Freeze the device state, not only the script

AI functions are more vulnerable to software change than a conventional beauty shot. Before production, create a minimum device matrix: primary and backup units; model and identifying label; OS and app versions; model-download state; language, region, account and permissions; network plan; publishable test data; a method for clearing personal notifications; and a reset procedure for each take.

The matrix changes the schedule. A unit that requires a large model download should not be initialised after the camera call. A cloud-dependent function needs a primary network, a backup network and a shot fallback if the service is unavailable. A generative feature with variable output needs an approved target result and an acceptable variation range so the team does not spend the day drawing unlimited samples. If the appearance shot and feature shot use different devices, the call sheet and shot log must say so; the edit must not casually imply that the cosmetic unit performed the function.

For an incomplete prototype, the honest route is not to hide the gap with finished-film polish. Mark the shot as a UI visualisation, concept demonstration or intended experience, then have product, marketing, legal or compliance and production approve the language. A brand film may legitimately express a future direction. The moment it functions as proof of a launch feature, its need for reproducibility rises.

On-set records give every polished result a route back to fact

The set should retain at least four types of record:

• Real-time master take: the complete path from input to output, used to confirm sequence and exceptions.
• Original screen files: unpolished captures, outputs and version information for post-production alignment.
• Clean handset and hand plates: material for reflection control, moiré repair, action continuity and multiple aspect ratios.
• Shot log: device, OS, model, network, account, input, result, retry reason and approval status.

Not all of these materials belong in the final film. They create boundaries for editorial choice. Removing empty wait time, reordering explanation or replacing sensitive test data can all be reasonable. Selecting one result after repeated failures and presenting it as guaranteed, packaging a cloud route as handset-only capability, or making a concept interface look like a released feature crosses the line from pacing into claim alteration.

Acceptance should ask more than whether it looks like a launch film

For every feature, return the edit to the truth sheet:

1. Which device, software and model state does the shot represent?
2. Can viewers identify the relationship between input, key interaction and result?
3. Are network, account, language, region or version limits clear when they matter?
4. Did UI replacement, time compression, AIGC or CGI change the apparent execution location or performance meaning?
5. Do voice-over, supers, end cards and the product page use the same approved claim language?
6. Would the shot remain true in another planned market or on another planned model?

No worksheet can replace technical validation by the brand. The truth sheet makes responsibility visible earlier: product confirms the capability and boundary, marketing confirms the claim, legal or compliance confirms the target market, and production confirms that the image does not exceed those facts. ONCE's video-production solutions can be a starting point for scoping, but each project still needs to be defined from the product, audience, market and task the film must prove.

Conclusion: prove where it happens before designing how intelligent it looks

An AI phone film does not need to turn every technical condition into engineering documentation. Nor should caution destroy pace. The useful discipline is to decide which product fact must be believed, then choose the smallest sufficient set of visual evidence.

If a feature runs on-device, make the on-device conditions genuinely true. If it depends on the cloud, do not make a hardware close-up vouch for the remote service. If it is hybrid, film the exact task so input, state and result remain connected. Device build, model download, network, account, language and region are not on-set trivia. They are part of the shot's claim.

The audience may see only one second of result. The production team must know where that second came from, what was removed, and which evidence would force a different treatment. That feature truth sheet should be the first storyboard an AI phone film approves.