The people building AI and the people buying it expect very different futures. Neither view belongs in your budget as an established fact.

The people building AI disagree with the people buying it

The most useful detail in Anthropic’s October research on the AI expectations gap is not a prediction of economic transformation. It is how differently informed groups expect that transformation to happen. Surveyed Anthropic staff expected AI to be able to do an average of 75% of their current work hours by 2030. US workers put the corresponding average at 28%. Those are expectations about capability, not measured automation rates, and neither number is a forecast for a British business.

The difference matters because business plans routinely smuggle this sort of belief into apparently precise numbers. A supplier says autonomous systems will handle most administration within a few years. A director converts that claim into a staffing assumption. Finance turns the assumption into a saving. By the time the plan reaches approval, a contested view about technical progress looks like an agreed operating outcome.

The opposite mistake is just as costly. A team that has tried one unreliable assistant may assume the technology will remain marginal. That belief can leave valuable, straightforward improvements unexplored. The research does not establish that insiders are right and everyone else is wrong. It shows why the source, population and question behind a forecast need to travel with the headline.

For a UK owner, the practical response is to separate an external outlook from an internal commitment. Keep a short register of material AI assumptions: what is expected to improve, which business activity depends on it, what evidence would support the claim, and when the assumption will be reviewed. A forecast can justify a small experiment. It cannot, on its own, justify removing the people or controls that currently make a service dependable.

A forecast about AI capability is not a forecast about your business.

Capability, adoption and business value are different questions

Anthropic’s economic scenario explorer explicitly separates capability, adoption, autonomy, productivity and adjustment. It models possible US economic outcomes if particular assumptions hold. It is not a company-specific prediction engine. That distinction is useful even if you never touch its sliders: a system can be technically capable without being widely used, and it can be widely used without producing a corresponding improvement in your margins.

Consider an illustrative property maintenance business. A model may be able to draft a competent response to a tenant. The business still needs permission to use the information, reliable access to the correct property record, a way to distinguish routine work from emergencies, and someone responsible for promises about appointments. The existence of the drafting capability does not prove that the whole customer journey can run unattended.

Adoption is another separate step. Staff may avoid a tool because opening it interrupts their normal system. Customers may insist on speaking to someone. Supervisors may reject outputs because the organisation has not agreed what a good result looks like. None of those problems is necessarily solved by a more capable underlying model. They belong to process design, training and customer expectations.

In practice, write five separate statements before approving a project. Can the system perform the task? Will people use it in the actual workflow? What authority can it safely exercise? Does the completed work improve the service or its economics? What changes must the team absorb? Give each statement an evidence source and an owner. Do not let a compelling demonstration answer all five by implication. This prevents a plausible technology story becoming an unsupported operational promise.

Being able to do a task is only the first of several gates.

Use UK adoption figures without pretending they prove a return

The ONS bulletin published on 8 October 2026 reported that 30% of businesses used at least one AI technology in September, compared with 9% when the question was introduced in September 2023. The bulletin describes these as official statistics in development and advises caution. The figures are evidence that adoption is spreading, not evidence that every adopter has a successful transformation programme or that your competitors have already automated your service.

A separate government AI adoption survey published on 29 October reported 32% adoption. Do not turn the difference between those two surveys into a growth calculation: their methods and survey populations need to be understood before comparing them. More revealing for planning is the government survey’s report that 64% of businesses had seen no immediate financial effect on operating costs, while 24% reported reductions and 9% an increase. These are reported experiences, not experimentally established effects.

That is not an argument that AI is failing. An organisation can gain better turnaround, more consistent documents or additional capacity before it reduces cash expenditure. Staff may spend released time on customer work rather than disappear from payroll. The point is that a board paper must say which benefit it is buying instead of using productivity, cost reduction and profit as interchangeable labels.

What this means in practice is a disciplined baseline. Record the existing volume of work, completion time, error corrections and service outcome before introducing a tool. Then state whether the project is meant to release capacity, reduce external spend, improve quality or increase throughput. Track that outcome separately from logins and licence counts. National adoption data gives useful context for urgency; only local evidence can tell you whether the chosen intervention deserves a larger commitment.

Using AI and making money from AI are not the same measurement.

Make three operating plans rather than one heroic prediction

You do not need a view on the exact arrival date of transformative AI to make useful decisions this quarter. You need to know which commitments remain sensible under several plausible conditions. Start with three operating scenarios: incremental capability improvements, rapid improvement with uneven adoption, and rapid adoption that changes customer expectations. These are planning devices, not probability estimates and not promises about what will happen.

For each scenario, describe what changes in one named workflow. In an illustrative professional services firm, incremental progress might mean better preparation of meeting notes. Faster technical progress might allow a useful first draft of a complex proposal, but still require experienced review. Wider customer adoption might create demand for quicker answers and clearer evidence of expertise. Each scenario has different implications for training, process ownership and commercial positioning.

Now divide actions into reversible learning and expensive commitment. Cleaning up approved reference material, training a small group and documenting acceptance criteria can help in all three futures. Signing a long contract priced around assumed future autonomy may not. Reducing a skilled team before the replacement workflow has proved dependable creates a downside that better model performance next year cannot repair today.

The useful output is a one-page decision map, not a spectacular forecast chart. For every proposed commitment, write the condition that would make it sensible, the condition that would make it regrettable, and the earliest point at which you can observe the difference. Allocate a limited learning budget now. Release larger investment when the required evidence appears. This approach still allows ambition: it simply makes the next step depend on an observable change rather than on the loudest prediction in the room.

Choose actions that still make sense if progress is slower or faster than expected.

Set decision triggers that a manager can actually observe

A vague promise to review the AI strategy regularly does not protect a business from drifting assumptions. Set triggers that connect evidence to an authorised decision. A model release is a reason to run a bounded comparison. A supplier claim is a reason to request the underlying test. Neither should automatically become permission to change customer service, staffing or access to business systems.

For an illustrative quote-preparation workflow, a trigger might be that the new system produces acceptable drafts across a representative sample, handles missing information without guessing, and reduces total preparation and checking time. Management should decide the sample, quality threshold and acceptable error severity before seeing the results. Do not quietly lower the standard because the newest tool looks impressive in the easy examples.

Existing duties remain relevant while forecasts change. The ICO’s AI and data protection guidance covers accountability, lawfulness, fairness, transparency and accuracy. The page also warns that the guidance is under review following the Data (Use and Access) Act. Check the applicable current guidance for the proposed use, rather than treating an optimistic industry outlook as permission to reuse personal information or expand an automated system’s authority.

Triggers should include reasons to slow down as well as reasons to expand. More checking time, repeated customer escalation or uncertainty about data use should lead to investigation or a narrower scope. Assign one manager to each trigger and put the next review in the normal operating calendar. When a decision changes, record which evidence changed it. This makes the strategy explainable to colleagues and avoids a cycle in which every news story starts another unconnected pilot.

A date is a review point. A demonstrated outcome is an investment trigger.

Taking forecasts seriously does not mean betting the business on them

The strongest counterargument is straightforward: if the people building frontier AI expect unusually rapid progress, surely waiting for local proof risks moving too slowly. That deserves a serious answer. Insider expectations may contain information that the wider market has not absorbed. A business that ignores them could miss a genuine change in what customers expect or in what competitors can deliver.

But the Anthropic expectations study itself distinguishes beliefs, reported experiences and model-implied outcomes. It surveyed different groups with different exposure to AI. A gap between their views does not establish a timetable for a UK employer. Even accurate expectations about technical capability leave open questions about integration, liability, customer behaviour and the distribution of commercial gains. Faster progress increases the value of being prepared; it does not remove those questions.

The sensible compromise is to shorten the learning cycle without making the irreversible commitment sooner. Keep a modest approved pilot ready to rerun when a relevant capability improves. Maintain a small set of representative tasks and the current best results. Know which data may be used and who must approve changes. If progress accelerates, this preparation lets you move on evidence instead of assembling the basics in a panic.

This week, choose one material assumption in your current AI plan and rewrite it as a conditional decision. Replace an assertion such as AI will halve administration next year with a named workflow, an observed baseline, a proposed experiment and a trigger for expansion. Tell staff what is being tested and what has not been decided. You will have a plan that benefits from technical progress without requiring any particular forecast to come true. That is a stronger competitive position than either dismissing every prediction or treating one supplier’s future as your budget.

The right response to uncertainty is faster learning, not larger unsupported promises.

Key Takeaways

  • Keep forecast source, survey population and question attached to every material planning assumption.
  • Separate technical capability, actual adoption, permitted autonomy and measured business value.
  • Build three workflow scenarios and prioritise reversible preparations that help across them.
  • Set expansion and stop triggers before testing, with a named manager responsible for each.
  • Use UK adoption figures as context, not as proof that your project will cut operating costs.