The two-week test before emerging tech enters a budget

Every year a technology arrives that is genuinely capable and not yet dependable, and the gap between those two states is where budgets go to die. The question is never whether it is impressive. It is whether it is ready for the specific thing you want it to do.

Five questions before the money moves

1. What breaks if it is wrong, and who finds out? A technology that fails visibly and cheaply can go into production early. One that fails silently into a financial ledger cannot, however good the demonstration was.

2. Can you measure it against your own data? Not the vendor's benchmark. Two hundred of your own cases, with answers you agree on. If a vendor discourages this, that is the answer.

3. What is the cost per transaction at your volume? Model pricing is quoted per token and budgeted per month. Multiply it out at your real volume, including retries and the cases that go to a human anyway, before it is committed.

4. Who maintains it in year two? Every emerging technology carries a maintenance tail that is invisible at purchase: re-evaluation, version upgrades, drift. If no named person owns that, you are buying a pilot, not a capability.

5. Is it reversible? Can you turn it off on a Tuesday and run manually for a week without a crisis? Technologies you cannot switch off should be adopted a year later than ones you can.

The three-state rule

We sort emerging technology into three states, and the state determines what we are willing to put it near.

Experimental - works in demonstrations, fails in ways nobody has characterised yet. Fine for an internal process where a wrong answer costs someone ten minutes. Not near money, customers or regulators.

Dependable in a corridor - reliable for a narrow, well-specified task, with a measurable failure rate and a human path for the rest. This is where most useful AI work lives right now, and where most of the value is.

Plumbing - boring, cheap, documented, hireable. RPA is here. Nobody writes conference talks about it and it quietly runs a large share of European back offices.

Most disappointment comes from treating a technology in state one as though it were in state three, encouraged by marketing that describes state two.

The cheapest test available

Take one real process. Run the technology against ninety days of its actual history, offline, where a wrong answer costs nothing. Compare it to what people actually did. That exercise costs a fortnight and has cancelled more bad programmes in our work than any architecture review.