Guides

Can You Create a Construction Risk Register With AI and Structured Records?

William Doyle
William Doyle
CEO at Gather
14 min read
July 2, 2026
Can You Create a Construction Risk Register With AI and Structured Records?

What you need to know

  • Stop maintaining a document. Read the records you already keep. A document rots; a read is as current as this morning's record.
  • You need two things: structured records carrying a category, a reason and a quantity, and AI to normalise the mess and read the free text.
  • Normalisation turns five ways of writing the same event into one count. That count is your likelihood rating, evidenced rather than guessed.
  • The sharpest risks live in free text. AI lifts them onto the register with the source record attached.
  • It automates the admin, not the judgement. Horizon risks stay yours. And the RICS AI standard has required documented human oversight since 9 March 2026.

Executive summary

Most risk registers are fiction by week three. Built once in a workshop, then left in a folder while the real risks pile up daily in your records.

The fix: stop maintaining a document. Read the records you already keep.

You need two things. Structured records with a category, a reason and a quantity, and AI to normalise the mess and read the free text.

It automates the grunt work, not the judgement. The horizon risks you can see coming stay yours, always.

One caveat with teeth: the RICS AI standard is mandatory as of March 2026. Documented human oversight is the job now, not a nice-to-have.

Most risk registers are fiction by week three

You build it in a workshop. Everyone in a room, a spreadsheet on the screen, likelihood and impact scored one to five from memory and gut feel. It looks thorough. It feels like control.

Then the job starts. The register goes in a folder, and nobody opens it again until the next steering group, when you dust it off and recolour a few cells so it looks alive. The scores do not move because nothing behind them has moved. They were never connected to anything in the first place.

Meanwhile, the real risks are being written down every single day. On site. In the diary. In the progress records. In the allocation sheets. And not one of them is wired into the register on the wall.

I learned this the hard way. I nearly lost £20m on the North West Electrification Programme because our records were scattered across notebooks, spreadsheets and email chains. The risks were all there in the detail. Standing time, late responses, access we never got. We just had no way to see them together, in time to act, while the money was still recoverable.

So here is the question this piece is really about. Not whether you should do a risk workshop. You should. The question is whether your register has to stay a static document that decays the moment the workshop ends, or whether it can become a live read of the records your teams are already keeping.

The honest answer is that it can, and it does not need a data science team to get there. It needs two things. Records that carry structure, and AI pointed at the jobs a human should never have to do by hand.

Why the workshop register decays

A workshop register is a point-in-time snapshot dressed up as a live tool. It captures what the room believed on a Tuesday in mobilisation. That is useful once. It is close to worthless a month later, because the thing it was meant to track has kept moving and the register has not.

The frustrating part is that the raw material for a truly live register already exists on every job. Contemporaneous site records are the foundation of every compensation event assessment you will ever make. Site diaries, labour records, plant allocation, progress against the programme. The commercial team knows this instinctively, because when a claim gets serious the first thing anyone asks for is the records.

If those records are already the evidence base for entitlement, they are already the evidence base for risk. The two are the same data looked at from different ends. Entitlement asks what happened and who pays. Risk asks what is happening repeatedly and where is it heading. Same records. Different read.

The only reason we treat them as separate exercises is that, historically, connecting them by hand was too much work. Reading every shift comment across forty locations to spot a pattern is nobody's idea of a Tuesday. So it never happened, and the register stayed fiction.

That is the specific job AI is genuinely good at. Not judgement. Reading at volume, and imposing order on mess.

Ingredient one: records that carry structure

Start with the difference between a memory and a risk event.

A diary entry that says "wet, slow day" is a memory. It tells you nothing you can count, compare or act on. A diary entry where the lost afternoon is coded as adverse weather, against NEC4 clause 60.1(13), with the planned quantity, the actual quantity and the reason, is a risk event. It is dated. It is evidenced. It is quantified. And it already has a clause number attached to it.

Same effort on site. Completely different value on the other end.

When your teams record a variance with a category and a reason, they are not doing admin for the sake of it. They are logging a risk that carries its own contractual meaning. And a good deal of what happens on site maps cleanly onto the compensation event schedule if it is recorded properly:

  • Unforeseen ground or physical conditions sit under clause 60.1(12).
  • Weather beyond the measurements stated in Contract Data sits under clause 60.1(13).
  • The Project Manager or Supervisor failing to reply to a communication within the period required is clause 60.1(6).
  • A test or inspection by the Supervisor that causes unnecessary delay is clause 60.1(11).
  • And the most common of the lot, an instruction that changes the Scope, is clause 60.1(1).

Do that consistently and your register starts writing its own rows. Every coded variance is a candidate risk with an entitlement position already implied.

The catch is that no two projects code the same way. One site writes "60.113". Another writes "Weather". A third writes "rain stopped play". To the person on that job, all three mean the same thing. To a commercial manager trying to build a portfolio view across every project, that is three different things, and the picture fragments into noise.

This is exactly where most just-use-a-spreadsheet approaches fall over. The data is there. It simply will not add up, because it was never captured to a single standard and nobody has the hours to reconcile it by hand.

Ingredient two: let AI do the two jobs people hate

There are two jobs here. Both are tedious, both are error-prone by hand, and both are what machines are actually good at.

And this is the honest shape of the whole thing, so it is worth saying plainly. The AI is not doing the surveying. It is doing the data collection and the manipulation, the grunt work you have always resented, so that the part that is actually the job, the judgement, is the only thing left for you to spend your time on. It replaces the bits nobody enjoys. It does not touch the bits that need a brain.

Job one: normalisation

AI maps every one of those messy category strings back to a single taxonomy. Weather is weather whether it was typed as a clause number, a category or a shrug. "60.113", "Weather" and "rain stopped play" all resolve to the same underlying event. Your portfolio stops fragmenting.

And here is the payoff. A commercial manager can finally count how many times weather cost a shift this quarter, across every job, in one number. Not an impression. A count.

That count is your likelihood rating. Evidenced, not guessed. When someone in the steering group asks why weather is scored high, the answer is no longer that it feels about right. The answer is that it stopped work on eleven occasions across five jobs in the last three months, and here is the list. That is a different conversation, and it is one you win.

Job two: reading the narrative

Some of the sharpest risks never get a tidy category at all. They live in the free text of a shift comment, where no filter and no pivot table will ever find them.

The crew that stood three hours waiting for a point of contact who never picked up. The turf that did not arrive until one o'clock. The inspection that held the works until mid-morning.

That is standing time. It is a communication left unanswered. It is a test causing delay. Pure commercial exposure, sitting in a sentence someone typed at the end of a shift because it was on their mind, not because a form asked them to.

AI reads it. It pulls the standing time out of the narrative and puts it in front of you as a line on the register, with the record it came from one click away. The crew waiting on a decision that never came is the kind of thing that, if it was a communication requiring a reply, points straight at clause 60.1(6). The inspection holding the works, if the delay was unnecessary, points at 60.1(11).

I want to be precise here rather than oversell it, because this is where careless claims get made. Not every line the narrative surfaces is a compensation event. If the turf was late because of your own supply chain, that is your risk, not the Client's, and no amount of AI changes that. But the record still matters, because it feeds your own cost picture, your dayworks position and your disruption argument. The point is not that AI decides entitlement. The point is that it stops these events dying silently in free text where you can never act on them.

The two registers, side by side

It is worth seeing the contrast plainly.

The workshop registerThe records-fed register
How it is builtOnce, in a room, from memoryContinuously, from what site actually recorded
Likelihood scoringGut feel, one to fiveCounted frequency across real events
What it updates fromSomeone remembering before the steering groupA record being submitted on site
Evidence behind a lineA colour and a numberThe shift record, the quantities and the photos
What a director sees"Weather, likelihood medium""Weather stopped four shifts, here is the cost and the evidence"
State by week threeFictionStill true

The second column is not a better version of the first. It is a different kind of object. One is a prediction made at a moment. The other is a running account of what is actually happening, scored by what has actually happened.

What a signal looks like in practice

To make it concrete, here is the sort of thing sitting in your records right now, and what it points to. This is a read of what teams already capture, not a new form for them to fill in.

What site recordsThe signal hiding in itWhere it can point
Actual quantity well below planned, repeatedly, same activityProductivity, cost or programme riskDepends on cause, but it is evidence for the assessment either way
"Access unavailable" recurring at a locationA recurring constraint, not a one-offAccess not provided, clause 60.1(2)
Plant or labour allocated with no output recordedStanding time and a cost recovery questionDisruption, dayworks, or a linked compensation event
Free text: crew waiting on a decision that never cameStanding time, a communication left unansweredPM or Supervisor not replying, clause 60.1(6)
Free text: inspection held the works to mid-morningDelay caused by a test or inspectionUnnecessary delay, clause 60.1(11)
Extreme weather logged against the worksWeather risk, quantifiedWeather beyond the contract measurements, clause 60.1(13)

None of this requires anyone on site to do anything differently, provided the records already carry a category and a reason. That proviso is the whole game, and I will come back to it.

What you actually get

Not a workshop guess. A living register where weather, likelihood medium becomes weather stopped four shifts, cost these quantities, here are the records and the photos. Where access risk, likelihood low becomes access failed at three locations, on these dates, here is the pattern.

A director opens one view and sees which jobs are bleeding time, to what cause, and which ones are clean. Not a colour someone chose in a workshop. A count, with the evidence one click behind it.

And the register updates because something happened on site, not because someone remembered to update it. That is the difference between a document and a read. A document rots. A read is only ever as current as the last record submitted, which on a live job is this morning.

This is the territory we spend our time in at Gather, because the records are the product. When the site diary, the progress record, the allocation sheet and the photos are captured in a structured way, turning them into a live, evidence-backed risk register stops being a data project and starts being a query. You are not building the evidence base specially for risk. You already have it. You are just reading it a second way.

Where this goes next, and why it is harder

Everything above is about risk that has already landed or is emerging now. There is a more ambitious version of this, and I want to label it clearly as the harder, further-out capability, because it is easy to wave a hand at and much harder to do honestly.

Once your historic records are normalised across many projects, you can start benchmarking a planned activity against how similar work actually went. Not how long do we think this takes, but how long did it actually take, every time we did it before.

Say your programme assumes 40 metres a day of security fencing at a set of water-treatment sites. Pull the historic records for similar fencing at similar sites and you might find the median was closer to 22 metres a day, with a conservative figure lower still. That gap is a planning risk you can flag before a single panel goes in, rather than discovering it in month two when the productivity curve refuses to bend. (Figures illustrative.)

The same logic applies to winter works on exposed access routes, to a subcontractor whose output has fallen short before, to reactive works that historically generated quantities with no planned baseline and turned into a variation argument. The pattern is always the same. What normally happens on work like this, and does the current plan assume something the history says is optimistic.

I am deliberately not going to pretend this is a solved, push-button feature. It is where the direction of travel points, and it is genuinely powerful, but it depends on things that are easy to underestimate:

  • Enough historic data. A handful of records will not give you a trustworthy benchmark. This needs volume before it means anything.
  • Transparent similarity matching. Comparing this fencing to previous fencing is only fair if you are also matching on unit of measure, site type, season and supply chain. A black box that says this is risky, trust me, is worse than useless, because you cannot defend it and you should not act on it.
  • Treating the output as a flag, not a forecast. It tells you where to look and what to challenge. It does not tell you what will happen. Your programme, your team and your judgement decide that.

Used that way, the historic layer turns a record system into a commercial early warning system. Used lazily, it is just confident nonsense with a chart attached. The difference is entirely in whether you can see and question the comparison behind the number.

Be honest about the limits

This is not magic, and anyone who tells you it is has not run a job.

AI reads what your teams record. It is excellent at realised and emerging risk, the things already happening on the ground. It will not invent your horizon risks for you. Design maturity, procurement lead-in, the contractual exposure you can see coming from the tender documents. That is still your judgement, and it always will be. Structured records plus AI do not replace the risk manager. They give the risk manager a register that is actually true, so their judgement is spent on the things only judgement can catch. It automates the admin, not the judgement. That distinction is the whole game.

There is a hard dependency underneath all of it. If your records do not carry a category and a reason, there is nothing to normalise and nothing to read. Garbage in, and the cleverest model on earth gives you garbage out with a nicer font. Fixing the raw material comes first, always. It is not the glamorous part, but it is the load-bearing part.

Normalisation is not perfect either. The taxonomy mapping needs a human to review it and correct it, especially early on. The right model is not automation. It is suggestion. AI detects, recommends and evidences. A person accepts, rejects, merges or escalates. The moment you let it auto-create risks unchecked, it becomes a spam cannon, and a register full of noise is arguably worse than no register at all, because people stop trusting it and stop reading it.

There is also a professional obligation now, and it is not optional. Since 9 March 2026 the RICS Professional Standard on the responsible use of AI in surveying practice has been mandatory for RICS members and regulated firms. Where AI has a material impact on the service you deliver, you need documented human oversight. A named, competent person applying judgement to the reliability of the output, recorded in writing. Where AI produces outputs at volume, the standard expects you to dip sample them at regular intervals to assure quality. And you are expected to keep a risk register covering the AI's own risks, things like bias and erroneous output, alongside due diligence on the tools you procure.

There is a small irony worth sitting with. Build a risk register with AI, and the standard asks you to keep a risk register about the AI. Both point the same way. AI earns its place in the workflow when it is evidenced, sampled and supervised. It loses that place the moment it is trusted blindly. An AI-fed register does not delegate your accountability to an algorithm. It gives you better evidence to be accountable with.

Early Warning Register or risk register?

One last point of precision, because it trips people up in conversation with their Project Manager. NEC4 renamed the NEC3 Risk Register to the Early Warning Register for a reason. The contractual register under clause 15, maintained by the Project Manager, is a deliberately lightweight thing. It records the risk and the action to avoid or reduce it, and it is forward-looking.

NEC did that rename specifically to stop people confusing it with the broader project and commercial risk register that organisations run separately. Everything in this piece feeds that broader register. It can also surface matters that ought to trigger an early warning under clause 15 before they crystallise. So when you talk about the risk register, be clear which one you mean. They are related, but they are not the same document, and treating them as one is how notices get missed.

Try this on Monday

You do not need a platform or a pilot budget to test the core idea. You need ten minutes and last month's data.

Pull last month's variance categories across your projects and count them. If your records carry a category and a reason, you will have your top risks and their real frequency in about ten minutes. Not a workshop opinion. A count, from what actually happened.

Then look at what you have. Three things tend to jump out immediately. The one cause that keeps appearing and nobody had scored as a top risk. The location that is quietly worse than everywhere else. And the events that were happening all along but had never made it onto the register, because they lived in free text.

If your records do not carry a category and a reason, that is the finding, and it is the more important one. It means the raw material is not there yet. Fix that first, because it is the foundation for everything above. Agree a taxonomy, get categories and reasons captured consistently, and you have turned every future variance into a risk event you can count.

If you want to go one step further, run a small controlled test. Pick one project and one month. Agree the taxonomy up front. Run the count. Put five real risks in front of the team, each with its evidence attached, and see whether the conversation changes. My experience is that it does, because a risk with a record behind it gets acted on, and a risk with a colour behind it gets recoloured.

The real question

Structured records give you the raw material. AI does the reading and the counting that no human has the hours for. Your judgement does the part that matters most, the horizon risks and the calls that no record can make for you. None of it works without the discipline of capturing records properly in the first place, and none of it removes the professional on the hook for the advice.

So here is my question, and it is the one worth taking into your next risk review.

Is your risk register a document you maintain? Or a read of the records you already have?

Share

Keep reading

What Exactly Can You Do With an AI QS?
Guides
July 9, 2026
11 min read

What Exactly Can You Do With an AI QS?

The concrete answer to what an AI QS actually does: valuations, delay registers, application checks, CE packs, and hooks that read your diary for you.

Read Blog
Contemporaneous records and NEC4 event assessment
Commercial
January 22, 2026
3 min read

Contemporaneous records and NEC4 event assessment

Connect site records, instructions, notices and programme information without treating documentation as a guarantee of entitlement.

Read Blog
NEC4 Disallowed cost: applying the definition and supporting the records
Commercial
July 23, 2026
5 min read

NEC4 Disallowed cost: applying the definition and supporting the records

How to distinguish a contractual exclusion from an evidence gap when reviewing Disallowed cost under NEC4 ECC.

Read Blog
See Gather on your project

Keep site records, photos and resource allocations together for your commercial team.

Book a demo