The RICS AI Standard and Programme Review: Which Tools Count, and What You Must Record
Which scheduling and programme-review tools fall inside the RICS Responsible use of AI standard, how the material impact test works, and what you must record.
Since 9 March 2026, every RICS member and regulated firm has been bound by a professional standard on artificial intelligence. The first question most project teams ask about it is a practical one: does Primavera P6 count? The quantity surveyor who runs a programme review each month, the employer’s representative (ER) assessing an extension of time (EOT) claim, and the delay analyst preparing a report all use software that calculates dates, flags defects, and increasingly writes text. Some of that software is AI in the ordinary sense. Some of it may be AI under the definition RICS adopted, which is far wider than the ordinary sense.
For programme review, the standard’s material impact test does most of the sorting, and the records it requires fit into any structured construction schedule analysis workflow.
The standard at a glance
Item Detail Title Responsible use of artificial intelligence in surveying practice, 1st edition Published September 2025 Effective 9 March 2026 Applies to RICS members and RICS-regulated firms, globally Status Professional standard: “must” is mandatory, “should” is best practice Triggered by AI outputs that have a “material impact on the delivery of the surveying service” (section 1.2) Caption: Key facts from the RICS standard itself.
The Definition Is Wider Than Most Readers Assume
The standard defines an AI system using the OECD wording: “A machine-based system that, for explicit or implicit objectives, infers, from the input it receives, how to generate outputs such as predictions, content, recommendations, or decisions that can influence physical or virtual environments”. Most people read that as describing ChatGPT and machine-learning forecasting tools. The OECD’s own Explanatory Memorandum (March 2024) reads it more broadly. It lists “planning algorithms” and “combinatorial problem-solving systems” among its examples of AI systems with explicit objectives, and states that the definition “is inclusive and encompasses systems ranging from simple to complex”.
A critical path method (CPM) engine is a planning algorithm. On a literal reading, the forward and backward pass in P6 or Microsoft Project could sit inside the definition, and so could a rule-based checker that flags schedule defects. The standard doesn’t settle this, and nor will this guide: whether your scheduling software is an AI system is a determination for your firm, made and recorded under the standard’s own process.
| Tool in the programme-review workflow | How it produces output | Inside the OECD definition? |
|---|---|---|
| Large language model (ChatGPT, Copilot, an AI assistant inside another product) summarising a report or drafting prose | Generates content from patterns learnt in training | Yes, on any reading |
| Machine-learning forecasting (predicted completion, risk scoring trained on past projects) | Infers predictions from training data | Yes, on any reading |
| CPM scheduling (P6, Microsoft Project, Asta Powerproject) | Computes dates from logic and durations a planner entered | Arguably, on a literal reading (“planning algorithms”) |
| Rule-based quality checks (DCMA 14-Point metrics, logic audits) | Applies fixed thresholds to the programme data | Arguably, on a literal reading |
| Spreadsheet formulas | Fixed arithmetic | Unlikely |
Caption: Where common programme-review tools sit against the definition RICS adopted. “Arguably” means a firm could reasonably decide either way and should record why.
The breadth of the definition matters less than it first appears, because the standard only bites on certain outputs.
The Material Impact Test Decides What Is In Scope
Section 1.2 limits the standard to “the outputs of AI systems that have a material impact on the delivery of the surveying service”. Whether an output qualifies depends on “whether the output is capable of influencing the delivery of the service and, if it is, the nature of the influence it exerts”. The standard’s own examples include “outputs summarising documents that are then relied on when writing a report” and “outputs composing all or the significant parts of an opinion”.
The same section adds a duty that most summaries of the standard pass over. If a member or firm determines that its use of AI will have a material impact, it “must make a record of that determination and the reasoning behind it”. The determination itself is a record, before any of the heavier duties start.
the service you deliver?} B -->|No: incidental use| C[Outside the standard's duties] B -->|Yes| D{Is the tool an AI system
on your firm's reading?} D -->|No| E[Record the reasoning
and move on] D -->|Yes| F[Material impact:
record the determination] F --> G[Register, due diligence,
reliability decision, client disclosure]
Caption: How the material impact test and the definition interact for a single output. The recording step applies on both “Yes” branches.
In a programme review, the test sorts outputs quickly. An AI summary of the contractor’s monthly report that you rely on when assessing an EOT has a material impact. A language model that tidies the grammar of a cover email doesn’t. AI-written commentary inside a schedule analysis report you forward to your client has a material impact if you adopt it. The CPM dates you rely on to judge whether a delay is critical could have a material impact if your firm treats the scheduler as an AI system, which is exactly why the reasoning should be written down either way.
What the Standard Requires, Clause by Clause
The duties fall on the individual member and on the regulated firm, and each has a practical meaning for someone reviewing programmes.
| Section | Mandatory requirement | What it means for programme review |
|---|---|---|
| 2 | Members using AI must have a basic understanding of AI types, failure modes, the risk of erroneous output, bias, and data risks | Know how the tool you rely on can go wrong before you rely on it |
| 3.1 | Firms must not upload private and confidential data to AI systems without “express written consent in advance” and a reasonable-risk assessment | A contractor’s programme is commercially sensitive; uploading it to an AI tool needs written consent first |
| 3.2 | Firms must record an assessment of whether AI is the most appropriate tool, keep a written register of AI systems with material impact, and have responsible-use policies | Your register lists each tool, its purpose, first-use date, and next review date |
| 3.3 | Firms must operate an AI risk register, reviewed at least quarterly | Record risks such as erroneous output and data retention, with a RAG rating |
| 4.1 | Firms must request specified information from AI suppliers in writing before procurement | Six written questions to each supplier (see below) |
| 4.2 | Members must document a written decision on the reliability of any AI output with material impact | A named surveyor signs off each relied-on output, or dip-samples high-volume ones |
| 4.3 | Clients must be told in writing, in advance, when and for what AI is used | Terms of engagement name the AI use, the redress route and any opt-out |
| 4.4 | Firms must be able to explain, in writing on request, the AI system, its limitations, and the reliability decisions | Keep the supplier’s answers and your decisions where you can produce them |
Caption: Mandatory (“must”) requirements in sections 2 to 4 of the RICS standard, read for programme review. Section 5 applies only to firms developing their own AI systems.
Section 3.1 is where programme review is most exposed. The standard’s glossary says private and confidential information “may include commercially sensitive data,” and a native programme file carries the contractor’s logic, resourcing, and commercial position. Before any AI feature touches that file, ask the tool’s supplier exactly what leaves your hands. If the AI part of the tool can be switched off, and the rest keeps working, that switch is how a firm stays inside section 3.1 on projects where it holds no consent.
Write the Reliability Decision Properly
Section 4.2 carries the most work, and its reach goes beyond RICS discipline. The standard’s own document definitions state: “It is also likely that during any legal proceedings a judge, adjudicator or equivalent will take RICS professional standards into account.”
What the standard requires: Section 4.2 requires the written reliability decision to detail “any relevant assumptions made”, “key areas of concern regarding reliability”, “the reason for each concern”, “whether anything could be done to lessen each concern”, and a concluding statement on “whether the member or RICS-regulated firm considers that the output can reasonably be used for its intended purpose.” It must be prepared by, or under the supervision of, “an appropriately qualified and named surveyor who accepts responsibility for its use”.
What it means: A tick in a checklist doesn’t meet the requirement. For AI-written commentary on a programme, the decision should show that someone compared the prose against the figures it describes. A language model can state a real figure with the wrong direction, so the check that matters is whether each movement described in the prose matches the sign and size in the underlying table.
Imagine an AI summary of a monthly update that reads “the programme recovered seven days” when the comparison table shows the finish moving seven days later. The number is right; the direction is wrong. A reviewer who checks only that the number appears in the data will pass it. A reviewer who checks direction as well catches it, and that check is the substance of a defensible section 4.2 decision. Reliability checks on AI text sit comfortably alongside the checks you already run when reviewing a contractor’s programme.
For high-volume or automated outputs, section 4.2 accepts that scrutinising every output isn’t proportionate, but firms “must therefore undertake randomised dip samples of the outputs at regular intervals”. Record the sample size, the date, and what was found.
Six Questions for Your Software Supplier
Section 4.1 requires written requests, with the answers recorded and assessed. Where a supplier gives no or limited information, the firm “must identify the risks associated with any missing information and record them in the risk register”. A limited answer is acceptable; an unrecorded one isn’t.
| Section 4.1 question | What a usable answer contains |
|---|---|
| Environmental impact of the AI system | A figure if one exists; if not, a plain statement of scale (how many model calls, how much text) |
| Who was involved in developing the AI system | Who built the model, who runs it, who built the product around it |
| Compliance with data and confidentiality law | What data leaves your hands, where it goes, how long it’s kept, and under whose law |
| Permissions where personal data was used | What personal data the model was trained on, to the extent the publisher documents it |
| Accuracy, relevance and diversity of training data, and known bias | What the supplier knows, and a candid statement of what it doesn’t |
| Type and extent of the supplier’s liability | The liability cap and exclusions in the supplier’s terms |
Caption: The six mandatory written requests in RICS standard section 4.1, with what a firm can file.
Many suppliers will answer some of these poorly, particularly the environmental and training-data questions for models they license from someone else. Record the gap as a risk rather than chasing an answer that doesn’t exist. As one worked example of written answers to all six, ScheduleLens publishes its own at schedulelens.com/ai-transparency; the format matters more than the source, and any supplier’s answers should be filed the same way.
Keep the Records Where You Can Produce Them
The standard turns AI use into a records obligation, and the records it requires map neatly onto the contemporaneous-records discipline already expected of a delay analyst. Five records sit behind a compliant programme-review workflow:
- The material impact determination and its reasoning, for each tool (section 1.2).
- The AI register entry: system, purpose, date first used, and next review date (section 3.2).
- The risk register, reviewed at least quarterly (section 3.3).
- The supplier’s written answers, and your assessment of them (section 4.1).
- Each reliability decision, or the dip-sample log for high-volume outputs (section 4.2).
These records answer the question a client is entitled to ask under section 4.4, and the question an adjudicator may ask when your programme review is in evidence. They also carry into any delay analysis report you prepare: if AI-written text appears in it, the reliability decision is part of the report’s audit trail.
Standards Referenced
| Source | Section | What it covers |
|---|---|---|
| RICS, Responsible use of artificial intelligence in surveying practice, 1st edition | 1.2 | Scope, material impact test, recording the determination |
| 3.1 to 3.3 | Data governance, system governance and register, risk register | |
| 4.1 to 4.4 | Supplier due diligence, reliability decisions, client communication, explainability | |
| OECD, Explanatory memorandum on the updated OECD definition of an AI system (March 2024) | “AI system objectives”; “Application of the updated definition” | Planning algorithms as AI systems; the definition’s breadth |
Caption: Sources for every requirement quoted in this guide.
Start with the definition question for each tool you use, write down the answer, and apply the material impact test to what the tool actually produces. The heavier duties follow only from that record, and the record is what you’ll be asked to produce.
This article is for educational purposes and isn’t legal advice. Whether a particular tool or output falls within the RICS standard is a determination for your firm.