Here is the state of AI in private equity as of early 2026. The numbers tell a story that most firms are not ready to hear.
80% of PE and VC firms deployed AI in some capacity by late 2024, a 70% increase from the prior year, according to Bain. Global AI spending is projected to cross $2 trillion in 2026. Vista Equity Partners now requires portfolio companies to submit quantified GenAI goals as part of their operating cadence. Every conference keynote, LP letter, and operating partner offsite includes an AI strategy slide.
And yet. Only about 20% of these firms have operationalized AI use cases that produce measurable returns. The rest are somewhere between “we have a proof of concept” and “we spent six months and do not have much to show for it.”
The gap between AI ambition and AI results is not a technology gap. It is a data gap. AI without clean data is expensive hallucination. And in PE, where every dollar of EBITDA gets multiplied by 10x or more, expensive hallucination is not a tolerable outcome.
This post makes the case that most portfolio companies do not need an AI strategy. They need a data strategy that enables AI. And it provides the framework for building that foundation.
Why AI initiatives fail at portfolio companies
I have been involved in data infrastructure programs at Fortune 100 scale and at mid-market companies with $30M to $300M in revenue. The failure mode for AI is remarkably consistent across both.
The pattern goes like this.
Month 1. The PE firm tells the portfolio company to develop an AI roadmap. The company hires a consultant or a data scientist. Enthusiasm is high.
Month 2. The team identifies three promising use cases. Customer churn prediction. Demand forecasting. Automated reporting. Each one has a clear business case and an excited sponsor.
Month 3. The team starts building the churn prediction model. They need customer transaction history, engagement data, support ticket data, and contract terms in a single dataset. They discover that transaction data lives in the ERP, engagement data lives in the product, support data lives in Zendesk, and contract terms live in a mix of Salesforce and spreadsheets. None of these systems share a common customer identifier.
Month 4. The team spends the entire month building data pipelines to connect these systems. They discover that 23% of customer records in the CRM have no match in the billing system. They discover that the product’s engagement data changed format after a platform migration eight months ago. They discover that contract terms in Salesforce are only current for 60% of active customers.
Month 5. The team has a dataset. It is 77% complete. They build a model. The model’s predictions correlate with churn, but the confidence intervals are wide because of the missing data. The results are interesting but not actionable.
Month 6. The sponsor asks for a status update. The team explains the data quality issues. The sponsor is frustrated. The AI initiative is quietly deprioritized in favor of more pressing operational work.
This is not a hypothetical. I have watched some version of this happen at more than a dozen companies. The AI was not the problem. The data was.
The uncomfortable truth about AI readiness
AI models are sophisticated pattern-matching engines. They find patterns in data and use those patterns to make predictions or generate outputs. The quality of the output is bounded by the quality of the input.
This is not a new insight. It is the oldest truism in computing. But in the AI hype cycle, it gets buried under excitement about what AI can do when the data is good, without honest assessment of what happens when the data is not.
For PE-backed portfolio companies, the implications are concrete.
Bad input data produces bad predictions. A churn model trained on incomplete customer data will predict churn poorly. A pricing model built on inconsistent cost allocations will recommend wrong prices. A demand forecasting model fed with revenue data that does not reconcile across systems will forecast incorrectly.
Data cleaning in service of an AI project is wasteful. When you clean data for a specific AI use case, you solve a narrow problem. When you build a data foundation, you enable every use case. The marginal cost of the second, third, and fourth AI initiative drops dramatically when the foundation is right.
AI does not fix data problems. It amplifies them. If your customer definitions are inconsistent across departments, an AI model trained on that data will learn the inconsistency. It will make predictions based on flawed definitions and present them with confidence. This is worse than having no model at all, because the model gives a false sense of precision.
Five prerequisites for AI readiness
These are not theoretical requirements. They are the specific data capabilities that must exist before AI can produce reliable, operationalizable results. I have arrived at this list through two decades of building data infrastructure, the last several years focused on PE-backed companies.
1. Master data management
What it means. Your core business entities (customers, products, vendors, employees, locations) have a single, authoritative definition and a single source of record. When someone asks “how many customers do we have?” there is one answer, produced by one system, using one definition.
Why AI needs it. Every AI model that touches customer data, product data, or operational data needs to join information across systems. If customer ID 4521 in your CRM is the same entity as account 7803 in your billing system but there is no mapping, the model cannot connect the data. It will treat them as two separate entities and produce wrong results.
What good looks like in practice. A mid-market SaaS company I worked with had customer data in Salesforce, Stripe, and their product database. Before building their master data mapping, they had 12,400 records across the three systems that represented 8,200 unique customers. The 4,200 duplicates and orphans were creating noise in every analysis they ran.
Building the master data mapping took six weeks. It was not glamorous work. It involved fuzzy matching on company names, domain matching on email addresses, and manual review of 300 edge cases. But once it was done, every downstream analysis improved immediately. Customer lifetime value calculations became accurate. Retention rates could be measured consistently. And when they eventually built a churn prediction model, it worked on the first iteration because the underlying data was clean.
The minimum bar. You do not need a master data management platform. You need a documented mapping between your core systems and a process for keeping it current. A spreadsheet maintained by one person with a monthly reconciliation is better than no master data management at all.
2. Data quality baseline
What it means. You know how good your data is, quantitatively. Not “we think it’s pretty clean” but “customer address completeness is 89%, email validity is 94%, revenue allocation accuracy is 97%.”
Why AI needs it. AI models do not handle missing data gracefully. Different models handle it differently, some impute values, some drop records, some produce biased results. You need to know, before training a model, which fields are reliable and which ones are not.
What good looks like in practice. Run automated quality checks on the 20 fields that matter most to your business. Revenue, customer attributes, product categorizations, cost allocations, dates. Measure completeness (is the field populated?), accuracy (does it match reality?), consistency (does it mean the same thing across systems?), and timeliness (is it current?).
A $90M distribution company I assessed had a product categorization field that was 96% complete but only 71% accurate. Someone had populated the field by running a bulk import three years earlier and never updated it. The field looked fine in a completeness check. It was useless for any analysis that depended on product categories.
The minimum bar. Monthly quality reports on the 20 most critical data fields. Track the metrics over time. Set targets. Treat data quality like you treat financial close quality, with documented results and accountability for improvement.
3. Integration layer
What it means. Your systems can share data reliably, repeatably, and with minimal manual intervention. When data moves from your CRM to your data warehouse to your reporting tool, the pipeline is automated, monitored, and produces consistent results.
Why AI needs it. AI models consume data from multiple sources. If the integration between those sources is a monthly CSV export that someone runs manually and loads into Excel, the model cannot be refreshed frequently enough to be useful. Real-time or daily-refresh models require real-time or daily-refresh data pipelines.
What good looks like in practice. You do not need a real-time streaming platform. You need automated, scheduled data movement between your core systems with error handling and monitoring. For most mid-market companies, this means an ETL tool (Fivetran, Airbyte, or similar) pulling data from source systems into a central location, on a daily schedule, with alerts when something breaks.
The minimum bar. Automated daily refresh of your core data (financial, customer, operational) into a central location. The central location can be a data warehouse, a database, or even a well-structured set of tables. The key is automation and monitoring. If a pipeline breaks on Tuesday and nobody notices until the board meeting on Thursday, the integration layer is not ready.
4. Governance framework
What it means. Someone owns data quality. Definitions are documented. Changes to data structures, definitions, or processes go through a review. There are rules about who can modify what.
Why AI needs it. AI models are sensitive to changes in the underlying data. If someone changes the definition of “active customer” in your CRM without updating the model, the model’s predictions shift without explanation. If someone adds a new product category that the model has never seen, the model may produce garbage for that category.
Governance ensures that data changes are intentional, documented, and communicated to downstream consumers, including AI models.
What good looks like in practice. A data dictionary that lists every metric, its definition, its source, and its owner. A change management process that requires approval before modifying metric definitions or data structures. Quarterly reviews of data quality metrics with the leadership team.
This does not need to be heavy. For a company with 15 to 30 key metrics, the data dictionary takes a day to build. The change management process is a shared document that people update when definitions change. The quarterly review is a 30-minute agenda item in the operating review.
The minimum bar. A data dictionary covering the metrics in your board deck and management reporting package, with a named owner for each metric. If the definition of “ARR” exists in one place and one person is accountable for it, you are ahead of 80% of mid-market companies.
5. Skills and literacy
What it means. Your team can work with data. Not just the data analyst or the BI developer. The functional leaders who will consume AI outputs and make decisions based on them.
Why AI needs it. An AI model that produces perfect predictions is useless if the sales VP does not trust it, the operations manager does not understand it, or the CFO cannot validate it. AI adoption is a people problem as much as a technology problem.
What good looks like in practice. The leadership team can interpret a dashboard without someone explaining it. The sales leader understands what a churn prediction score means and how to act on it. The CFO can validate that the model’s inputs match the financial data. Functional leaders ask “what data supports that?” as a reflexive question in meetings.
You do not need everyone to write SQL. You need everyone to think critically about data.
The minimum bar. The top 10 people in the company can answer three questions about every metric they report: What is the definition? Where does it come from? How confident are we in it?
The framework applied
Here is how these five prerequisites sequence in practice.
Months 1 to 3. Assess and plan. Run a data readiness assessment against the five prerequisites. Score each one. Identify the gaps. Build a remediation plan. This is the work described in the PE Exit Readiness Checklist, applied through an AI lens.
Months 4 to 9. Build the foundation. Address master data management and data quality baseline first. These are the highest-leverage items. Most AI initiatives fail because of problems in these two areas. Build the integration layer in parallel if you have the capacity. Start the governance framework with the data dictionary.
Months 10 to 12. Pilot AI use cases. With the foundation in place, identify one or two AI use cases that align with the value creation plan. Build them on top of the clean, integrated data. Measure results. Iterate.
Months 13 and beyond. Scale. Expand AI use cases based on what worked. The marginal cost of each new use case is lower because the foundation supports it. Governance and skills develop through practice.
This timeline looks slow to sponsors who want AI results in 90 days. But consider the alternative. Spending months 1 through 6 on an AI initiative that fails because the data is not ready, then spending months 7 through 12 doing the foundation work anyway. The net result is the same timeline, but with six months of wasted effort and a demoralized team.
The PE-specific argument
Private equity firms have a unique advantage and a unique constraint when it comes to AI readiness.
The advantage. PE firms can mandate data standards across their portfolio. They can require consistent definitions, shared tooling, and common reporting. Vista does this. So do other forward-thinking firms. When the sponsor sets the data standard, the portfolio company does not have to figure it out alone.
The constraint. The hold period is finite. You have three to five years to create value and exit. Every month spent on foundation work that does not produce visible results is a month the operating partner has to defend in the quarterly review.
The answer is to treat data readiness as a value creation activity, not a prerequisite. It is not something you do before you create value. It is how you create value. Clean data enables better pricing decisions today. Documented processes enable faster reporting today. Master data management enables accurate customer analytics today. These are not future benefits. They are immediate operational improvements that happen to also enable AI.
When you frame data readiness this way, the conversation with the investment committee changes. You are not asking for permission to spend twelve months on infrastructure. You are delivering operational improvements every quarter that compound into AI readiness over the hold period.
What to tell the investment committee
If you are an operating partner who needs to align the investment committee on data-first versus AI-first, here is the frame.
The ask. Invest the first three quarters in data foundation work (master data, quality, integration, governance). Begin AI pilots in Q4 of the first year.
The return. Data foundation work delivers operational value immediately (faster reporting, better metrics, fewer reconciliation problems). AI pilots in Q4 build on a solid base and have a higher probability of producing actionable results. The alternative (starting AI now on weak data) has a 60 to 80% failure rate based on industry benchmarks.
The evidence. Point to the companies in the portfolio that tried AI first and the ones that built the foundation first. The pattern is consistent. Foundation-first companies produce AI results faster because they do not spend months fixing data problems inside the AI project.
The timeline. Measurable operational improvements from data work within 90 days. First AI use case producing results within 12 months. Full AI operating cadence within 18 to 24 months.
This is not a slow approach. It is the fast approach that looks slow in month one and looks fast by month twelve.
The bottom line
You do not need an AI strategy. You need a data strategy that makes AI possible.
The five prerequisites (master data management, data quality baseline, integration layer, governance framework, skills) are the foundation. Without them, AI initiatives fail. With them, AI initiatives succeed and scale.
The firms that recognize this will spend less on AI and get more from it. The firms that do not will continue the cycle of ambitious AI roadmaps that produce proof-of-concept demos instead of operational value.
For a practical framework on building the data foundation during the hold period, start with the Post-Acquisition Data Playbook. For the diligence perspective on data readiness, see 7 Data Red Flags That Kill Deals.
For a weekly brief on data strategy, AI readiness, and operational frameworks for PE-backed companies, subscribe to Inside the Data Room. One constraint, one framework, one practical tool. Every week.