Here is the uncomfortable part of buying AI in 2026. The tool you commit to today will look dated in eighteen months, and the money you spend committing is mostly sunk. Meanwhile the thing you learn by trying it — how your team actually uses it, which process it fits, where it breaks — stays with you even when the tool is replaced.
That imbalance is the whole subject of a paper posted to arXiv on 14 September 2026 by Gaurav Tewari, titled Pilot Early, Commit Late: A Real-Options Model of Enterprise AI Adoption under Rapid Technological Progress. It is a mathematical model, not a survey, and it contains no case studies. But its conclusion is unusually blunt for this genre: a sensible company responds to fast-moving AI by experimenting more, and by committing less.
Why moving fast can be the wrong call
The paper frames AI adoption as a timing problem, not a spending problem. A business has three moves, and they are not variations of each other:
- Deploy now. You earn the benefit this quarter, but you also build around today's model, today's pricing, and today's limits. The paper calls the downside "architectural obsolescence" — the risk that next year's version makes your integration redundant.
- Pilot. You deliberately give up some current benefit to build knowledge that only exists inside your company. Nobody else can hand you the answer to "does this work in our quote process, with our data?"
- Wait. You keep your budget intact and your options open, and you learn nothing.
The result that surprised me is the second one. When the technology frontier is improving quickly, faster progress can make immediate deployment look worse, not better — specifically when the setup you build captures only a slice of the future improvement. If your system is welded to today's model and tomorrow's model is far better, you have paid for a bridge to the wrong bank. That is not an argument against AI. It is an argument against the permanent version of it.
Waiting is not the same as piloting — and the gap is where your money is
Most owners I talk to collapse two very different choices into one. Doing nothing and running a small pilot both keep your options open. Only one of them teaches your team anything.
Tewari's third result puts a condition on that: a pilot beats waiting exactly when the value of the knowledge it produces is worth more than the benefit you gave up to get it. That sounds obvious written out. It stops being obvious when you notice how little most "AI pilots" are designed to teach. If the pilot is a thirty-day trial of a tool that a salesperson set up for you, and nobody inside the business owns it, you have paid the cost of a pilot and collected the return of waiting.
The pilot is the product. The tool is disposable.
The practical reading of a real-options timing model
The one question that decides whether to commit now
The paper offers a single test that a non-technical owner can actually run, and it is the fifth result. There is a threshold of "modularity" above which committing now is clearly the better move. Translated: if you could swap the AI piece out in an afternoon without rebuilding the rest of your setup, the obsolescence risk is small and you should just go.
So ask this about whatever you are considering:
- If a better tool appeared in six months, how painful would it be to switch? If the answer is "we'd export our data and point the new tool at it" — that is modular. Commit, and stop agonising.
- Is the AI wired into the middle of something you cannot replace? A booking system, a bespoke client database, an ERP with a custom module. That is not modular, and that is exactly where a fast-moving frontier punishes you.
Notice that this reframes the decision. It is not "AI or no AI". It is "which of my AI plans are easy to undo, and which ones are permanent". Easy to undo — do it now. Permanent — pilot, and set a date to look again.
How to run a pilot that actually earns its keep
The model is abstract, but the version that fits a ten-person business is not. Four things, all of which you can set up this week:
- Pick one process, not a department. "We'll use AI in the office" teaches nobody anything. "We'll use it to turn rough site notes into customer quotes" is testable. One process, one output, one person who owns the result.
- Time-box it, and write the end date on the calendar. Thirty to sixty days is plenty to learn whether a tool fits. An open-ended trial quietly becomes a permanent subscription with no decision behind it.
- Pick the number before you start. How long does the quote take today? How many go out per week? If you cannot measure it now, you will not be able to justify the spend later — and you will not be able to tell a good tool from a good demo.
- Bias towards tools you can leave. Monthly billing, exportable data, no custom build for the pilot phase. You are buying information, so keep the exit cheap.
Then, on the review date, make an actual decision: commit, extend once with a reason, or stop. "Let's keep going and see" is not a decision, it is a subscription.
What to stop doing — the half nobody sells you
This is where the timing model pays for itself, and it is the half that no vendor will ever put in a proposal.
Stop signing multi-year AI commitments. The entire logic of the paper is that the technology keeps moving. A three-year lock-in prices that movement against you. If a supplier needs a multi-year term to make the economics work, that is their problem, not yours — and in a market this fast, it is a warning sign, not a discount.
Stop paying for tools that are being absorbed into something you already own. Assistant features keep collapsing into the platforms businesses already run — the mail suite, the accounting package, the CRM. When yours adds the capability natively, the standalone subscription you bought for it last year is now a duplicate charge. Run the list once a quarter and cancel what has been swallowed.
Stop treating the failed pilot as sunk cost. A pilot that ends with "this does not fit our process" has done its job. It cost you a month and saved you a commitment. The expensive outcome is not a stopped pilot; it is the one nobody ever stopped evaluating.
Frequently asked questions
Does this mean I should sit still and wait for the technology to settle?
No — and that is the point the model makes. Waiting and piloting are different moves with different returns. Waiting keeps your money and teaches you nothing; piloting costs a little now and builds knowledge that survives the next tool change. When the frontier is moving fast, the right response is more experimentation, not less. Just keep the commitment small until you know more.
Is this paper peer-reviewed? How much weight should I give it?
It is an unreviewed preprint on arXiv, posted 14 September 2026, and it reports no empirical validation against real company data. The author is explicit that the model's assumptions do the work. Treat it as a clean way to structure a decision, not as proof of what will happen in your business. I would not reprice a contract on the strength of it — but I would absolutely use its two questions in your next AI meeting.
We already rolled AI out everywhere last year. Is that a mistake?
Not necessarily. The result is conditional: committing now is fine when what you built is modular — when you could replace the AI piece without rebuilding everything around it. If your setup is airy and swappable, you did the right thing. If it is welded into the one system you cannot change, the review worth doing is not "was that wrong?" but "what is our worst-case cost if this piece is obsolete in a year, and can we reduce it now?"
We are three people. Does any of this apply without an IT department?
It applies more, if anything. You have less slack to absorb a bad commitment and no one whose job is to watch the technology move. Your version of the model is simpler than the paper's: one process, one number, one review date, monthly billing. At that size, the pilot is not a strategic project — it is an ordinary week's work you decide to stop or keep.