Build the register before you write the policy
Discovery costs four weeks and one uncomfortable decision: that nobody gets into trouble for what they report. Get that right and the register is accurate. Get it wrong and every control built on top of it sits on a false picture.
What were the answers to the previous five questions?
1. What is the first thing a construction business should build: an AI policy, or something else?
A register, built from a discovery exercise. Policy is the cheap part and can be written in an afternoon once you know what you are governing. Discovery is the part that takes four weeks and cannot be skipped.
2. Why should a register record a system and a use case together rather than just naming the tool?
Because the risk lives in the pairing. Copilot summarising an internal meeting and Copilot analysing contractual correspondence share a product name and nothing else: different data, different consequence, different control. A single row saying "Microsoft Copilot" governs nothing.
3. What single question, asked of an employee, reveals the consequence of a given AI use faster than any other?
"What happens if it is wrong?" It cuts past the description of the tool straight to the exposure, and people answer it accurately because it is a question about their work rather than about their compliance.
4. What should you do with the workarounds people describe during a discovery exercise?
Record them prominently. A workaround marks a place where the formal process is failing badly enough that a busy person built their own route around it. That is both a risk and the best automation candidate list you will get.
5. Why does a register that grows over time indicate success rather than deterioration?
Because growth means people are reporting new use rather than concealing it. A register frozen at its first count is not a stable organisation, it is one where nobody trusts the process enough to add anything.
What does a discovery exercise involve?
Four weeks, a handful of interviewers, and a decision at the outset to treat this as a survey rather than an audit. The distinction is not presentational. If people believe that admitting to using a consumer tool will get them into trouble, they will not tell you, and you will build your entire control framework on a false picture.
Nominate interviewers people already trust inside each department. Do not send compliance to ask a design team about AI. Book twenty minutes, ideally at a point in the week when the person has recently done the work rather than at four o'clock on a Friday, and ask six questions.
- What AI system do you currently use at work?
- What task does it save you from doing?
- What information do you give it?
- What do you use the answer for?
- How do you check it has given you the right answer?
- What would happen if it got it wrong?
What goes into a register row?
One row per meaningful pairing of a system with a use case. This is the AI register, and it is the artefact every later part refers back to. Start it in a spreadsheet: visibility first, database later, and if you find twenty three use cases then you have twenty three rows and no rounding.
| Field | What it captures | Why it earns its place |
|---|---|---|
| Reference | AI-001, AI-002 | Lets risks, incidents and training records point at something |
| System and use case | The pairing, not the product | One row per product governs nothing, because the product is the one thing that does not vary |
| Role using it | QS, PM, design coordinator, admin | Roles survive staff changes; names do not |
| AI function | Generate, retrieve, summarise, compare, recommend, act | Determines what can go wrong |
| Information in | Project, client, commercial, personal, special category | Drives the data protection question |
| Output use | Does it become a project record? Whose decision does it touch? | Separates convenience from consequence |
| Consequence if wrong | Financial, contractual, safety, regulatory, reputational | The input to classification |
| Current checks | What actually happens today, not what should | A baseline you can improve against |
| Business owner | Accountable for the use case existing | Somebody decides whether it continues |
| Decision owner | Accountable for each individual output | Named role, or the control is theatre |
| Classification | Green, Amber or Red | Set tomorrow, from consequence |
| Gate | Self check, competent review or named approval | Set in part 5, and it lives next to the use case rather than in a policy |
| Control matrix | The seven fields for every Amber and Red row | Set in part 6. A row without one is a classification with no control behind it |
| Dates and reviewer | Added, last reviewed, next due, and by which role | A register with no review dates cannot evidence a review cycle, which is the first thing a regulator, an insurer or a client looks for |
For RICS regulated firms this is not optional housekeeping, and it is two artefacts rather than one. The professional standard requires a written register of AI systems that have a material impact on service delivery, recording the purpose, the date of first use and the date of next review; and, separately, a risk register carrying a red, amber, green rating that must be reviewed and updated at least quarterly by the staff responsible for decisions about the firm use of AI (RICS). This register is the first of those. A firm already running a corporate risk register should cross reference into it rather than duplicate. Firms outside RICS regulation should expect their clients and their insurers to arrive at the same requirement by a different route.
What do people actually report when you ask properly?
A predictable spread, and one or two things that stop the room.
- Meeting transcription and summarisation, which spreads fastest because it needs no decision from anyone and shows a visible saving on day one, and which almost never has an owner.
- Email drafting and refinement, including on correspondence that is a project record.
- Document interrogation: specifications, subcontracts, technical submissions.
- AI features that arrived inside existing software by update, which people do not describe as AI at all.
- Personal subscriptions being used for work, on work information, on a personal account.
That last category is the one worth handling carefully. It carries the highest data risk on the list, because work information sits on an account the firm cannot see, cannot search and cannot delete, and it exists because no approved route does. Treating it as misconduct produces a smaller register and the same behaviour. Treating it as unmet demand produces an approved route and a register you can believe.
How do you keep it from becoming a dead document?
By attaching a rhythm and a use to it on the day it is created.
| Cycle | What happens | Who |
|---|---|---|
| Monthly | New use cases added as placeholders pending classification | Business owners |
| Quarterly | Full review of Amber and Red entries: are the controls still proportionate? | Governance owner |
| Annually | Re-run discovery. Tools change, people change, unofficial use returns | Whole organisation |
And pick three quick decisions in week four, once the classification in part 5 is in hand: one Green use case to approve and publicise, one Amber to add guidance to, one Red to route through a named approver. That demonstrates within a month that governance widens what people are allowed to do rather than narrowing it, which is the only argument that will keep them reporting honestly. See what a proper AI audit looks like and what an automation consultant actually does for the adjacent work.
You now have a list of real uses with real consequences. part 5, classify by consequence, not by which logo is on the screen turns that list into a control framework, and the two variables that set it are what it costs to be wrong and how late you would find out.
What five questions should you be able to answer now?
Attempt these before tomorrow. Each has a defensible answer, and each is answered at the top of the next part.
- Two people use the same AI product. One summarises internal minutes, the other drafts contractual notices. Should they carry the same controls, and why?
- What two variables should determine whether a use case is Green, Amber or Red?
- Why is "is the tool enterprise grade" the wrong basis for classification?
- Which kind of use case feels low risk but should be classified Red?
- What is the minimum control that should attach to any Red classified use?
Which sources is this part built on?
Every figure quoted above resolves to one of these. Each was checked before publication.