An executive comparing AI services can receive two apparently incompatible messages: computing is becoming much more capable, and the bill for using it is becoming harder to predict. Both can be true.
More capable systems can attempt more work. They can also use longer contexts, make more calls, try several approaches and require substantial evaluation. A cheaper unit of inference does not guarantee a cheaper completed process.
The question for enterprise strategy is therefore how changes in computational scale affect a specific decision. They can open a previously unattractive workflow, alter the economics of a supplier or make a technical constraint less important. They do not provide a universal calendar for automation.
Three different sources of progress
Moore's law concerns a historical pattern in transistor density. It is frequently used as shorthand for all improvement in computing, but AI progress depends on several distinct inputs.
Hardware and systems engineering can increase useful throughput through specialised chips, memory, networking and parallel computation. Algorithmic improvements can reduce the resources needed for a particular level of task performance. Organisations can also spend more total resources on training and serving systems. Those changes interact; they are not the same curve.
Sevilla and colleagues' study of compute trends across three eras of machine learning, published in 2022, examines historical training-compute patterns. It helps explain why transistor density alone is an incomplete account of AI development. Historical training expenditure does not establish a corresponding rate of progress for every capability or enterprise workflow.
Keep that distinction in a strategy presentation. A chart of compute investment describes an input. A benchmark describes performance under a defined test. An operating result describes what happened in a process. Moving from one to the next requires evidence.
Scientific progress demonstrates possibility within a domain
The 2021 AlphaFold paper is a useful example of an important capability achieved through a defined scientific problem. Protein-structure prediction had clear evaluation questions and substantial domain knowledge behind it. That result matters on its own terms.
It does not show that a general assistant can manage an industrial operation. Nor does it mean an enterprise must wait for a similarly dramatic breakthrough before using AI productively. Some valuable applications improve an ordinary task by an ordinary amount, with less spectacular technical requirements.
The executive lesson is to ask what would make progress legible in the relevant domain. What is the reference task? Which errors matter? Who can verify the output? Are improvements concentrated in the routine cases while the difficult exceptions remain unchanged?
This makes scientific examples informative without turning them into evidence for an unrelated business promise.
Follow the cost of an accepted task
Consider a hypothetical service that helps engineers answer questions using an approved document library. It retrieves sources, prepares an answer and either provides a usable citation or exposes an unresolved question.
The cost of one model call is only part of the cost of one accepted answer. Retrieval may require additional services. A difficult question may create several calls or a longer context. An engineer may need to verify the cited instruction. A wrong answer can create rework elsewhere. Unanswered questions may still require the original process.
To compare designs, use a common work sample and acceptance standard. Measure the proportion of answers that satisfy it, the effort needed to confirm them and the total resources consumed. Include routine and difficult cases, and report them separately where the difference matters.
A smaller model with good retrieval may serve routine questions well. A larger model may justify its cost on complex synthesis. A rule or direct search may be sufficient when the required fact is unambiguous. Routing is useful only if the system can recognise the cases and the savings exceed its added complexity.
This is why the cost per accepted task is a more useful management measure than a model's advertised unit price. For an external service, include support, minimum commitments and integration. For an internal service, include operators, monitoring, security, evaluation and maintenance. Use the same time horizon for both.
Plan for normal, difficult and degraded operation
Demand forecasts should distinguish normal usage from peaks and recovery. A document service may be lightly used most days and heavily used before a shutdown or tender deadline. Average consumption can conceal the service requirement that actually determines capacity.
Now ask what happens when the preferred service is unavailable, slower than expected or changes its behaviour after an update. A fallback could be another provider, a smaller supported task or the manual process. Each carries a different cost and limitation.
Test that fallback with the people who will use it. A technically reachable alternative is insufficient if its outputs fail the acceptance standard or its data terms do not fit the application. Keep an evaluation set that can detect meaningful regressions when a model or retrieval component changes.
These measures make a capacity decision reviewable. They also help explain when paying for resilience is justified. A service that supports a critical production deadline may warrant different commitments from a convenience tool used for internal drafting.
Use scenarios to expose the decision that could go wrong
A useful scenario exercise does not require a prediction of frontier compute in 2030. It asks how a commitment performs under different plausible conditions.
If capability improves and delivered costs fall, which backlog items become worth testing? A company with accessible data and an evaluation method can answer sooner. A company tied to a large fixed contract may benefit less from the lower prices than its technology forecast suggests.
If capability improves but demand and verification costs also rise, can the business still make the workflow economic? This scenario rewards clear task boundaries, effective retrieval and attention to the review burden.
If progress on the required task plateaus, does the proposed investment retain value? Improved document access and a reliable integration layer may still help. A business case that depends entirely on an untested future ability needs a different funding structure.
If service concentration or supply constraints increase, is the fallback workable at an acceptable cost? That question may justify flexibility even when the current supplier wins the evaluation.
The appropriate response can differ by workload. Avoid using the same forecast to justify an urgent infrastructure purchase and a promise that infrastructure costs will soon become negligible.
Make the next commitment smaller than the uncertainty
Computational progress gives leaders more options. Realising them still requires a bounded problem, usable inputs, task-level evaluation and an operating owner.
Before approving a large commitment, ask for one comparison that connects capability to the complete cost and quality of the work. Ask what assumption would change the recommendation, who will notice that change and how the company can respond. This is a more durable discipline than trying to identify a permanent winner in a moving technical market.
Use the AI ROI Calculator to make benefit assumptions visible and Build, Buy or Partner to compare the delivery commitments. The calculation should make uncertainty easier to discuss, rather than hide it behind a growth curve.