Governed AI adoption
From AI Experiment to Controlled Pilot: Building a Governed AI Operating Model for a Construction Consultancy
Client identity and commercially sensitive implementation details are anonymised. The outcomes below are limited to what was evidenced during the pilot; no unmeasured productivity saving is claimed.
The Challenge
The client could already see useful applications for generative AI across construction and professional-services workflows. The problem was not a lack of ideas. It was how to move from individual experimentation to something the business could operate safely, repeatably, and at a sensible cost.
The environment included Microsoft 365, project documents, sensitive business information, existing user permissions, and a growing library of AI-assisted skills. A simple "turn AI on for everyone" approach would have created unclear data boundaries, inconsistent working practices, and operational risk.
The Approach
We treated AI adoption as an operating-model problem rather than a software-installation project. The work started by mapping the real data boundary, user groups, platform capabilities, risks, ownership, and rollout constraints before widening access.
An initially attractive Microsoft 365 connector route was rejected during delivery when its live permission model proved broader than the required project-folder boundary. Rather than force the design to fit the technology, the pilot switched to a controlled working method using locally synchronised project folders while Microsoft 365 remained the system of record.
Rollout was deliberately incremental. Each user had to pass the relevant onboarding controls before receiving access, and restricted information had no AI route during the pilot.
Controls Designed Into the Pilot
Invite-only AI workspace with controlled seat ownership
Multi-factor registration required before each user receives a seat
Green / Amber / Red information classification for AI use
Human review retained for AI-assisted outputs
Incremental rollout rather than a big-bang deployment
Versioned skills, operating records, change control, and review ownership
What Was Built
- Controlled AI workspace configuration and sign-off record
- AI usage policy and information-classification guide
- Role-based user and onboarding templates
- Administrator and starter/leaver procedures
- AI Operations Register for skills, seats, changes, and reviews
- Cost and workload model tied to useful workflow units
- Security-readiness roadmap and handover pack
What the Pilot Proved
The working method was tested end to end with two users and an AI-assisted workflow that wrote back into the project working area. The resulting file was verified successfully in SharePoint. The test also exposed a recoverable last-writer-wins concurrency behaviour, which was documented as a user working rule rather than hidden.
Single sign-on, workspace configuration, seat controls, and the user onboarding model were tested and documented. The engagement produced an operational record that the client could continue to use for skills, access, reviews, and changes after handover.
Just as importantly, the pilot identified conditions that were not ready for wider rollout. A tested restore capability was not in place, so expansion beyond the initial controlled cohort was explicitly gated rather than treated as a reason to push ahead.
Measuring Value Without Inventing ROI
The onsite work did not produce a statistically useful productivity baseline, so no percentage saving is claimed. Instead, the operating model included a repeatable way to measure value during rollout: baseline manual effort, AI-assisted human effort, completed workflow units, review quality, frequency, and indicative financial value.
This shifts the conversation away from prompt counts and token consumption towards a more useful question: did a governed workflow produce an accepted business output with less human effort, and was that benefit worth the seat and operating cost?
Quality and Governance Were Part of Delivery
The handover pack went through repeated independent AI-assisted QA reviews before acceptance. Those reviews found substantive issues, including places where early control language was too confident about prompt-injection containment and where incomplete deliverables could have been presented as finished. The documentation was corrected rather than the risks being softened for presentation. That evidence discipline became part of the operating model itself.
The Outcome
The client moved from loosely defined AI experimentation towards a controlled pilot with a proven working method, explicit data and human-review rules, documented ownership, measurable-value tracking, and clear stop/go gates for wider adoption.
The result was not "AI everywhere". It was a safer route to scale AI only when the underlying process, controls, and business case were ready.
Lessons Learned
Start with the workflow, not the vendor. A technically available connector can still be the wrong design if its effective data boundary is broader than the business needs.
Governance is operational. Policies matter, but so do seat ownership, onboarding gates, version control, review routines, tested recovery, and knowing who can change what.
A good pilot is allowed to say no. Finding that an underlying control is not ready and stopping expansion is a successful outcome when the alternative is unmanaged rollout.
Measure useful outputs. Cost per completed, human-reviewed workflow is more useful than raw token or prompt counts.
Have a repetitive workflow worth testing?
The AI Workflow Concierge starts with one real process, works out whether AI can genuinely improve it, and adds the governance needed to make the result usable in a business rather than just impressive in a demo.