Project AI NIST compliance in construction and infrastructure: running the AI RMF project by project

Referenced is not ignorance. It is usually the opposite: someone in the business has read the framework properly, written a good paragraph about it, and won work with it. The gap is structural rather than intellectual — the paragraph was written by a bid team in a head office, and the thing it describes has to happen inside a project organisation that did not exist when the bid was submitted and that answers to a different director.

What makes this stage hard to see from the inside is that everything about it looks compliant. There is a policy. There is a named framework. There may even be a slide in the induction pack. What is missing is any artefact on the project that a reviewer could ask for: no register, no intended-purpose statement, no measurement plan, no owner. Ask for the project's AI risk position and you get a firm-level document plus an assurance that the project follows it.

The cost of staying here is not a fine — the AI RMF carries no penalty, because it is voluntary. The cost is that reliance accumulates invisibly. Site teams start acting on outputs they have never tested, design teams start submitting drawings a tool helped produce, and commercial teams start valuing progress from an analytic nobody has calibrated. None of that is recorded, so when a question arrives — from a client, an insurer, a coroner or a regulator — the project has to reconstruct from memory what it was relying on, and memory has already demobilised.

Profiled is the first stage where the framework is doing work rather than being cited. The register is a modest artefact — often a single spreadsheet or a CDE-hosted table with a dozen rows — and it changes the conversation immediately, because for the first time the project can answer the question 'what are you relying on?' with a list rather than an anecdote.

Two entries on that list surprise almost every project. The first is embedded AI: the scheduling optimiser inside the planning tool, the anomaly detection in the plant telematics portal, the auto-classification in the document system. Nobody procured these as AI and nobody thinks of them as AI, so they arrive under the radar and end up carrying real weight. The second is client-specified AI — a platform named in the employer's requirements that the project must use and cannot change. Both belong on the register precisely because the project did not choose them.

The stage's characteristic weakness is that the register describes and does not test. Intended purpose is written from the vendor's description, consequence class is assigned by feel, and the accuracy figure everyone repeats came from a sales deck. That is still a large improvement on stage 1, and it is also a trap: a well-formatted register can make a project feel assured while every number in it is somebody else's. MAP without MEASURE produces confident documentation of untested reliance.

Measured is where the framework starts paying for itself, and the reason is unglamorous: a number measured on this project is arguable in a way a vendor benchmark is not. When a design manager says a checking tool has a 4% miss rate on the project's own seeded non-conformances, the conversation moves immediately to what to do about the 4% — sampling rate, second check, which packages. When the same manager says the vendor reports 96% accuracy, the conversation stops, because nobody in the room can interrogate a number produced on somebody else's data.

The test set is the artefact that defines this stage, and building it is a records exercise rather than a data-science one. Every project already holds a corpus of known-bad examples: the NCR log, the RFI log, the snagging list, the rejected inspection records, the design-review comment tracker. Seeding a held-out set from those, plus a controlled set of defects the team introduces deliberately, gives a recall figure that means something in the project's own units. NIST's term for this whole activity is TEVV, and the AI RMF is explicit that its parameters have to be aligned to real deployment conditions rather than to laboratory ones.

The stage's limitation is that measurement without a rehearsed response is a report, not a control. Projects at this stage can tell you precisely how often a tool is wrong and have no agreed answer for the morning it is wrong about something that matters. The miss gets handled by whoever notices, competently and invisibly, and no record is created — which means the third recurrence of the same failure mode still looks like a first.

Managed is the stage at which AI stops being a digital-team topic and becomes an ordinary project risk. The signature is boring in the best way: AI items appear on the same weekly risk agenda as temporary works, ground conditions and long-lead procurement, discussed by the same people in the same vocabulary, with the same expectations about owners and dates. Nothing about the framework requires a parallel governance structure, and projects that build one usually find it starved of attention within two months.

The characteristic capability here is rehearsal. Construction is unusually good at this — it already drills fire, rescue from height, confined-space entry and concrete-pour contingency — and the same instinct transfers directly. Running one deliberate exercise, in which a tool is declared unavailable or wrong on a live package and the team executes the fallback, converts a paragraph in the method statement into a known quantity. It also surfaces the thing paper never does: how many downstream artefacts had already absorbed the AI's output before anyone noticed.

The stage's blind spot is time. Everything works while the project exists, because the people who wrote the profile are still in the office and the reasoning is still in their heads. Nothing at this stage has been built to survive demobilisation. The evidence exists but has never been assembled; the register is current but has no consignee; the reasoning behind a reliance decision lives with a design manager who moves to the next scheme in March. A project can be genuinely excellent at MANAGE and still hand over nothing at all.

Transferable is a narrow stage and deliberately so. It does not mean the project has automated anything, and it does not mean the AI is more capable than at stage 4. It means one specific thing: that the record of what was relied on, how it was tested and what went wrong has been made into an object that crosses two organisational boundaries — the handover to a permanent asset owner, and the mobilisation of the next temporary organisation.

The handover boundary is the one with statutory weight. In the UK, the Building Safety Act regime made the durability of building information an explicit duty for higher-risk buildings, and the CDM regulations have long required a health and safety file to pass to the client at completion. Neither instrument names AI, and neither needs to: the question a duty holder will ask in year seven is what the design or inspection record was based on, and 'a tool the contractor used, which nobody has any record of' is a bad answer regardless of which regime is asking. The AI evidence pack is the cheapest available insurance against that question, and it costs almost nothing if it is assembled continuously rather than reconstructed at completion.

The mobilisation boundary is the one with commercial weight. A firm whose projects each start from a blank register pays the same setup cost every time and learns nothing across schemes. A firm whose next mobilisation starts from the last project's returned profile — the same tools, the same consequence classes, the same test sets, the same known failure categories — compresses stage 1 and 2 into a fortnight. This is also the only mechanism by which GOVERN becomes real rather than declarative: the enterprise's policy improves because projects hand something back, not because the policy was rewritten.