The Foundation That Gets Overlooked

When AI produces an output that cannot be justified, a risk rating that seems inconsistent, a recommendation that contradicts human judgment or a decision that a regulator challenges, the instinct is to interrogate the model. Retrain it. Adjust the parameters. Add a layer of human review.

However, the failure often sits upstream. The model was working exactly as designed. The problem was that it was processing incomplete, inconsistent or unverified data, or data drawn from sources that could not be traced. While the model was coherent, the data was not.

In financial services, where I work with companies with incredibly data-intensive compliance processes, the consequences are tangible. Financial institutions are managing millions of corporate client records across multiple jurisdictions. Each of those records is assembled from a patchwork of sources, often collected at different points in time, by different teams, in different formats.

When AI is trained or applied against that kind of data estate, the outputs inherit all its inconsistencies. So, an entity flagged as high-risk in one model may appear clean in another, not because the risk calculus differs, but because the underlying data describes a different version of the same company.

This is where many organizations struggle, with Gartner finding "sixty-three percent of organizations either do not have or are unsure if they have the right data management practices for AI." Gartner also found that organizations will abandon the majority of AI projects unsupported by AI-ready data.

Defining Explainable Data

Explainable data is data whose provenance can be demonstrated. For any AI system operating in a regulated environment, that means being able to answer four questions:​

• Where did this data come from?

• When was it last verified?

• How was it assembled?

• What changed, and when?

When these four questions can be answered confidently for every data point that feeds an AI model, explainability becomes a property of the system, not an afterthought applied to its outputs.

What This Looks Like In Practice​

​The clearest illustration I can offer comes from KYC, one of the most data-intensive compliance processes in financial services, and one where the gap between explainable and unexplainable data has direct regulatory consequences.

For decades, the KYC process, building and maintaining a verified picture of every corporate client, has been fundamentally manual. Analysts gather documents. They cross-reference registries. They map beneficial ownership structures through layers of subsidiaries and holding companies. They store the results in systems that were not designed to keep pace with the rate at which corporate entities change.

That legacy creates a direct problem for AI adoption. When the four questions above cannot be answered for the data feeding a KYC model, the model's outputs cannot be defended.

Four Shifts Technology Leaders Can Make

Based on what I'm seeing across the market, here are four strategies that can help executive technology leaders ensure they have a strong explainable data foundation for their AI models:

Treat data quality as an AI prerequisite, not a parallel workstream.

The instinct in many transformation programs is to build the AI capability and address the data foundation in parallel. In practice, this creates systems that are technically impressive but operationally unreliable.

The data work needs to come first. At a minimum, the architecture needs to be designed around the requirements of explainability from day one.

Define what ‘verified' means for your domain.

For a financial institution managing corporate client data, verified means sourced from a primary authority, with a provenance trail that can be produced on request.​

Verified is not the same as present. It is not the same as recent. It is a specific standard that the data either meets, or it does not.

Build audit capability into the data layer, not just the model layer.

Many explainability frameworks focus on making the model's reasoning visible through attention mechanisms, confidence scores or post hoc explanation tools.

These are valuable. They explain what the model did with the data it received.

However, if the data itself cannot be interrogated, those explanations are incomplete. The audit trail needs to run from the model output back to the original source, with every step in the data pipeline logged and accessible.

Decide where the model holds the decision, and where it does not.

Large language models (LLMs) are non-deterministic by design. The same verified data, the same prompt, can produce different outputs on different runs. For compliance use cases, that is a first-class constraint.

Explainable data removes the ambiguity from the evidence layer. But you still need to be deliberate about which decisions an LLM can own, and which ones require deterministic, auditable logic to hold the line.

Conclusion

There is a final point that deserves more attention in executive conversations about AI strategy: Explainable data can be a competitive differentiator.

According to a McKinsey survey, more than 2 in 5 institutions in the credit industry have slowed AI development due to disappointing outcomes, with upstream data risk among the most commonly cited reasons.​

Other McKinsey research found that banks assign 10% to 15% of their workforce to KYC and AML alone, and that AI can be a significant productivity multiplier for these teams. However, AI is unlikely to reduce this cost base if the underlying data cannot be trusted. ​

The institutions that invest in a verified data foundation first can get results they can trust as well as defend.​​​

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?