From AI Strategy to AI Implementation: bridging the gap between governance and deployment 

Our three stages of AI maturity in private markets describe where firms typically sit today: assessing opportunities, driving adoption, or scaling capability. Most organisations are still in the first two stages. The next challenge is not deciding whether AI matters: it is turning a strategy into something that works safely, consistently and at scale. 

This is where many firms discover that strategy and implementation are not the same thing. 

The executive team agrees an AI strategy. IT procures licences for Microsoft Copilot, Gemini or ChatGPT Enterprise. AI capabilities begin appearing inside existing platforms as vendors roll out new features. Employees start experimenting with them. Each of these decisions is sensible in isolation, but they often happen on separate tracks. 

The strategy describes how the firm intends AI to be used. The systems reflect whatever has been enabled, licensed and configured. Somewhere between the two, the organisation loses alignment. 

The reason is usually straightforward. Many firms begin with a desire to keep pace with AI rather than with a clearly defined business problem. Procurement comes first, adoption follows naturally, and governance tries to catch up afterwards. By then, AI is already embedded in day-to-day work. 

The real challenge is understanding that governance changes form during implementation. 

At strategy stage, governance is a policy. 

At deployment stage, governance is a configuration. 

Policies define intent. Configurations determine what people can do. Policies say confidential information must only be shared through approved tools. Configurations decide which tools are available, which data they can access, how information is labelled, what is logged, where data is processed and who is permitted to use it. 

Configuration is what makes policy enforceable. 

Bridging that gap is what AI implementation really consists of. 

A successful implementation starts with a strategy that answers several practical questions. Before any deployment begins, firms should be able to state with confidence: 

  • We know why we are investing in AI. 
  • We have prioritised the use cases we intend to deliver and agreed the order in which they will be implemented. 
  • We understand which tools and models support each use case. 
  • We know where our data resides, how it moves and what will happen to it. 
  • We know who should have access to that information, and who should not. 
  • We have executive sponsorship, business ownership, IT engagement and support from risk, compliance and legal. 
  • We have allocated budget, resources and a roadmap with measurable outcomes. 

If these questions cannot yet be answered, implementation is likely to expose the gaps quickly, and at considerably greater cost than resolving them beforehand. 

One of the biggest reasons AI programmes stall is the assumption that every piece of enterprise data must be perfectly organised before any AI initiative can begin. 

Readiness depends entirely on the first use case. 

If your organisation already has a governed data platform integrating CRM, portfolio monitoring, finance and operational systems, you have an excellent foundation. AI can query information across those systems, generate reports, analyse trends and support investment decisions using consistent underlying data. 

If you do not yet have that platform, the question is not whether you will eventually need one. Most firms will. The more valuable AI use cases – portfolio reporting, performance analysis, investor reporting and operational insight – depend on consistent information drawn from multiple systems. 

The important question is simpler: 

Different use cases have different requirements. 

A document-based assistant summarising CIMs, drafting investment committee papers or answering questions across historical deal documentation may require little more than well-managed SharePoint content with accurate permissions. 

A portfolio reporting assistant producing fund performance metrics requires integrated, validated data before anyone should rely on its outputs. 

Rather than treating data quality as one large transformation programme, successful firms phase improvements around each priority use case. The data platform grows incrementally as new capabilities demand it, allowing value to be delivered much earlier. 

Document-based AI requires a different kind of readiness altogether. 

Metadata. 

Taxonomy. 

Version control. 

Sensitivity labels. 

Deduplication. 

These may sound mundane compared with large language models, but they often determine whether document-based AI succeeds. Poorly organised SharePoint estates, duplicated files and uncertainty over draft versus final versions quietly reduce the quality of every AI-generated output. 

For many firms, document management becomes the first AI project, not because it is glamorous, but because every subsequent use case depends on it. 

The framework above illustrates the principle at the heart of successful AI implementation: governance is not defined by what a policy says, but by how that policy is enforced within the technology estate. 

Every control in the framework ultimately comes down to configuration. Organisations need to decide which AI services are approved, how data is classified, who can access it, how outputs are reviewed, and how those decisions are maintained over time. These are not one-off implementation tasks: they become part of the organisation’s operating model. 

This matters because configuration is not static. A control can be correctly implemented today and weakened tomorrow because a setting is changed, a permission is extended, or a new platform feature alters how information can be accessed or shared. What appears to be a relatively small technical change can have consequences well beyond the system in which it was made. 

AI makes this particularly important. Enterprise assistants can search, synthesise and surface information at a scale that was previously impractical. A permission that has been too broad for years, or a security setting that nobody realised had changed, can suddenly become much more consequential. Controls therefore need clear ownership, ongoing monitoring and periodic testing. 

Of those controls, permissions deserve particular attention because they are frequently misunderstood. 

Enterprise AI assistants generally inherit existing user permissions. They do not create new access rights or bypass security controls. What they do exceptionally well is expose permission models that have gradually deteriorated over time. 

Information that was technically accessible but practically impossible to find suddenly becomes discoverable through natural language. 

That distinction matters because the correct response is not restricting AI. It is reviewing and remediating the underlying permissions that already exist. 

The same principle applies to citations. 

When an AI assistant generates analysis across a data room, SharePoint estate or investment archive, citations are far more than a convenience. They provide traceability, allowing reviewers to verify where information originated and whether it supports the conclusion being presented. 

In that sense, citations become part of the governance model. They transform human review from an expectation into an evidence-based control, giving users confidence in both the output and the process behind it. 

The temptation after selecting an AI platform is to deploy it broadly and wait for valuable ideas to emerge. 

Successful firms do the opposite. 

They choose one carefully defined use case. 

Success is agreed before any configuration begins. 

The business outcome is measurable. 

Ownership is clear. 

Then comes an important decision: 

Configure. 

Buy. 

Or build. 

For organisations early in their AI journey, configuring existing enterprise capabilities is often the fastest route to value. Many firms already license sophisticated AI functionality that remains largely unused. 

As use cases mature and the supporting data foundation improves, specialist products or bespoke development become more attractive because requirements are better understood and expected returns are easier to justify. 

Regardless of the approach, evaluation matters. 

Implementation should include: 

  • Representative test cases with known answers. 
  • Accuracy thresholds appropriate to the business process. 
  • Deliberate testing of permission boundaries. 
  • Documented review criteria. 
  • Named business owners responsible for approval. 

Different use cases require different standards. 

A quarterly investor report containing incorrect financial figures has almost no tolerance for error. 

A first-pass summary of an investment memorandum can tolerate considerably more uncertainty because a human reviewer remains part of the workflow. 

Applying identical acceptance criteria to both either blocks useful capabilities or introduces unacceptable risk. 

Technical implementation is only one part of successful adoption. 

People need role-specific training. 

They need examples relevant to their daily work. 

They need opportunities to ask questions once they have begun using the tools rather than only before deployment. 

Experience consistently shows that the second round of training is often more valuable than the first because employees now understand where AI genuinely helps, and where it does not. 

The technology changes quickly. 

Human habits change much more slowly. 

After the first use case succeeds, implementation becomes repeatable. 

Each new project should inherit what has already been built. 

Prompt libraries become organisational assets rather than personal collections. 

Configured assistants are version controlled. 

Templates are shared. 

Evaluation frameworks are reused. 

Someone owns the prioritisation of future use cases. 

Someone monitors licensing costs and token consumption. 

Someone decides when a use case should be retired because it no longer delivers sufficient value. 

Operating an AI capability is not simply about adding new use cases. 

It is about managing the ones already in production. 

That means monitoring meaningful adoption rather than licence counts, reviewing changes to vendor terms, and assessing new AI functionality before it is enabled. It also means monitoring the controls around AI itself. Settings change, permissions drift, vendors release new capabilities and models evolve. Governance therefore needs to be continuously validated rather than assumed to remain effective because it was configured correctly at deployment. 

The governance register established during implementation becomes increasingly valuable over time. 

It answers investor due diligence questions. 

It supports internal audit. 

It provides evidence for emerging regulatory obligations, including AI inventory requirements under the EU AI Act. 

Implementation therefore becomes an ongoing operating discipline rather than a one-off technology project. 

Many firms now have AI policies. 

Far fewer have translated those policies into operating controls. 

The clearest indicator that an organisation has moved from AI strategy to AI implementation is not the existence of a governance document. 

It is the evidence that governance has changed the way systems operate. 

Can the firm produce the completed access review? 

Can it show which AI services are enabled and why? 

Can it demonstrate sensitivity labels, DLP rules and permission remediation? 

Can it identify the person who approved the last AI-generated output that informed an investment decision? 

When those things exist, governance is operating. 

When only the policy exists, governance remains an intention—and AI is often progressing faster than the controls designed to manage it. 

That is ultimately the difference between having an AI strategy and having an AI capability. 

Having an AI strategy is only the first step. The real challenge is translating governance into operational controls, prioritising the right use cases, and implementing AI in a way that is secure, measurable and scalable. 

Our AI and Innovation services support firms across three stages of AI maturity: 

  • AI Readiness – Assess and prioritise: Understand your current AI maturity through our AI Healthcheck, identifying gaps and opportunities and establishing practical next steps. From there, define your AI strategy, prioritise high-value use cases, and establish the governance, data and operating foundations needed for successful adoption. 
  • AI Adoption – Implement and embed: Move from strategy and experimentation into practical implementation through governance, training, vendor assessment, and the deployment and adoption of AI across real business workflows. 
  • AI Engineering – Build and scale: Use proven AI accelerators to speed up delivery, and build skills, agents and integrations around your firm’s data and workflows where off-the-shelf capabilities are not enough.