Construction AI pilots mostly die. Here is the pattern.

Somewhere in most large contractors there is a corner of a site office with a folding table in it, a stacking chair upturned on top, and a curling poster taped to the partition with a QR code that no longer resolves. Six months earlier that corner was the AI trial. The licence may well still be paid. The innovation lead is still enthusiastic when you ask. And every drawing that reached the workface last week travelled by exactly the route it travelled the year before.

Pilots like that do not fail loudly. They simply stop being mentioned. Most of them, in my experience, were missing the same three things, and they were missing them on day one: nothing tying the tool to the information the site is actually allowed to build from, nobody with the authority to change how work gets done, and no point in the week where using it is compulsory.

The adoption headlines and the funding rounds are in the December 2025 register. The burial is much quieter than the announcement, and it usually happens on jobs where everybody involved is behaving perfectly reasonably.

What dying actually looks like

20|A trial, in the usual shape, is time-boxed and runs on a live or recently finished job. Someone with a budget and an innovation remit books a sandbox. A folder of last week's PDFs is uploaded. A chat window summarises a drawing, convincingly, in front of an audience. A slide says the organisation is evaluating. And the live work — the transmittal, the RFI, the inspection, the daily report — carries on inside the systems that already issue and withdraw information.

Dying has nothing to do with failing a benchmark; most of them do fine on the demo, which is part of the problem. What happens is that the job never adopts the trial as the way issued work gets done. The licence stays current, the hut still plots from the issued set, and the unofficial set in the trailer is still the one the gangs trust.

None of this needs a survey to recognise. Anyone who has sat through three of these can describe the fourth before it starts.

Three things missing

Failed deployments cluster, and the clustering is not subtle.

30|1. Nothing anchors the trial to the information the site is allowed to build from — these sheets, this model state, this revision, released to these companies, for this purpose. 2. Nobody owns the exception, the data, or the switch-off. There is a champion, which is a different job. 3. The trial never enters a production workflow. It gets shown to visitors, and Tuesday runs the way it always ran.

One absence is enough to finish it off. All three is the usual arrangement.

The flattering reading is that the organisation bought intelligence at the same time as it bought a pilot. Folders have names. Models have federations. Someone is on AI. The plotter still sings. In that version the demo is the work, opening it is the evaluation, and a thumbs-up in a steering pack counts as close-out.

Nothing anchors it to the issued set

Start with the corpus, because that is where the trial gives itself away first.

40|The issued set is not whatever landed in the download folder. It is a dated act: named containers, a revision, a suitability or purpose, a list of recipients, and a predecessor that was withdrawn. ISO 19650 is unglamorous about this. Work in progress is not Shared, and Shared is not Published. A chat window pointed at a ZIP of last Thursday's export is reading a pile of files, and a pile of files has no opinion about what the site is allowed to build.

Without that anchor, every answer floats. The model will be fluent about a beam depth that was superseded on the Monday. It will happily reconcile a register against sheets that were never transmitted to anybody. It will summarise a method statement that is not the one on the permit board. The site will still build the issued set, because that is what issued means, and the trial's answer will simply be interesting.

Trials skip the anchoring because anchoring is the expensive part. It needs a register that is true, a transmittal history that is complete, and the thankless habit of getting the old plot back off the people who still have it in a drawer. A folder dump takes an afternoon. It also produces a very confident liar. The unofficial set in the trailer is the paper version of the same problem: when the official record cannot be trusted to name the current instruction, people keep their own copy of what they believe was agreed.

So it is worth asking a trial which containers, which revision, which recipients, which purpose. If it cannot answer, what you have is retrieval over a picnic of files, and no amount of model quality upstream changes that.

Champions and owners

50|Ownership is not the name on the kick-off slide.

Every pilot has a champion: someone in digital, someone in innovation, a curious quantity surveyor, a design manager who came back from a trade show with an idea. Champions are necessary and I have never seen a trial begin without one. What they usually do not have is the authority to change how issued work is done, or to put on record, with a date and a name against it, that the trial was wrong and the issued information stands.

Unowned trials go local fast. One package decides the chatbot is useful for RFIs; the package next door still writes them in mail. The document controller was never invited, because nobody treated the trial as an information-management act in the first place. Then the secondment ends, or the financial year closes, or the person who understands the tool leaves for a contractor that still plots from a USB stick — and the sandbox sits there while the labour on site notices nothing at all.

There is a second owner missing, and it is the one that matters on a bad day. Models are wrong. Drawings conflict. A retrieved clause turns out to be from a different contract. Somebody needs the standing job of saying stop: this output does not issue, this answer does not go to the workface, this is not the current revision. If that person is the vendor, the only decision that mattered has been outsourced. If that person is everyone, it is nobody.

Then there is the data. Who may delete the upload. Who may export the prompts. Who is holding the folder when the trial ends. A pilot that has not named those three is already written as a sunset, and it is only waiting for a date.

60|## It never gets into Tuesday

A workflow has an owner, a next action, a due state, and a close condition that amounts to more than running the demo again for a different audience.

The production workflows on a job are the ones that happen every week whether or not anybody is evaluating software: issue and withdraw drawings, raise and close RFIs, inspect and record, write the daily report, move a container through a gate. The trial sits alongside all of that, politely. The pilot is a Thursday meeting; the job is a Tuesday habit.

"We will integrate later" kills more trials than any technical limitation, and it manages to sound like a plan while doing it. Later means after the evaluation window, after the bonus cycle, after the job has already taught itself that the sandbox is optional. Optional tools get dropped the first week the programme gets tight. The unofficial set never gets dropped, because it is how people finish the day.

There is usually no evaluation set either, which is what would have made "later" honest — an agreed pile of questions the live job already asks, this RFI, this revision conflict, this inspection hold point, and some rule about what a right answer would look like. Without it, success is a feeling in a steering pack, and feelings do not survive contact with a claims file.

70|Close-out, if the word is to mean anything, is one of two recorded acts:

The production path changes. A named workflow now runs through the trial, anchored to the same issued containers, with a named owner for exceptions, and the old path is withdrawn from the people still using it.
A dated decision rejects it: wrong corpus, wrong owner, wrong workflow, sandbox switched off.

If neither act exists, the pilot is not live, whatever colour it has been painted on the portfolio slide.

Why the pattern holds

They die because dying was never the failure the pilot was hired to prevent.

80|The pilot was hired to prove curiosity, and it does that job well. That proof is genuinely useful in a bid, in a digital appendix, in a year-end pack. It is also very cheap next to the work that follows: anchoring the corpus to issued containers, naming somebody who can stop a bad answer, inserting the tool into a Tuesday workflow, withdrawing the workaround, then walking out to the hut to check that the superseded depth is no longer taped to the wall.

The time-box also protects the people who would otherwise have to decide. A four-week trial is an alibi — nobody gets blamed for a sandbox that showed promise. A named workflow with two overdue exceptions is a management object with somebody's name on it. Given the choice, most projects take the alibi, and I do not entirely blame them.

The third reason is informational rather than moral. A live deployment crosses systems a sandbox never enters. The answer lives in a chat. The decision lives in a comment, or an email thread, or a corridor. The change lives in a native model. The instruction lives, if it lives anywhere, in a published PDF and a transmittal. Until those are one record, "in production" has nowhere single to be true. The clash report nobody closed is the same failure with a different engine: output, no close-out. Detection is a count. Coordination begins when somebody can still say, months later, what was decided, which version went out, who received it, and which answer was allowed to stand.

What living would look like

You do not need a better adjective than transformational. You need something else to measure.

90|Measure whether the trial reads the current issued set rather than a folder someone dragged across. Measure whether an owner can stop an output and pull back a wrong instruction, rather than whether a champion is still on the distribution list. Measure whether Tuesday's work goes through the tool or around it.

And stay open to the awkward case: a trial with all three — an anchored corpus, a named owner of exceptions and data, a production path with a close condition — that the job abandoned anyway. I have not come across many. If you have one, it is worth writing down, because it would say something the three absences do not.

Put every live trial on one of two papers before the next bonus cycle, and make the person who can change how issued work is done write it — the principal contractor's information manager, or the package lead, not the innovation champion. Either a named Tuesday workflow that reads the current issued set, with someone who can stop a bad answer and pull a wrong instruction back, or a dated rejection and the sandbox switched off. Keeping the licence while Tuesday runs around the tool is the option that has already failed. The switch costs the true register, the withdrawn workaround, and the authority to walk out to the hut. It does not cost another demo. If those three cannot be named, let the poster curl.