Cheap to Build. Expensive to Fail.
AI compresses build cost, compresses ownership cost more slowly, and does nothing at all to failure cost. Most technology decisions are still argued on the first number.
A proposal for a new system contains a number. Almost always, it is the cost of building it.
That number was never a good summary of the decision. It is now actively misleading, because it is the one number AI is changing fastest.
Three economics, not one
Any system a company depends on has three distinct cost profiles, and they behave differently under cheap creation.
Build cost
What it takes to create the thing: people, time, tooling. AI compresses this hard, visibly and immediately. This is the part everyone has noticed.
Ownership cost
What it takes to operate, understand, govern, secure, maintain, integrate, support, audit and evolve it — across its whole life. Some of this compresses. None of it disappears, and the parts that resist compression are the parts that involve responsibility.
Failure cost
What happens when the system is wrong. This is not a property of the system at all. It is a property of the process the system supports, and cheap creation does not touch it.
The asymmetry is the point. Build cost falls by an order of magnitude; failure cost does not move. So the ratio between them changes, and every intuition calibrated on the old ratio is now wrong in the same direction.
A five-hundred-euro internal tool that controls a fifty-million-euro operational process is not a five-hundred-euro risk.
What failure actually costs
Failure cost is uncomfortable to estimate, which is part of why it is skipped. But the categories are not mysterious, and naming them is usually enough to change a decision.
- Production interruption, and the recovery that follows it
- A financial decision taken on a wrong number
- Data exposed to people who should not have it
- A wrong quality decision that reaches a customer
- A missed delivery, and the commercial consequence of missing it
- A regulatory failure, including the reporting obligation it triggers
- A wrong output sent to a customer under the company’s name
- Damage to equipment, or a safety event
- Trust, which is the only item on this list with no recovery procedure
Notice that none of these scale with the cost of the system. They scale with the process. A tool that was assembled in an afternoon and a system that took two years to build carry identical failure costs if they sit in the same place in the operation.
Why the wrong number wins
Build cost is measured, approved and reported. It appears in a budget line, it has an owner, and someone is accountable for it being exceeded. Failure cost appears nowhere until it is realised, at which point it is described as an incident rather than as a cost that was accepted earlier without being written down.
This is a straightforward organisational bias, and it was tolerable while build cost and consequence were loosely correlated. Expensive systems tended to be important, and the expense bought scrutiny along the way. That correlation is what is breaking.
Why do organisations still evaluate technology by creation cost when business risk depends on operational consequence?
The critical process test
One question restores the missing dimension without requiring a model or a workshop.
What happens if this is wrong for one day?
The answer sorts a tool into one of four levels — convenience, productivity, operational dependency, mission critical — and each level implies a different standard of ownership, testing, monitoring and fallback. The scale is conceptual on purpose. Precision here would be false, and the classification is doing the work, not the number.
It applies to more than software. A spreadsheet, an AI agent, a low-code application, an integration, an automation, a machine-vision inspection, a planning system and a robot cell all answer the same question, and all of them can be wrong in ways that take a day to notice.
What changes if you use it
Three things, and none of them slows a company down.
Most things get easier, not harder
The majority of what gets built is low-consequence, and the test says so explicitly. Removing ceremony from that category is what makes the discipline affordable everywhere else.
The expensive cases get named early
A system that will carry a critical process is identified while it is still cheap to give it an owner, a test and a fallback — rather than during the incident review.
The argument moves to the right question
Instead of debating whether a team should have built something, the conversation becomes what the business now depends on. That is a question with an answer.
For owners, boards and buyers
The same logic reads directly as an asset question. A business whose critical processes rest on tools nobody owns has an unrecognised liability: the rebuild will eventually be paid for, and its timing is not a management decision.
It is also unusually easy to test in a diligence. Ask which processes would stop this week if a system were wrong. Ask what carries them. Ask who owns those things by name. The gap between the answers is the finding — and it is the operational half of what technology and AI due diligence is for.
The pattern behind all of this, and where it came from, is the Excel problem.