Your Data Isn’t Ready for AI. Here’s How to Fix That Before the Regulator Asks.

The Question Boards Are Getting Wrong

Every board we speak to is talking about AI. What they want to know is which use cases to prioritise, which vendors to evaluate, and how far behind their competitors they are. Those are fair questions. But they nearly all skip the one that matters most right now:

Is our data actually ready for this?

Not conceptually. Not on a slide. Right now, today do we have the foundations in place to deploy an AI system that performs reliably, behaves safely, and stands up to regulatory scrutiny?

In most organisations, the honest answer is no. And the gap between where data capability actually sits and what AI genuinely requires is closing fast, not because of internal ambition, but because of external regulatory pressure.

The EU AI Act changed the dynamic. So has the FCA’s increasingly data-centric approach to Consumer Duty.

So has BCBS 239 for banks. These frameworks are no longer asking whether you have a data strategy. They are asking whether your data is governed, traceable, and demonstrably fit for purpose at the point of AI use. That is a much harder question.

Crucially, as we focus in on AI usecases, the data question is no longer about critical data, CDEs, key metrics – it’s about all data and the level of warranty & trust that can be demonstrated.

The world is moving from data management for compliance, to data management for AI competitive advantage – organisations need to be ready.

Why This Is a Compliance Problem, Not Just a Performance One

For years, data maturity was framed as an efficiency and value argument: better data, better decisions, faster insights, more revenue. All true. But that framing has consistently failed to generate the investment and urgency that AI and regulation together are now forcing.

The EU AI Act classifies AI systems used in insurance risk assessment and pricing, credit scoring, employment, critical infrastructure, law enforcement, and regulated products as high risk. For organisations deploying AI in any of those domains, the Act mandates specific, auditable controls including:

  • Data governance and data quality controls for training, validation and testing data
  • Logging and traceability of AI system inputs and outputs
  • Human oversight mechanisms
  • Post-market monitoring
  • Ongoing input data quality management throughout the operational lifecycle

Read that list carefully. It is not a description of a future state. It is a legal requirement, enforceable now. And it maps almost exactly onto what the DCAM and CDMC frameworks define as core data management capabilities.

The UK’s ICO guidance on AI and data protection, the FCA’s expectations under Consumer Duty, and growing US state-level AI accountability legislation are heading in exactly the same direction. Regulators across jurisdictions are converging on a shared expectation: that organisations can demonstrate, with evidence, that their data is governed, traceable, high quality, and used responsibly before the AI is deployed not after something goes wrong.

Your board may have not asked for an AI readiness audit yet. But the regulator is about to.

What AI Readiness Requires and What It Doesn’t

The assumption we encounter most often is that AI readiness is primarily a technology problem. Get the right platform, deploy a modern data architecture, invest in a context store & vector database, and you are ready to go. This gets it backwards.

Technology is the last mile. The foundations that determine whether AI performs reliably or fails dangerously are the data management capabilities that sit upstream: how data is defined, owned, governed, quality-controlled, and made genuinely reusable across the enterprise.

When those foundations are weak or absent, AI projects don’t just underperform. They produce unreliable & unpredictable outputs, generate model risk, create regulatory exposure, and erode the internal trust needed to scale AI beyond a single proof of concept. As we explored in AI Doesn’t Have a Capability Problem. It Has a Trust Problem., the next wave of enterprise AI will be defined not by what models can do, but by whether organisations can trust the data that feeds them.

That trust is built in the data layer, long before the model is trained.

DCAM and CDMC: What the Frameworks Actually Tell You

The Data Management Capability Assessment Model is the EDM Association’s global standard for measuring and building enterprise data management capability. It defines the disciplines, controls, and maturity levels an organisation needs, to manage data as a strategic asset and it is the framework Quaylogic uses as the diagnostic backbone of every AI foundations engagement, as authorised EDM Association’s partners.

The Cloud Data Management Capabilities framework extends DCAM into modern cloud and hybrid environments, addressing the specific controls needed when data moves across platforms, jurisdictions, and automated pipelines. For most organisations operating on cloud infrastructure today, CDMC is where the rubber meets the road.

Together, these frameworks, provide a structured, measurable view of whether your data capability is fit for AI. The key domains they assess, map directly onto what AI systems genuinely need:

1.  Data Meaning and Governance

AI systems need to know what data means. Not just what a column is called, but what it represents, in which business context, with what ownership, and with what accountability for quality and use. Without an operational business glossary, active data dictionary, functioning data ownership model, and live governance controls, AI will consistently misinterpret its inputs. The critical word here is operational. A business glossary that lives in a document nobody reads is not a data governance capability. DCAM measures the difference between governance that exists on paper and governance that actually runs.

👉See: Data Culture in the Age of AI.

2.  Data Quality Controls

Poor data quality is the single most common reason AI projects fail to deliver. Quality issues that a human analyst absorbs through judgement and context, become systematic model errors when an AI is consuming the same data at speed and at scale. The cost of bad data in the UK is already significant in traditional analytics contexts. In AI, it compounds. DCAM and CDMC define the controls required: quality rules with business meaning attached, automated measurement and monitoring, issue identification with clear remediation ownership, and quality standards enforced at the point of ingestion & processing, not caught downstream.

3.  Data Lineage and Traceability

The EU AI Act requires deployers to maintain logs and demonstrate traceability of AI decision inputs, which is impossible without end-to-end data lineage. This is also the mechanism that makes regulatory reporting, audit trails, and model explainability achievable. Building IRB-compliant lineage for mortgage portfolios has taught us that the lineage work is only achievable where governance, quality, and architecture foundations are already in place. Where they are absent, lineage becomes a much longer programme of work than it needs to be.

👉 For practical context, see: Navigating the EU Data Act.

4.  Data Protection and Acceptable Use

AI systems that consume personal data need to do so within clearly defined, enforceable acceptable use boundaries. Policies are not enough, boundaries need to be implemented at the architecture level through contracts, classification, metadata controls, consent tracking, and privacy-by-design patterns built into the platform.

CDMC addresses the controls required for data in cloud environments: access governance, jurisdictional constraints, encryption, and automated enforcement of data handling rules. The ICO’s AI and data protection guidance is clear on this.

👉 Our Unified Privacy, Data and Security Operating Model covers the structural model in more depth.

5.  Reusable Data Products in a Controlled Environment

The organisations making the most of AI are not rebuilding their data layer from scratch for every new use case. They have invested in reusable, trusted, warranted data products that are well-defined, governed, quality-assured datasets consumed across multiple AI and analytics initiatives without each team re-doing the same preparation in a silo. This matters both for efficiency and for risk management. Reaching it is the difference between AI at pilot scale and AI at enterprise scale.

👉See: Data Products Are Failing in Most Organisations: Here’s Why and Turning Data into a True Business Asset.

The Five Gaps We Find Most Often

A DCAM assessment reveals the same patterns with remarkable consistency across sectors and organisation sizes. These are the five gaps that we find in almost every engagement:

Gap 1: Governance exists on paper but isn’t fully operational

Business terms are defined but not consistently applied. Data owners are named but not active. Governance forums meet but don’t make binding decisions. This is the most common gap, and the most dangerous for AI. A governance layer that is decorative rather than functional provides no actual protection when a model is consuming data at scale.

Gap 2: Data quality is measured but not managed

Most organisations have quality dashboards. Far fewer have closed-loop quality management — rules that trigger remediation & straight-through-processing automatically, monitoring that tracks trends over time, and standards enforced at the point of data ingestion & processing. AI amplifies whatever quality posture already exists. Average data quality produces average, unreliable & unpredictable AI, at best.

Gap 3: Lineage is incomplete or domain-specific

Most organisations can trace data within a single system. Very few can trace it end-to-end across the enterprise, from original source through every transformation to the model input. That is the gap that becomes a regulatory liability the moment an AI decision is challenged or an audit is triggered.

Gap 4: Data protection is advisory rather than enforced by architecture

Policies exist. What is rare is architecture-level enforcement: classification schemas active in the data catalogue, consent metadata flowing through pipelines, access controls applied automatically rather than manually. As AI systems consume more data at greater speed, the gap between policy and enforcement becomes material risk.

Gap 5: Every AI project rebuilds its own data layer

Without reusable data products, each AI initiative starts from the beginning — cleansing, mapping, and governing its own data in isolation. This is slow, expensive, and accumulates technical and governance debt with every project. It is also the main reason AI fails to scale beyond individual proofs of concept.

Figure: The 5 Gaps – Why AI Initiatives Struggle to Scale

Where to Start

A DCAM baseline assessment moves the conversation from ‘we think we’re roughly ready for AI’ to ‘here is precisely where we stand, and here is the ordered sequence of capability investments that will close the gap.’

In practice, that drives four parallel workstreams that run alongside – not before – AI development:

01. Activate governance: move from documented to operational: active data owners, a living business glossary, governance forums that make and enforce decisions

02. Implement quality by design: shift quality management upstream into the point of data ingestion & processing so AI systems receive pre-validated, trusted data

03. Build lineage for the critical domains first: prioritise data elements feeding your highest-risk AI systems and most scrutinised regulatory reporting

04. Build reusable data products: so each new AI use case draws on governed, quality-assured, pre-approved datasets rather than starting from scratch

    The Moment Is Now

    The organisations that will move fastest and most confidently with AI are not necessarily the ones with the most advanced models. They are the ones whose data foundations are strong enough to deploy those models at scale, safely, and with abundant evidence to defend against any regulator, board, or customer challenge.

    That work is not glamorous. Nobody gets excited about business glossaries or data quality monitoring pipelines. But they are exactly what separates an AI programme that delivers sustained value from one that produces impressive demos and then stall.

    The board will ask for an AI readiness audit. The regulator may demand one. The question is whether you do it now, on your own terms, or later under pressure, in response to something that has already gone wrong.

    At Quaylogic, we work with CDOs, CIOs, and transformation leaders to assess data management maturity using DCAM and CDMC, identify the priority gaps that carry the most risk, and build the foundations that turn AI investment into trusted, scalable business capability. We don’t just measure and advise. We design, execute and embed.

    Ready to understand where your organisation sits on the AI readiness spectrum? 🚀

    Contact our Quaylogic team to discuss an assessment.


    What We Get Asked (FAQs)

    What is AI data readiness?

    The state in which an organisation’s data governance, quality, lineage, protection and product capabilities are operating and whether they are sufficient to deploy AI reliably, safely and in compliance with applicable regulation.

    What frameworks measure it?

    The EDM Association’s DCAM (Data Management Capability Assessment Model) and the CDMC (Cloud Data Management Capabilities) frameworks.

    Why does it matter now?

    The EU AI Act is in force. For deployers of high-risk AI, data governance and data quality controls are legal requirements not aspirational targets.

    What does good look like?

    Operational, highly automated, governance (not just documented), engineered data quality, end-to-end lineage, architecture-level data protection, and reusable data products that serve multiple AI use cases without being rebuilt each time.

    How long does a DCAM assessment take?

    A baseline DCAM assessment with Quaylogic typically runs over four to six weeks, depending on organisational complexity. It produces a scored, evidence-based maturity profile across all key capability domains, a prioritised gap analysis, and a roadmap linked to both AI ambitions and regulatory obligations.

    Do we need to reach full DCAM maturity before deploying AI?

    No. The goal is not to complete a maturity programme before touching AI. The goal is to understand precisely where your capability sits today, identify the gaps that carry the highest risk for your specific AI use cases, and close those gaps in parallel with AI development not sequentially.

    Is DCAM relevant if we are not a financial services firm?

    Yes. DCAM was originally developed with financial services in mind but is now applied across industries, healthcare, public sector, retail, and technology organisations. The capability domains it covers, governance, quality, lineage, architecture, data products, are universal requirements for AI-ready data across sectors.

    How does DCAM relate to the EU AI Act?

    The EU AI Act’s data governance requirements for high-risk AI systems map onto DCAM capability domains. Achieving DCAM maturity in the relevant areas provides substantive, evidential readiness for AI Act compliance not just documentation, but operational capability.

    What is the difference between DCAM and CDMC?

    DCAM assesses enterprise data management capability broadly. CDMC focuses specifically on cloud data management controls data security, access governance, jurisdictional compliance, and automation in cloud and hybrid environments. For most modern organisations, both are relevant.


    About the Author

    IOANNIS ACHLADIOTIS, Partner, Strategy & Transformation

    Ioannis leads Quaylogic’s Strategy & Transformation practice, with a strong focus on data strategy, data management, and large-scale transformation. He helps clients align data strategy with business value, creating trusted, scalable foundations for growth.

    A seasoned data professional with over 20 years’ experience, Ioannis has designed and delivered large-scale Data & Analytics programmes that drive transformation and lasting adoption across organizations. His career spans senior leadership roles at HSBC, Deutsche Bank, and Lloyds Banking Group, as well as consulting experience with Accenture.

    Share the Post:
    Privacy Overview

    We use cookies to help you navigate efficiently and perform certain functions.

    You can choose to enable or disable some or all of these cookies but disabling some of them may affect your browsing experience.

    You can read more here.

    Necessary Cookies

    These cookies are stored on your browser as they are essential for enabling the basic functionalities of the site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.

    3rd Party Cookies

    We also use third-party cookies that help us analyse how you use this website, store your preferences, and provide the content and advertisements that are relevant to you. These cookies will only be stored in your browser with your prior consent.