Has AI Really Become More Accessible?
For years, the story has been that AI is becoming more accessible. Every product launch, every keynote, every headline repeats some version of the same claim: intelligence is being put into everyone's hands.
It is worth pausing on that claim, because it is not quite true in the way it sounds. Today, meaningful AI generally requires one of three things: expensive workstation-class hardware capable of running a large model locally, a continuous cloud subscription billed every month whether you use it or not, or access to a proprietary AI ecosystem controlled by whichever platform happens to be installed on your device. Take any one of those away, and for most people, "AI" quietly stops meaning much at all.
That is not a criticism of any single company. It is a description of where the industry's default architecture has settled, and defaults are exactly the kind of thing engineering is supposed to question. So here is the question this article sits with: what if the hardware problem has already been solved, and the part that hasn't caught up is everything built on top of it?
Billions of people already own a device capable of running a genuinely useful AI model, offline, in their pocket. The gap left to close is not silicon. It is software, ecosystems, and the will to build for the hardware people already have instead of the hardware a keynote wishes they had.
The AI Divide
None of this makes cloud AI wrong. Hyperscale data centres have made genuinely capable frontier models available to anyone with a browser tab, and that is a real achievement worth keeping in view throughout this piece. But running a frontier-scale large language model locally, at the quality bar people now expect from a capable assistant, still generally requires hardware well beyond what most people own, workstation-class GPUs that run from several hundred to tens of thousands of dollars, more RAM than a typical laptop ships with, and often a cooling and power budget that assumes a desk, not a pocket.
So most people interact with AI a different way: through a cloud service, paid for by subscription or by the request, or through whatever assistant the platform on their device happens to bundle. That arrangement works well for a great many use cases. It also creates three barriers that are easy to underweight from inside the industry, because the people building AI products are rarely the people most affected by them: cost, since a recurring subscription is a permanent line item, not a one-time purchase; connectivity, since cloud AI is only as available as the network underneath it, which is not a safe assumption everywhere on earth; and dependency, since a feature that lives on someone else's server can be repriced, rate-limited, or discontinued on someone else's schedule, not yours.
The International Energy Agency's 2025 Energy and AI report is a useful anchor for just how much infrastructure sits behind the "instantaneous" feel of a cloud AI response: global data centre electricity consumption reached roughly 415 terawatt-hours in 2024, growing at nearly four times the rate of overall global electricity demand, with AI named as the single most important driver of that growth.[1] That scale of infrastructure is a remarkable engineering achievement. It is also, definitionally, infrastructure that has to be built, financed, and maintained by someone, which is a very different cost structure from a capability that runs on hardware the user already paid for and already owns.
The AI divide is not a gap between people who understand AI and people who don't. It is a gap between people for whom AI is a recurring bill or a permanent network dependency, and people for whom it can simply be a capability their device already has, no subscription, no connection, no third party in the loop.
Small Language Models Change the Equation
Over the last two years, a parallel current has been running alongside the race toward ever-larger frontier models: a family of deliberately smaller models, commonly called Small Language Models, or SLMs, built to run well within the memory and power envelope of a phone rather than a server rack. Google's Gemma family, Microsoft's Phi family, Alibaba's Qwen family, Mistral's smaller releases, and compact variants of Meta's Llama models are all examples of this current. They are mentioned here only as examples, not as a comparison. This article is not a benchmark leaderboard, and the specific model a team chooses matters far less than what the category as a whole makes possible.
What makes SLMs significant is not that they are about to replace frontier-scale models, for many tasks, they clearly won't, and pretending otherwise would be dishonest. Their significance is that they let meaningful AI execute on hardware hundreds of millions of people already carry in their pocket, without a network round trip and without a subscription. That reframes the central question an engineering team asks when reaching for AI: not "which model has the highest benchmark score," but "which model is small enough to actually run where my user is, and still good enough to do the job."
This is also not a fringe engineering opinion. NVIDIA's own research team argued exactly this case in 2025, in a paper titled Small Language Models are the Future of Agentic AI: that for the majority of agentic and tool-using tasks products actually ask of AI today, small, specialized models are sufficiently capable, and that defaulting to the largest available model for every task deserves to be treated as a design choice to justify, not an assumption to skip past.[2]
Accessibility, not maximum capability, is the strongest argument for Small Language Models. A model that runs on the phone someone already owns, for free, offline, is more democratic than a more capable model that only exists behind a subscription and a network connection, even when the second model would score higher on a benchmark.
The AI Computer Already Exists
It is easy to still picture a smartphone as a communication device that happens to run some apps. That picture is out of date. A modern flagship phone typically ships with a dedicated neural processing unit alongside its CPU and GPU, purpose-built silicon whose entire job is accelerating the matrix math that machine learning models are built from. Arm, whose CPU designs sit inside the overwhelming majority of the world's smartphones, documents this shift directly in its own developer materials on AI-capable mobile architectures, describing NPUs and GPU compute as now-standard components of the mobile compute stack rather than a specialized add-on.[3] Qualcomm and MediaTek, whose chipsets power most Android flagships, have each published extensively on running generative AI workloads directly on their mobile NPUs, Qualcomm's own engineering blog has walked through running billion-parameter generative models on-device, entirely locally, years before it became a mainstream product conversation.[4]
Samsung, Apple, and Google have each already demonstrated, in shipping products, that a phone can do useful AI work without a server on the other end of a network call. Apple's Core ML and Apple Intelligence documentation describes on-device model execution across its silicon lineup as a first-class platform capability, not an experimental one.[5] Samsung's Galaxy AI developer materials describe a comparable set of on-device intelligence features built into its own devices.[6] Google's own Android developer documentation for ML Kit describes on-device machine learning APIs, for tasks like text recognition, that run with no network dependency at all.[7]
What's worth naming honestly, though, is the shape of what those platforms currently offer a developer. Today's platform AI capabilities are primarily designed around the operating system's own features and a fixed set of developer APIs for specific tasks, a summarization API here, a text-recognition API there. A developer generally cannot install an arbitrary Small Language Model of their own choosing as a reusable, system-level AI resource the way they can add a database or a networking library. The AI computer already exists in nearly everyone's pocket. What doesn't yet exist, broadly, is an open lane for a developer to hand that computer any model they choose and let it run.
The hardware conversation and the software conversation are at different stages of maturity. NPUs, mobile GPUs, and efficient quantized models have made "can this phone run a real model" a solved problem for a growing share of devices. "Can any developer easily ship any model to run on that hardware, shared across apps, without bundling a multi-gigabyte runtime into every single one" is still very much an open one.
AI Accessibility
Step back from the hardware and the model architectures for a moment, because the more important pattern here is historical, not technical. Personal computers democratized computing. They took a capability that once required an institution and put it on a desk. The internet democratized information. It took knowledge that once required a library card or an expensive encyclopedia and put it a search away. Smartphones democratized connectivity. They took a capability that once required a landline and a fixed address and put it in a pocket, everywhere, for a large share of the planet.
Each of those shifts followed the same underlying shape: a capability that used to require money, institutional access, or physical infrastructure became available on a device ordinary people already had reason to own. Small Language Models running on edge hardware may be the next entry in that same lineage, not because the technology is flashier than what came before, but because it follows the identical pattern: billions of people already own hardware capable of running useful AI. The part that hasn't caught up is the software ecosystem that would let that potential actually get used.
This is worth sitting with as more than a technical detail, because the stakes are not abstract. A student without a data plan. A clinician in a region with unreliable connectivity. A small business that cannot justify a recurring per-seat AI subscription. A person who, for entirely reasonable privacy reasons, does not want a sensitive question leaving their device at all. For every one of them, "AI that runs locally, for free, on hardware you already own" is not a nice-to-have feature. It is the difference between having access to a capability at all, and not.
This is the emotional centre of the argument, and it deserves to be stated plainly rather than hedged: intelligence being available offline, for free, on a device someone already owns, is not a secondary feature of AI's future. For a very large share of the world's population, it may be the feature that decides whether they get to participate in this technology at all.
Beyond Platform AI
None of what follows in this section has been announced by any company. It is offered explicitly as a possibility worth engineering toward, not a prediction of what any platform will ship.
Imagine a future mobile operating system where a user can download their preferred AI model the way they install an app today, replace it with a different one if their needs change, and update it independently of any single app that happens to use it. Imagine multiple applications on the same device sharing one installed model and one inference runtime, instead of each app bundling its own multi-gigabyte copy of essentially the same weights. Imagine model access being governed the way camera or location access already is, a permission a user grants deliberately, scoped to a specific app, revocable at any time, visible in one place in system settings rather than buried inside each app's own onboarding flow.
The potential benefits of that kind of shared-model ecosystem are concrete and unglamorous in exactly the way good infrastructure usually is: lower device storage consumption, because ten apps that each need language understanding don't each need their own multi-gigabyte model file; reduced duplication of download bandwidth, particularly meaningful in regions where data is expensive or connectivity is metered; and greater interoperability, because a developer building a genuinely useful AI feature wouldn't need to first solve model distribution and runtime engineering before writing a single line of the feature itself.
A future where local models are a shared, user-managed system resource, rather than a private ingredient every app quietly bundles for itself, would let developers build genuinely useful local AI features without each one re-solving model distribution, storage, and runtime lifecycle from scratch. Nobody has announced this. It is offered here as an engineering opportunity worth naming, not a roadmap.
FarmakoMed as a Practical Example
Everything so far has been about where the industry could go. FarmakoMed is one concrete example of a team building toward part of that vision today, and it is worth being precise about what that actually looks like in the running app rather than describing it in the abstract.
FarmakoMed's medication-recognition feature runs a Gemma vision-language model entirely on-device, through Google's LiteRT-LM runtime, on both Android and iOS. A user photographs a medication package, and the model, resident on their own phone, reads the image directly and returns structured fields: the medication name, active ingredient, strength, dosage form, and expiry date, without a photo or a word of that request ever reaching a server. Once the model file has been downloaded once and verified, the entire recognition pipeline works fully offline. The app also runs entirely without that AI model at all for any user who declines it or whose device doesn't meet the eligibility bar, every non-AI feature, from the medication list to reminders to appointments, works identically either way. AI here is additive, never a precondition for the app being useful.
The model file is downloaded once, verified by SHA-256 checksum, installed atomically into app-private storage, resumable if the download is interrupted, and then reused across every scan for as long as it's installed, with no further network dependency. The runtime manages its own lifecycle: it warms up in the background, releases itself under memory pressure, and rebuilds itself automatically if it's evicted while the app is backgrounded, so the healthcare features around it never have to wait on the AI model's state to stay usable.
FarmakoMed's engineering choices are also a small case study in matching the tool to the task rather than reaching for the biggest available model by default, the same instinct this article argues the whole industry should apply more broadly. Document and appointment scanning uses Google's ML Kit on-device text recognition, not the vision-language model, because the team measured that the smaller, purpose-built engine did the job in a few hundred milliseconds and roughly 12 megabytes, against multi-second latency and gigabytes of memory for the same task run through the larger model. The voice assistant, similarly, runs on a deterministic local rules engine rather than the language model at all, because the feature doesn't need generative reasoning to answer "when is my next appointment" from data already on the device. Every one of these choices was made independently, for its own task-level reasons, but together they demonstrate the discipline this piece keeps returning to: use the smallest tool that can do the job correctly, not the largest one already on hand.
None of this makes FarmakoMed a replacement for cloud AI, and it isn't offered as one. It's one working example that the vision described earlier in this article, meaningful AI running locally, offline, on hardware a user already owns, with no subscription and no server in the loop, is not a hypothetical for some future generation of phones. It is possible today, on hardware already sitting in people's pockets, for at least one real, shipping healthcare feature.
Democratizing Intelligence
Pull back to the widest frame this article is willing to draw. The future of AI may not depend solely on building larger and larger models. It may depend just as much on making the intelligence that already exists reachable by more people, in more places, under more constrained conditions than the industry has designed for by default.
Think about where that matters most concretely: a student studying without reliable data, who could still get help from a model that lives entirely on their phone. A clinic in a region with intermittent connectivity, where "the AI feature doesn't work because the network is down" is not an acceptable failure mode for anything touching patient care. A person for whom a recurring subscription is simply not affordable, for whom "free, because it runs on hardware you already bought" is the only version of this technology they will ever get to use. A person who wants a private question answered privately, with the certainty that comes only from the words never having left their own device. None of these are edge cases in the way the phrase is usually meant. Collectively, they may describe more people than the ones for whom a cloud subscription was always an easy yes.
None of this argues that on-device AI should replace cloud AI. A phone's chip will not out-reason a data centre's cluster, and plenty of tasks genuinely need the scale only the cloud can offer. The honest position is that both deployment models are legitimate, and that an industry with only one default, cloud-first, subscription-gated, is optimising for one axis while leaving accessibility on the table.
One Last Thought
Artificial intelligence does not become truly democratic the moment everyone can talk to a chatbot. Plenty of people already can, through a browser, for free, today, and that has genuinely mattered. It becomes democratic in the deeper sense when everyone has the ability to build with, run, and rely on AI using devices they already own, on their own terms, whether or not a network is available and whether or not a subscription is active.
Perhaps the next real AI revolution isn't waiting on a new generation of hardware at all. Perhaps, for a meaningful share of what people actually need from this technology, it's already sitting in their pocket. The remaining work isn't inventing the silicon. It's opening the ecosystem built on top of it.
- International Energy Agency, Energy and AI (2025). Source for global data centre electricity consumption figures and AI's role as a primary growth driver.
- Belcak, P. et al., Small Language Models are the Future of Agentic AI, NVIDIA Research (2025). Source for the argument that small, specialized models are sufficient for the majority of agentic AI tasks.
- Arm, AI on Arm developer documentation. Source for the description of NPUs and mobile AI acceleration as standard components of modern mobile silicon.
- Qualcomm, Qualcomm OnQ Blog, on-device generative AI engineering posts. Source for on-device generative model execution on mobile NPUs.
- Apple Developer, Core ML and Apple Intelligence documentation. Source for on-device model execution as a first-class platform capability on Apple silicon.
- Samsung Developer, Galaxy AI developer documentation. Source for Samsung's on-device intelligence features.
- Android Developers, ML Kit documentation. Source for on-device, no-network-dependency machine learning APIs on Android.
- Google AI, Gemma model documentation, and Google AI Edge, LiteRT runtime documentation. Source for the Small Language Model and on-device runtime referenced in the FarmakoMed case study.
- Related reading in this journal: Choosing a Model for On-Device Healthcare AI, The Engine Isn't the Car, and Can AI Be Sustainable?.
Key Takeaways
The hardware problem is largely solved; the software ecosystem hasn't caught up. Billions of phones already ship with NPUs and mobile GPUs capable of running useful AI models locally.
Small Language Models matter because they run where the user already is, not because they beat frontier models on a benchmark. Accessibility is a different axis than maximum capability.
Today's platform AI is API-shaped, not resource-shaped. Developers can call specific on-device features; they generally can't install an arbitrary model as a reusable, shared system resource, yet.
PCs democratized computing, the internet democratized information, smartphones democratized connectivity. Small Language Models on edge hardware may be the next entry in that lineage.
FarmakoMed shows this is possible today, not hypothetical. A Gemma vision model runs fully on-device via LiteRT-LM on both Android and iOS, no server, no subscription, and the app works fully without it too.
More in the Journal
This article builds on the model-selection reasoning described in our earlier piece on choosing a model for on-device healthcare AI.
Read "Choosing a Model for On-Device Healthcare AI"Join the conversation
Should the industry build toward shared, user-managed on-device AI models? We'd like to hear how your team thinks about it. Follow FarmakoMed on LinkedIn.
Follow on LinkedIn