Why generic AI copilots struggle with construction claims
General-purpose AI assistants are useful, but construction claims expose their limits: messy records, contract-specific entitlement, and the cost of a wrong number. Where horizontal copilots fall short, and what actually matters.
Every contractor is being told they are behind on AI, and most are experimenting with a general-purpose assistant to prove they are not. For a lot of office work, that is the right instinct. For construction claims specifically, it runs into limits that are worth understanding before you build a process around it, or judge the whole category by what a generic tool can do.
The three assumptions a generic copilot makes
A horizontal AI assistant is built for the average knowledge-work task. To be useful across everything, it quietly assumes three things that hold in most offices and fail on a live construction claim.
It assumes clean inputs. A general copilot works best when you hand it a tidy document and a clear question. A construction claim is the opposite: the evidence is scattered across emails, instructions, RFIs, programmes, site diaries, photographs, and cost systems that do not talk to each other, much of it contradictory or incomplete. The hard part of a claim is not writing it up once you have the material. It is assembling and reconciling the material in the first place, which is exactly the part a generic tool is least equipped to do.
It assumes general knowledge is enough. A horizontal model knows a great deal about the world in general and very little about your contract in particular. Whether you are owed anything turns on specifics: the exact clause, the notice deadline it imposes, whether that deadline is a condition precedent, and how the Particular Conditions or Z-clauses on your project have amended the standard form. A generic tool will produce a fluent, confident answer about the standard position and miss that your contract changed it, which is the difference between a valid claim and a forfeited one.
It assumes the cost of a mistake is low. If a copilot writes a slightly awkward email, you fix it and move on. If it misreads an entitlement or builds a quantum figure it cannot defend, the mistake can cost millions and you may not discover it until a resisting counterparty pulls it apart. General-purpose tools are tuned to be helpful and fluent, not to be right about a number that has to survive a dispute. Fluency is not the same as defensibility, and on a claim only defensibility pays.
The verification problem underneath all three
There is a deeper issue that ties those three together. The value of an AI tool in serious work is not that it produces an answer. It is that it produces an answer you can trust without redoing it yourself. A generic copilot that cannot check its own work has not removed the burden from your team. It has moved it, from doing the analysis to auditing the analysis, and on complex claims that second job can take as long as the first.
Anyone who has worked alongside general-purpose AI on high-stakes documents has seen this: the output looks plausible, so it has to be checked line by line, and the checking consumes the time the tool was supposed to save. On a construction claim, where a plausible-but-wrong entitlement or quantum figure is worse than no answer at all, the ability of a tool to verify its own output, and to show its working against the source records, matters more than how fluently it writes. That is the capability a horizontal copilot is not built to provide.
What this does and does not mean
None of this means AI has no place in construction claims. The opposite is true: claims are an unusually good fit for AI, because the core task is reading and reasoning across large volumes of document and contract, which is what these models are fundamentally good at. The point is narrower. It means the tool has to be built for the conditions a claim actually presents: fragmented records rather than clean inputs, contract-specific entitlement rather than general knowledge, and verification built in rather than left to an already-stretched team.
It also does not mean general copilots are useless to a commercial team. They are fine for a first draft of routine correspondence, for summarising a document you already understand, for the everyday tasks where an approximate answer is good enough and easy to check. The mistake is assuming that because a generic tool handles those tasks well, it can be trusted with the entitlement and quantum work where the records are messy, the contract governs, and the number has to hold. Those are different jobs.
How to evaluate a claims tool with this in mind
If you are assessing AI for claims work, three questions separate a tool built for the job from a general assistant pointed at your documents:
Does it expect messy, fragmented records, or clean inputs? The realistic test is whether it can work with the disordered documentation a project actually produces, not a tidy sample.
Does it understand your contract, or construction in general? A useful tool knows what a compensation event, a Notice of Claim, or a measured-mile analysis is, and can account for the amendments on your specific contract, not just the standard form.
How does it handle verification? Ask how it checks its own output and traces conclusions back to the source records. A tool that generates a confident answer you then have to fully re-audit has not saved you the work.
This is the reasoning behind how Hecato is built: for the data reality of a live construction claim rather than the clean-input, general-knowledge world a horizontal copilot assumes. See how Hecato approaches claims recovery.