When a business hears “AI feature”, it is easy to imagine another online account, another subscription and another journey for its information. A different approach is becoming available for some tasks: run the model on a supported device.
Google’s built-in AI documentation describes browser-managed models for tasks such as summarising and rewriting. Its May 2026 developer article explains the potential for local processing and offline use once the relevant model is downloaded. That is a particular implementation route, not a statement that any website with an AI feature keeps data on your device.1
The useful question is where the work happens
Imagine asking a developer for a feature that turns rough notes into a short draft. Before discussing the colour of the button, ask: where are the notes processed?
A cloud design sends information to a remote service. A local design runs the relevant model on the device. A hybrid design may use different routes depending on what is available. Those are different arrangements, even if the button looks identical to the person clicking it.
The distinction matters because a business needs to understand both the feature and its fallback. “On-device where possible” leaves an unanswered question: what happens when it is not possible? The answer should be specific enough to inform a decision.
A practical use without the grand promises
That is a more useful starting point than asking whether AI can “automate the office”. It gives the business a defined task, a known input and a result someone can check. It also makes failure visible: if a draft drops a key detail, the person reviewing it can say so.
We would start with fictional or non-sensitive material, compare the output with the original and record the corrections needed. Local processing changes the route taken by the information; it does not make generated text automatically accurate. A feature that saves typing but creates hidden checking work may be a poor trade.
It will not work on every device
The current Chrome documentation sets operating-system, storage and hardware requirements for its foundation-model APIs. It does not list Chrome on Android or iOS as supported for those APIs. Different browsers and devices need separate checks, and the availability of one built-in AI API does not imply all the others are available.2
This is especially relevant if a business works mainly from phones or iPads. A demonstration on a capable desktop is not evidence that a field team can use the same feature. Ask to see it on the actual devices, browsers and working conditions that matter to the business.
The normal workflow should remain usable when AI is unavailable. A customer should not lose access to an essential form because their device cannot run an optional model. Treating AI as an enhancement makes that requirement easier to explain and test.
Watch the fallback
Google’s experimental Prompt API polyfill can be configured with local or cloud backends. Its documentation explicitly distinguishes the two: a cloud backend sends information for remote processing, while a local backend processes it in the browser.3
Our recommendation is that a fallback should be an intentional product decision, not a surprise. If the route changes, the explanation to the user should change too. If offline use matters, test the complete task offline rather than assuming that a model running locally makes every part of the application independent of a connection.
Four questions before commissioning a feature
- Which task are we improving? Define the input, output and review step.
- Where does each part run? Include storage, analytics and fallback processing in the explanation.
- Which devices support it? Test the equipment people actually use.
- What would make the trial successful? Compare time saved, correction effort and reliability with the existing method.
There may be a useful role for browser-based AI in a focused tool. There may also be cases where a simpler form or ordinary software rule is the better answer. The value of knowing about this development is being able to ask a better question before agreeing the project.
Sources and editorial notes
Checked 27 October 2026. Chrome Prompt API documentation updated 26 August 2026. This is an original SSC Digital explainer, with AI-assisted research and drafting, checked against the sources below. Examples and recommendations are our interpretation, not claims of measured results.
- Google Chrome for Developers: built-in AI features
Published 26 May 2026. Browser-managed AI use cases and local-processing model.
- Google Chrome for Developers: Prompt API
Updated 26 August 2026. Availability, hardware and operating requirements; check current support before implementation.
- Google Chrome for Developers: experimental Prompt API polyfill
Published 14 May 2026. Distinction between local and cloud backends.
Corrections: none recorded at publication. Send a correction or question.

