[EAAPL-DAT002] Data Quality for AI

Category: Data Architecture
Sub-category: Data Quality / AI Readiness
Version: 1.3
Maturity: Proven
Tags: data-quality, feature-validation, quality-gates, drift-detection, label-quality, AI-readiness
Regulatory Relevance: EU AI Act Article 10, APRA CPS 234, ISO 42001 §8.4, NIST AI RMF MAP-2.3

1. Executive Summary

AI systems are uniquely sensitive to data quality failures in ways that traditional BI systems are not: a 3% missingness rate in a key feature can degrade a fraud model's recall by 15–25%. Yet most enterprises apply generic data quality frameworks designed for reporting, not for machine learning. This pattern defines an AI-specific data quality management pipeline that enforces quality gates at every stage of the AI data lifecycle — from source ingestion through training to live inference.

The pattern introduces six AI-specific quality dimensions beyond the classic accuracy/completeness/timeliness trio: representativeness, label quality, inter-feature consistency, distribution stability, temporal validity, and lineage completeness. Automated quality scoring, threshold-based pipeline gates, and remediation workflows ensure that only fit-for-purpose data reaches model training and inference serving.

Organisations that implement this pattern report a 30–50% reduction in model retraining cycles triggered by data quality degradation and a significant improvement in their ability to satisfy regulatory enquiries about training data fitness under EU AI Act Article 10.

Target audience: Chief Data Officers, ML Platform leads, Data Engineering leads.

2. Problem Statement

Business Problem

AI models in production degrade silently because the data feeding them changes without detection. Business decisions based on degraded model outputs cause financial loss, regulatory exposure, and erosion of stakeholder trust in AI programmes.

Technical Problem

• Standard data quality tools (Great Expectations, Deequ) test for completeness/uniqueness/referential integrity — necessary but insufficient for AI.
• AI training requires representativeness (does the training distribution match the inference population?), label quality (are ground-truth labels correct and consistent?), and temporal validity (are time-windowed features computed correctly?).
• Quality checks are typically applied at source ingestion, not at the point of feature computation or model serving — leaving a gap in the AI data pipeline.
• There is no standard mechanism for quality failures to trigger model rollback or human review rather than silent degradation.

Symptoms

• Model performance metrics (AUC, F1) decline between retraining cycles without obvious cause.
• ML engineers discover data quality issues only after model deployment.
• Training datasets fail regulatory audit because quality assessment documentation is absent.
• Feature pipelines pass unit tests but produce subtly incorrect features in production (e.g., data leakage from incorrect time-windowing).

Cost of Inaction

3. Context

When to Apply

• Any AI system where training data originates from operational systems (ETL pipelines, event streams, external feeds).
• AI systems subject to regulatory oversight (high-risk AI per EU AI Act Annex III; APRA-regulated institutions).
• Production AI models where retraining is costly or infrequent (>2 weeks between retraining cycles).
• Systems where model output quality directly affects business decisions or customer outcomes.

When NOT to Apply

• Pure research/experimentation environments where data quality enforcement would slow iteration.
• AI systems consuming already-validated data products from a mature Data Mesh (quality gates already enforced upstream).
• Very simple rule-based classifiers where feature engineering is trivial and interpretable.

Prerequisites

Industry Applicability

4. Architecture Overview

Design Philosophy

The core insight of this pattern is that data quality for AI is a pipeline property, not a dataset property. A dataset can be perfectly accurate yet produce incorrect features due to wrong join logic, data leakage, or distribution shift. Quality must therefore be assessed and enforced at each stage of the AI data pipeline, not only at source.

Stage 1 — Source Quality. Traditional quality checks (completeness, accuracy, referential integrity, format validity) are applied at data ingestion. These checks use proven frameworks (Great Expectations, Deequ, dbt tests) and block pipeline execution on hard failures. This stage is necessary but not sufficient.

Stage 2 — AI-Specific Feature Quality. After feature engineering, a second quality pass applies AI-specific checks:

• Representativeness: Statistical tests (Population Stability Index, KS test, chi-squared) compare the feature distribution in the current training cohort against a reference distribution (typically the first production training run). A PSI > 0.25 indicates significant distribution shift requiring human review.
• Temporal validity: For time-windowed features, validate that no future data has leaked into the training window (a subtle but catastrophic quality failure).
• Label quality (for supervised learning): Assess label error rate using Cleanlab or cross-validation confidence-based methods. Label error rates above 5% in training data typically degrade model performance below acceptable thresholds.
• Inter-feature consistency: Validate that combinations of features are logically consistent (e.g., account_age cannot be negative; customer_tenure cannot exceed account_age).

Stage 3 — Training Dataset Quality Gate. Before a training run is initiated, an automated Quality Scorecard is computed across all six AI quality dimensions. Each dimension has a threshold. A training run is blocked if any dimension falls below its hard threshold, or if the weighted quality score falls below an overall threshold (recommended: 0.85 on a 0–1 scale).

Stage 4 — Inference-Time Feature Quality. At inference time, online features are validated before being passed to the model. This catches data pipeline failures that would otherwise cause the model to serve incorrect predictions silently. The validation is lightweight (schema check + null check + range check) to avoid inference latency impact.

Stage 5 — Prediction Quality Monitoring. Model outputs are monitored for prediction distribution drift. A sudden shift in the distribution of predicted classes or scores is an early indicator of underlying data quality degradation. This feeds back into a retraining trigger mechanism.

Quality Scorecard Design. Each of the six dimensions produces a normalised score (0–1). The overall quality score is a weighted average, with weights configurable by use case (e.g., healthcare AI weights label quality higher; fraud detection weights representativeness higher). The scorecard is stored alongside the training dataset version and model version for audit purposes.

5. Architecture Diagram

6. Components

7. Data Flow

Primary Flow

Error Flow

8. Security Considerations

Authentication & Authorisation

• Quality check pipelines run under service identity with read-only access to source data; no write-back to source systems.
• Quality scorecard store protected by role-based access; model training pipeline must present valid scorecard ID to proceed.

Secrets Management

• Database credentials for quality checks stored in secrets manager; rotated every 90 days.
• No credentials embedded in pipeline code or Great Expectations config files.

Data Classification

• Quarantine store inherits classification of source data; treated as Confidential minimum.
• Quality reports do not contain sample records — only aggregate statistics — to avoid PII exposure in quality artefacts.

Encryption

• Quarantine store encrypted at rest (AES-256); in transit TLS 1.3.
• Quality scorecards and reports encrypted at rest; access logged.

Auditability

• Every quality check execution logged with: dataset version, check type, result, timestamp, pipeline run ID.
• Quality gate decisions (pass/block/override) logged immutably; human review decisions captured with reviewer identity.

OWASP LLM Top 10 Mapping

9. Governance Considerations

Responsible AI

• Representativeness checks enforce demographic parity in training data, reducing systematic bias introduction.
• Quality scorecards are mandatory artefacts for high-risk AI impact assessments.

Model Risk Management

• Model risk management frameworks require training data quality attestation; Quality Scorecard provides this automatically.
• Quality score < 0.85 is an automatic risk flag requiring risk committee review before model deployment.

Human Approval Checkpoints

• Distribution shift alerts (PSI > 0.25) require human ML lead approval before training proceeds.
• Label quality failures require label owner review and sign-off before training.
• Quality score override (proceeding with score < 0.85) requires written justification from CDO-delegated authority.

Governance Artefacts

10. Operational Considerations

Monitoring

SLOs

Logging

• All quality check results logged in structured JSON; retained 7 years for regulatory compliance.
• Quarantine records retained for 90 days minimum; extended for records involved in regulatory investigations.

Incident Management

• Quality gate block → P2 incident; data owner and ML lead notified within 15 minutes.
• Prediction drift alert → P2 incident; ML platform team investigates root cause.
• Label quality failure → P1 if model in production; immediate production model freeze investigation.

Disaster Recovery

Capacity Planning

• Source quality checks run as batch jobs; scale Spark/Deequ executors based on daily data volume.
• Inference-time validation is in-process; minimal compute overhead (target <5ms).
• Drift monitors run on prediction sample (typically 1–10% of predictions); compute scales with sampling rate.

11. Cost Considerations

Cost Drivers

Scaling Risks

• Batch quality checks on very large datasets (>10TB) can become expensive; use sampling for distribution checks.
• Inference-time validation overhead grows with feature vector size and request volume; keep validation logic lightweight.

Optimisations

• Use statistical sampling for representativeness checks; full dataset scanning is rarely necessary.
• Cache quality check results for unchanged dataset partitions (incremental quality check pattern).
• Use open-source Evidently AI for drift monitoring rather than SaaS platforms for cost-sensitive deployments.
• Run Cleanlab label quality checks once per labelling cycle, not per training run.

Indicative Cost Range

12. Trade-Off Analysis

Option Comparison

Architectural Tensions

13. Failure Modes

Cascading Failure Scenarios

• Silent distribution shift cascade: PSI threshold misconfigured → distribution shift not detected → model trained on shifted data → model deployed → prediction quality degrades → business decisions affected → detected only at quarterly review.
• Quality gate outage cascade: Quality gate controller service down → pipeline bypasses quality checks → bad data reaches training → biased model trained → deployed to production → regulatory audit finds no quality attestation for model.

14. Regulatory Considerations

15. Reference Implementations

AWS

Azure

GCP

On-Premises

16. Related Patterns

17. Maturity Assessment

Overall Maturity: Proven — Source quality frameworks (Great Expectations, Deequ) are mature. AI-specific quality dimensions (representativeness, label quality) are emerging as industry standard practice, supported by Cleanlab and Evidently.

18. Revision History