Deploy —
First Moves

Gartner's "Predicts 2025: AI and the Future of Work" contains a statistic that every deployment lead should print and keep on their desk: by 2026, more than 80% of enterprises will have used generative AI. But only one in three AI projects currently reaches production. The gap between "we ran a demo" and "this is embedded in how we work" is where most enterprise AI investment quietly disappears.

The paradox is this: the conditions that make a proof-of-concept succeed are precisely the conditions that make it fragile. A demonstration uses clean data, enthusiastic volunteers, a controlled use case, and an expert facilitator. A deployment has to survive contact with messy data, reluctant users, ambiguous use cases, and a line manager who was never briefed and has already decided this is another technology fad.

The difference between a demo and a deployment is not technical. It is organisational. The technology rarely fails at the second stage — the governance, the communication, the change management, and the support infrastructure do. This issue is about building those non-technical foundations before you switch anything on.

The McKinsey Global Institute estimates that customer operations, marketing and sales, software engineering, and R&D account for 75% of the value AI can deliver across business sectors. These are also the functions most likely to have early Copilot deployments. If you deploy without governance, without training, and without a support route, you are not just wasting licence spend — you are burning credibility with the people whose buy-in you will need for every subsequent wave.

The governance conversation is not glamorous. Nobody gets excited about data classification policies or acceptable use frameworks. But skipping this step is how organisations end up with sensitive client data processed through a third-party AI with no contractual basis for doing so, or employees using public AI tools for tasks that should only ever touch systems within the enterprise boundary.

At minimum, your governance baseline needs four components. The first is a data classification framework that distinguishes between public data (safe to process in any context), internal data (safe in enterprise-managed AI tools), confidential data (requires explicit governance approval and technical controls), and restricted data (not to be processed by AI systems without a formal data processing agreement and legal review). This is not a new framework — it builds on whatever data classification you already have. The AI-specific step is mapping your existing classification to AI tool tiers.

The second component is an acceptable use policy for AI — a concise, readable document that tells employees what they can and cannot do. This is not a legal document; it is a behavioural guide. It should cover: which tools are approved, which data classifications can be used with each, what kinds of output require human review before use, and how to report a concern or incident. Keep it to two pages. Employees will not read a twenty-page policy, and ambiguity in a short document is better than comprehensiveness in one nobody reads.

The third component is technical controls in Microsoft 365 — sensitivity labels, admin controls in the Microsoft 365 Admin Centre, Copilot settings that limit which users have access and to which features, and Data Loss Prevention policies that prevent sensitive content from leaving the organisation's boundary. These controls exist and are available to every M365 tenant; most organisations have simply not configured them for the AI context.

The fourth component is a named AI Lead or AI Governance owner — a person whose job includes keeping the policy current, processing requests for new use cases, managing incidents, and serving as the liaison between IT, Legal, HR, and the business. Without a named owner, governance is everyone's responsibility and therefore no one's.

Before your first user opens Copilot for Microsoft 365, the following ten items should be in place. This is not a perfect checklist — every organisation is different — but it represents the minimum viable deployment infrastructure that separates a successful first wave from an expensive false start.

The case for a phased deployment is not caution for its own sake. It is a recognition that the learning from Wave 1 is essential infrastructure for Wave 2, and that the credibility built in a successful Wave 1 is the most valuable asset you have for the organisational change required in Wave 3.

Wave 1 is your learning laboratory. It should be small enough that you can give it genuine attention — 20 users, across four different business areas, for eight weeks. The breadth of business areas matters: you will learn different things from a Marketing user than from a Finance user, and you need that range to build a credible picture of where the value is for your organisation. Champion selection matters more than anything else at this stage. You are not looking for the people who are already excited about AI — you are looking for the people whose colleagues will trust their judgement when they say "this is useful" or "this doesn't work here."

Wave 2 scales to roughly 200 users, adds structured onboarding (not just access), and introduces a weekly cadence of learning prompts, champion-led tips, and usage review. The twelve-week timeline gives enough runway to see whether usage deepens over time or plateaus after the initial novelty. Structured onboarding means at minimum: a two-hour kickoff session, a reference card of use cases specific to each business area, and a named champion contact for each group.

Wave 3 is the full organisation rollout, by which point your champions are experienced, your governance model has been stress-tested, your use cases are documented, and your managers have seen the results rather than just heard about them. This is also the wave where the change and comms infrastructure described in Issue 03 becomes critical — because at full organisation scale, the adoption problem is a human problem, not a technology problem.

In the first 30 days of Wave 1, the most common mistake is reaching for the wrong metrics. Executive sponsors want to see cost savings and productivity gains — and those numbers will come, but not in the first month, and not in a way you can attribute cleanly to Copilot rather than to the general excitement of a new tool. Chasing those metrics too early produces gaming: users who inflate their reported time savings because they know that is what is being measured.

What you can legitimately measure in the first 30 days is behaviour. Microsoft 365 admin reporting gives you active usage days per user — a much more meaningful signal than raw seat utilisation, which tells you nothing about how deeply the tool is being used. The difference between a user who opens Copilot once and a user who uses it on 15 of 20 working days is the difference between a licence wasted and a genuine behaviour change.

Feature adoption breadth is the second signal. A user who has tried Copilot in Teams meeting summaries, in email drafting, and in document creation is building genuine capability. A user who has only ever used it in one context may be getting value but has not yet crossed the threshold into habitual use. The Viva Insights admin interface (covered in more depth in Issue 04) provides adoption analytics that go beyond the basic admin report.

The qualitative signal matters as much as the quantitative. A weekly check-in with Wave 1 champions — even a five-minute Teams message exchange — generates the stories, the failures, and the unexpected discoveries that will become your internal evidence base. The BCG study showed that the frontier is jagged in ways that are not predictable in advance: your champions are your frontier scouts. Treat their anecdotes as data, capture them systematically, and you will arrive at Wave 2 with a real picture of where the edge is in your organisation.

What you are emphatically not doing in the first 30 days is announcing results to the wider organisation. Nothing undermines a future rollout faster than a premature claim about productivity gains that subsequent waves cannot replicate. Build quietly. Learn carefully. The moment for the broader narrative comes when you have the evidence to back it.