The AI literacy and implementation game plan

Most firms now have enough AI access to be dangerous, but not enough structure to be effective. Some teams use Copilot. Some use ChatGPT or Claude quietly. Some have access to connectors, code execution or internal document stores; others are limited to a chat window and a policy PDF. Senior leaders know AI matters, but they often do not know which use cases are real, what is safe, what is blocked, or whether the current tooling is enough.

That is the point of an AI literacy and implementation programme. It should not be a generic course that teaches people ten prompt tricks and leaves them to it. It should be a structured path from what is our current AI maturity? to which workflows are now productionised, governed and used?

This is the game plan I would use inside a private equity, private markets or regulated firm.

Fig 1

01Start with an AI maturity assessment

The first consulting phase is an honest assessment of the current state. Not a glossy benchmark. A practical inventory of what people are doing, what tools they have, what those tools can reach, and where the actual blockers sit.

I would start by looking at four areas:

• Current AI skills. Who is already using AI? What are they using it for? Are they prompting, uploading files, using connectors, building automations, writing code, creating custom GPTs or agents, or just asking basic questions?
• Existing tooling. Which AI products are approved? Which are being used informally? Which features are actually switched on - web access, Microsoft 365 connectors, SharePoint access, code execution, data analysis, image generation, API access, MCP-style connectors, workflow automation?
• Data readiness. Where does the work live? Outlook, Teams, SharePoint, deal folders, CRM, portfolio systems, data rooms, finance systems, spreadsheets, PDFs, databases. The key question is whether high-value use cases can reach the data they need.
• Security and governance. What data can be used? What cannot? Who approves tools? Are there audit trails? Human review points? Restrictions on client data, confidential information, copyright material or regulated outputs?

This is also the right point to agree success metrics. Some firms want time saved. Some want higher adoption. Some want more active usage, more messages sent through approved tools, fewer shadow-AI behaviours, more implemented AI use cases, or measurable improvement in a particular process. If the KPIs are not agreed early, the programme turns into vibes.

The assessment should end with a map: what is currently possible, what is technically possible but blocked, what requires new data access, what requires a vendor trial, and what should not be attempted.

02Then move into business-focused adoption

The next phase is adoption, but not adoption in the abstract. The sequence matters.

First, run general AI training. Everyone needs a baseline: what the tools are good at, where they fail, how to structure prompts, how to verify answers, when not to use AI, and what the firm's rules are. This is the horizontal layer.

Then meet teams individually to identify use cases. Investment, portfolio, investor relations, operations, legal, compliance and finance will all have different work patterns. The best ideas normally come from people describing what they hate doing every week. That is where the drudgery is, and drudgery is often where implementation value hides.

After that, run team-specific training sessions around real use cases. A generic "how to use AI" session is useful once. A session that teaches the portfolio team how to summarise board packs, the investment team how to structure first-pass diligence, or the IR team how to produce a controlled first draft of LP Q&A is useful repeatedly.

The map should be both horizontal and vertical. Horizontal means shared skills every team should have: prompting, verification, document analysis, meeting follow-ups, email workflows and low-code automation basics. Vertical means the deep workflows that matter to each team.

Fig 2

Senior people need their own track too. Their use cases are often different: productivity, faster access to firm knowledge, reviewing materials before meetings, interrogating portfolio data, preparing for calls, summarising long chains of communication. A one-to-one setup session is often more valuable for a senior user than a group workshop, because the bottleneck is not knowledge of AI in general. It is configuring it around their own week.

During these sessions, champions should be identified. Every team needs two or three people who will go deeper, test harder use cases, help colleagues, and become the local source of practical knowledge. The consultant's role should be hands-on enough to unblock, but hands-off enough that the team builds capability itself.

03Use-case generation is not the hard part

Most AI programmes do not suffer from a shortage of ideas. They suffer from a shortage of productionised delivery. Anyone can create an "almost there" solution with dummy data, a friendly prompt and no governance. That means very little. The useful question is whether the output can be generated repeatedly, on real data, inside approved systems, by the people who need it, with the right review points.

The use-case process should therefore work like a ladder. First, collect as many ideas as possible. Do not filter too early. Then merge duplicates, because the same need will appear in different words across teams. Then decide what to focus on by value, feasibility and risk.

The first rung is easy: a demo using dummy data. The second rung is harder: a reproducible output using real inputs. The third rung is the real prize: a productionised workflow that is connected, governed and used.

Fig 3

This is why hackathons are useful when they are designed properly. A focused hackathon can surface use cases, test feasibility, identify champions and create momentum in a way that a survey cannot. But the standard should be implementation, not novelty. The output should be something that can be taken into the team's real workflow, or at least something that has a clear path to get there.

More difficult use cases should be assigned to small groups of two or three people. Give them access to the consultant, but do not let the consultant simply build the solution for them. They should plan it, test it, understand the blockers, and demonstrate it back to the wider team. Demonstrating on stage matters because it turns AI from an abstract management initiative into something colleagues can see someone like them using.

04Productionisation starts with data access

The fastest way for a use case to die is to ignore where the data lives. If a high-priority use case depends on a data source that is not connected, that fact has to be surfaced quickly. Sometimes the fix is straightforward: connect the relevant system through an approved connector, API or MCP-style integration. Sometimes it is a cadenced raw data download from a system that cannot yet be connected directly. That is not ideal, but it may still be automatable and good enough for phase one.

The practical rule is simple: no serious use case should be approved without an answer to four questions.

1. What data does it need?
2. Where does that data currently live?
3. Can the approved tooling reach it safely?
4. If not, what is the smallest sensible way to bridge the gap?

Existing tooling should usually be prioritised. If the firm already has Microsoft 365, Copilot, approved chat tools or workflow automation, start there. But some use cases will not fit inside the core GenAI stack. AI video generation, specialist research tooling, document review platforms, code agents, voice tools or data extraction products may require a vendor analysis. In those cases, the answer is not "buy the shiniest product". It is a structured competitor review, a controlled trial, clear success criteria and a decision process.

05Governance should be a product, not a blocker

Governance is often treated as the thing that slows AI down. That is backwards. Good governance speeds up sensible decisions because people know the route from idea to trial to approval.

A lightweight AI governance framework should cover at least: hallucinations, confidential data, copyright, human approval, audit trails, regulatory requirements, and where AI should not be used. The aim is not to create a giant committee. The aim is to make decisions repeatable.

Every new tool trial should have a small trial plan: owner, user group, use case, data involved, risk classification, controls, duration, KPI, cost, and exit rule. If it succeeds, there is a basis for rollout. If it fails, the firm has learned something without leaving a half-approved tool floating around the organisation.

Fig 4

The use-case pipeline should have a traffic light system. Green means the data is available, the tooling is connected, and the risk is acceptable. Orange means the use case is possible but currently blocked: a connector is missing, a cost has been identified, a vendor choice is needed, or access has not yet been approved. Red means the use case is impossible, not approved, too risky, or too expensive. A red light is not a vague no. It should state the reason.

Fig 5

06Create the internal AI marketplace

AI knowledge decays quickly if it is trapped in meetings. A centralised resource hub should be created early and maintained as the programme develops. It does not need to be complicated, but it does need to be useful.

Employees should be able to browse:

• approved tools and usage rules;
• prompts that have worked inside the firm;
• custom GPTs, agents or skills;
• automations and workflow templates;
• tutorial videos and recordings;
• implemented use cases, filtered by team, system, status and value;
• known blockers and how they were resolved.

This is not a document library for its own sake. It is an internal marketplace for reuse. If the legal team has created a strong clause review workflow, the investment team may be able to adapt the same pattern for a diligence checklist. If one group has built an automation around weekly reporting, another group should be able to copy the structure instead of starting from zero.

07Keep communication alive

The AI space moves too quickly for one-off training to work. Interfaces change. Models change. Features appear, disappear and get renamed. Connectors improve. Security policies evolve. People need a steady communications channel so the programme does not fade after the launch month.

That channel can be Teams, Slack, an email newsletter, a monthly internal post, or a mixture. The content should be practical: new approved features, short demonstrations, adoption statistics, high-quality use cases, mistakes to avoid, upcoming drop-in sessions, and examples of work that has moved from orange to green.

Weekly drop-in sessions are particularly useful. They give people a place to ask whether an idea is possible, get hands-on help, and learn what is not currently feasible. The best sessions are not lectures. They are clinics.

08Treat automation as part of the AI programme

Low-code automation is not separate from AI adoption. Tools like Power Automate, Make.com or n8n can be as important as the model itself, because many valuable workflows are not solved by a better prompt. They are solved by connecting events, files, approvals and systems.

In fact, not all "AI use cases" are actually AI use cases. Some are basic process changes. Some are reporting changes. Some are automations. Some are data access problems. A good consultant should push back and simplify. If a workflow can be fixed without AI, fix it without AI. The point is not to maximise model usage. The point is to improve the work.

09The end state

The end state is not "everyone has had AI training." The end state is a firm with a working AI operating model:

• people know what they are allowed to use;
• teams have real use cases in flight;
• champions exist across the business;
• governance routes are clear;
• AI and automation are treated together;
• new ideas are tracked, triaged and either built, unblocked or stopped;
• approved knowledge, prompts, workflows and tools are centralised;
• usage and value are measured.

That is what AI literacy should mean. Not familiarity with the technology, but the organisational ability to turn it into safe, repeated, useful work.

If you want to build that system inside a private markets or regulated firm, the starting point is a maturity assessment.