A project manager uses AI to draft a progress report. A commercial team uses it to compare quotations. A property manager asks it to extract obligations from a lease.
Each task creates an opportunity to improve how work gets done.
Each also raises practical questions.
What information can the system access? What could it get wrong? Who checks the output? And who decides whether it is suitable for everyday use?
AI governance is how an organisation answers those questions and puts the answers into practice.
At Go Left, we recommend building those decisions into the work from the beginning. Our BUILD™ framework connects them through five stages: Baseline, Understand, Implement, Learn and Develop.
The aim is to give people a clear, supported way to improve a process, with controls proportionate to the consequences of getting it wrong.
01 / VISIBILITY
Start with the work people are doing
Before writing an AI policy, establish where AI is already being used and which processes people want to improve.
Speak to the teams doing the work.
Are they drafting reports, reviewing specifications, summarising meetings or searching project records? Which tools are they using? What information are they putting into them?
Include AI features within existing software. A familiar project platform may introduce a new capability that changes how information is processed or outputs are produced.
We suggest keeping a simple record of:
- The tool and the process it supports.
- The person responsible for that process.
- The information the tool receives.
- The output it produces and who uses it.
- Whether the use is being explored, tested or operated.
- The next review date.
This creates a shared starting point. It also helps identify useful experiments that need better support or clearer boundaries.
02 / PROPORTIONATE CONTROL
Assess the consequences of getting it wrong
Different uses of AI need different levels of scrutiny.
A draft agenda and a technical recommendation can both contain errors. The consequences of those errors may be very different.
Consider a contractor using AI to summarise a tender package.
An omitted requirement could affect the price, scope or assumptions behind a submission. The assessment should therefore consider how the summary will be used, what the estimator will check and how omissions might be detected.
For each proposed use, ask:
- Could an error affect safety, money, contractual commitments or professional advice?
- Could private or confidential information be exposed?
- Would someone recognise an incorrect or incomplete result?
- Can the output be corrected before it affects another person or process?
- What happens if the system becomes unavailable?
These questions should inform the decision to proceed, the evidence required and the controls around the work.
Check applicable professional requirements too. For example, RICS’ responsible-AI standard addresses AI use with a material impact on surveying services, including procurement, output assurance and client communication. Read the RICS professional standard.
03 / BOUNDARIES
Define what is approved
Approving a tool is only part of the decision.
People also need to understand which tasks, information and actions have been approved.
An organisation might permit a tool to help draft an internal presentation while requiring a separate assessment before it processes confidential project documents.
A reporting assistant might be allowed to prepare a draft, with a named reviewer responsible for approving it before issue.
Make those boundaries specific.
Explain which information can be used, where it can be stored, who can access it and what the system is permitted to do.
If an AI system connects to other software, consider its permissions. Searching approved records carries different consequences from changing them or sending information outside the organisation.
Give users a straightforward route for requesting a new use or raising an uncertainty.
Our article on where your data goes when you use AI sets out the questions to ask about storage, processing, access and retention.
04 / HUMAN REVIEW
Make checking part of the process
“Someone will check it” leaves too much unresolved.
A useful review process identifies the person, the evidence they need and the decision they are expected to make.
For a condition report, that might mean comparing the draft with inspection notes and photographs, checking descriptions and resolving unsupported conclusions.
For a quotation comparison, it might mean checking exclusions, qualifications and scope differences against the original submissions.
Agree:
- Who has the knowledge to review the output.
- Which sources they should check.
- Which errors or omissions matter most.
- How exceptions are escalated.
- What record of review is needed.
- Who can pause the workflow.
Allow time for that work.
Checking and correction are part of the process cost. They belong in the assessment of whether the solution creates a worthwhile improvement.
The person reviewing the output also needs the authority and practical ability to challenge it.
05 / TESTING
Agree the evidence before the trial
A useful proof of concept has a clear boundary.
Choose the process, users, cases and information involved. Agree what success would look like and what would cause the test to pause or stop.
For example, a project-reporting trial could assess:
| Area | Evidence to gather |
|---|---|
| Effort | Time spent preparing, checking and correcting reports |
| Quality | Missing information, unsupported statements and factual errors |
| Usability | Whether the output fits the team’s reporting process |
| Adoption | Whether intended users can use it confidently |
| Control | Whether permissions, review and escalation work as intended |
Use representative work, including incomplete information and awkward cases.
Compare the results with the original process. Record what worked, what failed and what needs further investigation.
That evidence should support an explicit decision: proceed, refine, pause or stop.
A successful trial also needs a separate decision about readiness for wider use. More users, different projects and greater dependence can introduce risks that a small test has not yet examined.
06 / OWNERSHIP
Plan for everyday operation
Once a solution becomes part of delivery, someone needs to own its continued performance.
We recommend distinguishing three responsibilities:
Business ownership: Is the process still achieving the intended outcome?
Technical support: Is the system reliable, appropriately configured and supported?
Risk and professional oversight: Are the controls still suitable for the work and its consequences?
In a smaller organisation, one person may hold several responsibilities. Make that arrangement explicit.
Agree how users will receive training, report problems and request changes.
Decide which changes need further assessment. A new data source, broader permissions or a different type of output may require additional testing.
Keep a record of changes and approval decisions.
Also consider continuity. The team should understand how to retrieve necessary records and continue the work if the service becomes unavailable.
07 / ONGOING REVIEW
Keep learning from actual use
Governance continues as the process changes.
Useful evidence includes corrections, recurring exceptions, user feedback, incidents, support requests and benefits actually achieved.
Look at these together.
If a team regularly works around a control, investigate why. The process may be unclear, the system may be unsuitable for part of the task, or users may need better support.
If an output reaches a client with an error, establish what happened and whether the same issue could affect other work. Follow the organisation’s relevant incident and professional procedures, then update the controls and training.
Set review dates, but also agree events that trigger an earlier review.
The objective is to make each decision easier to explain:
What problem are we solving? What evidence do we have? What is the next sensible step? And who owns what happens next?
That is how we apply governance throughout BUILD™, from the first opportunity assessment to ongoing operation and improvement.
Put the approach into practice
Choose one process with a visible problem and a named owner.
Map the current work. Assess the value and risk. Agree the information boundaries, professional decisions and evidence needed for a controlled test.
Then use the results to decide what should happen next.
This gives your organisation a practical basis for introducing AI, supporting the people who use it and sustaining improvements over time.