Claims analysis AI for construction and infrastructure projects

Most of what ranks for this phrase concerns insurance claims: adjusters, fraud scoring, first notice of loss. This article addresses the other meaning, the one that matters to contractors, consultants, owners and dispute boards, where a claim is a demand for time or money under a construction contract.

TL;DR

• AI claims analysis on projects is document work first: classifying contract clauses, reconciling records, building chronologies and drafting the narrative a claims specialist then tests.
• A rail-infrastructure case study cut documentation preparation from 60 man-hours to about 21, with subject-matter experts validating the approach qualitatively.
• Professional bodies agree on the limits: check that the contract and the law permit AI, protect confidential data, verify every output, and keep decisions human.
• The usable test for any tool is traceability: every finding should point back to a page, a clause or a data row, and every assumption should be written down.
• Public AI tools are the wrong place for confidential project files; governance and data handling come before the first upload.

What claims analysis means on a construction project

A construction claim is rarely one document. It is a chain: a clause that allocates risk, a notice that was or was not served in time, a schedule that moved, a set of records showing what happened on site, and a cost build-up that must be traced to each of those events. The analyst’s job is to show that the chain holds at every link.

The Dispute Resolution Board Foundation’s best practice guidelines on AI describe the realistic role: AI can help review and summarize complex, voluminous project documents and assist with delay and quantum claims, but it is not a substitute for a board’s own review, expertise or judgment. That framing, assistance on volume with judgment retained, is the correct starting point for every other question in this article.

The volume is the problem AI addresses. A mid-sized infrastructure job can generate tens of thousands of emails, hundreds of meeting minutes, dozens of programme revisions and thousands of site diary entries. A human team reading all of it linearly is slow and uneven: the person who reads the correspondence in week one is not the person who reads the revised programme in week six, and contradictions slip between them.

What the software can actually read

The useful inputs fall into four groups.

Contract documents. Conditions, particular conditions, amendments, specifications and employer’s requirements. Research published in 2025 in Computers in Industry showed that NLP and machine learning models can classify construction contract sentences with 89% accuracy and identify related parties with 83% accuracy, in support of risk and responsibility assessment. The figures are a research result on a defined task, not a guarantee for any particular contract set, but they show why clause-level extraction is now practical: notice periods, time bars, change mechanisms and liability caps can be pulled out and tabulated rather than hunted for.

Correspondence and records. Letters, RFIs, instructions, meeting minutes, daily reports, inspection records. The task here is chronology: which event happened first, who was told, and when.

Programme and progress data. Baseline and updated schedules, look-ahead plans, progress photos and measurements. The task is comparison between what was planned, what was instructed and what was achieved.

Cost and quantity data. Tenders, bills of quantities, subcontract accounts, timesheets, plant records and quantities taken from drawings or BIM models. The task is reconciliation: does the money claimed trace to the events claimed?

The tender stage matters more than it appears, because the claim is often a dispute about what was priced. Teams that already structure their tender documents have a head start; the approach is described in construction tender document analysis with human signoff.

How AI finds inconsistencies, gaps and impacts

This is where the work becomes more than summarization. A capable system performs several distinct checks, and each can be reviewed separately.

Contradictions between documents

The notice letter says the instruction was received on a Tuesday; the RFI log says Thursday. The specification calls for one concrete class and the drawing notes another. A system that holds the whole file in view can flag such mismatches systematically, where a person reading sequentially will catch some of them by luck.

Missing evidence

A claim for prolongation costs implies certain documents: the notice, the programme showing the critical path, resource records for the period, and evidence of mitigation. Checking a claim file against the evidence its own theory requires produces a list of gaps. That list is arguably the most valuable output, because it is available while there is still time to find the missing records.

Schedule effects

Delay analysis compares an event with the programme in force when it occurred. Software can extract activities, logic links and dates from schedule exports, match them with the events in the correspondence, and draft the sequence for a specialist to examine. Whether an event actually sat on the critical path, and which analysis method suits the quality of the programme records, remain questions for a scheduling expert. The software prepares the ground; the expert chooses and defends the method.

Cost and quantity issues

Quantities taken off from drawings or BIM models can be compared with the quantities in the claim, and rates can be compared with the tender. Where a claim lumps several causes together, the reconciliation shows which portion has no event behind it. The principles for keeping a human in that loop are covered in AI for BIM and the 30% rule.

What the evidence says about time saved

Published measurements are scarce, and they should be read as case evidence, not as a promise. A case study presented to AACE on a rail-infrastructure project reported that documentation preparation fell from 60 man-hours to about 21, with subject-matter experts validating the approach qualitatively. Two details deserve attention. The saving is in preparation of documentation, the assembly stage, and the validation was by experts reviewing outputs, which is the human check this article keeps returning to.

Customers of Yesper report 50 to 95 percent time saved on projects, together with higher quality because errors that human reviewers missed are caught. That is the customers’ own reporting, and the wide range reflects how different the tasks are: a clean, well-indexed document set behaves differently from a decade of unstructured site correspondence.

Where human review is not optional

The professional guidance is unusually uniform. The DRBF guidelines advise that dispute boards should not delegate decision-making to generative AI, and that where AI assists in preparing a decision, its intended use should be disclosed to the parties in advance and accepted by them. The Construction Management Association of America makes a parallel point: AI can guide and synthesize, but results must be verified by seasoned professionals and not blindly accepted.

Courts are moving the same way. The 2026 Technology and Construction Court Guide in England and Wales introduces a section on AI that requires legal representatives to verify AI-generated legal research and to take responsibility for inaccuracies. That is a UK rule, not a universal one, but it shows where formal proceedings are heading.

For experts the stakes are explicit. Rimkus advised in 2025 that quantum experts must provide supporting documentation for AI-assisted analyses to avoid the black box problem, because evidence without a clear logic path may be treated as inadmissible. In practice, an analysis that cannot show its sources and assumptions is not merely less persuasive, it may be unusable.

A workable process, step by step

The guidance converges on a sequence that any contractor, consultant or owner can adopt.

1. Check permission. Confirm that the contract and the relevant law allow AI to be used on the material. The DRBF guidelines place this first.
2. Decide what may be uploaded. Confidential project, party and site data should not go into public or open AI tools unless confidentiality is assured. White & Case’s summary of the guidelines repeats this point. Internal data-handling questions are laid out in AI data security in construction.
3. Index the record. Assemble the contract set, correspondence, programmes, site records and cost data in one place with consistent naming and dates.
4. Extract and tabulate. Have the system pull out clauses, notice dates, events and quantities into tables that cite their source pages.
5. Test the theory. Ask what evidence the claim’s logic requires, and list what is missing or contradictory.
6. Verify. A named person checks each finding against the source document. Assumptions the system made should be written down, so they can be reviewed like a colleague’s.
7. Disclose where required. If the use bears on a decision or an expert report, tell the parties in line with the contract and the forum’s rules.
8. Retain responsibility. The signatory is a person, whatever drafted the first version.

Teams that want a formal structure around steps 1, 2 and 8 will find one in a practical AI governance framework for construction.

Risks to manage

The DRBF guidelines list the main hazards: confidentiality and security breaches, bias, hallucinations, and use that conflicts with the contract documents or applicable law. Each has a specific counter.

• Confidentiality: keep project data inside tools whose handling terms the organization has reviewed.
• Hallucination: require every statement to carry a citation to the source page, and reject any that does not.
• Bias: a system summarizing only one side’s correspondence will tell one side’s story. Feed it the full record.
• Contract conflict: a clause may forbid or condition the use of AI by the parties, so read before use.

A further risk concerns automation of contract terms themselves. Global Arbitration Review notes that self-executing contracts may automatically trigger payments, penalties or dispute procedures, yet their deterministic terms may not account for nuanced circumstances and can produce harsh outcomes that conventional interpretation would avoid. The same guide observes that AI operating across several regions may raise novel jurisdictional questions, with possible consequences for enforcing awards. For international infrastructure work, that is a reason to involve counsel early.

What to ask of any claims analysis tool

The difference between tools shows under complexity. A general-purpose model summarizes a letter well and fails when the task requires a geotechnical report built from raw CPT protocols, quantities extracted from a BIM model, or one comparable set of numbers from a dozen tenders in three currencies. Those are the jobs where a claim is won or lost, and the distinction is discussed in what sets specialized engineering AI apart.

Six questions separate serious tools from demonstrations:

Question	What a good answer looks like
Does every finding cite its source?	Page, clause or data row, openable in one click
Are assumptions recorded?	Written down, reviewable and editable
Does it handle your file types?	Contracts, schedules, drawings, BIM, spreadsheets, scans
Can it work end to end?	Produces the deliverable, not only an answer in a chat window
How is data handled?	Clear, reviewable terms, consistent with your contract
Who signs off?	A named human, built into the workflow

Perspective

We build Yesper as an AI civil engineer, and claims work shows why that framing matters. A claim is an engineering argument before it is a legal one: what was built, when, in what sequence, against which quantities. Software that only answers questions cannot carry that argument. It has to produce the chronology, the quantity reconciliation and the draft narrative itself, and it has to write down every assumption it made so that a reviewer can challenge it the way they would challenge a colleague’s.

The sceptic’s objection is usually the right one: who is accountable? The answer is that the engineer or claims specialist remains accountable, and the tool’s value is that it makes accountability easier to exercise. When every statement links back to a source, review becomes a matter of checking, not rediscovering. Our customers, including teams at AFRY, NRC Group and Netel, report that errors human reviewers had missed were caught this way, which is the quality half of the argument and the half most often forgotten.

What we would not do is pretend that more automation means less expertise. The volume of documents on a modern infrastructure project has outgrown linear reading. The expertise is still needed, aimed at the judgment calls instead of the filing.

Benjamin

How Yesper fits into claims work

Yesper is built for construction and infrastructure teams: it searches project documents, checks them against regulations, detects errors, takes off quantities from BIM and drawings, and creates deliverables such as reports, tenders, presentations and spreadsheets, with traceability to the source. Agents can be configured for different project roles, so a contract manager, a planner and a quantity surveyor each work with the same underlying record. Contractors, consultants and owners can book a demo to see the platform. For the broader picture of how this kind of system differs from a chatbot, see what an AI civil engineer is.

Can AI replace the claims analyst?

Not on the current evidence. CMAA states that AI is a resource for guidance and synthesis but cannot currently replace the experienced judgment that construction dispute resolution requires. What changes is the distribution of the analyst’s day: less time locating and transcribing, more time on causation, entitlement and negotiation. Organizations that treat the technology as an organization-wide capability, not an individual shortcut, see the larger gains, a theme explored in turning AI pilots into project gains.