Private Equity's AI Problem Is Not a Model Problem

The pitch to private equity has been the same for two years running: your associates spend their nights reading documents, and the model reads faster. Buy the licenses, hand them out, watch the hours come back.

The hours don’t come back. What comes back is a small population of power users who genuinely like the tool, a much larger population who tried it twice, and an IT invoice nobody wants to defend at the next partner meeting. The reflex diagnosis is that the model isn’t good enough yet. It’s the wrong diagnosis, and it’s expensive, because it points every remedy at the one part of the stack that is improving fastest on its own.

I should say where I’m standing. I don’t work at a private equity firm. I build ML systems in regulated finance — retrieval and agent features inside a compliance-heavy communications platform, and before that quant tooling and market data pipelines. So I’m writing about PE the way an engineer writes about a system they’ve been asked to integrate with: from the shape of the data and the constraints, not from the deal side. The constraints are the interesting part, and in my experience they’re what practitioners consistently underweight when they scope this work.

The short version: a frontier model dropped into a PE firm has nothing to read. The firm’s actual knowledge is not in a database. It’s in mailboxes, expired data rooms, and Excel files named Model_v7_FINAL_JB_rev2.xlsx. Until that changes, you are paying frontier prices for a general-purpose writing assistant.

Why Private Equity Is a Strange Place to Put an LLM

Most enterprise AI thinking assumes a large organization: thousands of employees, a platform team, a data warehouse someone owns, and workflows that repeat often enough to justify automating them. Private equity inverts nearly all of that.

The headcount is tiny and the document surface is enormous. A mid-market firm might run fifteen to forty investment professionals against a few hundred reporting relationships across the portfolio, plus every deal they looked at and passed on. There is no platform team. There is often one person with “technology” in their title, and their real job is vendor management.

The work is bursty and deadline-locked. Diligence is not a steady-state process you can iterate on over quarters. It is three weeks of extreme intensity, then nothing, then three weeks somewhere else. A tool that needs a month of tuning to become useful will never get that month, because the month never exists. Anything you build has to be useful on the first deal it touches.

Confidentiality isn’t a policy, it’s the product. Deal teams are walled from each other by design. An LLP agreement and an NDA are not internal guidelines you can route around with a permissions ticket. This is the constraint that kills the most demos: the impressive version of the tool is the one that can see everything, and the compliant version is the one that can’t.

And the data is genuinely hostile. Not messy — hostile.

Where a PE firm's answers actually live

  EMAIL         ████████████████████████   unstructured, per-person
  DATA ROOMS    ██████████████             per-deal, access expires
  EXCEL         ████████████               semi-structured, no schema
  CIMs / DECKS  ██████████                 PDF, tables rendered as images
  CRM           ████                       structured, chronically stale
  ACCOUNTING    ███                        structured, one silo per portco

                └─ the top four hold most of the value,
                   and none of them are queryable

The two systems that are actually structured — the CRM and the portfolio accounting — hold the least interesting information, and one of them is out of date because keeping it current is nobody’s favorite part of the job. Everything a partner would actually want to ask about lives in the unqueryable half.

This is why “we bought everyone a chatbot” produces nothing. You gave people a very fast reader and no library card.

The Four Workflows

There are exactly four places where this work pays for itself. They are not equally tractable, and they fail in different ways, so it’s worth being precise about each.

Sourcing and screening. The firm has a thesis; it wants companies matching it. This is the workflow most amenable to off-the-shelf tooling, because most of the relevant data is external — company databases, filings, web signal — and the failure mode is tolerable. A false positive costs someone twenty minutes. It’s also the workflow with the least durable advantage, because your competitor can buy the same subscription tomorrow. The edge here isn’t the screening, it’s the accumulated record of what the firm has already seen and rejected, which is internal and which almost nobody has structured.

Diligence. This is where the hours are, and where generic retrieval fails hardest. A diligence question is rarely “find me the section about customer concentration.” It’s “reconcile the churn assumption in the model against what the CRM export actually shows, and tell me if management’s definition of a logo changed between 2023 and 2024.” That is a cross-document, cross-format reconciliation with a numeric answer, and it needs a citation precise enough that an associate can defend it to a partner. Top-k chunk retrieval cannot do this, and worse, it will produce a fluent paragraph that looks like it did.

Portfolio operations. The hundred-day plan, the monthly reporting pack, cross-portfolio benchmarking. Structurally this is the most valuable workflow and the one with the longest lead time, because it requires the same question to be answerable across companies that share no systems, no chart of accounts, and no definition of “revenue.” The unlock isn’t summarization. It’s that a partner can ask one question and get one answer covering eleven companies, which today takes an analyst four days.

LP relations and reporting. Quarterly letters, capital account queries, ad-hoc data requests from institutional LPs who each want a slightly different cut. Highly repetitive, highly templated, and — critically — the output goes to an external party under a legal obligation to be accurate. Which makes it simultaneously the easiest to automate and the scariest, and explains why it’s usually last.

Notice what these have in common. Only the first is really a search problem. The other three are reconciliation problems: take facts that live in incompatible representations and make them agree, with provenance. That’s a data engineering problem wearing an LLM costume.

A Maturity Model

Firms tend to move through four stages. Each stage is gated by something the previous stage has to establish, and skipping a gate is how you end up with an expensive tool nobody trusts.

Stage one, sanctioned chat, is a licensing and policy exercise. Get a frontier model behind SSO with a retention posture legal has actually read, so people stop pasting the CIM into a personal account. This is worth doing on day one and it is worth exactly what it costs — real individual productivity, zero institutional leverage. The gate to stage two is simply having a written answer to “where does the prompt go, and for how long.”

Stage two, corpus retrieval, is where the firm points a model at its own documents. Search and Q&A over memos, decks, data rooms, past IC materials. This is where nearly everyone is, and where nearly everyone stops.

Stage three, workflow agents, means narrow agents that produce a work product rather than an answer: an extraction from a data room into a structured schema, a comparison of this quarter’s reporting pack against the last four, a first-draft memo section with every figure linked to a source cell. The gate is an eval harness. Without one you cannot tell whether a change to the prompt made things better, and you will not ship anything into a live deal that you cannot regression-test.

Stage four, the portfolio data platform, is one resolved entity layer spanning funds, portfolio companies, and time periods, queryable by humans and agents alike. The gate is entity resolution, and it’s a gate because entity resolution is a job someone has to own, not a library you install.

The stages are cumulative and the gates are real. I’ve watched teams in adjacent industries try to jump from two to four by buying a platform, and what they get is stage two with a nicer dashboard.

Why Everyone Stalls at Stage Two

Three reasons, and they’re the same three every time.

There’s no eval harness, so there’s no way to improve. A firm ships document Q&A, it’s impressive in the demo, and then in week three an associate gets a confidently wrong number. Now the tool is “unreliable” — a permanent status, because nobody can measure the unreliability. You need a set of questions with known-correct answers drawn from deals that already closed, and you need to run it on every change. Twenty questions is enough to start. The reason this doesn’t exist isn’t cost, it’s that building it requires someone to go back through old deals and write down what the right answer was, which is unglamorous and looks like it isn’t the project.

The second-order effect is worse than the accuracy problem. Without an eval, every disagreement about the system becomes a matter of opinion, and the loudest skeptic wins by default.

There’s no entity resolution, so nothing composes. “Acme Health” in the CRM, “Acme Healthcare Holdings LLC” in the fund accounting, “Project Falcon” in the diligence folder, and “AHH” in someone’s email are the same company. Until a system knows that, every cross-deal and cross-portfolio question is out of reach, which is to say every question a partner actually wants to ask. This is the single highest-leverage piece of unglamorous infrastructure in the entire stack, and it is almost never anyone’s project because it doesn’t demo.

And permissions were treated as a feature instead of the substrate. This is the one that quietly kills projects at the finish line. Retrieval systems are usually built permission-blind and then have access control bolted on top, typically by filtering results after the fact. That fails in two directions at once: it leaks through summaries and citations even when it filters the chunks, and it’s unauditable, so compliance can’t sign off even when it happens to be correct.

The right model is that identity flows through the whole pipeline — the retrieval index itself is scoped per-principal, not filtered per-response — and every answer carries the provenance of what it was allowed to see. That’s a foundational architecture decision. Retrofitting it means rebuilding.

Q: "What did we underwrite for churn on the last three
    healthcare deals?"

naive RAG    → top-k chunks from whatever the index holds
             → fluent answer, wrong fund, no citation
             → nobody catches it because it reads well

what's needed
             → resolve "healthcare" against a sector taxonomy
             → resolve "we underwrote" to model files, not memos
             → scope the index to what this principal may see
             → cite the cell, the file, and the version
             → return "I can see two of three" when that's true

That last line is most of the trust. A system that says “I can only see two of the three deals you’re asking about, here’s why” is usable in a regulated environment. A system that silently answers from two and reports three is not, and no amount of model quality fixes it, because it isn’t a model behavior — it’s an architecture that never had the information.

Build, Buy, and the Thing In Between

The allocation I’d defend:

Buy the horizontal layer, always. Model access, transcription, generic document Q&A, coding assistance, the meeting-notes tooling. This is commoditizing fast and a firm with no engineering org has no business maintaining any of it. Anything that will be a feature of Microsoft 365 within eighteen months is a purchase, not a project.

Build the entity layer, always. The mapping from every identifier the firm uses to a canonical company, fund, period, and metric definition. This is the one thing no vendor can sell you, because it encodes decisions specific to your firm: how you define ARR, which entities roll up to which fund, what “the Acme deal” refers to across four systems and six years. It’s also the asset that makes every future tool cheaper, and it appreciates. Every vendor you onboard afterward plugs into it instead of re-solving it.

Never build the model. Fine-tuning a base model on firm documents is a recurring proposal and it is nearly always wrong here. The corpus is too small, it changes constantly, the confidentiality boundaries are exactly what fine-tuning dissolves, and retrieval against a well-structured corpus outperforms it at a fraction of the cost and risk. The exception is narrow classifiers — routing, document typing, extraction — where a small trained model beats a prompt on both latency and cost. Those are worth building, and they are not what people mean when they say fine-tuning.

The honest version of the build/buy conversation is that the middle layer — the workflow agents — is genuinely contested, and the answer depends on whether your workflows are actually idiosyncratic or you just think they are. Most firms’ diligence processes are more similar than they’d like to believe.

Six Products That Should Exist

These are the gaps I’d point a founder at. I’ve stated each as a problem shape rather than a pitch, because the shape is the part that’s defensible.

Citation-grade diligence extraction. Not “chat with your data room” — a system that takes a data room and a target schema and produces a populated, cell-level-cited structured output, with a calibrated confidence per field and an explicit not found that it is willing to return. The hard part is not extraction, it’s the eval harness that lets a buyer trust field-level accuracy, and that harness is the product. Whoever ships a credible accuracy number on standardized diligence artifacts wins this category, and nobody has.

A cross-portfolio semantic registry. Entity resolution and metric normalization across portfolio companies as a managed service. Ingest whatever eleven companies send, resolve entities, normalize the chart of accounts, and expose one queryable layer. This is the least glamorous item on the list and the one I’d bet on hardest, because it’s the gate on stage four, it compounds with tenure, and switching costs are enormous once it’s populated.

An LP request router. LP data requests are high-volume, highly templated, and currently absorb a startling amount of senior IR time. The workflow — classify the request, resolve which fund and period it concerns, pull from the accounting system, draft in the firm’s format, route to a human for sign-off — is well-defined enough to automate end to end, and the accuracy bar is enforceable because the underlying numbers are already structured. This is the most tractable item here and it’s underserved because it’s unsexy.

Continuous portfolio monitoring over unstructured sources. Board decks, monthly reporting packs, management calls, customer reviews, hiring pages. The value isn’t the summary, it’s the delta and the anomaly: this portco’s reported gross margin definition changed between March and April, this one stopped mentioning its largest customer, this one’s engineering headcount has been flat for two quarters against a plan that assumed growth. Nobody has time to read for that. A system does.

Diligence memory. The firm’s record of everything it has evaluated and passed on, made queryable. “Why did we pass on this in 2023, who ran it, and what has changed since?” This is a genuinely proprietary corpus — nobody else has your pass reasons — and it’s currently stored as a folder nobody opens. Structuring it is the cheapest durable advantage on this list, and it’s the one that gets systematically ignored because it’s about deals that didn’t happen.

Permission-aware retrieval as infrastructure. The one I think is actually the moat. Retrieval where identity and entitlement propagate through indexing, ranking, generation, and citation — not filtering bolted on top — with an audit trail a compliance officer can read. Every product above needs this, most teams build a broken version of it, and it’s hard enough to get right that it’s defensible. It is also, notably, not a private-equity product. It’s a regulated-industry product with private equity as an early, wealthy, and unusually motivated buyer.

If I were choosing one, it would be the registry or the retrieval substrate. They’re the two that everything else is waiting on, they’re both boring enough that the demo-driven competition ignores them, and they’re the two where being early actually compounds instead of just being early.

What Actually Compounds

The firms that will be meaningfully ahead in three years are not the ones with the best model access. Model access is a purchase order. They’ll be the ones that spent an unglamorous year turning a folder hierarchy into a resolved, permissioned, queryable representation of what the firm knows — and then pointed whatever the best model happens to be that quarter at it.

That’s the whole thesis, and it’s the same thesis I keep arriving at from a completely different direction. When I was working on context management for LLM agents, the finding that mattered was that a well-organized thirty-thousand-token context beats a naive eighty-thousand-token one, consistently, because structure lets the model find what it needs. The same thing holds three levels up. A firm with a well-structured corpus and a mid-tier model will outperform a firm with a chaotic corpus and the frontier, and the gap widens rather than closing, because the structured firm can adopt each new model in an afternoon and the other one has to start over.

The model is the part you rent. The corpus is the part you own. Almost everyone is over-investing in the rental.