Yes, for specific, bounded work. But usefulness, adopter ROI, supplier profit and investor return belong on four different scoreboards.
The practical question is not whether AI is universally good. It is whether one workflow gets measurably better after review, error handling, integration and the full operating cost.
Infrastructure economics can be ugly while users capture real value. A serious answer should steelman the supply-side warning without treating it as a usefulness test.
For the full argument and study limits, read Is AI profitable? The economics beyond chatbots.
Useful demand does not guarantee that every planned facility achieves high utilization or attractive returns.
Committed, subsidized or ecosystem-funded spend deserves more skepticism than diversified end-customer renewals.
Long-lived assets serve demand across years. The right test includes utilization, depreciation, financing and cash flow over the asset life.
Cheaper inference can compress supplier margins while making many more user workflows economical.
Economic surplus can accrue to adopters and customers even when suppliers compete much of it away.
Railways, telecoms and the web created enormous utility alongside overbuild, consolidation and investor losses. AI can do the same.
Capability is
becoming capacity.
AI systems depend on chips, power, data centres and networks. Those inputs shape cost, resilience and who can operate capable systems.
The practical question is not who owns one chat product. It is who can secure enough compute, on acceptable terms, for the work that matters.
Europe 2031 is a June 2026 scenario, not a forecast. It uses a fictional path from August 2026 onward to ask what could happen if Europe underestimates AI’s pace while remaining dependent on foreign compute, models and political decisions.
The authors imagine Europe reacting too slowly, spreading investment too thinly and treating sovereignty as self-sufficiency rather than bargaining power. In their downside path, limited compute and fragmented diplomacy leave the continent with less access to frontier systems, slower adoption and fewer good choices between the United States and China.
The proposed alternative is broader than “build a European model”: mobilize compute, energy and semiconductor supply chains; form a coalition of aligned middle powers; help workers through faster adoption; expand robotics and industrial AI; and give the public a positive account of what the transition is for.
Cost, workload placement and security concerns are pushing buyers toward more control. These surveys are directional, four are vendor-published or vendor-hosted, and none proves private infrastructure is always cheaper or safer.
cited on-premises AI as lower in cost or equal in cost to public-cloud AI services.
of organizations were reported as embracing a hybrid multicloud approach to AI, with privacy and control among the factors.
ranked data leakage during model training as a top AI-security concern.
48%also named unauthorized data access.
of employees in the workplace sample reported uploading sensitive company or customer information into public generative-AI tools.
of respondents reported a GenAI-related security incident during the previous year.
What the five signals support: enterprises are demanding control, security and placement choice, not making a blanket case for owning every workload.
Our verdict is intentionally split. These are editorial assessments grounded by the evidence on this site, not market forecasts or percentage scores.
Models can already perform useful bounded work with measurable effects and public implementations.
See the evidence →Support, writing, coding, tutoring and scientific workflows show value, but not every task or deployment does.
Model your own case →Compute demand can be genuine while parts of the buildout are early, mistimed, overfinanced or overbuilt.
See what would decide it →Thin wrappers, undifferentiated models and assets priced for perfect utilization are especially exposed.
Review both ledgers →The concise answer: a real productivity boom with speculative excess attached.
Usefulness does not rescue weak economics. Weak supplier economics do not erase useful work. The disagreement disappears once those claims stop sharing one scoreboard.
Count only savings that survive review and actually change how work is done. This version discounts claimed time savings and includes ongoing operating cost.
Do count: net saved time, genuinely retired subscriptions, avoided external spend and measurable throughput.
Do not count: impressive demos, time nobody can redeploy, hypothetical headcount reduction or gross savings before correction.
A scenario tool, not evidence or accounting advice. Measure a manual baseline and ten representative runs before buying dedicated hardware, then use the five-stage adoption journey to turn a proven result into a repeatable process.
Monthly net value-
First-year net after setup-
An 80/20 local-cloud split is a useful target, not a universal law. Independent studies support doing most economical work on-device and escalating selectively, but the measured unit varies between tasks, tokens and cost.
Run the intelligence where you trust it. Carry only the controls in your pocket.
A phone can be the control surface while a home machine handles private or repeated work and a cloud model handles the exceptions. Start with 80/20 as a hypothesis, then keep the split only if representative runs support it, and always show where each request actually runs.
Design the phone-to-model routeDocument search, transcription, extraction, classification, code assistance and drafts where a smaller model passes the acceptance test, even when the request arrives from your phone.
Complex reasoning, very large context, peak demand, advanced multimodal work or managed enterprise controls.
Set allowed data, cost ceilings, latency targets and fallback behavior. Show phone, home or cloud as the execution location and log why an escalation occurred.
A local hallucination is still a hallucination. Keep citations, deterministic tools, tests and approval gates around consequential output.
A coding-agent preprint separately reports 45-79% cloud-token savings from local routing plus prompt compression, depending on workload. These results point toward selective cloud escalation; they do not make 80/20 a population-wide measured fact.
A model becomes useful infrastructure only when it is attached to context, tools, controls and an external definition of done. For software work, the Thinking with AI loop turns those parts into a reviewable build process.
Define inputs, output, non-goals, allowed data and the consequence of failure.
Supply the right files, policy, examples and deterministic sources instead of relying on model recall.
Expose only the APIs, terminal commands or applications required for this workflow.
Require citations, checks, logs or approval before output crosses a consequential boundary.
A useful thesis should be falsifiable. Watch renewal, utilization and measured workflow value, not announcement volume.
Do people keep using the same workflow after novelty fades, and does net time saved remain positive after correction?
Are seats, API contracts and agent deployments renewed because they produce measurable value rather than because budgets were experimental?
Do GPU clusters and datacenters achieve sustained paid utilization before replacement and financing costs overwhelm returns?
Do capable local models and compact workstations become normal professional tools, or remain specialist equipment?
Which layers retain pricing power after open models, falling inference cost, bundling and competition redistribute the surplus?
Do verification and permission controls improve faster than systems are given authority, or do costly failures halt adoption?
Short answers to the questions behind the evidence, guides and implementation choices on this site.
Yes, for specific and bounded work. Controlled studies and field evidence show gains in tasks such as customer support, professional writing and coding, but results vary by workflow and still require review.
A useful workflow has a named deliverable, the right context, narrowly scoped tools and an external acceptance test. Its benefit remains positive after review, correction, operating cost and risk are counted.
Measure one repeated workflow against a manual baseline. Count net time saved after correction, genuinely avoided spend and measurable throughput, then subtract model, integration, governance and maintenance costs.
Use the smallest approved deployment that passes the workflow test. Local models often suit private, repeated or latency-sensitive work; cloud models suit harder, bursty or frontier-dependent tasks. Data policy and verification apply in either location.
Pick one repeated task. Keep authority narrow. Measure ten real runs.