Every operating partner working through an AI agenda right now is dealing with a version of the same conversation: the portfolio company CEO is enthusiastic, the vendor is booked, and the budget is approved. What nobody has checked is whether the data underneath the plan can actually carry it.

That gap is not rare. Only 8% of businesses say their data is fully ready to support AI at scale (Dun & Bradstreet AI Momentum survey of 10,000 businesses, November 2026). That is not a number about bad technology choices. It is a number about data foundations that were never stress-tested before the build began.

For a fund with a dozen portfolio companies all running some version of an AI initiative, that readiness gap is not a one-company problem. It is a portfolio-wide risk, and most operating partners are managing it company by company, with no common language and no shared baseline.

Why a single read is only half the answer

Commissioning an independent readiness read for one portfolio company is a sound move. It tells you whether that company’s data can support its AI plan before the capital goes in. Think of it as the structural survey before the renovation: you would not skip it, and the cost of skipping it is always higher than the cost of the survey itself.

But a single read, done in isolation, leaves the harder question unanswered. Across the portfolio, which companies are genuinely ready? Which are about to deploy AI agents before their data is ready? Which are quietly building technical debt that will surface in a buyer’s diligence process and compress exit value?

Weak data and KPI reporting is one of the biggest finance issues at exit. A company that cannot accurately reflect its value-creation initiatives in reported EBITDA leaves a buyer’s diligence team unable to verify the numbers, and the multiple compresses accordingly. That is a carry problem, not just an operational one.

A portfolio-wide baseline changes the frame. Instead of asking ‘is this company ready?’ you are asking ‘where in the portfolio do we have the strongest foundation, where do we have the most urgent remediation need, and where should we sequence our AI capital?’ That is a different, more valuable question, and it is one the IC can actually act on.

The mechanism: why cross-system gaps are where AI projects break

Most portfolio companies already have some kind of data health reporting inside their individual systems. The CRM has its own data quality score. The ERP flags its own exceptions. The HRIS runs its own audits. Each system tells you it is happy with itself.

That is not readiness. AI projects break in the gaps between systems, not inside them. When a model needs to join customer data from the CRM with revenue data from the ERP and headcount data from the HRIS, the inconsistencies that were invisible inside each system become compounding errors in the output. And because the output carries the implied authority of a model, those errors get distributed across every downstream decision before anyone notices.

This is the Amplification Effect. AI does not fix a shaky data foundation. It amplifies it. Errors that sat quietly in one system get multiplied across every decision the model touches. Garbage in, garbage amplified.

An independent read that scores the gaps between systems, not just within them, is the read that comes closest to telling you whether an AI project will deliver. Every platform vendor now ships some kind of readiness score, but a vendor score always points to buying more of that vendor. It cannot score the cross-stack gaps, because it does not have visibility across the whole stack.

Building the portfolio baseline: how it works

A portfolio baseline from DataTruth is not twelve separate reports. It is a single, comparable view: one rule-based method applied consistently across every company, producing a Truth Score™, a score out of 100 for how far the data can be trusted, that an operating partner can drop into an IC deck and read at a glance. Each company starts with a Truth Score Read; the same method then runs across the rest.

Prioritisation by readiness band

The baseline immediately answers the sequencing question. Companies in band A (80 and above, AI ready) are ready to move. Companies in band B (60 and above, Minor issues) or band C (40 and above, Significant work needed) need targeted fixes before AI capital goes in. Companies in band D (below 40, Foundation needed) need a data foundation programme first, and any AI spend ahead of that is at high risk of stalling.

Exit preparation, not just operational improvement

A documented, independently produced Truth Score is a defensible artefact in a sale process. It demonstrates to a buyer’s diligence team that the data underpinning the company’s AI initiatives has been independently verified, not self-reported. The companies that can prove their data supports their AI story, with independent evidence, command a different conversation at exit.

A common language across the portfolio

The quieter benefit of one method across many companies is a shared vocabulary. Instead of each portfolio company describing its data situation in its own terms, every company is scored on the same six pillars. That makes board reporting cleaner, operating partner time more focused, and IC conversations more grounded.

The compliance dimension

For any portfolio company that operates in or sells into the EU, the EU AI Act adds a compliance dimension to the readiness question, with data governance and documentation obligations that are heaviest for higher-risk AI systems. A portfolio-wide baseline identifies which companies face that obligation and whether their current data practices would satisfy it. Discovering that gap in a diligence process is a worse outcome than discovering it now.

Start before the capital moves

The case for a portfolio-wide baseline is straightforward: it costs less to test readiness before the build than to remediate a failed deployment after it. It produces a defensible, board-ready view of where AI value creation is actually achievable. And it gives operating partners the sequencing logic they need to deploy AI capital where it will compound, not where it will stall.

If you carry an AI agenda across a portfolio without a common baseline, start with one company: get your Truth Score, then apply the same method across the rest.

Every major platform vendor now ships some version of an AI readiness score. Salesforce will tell you how ready your CRM data is. SAP will tell you how ready your ERP data is. Workday will tell you how ready your HRIS data is. Each of those scores is real, in the sense that it measures something. But each one measures only what that vendor can see, and each one, by design, points towards buying more of that vendor’s products to close the gap.

For an operating partner sitting across a portfolio of a dozen companies, each running a different stack, that is not a readiness score. It is a sales motion dressed up in a dashboard.

The gap between what a vendor score tells you and what your AI investment actually needs to land on is where carry gets left on the table.

Why the gap between systems is where AI projects break

AI does not fail because one system has bad data. It fails because the data flowing between systems, from CRM to ERP to HRIS, is inconsistent, unlinked, or simply wrong in ways no single platform can see. A green score inside Salesforce tells you Salesforce is happy with itself. It tells you nothing about whether the customer records in Salesforce match the revenue records in the ERP, or whether the headcount data in the HRIS lines up with the cost centres in the finance system.

Those cross-system gaps are invisible to any vendor score. They are not invisible to an AI model. The model ingests all of it, treats it as ground truth, and distributes the errors across every downstream decision it touches, with the implied authority of a model behind them. This is the Amplification Effect: AI does not fix a shaky data foundation, it amplifies it. Garbage in, garbage amplified.

When AI projects stall, they rarely stall on the model side. They stall on the data side, specifically on the cross-system coherence that no single vendor is incentivised to surface.

The size of the readiness gap

The scale of the problem is not marginal. Only 8% of businesses say their data is fully ready to support AI at scale (Dun & Bradstreet AI Momentum survey of 10,000 businesses, November 2026). AI use is widespread. Enterprise value from it is not.

This is not a problem of companies that have not started. It is a problem of companies that are already spending. Investment in AI is running well ahead of readiness to run it in production, and the barrier is rarely model selection, compute or talent. It is the quality and lineage of the data.

And the consequences of moving without a proper read are accelerating. Plenty of enterprises have deployed AI agents before their data was ready. That is not a technology problem. That is a governance problem, and it is one that operating partners are in a position to prevent.

What an independent score actually gives you

The case for an independent readiness read is the same case you would make for any independent due diligence. You would not accept a vendor’s own audit of the asset you are buying. You would not let the seller’s accountant sign off on the quality of earnings. The same logic applies to AI readiness.

An independent read looks across the whole stack, scores the gaps between systems rather than the health of any single system, and produces a number that is defensible to an investment committee. It is not a vendor’s view of their own product. It is an outside view of whether the data can actually carry the AI plan before the capital goes in.

The analogy that holds: you would not start a renovation without a structural survey first. Committing AI budget to a portfolio company without knowing whether the data can support it is the same bet, just more expensive when it stalls six months in and the remediation cost lands in the next budget cycle.

What operating partners need from a readiness score

• A single, banded score that lets you compare a dozen portfolio companies on one scale, not a different metric from each vendor in each company.
• Coverage of the cross-system gaps, specifically the joins between CRM, ERP, and HRIS, where AI projects actually break.
• Independence from any vendor relationship, so the findings point towards what the business needs, not towards an upsell.
• A board-ready output that an operating partner can drop into an IC deck without translation.
• A remediation roadmap that sequences the fixes by value impact, not by technical complexity.

The exit angle is not optional

This is not only a value creation question. It is an exit question. Weak data and KPI reporting is one of the biggest finance issues at exit. Many firms cannot accurately reflect their value-creation initiatives in reported EBITDA, which compresses exit value when a buyer’s diligence team cannot verify the numbers.

A buyer’s technical diligence team in 2025 and 2026 is looking at data infrastructure with the same scrutiny that financial diligence teams apply to revenue quality. A portfolio company that cannot demonstrate clean, auditable, cross-system data is going to face questions it cannot answer cleanly. The time to build that answer is before the process starts, not during it.

The gap between the companies that capture value from AI and the companies that do not is not the AI model. It is the data underneath it.

Clarity before capital

DataTruth is the independent check on AI investments, commissioned before AI capital goes into a company. A Truth Score Read compares exports from two or more systems record by record and returns a signed memo within 5 working days of complete exports: the Truth Score™ (a score out of 100 for how far the data can be trusted), a Leverability read on the AI in question (which AI ideas you can use now, after fixes, or not at all), the cross-system red flags and a short fix list. The AI Investment Review goes further, with a full remediation roadmap and a board readout. It is the survey before the build.

If you are allocating AI budget across a portfolio and relying on vendor scores to tell you which companies are ready, you are reading the seller’s own audit. Get your Truth Score before the capital moves.

Ask any operating partner where AI projects stall and you will hear the same answers: the model was not right, the vendor overpromised, the team was not ready. Rarely will you hear the honest answer, which is that the data could not hold the weight. And within that, the failure almost never sits inside a single system. It sits in the seams between them.

A portfolio company’s CRM holds customer revenue. Its ERP holds cost and fulfilment. Its HRIS holds headcount and compensation. Each system, audited in isolation, can look perfectly healthy. The CRM team will tell you their data is clean. The finance team will say the ERP is solid. But the moment an AI initiative tries to join those systems, to answer a question like ‘which customers are profitable net of fulfilment cost and sales headcount,’ the gaps appear. Customer IDs do not match. Product codes were reclassified mid-year. Headcount allocations live in a spreadsheet nobody has touched since the last CFO left.

This is where AI projects actually break. Not inside any one system. In the space between them.

Why the readiness gap is wider than most firms realise

The gap between AI adoption and AI value is striking. Almost every company now uses AI in some form; far fewer can point to value at enterprise level. The foundation explains much of it: only 8% of businesses say their data is fully ready to support AI at scale (Dun & Bradstreet AI Momentum survey of 10,000 businesses, November 2026). The gap between ambition and foundation is not a rounding error. It is the dominant story in enterprise AI right now.

None of that is about models or compute. It is about the unglamorous work of making sure a customer record in the CRM means the same thing as a customer record in the ERP, and that both of them are current, complete, and trustworthy enough to act on.

For PE-backed companies specifically, the stakes compound at exit. Weak data and KPI reporting is a recurring finance problem at exit. A buyer’s diligence team that cannot verify the numbers behind a value-creation story will discount the multiple. The operating partner who built the story knows it is real. The buyer, looking at inconsistent data across systems, cannot confirm it. That gap costs carry.

The Amplification Effect: why bad cross-system data gets worse with AI

There is a tempting assumption that AI will surface and fix data problems over time. The opposite is closer to the truth. AI does not fix a shaky data foundation. It amplifies it.

Errors that sat quietly inside one system, affecting one report, one analyst, one decision, get distributed across every downstream output the moment a model is trained on or connected to that data. They arrive with the implied authority of a model behind them. A mismatched customer ID that skewed one dashboard now skews every recommendation the AI produces, at scale, in real time, with confidence scores attached.

Plenty of companies deploy AI agents before their data is ready. That is not recklessness. It is a genuine blind spot: a cross-system view of data quality is rarely on the table when the commitment is made. They have a green light from each system individually, which is not the same thing.

Why a green score inside one platform is not readiness

Every major platform vendor now ships some version of a data health or AI readiness score. The problem is structural: a vendor score tends to point to buying more of that vendor. A CRM vendor’s score will tell you your CRM data is ready. An ERP vendor’s score will say the same about the ERP. Neither has any incentive to tell you that the join between them is broken, because fixing that join is not something either vendor sells.

The gaps between systems are exactly where AI projects break, and they are exactly what vendor-native scores are not designed to find. An operating partner who relies on those scores before committing AI budget is, in effect, asking each contractor to survey their own work before the renovation begins.

The survey before the build

The right sequence is straightforward in principle, even if it is rarely followed in practice. Before committing AI capital to a portfolio company, commission an independent read on whether the data can actually carry the plan.

That is what a Truth Score Read does. We compare exports from two or more systems, record by record: not each system in isolation, but the joins between CRM, ERP and HR, the places where customer, cost and headcount data are supposed to speak to each other. The output is a signed memo with the Truth Score™ (a score out of 100 for how far the data can be trusted), a Leverability read on the AI in question (which AI ideas you can use now, after fixes, or not at all), the cross-system red flags and a short fix list. The deeper AI Investment Review adds a remediation roadmap that tells the operating partner what needs fixing, in what order, before the AI build begins, written for the company’s own team or any outside firm. We never do the work.

The Truth Score is designed to be board-ready. An operating partner can put it in an IC deck and compare portfolio companies on one consistent scale. It is not a vendor’s self-assessment. It is an independent, defensible number that answers the question the investment committee should be asking before every AI initiative: is this company’s data foundation strong enough to support what we are about to fund?

The distance between a company that captures the upside from AI and one that abandons its AI programme mid-build is rarely model quality. It is data foundation. The survey before the build is how you find out which side of that line your portfolio company is on, before the capital goes in, not after.

The practical next step

If you are an operating partner with AI initiatives live or in planning across your portfolio, the question worth asking is simple: do you have an independent, cross-system read on whether the data can hold the weight? Not a vendor score. Not a self-assessment from the internal data team. An outside view, across the full stack, before the budget is committed.

If an AI proposal is on the table, a Truth Score Read tests it against the company’s own records before you sign. If the foundation is solid, you will know it. If it is not, you will know that too.

Agentic AI, the kind that does not just answer questions but takes actions, books meetings, triggers workflows, updates records, is moving from proof-of-concept into production inside portfolio companies right now. The pressure is real: management teams see the competitive narrative, boards ask about AI strategy, and operating partners are being asked to sign off on budgets that assume the technology will deliver.

The problem is the sequence. Many enterprises are deploying AI agents before they are ready. That is not a commentary on ambition. It is a commentary on what happens when the urgency to ship outpaces the discipline to check whether the underlying data can carry the load.

For a PE-backed company, that gap is not a technology footnote. It is a value creation problem with a timeline attached to it.

Why agents break where platforms look fine

Many major software vendors now ship some version of an AI readiness score. The CRM says it is AI-ready. The ERP says the same. So does the HRIS. Management looks at three green lights and concludes the company is prepared.

But agentic AI does not live inside one system. It moves between them. It reads a customer record in the CRM, checks inventory in the ERP, and updates a forecast that feeds into the board pack. The gaps that matter, the ones that cause agents to act on stale data, duplicate records, or mismatched definitions of a simple term like ‘revenue’, sit in the joins between systems. A green score inside one platform is not readiness. It is one system telling you it is happy with itself.

This is the cross-stack problem, and it is where AI projects actually break.

The Amplification Effect: garbage in, garbage amplified

There is a specific mechanism worth understanding before any AI capital goes in. AI does not fix a shaky data foundation. It amplifies it. Errors that sat quietly in one system, a duplicated customer record, an inconsistent cost centre code, a revenue figure that means different things in different tools, get distributed across every downstream decision the agent makes, with the implied authority of a model behind them.

In a manual process, a finance analyst catches the anomaly. In an agentic workflow, the anomaly becomes the input for the next ten decisions before anyone notices. The compounding is fast and the audit trail is opaque.

This is not a theoretical risk. Plenty of companies now use AI; far fewer capture enterprise value from it. The gap between deployment and value is a data problem far more often than a model problem.

The readiness numbers are stark

The macro picture reinforces the point. Only 8% of businesses say their data is fully ready to support AI at scale (Dun & Bradstreet AI Momentum survey of 10,000 businesses, November 2026). Investment is running well ahead of that readiness, and the barrier is rarely the model. It is the quality and lineage of the data underneath.

These are not numbers about laggard companies. They describe the average enterprise. The portfolio company your team is about to fund for an AI build-out almost certainly sits somewhere in that majority.

The exit dimension operating partners cannot ignore

There is a carry angle here that does not always make it into the AI conversation. Weak data and KPI reporting is a recurring finance problem at exit. A company that cannot accurately reflect its value-creation initiatives in reported EBITDA loses exit value when a buyer’s diligence team cannot verify the numbers.

An agentic AI programme that ran on unreliable data does not just underdeliver during the hold period. It creates a diligence liability at exit. The buyer’s team will ask how the AI-driven decisions were made, what data they relied on, and whether the outputs are auditable. If the answer is unclear, the multiple suffers.

The EU AI Act’s governance and data lineage requirements add a compliance layer for any portfolio company that operates in or sells into the EU. Lineage, the ability to trace where data came from and how it moved through a system, is no longer just good practice. For high-risk AI applications, it will be a legal obligation.

The survey before the build

The analogy that holds up is a structural survey. You would not commit capital to a building renovation without first understanding whether the foundations can carry the work. Committing AI budget to a portfolio company without knowing whether the data can support the plan is the same bet, just more expensive when it stalls six months in and the roadmap has to be rebuilt from scratch.

DataTruth is the survey before the build. A Truth Score Read compares exports from two or more of the company’s systems, record by record, and returns a signed memo before the capital goes in: the Truth Score™, a score out of 100 for how far the data can be trusted, a Leverability read on the AI in question (which AI ideas you can use now, after fixes, or not at all), the cross-system red flags and a verdict. For a full AI plan, an AI Investment Review tests every AI bet play by play and adds a remediation roadmap, in order, for the management team or any outside firm to execute.

Because DataTruth sells no AI, no software and no implementation, the score is not pointing towards any vendor’s product. It covers the gaps between CRM, ERP and HRIS, the places where agentic AI actually breaks, and it produces a banded result an operating partner can drop into an IC deck to compare companies across the portfolio on one consistent method.

The distance between AI leaders and everyone else is rarely the model. It is the foundation the model runs on.

Start with clarity

If your portfolio has AI spend on the roadmap and nobody has taken an independent look at whether the data can support it, that is the conversation worth having first. A 30-minute call tells you whether it is worth testing, and commits you to nothing.

By the time a sell-side process launches, most of the value-creation work is done. The management team has hit its targets, the EBITDA story is compelling, and the deck looks strong. Then diligence starts, and the buyer’s team cannot verify the numbers.

This is not a hypothetical. Weak data and KPI reporting is one of the biggest finance issues at exit. Not leverage. Not market timing. Not the quality of the underlying business. The data. The inability to show a buyer, in a clean and auditable way, that the numbers in the deck are the numbers in the systems.

When a buyer cannot verify value-creation initiatives in reported EBITDA, they do one of two things: they discount the multiple, or they walk. Neither outcome is acceptable when carry is on the line.

Why this problem is getting worse, not better

The pressure on data quality at exit has always existed. What has changed is the AI layer sitting on top of it.

Portfolio companies are now expected to have an AI strategy. Buyers are pricing it in. A company that can demonstrate AI-enabled efficiency, AI-assisted forecasting, or AI-driven customer intelligence commands a premium. A company that cannot is leaving a story untold.

But here is the problem: only 8% of businesses say their data is fully ready to support AI at scale (Dun & Bradstreet AI Momentum survey of 10,000 businesses, November 2026). The gap between ambition and foundation is enormous. Using AI is common. Capturing enterprise value from it is not.

The reason is almost never the model. The model is fine. The data underneath it is not.

This matters at exit because a buyer’s technical diligence team now looks at the data stack, not just the financials. They want to know whether the AI initiatives in the deck are real, whether the KPIs are produced by systems that can be trusted, and whether the data infrastructure can carry the next owner’s growth plan. If the answer to any of those questions is unclear, the multiple moves.

The Amplification Effect cuts both ways

Operating partners are familiar with the Amplification Effect in its negative form: AI does not fix a shaky data foundation, it amplifies it. Errors that sat quietly in one system get distributed across every downstream decision, with the implied authority of a model behind them. Garbage in, garbage amplified.

What is less discussed is that the same effect works in the seller’s favour when the data is clean. A portfolio company with verified, cross-system data can demonstrate AI-driven value creation in a way that is auditable and defensible. The buyer’s team can follow the logic from raw data to reported KPI without a gap. That is a premium story, not a discount story.

The companies pulling ahead on AI are not doing it with better models. They are doing it with better data foundations that let the models work as intended.

Where the gaps actually live

Between systems, not inside them

The most common mistake in pre-exit data preparation is treating each system in isolation. The CRM looks clean. The ERP looks clean. The HRIS looks clean. But the KPIs that matter at exit, customer acquisition cost, net revenue retention, EBITDA bridge, headcount efficiency, are produced by joining those systems together. That is where the gaps live, and that is where a buyer’s diligence team will find them.

A green score inside one platform is not readiness. It is one system telling you it is happy with itself. The question is whether the data flows between systems are consistent, auditable, and defensible under scrutiny.

The KPI verification problem

Management teams often know their numbers. The problem is that the path from the number in the deck to the number in the system is not always clear to an outside party. When a buyer asks to see the methodology behind a KPI, the answer should be a clean data lineage, not a spreadsheet maintained by one analyst who has since left the business.

The stakes are rising. The EU AI Act is making data governance and documentation a compliance matter for EU-domiciled or EU-selling companies building higher-risk AI, not just a diligence nicety. Buyers with European exposure will ask for it.

The survey before the build

The right time to find these gaps is not during a sell-side process. It is twelve to eighteen months before one starts, when there is still time to remediate without pressure.

The analogy is straightforward. You would not start a renovation without a structural survey first. Committing to an exit narrative built on AI-driven value creation, without knowing whether the data can support it under scrutiny, is the same bet, just more expensive when it stalls in diligence.

DataTruth is the survey before the build: the independent check on AI investments. A Truth Score Read compares exports from two or more systems record by record and returns a signed memo within 5 working days of complete exports, with the Truth Score™ (a score out of 100 for how far the data can be trusted), the cross-system red flags and a short fix list. The AI Investment Review adds a remediation roadmap that sets out what to fix and in what order, written for your own team or any outside firm to execute. We never do the work.

The Truth Score is not a vendor telling you to buy more of its product. It is a cross-stack read that scores the gaps between CRM, ERP, and HRIS, the gaps that actually break AI projects and compress exit multiples, and produces a banded score an operating partner can drop into an IC deck to compare companies on one consistent scale.

Clarity before capital

The firms that will protect their multiples at exit are the ones that treat data readiness as a value-creation lever, not a technical afterthought. Clean data, verifiable KPIs, and an auditable path from system to reported number are not just hygiene. They are the difference between a buyer who pays full price and a buyer who discounts.

If exits are on the horizon and you are not certain your portfolio companies can answer a buyer’s data diligence questions cleanly, find out now, while there is still time to fix what is broken.

Every week, another portfolio company somewhere comes to its board with an AI initiative. A new forecasting engine. An automated churn predictor. An AI-assisted pricing layer. The ambition is real, the vendor is credible, and the business case looks compelling on paper.

Then, six months later, the project stalls. Not because the model was wrong. Because the data feeding it was.

This is not a fringe outcome. It is what happens whenever a model is pointed at data nobody has checked. The failure mode is rarely the algorithm. It is the foundation underneath it.

The gap between what AI leaders achieve and what most portfolio companies actually get from AI is not a model gap. It is a data gap.

What the Amplification Effect actually means

There is a comfortable assumption buried in most AI business cases: that the model will work with whatever data exists, smooth out the inconsistencies, and surface something useful anyway. That assumption is wrong, and it is expensive.

AI does not fix a shaky data foundation. It amplifies it.

Consider how it plays out. A portfolio company has a CRM that sales reps update inconsistently. Customer segments are miscoded. Deal stages mean different things to different teams. Individually, these are nuisances. A finance director knows to discount the pipeline report by a certain percentage. A head of sales knows which reps are reliable and which are not. The errors sit quietly, managed by institutional knowledge.

Then an AI layer goes on top. Now those errors are not sitting quietly. They are being read as signal. The model is learning from them, weighting them, and distributing its conclusions across every downstream decision, with the implied authority of a model behind them. The finance director no longer knows to apply a discount. The output looks precise. It is not.

Garbage in, garbage amplified. The phrase, and the idea behind what we call the Amplification Effect, is adapted from Dr. Gurpinder Dhillon, speaking on the Robots and Red Tape podcast.

The same dynamic shows up when AI agents go live before their data is ready: the build happens before anyone verifies that the data can carry it.

Where AI projects actually break

The cross-system gap

Most data quality conversations focus on individual systems. Is the CRM clean? Is the ERP accurate? But AI projects do not live inside one system. They pull from CRM, ERP, HRIS, and finance data simultaneously, and they break in the gaps between those systems, not inside any one of them.

A customer lifetime value model needs clean customer records from the CRM, clean revenue records from the ERP, and a consistent definition of what a customer actually is across both. If those definitions do not match, and nobody has checked whether they do, the model is doing sophisticated arithmetic on a flawed premise.

A green score inside one platform is not readiness. It is one system telling you it is happy with itself.

The readiness gap is wider than most assume

Only 8% of businesses say their data is fully ready to support AI at scale (Dun & Bradstreet AI Momentum survey of 10,000 businesses, November 2026). That gap, between strategic intent and operational reality, is where AI budgets go to die.

Very few organisations are ready to run AI agents in production, and the barrier is rarely model capability, compute or talent. It is the quality and lineage of the data.

The constraint is the foundation, not the build on top of it.

The exit dimension operating partners cannot ignore

The Amplification Effect is not only an operational problem. It is an exit problem.

Weak data and KPI reporting is a recurring finance problem at exit. Value-creation initiatives that cannot be traced clearly into reported EBITDA compress exit value when a buyer’s diligence team cannot verify the numbers. An AI initiative that ran on bad data does not just fail to create value. It can actively obscure the value that exists, because the outputs are not auditable and the inputs are not defensible.

A buyer’s operating partner will ask how the AI-driven pricing model was built and what data it was trained on. If the answer is uncertain, the multiple conversation gets harder.

For EU-domiciled or EU-selling portfolio companies, there is a compliance dimension layered on top: the EU AI Act sets data governance and documentation requirements for high-risk AI systems. That is not a problem to leave until the rules bite. The build time is now.

The survey before the build

A structural engineer does not start a renovation by knocking down walls. They survey the building first. They find out what can carry load and what cannot, before any capital is committed to the build on top.

Committing AI budget to a portfolio company without knowing whether the data can support it is the same bet, just more expensive when it stalls at month six.

DataTruth is the survey before the build. A Truth Score Read compares exports from two or more of the company’s systems, record by record, and says in a signed memo whether the data can actually carry the AI plan. The output is one board-ready number, the Truth Score™ (a score out of 100 for how far the data can be trusted), with a Leverability read on the AI in question (which AI ideas you can use now, after fixes, or not at all) and the cross-system red flags. It scores the gaps between CRM, ERP and HR, which is where AI projects actually break, and produces a banded score that an operating partner can drop into an IC deck to compare companies on a single scale.

Every platform vendor now ships some version of a readiness score. But a vendor score tends to point to buying more of that vendor. DataTruth sells no AI, no software and no implementation, and never fixes what it finds, so it has no stake in what the answer is.

Clarity before capital. That is the sequence that protects the multiple.

Before the next AI budget

If you have an AI initiative in the portfolio and you are not certain the data can carry it, a Truth Score Read tests it against the company’s own records before the budget is committed.

Buy-and-build is one of the most reliable value-creation playbooks in private equity. Acquire a platform, bolt on complementary businesses, extract synergies, and exit at a premium multiple on a larger, more defensible revenue base. The logic is clean. The execution, at the data layer, rarely is.

Every acquisition brings a CRM. Sometimes two. Each one was configured by a different sales leader, uses different field definitions, and has been maintained, or not maintained, by a different team. One company calls a prospect an ‘opportunity’ at first contact. Another does not log an opportunity until a proposal is sent. A third has not cleaned its contact records in three years. When you consolidate these systems into a single view of the combined business, you are not consolidating data. You are consolidating contradictions.

The problem is not new. What is new is the cost of ignoring it.

AI does not fix the foundation. It amplifies it.

Operating partners are under real pressure to show AI-driven value creation across the portfolio. That pressure is legitimate. The upside from AI is real, and the IC knows it.

But the readiness gap between ambition and reality is equally real. Only 8% of businesses say their data is fully ready to support AI at scale (Dun & Bradstreet AI Momentum survey of 10,000 businesses, November 2026).

In a roll-up, those odds get worse, not better, because the data problems compound across every entity in the portfolio company. And when you point an AI model at compounded bad data, you do not get a neutral result. You get the Amplification Effect: errors that sat quietly in one CRM get distributed across every downstream decision, pipeline forecast, and pricing model, with the implied authority of a model behind them. Garbage in, garbage amplified.

Deploying AI agents before the data is ready is common. In a roll-up context, that is not just a technology risk. It is a carry risk.

Where roll-ups break: the gaps between systems

The most dangerous data problems in a buy-and-build are not inside any single system. They live in the gaps between systems, between the CRM, the ERP, and the HRIS, where no single vendor’s readiness score can see.

Consider what a typical roll-up operating partner is trying to do: build a consolidated revenue view, identify cross-sell opportunities across the acquired customer bases, and demonstrate organic growth to a future buyer. Each of those objectives depends on CRM data that is consistent, complete, and trustworthy across every entity. When it is not, the analysis is not just imprecise. It is actively misleading.

Common failure modes in roll-up CRM data include:

• Duplicate customer records across entities, inflating the apparent size of the combined customer base.
• Inconsistent revenue attribution, making it impossible to separate organic growth from acquisition contribution.
• Pipeline data that reflects different stage definitions, producing a consolidated forecast that is arithmetically correct and commercially meaningless.
• Missing contact and activity data from acquired companies that never enforced CRM hygiene, leaving the AI with no signal to learn from in those segments.

Every platform vendor now ships some kind of readiness score, but a vendor score always points to buying more of that vendor. A green score inside one CRM is not readiness. It is one system telling you it is happy with itself. It says nothing about whether that system’s data aligns with the ERP sitting next to it, or with the three other CRMs you acquired last year.

The exit consequence operating partners cannot afford to ignore

Bad CRM data is not just an operational inconvenience. It is an exit liability. Weak data and KPI reporting is one of the biggest finance issues at exit, and many firms cannot accurately reflect their value-creation initiatives in reported EBITDA. When a buyer’s diligence team cannot verify the numbers, the narrative collapses and the multiple compresses.

In a roll-up, the diligence exposure is multiplied by the number of entities. A buyer will want to see a clean, consolidated customer view, verifiable organic growth, and evidence that the AI capabilities you have invested in are built on a foundation that will hold. If the CRM data underneath the story is inconsistent, the story falls apart under scrutiny, at exactly the moment when scrutiny is highest.

Readiness is harder still in a roll-up, because it requires consistency across entities, not just within them.

The survey before the build

You would not start a renovation without a structural survey first. Committing AI budget to a roll-up portfolio company without knowing whether the consolidated data can support it is the same bet, just more expensive when it stalls mid-build.

DataTruth is the survey before the build: the independent check on AI investments. A Truth Score Read compares exports from the CRMs, the ERP, the HRIS and the gaps between them, record by record, and returns a signed memo within 5 working days of complete exports: the Truth Score™ (a score out of 100 for how far the data can be trusted), a Leverability read on the AI in question (which AI ideas you can use now, after fixes, or not at all), the cross-system red flags and a short fix list. The AI Investment Review adds a remediation roadmap that tells the operating team what to fix, in what order, to move the score.

Because DataTruth is independent, the Truth Score is not a vendor’s self-assessment. It is a number an operating partner can drop into an IC deck to compare a dozen portfolio companies on one scale, and defend to a future buyer’s diligence team.

In a buy-and-build, clarity before capital is not a nice-to-have. It is the difference between a roll-up that exits on thesis and one that leaves carry on the table.

For most of the last decade, data governance sat in the same mental bucket as cyber insurance and GDPR compliance: necessary, unglamorous, and easy to defer until someone made you deal with it. That framing is now expensive.

Two things have shifted simultaneously. First, AI has moved from pilot to production across the portfolio, which means the quality of the underlying data is no longer an IT concern, it is a P&L concern. Second, buyers and their diligence teams have become significantly more sophisticated about what they are actually buying when they acquire a company. They are not just buying EBITDA. They are buying the reliability of the systems that produced that EBITDA number.

Operating partners who still treat governance as a compliance line item are leaving value on the table at entry, during the hold, and at exit.

The readiness gap is wider than most boards realise

The numbers on data readiness are sobering. Only 8% of businesses say their data is fully ready to support AI at scale (Dun & Bradstreet AI Momentum survey of 10,000 businesses, November 2026).

That is not a statistic about small or unsophisticated businesses. It describes the typical company. Which means it describes a significant portion of the average PE portfolio.

The gap between intention and readiness is not a technology problem. It is a governance problem. Companies are deploying models on top of data that was never structured, validated, or connected well enough to support the decisions those models are now being asked to make.

The Amplification Effect: why governance failures get worse, not better, with AI

There is a mechanism worth understanding here, because it changes the risk calculus considerably.

AI does not fix a shaky data foundation. It amplifies it. An error that sat quietly in one system, a misclassified revenue line in the ERP, a duplicated customer record in the CRM, gets distributed across every downstream decision the model touches, with the implied authority of an algorithm behind it. Garbage in, garbage amplified.

Plenty of enterprises have deployed AI agents before their data was ready. The consequence is not just wasted AI budget. It is operational decisions made on corrupted inputs, at speed, at scale.

Governance is the mechanism that stops this. It is not about documentation for its own sake. It is about ensuring that when a model pulls a number, that number means what everyone thinks it means, and that it came from where everyone thinks it came from.

The exit angle: governance protects carry

Weak data and KPI reporting is one of the biggest finance issues at exit. Many firms cannot accurately reflect their value-creation initiatives in reported EBITDA, which compresses exit value when a buyer’s diligence team cannot verify the numbers.

This is the part of the governance conversation that tends to get operating partners’ attention quickly. The work done during the hold to clean up data lineage, standardise KPI definitions across business units, and connect the CRM, ERP, and HRIS into a coherent picture does not just make AI projects more likely to succeed. It makes the exit story legible to a buyer.

A buyer who can trace every number in the CIM back to a clean, auditable source pays a different multiple than a buyer who cannot. The governance work is the same work either way. The question is whether it happens proactively, when there is time to fix what is broken, or reactively, in the final months before a process when there is not.

The cross-system gap: where AI projects actually break

Most portfolio companies have some version of data quality monitoring inside their individual systems. The CRM has its own health metrics. The ERP has its own validation rules. The HRIS has its own reporting. Each system can tell you it is happy with itself.

The problem is that AI projects do not live inside one system. They live in the joins between systems. A churn prediction model needs the CRM and the billing data to agree on what a customer looks like. A margin optimisation model needs the ERP and the operational data to speak the same language. When they do not, the model either fails or, more dangerously, produces confident-looking outputs built on a broken foundation.

Governance at the portfolio level means owning that cross-system layer, not just the individual systems. That is where the value creation opportunity sits, and it is the area a single-system review never reaches.

What good looks like before the capital goes in

The analogy that holds up well here is the structural survey. You would not commit to a renovation without understanding what is behind the walls first. Committing AI budget to a portfolio company without knowing whether the data can actually support the plan is the same bet, just more expensive when it stalls twelve months in.

The distance between an AI leader and an AI laggard is not the model. It is the foundation the model runs on.

DataTruth is the independent check operating partners commission before that capital goes in. A Truth Score Read compares exports from two or more systems record by record and returns a signed memo within 5 working days of complete exports: the Truth Score™ (a score out of 100 for how far the data can be trusted), a Leverability read on the AI in question (which AI ideas you can use now, after fixes, or not at all) and the cross-system red flags. The AI Investment Review adds a remediation roadmap and a board readout. It is not a vendor score pointing to more of one vendor’s product. It is an independent read across the whole stack, scored on one scale, comparable across a dozen companies in the same IC deck.

With the EU AI Act adding data governance and documentation obligations for EU-domiciled or EU-selling companies building higher-risk AI, there is a compliance catalyst as well. Governance that was a best practice is becoming a requirement.

The conversation worth having now

If you are an operating partner carrying AI ambitions across the portfolio and you are not certain the data foundations are there to support them, that uncertainty is worth resolving before the next board cycle, not after.

Get your Truth Score before the next board cycle. Clarity before capital.

Walk into any IC meeting this year and you will find AI somewhere in the value-creation plan. Faster pricing decisions, automated reporting, predictive churn models, margin improvement through operational intelligence. The ambition is real and, in many cases, the budget is already allocated. What is rarely on the table is a defensible answer to the question that determines whether any of it works: can this company’s data actually carry the plan?

That is not a technical question. It is a capital allocation question, and it belongs in the investment committee.

The readiness gap is not closing

The evidence points one way. Only 8% of businesses say their data is fully ready to support AI at scale (Dun & Bradstreet AI Momentum survey of 10,000 businesses, November 2026). AI use is widespread. Enterprise value from it is not.

This is not early-adopter growing pains. It is the current state of the market. The gap between AI ambition and AI-ready data is wide, and it is not closing fast enough to be ignored at the point of investment.

Why AI amplifies the problem rather than solving it

There is a persistent belief in the market that AI will surface and correct data problems over time. The opposite is closer to the truth. AI does not fix a shaky data foundation. It amplifies it. Errors that sat quietly in one system get distributed across every downstream decision, with the implied authority of a model behind them. Garbage in, garbage amplified.

The specific failure point is almost never inside a single system. A CRM that is internally consistent, an ERP that balances, an HRIS that reconciles: each can look healthy in isolation. The gaps that break AI projects live between those systems, in the joins, the mismatched identifiers, the fields that mean different things in different tools. That is where the model gets confused, where the output becomes unreliable, and where the value-creation thesis quietly stalls.

Plenty of enterprises have deployed AI agents before their data was ready. The consequence is not just wasted budget. It is decisions made on outputs that look authoritative and are not.

What this means for the investment committee

The IC is already comfortable asking hard questions about revenue quality, customer concentration, and management depth. Data readiness deserves the same rigour, for three reasons that map directly to value and carry.

Capital at risk before the build starts

Committing AI budget to a portfolio company without knowing whether the data can support it is a structural bet, not an informed one. You would not start a renovation without a structural survey. The same logic applies here. The cost of discovering the foundation is broken after the capital is in is always higher than the cost of finding out before.

The exit multiple depends on it

Weak data and KPI reporting is one of the biggest finance issues at exit. Many firms cannot accurately reflect their value-creation initiatives in reported EBITDA, which compresses exit value when a buyer’s diligence team cannot verify the numbers. If the AI-driven margin improvement is real but cannot be traced cleanly through the data, a sophisticated buyer will haircut it. The carry impact is direct.

The spread between companies that execute on AI and those that do not is real and growing. The question for the IC is which side of that spread a given portfolio company is actually positioned to land on, not which side the management deck says it will land on.

Regulatory pressure is building

For any portfolio company that operates in or sells into the EU, the EU AI Act brings data governance and documentation obligations, heaviest for higher-risk AI systems. Companies that have not mapped their data lineage face compliance exposure that will surface in the next diligence cycle. Getting ahead of it is straightforward. Getting caught behind it is not.

The case for an independent read

Every major technology vendor now ships some version of a readiness score. The problem is structural: a vendor score always points towards buying more of that vendor. A green score inside one platform is not readiness. It is one system telling you it is happy with itself.

What the IC needs is an independent read across the whole stack, one that scores the gaps between systems rather than the health of any single one, and produces a number that can sit in a deck alongside twelve other portfolio companies on a single comparable scale.

That is what DataTruth is: the independent check on AI investments, commissioned before AI capital is committed. A Truth Score Read compares exports from two or more systems record by record and returns a signed memo within 5 working days of complete exports: the Truth Score™ (a score out of 100 for how far the data can be trusted), a Leverability read on the AI in question (which AI ideas you can use now, after fixes, or not at all), the cross-system red flags and a short fix list. The AI Investment Review goes further, testing every AI bet in the plan, with a remediation roadmap and a board readout. It is the survey before the build.

The memo is written to be understood by an IC member, a CFO, or a CEO without any data-engineering background. The Truth Score is a score out of 100 for how far the data can be trusted, banded A (80 and above, AI ready), B (60 and above, Minor issues), C (40 and above, Significant work needed) or D (below 40, Foundation needed). It is comparable across companies and defensible to a buyer’s diligence team at exit. Clarity before capital.

The practical ask

If AI is in the value-creation plan and the IC has not seen an independent read on the data, the question is not whether to commission one. It is how quickly it can be done before the next capital decision.

To talk it through for one company or across a portfolio, start with a 30-minute call. No vendor agenda, just a straight answer on where to start.

This checklist is designed for operating partners and portfolio company executives evaluating AI initiatives. It distils the common failure points in AI projects into a practical verification framework.

Use case definition

Specific use case identified. The AI application should be precisely defined, not a vague goal like leverage AI or improve operations. What specific prediction or decision will AI support? What input will it receive and what output will it produce?

Business value quantified. The expected financial impact should be calculated with explicit assumptions. How much revenue will be protected or generated? How much cost will be avoided? What is the confidence level in these estimates? Value should be quantified in terms that connect to enterprise value, not just operational metrics.

Success metrics defined. Beyond financial impact, what technical and business metrics will indicate success? What accuracy is required for predictions to be actionable? What adoption level is needed for value realisation? Define thresholds that distinguish success from failure.

Timeline realistic. AI projects routinely take longer than planned to reach production value. Does the timeline account for data preparation, model development, testing, integration, and organisational adoption? Is the timeline compatible with holding period constraints?

Organisational readiness confirmed. Will the business actually act on AI predictions? Is there commitment from the teams who must change their workflows? Have change management requirements been identified and planned for?

Data availability

Required data elements identified. What specific data fields are needed to support the use case? This should be a comprehensive list with enough specificity to enable verification, not a general category like customer data.

Data existence confirmed. For each required element, has the team verified the data actually exists in accessible systems? Do not assume based on system documentation. Verify against actual data.

Historical depth adequate. Does historical data extend far enough back to capture the patterns the model needs to learn? For cyclical phenomena, does data span multiple cycles? Are there discontinuities from system migrations that limit usable history?

Data accessible. Can the data be extracted from source systems in a reasonable timeframe? Are there technical, legal, or organisational barriers to access? Has access been tested, not just planned?

Labels available. For supervised learning, are there reliable labels for the outcome being predicted? If predicting churn, is there a consistent historical record of which customers churned and when? If predicting fraud, are there accurate labels for historical fraudulent transactions?

Data quality

Completeness assessed. What percentage of records have all required fields populated? Is coverage adequate across all segments the model must handle? Are there systematic gaps that would bias training data?

Accuracy validated. Has data accuracy been verified against authoritative sources or through business process review? Are there known accuracy issues that could impact model training?

Consistency confirmed. Is the same entity represented consistently across systems that must be integrated? Have definitions remained stable over the historical period being used for training?

Quality sufficient for use case. Given the specific AI application, are quality levels adequate? Different use cases have different tolerance for quality issues. Has quality been evaluated against use-case-specific requirements?

Remediation scoped if needed. If quality gaps exist, has the remediation work been scoped, budgeted, and scheduled? Is remediation a prerequisite for AI development or can they proceed in parallel? Are remediation timelines realistic?

Data integration

Cross-system requirements identified. Which systems must be integrated to support the use case? What data must flow between them? Have all required integrations been identified?

Entity resolution tested. Can records be reliably matched across systems? Has matching logic been tested on representative samples? What is the expected match rate? How will unmatched records be handled?

Definitions reconciled. Where systems use different definitions for the same concept, has reconciliation logic been defined and validated? Do reconciled values match business expectations?

Integration infrastructure exists. Is there a data pipeline capable of integrating data from required sources? Or must this infrastructure be built? If building is required, has this been included in timeline and budget?

Governance

Data ownership clear. Is there an accountable owner for each critical data element? Do owners understand their responsibility for quality? Do they have authority to enforce standards?

Quality monitoring in place. Are there automated checks that will detect data quality degradation? Who is responsible for responding to quality alerts? Have response procedures been defined?

Documentation adequate. Are data definitions, business rules, and system integrations documented sufficiently to support AI development and maintenance? Would a new team member be able to understand the data?

Privacy compliance confirmed. Does the intended use of data comply with privacy regulations and customer expectations? Has legal reviewed the AI application? Are there consent or notice requirements?

Resources

Technical capabilities available. Does the team have the data engineering and data science skills required? If not, has external support been secured? Are resources committed and available when needed?

Infrastructure adequate. Is computing infrastructure sufficient for model training and deployment? Are required tools and platforms available? If infrastructure must be provisioned, has this been included in plans?

Budget realistic. Does the budget account for data preparation, model development, integration, testing, deployment, change management, and ongoing monitoring? AI projects consistently exceed initial estimates. Has buffer been included?

Timeline has contingency. Is there buffer in the timeline for unexpected issues? AI projects rarely proceed exactly as planned. Has contingency been built in for likely delays?

Risk assessment

Failure modes identified. What could cause the project to fail? Data quality issues? Organisational resistance? Technical limitations? Integration challenges? Have potential failure modes been explicitly identified and acknowledged?

Mitigation planned. For each identified risk, what mitigation steps are planned? Who is responsible for monitoring risks? What triggers would indicate that risks are materialising?

Stage gates established. Are there checkpoints where the project will be evaluated against defined criteria? What criteria would trigger a pause, pivot, or discontinuation? Who has authority to make these decisions?

Exit criteria defined. Under what circumstances would the project be discontinued? Having explicit exit criteria prevents projects from continuing long after they should have been stopped. Have these criteria been agreed with stakeholders?

Using this checklist to audit your data before an AI investment

Review this checklist before committing significant resources to AI initiatives. Every unchecked item represents risk. The more unchecked items, the higher the probability of failure.

Do not proceed with AI development until critical items are verified. Data availability, data quality, and integration feasibility are critical. Proceeding without verification in these areas almost always leads to costly mid-project discoveries.

For items that cannot be verified, make explicit decisions about accepting risk or addressing gaps before proceeding. Document these decisions and ensure stakeholders understand the implications.

This checklist does not guarantee success. But each unchecked item is a risk you carry into the build, and each one you clear before signing is a risk you no longer have to explain to the board. The investment in verification is small compared to the cost of failed AI initiatives.

That positioning is changing rapidly. The rise of AI has elevated data readiness from technical concern to strategic imperative. Boards are asking about data quality. Executive committees are reviewing data readiness assessments. Investment decisions are being gated on data capabilities.

The numbers put it starkly: data readiness is critical for AI-driven business transformation, yet only 8% of businesses say their data is fully ready to support AI at scale (Dun & Bradstreet AI Momentum survey of 10,000 businesses, November 2026). The gap between data importance and data readiness represents both strategic risk and strategic opportunity.

Why boards are paying attention

Several factors are driving board-level attention to data readiness:

AI is now a board-level topic

AI has moved from technology curiosity to strategic priority. Boards are asking about AI strategy, AI investment, and AI risk. They are evaluating competitors’ AI progress and considering AI implications for industry dynamics.

As boards engage with AI, they inevitably encounter data requirements. AI presentations that seemed compelling raise questions about data adequacy. AI failures at other companies prompt questions about data risk. The connection between AI ambition and data readiness becomes clear.

AI failures are visible and expensive

The AI failures of recent years have not gone unnoticed. High-profile projects that consumed large budgets without delivering results draw scrutiny. Post-mortems that identify data issues as root causes create awareness.

Boards that have approved AI investments want to understand why some succeeded and others failed. Data readiness emerges as a key differentiator. This awareness drives demand for data assessment before future AI approvals.

Competitive dynamics are shifting

Industries are beginning to bifurcate between organisations that can leverage AI effectively and those that cannot. The AI-capable organisations are achieving efficiency gains, customer insights, and competitive advantages that AI-challenged organisations cannot match.

Boards recognise that falling behind in AI capability means falling behind competitively. They understand that data readiness determines AI capability. This competitive pressure elevates data readiness to strategic importance.

Data readiness determines AI capability

The most sophisticated AI technology cannot overcome inadequate data. Organisations with strong data foundations can leverage AI effectively. Organisations with weak data foundations cannot, regardless of their AI technology investments.

This dependency makes data readiness a prerequisite for strategic AI capability. Boards that want their organisations to compete effectively with AI must ensure that data foundations support that ambition.

What this means for organisations

The elevation of data readiness to strategic imperative has implications for how organisations approach data:

Data readiness needs executive ownership

Strategic imperatives require executive ownership. Data readiness can no longer be delegated entirely to IT. Executive leadership must own data strategy, champion data investment, and hold the organisation accountable for data outcomes.

This does not mean executives need to manage data operations. It means they need to set direction, allocate resources, and create accountability. The same executive attention applied to other strategic priorities must be applied to data readiness.

Investment must match importance

If data readiness is strategically important, investment should reflect that importance. Organisations that acknowledge data importance while underinvesting in data capabilities are not serious about AI success.

Appropriate investment includes funding for data quality improvement, integration infrastructure, governance capabilities, and data talent. The investment level should reflect the strategic value of AI capability that data enables.

Measurement must be meaningful

Strategic priorities require measurement. Data readiness should be measured in ways that indicate actual AI capability, not just technical compliance.

Meaningful measurement includes readiness scores tied to the specific AI uses the business wants, tracking improvement over time, and connecting data metrics to business outcomes.

Executive dashboards should include data readiness metrics alongside other strategic indicators. Board reporting should address data readiness progress and gaps.

Timelines must be realistic

Data readiness improvement takes time. Quality improvement, integration development, and governance maturation cannot be achieved in quarters. Organisations should plan for multi-year journeys.

Realistic timelines prevent the frustration that comes from expecting quick fixes. They enable appropriate resource allocation over time. They set stakeholder expectations appropriately.

From imperative to action

Recognising data readiness as strategic imperative is necessary but not sufficient. Translating recognition into action requires specific steps:

Assess current state

Understand your actual data readiness, not your assumed readiness. Conduct rigorous assessment that measures the dimensions that determine AI success. Identify specific gaps and their implications.

Assessment should produce findings that executives can act on. Not just technical details but strategic implications. What AI capabilities are enabled by current data? What capabilities are blocked? What investment would be required to close gaps?

Define target state

What level of data readiness is required to achieve strategic AI objectives? Define target state in measurable terms. Identify the gap between current and target state.

Target state should connect to business strategy. What AI capabilities are strategically important? What data readiness would support those capabilities? This connection ensures that data investment serves strategic purposes.

Build the roadmap

Develop a realistic roadmap from current state to target state. Sequence initiatives appropriately. Identify dependencies and risks. Allocate resources to achieve milestones.

The roadmap should be achievable but ambitious. It should demonstrate progress within reasonable timeframes while acknowledging that comprehensive readiness takes years. It should include milestones that enable tracking and accountability.

Execute with discipline

Execute the roadmap with the discipline applied to other strategic initiatives. Track progress against milestones. Address obstacles that emerge. Adapt plans as circumstances change while maintaining strategic direction.

Execution requires sustained attention. Data readiness is not a project that completes but a capability that is built and maintained. Ongoing executive attention ensures that data readiness remains a priority as other demands compete for organisational focus.

The strategic opportunity

While data readiness gaps present risk, they also present opportunity. If so few companies say their data is ready, the organisations that get there will have an advantage over the large majority that have not.

This advantage compounds over time. Organisations with strong data foundations can leverage AI effectively, generating insights and efficiencies that weaker organisations cannot match. They can move faster on new AI applications because their data is ready. They can achieve better results because their data is higher quality.

The strategic question is not whether data readiness matters but whether your organisation will be among those that achieve it. The organisations that treat data readiness as the strategic imperative it has become will be positioned for success in an increasingly AI-driven competitive landscape.

A data-first approach inverts this sequence. Start with understanding your data reality. Identify AI opportunities that align with data strengths. Plan initiatives that are achievable given data constraints. This approach produces better outcomes because it ensures AI investments match data readiness.

Step 1: audit current data state

Before considering any AI use case, understand your current data reality. This means going beyond assumptions and stakeholder impressions to actual measurement of data characteristics.

The audit should cover data inventory documenting what data exists, where it lives, and who owns it. It should include quality assessment measuring completeness, accuracy, consistency, and timeliness. It should examine integration capability assessing whether data from multiple systems can be combined. And it should evaluate governance maturity examining whether organisational capability exists to maintain quality.

The audit should be honest rather than optimistic. Its purpose is to reveal reality, not to confirm hopes. Findings that reveal gaps are as valuable as findings that confirm readiness because they prevent wasted investment.

Document audit findings in a form that can guide subsequent planning. Create a data asset inventory with quality scores. Identify areas of strength and weakness. Note gaps that would block common AI applications.

Step 2: identify AI opportunities aligned with data strengths

With data reality understood, identify AI opportunities that align with data strengths. Where is your data strongest? What AI applications could leverage those strengths?

For example, if your product usage data is comprehensive and high quality, applications like usage-based churn prediction or product recommendation are well-supported. If your transaction data is extensive but customer data is fragmented, applications that depend only on transaction patterns are more feasible than applications requiring customer integration.

This alignment exercise often reveals opportunities that stakeholders had not considered. Data strengths may support valuable applications that were not on anyone’s radar. Conversely, applications that stakeholders assumed were feasible may require data that does not exist.

Prioritise opportunities based on business value, data readiness, and achievability. The best opportunities combine high value with strong data support and realistic implementation paths.

Step 3: gap analysis for high-value use cases

Some AI applications offer significant business value but face data gaps. For these high-value cases, conduct detailed gap analysis to understand what remediation would be required.

Gap analysis should specify what data is missing or inadequate, what remediation would address the gap, what effort and timeline remediation would require, and what residual risk would remain after remediation.

Gap analysis enables informed decisions about whether to invest in remediation. Some gaps can be addressed with reasonable effort, making the use case achievable. Other gaps require extensive remediation that may not be justified by the use case value.

Be realistic about remediation timelines. Data quality improvement takes longer than organisations typically expect. Integration projects have a history of delays. Build buffer into remediation estimates.

Step 4: build the roadmap

With opportunities identified and gaps analysed, build a roadmap that sequences AI initiatives appropriately:

Near-term initiatives are AI applications where data already supports implementation. These can begin immediately and demonstrate value while longer-term work proceeds. Near-term wins build credibility and momentum.

Medium-term initiatives are applications requiring modest remediation that can be completed in a reasonable timeframe. Begin remediation work now so these applications can start when remediation completes.

Long-term initiatives are high-value applications requiring significant data foundation work. Include these in strategic planning but recognise that they require multi-year data investment before AI development can begin.

The roadmap should show dependencies between data work and AI development. It should indicate when each initiative can realistically begin and deliver value. It should be achievable with available resources.

Step 5: budget appropriately

AI budgets often underestimate the full cost of successful implementation. Data-first planning enables more accurate budgeting by surfacing data preparation requirements early.

Comprehensive AI budgets should include data assessment costs for understanding current state and requirements, remediation costs for addressing identified gaps, integration costs for building required data pipelines, AI development costs for model building and validation, change management costs for organisational adoption, and ongoing costs for monitoring, maintenance, and model updates.

Data preparation is routinely one of the largest items in a successful AI initiative. Budgets that allocate most resources to AI technology while minimising data preparation are likely to fail.

Common planning mistakes to avoid

Starting with technology: Selecting AI platforms before understanding data requirements leads to technology that does not match organisational reality. Start with data, then select technology that fits.

Assuming data readiness: Hoping data will be adequate rather than verifying leads to expensive mid-project discoveries. Audit data before committing to AI investments.

Underestimating remediation: Optimistic remediation timelines lead to delays that cascade through AI development. Build realistic buffer into remediation plans.

Ignoring governance: Building AI without governance capabilities leads to short-term success that degrades over time. Include governance investment in AI planning.

Pursuing too many initiatives: Spreading resources across many AI initiatives often means none succeed. Focus on fewer initiatives with adequate resources rather than many initiatives that are under-resourced.

The data-first advantage

Organisations that adopt data-first AI planning achieve better outcomes. They avoid wasted investment in AI initiatives that cannot succeed given data constraints. They focus resources on achievable applications with strong data support. They build data capabilities that enable expanding AI ambitions over time.

The data-first approach requires patience. It may mean deferring exciting AI applications until data supports them. It may mean investing in unglamorous data work before pursuing innovative AI. But the patience pays off in higher success rates and better returns on AI investment.

As you plan AI initiatives for 2026, start with data. Understand your reality. Align opportunities with strengths. Address gaps systematically. Build achievable roadmaps. The organisations that follow this approach will achieve AI success while others continue to struggle with the consequences of technology-first planning.

These are the trends we expect to define AI and data quality in 2026, based on patterns emerging from organisational responses to 2025 challenges.

Trend 1: data readiness assessment becomes standard practice

In 2025, AI initiatives were routinely launched without a rigorous assessment of data readiness. They assumed data would be adequate or that issues would be resolved during implementation. Many learned expensive lessons about these assumptions.

In 2026, expect AI readiness assessment to become standard practice. Executives who approved AI budgets that delivered nothing are now requiring proof of data readiness before approving future budgets. The question is no longer can we do AI but is our data ready for AI, and assessment answers that question.

Assessment will be conducted earlier in AI initiative lifecycles. Rather than discovering data issues during implementation, organisations will identify them during planning. This enables better decisions about whether to proceed, what remediation is needed, and what timelines are realistic.

Assessment methodologies will mature and standardise. Scored frameworks, such as the Truth Score™ (a score out of 100 for how far data can be trusted), will matter more as organisations seek consistent ways to evaluate and communicate readiness. Benchmarking against peers will become common as organisations seek context for their scores.

Trend 2: integration platforms gain prominence

Integration complexity emerged as a top barrier to AI success in 2025. Most valuable AI applications require data from multiple systems, and integrating those systems proved harder than expected.

In 2026, expect growing investment in integration infrastructure. Modern data platforms that unify enterprise data sources are becoming prerequisites for AI, not nice-to-haves. Organisations will invest in platforms that provide unified data access across systems, entity resolution to link records across sources, semantic layers to reconcile definitions, and real-time synchronisation to maintain freshness.

The integration platform market will see continued growth and consolidation. Vendors will compete to be the integration foundation for AI. Organisations will evaluate integration capability as a strategic investment rather than a tactical project.

Trend 3: AI-specific data governance emerges

Traditional data governance focused on compliance, security, and operational quality. These concerns remain important but do not fully address AI requirements.

In 2026, expect emergence of governance frameworks specifically designed for AI use cases. These frameworks will address feature quality monitoring to track the data AI models depend on, model input tracking to maintain lineage from source to prediction, drift detection to identify when data patterns shift from training, and label management to maintain quality of supervised learning targets.

AI-specific governance will complement rather than replace traditional governance. Organisations will operate multiple governance frameworks addressing different concerns. The challenge will be integration across frameworks to avoid duplication and gaps.

Trend 4: synthetic data gains traction

Where real data is insufficient, synthetic data offers an alternative. Synthetic data generation creates artificial data that preserves statistical properties of real data without exposing actual records.

In 2026, expect synthetic data to gain traction for several use cases. Training data augmentation uses synthetic data to expand limited training sets. Privacy preservation uses synthetic data to enable AI without exposing sensitive records. Edge case coverage uses synthetic data to provide examples of rare scenarios underrepresented in real data.

Synthetic data is not a solution for all data limitations. It cannot create information that does not exist in some form. But for specific use cases where synthetic approaches are appropriate, it will become a standard tool in the AI development toolkit.

Trend 5: realistic expectations replace hype

The AI hype cycle peaked in 2024 and 2025. Vendor promises, media coverage, and executive enthusiasm created expectations that reality could not meet. The disappointments of 2025 are recalibrating expectations.

In 2026, expect more realistic expectations about what AI can accomplish and what it requires. Timelines will extend to reflect actual implementation experience. Budgets will expand to include data preparation and integration, not just AI technology. Success criteria will shift from deployment to business outcomes.

This recalibration is healthy. Realistic expectations enable better planning, appropriate resource allocation, and higher success rates. Organisations that approach AI with calibrated expectations will achieve more than those that chase hype.

Trend 6: data quality as competitive advantage

As AI becomes more widespread, the technology itself becomes less differentiating. AI platforms and tools are available to all organisations. What differentiates is the ability to use them effectively.

In 2026 and beyond, data quality will emerge as a sustainable competitive advantage. Organisations with better data foundations will achieve better AI outcomes. They will move faster because they spend less time on data preparation. They will achieve higher accuracy because their models learn from cleaner data. They will sustain results because their governance maintains quality over time.

Data quality is difficult to replicate. It reflects years of decisions about systems, processes, and governance. Competitors cannot quickly match data quality advantages. This makes data quality a durable advantage in ways that AI technology, which competitors can acquire, is not.

Organisations that recognise this will invest in data quality not just to enable specific AI initiatives but to build strategic capability. They will treat data as an asset that appreciates with investment rather than a byproduct of operations.

Preparing for 2026

Organisations preparing for AI success in 2026 should consider several actions:

Assess current state honestly. Understand your actual data readiness rather than assuming adequacy. Identify gaps that would block intended AI applications.

Invest in integration infrastructure. Build the integration capabilities that AI applications will require. Do not wait until specific projects need integration to build it.

Develop AI-specific governance. Extend governance frameworks to address AI requirements. Build capabilities to maintain AI data quality over time.

Set realistic expectations. Plan AI initiatives with realistic timelines and budgets. Ensure stakeholders understand what AI requires and what it can deliver.

Treat data as strategic asset. Invest in data quality as a source of competitive advantage, not just a prerequisite for specific projects.

The organisations that act on these lessons from 2025 will be positioned for AI success in 2026 and beyond. Those that repeat 2025 mistakes will repeat 2025 failures.

What actually happened in 2025

Pilot proliferation without production progress

AI experimentation became close to universal. Boards asked for AI plans, vendors added AI to every product, and most leadership teams could point to at least one pilot, often several.

But piloting did not translate to production. A pilot runs on a curated extract; production runs on the whole estate, with every duplicate, gap and disagreement between systems included. That step is where pilots stalled, consuming budget without delivering proportionate value. By the end of the year, 8% of businesses say their data is fully ready to support AI at scale (Dun & Bradstreet AI Momentum survey of 10,000 businesses, November 2026).

The pilot-to-production gap became the defining challenge of enterprise AI in 2025. Organisations could demonstrate AI potential in controlled experiments but could not scale to production where data quality, integration, and organisational challenges emerged.

Data readiness emerged as the primary blocker

As organisations investigated why pilots failed to scale, data readiness emerged as the primary cause. Not AI technology limitations. Not talent shortages. Not budget constraints. Data.

The specific data issues varied but fell into familiar categories. Insufficient training data existed for intended use cases. Data quality was too poor for models to learn reliable patterns. Integration across systems proved more difficult than expected. Historical data was inconsistent due to definition changes and system migrations.

The pattern was the same across industries: the AI worked on the demo data and struggled on the real thing.

Integration complexity surprised everyone

AI applications that seemed straightforward in isolation proved complex when integration requirements emerged. A churn prediction model needed data from CRM, product usage, support systems, and billing. A demand forecast needed data from sales, inventory, promotions, and external sources.

Each integration introduced challenges. Systems used different identifiers. Definitions did not align. Update timing created inconsistencies. What seemed like a data science project became a data engineering project, and organisations were not prepared for the effort required.

Governance requirements became apparent

Even an AI project that works at launch needs governance to keep working: owners, monitoring and change control that many teams had never set up. Models degraded as data patterns shifted. Data quality drifted when no one monitored it. Changes to source systems broke AI applications.

The organisations that sustained AI success were those that had invested in governance: clear data ownership, quality monitoring, change management, and documentation. Organisations without these capabilities found that AI wins were temporary.

Lessons learned in 2025

Data readiness must precede AI investment

The most expensive lesson of 2025 was that AI investment without data readiness is largely wasted. Organisations that launched AI initiatives before understanding their data paid heavily to discover limitations that a check up front would have revealed for a fraction of the cost.

The sequence that holds up is to invest in data foundations before AI development. They knew their data was ready, or they remediated gaps before building models. They did not assume readiness and hope for the best.

Use-case specificity matters

Generic AI readiness does not exist. Data that supports one use case may not support another. Organisations that assessed readiness generically missed issues specific to their intended applications.

Successful organisations assessed readiness for specific use cases. They asked whether data supported churn prediction specifically, demand forecasting specifically, fraud detection specifically. This specificity revealed gaps that generic assessment missed.

Timelines must be realistic

AI initiatives consistently took longer than planned. Data preparation consumed more time than expected. Model development required more iteration than projected. Integration proved more complex than assumed. Change management took longer than hoped.

Organisations that planned realistic timelines, accounting for these realities, achieved better outcomes than those that projected aggressive timelines they could not meet. Realistic planning also enabled appropriate resource allocation and expectation management.

Organisational change is as important as technology

AI that produces predictions no one uses creates no value. Organisational readiness to act on AI proved as important as technical capability to produce AI.

Successful AI implementations included change management as a core workstream. They engaged business users early. They designed AI outputs for user needs. They trained users and supported adoption. They measured business outcomes, not just technical performance.

Implications for 2026

The lessons of 2025 will shape how organisations approach AI in 2026:

Continued focus on data foundations

Expect continued investment in data quality, integration, and governance. Organisations that deferred these investments in favour of AI technology discovered that AI technology without data foundations does not work. The pendulum is swinging towards foundation investment.

Consolidation in AI tooling

The proliferation of AI tools in 2024 and 2025 will likely consolidate in 2026. Organisations overwhelmed by tool choices will seek integrated platforms that reduce complexity. Vendors will consolidate through acquisition and feature expansion.

Growing sophistication in AI assessment

AI readiness assessment will become standard practice rather than occasional exercise. Organisations burned by launching without assessment will require assessment before future investments. Assessment methodologies will mature and standardise.

Integration as the critical capability

Integration emerged as the binding constraint for many AI initiatives in 2025. Expect growing investment in integration infrastructure, including modern data platforms, integration tools, and data engineering talent. Organisations will recognise that integration capability is a prerequisite for AI capability.

The story of enterprise AI in 2025 is ultimately a story of maturation. The hype that preceded 2025 gave way to realism about what AI requires. The failures of 2025 will inform the successes of subsequent years. Organisations that learn from 2025 will be better positioned for AI success going forward.

The result is organisations with green data quality dashboards that still cannot build working AI systems. The metrics say the data is good, but the AI fails anyway. Something is wrong with how we measure.

The Truth Score™ was built to address these limitations. It is a score out of 100 for how far your data can be trusted, measured on the records themselves rather than on a survey or a self-assessment. Paired with a Leverability read (which AI ideas you can use now, after fixes, or not at all), it tells a CEO or investor whether the data under an AI proposal can carry it, before the money is committed.

How the Truth Score works

The Truth Score measures data across six pillars, each scored from 0 to 100. The pillars carry fixed weights and the same rules apply everywhere, so a score is built the same way at each company. Where a pillar is not assessed, the memo says so. It is rule-based, not AI-generated: the same data, scored on the same date, gives the same score. Every pillar shows what was measured and what was not, and a pillar with no signal is marked not assessed rather than guessed. The full method is set out on our approach page.

Accuracy (22%)

Accuracy measures whether data correctly represents reality. It looks for duplicate records, invalid emails, phone numbers and dates, statistical outliers and inconsistent formats: the errors that make one customer look like three.

A high accuracy score indicates that data reflects reality well enough for models to learn true patterns. A low score indicates that models would learn from erroneous data and reproduce errors in predictions.

Completeness (18%)

Completeness measures whether the data an AI application needs is actually there. It looks at fill rates for required and key fields, and at record-level completeness: what share of records have every required field, not just each field on its own.

A high completeness score indicates that the data volume and coverage are adequate for model training. A low score indicates gaps that would limit training data or leave blind spots in model coverage.

Governance (18%)

Governance measures whether anyone is looking after the data. It looks for records with no owner, stale records nobody has touched, whether lifecycle stages are tracked, and whether changes leave an audit trail.

A high governance score indicates that current quality will persist. A low score indicates that quality may degrade even if current measurements are acceptable.

Consistency (16%)

Consistency measures whether the same thing is recorded the same way. It looks at format standardisation, whether related fields agree with each other, whether dates run in a sensible order, and whether values fall in plausible ranges.

A high consistency score indicates that data can be reliably combined and that historical patterns reflect consistent definitions. A low score indicates definitional shifts that could confuse models.

Connectivity (14%)

Connectivity measures whether your systems agree about the same customer, contract or employee. It matches records between systems (CRM to billing or finance, for example), checks that contacts link to the right companies, and looks for shared identifiers. This is where the surprises usually sit: every system can look clean on its own while the gaps between them are wide.

A high connectivity score indicates that an AI tool drawing on more than one system will see one consistent picture. A low score indicates that it will see several conflicting ones.

Lineage (12%)

Lineage measures whether you can trace where data came from. It looks at whether sources are identified, whether transformations are documented, and whether changes are versioned.

A high lineage score indicates that an AI output can be traced back to the records behind it. A low score indicates that nobody can explain why the model said what it said.

Critical pillars and the cap

A weighted average can hide a fatal gap. If two systems disagree about who your customers are, strong scores elsewhere don’t make the data safe for AI. So three pillars are treated as critical: Accuracy, Completeness and Connectivity.

If the weakest of the three is below 80, the overall score is capped at 0.55 × that pillar + 35, rounded. The cap only ever lowers a score; it never raises one.

A worked example from our sample memo (real engine output on generated test data, not a client): Accuracy 88, Completeness 97, Governance 69, Consistency 88, Connectivity 44 and Lineage 50 give a weighted average of 75. Connectivity is the weakest critical pillar at 44, so the cap is 0.55 × 44 + 35 = 59.2, rounded to 59. The Truth Score is 59: Band C, significant work needed. Without the cap, the same data would have read as a comfortable Band B.

Pillars with too little signal in the exports are shown as “limited signal” or “not assessed”, never guessed.

Use cases: the Leverability read

Different AI applications have different requirements. A demand forecasting model leans on consistent history. A fraud detection model leans on accuracy. A recommendation engine might tolerate some inconsistency but needs high completeness.

The Truth Score keeps its weights fixed, so it stays comparable. Use-case fit is handled separately, by the Leverability read: each AI play or use case is marked Deploy now, Needs work or Blocked, with the reason found in your own records.

The same underlying data can therefore support one AI idea today and block another. That reflects the reality that data ready for one application may not be ready for another.

Interpreting Truth Scores

Truth Scores fall into four bands:

A, 80 and above: AI ready. The data can support AI for the plays assessed. Proceed with reasonable confidence. Minor fixes may improve results but are not blocking.

B, 60 to 79: Minor issues. AI work can proceed but may face challenges. Targeted fixes to the weakest pillars would improve outcomes. Weigh the cost of fixing against accepting some model limitations.

C, 40 to 59: Significant work needed. Gaps exist that would likely undermine AI. Fix the specific blockers before committing serious budget.

D, below 40: Foundation needed. Foundational data work should precede AI development. Investing in AI before addressing data gaps would likely waste resources.

The bands are guidance, not absolute rules. Context matters. A use case with enormous value potential might justify proceeding at a lower score with acceptance of higher risk. A use case with modest value might require a higher score to justify investment.

From score to action

Truth Scores are valuable not just for go/no-go decisions but for directing the fixes:

Prioritise the weakest pillars: Focus on pillars with the lowest scores, especially the heavily weighted ones and the ones your AI plays depend on. Because of the cap, lifting a weak critical pillar matters more than polishing a strong one.

Understand specific gaps: The Truth Score is backed by detailed findings that identify specific issues in specific records. Use these findings to plan targeted fixes rather than broad data quality initiatives.

Set improvement targets: Define the score, and the Leverability read, that would let you proceed with confidence. The remediation roadmap gives each fix an owner, an effort estimate and a “done when” test, written for your own team or any outside firm to execute. We never do the work.

Compare across use cases: If multiple AI use cases are being considered, the Leverability read puts them side by side. Pursue the ones marked Deploy now while fixing the data behind the ones that need work.

Tracking over time

Because the method and the weights are fixed, Truth Scores are comparable over time and across companies scored the same way. A portfolio can be read on one method, one company after another.

A re-read shows whether fixes have landed and whether quality is drifting back. That is the job of AI Value Tracking: a quarterly re-read of the Truth Score and Leverability read for each company, against the roadmap.

Conclusion

Traditional data quality metrics do not predict AI success. A dashboard can be green while the AI built on it fails, because it measures each system on its own. The problem is not measurement execution but measurement design.

The Truth Score addresses this gap by measuring the records themselves, across systems, on fixed pillars, fixed weights and a published cap, and by pairing the score with a Leverability read on the AI in question.

If an AI proposal is on the table, a Truth Score Read tests it against your own records before you sign.

Meanwhile, the actual track record of AI in portfolio companies remains mixed. Behind the success stories presented from the stage sit quiet failures that never make the agenda. The gap between AI hype and AI reality is substantial, and closing that gap requires understanding where AI actually creates value versus where it disappoints.

Where AI is actually creating value

Despite the high failure rate, some PE-backed companies are achieving meaningful AI results. These successes share common characteristics:

Focused use cases with clear ROI

Successful AI implementations target specific, bounded problems with quantifiable value. They do not pursue broad AI transformation. They pursue specific predictions that enable specific decisions with measurable impact.

Examples include demand forecasting that reduces inventory costs by optimising stock levels, churn prediction that enables proactive retention reducing customer loss, pricing optimisation that improves margins through dynamic pricing, and quality prediction that reduces defects through early intervention.

Each of these has a clear value mechanism. Better forecasts lead to lower inventory costs. Earlier churn detection leads to more saves. The connection between AI output and business value is direct and measurable.

Adequate data foundations

Successful implementations build on data that is genuinely ready for AI. This means sufficient historical examples for model training, adequate data quality across required features, reliable integration across source systems, and consistent labels for supervised learning.

The AI initiatives with the best chance are the ones built on data foundations checked before development starts. They treated data readiness as a prerequisite rather than assuming it would be addressed during implementation.

Realistic timelines

Successful implementations plan for the time AI actually requires. They allow months for data preparation, time for model iteration and refinement, gradual rollout rather than big-bang deployment, and ongoing monitoring and maintenance.

For significant AI applications, the time from initiative start to measurable value is usually counted in years, not quarters. Organisations that expect faster results either have exceptional data readiness or are setting themselves up for disappointment.

Organisational readiness to act

AI creates value only when organisations act on predictions. This requires business processes that incorporate AI outputs, users who trust and adopt AI recommendations, decision authority aligned with AI insights, and feedback loops that improve models over time.

Technical AI capability without organisational readiness produces predictions that no one uses. The most sophisticated model creates zero value if recommendations sit in dashboards that no one checks.

Common failure patterns

Failed AI initiatives exhibit predictable patterns that can be recognised and avoided:

Data readiness assumptions

The most common failure pattern is assuming data readiness without verification. Organisations launch AI initiatives believing their data is adequate, only to discover during implementation that data is incomplete, inconsistent, or incompatible.

By the time data problems are recognised, significant resources have been consumed. Projects either continue on inadequate data, producing poor results, or stall for data remediation, missing timelines and budgets.

Scope creep

AI initiatives that start with focused use cases often expand during development. Initial success breeds enthusiasm that expands scope beyond data readiness. What started as churn prediction for one segment becomes churn prediction for all segments. What started as demand forecasting for top products becomes forecasting for the full catalogue.

Expanded scope encounters data limitations that the original scope avoided. The initiative that was succeeding for a narrow scope fails when expanded beyond data support.

Vendor over-reliance

Organisations sometimes rely too heavily on AI vendors to deliver results. They expect vendor platforms to solve data quality issues, provide integration out of the box, and require minimal internal effort.

Vendors can provide technology but cannot provide data readiness or organisational change. Over-reliance on vendors leads to disappointment when vendor technology cannot overcome organisational limitations.

Measurement failure

Some AI initiatives fail to establish clear success metrics or measure results against them. They report technical metrics like model accuracy without connecting to business outcomes. They claim success based on deployment without evidence of value creation.

Without rigorous measurement, successful initiatives cannot be distinguished from failures. Resources continue flowing to initiatives that are not creating value while genuinely successful initiatives may be under-resourced.

A framework for AI value creation

PE firms can improve AI outcomes by applying a structured approach:

Start with value creation priorities

AI should serve the value creation thesis, not drive it. Start with the improvements that would most increase portfolio company value. Then evaluate whether AI can enable those improvements.

If the priority is improving gross margin, evaluate whether AI-driven pricing optimisation or demand forecasting could help. If the priority is reducing customer acquisition cost, evaluate whether AI-driven targeting or personalisation could help. Let business priorities drive AI exploration.

Identify specific, bounded use cases

Translate priorities into specific use cases with clear value mechanisms. Avoid vague objectives like optimise operations with AI. Define specific predictions that enable specific decisions with quantifiable impact.

Good use cases have clear input/output specifications, measurable success criteria, bounded scope that matches data readiness, and direct connection to business value.

Assess data readiness honestly

Before committing to AI development, assess whether data can support the intended use case. This assessment should be honest, not optimistic. It should test actual data, not assume based on system documentation.

Assessment findings should inform go/no-go decisions. Some use cases may be immediately feasible. Others may require data remediation first. Others may not be feasible within reasonable investment. All of these are valuable findings.

Plan realistically

AI plans should reflect realistic timelines, resource requirements, and expectations. They should account for data preparation time, model development iteration, organisational change management, and ongoing maintenance.

Realistic planning prevents the disappointment that comes from unrealistic expectations. It also enables appropriate resource allocation that supports success.

Measure business outcomes

AI success should be measured in business terms, not technical terms. Model accuracy matters only to the extent it translates to business impact. Deployment is not success; value creation is success.

Establish baseline metrics before AI implementation. Measure changes after implementation. Attribute value to AI where attribution is defensible. Report results honestly, including where AI fell short.

The operating partner role

Operating partners are uniquely positioned to improve AI outcomes across portfolios:

Pattern recognition: Operating partners see AI initiatives across multiple companies. They can recognise patterns of success and failure that individual companies cannot see from their single vantage point.

Realistic expectations: Operating partners can push back on unrealistic AI plans based on experience across the portfolio. They can advocate for the data foundation investments that portfolio company executives might skip.

Resource allocation: Operating partners can champion shared AI resources that benefit multiple portfolio companies. They can advocate for data infrastructure investments that enable AI success.

Accountability: Operating partners can hold portfolio company leadership accountable for AI results. They can ensure that AI initiatives are measured and that measurement informs resource allocation.

PE firms that develop operating partner AI capabilities will achieve better AI outcomes than firms that leave AI to individual portfolio company initiative. The pattern recognition and shared resources that operating partners enable are significant advantages in the challenging AI landscape.

Yet despite the impressive vendor landscape, many enterprise AI projects stall or fail. Something is broken in how the AI vendor landscape operates.

How the landscape is broken

Capability claims exceed reality

AI vendors naturally emphasise their capabilities. Marketing materials highlight the most impressive use cases. Demos are designed to impress, showing what is possible under ideal conditions.

But enterprise environments are not ideal. Data is messier than demo data. Integration is harder. Users are less enthusiastic. The gap between demo capabilities and production reality is substantial.

Data requirements are understated

Vendors have strong incentives to minimise data requirements. Acknowledging that AI success requires substantial data preparation would slow sales cycles. Easier to claim that the platform can work with your existing data.

Buyers discover data requirements mid-project when implementation stalls.

Implementation complexity is hidden

AI implementation involves much more than deploying a platform. It requires data preparation, feature engineering, model training, integration, change management, and ongoing maintenance.

Vendor sales processes often focus on platform capabilities rather than implementation complexity.

Lock-in is engineered

AI platforms often create dependency that makes switching costly. Proprietary data formats, custom model architectures, and platform-specific integrations make it difficult to migrate.

How to navigate the landscape

Start with Use Case Requirements. Begin with a clear understanding of what you need AI to accomplish. Use requirements to evaluate vendors rather than letting vendor capabilities define your requirements.

Assess Data Requirements Explicitly. Ask vendors explicitly about data requirements for your specific use case. Push past general claims to specific criteria.

Request Relevant Reference Customers. Seek customers with similar data environments, technical capabilities, and use cases. Ask specific questions about their experiences.

Run Realistic Proofs of Concept. Before committing, run a proof of concept with your actual data. Not a demo with vendor-prepared data.

Understand Total Cost of Ownership. Platform licence fees are often the smallest component. Include data preparation, implementation, integration, change management, and ongoing maintenance.

Negotiate Risk Sharing. Consider success-based pricing, trial periods, performance guarantees, and exit clauses.

An independent read gives you a perspective vendors cannot offer. A Truth Score Read shows your real starting point before you sign, so you can set realistic expectations and choose vendors on evidence.

Governance is not as exciting as AI use cases or as tangible as data quality metrics. It does not appear in vendor demos or pilot projects. But governance determines whether AI success is sustainable or temporary. Without governance, even successful AI implementations degrade over time as the data they depend on degrades.

For PE firms operating on defined holding periods, this matters enormously. An AI capability that works at acquisition but fails by exit creates no value. Sustainable AI requires sustainable data quality, which requires governance.

Why governance matters for AI

AI systems are not static implementations that work forever once deployed. They are living systems that require ongoing maintenance as data patterns shift, business requirements evolve, and the underlying data changes.

Consider a customer churn prediction model deployed in a portfolio company. The model was trained on historical data and learned patterns that predicted churn at that time. Over the following months and years, several things change:

Customer behaviour evolves. New product features change how customers engage. Competitive dynamics shift customer expectations. Economic conditions affect purchasing patterns. The patterns that predicted churn in the training data may not predict churn in current data.

Data collection changes. New systems are implemented. Existing systems are upgraded. Integration points are modified. The data flowing into the model may have different characteristics than the training data.

Business definitions evolve. What counts as an active customer? When is a customer considered churned? How are customer segments defined? These definitions may change for legitimate business reasons, but each change affects model validity.

Data quality drifts. Without active maintenance, data quality degrades over time. New data entry errors accumulate. Integration issues cause gaps. Legacy data becomes stale. The quality that enabled initial AI success erodes.

Governance provides the organisational infrastructure to manage these changes. It ensures that someone is responsible for data quality, that changes are assessed for AI impact, and that quality is monitored and maintained over time.

Key governance capabilities for AI

Effective AI governance requires several specific capabilities:

Ownership clarity

Someone must be accountable for each critical data element. This is not just documentation of who created the data but assignment of ongoing responsibility for data quality, definition, and evolution.

Ownership clarity answers questions like: Who is responsible when this data has quality issues? Who must approve changes to how this data is collected? Who ensures this data meets requirements for downstream AI applications?

Without clear ownership, data problems are everyone’s and no one’s responsibility. Issues are discovered only when they cause visible failures. By then, significant damage may have occurred.

Quality monitoring

Automated checks must detect when data quality degrades. This means implementing monitoring that tracks completeness rates, validates accuracy against business rules, detects anomalies in distributions, and alerts when metrics fall outside acceptable ranges.

Quality monitoring for AI should focus on features that models depend on. If a model uses ten input features, those ten features need monitoring even if they represent a small fraction of total data assets.

Change management

When business processes change, systems are modified, or definitions evolve, the data implications must be assessed. This requires a change management process that identifies data-affecting changes, evaluates their impact on AI applications, and ensures appropriate adjustments.

Documentation

Data definitions, business rules, quality standards, and system integrations must be documented sufficiently to support AI development and maintenance. Without documentation, institutional knowledge walks out the door with employee turnover.

Assessing governance in portfolio companies

PE operating partners should assess governance as part of AI opportunity evaluation. Key questions include:

Is data ownership clear? For the data elements that would support AI applications, is there a clear owner? Can you identify who is responsible for quality?

Are quality processes in place? Is data quality actively monitored? Are there defined standards and thresholds? Is there a process for responding to quality issues?

Is documentation adequate? Are data definitions documented? Are business rules captured? Would a new team member be able to understand the data?

Is change management practiced? When systems or processes change, is data impact assessed? Are AI implications considered?

Weak answers indicate governance gaps that will undermine AI sustainability.

Building governance as part of AI readiness

When governance gaps exist, they should be addressed as part of AI readiness investment:

Establish Ownership for AI-Critical Data. Identify the data elements required for target AI applications. Assign clear owners with responsibility for quality, definition, and evolution.

Implement Monitoring with Alerting. Deploy automated monitoring for AI-critical data. Establish alerting thresholds and response procedures.

Document What Matters. Create documentation for AI-critical data elements focusing on definitions, valid values, quality standards, and integration points.

Integrate with Change Processes. Add AI impact assessment to existing change management processes.

The investment in governance is not overhead but foundation that enables lasting AI value creation.

Understanding these industry-specific patterns helps organisations set realistic expectations, prioritise appropriate use cases, and benchmark their readiness against relevant peers. A manufacturing company should not compare itself to a tech company. A healthcare provider faces different challenges than a retailer.

This analysis examines AI readiness patterns across major industry sectors, identifying common strengths, hidden challenges, and priority focus areas for organisations in each sector.

B2B software: higher baseline, hidden challenges

Business-to-business software companies generally have the highest AI readiness among traditional industries. Their digital-native operations generate comprehensive data, and their technical teams understand data and AI requirements.

Strengths

Product usage data is comprehensive. SaaS platforms capture detailed telemetry about how customers use the product. Feature adoption, usage frequency, workflow patterns, and performance metrics are automatically collected. This data provides rich signals for AI applications like churn prediction, upsell targeting, and product optimisation.

Engineering capabilities enable rapid experimentation. Software companies have technical teams who understand data pipelines, APIs, and machine learning infrastructure. They can build and deploy AI applications faster than organisations without this technical foundation.

Data-driven culture supports AI adoption. Software companies are accustomed to measuring everything and making decisions based on data. The cultural barriers to AI adoption are lower than in industries where intuition and experience traditionally dominated decision-making.

Hidden challenges

Customer data often fragmented across go-to-market systems. While product data is comprehensive, customer data may be scattered across CRM, marketing automation, support systems, and billing platforms. Integrating these systems for a complete customer view is often harder than expected.

Self-service and product-led growth models create data gaps. Customers who sign up and use the product without sales interaction may have sparse CRM records. The customers most likely to churn without warning, those who never engaged with success teams, are often the customers with the least data.

Rapid product changes invalidate historical patterns. Software products evolve quickly. Features are added, redesigned, or deprecated. Usage patterns that predicted churn in the old product version might not apply to the new version. AI models trained on historical data may not transfer to current conditions.

Priority focus areas

B2B software companies should focus on customer data integration across systems, establishing consistent customer identity across product, sales, and support data. They should also address the challenge of modelling through product changes, developing approaches that adapt to evolving product contexts.

Manufacturing: legacy systems, untapped opportunity

Manufacturing companies often have rich operational data from production systems but struggle with the IT infrastructure and data integration required for AI applications.

Strengths

Rich operational data from production systems. Modern manufacturing equipment generates extensive sensor data, quality measurements, and production metrics. This data can support AI applications in predictive maintenance, quality optimisation, and demand forecasting.

Clear ROI cases for AI. Manufacturing inefficiencies have direct cost implications. Reducing unplanned downtime, improving yield, and optimising inventory have quantifiable value that makes AI business cases straightforward.

Process discipline supports data governance. Manufacturing operations require process discipline for quality and safety. This discipline can extend to data governance when organisations make the connection.

Hidden challenges

Legacy OT/IT divide creates data accessibility issues. Operational technology systems on the factory floor often run on proprietary protocols with limited integration to enterprise IT systems. Getting data from machines into AI-ready formats requires bridging this divide.

Historical data may exist only in paper or disconnected systems. Older manufacturing data might be in paper logs, local databases, or obsolete systems. Digitising and integrating this historical data for AI training is often a major undertaking.

Data from acquired facilities may be incompatible. Manufacturing companies that have grown through acquisition often have different systems and standards at different facilities. Standardising data across sites is a prerequisite for enterprise-wide AI.

Priority focus areas

Manufacturing companies should prioritise OT/IT integration to make operational data accessible for AI applications. They should also focus on data standardisation across facilities to enable enterprise-wide AI rather than site-by-site solutions.

Healthcare services: regulatory strength, integration weakness

Healthcare organisations have strong data governance driven by regulatory requirements but struggle with data fragmentation across clinical and administrative systems.

Strengths

Strong data governance driven by regulatory requirements. HIPAA and other healthcare regulations require careful attention to data handling. Healthcare organisations have established governance frameworks that can be extended to AI requirements.

Rich clinical data with potential for AI impact. Electronic health records contain detailed patient information that can support AI applications in diagnosis support, treatment optimisation, and population health management.

Clear value from AI applications. AI that improves clinical outcomes, reduces readmissions, or enhances operational efficiency has obvious value in healthcare. The case for AI investment is often compelling.

Hidden challenges

Data fragmented across EMR, billing, scheduling, and departmental systems. Healthcare data is notoriously siloed. A single patient might have records in the EMR, the billing system, the radiology PACS, the lab information system, and multiple departmental applications. Integrating this data for a complete patient view is extremely difficult.

Interoperability standards are improving but not solved. FHIR and other standards are making healthcare data exchange easier, but full interoperability remains aspirational. Data from different systems may have different formats, codes, and meanings.

Privacy constraints limit data use. Even with strong governance, privacy requirements may limit how data can be used for AI. Training models may require de-identification that reduces data utility. Some valuable data linkages may be prohibited.

Priority focus areas

Healthcare organisations should focus on clinical data integration, building comprehensive patient views from fragmented systems. They should also address the privacy/utility balance, developing approaches to use data for AI while meeting regulatory requirements.

Retail and e-commerce: volume advantage, identity challenge

Retail organisations have high transaction volumes providing ample data for AI but struggle with customer identity across channels.

Strengths

High transaction volumes provide ample training data. Retail transactions number in the millions or billions, providing extensive data for AI applications like demand forecasting, recommendation engines, and pricing optimisation.

Digital commerce generates rich behavioural data. E-commerce platforms capture detailed clickstream data, search behaviour, cart activity, and purchase patterns. This behavioural data provides strong signals for personalisation and prediction.

AI directly impacts core business metrics. Better recommendations increase conversion. Better forecasting reduces stockouts and overstock. Better pricing improves margins. The path from AI to business value is direct.

Hidden challenges

Omnichannel creates identity resolution challenges. A customer who browses on mobile, researches on desktop, and purchases in store appears as three different people in channel-specific systems. Unifying these identities to build a complete customer view is technically challenging and often incomplete.

Anonymous and guest transactions limit personalisation data. Many retail transactions, especially in stores, are anonymous. Without customer identity, these transactions cannot contribute to individual-level AI applications like personalisation.

Seasonal and promotional patterns complicate modelling. Retail demand is heavily influenced by seasons, promotions, and events. Models must account for these patterns, which requires data spanning multiple seasonal cycles and comprehensive promotional calendars.

Priority focus areas

Retail organisations should prioritise customer identity resolution across channels and touchpoints. They should also focus on comprehensive promotional and pricing data to enable accurate demand modelling.

Financial services: data rich, regulation complex

Financial services organisations have extensive data and sophisticated analytics capabilities but face complex regulatory requirements for AI applications.

Strengths

Extensive transaction and customer data. Banks and financial services companies have detailed records of every transaction, balance, and customer interaction. This data can support AI applications in fraud detection, credit risk, and customer analytics.

Sophisticated analytics heritage. Financial services have long used statistical models for credit scoring, risk assessment, and fraud detection. The transition to machine learning builds on existing analytical capabilities.

AI directly impacts risk and revenue. Better fraud detection reduces losses. Better credit models improve risk-adjusted returns. Better customer analytics increases cross-sell success. AI impact is directly measurable.

Hidden challenges

Regulatory requirements for model explainability. Regulations like the Equal Credit Opportunity Act require that credit decisions be explainable. Black-box AI models may not meet regulatory requirements, limiting the techniques that can be applied.

Legacy core systems complicate data access. Many financial institutions run on core systems that are decades old. Extracting data from these systems for AI applications requires careful integration work.

Data from acquisitions may have different standards. Financial services consolidation has created institutions with multiple legacy systems from acquired companies. Data standardisation across these systems is an ongoing challenge.

Priority focus areas

Financial services organisations should focus on regulatory-compliant AI approaches that meet explainability requirements. They should also prioritise core system data integration to make legacy data accessible for modern AI applications.

Benchmarking your organisation

Understanding industry patterns helps organisations benchmark their readiness against relevant peers. A manufacturing company in the bottom quartile of manufacturing AI readiness faces different challenges than a manufacturing company in the top quartile.

Benchmarking should consider both absolute readiness, measured against AI requirements, and relative readiness, measured against industry peers. Being above average in a low-readiness industry still means significant work to achieve AI success. Being below average in a high-readiness industry suggests the organisation is falling behind competitors.

Industry patterns also inform prioritisation. In industries where integration is the primary challenge, integration investments have the highest leverage. In industries where data volume is adequate but quality is poor, quality remediation is the priority.

The goal is not to excuse poor readiness based on industry challenges but to understand the specific obstacles to address. Every industry has organisations that have achieved AI success by addressing their sector-specific challenges. Understanding those challenges is the first step to joining them.

But when AI projects fail despite green quality indicators, a fundamental question emerges: are we measuring what actually matters? Illustrative example, not a client: a company with 94% completeness, 91% accuracy and 97% freshness still cannot build a working churn prediction model. The dashboard is green, but the AI initiative is red.

Building a data quality scorecard that actually predicts AI success requires rethinking what we measure and how we measure it. Traditional metrics optimised for operational systems and business intelligence do not capture what machine learning requires.

What traditional metrics miss

Traditional data quality metrics have evolved over decades to support database management, regulatory compliance, and business intelligence. They measure important things, but not necessarily the things that determine AI success.

Traditional metrics measure averages

A completeness score of 90% tells you that nine out of ten values exist. It does not tell you which values are missing or whether the missing 10% is random or systematic.

For AI, the distribution of missing data matters enormously. If missing values are randomly distributed across records, many machine learning techniques can handle them. If missing values are concentrated in records with specific characteristics, particularly characteristics related to what you are trying to predict, your model will be systematically biased.

A customer churn model trained on data where churned customers have more missing values will underpredict churn because the patterns that precede churn are underrepresented in complete records.

Traditional metrics measure individual fields

Dashboards typically show completeness, accuracy, and validity for individual fields. Take a hypothetical dashboard: Field A is 95% complete. Field B is 92% complete. Field C is 88% complete. All green.

But AI models consume records, not fields. If different records are missing different fields, the percentage of records with all required fields is much lower than individual field metrics suggest. With 95, 92, and 88% completeness on three independent fields, only about 77% of records have all three fields populated.

Feature engineering compounds this problem. A derived feature that requires multiple source fields inherits the incompleteness of all its inputs. A feature combining five fields with 90% completeness each might only be calculable for 59% of records.

Traditional metrics measure against static rules

Traditional quality rules encode domain knowledge: dates should be in the past, prices should be positive, email addresses should contain @ symbols. These rules catch obvious errors but do not assess whether data is adequate for specific AI applications.

A customer churn model might require 24 months of behavioural history, balanced representation of churned and retained customers, and specific engagement features. Traditional metrics do not measure any of these requirements. Data can pass all standard quality checks while completely failing AI readiness criteria.

Traditional metrics ignore label quality

Supervised machine learning requires labelled training examples. The model learns to predict the label based on input features. Label quality directly determines what the model learns.

Traditional data quality frameworks rarely assess labels because operational systems do not have labels in the machine learning sense. The concept of a target variable that needs quality assessment is foreign to traditional data quality.

Yet label quality is arguably the most important factor in supervised learning. A model trained on incorrect labels learns incorrect patterns, regardless of how good the input features are.

Traditional metrics do not assess sufficiency

Traditional metrics measure quality of existing data. They do not assess whether enough data exists for the intended purpose.

A database might have perfect quality scores but contain only 500 records. For simple analyses, 500 records might be adequate. For complex machine learning, 500 records is almost certainly insufficient. Traditional scorecards would show green while AI readiness is clearly red.

Designing AI-relevant metrics

Effective AI readiness scorecards supplement traditional metrics with measures specific to machine learning requirements:

Training data sufficiency

How many usable training examples exist for each outcome category? This is not just total record count but records with complete features and reliable labels.

For classification problems, break down counts by class. A churn model needs sufficient examples of both churned and retained customers. If churned customers represent only 5% of records, the 500 churned examples in a 10,000 record dataset may be insufficient for reliable learning.

For regression problems, assess coverage across the range of target values. A revenue prediction model needs examples across the full range of revenue values, not just concentration around the mean.

Sufficiency thresholds depend on model complexity and data characteristics. Simple models might work with thousands of examples. Complex deep learning might require millions. Domain expertise and experimentation inform appropriate thresholds.

Feature completeness by use case

Instead of measuring field-level completeness, measure the percentage of records with all features required for specific AI use cases. This directly indicates how many training examples are usable.

Define feature sets for each planned AI application. A churn model might require demographic features, behavioural features, engagement features, and support interaction features. Measure what percentage of customer records have complete data across all required feature categories.

This metric reveals problems that field-level metrics hide. A use case requiring ten features, each 90% complete, might have only 35% of records fully usable if completeness is not correlated across fields.

Class balance and coverage

For classification problems, measure the balance between outcome classes. Severe imbalance, such as 99% negative and 1% positive examples, creates learning challenges that require specific techniques to address.

Also assess coverage across important segments. Does training data include examples from all customer segments, geographic regions, time periods, and use case variations that the model will encounter in production?

Coverage gaps indicate where the model will struggle. A model trained primarily on enterprise customers will perform poorly on SMB customers even if overall metrics look adequate.

Label reliability

Assess the quality of outcome labels used for supervised learning. Have definitions been consistent over time? Were labelling criteria clear and consistently applied? What is the expected error rate in labels?

For labels derived from system data, trace the derivation logic. Labels that aggregate multiple fields, apply business rules, or involve calculations may inherit quality issues from underlying data.

For labels involving human judgment, assess inter-rater reliability. If different people would label the same example differently, the label is unreliable.

Entity resolution quality

For AI applications requiring data from multiple systems, measure the quality of entity resolution. What percentage of entities can be matched across systems? What is the confidence distribution of matches?

Low-confidence matches introduce noise into training data. Unmatched entities create incomplete feature sets. Entity resolution quality directly impacts the usability of cross-system features.

Track both match rate and match confidence. A 90% match rate with high confidence is better than 95% with many uncertain matches.

Temporal consistency

For AI applications that learn from historical patterns, measure consistency of data over time. Have definitions changed? Have collection practices varied? Are there gaps from system migrations?

Temporal inconsistency means that patterns learned from one time period may not apply to another. A model might learn patterns that are actually artefacts of definitional changes rather than real business dynamics.

Track key metrics over time and flag significant changes. A sudden shift in average values or completeness rates indicates potential consistency issues requiring investigation.

Feature stability

For production AI systems, measure the stability of input features. Are feature distributions in production consistent with training data? Drift between training and production distributions degrades model performance.

Implement monitoring that compares incoming feature distributions against training baselines. Alert when distributions shift beyond acceptable thresholds.

Operational integration

An AI-ready scorecard is only valuable if it drives action. Operational integration ensures that metrics inform decisions:

Link metrics to AI use cases

Each metric should connect to specific AI applications. Do not measure abstractly. Measure completeness for the churn model feature set. Measure sufficiency for the demand forecast training data. Measure label quality for the fraud detection classification.

This linkage makes metrics actionable. When a metric is red, it is clear which AI initiative is affected and what remediation would help.

Define thresholds based on AI requirements

Green-yellow-red thresholds should reflect AI requirements, not arbitrary standards. A feature with 80% completeness might be green for one use case and red for another depending on how critical that feature is to each model.

Work with data scientists to establish thresholds that reflect model requirements. Validate thresholds through experimentation showing how model performance degrades as metrics decline.

Update metrics continuously

AI readiness is not a point-in-time assessment but an ongoing capability. Metrics should update continuously as new data arrives and conditions change.

Implement automated pipelines that refresh metrics on a regular cadence. Daily updates for operational metrics. Weekly updates for aggregate scorecards. Real-time alerts for critical issues.

Integrate with AI development workflow

AI readiness metrics should be part of the AI development process, not a separate reporting exercise. Before model development begins, verify that readiness metrics meet thresholds. Before model deployment, confirm that production data meets expectations.

Build scorecard checks into CI/CD pipelines for AI systems. Fail deployments when data quality does not meet requirements. This prevents deployment of models that will fail due to data issues.

The path forward

Traditional data quality metrics served organisations well for operational systems and business intelligence. But AI has different requirements that traditional metrics do not capture.

Building an AI-ready scorecard requires supplementing traditional metrics with measures of training sufficiency, feature completeness, class balance, label quality, entity resolution, temporal consistency, and feature stability. These metrics directly indicate whether data can support machine learning.

The goal is not to abandon traditional metrics but to complement them with AI-specific measures. An organisation might maintain both an operational data quality scorecard for traditional purposes and an AI readiness scorecard for machine learning initiatives.

When both scorecards are green, AI initiatives can proceed with confidence. When traditional metrics are green but AI metrics are red, organisations understand that additional work is needed before AI development can succeed. This clarity prevents expensive failures and focuses remediation efforts where they matter most.

AI initiatives bring the cost of bad data into sharper focus because machine learning has zero tolerance for the data quality issues that traditional business processes have learned to work around. A sales team can succeed despite CRM data quality issues because human judgment fills the gaps. An AI model cannot apply judgment. It learns whatever patterns exist in the data, including patterns that reflect data quality problems rather than business reality.

Understanding the true cost of bad data in AI contexts is essential for building business cases for data quality investment and for setting realistic expectations about AI initiative requirements.

Direct costs of AI project failure

When AI projects fail due to data quality issues, organisations incur substantial direct costs that are often underestimated at project inception:

Technology investment

A mid-market AI implementation typically involves significant technology spending. Cloud infrastructure for data storage, processing, and model training scales with data volumes and computational requirements. AI platform licences from vendors like DataRobot, H2O, or cloud-native services add a recurring annual cost. Data integration and pipeline tools contribute additional costs. Development and testing environments require their own infrastructure.

For a failed AI project that runs for a year or more, the technology bill alone is substantial, with nothing to show for the investment. These costs are often spread across multiple budget lines, making the true total difficult to see until post-mortem analysis.

Personnel costs

Experienced data scientists command premium salaries. A typical AI project team might include two to four data scientists, one to two data engineers, a project manager, and significant time from business stakeholders who participate in requirements gathering, validation, and user acceptance.

Over a long project, the people cost adds up quickly. It includes not just salaries but benefits, overhead, and the opportunity cost of these skilled people not working on other initiatives.

Personnel costs are often the largest component of AI project investment, yet they are frequently underestimated because organisations focus on technology costs when planning budgets.

Consulting and vendor fees

Many organisations engage external expertise for AI initiatives. Implementation partners, strategy consultants, and specialised data quality vendors add to project costs. These engagements range from targeted assistance to comprehensive implementation support, and the larger ones can rival the internal team in cost.

When projects fail, these fees are sunk costs. The knowledge transfer that was supposed to build internal capability often fails to materialise when projects are abandoned before completion.

Opportunity cost

Perhaps the largest cost of AI failure is opportunity cost. The time spent on a failed project is time that competitors had to advance their own AI capabilities. The budget consumed by failure is budget not available for other strategic initiatives. The organisational attention devoted to the failed project is attention not devoted to other opportunities.

For a company that spends eighteen months on a failed AI initiative, the question is not just what they spent but what they could have achieved with those resources applied elsewhere. In fast-moving markets, eighteen months of strategic delay can be extremely costly.

Total direct cost

Add these together and a failed AI project is a large bill: technology, people, outside fees and lost time, all spent with nothing in production. The more ambitious the initiative, the larger the bill.

Indirect costs often exceed direct costs

Beyond direct project costs, AI failures create indirect costs that often exceed the direct investment:

Organisational credibility damage

When high-profile AI initiatives fail, the teams and leaders who championed them suffer credibility damage. This damage extends beyond the individuals to affect organisational appetite for future AI investment.

Executives who approved AI budgets that delivered nothing become sceptical of future proposals. Technical teams that failed to deliver become hesitant to take on ambitious projects. Business users who were promised AI-driven improvements become cynical about technology initiatives generally.

This credibility damage can persist for years, making legitimate AI opportunities harder to fund and staff even when conditions improve.

AI fatigue

Failed AI initiatives create organisational fatigue that affects future attempts. Employees who invested time in workshops, requirements sessions, and change management for a failed project are reluctant to engage again. The failure narrative, whether AI does not work here or the data is not ready, becomes embedded in organisational culture.

Overcoming AI fatigue requires demonstrating success, but the fatigue itself makes success harder to achieve. This creates a negative cycle that can persist through multiple planning cycles.

Competitive disadvantage

While one organisation struggles with failed AI initiatives, competitors may be succeeding. The organisations that figure out AI, often by investing in data foundations before AI development, build capabilities that translate to competitive advantage.

In industries being transformed by AI, the gap between leaders and laggards widens over time. A two-year delay in achieving AI capability might translate to significant market share loss in fast-moving sectors.

Data debt accumulation

Failed AI initiatives often leave data problems unaddressed. The assessment may have revealed issues, but if the project failed before remediation was complete, those issues persist. Meanwhile, new data continues to accumulate with the same quality problems.

Data debt, like technical debt, compounds over time. The longer it goes unaddressed, the more expensive remediation becomes. Organisations that defer data quality investment after AI failures find the problem worse when they return to it.

The cost of delayed success

Even when AI initiatives eventually succeed, data quality issues create costs through delay. An initiative that could have delivered value in twelve months but requires twenty-four months due to data remediation has a twelve-month opportunity cost.

Consider a demand forecasting initiative expected to cut inventory costs every year. Every month that data quality issues delay deployment is a month of savings the organisation never gets back, and the loss grows with each month the delay runs on.

These delay costs are often invisible because organisations focus on eventual success rather than the value lost during extended timelines. But for time-sensitive opportunities, delay costs can exceed project costs.

Quantifying data quality impact

Building a business case for data quality investment requires quantifying the impact of quality issues on AI outcomes. Several approaches can help:

Expected loss analysis

Start with the expected value of the AI initiative if it succeeds. Then estimate the probability of failure given current data quality. The expected loss is the initiative value multiplied by the failure probability.

Illustrative example, not a client: an AI initiative expected to deliver 5 million dollars in annual value with a 70% probability of failure given current data quality has an expected loss of 3.5 million dollars. Investment in data quality that reduces failure probability to 30% reduces expected loss to 1.5 million dollars, a 2 million dollar improvement that justifies substantial data quality investment.

Delay cost modelling

Estimate the time required to achieve AI success with and without data quality investment. Calculate the value foregone during the extended timeline.

If upfront data investment adds three months to timeline but avoids twelve months of downstream delays, the net effect is nine months of accelerated value delivery. For a high-value initiative, this acceleration easily justifies the upfront investment.

Risk-adjusted ROI

Traditional AI business cases often ignore execution risk. Risk-adjusted analysis incorporates the probability of different outcomes, including failure, partial success, and delayed success.

An AI initiative with a spectacular projected ROI on success looks attractive. But if the odds of success are low, the risk-adjusted ROI is much lower. Data quality investment that increases success probability significantly improves risk-adjusted returns.

Building the business case

Securing investment for data quality requires framing the business case effectively:

Frame around AI success, not data purity

Data quality investment is easier to fund when positioned as enabling AI success rather than pursuing abstract data purity. Executives who are sceptical of data governance are often enthusiastic about AI-driven competitive advantage.

Position data quality as a prerequisite for AI initiatives the organisation wants to pursue. The investment is not in data quality for its own sake but in the foundation required for strategic AI capability.

Quantify using specific AI use cases

Abstract data quality arguments are less compelling than specific AI use case economics. Identify the highest-value AI opportunities and calculate the data quality investment required to pursue them.

A presentation showing that a modest, scoped data quality investment unlocks a specific, high-value AI initiative is more compelling than an argument for data quality best practices.

Propose phased investment

Large upfront data quality investments are hard to fund. Phased approaches that show incremental progress and value are easier to approve.

Propose an initial assessment phase to quantify gaps and requirements. Follow with targeted remediation for the highest-priority AI use cases. Demonstrate success before requesting investment for broader data quality improvement.

Include ongoing maintenance

Data quality is not a one-time fix. Business cases should include ongoing maintenance costs to sustain quality over time. Organisations that fund initial remediation but not ongoing maintenance find quality degrading back to original levels.

The path forward

The cost of bad data in AI initiatives is substantial and often underestimated. Direct project costs, indirect organisational impacts, and opportunity costs can total many times the original project budget.

But these costs are not inevitable. Organisations that invest in data quality before AI development achieve higher success rates, faster time to value, and better returns on AI investment. The investment in data quality is not an additional cost but a reallocation that improves overall economics.

The question is not whether to invest in data quality but whether to invest before AI initiatives fail or after. The economics strongly favour checking before you invest. Learning it after a failed project is the expensive way.

Then the AI initiative began, and the truth turned out to be messier than anyone expected.

When the data science team began preparing customer data for a churn prediction model, they discovered problems that traditional CRM reporting had tolerated but AI could not. Inconsistent data entry, incomplete records, stale information, and duplicates that had accumulated over years suddenly became critical obstacles.

It is a common pattern for organisations applying AI to CRM data. The same data that works adequately for reporting and basic analytics fails to support machine learning. Understanding why this happens and what to do about it is essential for organisations planning AI initiatives involving customer data.

The CRM data quality reality

CRMs are input-intensive systems. Unlike systems that capture data automatically, such as web analytics or transaction processing, CRMs depend on humans entering information. Every contact, account, opportunity, activity, and note requires someone to type something into a field.

This human dependency creates systematic quality issues that accumulate over time:

Inconsistent data entry standards

Different sales reps enter data differently. One rep meticulously logs every customer interaction. Another enters only required fields. One uses formal company names while another uses abbreviations. One records phone conversations while another only logs emails.

Even with data entry guidelines, enforcement is inconsistent. Sales managers focused on hitting quota rarely prioritise data quality. Reps under pressure to close deals view CRM updates as administrative overhead rather than valuable documentation.

Over time, these inconsistencies compound. A sales team of dozens of reps, each entering data differently for years, has accumulated enormous variability that looks like noise to a machine learning algorithm.

Incomplete records across critical fields

Required fields get populated because the system enforces them. Optional fields are populated sporadically based on individual judgment. Fields that were added after initial implementation may be blank for older records.

The pattern of incompleteness often correlates with what you most want to predict. Records of customers who churned may be more incomplete than records of customers who stayed. Reps may have stopped updating records for accounts that seemed to be slipping away. The very signals that would predict churn are missing from the records of churned customers.

Stale data from relationship decay

Customer information changes over time. People change jobs, companies change addresses, organisational structures evolve. Contact information that was accurate when entered becomes stale.

CRMs rarely have mechanisms to prompt updates. A contact record might show someone in a role they left two years ago. An account might reflect an organisational structure that was reorganised after an acquisition. This stale data is not just incomplete; it is actively wrong.

The staleness problem is particularly acute for accounts with low engagement. Accounts that are regularly active get updated through normal business interaction. Accounts that have gone quiet are never updated, so their records become increasingly detached from reality.

Duplicate records accumulated over years

Duplicate detection and merging is an ongoing challenge in any CRM. A new rep might create an account that already exists under a slightly different name. A contact might be entered multiple times with different email addresses. Acquired companies might bring their own CRM data with overlapping records.

Duplicates create multiple problems for AI. They inflate counts, making certain customers appear more active than they are. They fragment history, splitting a customer journey across multiple records. They introduce inconsistency when duplicates have different values for the same field.

Inconsistent activity and engagement tracking

Understanding customer engagement requires comprehensive activity tracking. Calls, emails, meetings, support interactions, product usage, marketing responses, all of these touchpoints contribute to understanding customer health and predicting behaviour.

But activity capture is notoriously inconsistent. Email integration might capture some messages but not others. Call logging depends on rep discipline. Meeting notes vary from detailed summaries to single words. Integration with support systems might be incomplete or delayed.

The result is an engagement picture full of gaps. A customer might appear disengaged simply because their interactions were not captured, not because they actually stopped engaging.

Why AI struggles with typical CRM data

Traditional CRM reporting can tolerate substantial data quality issues. Human analysts apply judgment, recognise anomalies, and interpret data in context. A sales manager reviewing pipeline knows which deals are real and which are wishful thinking, regardless of what the CRM says.

AI cannot do this. Machine learning algorithms learn patterns from whatever data they are given. They cannot distinguish meaningful patterns from artefacts of data quality issues. They cannot apply business judgment to interpret ambiguous data. They treat noise as signal.

Inconsistent encoding breaks categorical features

If industry is encoded as Technology for some accounts, Tech for others, and IT for still others, the model sees three different industries. If company size is recorded as SMB, Small-Medium Business, and Mid-Market for similar companies, the model cannot learn patterns based on company size.

Feature engineering can partially address encoding inconsistency, but only if the variations are known and mappable. Unknown variations become noise that obscures real patterns.

Missing values create training gaps

Machine learning models need complete feature vectors. A record missing three of ten features might be excluded from training entirely. If missing values are systematic rather than random, excluding incomplete records creates biased training data.

Imputation, filling in missing values with estimates, can help but introduces its own risks. Imputed values are guesses that may not reflect reality. Training on imputed data means training on a mix of real and estimated values.

Duplicates distort frequency statistics

Many AI models depend on frequency counts. How often did this customer contact support? How many opportunities has this account had? How much total contract value has accumulated?

Duplicates corrupt these counts. A customer with two duplicate records appears to have half the activity on each record. Deduplication before AI training is essential but often incomplete.

Stale data teaches wrong patterns

If contact information is stale, engagement features based on that information are wrong. The model might learn that customers with certain email domains churn, when actually those domains are defunct and the customers have moved to new addresses.

Stale data is particularly dangerous because it is not obviously wrong. The values are valid; they are just no longer true. Quality checks that look for format violations will not catch staleness.

Activity gaps create false negatives

If customer engagement is incompletely captured, customers appear less engaged than they actually are. A customer who had multiple productive interactions that were not logged looks like a disengaged customer at risk of churn.

The model learns that low visible engagement predicts churn, which may be true. But it also learns to ignore actual engagement signals that are not consistently captured, reducing model accuracy.

The remediation roadmap

Addressing CRM data quality for AI requires a systematic approach. The goal is not perfection but sufficiency for the intended AI application.

Standardise going forward

Before cleaning historical data, establish standards for new data entry. Define required fields, acceptable values, and entry procedures. Implement validation rules that enforce standards at entry time. Train users on standards and provide ongoing reinforcement.

Standardisation prevents new problems from accumulating while you address existing ones. Without standardisation, historical cleanup is a Sisyphean task.

Cleanse critical historical data

Not all historical data needs remediation, only data that will be used for AI training and prediction. Identify the specific fields and records required for your AI use case and focus remediation efforts there.

Prioritise by impact. Fields that are highly predictive deserve more remediation investment than fields with marginal importance. Records from critical customer segments matter more than records from segments outside the AI scope.

Implement entity resolution

Entity resolution is the process of identifying which records refer to the same real-world entity and consolidating them into a unified view. This addresses the duplicate problem and enables cross-system integration.

Effective entity resolution requires matching logic that handles name variations, address changes, and missing identifiers. It requires confidence scoring so uncertain matches can be reviewed. It requires ongoing maintenance as new records are created.

Enrich with external data

External data sources can fill gaps and validate accuracy. Company databases can verify firmographic data like industry, size, and location. Contact databases can validate and update contact information. Third-party intent data can supplement engagement signals.

Enrichment is not a substitute for fixing internal data quality but can accelerate remediation and improve completeness for fields that are difficult to capture internally.

Build quality monitoring

Data quality is not a one-time fix but an ongoing discipline. Implement monitoring that detects quality degradation before it undermines AI systems.

Monitoring should track completeness rates, matching rates, staleness indicators, and validation failure rates. Alerts should trigger when metrics fall below thresholds. Regular reviews should identify emerging quality issues.

Plan for ongoing maintenance

CRM data quality requires continuous attention. New users need training. Standards need enforcement. Duplicates need resolution. Stale records need updating. Without ongoing maintenance, quality will degrade.

Build data quality maintenance into normal operations rather than treating it as a one-time project. Assign ownership, allocate resources, and establish accountability for sustained quality.

The path forward

CRM data quality issues are not reasons to abandon AI ambitions. They are obstacles that can be addressed with appropriate investment and discipline. CRM data can support AI once the quality issues that matter for the use case are fixed.

The key is realistic assessment before AI development begins. Understand the current state of your CRM data. Understand the specific requirements of your intended AI application. Understand the gap between current state and requirements. Plan and fund remediation as part of the AI initiative.

Organisations that skip this assessment and proceed directly to AI development tend to fail. The data issues that traditional reporting tolerated become insurmountable obstacles for machine learning. The AI initiative fails, and the organisation concludes that AI does not work for their business.

But AI does work when built on an adequate data foundation. The question is whether you build that foundation before the AI initiative or learn the hard way that it was needed.

Yet the customer churn prediction model built on it fails badly in production. False positives run far above expectations. The model misses customers who actually churn. Business users lose confidence and stop using the predictions. After a long build and significant investment, the AI initiative is quietly wound down.

The disconnect between green data quality metrics and failed AI highlights a critical distinction that is easy to miss: data quality and AI readiness are related but not identical concepts. Understanding this distinction is essential for organisations planning AI investments.

Traditional data quality: necessary but insufficient

Traditional data quality frameworks evolved to support operational systems and business intelligence. Their origins trace back to the challenges of maintaining database integrity: ensuring records are properly formatted, duplicates are merged, required fields are populated, and referential integrity is maintained.

These frameworks measure whether data meets standards for database management. Common dimensions include completeness (are fields populated?), accuracy (do values match authoritative sources?), consistency (is data uniform across systems?), timeliness (is data sufficiently current?), and validity (do values conform to expected formats?).

These measurements matter. Data that fails traditional quality standards will certainly fail AI requirements. You cannot build reliable predictions on data that is incomplete, inconsistent, or inaccurate.

But traditional metrics often miss what AI specifically requires. A database can score perfectly on traditional quality dimensions while being completely unsuitable for machine learning. The green dashboard in the example above has exactly this problem.

Where traditional metrics fall short

Traditional data quality metrics fail to capture several requirements specific to AI applications:

Traditional metrics measure averages, not distributions

The example’s 94% completeness rate sounds impressive. But which 6% is missing? If the missing data is randomly distributed, the impact on AI might be manageable. If the missing data is systematically related to the outcome you are trying to predict, your model will be fundamentally biased.

In the example, the churn model fails partly because customers who churned were more likely to have incomplete records. They had stopped engaging with the product, stopped responding to surveys, and stopped updating their information. The 94% completeness rate masks the fact that completeness was much lower for the exact customers the model most needed to understand.

Traditional metrics measure individual fields, not feature combinations

AI models do not use fields in isolation. They learn from combinations of features, identifying complex patterns that span multiple attributes. A customer with declining usage AND increasing support tickets AND late payments is different from a customer with just one of these signals.

Traditional quality metrics assess each field independently. They might show high completeness for usage data and for support data. But if different records are missing each field, the percentage of records with both fields is much lower. And the percentage with all features required for the model lower still.

Traditional metrics measure against static rules, not use-case requirements

Traditional quality rules are generic: is the email format valid, is the date in the past, is the revenue non-negative. These rules do not know whether the data is adequate for a specific AI application.

A customer churn model might require two years of behavioural history to learn patterns of gradual disengagement. A demand forecasting model might require data spanning multiple seasonal cycles. A fraud detection model might require examples of specific fraud types. Traditional metrics do not assess whether these use-case-specific requirements are met.

Traditional metrics ignore label quality

Supervised learning, which covers most enterprise AI applications, requires labelled training examples. The model learns to associate features with outcomes by examining historical cases where the outcome is known.

The quality of these labels directly determines model quality. If labels are inconsistent, subjective, or wrong, the model learns noise instead of signal. Traditional data quality frameworks rarely assess label quality because operational systems typically do not have labels in the machine learning sense.

The example churn model also fails because the definition of churn had changed multiple times over the training period. Labels that were correct under one definition were incorrect under another. The model was learning from fundamentally inconsistent targets.

Traditional metrics do not assess representativeness

AI models learn from the examples they are given and struggle with situations unlike their training data. If training data overrepresents certain customer segments, the model will perform well on those segments and poorly on others.

Traditional metrics do not assess whether data represents the full range of situations the model will encounter. They measure quality of existing data, not whether the right data exists.

What AI readiness actually requires

AI readiness asks a different question than traditional data quality. Instead of asking whether data meets generic quality standards, AI readiness asks: can this specific data support this specific AI use case?

This reframing has important implications:

Sufficient training signal

Machine learning requires enough examples to learn reliable patterns. The required volume depends on the complexity of the pattern being learned and the noise in the data.

For a simple classification with clear patterns, a few thousand examples might suffice. For a complex prediction with subtle signals, millions might be required. For rare events like fraud, you need enough examples of the rare class to learn its characteristics.

AI readiness assessment must determine whether sufficient training signal exists for the specific use case. This requires understanding both the data and the machine learning requirements.

Representative coverage

Training data must represent the full range of situations the model will encounter in production. This includes different customer segments, different time periods, different geographies, and different edge cases.

Representativeness is particularly challenging when the target population differs from the historical population. If you are launching in a new market, historical data from existing markets may not transfer. If customer behaviour has fundamentally changed, older data may teach outdated patterns.

Temporal integrity

AI models often need to understand change over time. A customer churn model learns that certain patterns of behavioural change precede churn. A demand forecasting model learns seasonal patterns.

Temporal integrity means that historical data accurately reflects what was true at each point in time. If definitions changed, if collection practices varied, if system migrations introduced discontinuities, temporal integrity is compromised.

This is different from traditional timeliness, which measures how current data is. Temporal integrity measures whether historical data is reliable for learning time-based patterns.

Label quality

For supervised learning, label quality is arguably the most important factor. A model cannot learn correct patterns from incorrect labels, no matter how good the input features are.

Label quality requires consistent definitions over time, reliable processes for applying labels, and accurate recording of outcomes. When labels come from human judgment, inter-rater reliability becomes important.

Label problems tend to surface only after an AI project has failed, which is the most expensive time to find them. Historical records that seemed adequate for reporting prove inadequate for learning.

Feature engineering feasibility

Raw data rarely goes directly into AI models. It must be transformed into features that capture relevant patterns. This feature engineering process requires data that can be manipulated reliably.

If data from multiple systems cannot be joined reliably, cross-system features are impossible. If timestamps are unreliable, time-based features are unreliable. If categorical values are inconsistent, categorical features are noisy.

AI readiness must assess not just data quality but the feasibility of transforming data into useful features.

Bridging the gap

Organisations serious about AI success need to evolve their data quality programmes towards data readiness assessment. This does not mean abandoning traditional quality metrics but supplementing them with AI-specific evaluation.

Anchor assessment to specific use cases

Generic data quality assessment produces generic findings. AI readiness assessment must be anchored to specific, well-defined use cases. What prediction will the model make? What features are required? What historical depth is needed? What label quality is necessary?

Different use cases have different requirements. Data that is ready for one application may be completely inadequate for another. Assessment without use-case specificity provides false confidence or unnecessary alarm.

Evaluate completeness in terms of feature coverage

Instead of measuring field-level completeness, measure feature coverage: what percentage of records have all features required for the specific use case? This directly indicates how many training examples are usable.

Also assess whether missing data is random or systematic. Random missingness is more manageable than systematic missingness that correlates with the outcome being predicted.

Assess label reliability

Examine how outcome labels were generated. Have definitions been consistent? Were labelling criteria clear and consistently applied? For human-generated labels, what was the inter-rater reliability?

If labels are derived from system data, trace back to original sources. Labels that come from aggregations, calculations, or business rules may inherit quality issues from underlying data.

Test cross-system integration

If the AI application requires data from multiple systems, actually test the integration. What percentage of entities can be matched across systems? What is the confidence level of matches? What features are lost when matching fails?

Paper architecture reviews miss issues that only emerge when integration is attempted. Actual data matching reveals the real challenges.

Evaluate temporal patterns

Examine how data has evolved over time. Have definitions changed? Have collection practices varied? Are there discontinuities from system migrations? Is there sufficient history for the patterns you need to learn?

Temporal evaluation often reveals issues invisible in point-in-time quality assessments.

Assess at the model input level

Ultimately, AI readiness should be assessed at the level of model inputs, not raw data. After feature engineering transforms are applied, what is the quality of the resulting training data? This end-to-end assessment captures issues that emerge during data transformation.

The bottom line

High scores on traditional data quality metrics do not guarantee AI success. The green dashboard in the example makes the point. The data met traditional standards but lacked the specific characteristics required for their AI use case.

Organisations planning AI investments need to move beyond traditional data quality to AI readiness assessment. This means anchoring evaluation to specific use cases, assessing dimensions that traditional metrics miss, and testing actual feasibility rather than assuming it from quality scores.

The question is not whether your data is high quality. The question is whether your data can support the specific AI application you envision. These are different questions with potentially different answers.

After eighteen months and a seven-figure budget, the customer churn prediction project at CustomerCo was being quietly discontinued. The internal announcement cited a strategic pivot and changing priorities. The real reason was simpler: the model did not work, and after months of struggling, leadership concluded there was no realistic path to making it work.

How had such a well-resourced project, with strong executive sponsorship and a clear business case, failed so completely? The answer reveals patterns that organisations contemplating AI initiatives need to understand.

The promise

CustomerCo was a mid-market B2B software company with a large base of enterprise customers. The company had grown rapidly through a combination of strong product-market fit and aggressive sales execution. Customer retention was good but not great.

The CEO had become convinced that AI could transform retention. The pitch from the AI vendor was compelling: by analysing customer behaviour patterns, the model would identify at-risk customers months before they churned, giving the customer success team time to intervene. Similar models had reportedly achieved remarkable results at other companies.

The maths looked straightforward. Every point of retention preserved meaningful recurring revenue, and a lift of a few points would repay the project several times over. On paper, it was a clear return.

The project kicked off with enthusiasm. A respected AI vendor was selected after a competitive evaluation. A cross-functional team was assembled, including customer success, sales, product, and IT stakeholders. Executive sponsors at the C-level committed to acting on model predictions and providing whatever resources were needed.

Early warning signs

The first hint of trouble came during the data discovery phase, about six weeks into the project. The vendor data scientists needed to understand what customer data was available for model training. What they found was concerning.

Customer data lived in multiple systems, each implemented at a different time by a different team:

Salesforce housed customer account information, sales history, and customer success activity logs. It had been implemented eight years earlier and modified extensively over time.

A homegrown product analytics system captured usage telemetry, tracking which features customers used and how frequently. This system was only four years old and had undergone two major schema changes.

Zendesk contained support ticket history, including issue categories, resolution times, and customer satisfaction scores. It had been implemented five years earlier.

NetSuite held financial data including billing history, payment patterns, and contract details. It was the oldest system, having been in place for over a decade.

HubSpot tracked marketing engagement including email opens, content downloads, and webinar attendance. It had been implemented three years earlier.

Each system used a different customer identifier. Salesforce used its internal Account ID. The product system used a separate Customer ID assigned at provisioning. Zendesk used email addresses as the primary identifier. NetSuite used its own customer numbers. HubSpot tracked contacts rather than accounts, creating many-to-one relationships.

Matching records across systems required complex logic that produced uncertain results. The data team estimated that a significant minority of customers could not be reliably matched across all five systems. For these customers, the model would have incomplete feature sets.

The second warning was the state of historical churn data. CustomerCo had been tracking churn for years, but the definition had evolved:

Pre-2022: Churn included both voluntary cancellations and non-renewals due to customer acquisition. If a customer was acquired by another company and that company did not continue the subscription, it counted as churn.

2022 to 2023: The definition was revised to exclude customers acquired by companies that remained CustomerCo customers under the acquiring company account.

2024: Customers who downgraded by more than half were reclassified as partial churn, a new category that was tracked separately.

These definitional changes meant that the historical churn labels were inconsistent. A customer with similar behaviour might be labelled as churned in one year and retained in another, depending on when the behaviour occurred.

Exit surveys, which would have provided insight into why customers left, had a low response rate. The survey questions had changed twice over the past four years, and the response categories were different in each version. Cancellation reason codes in Salesforce had been modified three times, with some categories split, others merged, and several added.

At this point, the project was six months in and had already consumed a substantial share of its budget in vendor fees, internal team time, and infrastructure setup. A rigorous assessment might have recommended pausing to address data issues. Instead, the team pushed forward, confident they could work around the problems.

The build

Model development took another eight months, far longer than the originally planned four months. The data scientists tried multiple approaches: logistic regression, random forests, gradient boosting, and eventually neural networks. Each approach required extensive feature engineering to handle the data quality issues.

The team developed elaborate workarounds. For customers who could not be matched across all systems, they imputed missing features using averages from similar customers. For inconsistent churn labels, they standardised to the most recent definition and relabelled historical records. For missing exit survey data, they inferred churn reasons from support ticket categories and usage patterns.

Performance on held-out test data was promising. The best model scored respectably, distinguishing between customers who churned and those who did not with reasonable accuracy. The precision and recall metrics were acceptable. The team was ready for production.

But troubling patterns had emerged during development that were not fully addressed. The model heavily weighted features that seemed like proxies rather than drivers: company size, industry vertical, and original contract value. These features did not change over time and therefore could not explain why a customer who was happy for three years suddenly became at risk.

Usage features, which the business believed should be highly predictive, showed surprisingly weak signal. Customers who churned did not have dramatically different usage patterns than customers who stayed. The data scientists hypothesised that usage data quality issues were masking true patterns, but by this point the project was over budget and behind schedule. There was pressure to move to production and show results.

The production disaster

The model went live in month fourteen. Customer success managers received weekly lists of at-risk customers with predicted churn probability scores. The team was optimistic.

Within six weeks, problems became undeniable.

The false positive rate was much higher than expected. Many customers flagged as high risk showed no signs of dissatisfaction when contacted. Customer success managers were wasting time on customers who had no intention of churning. Worse, the unnecessary check-in calls were annoying some customers. The sales team complained that CSM outreach was undermining relationships with healthy accounts.

The model was missing customers who actually churned. Post-mortem analysis of churned customers showed that many had been assigned low risk scores. These were often customers with data quality issues: incomplete matching across systems, missing usage data, or atypical characteristics that the model had not learned to recognise.

The predictions were not actionable. Knowing a customer was at risk did not tell the customer success team why or what to do about it. Was the customer unhappy with the product? Having implementation problems? Facing budget pressure? Under new leadership? The model provided a score but no insight into root cause. The promised integration with intervention playbooks had never materialised.

Trust eroded rapidly. After a few weeks of acting on predictions that proved wrong, customer success managers stopped trusting the model. They reverted to their own judgment and relationships, using the AI predictions only when convenient. The expensive AI system became shelfware.

The painful reckoning

By month sixteen, the executive team could no longer ignore the failure. Customer retention had not improved. In fact, it had slipped slightly, possibly because the misguided outreach had damaged some customer relationships. The investment had produced nothing of value.

A post-mortem analysis identified the root causes:

Data foundation was inadequate. The inability to reliably match customers across systems meant the model was trained on incomplete feature sets. The usage data that should have been most predictive was too noisy and inconsistent to provide signal.

Label quality undermined training. The changing definitions of churn meant the model was learning from inconsistent targets. It was trying to find patterns in what was partly noise.

The use case was poorly specified. The goal was to predict churn, but churn is an outcome, not a behaviour. The model could identify correlates of churn but could not identify the interventions that would prevent it. Prediction without actionability is worthless.

Warnings were ignored. The data quality issues were known early in the project but were treated as obstacles to work around rather than fundamental problems to solve. The pressure to show progress overrode the judgment to pause and fix the foundation.

What should have been different

In retrospect, several decision points could have changed the outcome:

Data assessment before project initiation. A rigorous assessment of data quality, completeness, and integration feasibility would have revealed the foundational issues before significant investment was made. The project could have been rescoped to a more achievable goal, or data remediation could have preceded model development.

Data remediation before model building. The identity resolution problem and the inconsistent churn definitions should have been addressed before any modelling began. Building sophisticated AI on a shaky data foundation guaranteed a shaky result.

Stage gates with clear criteria. The project proceeded past multiple warning signs because there was no formal checkpoint requiring data quality thresholds before advancing. Each phase flowed into the next on schedule rather than on readiness.

Use-case scoping aligned with data reality. Given the data limitations, a more modest use case might have succeeded. Perhaps identifying customers with support escalations or significant usage declines, rather than predicting churn broadly. A narrower use case with reliable data would have been more valuable than an ambitious use case with unreliable data.

Emphasis on actionability from the start. The project focused on prediction accuracy without equal attention to what would happen after predictions were made. A prediction system without an action system is incomplete.

The aftermath

CustomerCo eventually did improve retention, but through traditional methods: better onboarding processes, more proactive business reviews, improved support responsiveness, and closer alignment between product development and customer needs. These improvements were enabled by better use of existing data and closer customer relationships, not by AI.

The AI detour cost them the full project budget in direct expense, eighteen months of distraction, and significant organisational credibility damage. The executives who championed the project moved on. The data team was demoralised. The organisation became sceptical of AI, making future legitimate AI initiatives harder to fund.

The vendor moved on to the next customer, armed with lessons learned that would hopefully prevent similar failures. But the pattern continues across the industry: ambitious AI projects launched without adequate data assessment, proceeding past warning signs under schedule pressure, and ultimately failing when the data foundation proves inadequate.

The lesson is not that AI cannot work. The lesson is that AI cannot work without adequate data, and that organisations must honestly assess their data before committing to AI initiatives. The assessment might reveal that AI is possible with current data, that AI requires data remediation first, or that AI is not feasible for the intended use case. All of these are better outcomes than spending the budget to learn the hard way.

Understanding these dimensions helps organisations diagnose specific readiness gaps rather than treating data quality as a monolithic problem. Each dimension requires different assessment techniques and different remediation approaches. An organisation might excel on some dimensions while failing on others, and knowing which dimensions are problematic is essential for effective remediation planning.

What is AI-ready data?

AI-ready data is not the same as clean data. It is data fit for a specific use: enough history, consistent definitions, a representative sample and someone accountable for keeping it that way. A database can pass every traditional quality check and still be unsuitable for a model, if every customer comes from one industry or one period, or if the behaviour you want to predict was never recorded. AI readiness is a relationship between the data and the use case, not a fixed property of the data: data that is ready for one application can be inadequate for another. The six dimensions below are how to test that relationship.

Dimension 1: completeness

Completeness measures whether sufficient data exists to support the intended analysis. This is perhaps the most intuitive dimension, but it is often measured incorrectly. Organisations track field completion rates without understanding whether those rates are adequate for AI applications.

Field-level completeness

What percentage of records have values for each required field? A customer churn model that needs email engagement data will fail if most customer records lack email addresses. A demand forecasting model that needs promotional calendar data will fail if promotional events are inconsistently recorded.

Field-level completeness should be measured for each field required by the AI use case, not for all fields in the database. A database might have high overall completion rates while critical fields for the AI application are sparsely populated.

Record-level completeness

What percentage of records have all required fields populated? A record missing three of ten required fields might be unusable even if individual field completion rates look acceptable. As a simple illustration, if 90% of records have field A populated and 90% have field B populated, but different records are missing each field, only 81% of records have both fields.

For AI applications, partial records often cannot be used. The model needs complete feature vectors, meaning all input features must be present. Record-level completeness directly determines how many training examples are available.

Coverage completeness

Does the data cover all scenarios the model must handle? If your training data lacks examples of enterprise customers, your model will perform poorly on enterprise prospects. If your training data is all from North America but you are deploying globally, the model may fail in other regions.

Coverage completeness is particularly challenging when the target outcome is rare. In fraud detection, fraudulent transactions might be a tiny fraction of total volume. You need sufficient examples of fraud across different fraud types, amounts, and contexts to train an effective model.

Temporal completeness

Does historical data extend far enough back with sufficient continuity? A customer churn model might need two to three years of behavioural history. A demand forecasting model for seasonal products might need multiple years of seasonal data. Gaps from system migrations or changed collection practices can undermine model training.

Temporal completeness also means consistent collection over time. If data collection practices changed, older data might be missing fields that newer data has, or vice versa.

Why completeness matters for AI

For AI, completeness requirements are often more demanding than for traditional reporting. A business intelligence dashboard might work fine with patchy coverage. A machine learning model often needs near-complete coverage of the fields it depends on to avoid biased predictions.

Incomplete data does not just reduce the amount of training data available. It can introduce systematic bias if incompleteness is correlated with the outcome being predicted. If customers who churn are more likely to have incomplete records, training on complete records only will produce a model that systematically underestimates churn risk.

Dimension 2: consistency

Consistency measures whether the same real-world entity is represented the same way across all systems and over time. Enterprise data typically lives in multiple systems that were implemented at different times with different standards. Reconciling these systems for AI applications reveals inconsistencies that traditional reporting might tolerate.

Cross-system consistency

Does the same customer have the same identifier in your CRM, ERP, and marketing automation system? Does revenue mean the same thing in your sales system and your finance system? Cross-system consistency is particularly challenging in enterprises with multiple applications accumulated through organic growth and acquisitions.

Entity resolution, the process of determining whether records in different systems refer to the same real-world entity, is often more difficult than organisations expect. Name variations, address changes, and missing identifiers make matching uncertain. And uncertain matching means uncertain features for AI models.

Temporal consistency

Have definitions changed over time? If your definition of an active customer changed in 2023, comparing pre-2023 and post-2023 data will produce misleading results. If product categories were reorganised in 2022, sales trends that span that reorganisation are unreliable.

Temporal inconsistency is particularly insidious because it can be invisible in the data itself. The numbers look reasonable, but they mean different things in different periods. AI models learn patterns from this data without understanding the definitional shifts.

Definitional consistency

Are business rules applied consistently? If some sales reps classify deals differently than others, your win rate predictions will be unreliable. If some support agents categorise tickets differently, your support analytics will be noisy.

Human judgment introduces variability that machines cannot easily account for. Training data that reflects inconsistent human decisions teaches the model to reproduce that inconsistency.

Why consistency matters for AI

Machine learning algorithms are pattern-matching engines. They find patterns in whatever data you give them. If the data contains inconsistencies, the model learns those inconsistencies as if they were real patterns. The result is predictions that seem plausible but are fundamentally unreliable.

Cross-system inconsistency creates particular problems when AI applications need to combine data from multiple sources. A customer 360 view that cannot reliably link CRM data to product usage data to support interactions will produce fragmented features that miss important signals.

Dimension 3: accuracy

Accuracy measures whether data correctly represents the real-world entities and events it describes. Data can be complete, consistent, and formatted correctly while still being wrong.

An address field might be complete and consistently formatted but contain the wrong address. A transaction might be recorded in the system but with the wrong amount. A customer might be flagged as churned when they actually renewed through a different channel. A product might be categorised incorrectly. A date might be wrong due to timezone handling issues.

Measuring accuracy

Measuring accuracy is challenging because it requires comparison against authoritative sources or validation through business process review. Unlike completeness or consistency, accuracy cannot be assessed by examining the data alone.

Common approaches include comparison against authoritative external sources, such as validating addresses against postal databases. Sampling and manual verification provides ground truth for a subset of records. Process review identifies where errors could be introduced. Trend analysis detects anomalies that suggest accuracy issues.

Why accuracy matters for AI

For AI, accuracy directly impacts model quality. Inaccurate training data teaches wrong patterns. If even a small share of your customer addresses are wrong, your model learns geographic patterns based partly on noise.

Inaccurate prediction inputs produce wrong outputs. Even if the model is well-trained, feeding it inaccurate data at prediction time produces unreliable predictions.

Inaccurate outcome labels make it impossible to evaluate model performance. If you cannot reliably know what actually happened, you cannot know whether the model predicted it correctly.

Dimension 4: timeliness

Timeliness measures whether data is sufficiently current for its intended use. Different AI use cases have vastly different timeliness requirements, and understanding these requirements is essential to assessing readiness.

Currency

How old is the data? Customer contact information that is two years old is likely outdated for engagement purposes. Competitive pricing data that is a week old might be stale for dynamic pricing applications. Inventory levels that are hours old might be useless for real-time availability promises.

Update frequency

How often is data refreshed? Daily sales data might be adequate for demand planning but insufficient for real-time inventory optimisation. Weekly customer activity updates might be fine for monthly churn prediction but inadequate for real-time intervention triggers.

Latency

How long between an event occurring and data being available? Same-day fraud detection requires near-real-time data pipelines. An hour of latency might be acceptable for some applications but fatal for others.

Why timeliness matters for AI

For training data, timeliness affects whether historical patterns remain relevant. If customer behaviour has fundamentally changed, older data might teach outdated patterns. The COVID-19 pandemic rendered many pre-2020 behavioural models obsolete.

For prediction inputs, timeliness determines whether predictions are actionable. A fraud alert that arrives an hour after the transaction is useless. A churn prediction based on data that is two weeks old might miss recent warning signs.

Dimension 5: validity

Validity measures whether data conforms to defined formats, ranges, and constraints. This is the dimension most closely aligned with traditional data quality, but it remains essential for AI applications.

A date field containing text values is invalid. A price field with negative values might be invalid depending on business rules. An email field without an @ symbol is invalid. A percentage field with values above 100 is invalid. A state code that does not match any actual state is invalid.

Types of validity checks

Data type validity ensures fields contain the expected data types. Numeric fields should contain numbers. Date fields should contain dates.

Range validity ensures values fall within expected ranges. Ages should be positive and below some reasonable maximum. Prices should be non-negative.

Format validity ensures values conform to expected patterns. Phone numbers should match expected formats. Email addresses should contain @ symbols.

Referential validity ensures foreign keys reference existing records. A customer ID in an order should correspond to an actual customer.

Business rule validity ensures data complies with domain-specific rules. An order ship date should not precede the order date.

Why validity matters for AI

Invalid data can cause technical failures. Model training might crash when encountering unexpected data types. Runtime predictions might fail when feature engineering encounters invalid values.

Invalid data can also produce nonsensical predictions without causing technical failures. A model might happily process a negative age or an impossible date, producing predictions that are technically valid but substantively meaningless.

Dimension 6: governance

Governance measures the organisational capability to maintain data quality over time. The other five dimensions are point-in-time measurements. Governance determines whether quality will persist or degrade.

Without governance, data quality improvements are temporary. Quality degrades as systems change, processes evolve, and personnel turn over. Governance provides the organisational infrastructure to maintain quality continuously.

Ownership clarity

Is someone accountable for each critical data element? Data without clear ownership inevitably degrades. When no one is responsible for data quality, no one ensures quality is maintained. Ownership should include authority to enforce quality standards and accountability for quality outcomes.

Documentation adequacy

Are data definitions, business rules, and system integrations documented? Without documentation, institutional knowledge walks out the door with employee turnover. New team members make decisions that inadvertently violate undocumented assumptions. Documentation should cover data definitions, business rules, quality standards, and integration logic.

Quality monitoring

Are there automated checks that detect quality degradation? Without monitoring, problems are discovered only when AI models fail or business users complain. By then, significant damage may have occurred. Monitoring should cover all critical quality dimensions with alerting that enables rapid response.

Change management

Is there a process to assess data impact when systems or business processes change? Unmanaged change is a primary cause of data quality problems. A system upgrade, a process change, or a new data source can introduce quality issues that propagate undetected until they undermine AI applications.

Why governance matters for AI

AI systems are not one-time projects. They require ongoing maintenance as data patterns shift, business requirements evolve, and model performance degrades. Governance provides the organisational infrastructure for this ongoing maintenance.

Without governance, AI models degrade over time as the data they depend on degrades. Model retraining on degraded data propagates quality problems into future predictions. The result is AI systems that work initially but become unreliable over time.

Weighting dimensions for AI use cases

Each dimension matters differently depending on the AI application. Assessment should score each dimension independently, but the overall readiness score must weight dimensions based on the specific use case requirements.

A recommendation engine might tolerate some inconsistency but require high completeness. Without sufficient examples of user-item interactions, recommendations will be poor regardless of how consistent the data is.

A fraud detection model might prioritise timeliness over perfect accuracy. A slightly noisy signal delivered in real-time is more valuable than a perfect signal delivered hours later.

A demand forecasting model might prioritise temporal consistency over completeness. Better to have consistent data over a shorter period than inconsistent data over a longer period.

Effective assessment requires understanding both the general requirements of AI and the specific requirements of the intended use case. Generic data quality scores provide false confidence or unnecessary alarm. Use-case-specific assessment provides actionable insight.

That one unchecked assumption is where AI projects quietly stop. The vendor demo ran on clean sample data. The business case took the CRM at its word. The board approved a number that rested on records nobody had compared. Six months later the model is live, the outputs look plausible and nobody trusts them, and the project goes quiet: no announcement, just a contract that isn’t renewed.

This article sets out where AI projects actually break, why the usual data quality checks miss it, and the test to run before you sign.

The assumption under every proposal

Read any AI proposal closely and you will find the same sentence, stated or implied: the solution will use your existing customer, finance and operational data. Everything after that sentence depends on it. The forecast accuracy, the churn uplift, the hours saved: all of it assumes the data is complete, consistent and joined up.

Nobody in the room is placed to challenge it. The vendor is paid when you sign. The consultancy is paid to build. Your own team has backed the project before it reached the board. Each of them has a reason to take the data on trust, and none of them is paid to check it.

The wider picture suggests the assumption is fragile: 8% of businesses say their data is fully ready to support AI at scale (Dun & Bradstreet AI Momentum survey of 10,000 businesses, November 2026). And the stakes for the person signing are personal: half of CEOs believe their job is on the line if AI doesn’t pay off (BCG AI Radar, January 2026).

Every system looks clean on its own

Here is why the assumption survives. Ask the head of sales whether the CRM is in good shape and the answer is yes: the fields are filled, the pipeline report runs. Ask finance about the ledger and it balances. Ask HR about the employee list and it is current. Each answer is honest, and each is about one system.

AI doesn’t read one system. A churn model needs the customer in the CRM to be the same customer in billing. A revenue forecast needs deals marked won to have produced invoices. An AI agent working accounts needs the account owner to still work for you. The truth is in the gaps between systems, and those gaps are invisible to anyone looking at one system at a time.

The gaps look like this:

• Customers finance bills that sales never logged. Revenue exists that the CRM can’t see, so any model trained on the CRM learns from part of the customer base.
• Deals marked won with no matching invoice. The pipeline says one thing, the ledger another. A forecast trained on the pipeline inherits the difference.
• Accounts owned by people who have left. The CRM still routes work, alerts and renewals to them.
• The same customer recorded three ways. “Example Foods”, “Example Foods Ltd” and a billing record in capitals: one customer to a person, three to a model.

What it looks like in real output

To make this concrete, we ran our engine on a generated test dataset for a fictional B2B software company, Example Co: 72,837 records across seven exports from CRM, finance and HR. It is real engine output on generated test data, not a client, and the full memo is published as our sample Truth Score Read.

Inside each system, the data looked respectable. Completeness scored 97 out of 100. Accuracy and consistency both scored 88. A dashboard built on any single export would have been green.

Compared with each other, the systems told a different story:

• 823 customers in finance with no account in the CRM.
• Only 13% of deals reconciled to an invoice.
• 3,128 records where the city disagreed between systems.

Connectivity, the pillar that measures whether your systems agree about the same customer, deal or employee, scored 44. That one number changes the verdict. The weighted average of the six pillars was 75, but the Truth Score™ (a score out of 100 for how far your data can be trusted) is capped when a critical pillar is weak, so it came out at 59: Band C, significant work needed. The verdict on the memo was “Don’t sign yet”.

A churn model, a revenue forecast or an AI agent built on that data would have run. It would have produced confident output. And it would have been wrong in exactly the places that matter, because it could only see part of the customer base and couldn’t tie deals to revenue.

Why the usual checks miss it

Traditional data quality work isn’t wasted, but it was built for reporting, not for AI, and it has three blind spots.

It measures one system at a time. Fill rates, duplicate counts and format checks run inside a database. They can’t see that a customer in billing has no twin in the CRM. That is a cross-system question, and it needs the systems compared.

It averages. A field that is 94% complete sounds fine. If the missing 6% are the customers who left, a churn model is blind to exactly the cases it exists to predict.

It asks the people who run the systems. Questionnaires and maturity models record what people believe about their data. Belief and records can disagree in either direction, and the disagreement is often the most useful finding.

What a failed project actually costs

The licence fee is the smallest part. The larger costs are the months of internal time, the decisions made on outputs nobody should have trusted, and the credibility the sponsor spends getting the next AI proposal approved. For an investor-backed company the clock matters too: a project that stalls for a year consumes a year of the hold.

All of this is set in motion at the moment of signing, which is why the check belongs before it.

The test to run before you sign

The test is simple to describe. Take exports from two or more of the systems the proposal depends on, match the customers, people, deals and invoices between them, and see what doesn’t line up. Then read the proposal against what you found: which of the AI ideas in it the data can carry now, which after fixes, and which not at all.

That is what a Truth Score Read does. Our engine matches the customers, people, deals and invoices across the exports you send. Every red flag is checked by hand against sample records before sign-off. Within 5 working days of complete exports you get a signed memo: your Truth Score, a Leverability read on the AI in question (which AI ideas you can use now, after fixes, or not at all), the cross-system red flags, a scope line saying what we didn’t check, and a verdict: sign, fix first, or walk away.

The answer can be “sign”. If the data can carry the proposal, the memo says so in writing, and you go into the board meeting with evidence rather than an assumption. We sell no AI, no software and no fixes, and our fee is fixed before we start, so a “sign” pays us exactly what a “walk away” does.

The method is published on our approach page, including how the score cap works. Clarity before capital.