The conversation I keep having goes roughly like this. An operating partner calls with a question about their healthcare portco. New AI-assisted prior authorization tool in production, six months running. Efficiency numbers look good. The board is satisfied. Then: "We got a question from compliance counsel about the AI. Are we covered?"
That framing is the problem.
The compliance question itself is legitimate. But "are we covered" reveals the portco is treating this as a documentation exercise, when the real issue is an architecture question. Those require different responses, and confusing them is how portcos get caught unprepared.
The Calendar Operators Are Staring At
The regulatory clock on AI in regulated industries is not theoretical. Healthcare portcos processing AI-assisted clinical or administrative decisions are operating under existing HIPAA obligations that now explicitly cover algorithmic decision tools, and under a growing set of state-level bills requiring explainability for automated clinical recommendations. Several states with significant healthcare populations passed or implemented these requirements between 2024 and 2026.
Financial services portcos using AI for credit underwriting, transaction monitoring, or customer segmentation face an enforcement posture that has sharpened meaningfully over the last two years. The expectation – whether codified in statute or telegraphed through enforcement guidance – is increasingly specific: be able to explain the decision for a given applicant or account. Not "describe how the model works in general." Explain this specific decision.
Insurance companies using AI for underwriting face a patchwork that is consolidating. Several major insurance-regulating states have moved from guidance to rule-making in the last 18 months. The direction is consistent: regulators want to see the record of the decision, not a description of the system.
For portcos with meaningful European customer exposure, the enforcement calendar matters in a different way. The high-risk system obligations covering AI in healthcare, financial services, and insurance at scale carry an explicit documentation requirement: records of automated decisions must be maintained, accessible, and producible on demand.
These aren't being cited individually here. The point is the calendar: over the next 12 to 18 months, the question "can you produce a decision trace for that AI-assisted output" will move from best practice to regulatory expectation for most regulated-industry portcos. That window is already open for some. It is opening for the rest.
Why Legal Review Is the Wrong Frame
When an operating partner hears "compliance question about AI," the instinct is to route it to outside counsel. Counsel reviews the applicable regulations, reads the model vendor's compliance documentation, and produces a memo. The memo notes what applies, describes what the vendor says they support, and recommends a policy. The portco creates the policy. The binder gets thicker.
None of that tells you whether your portco is actually compliant.
What actually determines compliance in a regulated-industry AI deployment is whether the runtime can produce a decision trace. Not whether the model vendor is SOC 2 Type II. Not whether the company has an AI use policy signed by employees. Not whether the legal memo correctly identified the applicable regulation. Compliance is determined by whether, when a regulator or auditor asks "what decision did your system make for this patient, this applicant, this policyholder, and why," you can answer that question with documented, reproducible evidence.
If you cannot answer that question, you do not have a paperwork gap you can close with a memo. You have an architecture gap. Those are not the same problem, and they do not have the same fix.
The Runtime Is Where Compliance Is Decided
Over the past two years I have kept an informal running count of the production AI deployments I reviewed inside PE portfolio companies in regulated industries. The criterion was simple: does the system have a structured decision trace that records the input, the model or agent action, the output, and the timestamp, in a form that can be surfaced on demand?
In more than half of the cases, the answer was no. Not "partial" or "needs improvement." No trace. The model ran. The output went downstream. Nothing was recorded in a format that could be produced for an audit.
This is not a criticism of the engineering teams. These systems were built fast, under pressure, to capture an operational gain. The question of what happens when a regulator asks to see a specific decision in three years was not in scope when the system was built. It usually is not, until someone asks.
The operating partner is the person positioned to ask. The operating partner owns the value creation plan. The operating partner is accountable to the board for the risk profile of the portco. The operating partner is the one who will have to explain to an LP why a healthcare portco received a corrective action notice because its AI-assisted prior authorization tool could not produce a decision trace during a routine audit.
That is an operator problem. It happens to have legal consequences.
What a Traceable Pipeline Actually Looks Like
A decision trace is often treated as more technical than it needs to be, so it's helpful to be concrete about what it means in practice.
We worked with a financial services portco using an AI model to score and route transactions for manual review. Standard use case: the AI assessed a transaction, assigned a risk score, and if the score exceeded a threshold, routed the transaction to a human reviewer who made the final call.
When we arrived, the system had no trace layer. The AI score was used to route the transaction, but the score itself was not persisted. The routing logic was not logged. The human reviewer's decision was recorded in a case management system, but the AI's role in that decision was invisible in the record. If an auditor had asked to see every transaction the AI had flagged over the prior twelve months, the portco could not have produced that list.
We built a trace layer that did three things. First, every AI call logged the input feature set, the risk score, and the model version to an append-only store, keyed by transaction ID. Second, the human review step recorded the AI recommendation alongside the human decision, so any audit could distinguish cases where the human confirmed the AI's flag from cases where they overrode it. Third, the trace was surfaced in a read-only dashboard accessible to the compliance team without requiring a database query.
No proprietary tooling. No new vendor contract. About six weeks of engineering work to wire the trace layer into an existing pipeline. The portco went from "we cannot produce a decision trace for any transaction" to "here is the complete record of every decision this system has touched in the last three years" in one quarter.
The human-approval checkpoint is the other piece that matters. For decisions above a defined risk threshold, the AI recommendation required human sign-off before action was taken. That checkpoint is not just a compliance feature – it is the anchor point in the trace, the moment where a human was informed of the AI's recommendation and made a documented call. Regulators in financial services and healthcare have been converging on requiring exactly this structure for high-stakes automated decisions, not because they distrust AI, but because it is the structure that makes the system auditable.
The architecture is not complicated. The decision to build it is.
Audit the Runtime, Not the Binder
The question I would ask as an operating partner reviewing a regulated-industry portco with AI in production is not "do we have a compliance policy for AI?" It is: "Can you show me the decision trace for any AI-assisted output from the last six months?"
If the portco can pull that up in a few minutes, they are in reasonable shape. If they have to find the developer who built the model and ask what the logging situation is, they are not.
The compliance binder is not evidence of compliance. The decision trace is the evidence. If the trace does not exist, the policy document is a statement of intent, not a record of what the system actually did.
This matters particularly in healthcare and financial services, where the regulatory posture is converging on a specific ask: show me the record of this decision. Not "show me your AI policy." Not "show me your vendor's certifications." Show me the record of this specific decision, for this specific individual or account. That ask has a technical answer or it does not. A legal memo does not provide it.
What to Do Before the Window Closes
The operating partners who have gotten ahead of this problem have done the same thing: they have made the decision-trace question part of their standard portco operating review, alongside revenue, headcount, and technical debt. Not as a compliance checkbox, but as an infrastructure question.
Three questions take fifteen minutes to answer in a quarterly session. Does the runtime produce a structured decision trace? Is that trace accessible to the compliance team without engineering involvement? Is there a defined human-approval checkpoint for decisions above a risk threshold?
If the answers are yes, the portco is in reasonable shape for the coming regulatory expectations. If the answers are no, the portco has a short to-do list, not a compliance crisis. The engineering work to build a trace layer is not large. It takes weeks, not months. The regulatory window is not large either.
The portcos that will have a problem are the ones where the operating partner waited for legal to produce a policy before anyone asked whether the runtime can answer the regulator's actual question. The portcos that will not have a problem are the ones where someone asked to see the trace before the auditor did.