If AI is an advanced engine, then high-quality data is its fuel. AI is only as effective as the data it is trained on, the data it processes as input, especially the data characteristics used for analysis.
In my previous article, I introduced the Enterprise Data Reference Architecture (EDRA) as a guide for building a strong AI data foundation.
Before diving back in, EDRA has been updated since this article was first published. AI adoption has accelerated faster than most data strategies anticipated, and capabilities that felt experimental two years ago (vector stores, retrieval-augmented generation, agent orchestration, AI-specific governance) have simply become the norm. The data principles haven’t changed, however the architecture they sit within has. See below, my new EDRA.
One particular point of EDRA is that some foundational components at Level 0, such as Ingestion and Data Sharing and Access, Infrastructure and Security, can be reused across organisations that operate within the same technology ecosystem (e.g., AWS, Microsoft Azure, GCP). This reusability enables technology solution architectures for the data platforms to be standardised, requiring minor modifications across different clients and industries. Two further components now work the same way: AI Governance and Trust and a Semantic Layer, both reusable in the same standardised sense across cloud ecosystems.
But this raises an important question: What differentiates a successful AI project, or any other data-intensive project, from one that fails to meet business expectations? While multiple factors influence outcomes, a critical, and often overlooked, differentiator lies in the data domain.
Unlike infrastructure components of EDRA, the Data Management block is unique to each organisation and even to each AI project. This is where true differentiation occurs. In this article, we’ll explore Data Management, not from a tooling perspective, but as a decisive factor in project success.
To better illustrate this, I will use the empty shell scenario. Imagine a team of skilled technical architects, designers, and developers who have carefully analysed business problem statements, crafted solution architecture documents, designed and built a cutting-edge AI platform. The system is live and operational, but it is an empty shell. There is no data in the storages, no business rules, no data engineers, no data pipelines, no data ingestion, no AI models, and no user access. Below is a simplified example diagram to depict Azure AI platform infrastructure components.
Majority of other functional elements fall under Data and AI practice. Let’s explore the critical components of an approach to data management that ensures success for AI and data-driven projects.
- Data Architecture can be a part of Solution Architecture, which may include frameworks, data models and design artefacts. However, the focus is on business data domains representing: a)Data models to demonstrate how various business data domains interact; b) Data mappings to discover where the physical data for each domain is created, processed and stored; c) Data flows to reveal whether master data is unique and truly authoritative across enterprise; d) Data types documentation to respond to business needs for downstream use of data in the minimal transformed state.
- Data Governance (DG) that is not about committee and frameworks, policies, tasks or escalations. Here is what matters for our project: a) Both, Data and AI governance start with clear ownership, a data domain needs an accountable owner, and so does a model, a prompt library or an agent. b) Both depend on defined quality criteria, data quality characteristics on one side, model performance, explainability and output audit on the other. c) Both rely on controls and business rules rather than ad-hoc decisions, and both work best as an enabler embedded early, not a checkpoint bolted on at the end. d) If your organisation already has a mature DG practice, you are most of the way to mature AI governance practice. DG reinforces the cross-functional nature of AI initiatives and it is an enabler rather than a bottleneck. While an AI Centre of Excellence may reside within one business unit, the success of AI initiatives depends on enterprise-wide collaboration. Data Governance can facilitate cross-functional alignment, ensuring all contributing functional units understand the organisational objectives for AI and their data-related responsibilities.
- AI Governance genuinely specific elements worth mentioning are: a) Drift without any change to the system itself. A model can start behaving differently in production due to degraded accuracy, more bias, worse answers even when nothing about the model, the code, or the pipeline changed, simply because the world moved past what it was trained on. “Is it still doing what we approved” has to be watched continuously; it can’t be answered by checking lineage or a quality score the way a data question can. That’s the real justification for Model Monitoring existing as its own thing rather than folding into Data Observability. b) Guardrails for behaviour that doesn’t exist until the model invents it. AI governance increasingly has to constrain things that don’t exist yet: a generated response, an agent’s next action. That’s a different kind of check, not “is this input correct” but “is this novel output safe to show, or this action safe to execute”, which is why guardrails and human oversight had to become governance categories data governance never needed.
- Data Protection design remains a critical consideration, even though most AI use cases do not require sensitive data. When data source is a candidate for ingestion, data sensitivity is not always immediately clear or visible. Given the significant investment in data and AI platforms, which are typically built to serve a wide range of business needs beyond AI models execution, it is essential to maximise ROI by considering the following: a) Sensitive data in transit and at rest must be identified, protected, and segregated from non-sensitive data through specialised design approaches; b) Access controls should account for integration scenarios where sensitive and non-sensitive data may need to be used together, either in identified or de-identified forms.
- A Master and Reference Data Management approach that maximises data efficiency by aligning with the organisation’s current MDM maturity level is essential. AI initiatives often require scalability across multiple business domains, and the availability and accuracy of master and reference data directly influence project scalability, cost-effectiveness, and long-term viability.
- RAG and Vector Pipelines turn governed data into something a model can actually retrieve and reason over at the point of inference. A vector store is a living index, embedding model choice, and re-indexing cadence all affect what the system effectively “knows” at any given moment, and getting any of them wrong tends to show up as a confidently wrong answer rather than a broken pipeline. This is also where Data Protection principle above gets operationalised: once sensitive data is embedded into a vector store, row- or column-level controls don’t carry over cleanly, so redaction and sensitivity classification need to happen on the way into the index, not after, since removing a record from a vector store later is far harder than removing a row from a database.
- The Feature Store and Model Registry play the same role for AI that MDM plays for data. A single authoritative source for features and trained models that multiple AI projects can reuse, rather than each team re-deriving its own version. A Model registry does the equivalent for the models themselves: version, owner, approval status, and the dataset and feature set each model was trained against.
- Data environments design goes beyond the standard Development, Test, Production environments. Modern data platforms require additional capabilities. At least the following four environments are essential:
- User Data entry for manual input and maintenance of data and metadata that cannot be sourced from a system;
- Data engineering for configuring, managing, and monitoring data processing jobs, ideally restricted to a single physical data environment to minimise exposure;
- Automated audit processes exclusively to record audits and logs to perform quality checks and monitorin;
- Model training and experimentation, isolated from production data engineering, where data scientists can iterate on training runs and evaluation without risk to live pipelines or production data.
- A well-defined data engineering framework goes beyond selecting tools and building functional data pipelines, it is essential to ensuring scalability and long-term maintainability. To support automation, reuse, and data quality, the framework should be designed to enable as many parameters as needed to adopt patterns, modular code reuse, live cost control, live performance tuning, and automated maintenance. Key elements include:
- Early inclusion of data engineers in the design phase to test designs and minimise rework;
- Reusable data products to support a mesh of various forms, structures, and transformation states;
- Environment-agnostic configurable data pipelines deployed by parameters, and not manual configuration changes;
- Availability of raw data in the original state at any point of time without the need to re-extract from source systems;
- ‘As Built’ document to reflect actual implementation of the design that demonstrates any deviations to assist with support;
- Data catalogues that are versioned and built automatically to enable real time data lineage;
- Data effective dates and status flags designed to retrieve the data as at any point of time;
- Audit information design to extend standard system capabilities with specific logs to monitor individual jobs and automate data load status updates to business users.
- Data Observability built in from the start, such as pipeline monitoring, freshness checks, drift detection, SLA monitoring, to catch the silent data failures that AI pipelines are particularly prone to; Data Contracts between producers and consumers that guarantee schema stability, so downstream AI pipelines don’t break silently when an upstream source changes .
The engine is powerful but fuel must be right. 😊
Copyright © NeatenMyData
Neaten My Data 