Most funds are asking which AI tool to buy. The sharper question is what state your operation has to be in before you let a model act inside it.
You have already had the AI conversation. Maybe even 100 AI conversations.
It came up at an IC. It turned up in an LP's operational due diligence questionnaire. It sat in a board pack asking what the firm's plan is. It’s blasted all over LinkedIn. The category is past awareness, and the budget for it is as real as anything.
A companion piece here on this blog argued that AI won't replace fund managers, it will replace operational friction. This one picks up where that leaves off.
The question now is narrower: what does your operating model have to look like before a model can safely take on that friction?
Here is the whole argument in one line: getting value from AI in a fund is an operating-model problem before it is a technology problem. There is no chicken and egg conundrum, it is squarely an operating-model problem before it is a technology problem.
And the part that settles it is the state you let the model read and act on.
Drop a model into a document-and-reconciliation operation and it inherits that operation's condition. Point it at a governed operational state and it inherits that one instead.
That difference is organisational. It is also the part a GP or COO controls.
Adoption Is Not the Same as Value
It’s obvious, so we don’t need to labour the point.
BCG's 2025 AI Radar surveyed 1,803 executives. Around three in four ranked AI among their top three priorities for the year. Around one in four said their organisation had created significant value from it (BCG).
Sit with that gap for a second. High priority. High spend. A much smaller share reporting a return.
MIT's NANDA initiative found the same shape from another angle. Across 300-plus disclosed deployments, plus interviews and senior-leader surveys, it reported that about 95% of the generative AI pilots it studied showed no measurable P&L impact (MIT NANDA, "The GenAI Divide", July 2025). The sample is not comprehensive, and some read the stalled pilots as early rather than failed, so treat the 95% as directional. Both studies are also over a year old and we've come a long way since then. But the findings aren't really the point.
The point is what wasn't found - and what wasn't found was that the models were the problem.
BCG splits the work of a successful effort as roughly 10% algorithms, 20% technology and data, and 70% people and process. MIT names its cause a learning gap: the trouble of fitting a model into the way work runs.
The scarce input is an operation a model can be useful inside.
Reading and Acting Are Different Bars
A more sophisticated reader will push on a claim that is too broad, and "AI needs clean data" is too broad - far too broad for our liking.
A model can do real work against messy, unstructured material:
- Read a data room.
- Summarise a diligence pack.
- Draft a memo or an IC paper.
- Pull themes out of a decade of research.
None of that needs a governed operation behind it. If the job is reading or drafting, your operational state is not the constraint.
The bar rises the moment the model stops assisting a person and starts acting on the operation. Moving a step forward. Flagging an exception for treatment. Preparing a capital call. Building a distribution. In other words, moving from observation to action is where things can start to get tricky.
Acting is a different job, and it carries a precondition: structured, governed data is what lets a model act reliably on the core operating state of a fund.
A precondition, not a guarantee of a good outcome. Anyone selling it as a guarantee is skipping the truth and that may either be ignorance, lack of understanding or intentional - all three warrant pause from your side.
An earlier piece put the foundation plainly: the modern fund is becoming data native. Facts are more useful when they are structured and carry their meaning at the point they are created.
A model reads those facts at machine speed and volume. So it acts on whatever state they are in. Good state gives a model something reliable to act on - messy state means you have automated the mess.
The Question Underneath: Authority and Judgment
This is where AI stops being a data question and becomes an organisational one. It splits in two.
First, authority.
A fund runs on several domains of authority, not one. Our settlement piece set this out. The administrator may be authoritative for the accounts and NAV calculation. The bank is authoritative for cash. The valuation process establishes valuations, and the governing documents establish the terms.
So a model that acts has to know which record governs each material fact.
Authority is assigned by the firm, domain by domain. A model does not supply it. There is no single record it can defer to for everything, and pretending otherwise is how a confident machine ends up acting on the wrong number.
Second, judgment. This one decides what can be delegated at all.
The smart-contracts piece drew the line for executable rules, and it holds for models. Some steps are mechanical. They return the same answer for anyone who runs them:
- A capital-call date.
- A lock-up expiry.
- An eligibility check.
- A step in a distribution waterfall.
Those suit delegation. Other decisions are judgment, and they do not reduce to a rule:
- Whether to waive a breach this once.
- Whether a valuation is reasonable.
- Whether an investor-specific arrangement overrides a standard term.
- Whether a legal interpretation applies.
Clean data and clear authority do not turn a judgment into a mechanical step. Automate the judgment and you tend to add risk rather than take out cost.
Notice what just happened to the question. It stops being "does the model have good inputs" and becomes "does this workflow even contain a decision I can delegate."
A Simple Framework: Four Conditions
The organisational work comes down to four conditions. They are not a maturity ladder to climb in order. They describe the state that lets a model do useful work without becoming a fast new source of risk.
Legible state. Facts are structured, current and carry their meaning at source. The model reads them by reference instead of parsing a document.
Defined authority. Each material fact has a known source of authority. Each decision has an owner. The model can tell the two apart.
Evidence by default. Every action leaves a record of what happened, what governed it, and who stays accountable. It is produced as the work runs.
Redesigned work. Repeatable execution moves to the machine. Judgment, exceptions and oversight stay with the people accountable for them.
A model can add value with some of these missing. It is more likely to add durable value, and less likely to create a fast new source of risk, when all four hold together.
AI Evidence Has to Carry More
Condition three does more than repeat the last piece. It raises the bar.
Our earlier evidence piece set out what an institutional record needs: what happened, who authorised it, against which rule and data, and when. Five things. A human action clears the bar with them.
A machine action needs more to be defensible:
- Which model or agent acted.
- What instructions governed it.
- What data and sources it drew on.
- What tools it called.
- Which policy version constrained it.
- What it produced.
- Whether a person reviewed or approved the result.
Same limit as a human committee, though. The record shows the process was followed. It does not show the decision was correct.
This is not theoretical in Australia. In its review of AI use by licensees, ASIC warned of a governance gap, where adoption outpaces the arrangements meant to contain it, and reminded licensees that they stay responsible for AI whether it is built in-house or bought in (ASIC REP 798, October 2024). APRA's CPS 230, which commenced on 1 July 2025, has put operational resilience and third-party risk on a firmer footing for the entities it regulates and the providers that serve them (APRA).
Read that through a COO's lens. An AI action that cannot show its own working is a control gap first and a convenience second.
The Change Shows Up in How Work Is Divided
When a model takes on a mechanical step, the work does not vanish. Its shape changes.
Time moves from producing a result to approving it. From doing the task to handling the cases the model should not decide. From processing to calibrating what good looks like.
And oversight is more than one job:
- Review and approval.
- Exception handling.
- Quality calibration.
Each needs someone accountable for it. A COO will read that as a change to the operating model and the org chart, not a change to the software licence.
Put the two operating states side by side.
A model on a document-and-reconciliation operation reads scattered records, inherits the reconciliation, and carries the same uncertainty your team does, faster.
A model on a governed operational state reads by reference, acts within a defined authority, and writes its evidence back as it goes.
The studies line up with that picture. Value tends to show up where roles, workflows and governance were redesigned around the model, and to stall where a tool was bolted onto an unchanged process. That is a correlation from survey data, not a law, and your result will turn on your own structure.
Where This Leaves a GP or COO
The takeaway is an order of operations, not a purchase.
- Make the state legible, so a model has something reliable to read.
- Settle authority, so it knows which record governs and who owns each decision.
- Make workflows produce evidence, so a machine action is at least as accountable as a manual one.
- Divide the work, so judgment stays human and repeatable execution moves to the machine.
- Then choose the tool.
Do the organisational work first and you are more likely to be legible to whatever you adopt. Buy first and you tend to find out how much was never settled.
Now step back and notice the through-line across this whole series.
A token laid over a governed state inherits that governance. An API reading a governed state reads something already agreed. A model pointed at a governed state inherits its structure, its authority and its evidence.
The infrastructure is the constant. AI is the newest reason it matters, and it will not be the last.
That is where the product sits. Tranche:source holds the authoritative ownership and entitlement state: who holds which position, in what structure, with which rights. It is authoritative for that layer, not a universal system of record. The administrator stays authoritative for the accounts and NAV, the bank for cash. Tranche:route carries that state through the operation and runs the work that acts on it.
A model is one more actor reading and acting through those layers. So is a token. So is an API.
So here is the whole thing in four lines.
AI raises the value of knowing what is true. It forces authority to be explicit. It makes the record of accountability matter more. And it runs through your operational complexity at machine speed.
Which is the argument for settling that complexity before the model arrives, not after.
You will adopt AI either way. What decides whether it repays the spend is the operating state it lands in. And that is built before the tool.
