How to run a 30-minute AI working session in private markets

Most AI use cases in private markets do not fail because the model cannot do the work. They stall because the work has not been defined precisely enough to build around it.

Someone says, “We should use AI for this.” A colleague tries a prompt. A demo produces something plausible. Then the idea stops moving when the team asks how it will work every week, which data it can use, where judgement enters, who will review the answer and what production-ready actually means.

The solution is not another brainstorming session. It is a short working session with a narrow objective: turn one piece of workflow friction into a build decision.

01What the 30-minute session is for

The session is a piece of working time, not a general conversation about AI. Its job is to answer five practical questions:

1. What part of the current workflow is causing friction?
2. What data or information does the work actually use?
3. What process—including professional judgement—turns those inputs into an answer?
4. What should the output look like, and how will quality be judged?
5. Is the use case ready to test, missing information or large enough to scope as a project?

That definition matters in private equity, private credit, investment management, asset management and hedge funds because the visible task is often only the final step. The real workflow may cross an inbox, SharePoint, a virtual data room, spreadsheets, portfolio systems, research, internal precedents and several layers of review.

If the session only discusses what an AI tool might do, it will produce ideas. If it follows the work as it happens, it can produce something buildable.

02Preparation decides whether 30 minutes is enough

Before the meeting, send the workflow owner a short email or form asking for three things:

• Access to the raw data or an approved sample. This could be structured data, documents or communications. It must be safe and permitted to use in the session.
• The desired output. Ask what they want the AI to produce or do. A good existing example is far more useful than a verbal description.
• The current process. Ask how the work is completed now, including the systems used, hand-offs, checks and final reviewer.

This lets the facilitator review the problem before the clock starts. It also provides an anchor if the conversation drifts and avoids spending half the session searching for files or requesting access.

Thirty minutes is enough to make a build decision when the evidence is already in the room. It is not enough when the first twenty minutes are spent finding the evidence.

03Use a fixed agenda

The timings are not rigid, but the sequence is. Start with the problem, move through the evidence and end with a decision.

04Confirm the friction—do not start with the tool

The opening question should not be “Which model should we use?” It should be “What is going wrong in the work today?”

Look for friction that is observable:

• a repeated task takes too long;
• different people produce inconsistent outputs;
• important information is difficult to find or reconcile;
• senior reviewers repeatedly correct the same omissions;
• handoffs create delay or duplicated effort;
• the work is hard to audit, evidence or reproduce.

Ask what happens immediately before the problem and what happens immediately after it. This prevents the group from automating the visible symptom while leaving the actual bottleneck untouched.

A good friction statement is specific enough to test. “Our reporting process is inefficient” is not. “The team spends three hours every Friday reconciling updates from four sources before a reviewer can draft the weekly summary” is.

05Look at the data in context

In this session, “data” means any input the workflow relies on. It may be quantitative figures in Excel or a portfolio platform. It may also be information in a report, investment paper, email thread, Teams message, research document or virtual data room.

Do not just ask what the data is. Establish:

• Location. SharePoint, an inbox, a workbook, a data room, a portfolio system, a research platform or several of them?
• Access. Can the approved AI tooling reach it, and under whose permissions?
• Cadence. Is a new file sent weekly, is one document updated continuously, or does the user assemble the input manually each time?
• Shape. Is the source structured, unstructured or mixed? Are naming and formatting consistent?
• Evidence. Will the output need citations, links, page references or an audit trail back to the source?

Then follow the route the user takes to access it. A workflow description often omits login steps, manual downloads, renamed files, copy-and-paste work and side calculations because they feel too ordinary to mention. Those details are frequently the difference between a useful prototype and a workflow that cannot be repeated.

06Map the process and surface professional judgement

Walk through the process step by step as it really happens—not as the policy document says it happens.

At every stage, ask:

• What is the person looking for?
• What do they ignore?
• What makes them pause or investigate further?
• What exceptions change the route?
• What would make an experienced reviewer say the answer is incomplete or wrong?

This is often the hardest part in private markets. Important judgement may sit in the head of an investment professional, credit specialist, portfolio operator, risk reviewer or subject-matter expert. The person knows a weak answer when they see one, but the rules have never been written down.

If the judgement cannot be explained, the AI will not apply it consistently. The session does not need to encode every possible edge case, but it should expose the first set of rules, exceptions and human review points that a test version must respect.

07Define the output and the quality bar

Only after the inputs and process are clear should the group define the output.

Ask:

• Is the result a memo, table, dashboard, decision aid, task, email or system update?
• Who will use or review it?
• What must it contain every time?
• What must it never do?
• Does it need citations, page references, links or confidence flags?
• What can the AI draft, and what must a person approve?

Whenever possible, open a strong existing example. Ask the workflow owner to explain why it is good. This creates a concrete quality bar and often reveals requirements that never appear in the first description: ordering, tone, level of detail, house style, mandatory caveats, source attribution and review conventions.

The clearer “good” is, the more useful the first version will be.

08Finish with one of three decisions

The session should not end with “interesting—let’s circle back.” It should end in one of three states:

1. Ready to test. The inputs are accessible, the process can be described, the output is clear and a controlled first version can be judged.
2. Needs more information. A missing sample, system permission, decision rule or output example prevents a sensible test. Name the gap and the person responsible for closing it.
3. Scoped project. The use case crosses enough systems, teams, controls or integrations that it needs a proper project plan rather than an improvised prototype.

Whichever route is chosen, record four things before people leave: the owner, the next action, the success test for the first version and the approval path required before the workflow is treated as production-ready.

A decision not to build is a valid result. Document the reason—data access, weak economics, uncontrolled risk, unclear judgement or lack of adoption—and move on. That is more valuable than leaving another attractive demo in limbo.

09Keep the method broad enough for private markets

The framework is deliberately independent of a particular model, vendor or workflow. The same questions apply across private equity, private credit, investment management, asset management and hedge funds even though the underlying work is different.

Deal and credit teams may operate across data rooms, internal papers, models and communications. Asset managers and hedge funds may have more frequent market, portfolio, research and risk inputs. Investor relations, operations, legal, finance and compliance teams will have their own systems, approval routes and output standards.

The common design problem is the same: connect approved inputs to an explainable process, produce a useful output and preserve the right human judgement and controls.

This approach works particularly well for creating reusable tasks, skills, artifacts and lightweight automations. It also helps identify when those approaches are too small and the work needs integration, governance or a properly funded build.

10What good looks like after 30 minutes

A productive session does not leave the team with twenty exciting AI ideas. It leaves them with one of two things:

• one specific, owned and buildable workflow with a clear first test; or
• a clear, documented decision not to build it yet, including the reason and what would need to change.

The practical output should fit on one page:

• friction statement;
• inputs and access route;
• process steps and judgement rules;
• output definition and example;
• controls and human review;
• owner and next action;
• success test;
• sign-off route.

If you have a larger backlog, use this session after an initial value, feasibility, risk and adoption score. If you need to surface ideas across a wider group, start with a focused use-case hackathon. And if the prototype has to survive a regulated environment, design the route to production from the start—not after the demo—using the principles in shipping AI inside regulated firms.

If the session surfaces one workflow that deserves a real investment decision, the Private Markets AI Proof Sprint takes it through underwrite, working proof, validation and a clear go, revise or stop recommendation.

FAQQuestions about the 30-minute AI working session

Can an AI use case really be scoped in 30 minutes?

Yes—when the workflow owner arrives with an approved data sample, the desired output and a clear explanation of the current process. The goal is a build decision and a testable scope, not a finished production system.

What should participants prepare before the session?

Bring the raw data or an approved sample, an example of the output or action required, and a step-by-step explanation of how the work is completed today.

What counts as data in a private-markets AI workflow?

Data includes structured figures in spreadsheets and systems as well as unstructured material such as reports, investment papers, emails, Teams messages, data-room documents and portfolio updates.

How do you know whether the use case is ready to test?

It is ready when the inputs are accessible, the process and judgement rules can be explained, the expected output is clear, an owner is assigned and the first version has an agreed success test and review path.

Who should attend?

Include the person who performs or owns the workflow and, where useful, an experienced reviewer or data-system owner. Keep the group small enough to inspect the real work rather than discuss it in the abstract.