Six weeks post-close, we were embedded at a mid-market industrials portco that had moved fast on AI. Two LLM-based tools were in production: one for contract summarization, one for inbound sales routing. The operating partner had greenlit both. Nobody had documented what data either model could read.
When we asked the head of engineering to walk us through the data-access boundary on the contract summarization tool, he had to pull the developer who built it off a sprint to answer. That conversation surfaced that the model had read access to customer PII records the sales routing tool had no business touching. The misconfiguration had been sitting there for four months. Nobody had noticed because nobody had designed a reason to notice.
That gap is not unusual. It is the norm. And it is not a reflection on the engineering team. These systems were built fast because the value-creation timeline rewarded that speed. The problem is not the speed. The problem is that "who owns the data-access policy for that model" is a question nobody thought to ask until someone asked.
AI governance is not running at most PE portfolio companies. The AI is running. Governance is not. That gap compounds quietly until a buyer, a regulator, or a quarterly review asks a question nobody can answer.
Why Enterprise AI-Governance Frameworks Don't Map
Every enterprise AI governance framework I have looked at starts from the same assumption: you have a risk committee, a compliance function, and twelve months to stand up a governance program. NIST AI RMF assumes this. Most vendor AI governance playbooks assume it too.
PE portfolio companies operate with none of those things simultaneously. The CTO is often also the head of product. The engineering team is running at sprint velocity on value-creation priorities. In a roll-up, each acquired add-on arrived with its own stack, its own data environment, and its own AI tools deployed before the acquisition closed. There is no single entity with a unified data environment to govern.
Enterprise frameworks break under PE conditions in three specific ways. They require governance committees portcos cannot staff. They assume one entity, not a multi-entity roll-up with several different data environments. And they sequence governance work over quarters, not the compressed timeline a PE value-creation plan runs on.
The solution is not a simpler enterprise framework. It is a completely different model: controls that are minimal, cheap to install, owned by one named person, and designed to survive a lean team.
The Controls That Matter Before an LLM Touches Portco Data
Before any large language model processes portco data, three controls should be in place. Not a governance committee. Three things with named owners.
A living model inventory. One document listing every AI model or tool running in production: what it does, who owns it, what data it reads, and what outputs or decisions it produces. The format does not matter. The discipline does. Someone's job is to update it when a new system deploys and to own the list when a question arrives. Most portcos can build a first version in two days.
A documented data-access policy. A written document scoping what each model is permitted to read. Not a technical enforcement layer on day one. A written policy with a named owner who reviews access requests. This matters most for models that touch PII, financial records, health information, or customer contracts. A portco with no written policy is one misconfigured read permission away from an exposure it will not discover until someone else discovers it for them.
Decision and prompt-response logging. For any model contributing to a material decision, log the model version, the key inputs, and the output. Material means anything that affects a customer relationship, a financial outcome, or a regulatory obligation. The log does not need to be elaborate. It needs to exist and to be retrievable.
These three controls are cheap to stand up. They survive thin teams. They do not require a compliance function. They require a decision that someone is responsible for each one.
For portcos in regulated sectors, add a fourth: a human escalation rule for high-stakes outputs. When a model feeds consequential decisions, define which outputs require human review before action and name who holds that responsibility. This is not about slowing AI down. It is about having a defensible answer when accountability is the question.
Lineage and Audit Trail for When Regulators or Buyers Show Up
The audit trail is where governance connects directly to exit value. When a buyer's diligence team, a regulator, or an auditor arrives, the question is whether the portco can demonstrate provable model ROI, documented data practices, and a logged trail of what each model decided.
In healthcare, financial services, and insurance, the absence of that trail is a liability. In any sector, it compresses the valuation on AI-driven efficiency claims the investment thesis priced in. A model that drove a claimed 20% reduction in customer support costs needs a logged record of what it handled to survive diligence scrutiny.
The full argument on what "defensible" looks like at exit and under a regulator, and how the governance gap maps to multiple compression, is in our companion piece on the exit-diligence liability framework. That piece covers the specific questions buyers are now asking and the failure modes that show up most often in late-stage processes.
What this piece covers is the part that is missing from most governance advice: how to get from zero to an audit-ready governance posture when the mandate is 90 days.
Where to Start When You Are Pre-Governance and the Sponsor Wants AI in 90 Days
Most operating frameworks describe what governance should look like at the end. The question most operating partners actually need answered is how to get there when the portco has no governance starting point and the sponsor wants AI progress by the next quarterly review.
The sequence that works in practice starts with a freeze and an inventory.
Weeks 1 and 2: run the model inventory interview. CTO, engineering lead, and the relevant product owner working from one document. Map every AI system and LLM tool currently in production. For each: what does it do, who owns it, what data can it read, and what decisions does it touch? Simultaneously, freeze net-new model deployments for two weeks. Not permanently. Long enough to establish a governance baseline before it moves again.
Weeks 3 through 6: write the data-access policy for the systems on the inventory. Scope read permissions against the categories of sensitive data the portco holds. Stand up logging on the two or three models that touch the most consequential business decisions, the ones where an undetected wrong output creates the most risk. Those are the systems where a logging gap becomes a liability fastest.
Weeks 7 through 12: build the lineage layer and the escalation rules. For regulated-sector portcos, this means connecting data-access records to model outputs so you can trace what a model decided and on what inputs. For all portcos, it means defining which output categories require human review before action and naming who holds that responsibility. At the end of week 12, the portco has an audit-ready governance layer built without a compliance department, maintained by the team that already owns the systems.
Total time for a portco with five to ten AI systems in production: roughly 40 hours over 12 weeks, heaviest in weeks 1 and 2. This runs alongside the value-creation plan. It is not a separate workstream.
The Working Pattern
The governance that holds in a portco environment is minimal, owned, and logged.
Minimal means covering the controls that matter and nothing else. The model inventory, the data-access policy, and the decision log. The controls that answer the questions a buyer or regulator will actually ask, without a framework rollout.
Owned means one named accountable person for every element. Not a committee. One person who knows it is their job.
Logged means the paper trail exists before anyone asks for it. Decision logs, access records, and the model inventory, all retrievable when the question arrives.
The portcos that are positioned well at exit built this early, when it cost almost nothing. A model inventory takes two days. A data-access policy takes a week. Logging on three critical systems takes another week. The total investment is less than one engineering sprint.
If you are pre-governance right now and the sponsor is asking what your AI readiness looks like, start with the model inventory. Everything else follows from knowing what is running and who is responsible for it.
Blue Orange's Blueprint AI readiness assessment maps your current governance posture, identifies the highest-risk gaps, and produces a 90-day governance plan your team can own. Start the assessment.