The short version
In the AI projects I’ve reviewed, the data layer caused more delay than the modelling did. The data turns out to be inaccessible, inconsistently defined, or unusable for the purpose it was wanted for.
AI won’t fix your architecture - it will amplify it. Good data foundations make AI powerful. Bad foundations make AI expensive and unreliable.
The companies succeeding with AI aren’t the ones with the fanciest models. They’re the ones with:
- Clean, accessible, well-documented data
- Infrastructure that can serve models at scale
- Governance that enables experimentation safely
- Architecture that connects AI outputs to business processes
If your data sits in dozens of systems with no agreed definitions, an AI feature inherits every one of those inconsistencies and puts them in front of a customer faster.
Before an AI feature ships to EU customers
Most of this page covers the platform underneath. This section is the check I run on one feature before it goes live.
Try deleting one customer from everything the feature reads. That test finds the copies nobody listed: support tickets in the warehouse, chunked copies in a vector store, a sample in a fine-tuning file, prompts sitting in a vendor’s logs.
Five questions, yes or no:
- Can you list every place the feature’s input data is copied to, including caches, backups, and subprocessors?
- Can you remove one person from all of those, and do you know how each store handles it? GDPR gives a controller a month to respond, extendable by two months where the request is complex, and erasure applies where an Article 17 ground exists and no exception overrides it. Recipients of the data may need to be told as well. Backups are their own case: regulators accept that surgically deleting one record from a backup isn’t always possible, so the usual approach is to block any further use of the record and let the backup’s own retention and overwrite schedule remove it, while making sure an erased record isn’t reintroduced by a restore, or is deleted again straight after one. Write down which store does which.
- Is there a named owner for each source the model reads?
- Can you say which version of the data the feature saw on a given date, and which model and prompt produced a given output?
- Have you written down how the use case classifies under the AI Act, and why? Classification follows the system’s intended purpose. One route is Annex III, which lists high-risk use cases directly. The other runs through Annex I product legislation, and it applies only where the AI is a product or a safety component covered by that legislation and that product already requires third-party conformity assessment. Your role decides which obligations attach: providers carry most of them, deployers fewer, and a deployer can become a provider in defined circumstances such as putting its own name on the system or substantially modifying it. A provider relying on the Article 6(3) exception for an Annex III use has to document that assessment, and high-risk systems carry logging and traceability duties of their own.
If the answer to 1 or 2 is no, the data work comes before the launch date. In the teams where I’ve done this it has meant weeks of unglamorous plumbing rather than months, and it costs less than retrofitting it after a complaint.
None of this is legal advice. A DPO advises and monitors; the company stays accountable for the decision, and your counsel settles the legal questions. The copies, the owners, and the ability to reconstruct what the model saw are architecture, and that part is yours to fix.
Why AI projects stall at the data layer
The data readiness gap
Organizations launch AI initiatives assuming data is ready. It rarely is.
Common discoveries after the project starts:
- Data exists but can’t be accessed
- Data can be accessed but isn’t clean
- Data is clean but definitions vary across systems
- Data is consistent but not at the right granularity
- Data is available but there isn’t enough history
- Data exists but can’t be used (privacy, licensing, consent)
Each of these can derail an AI project that looked promising in the planning phase.
The data quality problem
Training data sets the ceiling, though model design, evaluation, prompts, retrieval, and runtime inputs all move the result too.
Inconsistent inputs show up as inconsistent predictions. Stale inputs produce confidently outdated answers: a retrieval store that missed last week’s price list will quote last week’s prices. Bias in the data can carry through to outputs, depending on the task, the mitigations, and how carefully anyone evaluated it.
The rigor data science brings to model development often isn’t matched in data preparation.
The integration challenge
Building a model is one problem. Getting its outputs into business processes is another.
AI that lives in a notebook isn’t delivering value. Value comes from:
- Models deployed reliably
- Predictions integrated into workflows
- Feedback loops that improve accuracy
- Monitoring that catches drift
Getting there is architecture, infrastructure, integration, and operational ownership.
Data architecture requirements for AI
Data accessibility
AI teams need access to data. Sounds obvious. Often isn’t.
Common blockers:
- Security policies that prevent access
- Data locked in production systems
- No self-serve capability
- Weeks of waiting for data extracts
Architecture solutions:
- Feature stores that provide curated, ready-to-use data
- Data catalogs that help teams discover what exists
- Access controls that enable rather than block
- Sandboxed environments for experimentation
Data quality
Models need clean, consistent data. Quality requirements include:
- Accuracy: Data reflects reality
- Completeness: Required fields are populated
- Consistency: Same concept means the same thing everywhere
- Timeliness: Data is fresh enough for the use case
- Validity: Data conforms to expected formats and constraints
This is data governance in action. Without it, teams spend a large part of every AI project cleaning and reconciling data before any modelling starts.
Data lineage
AI models need to know where data came from.
- What source systems contributed?
- What transformations were applied?
- When was it last updated?
- What quality checks did it pass?
Data lineage supports debugging, compliance, and trust. When a model returns something surprising, lineage tells you which data and which transformations were involved. It won’t explain the model’s reasoning, but it narrows where to look.
Feature infrastructure
Features are the inputs to models - derived, aggregated, transformed data.
Building features is expensive. Without infrastructure, teams:
- Rebuild the same features independently
- Create inconsistent versions of the same concept
- Can’t reproduce training data in production
- Struggle to share work across projects
Feature stores address this by providing:
- Centralized feature definitions
- Consistent serving for training and inference
- Point-in-time correct historical data
- Reusability across projects
Serving infrastructure
Models need to run somewhere. Options include:
- Batch: Scheduled runs that process data in bulk
- Real-time: Immediate predictions on request
- Streaming: Continuous processing of event data
- Embedded: Models running in applications
Each has different infrastructure requirements. Architecture must support the serving patterns your use cases need.
The AI-ready data platform
What does an AI-ready data platform look like?
Foundation layer
- Data lake/warehouse: Centralized, accessible storage
- Data integration: Reliable pipelines from source systems
- Data catalog: Discoverability and documentation
- Data governance: Quality, security, compliance
This is standard data architecture . AI doesn’t change the fundamentals - it raises the bar.
ML platform layer
- Experimentation environment: Notebooks, compute, sandboxes
- Feature store: Curated, reusable features
- Model registry: Version control for models
- Training infrastructure: Compute for model development
Serving layer
- Model serving: Infrastructure to run models
- Monitoring: Track model performance over time
- Feedback loops: Capture outcomes to improve models
- Integration: Connect predictions to business systems
Governance layer
- Model governance: Who approved this model for production?
- Bias monitoring: Are predictions fair?
- Interpretability: can a deployer understand the output well enough to use it appropriately? For high-risk systems the AI Act requires that much, rather than a full causal explanation of every prediction.
- Compliance: which obligations apply, given your role (provider or deployer) and the system’s classification?
Common AI architecture mistakes
Starting with AI before the data is usable
“We need an AI strategy” before you have a data strategy.
AI is a use case for data. If data foundations aren’t solid, AI won’t work.
Fix the foundations first. Then AI becomes possible.
Treating AI as a technology project
AI that doesn’t connect to business processes doesn’t deliver value.
Successful AI initiatives include:
- Clear business problem definition
- Stakeholder engagement
- Process redesign
- Change management
- Ongoing measurement
The technology is rarely the largest part of the work.
Underestimating MLOps
Building a model is one thing. Operating it is another.
Model performance declines when production data or business conditions drift away from the conditions it was evaluated under. Without monitoring, nobody notices until someone downstream does.
Learn more: What is MLOps?
Skipping governance
Governance tends to arrive after the first incident, and that pattern shows up across the industry .
AI introduces risks the existing data controls don’t cover:
- Bias and fairness concerns
- Explainability requirements
- Regulatory compliance
- Intellectual property questions
- Security vulnerabilities
Governance can’t be an afterthought. Build it in from the start.
Practical steps
If you’re starting from scratch
- Assess data readiness: What data do you have? What state is it in?
- Build foundations: Get basic data infrastructure working first
- Start small: One use case, not a platform
- Learn and expand: Use early projects to understand what’s needed
If you have existing data infrastructure
- Identify gaps: What’s missing for AI use cases?
- Extend, don’t replace: Add ML platform capabilities incrementally
- Enable experimentation: Give AI teams access and tooling
- Connect to production: Build paths from notebook to deployment
If AI projects are struggling
- Diagnose: Is the problem data, infrastructure, or integration?
- Fix root causes: Don’t paper over data problems
- Reduce scope: Focus on one success before scaling
- Build capability: Train teams on what’s actually needed
Related reading
AI and data reality
- Why Your AI Project Failed at the Data Layer
- AI Won’t Fix Your Architecture - It Will Amplify It
- If You Can’t Describe the Problem, AI Can’t Solve It
AI governance and risk
- AI Governance: Why 82% Are Scrambling
- GenAI Risks: The Billion Euro Wake-Up Call
- Is Your Architecture Ready for AI-Driven Threats?
Data foundations
Related topics
- Building Data Teams - Hiring for AI initiatives
- Data Platform Scaling - Infrastructure for AI workloads
- What Is Technical Debt? - How debt blocks AI progress
Get help
AI readiness is an architecture question: where the data is copied, who owns it, and whether you can reproduce what a feature saw.
If you’re planning AI work and want to know whether your foundations hold, a Platform Review identifies the gaps and produces a roadmap.
Book a discovery call to discuss your AI and data architecture challenges.
Fractional Data Architect helping startups and scaleups build data platforms that scale.
More about Thomas Nys →