AI-Ready Data: The Conversation We Need to Have Before We Talk About AI

I recently had the opportunity to moderate a roundtable with technology and data leaders on a topic that sounds straightforward but is anything but:

What does it actually mean to be AI-ready from a data perspective?

I went into the conversation expecting we would talk about vector databases, retrieval, data quality, infrastructure and AI workloads.

We did.

But what stayed with me was something much broader.

AI is forcing us to rethink some of the fundamental assumptions we've made about data architecture.

And that, to me, is where the really interesting conversation begins.

We may be solving the wrong problem

A lot of organisations today are asking:

"How do I make my existing data AI-ready?"

Clean the data.

Build a data lake.

Add a vector database.

Connect an LLM.

Build a RAG pipeline.

And start experimenting.

All of these are useful.

But perhaps the bigger question is:

If we were designing our data architecture today, knowing what we know about AI and agents, would we design it the same way?

I'm not sure we would.

And that may be the real shift - from making existing data architecture AI-ready to designing data architecture that is AI-native from the start.

I spent a significant part of my career building and operating platforms where databases, messaging systems and other stateful services had to work reliably at significant scale.

One lesson from that experience keeps coming back to me:

The architecture you build around a system can sometimes become more complicated than the system itself.

AI has the potential to amplify that problem - or give us an opportunity to rethink it.

AI isn't just another workload

Traditional applications generally have a fairly understandable interaction pattern.

A user does something.

An application processes it.

The application reads or writes data.

The system responds.

Now consider an AI agent.

It can retrieve information, reason over it, call APIs, write data, trigger another agent, evaluate the outcome and continue.

And potentially do all of this autonomously.

Now multiply that by thousands or millions of agents.

Suddenly, the question isn't simply:

"Can my database handle the traffic?"

It becomes:

"Can my data architecture support machines continuously consuming, creating, interpreting and acting on data?"

That's a very different problem.

The data isn't the whole story. Context is.

One of the things I found particularly interesting in our discussion was the distinction between data access and data understanding.

We often say:

"The AI has access to our enterprise data."

But what does that really mean?

Suppose an AI sees a field called customer_status.

Does it know what that field means?

Does it know who owns the definition?

Does it know how current the information is?

Does it know whether another system has a more authoritative version?

Does it understand the business rules behind it?

Does it know what information should be considered alongside it?

Humans fill in much of this context almost unconsciously because we understand the organisation.

AI doesn't.

This makes metadata, lineage, semantics, ownership and governance much more important.

AI-ready data isn't simply clean data. It is data with context.

Are we heading towards more specialised databases - or fewer?

This was another interesting tension.

Over the last decade, we've seen an explosion of specialised data systems.

Transactional databases.

Caches.

Search engines.

Data lakes.

Data warehouses.

Graph databases.

Vector databases.

Streaming platforms.

Each solves a real problem.

But every additional system also creates another boundary.

Another pipeline.

Another copy of data.

Another replication mechanism.

Another security model.

Another operational dependency.

So I keep wondering:

Will AI push us towards even more specialised systems, or will it push the industry towards more unified data platforms?

I don't think we know yet.

But I do think the cost of moving data between systems deserves much more attention than it gets.

Because in an AI world, data movement itself can become a bottleneck.

What if we designed for 2030 instead of optimising for today?

This may have been my favourite thought experiment from the roundtable.

Imagine there was no legacy.

No existing databases.

No accumulated pipelines.

No organisational boundaries.

No technology decisions from five or ten years ago that we now have to work around.

You know what AI agents can do.

You know that machines will increasingly become consumers - and producers - of enterprise data.

What would you build?

Would the database still be primarily an application's persistence layer?

Would we still move data around so much?

Would we create multiple copies of the same information?

Would applications continue to own so much of the business logic?

Would humans remain the primary users of enterprise systems?

Or would we design data platforms around a world where humans, applications and agents are all first-class participants?

I don't have the answer.

But I think asking the question is valuable.

Governance gets much harder when AI can act

There's another dimension that becomes impossible to ignore as agents become more capable.

It's one thing for an AI to tell me:

"I think this customer is likely to churn."

It's another for an AI to actually change the customer's status, initiate an offer, approve a transaction or trigger a workflow.

At that point, governance isn't just about who can read data.

It's about who - or what - can act on it.

That raises some very fundamental questions:

Who is the agent?

What is it allowed to do?

Under what conditions?

How do we audit its actions?

How do we explain why it made a decision?

How do we stop a bad decision from propagating across multiple systems?

And perhaps most importantly:

How much autonomy are we actually comfortable giving machines?

AI-ready architecture and AI governance therefore cannot be separate conversations.

They are becoming deeply intertwined.

I'm particularly intrigued by the idea of data being more "experimentable"

AI thrives on experimentation.

Try a different prompt.

Try a different context.

Try a different decision strategy.

Simulate an outcome.

Compare multiple approaches.

Today, doing this with enterprise data can be surprisingly cumbersome.

This is why ideas such as forkable databases and easily isolated data environments are interesting to me.

Imagine being able to safely create a version of your data, let an agent experiment against it, evaluate what happened, and then decide what - if anything - should make its way back.

That could fundamentally change the way organisations experiment with AI.

It also creates new questions around storage, consistency, security and governance.

But that's exactly what makes it interesting.

Sometimes the most valuable technology ideas are the ones that create new possibilities and new problems at the same time.

And then there is the economics

We often talk about AI infrastructure in terms of GPUs.

But as AI adoption scales, I suspect the conversation will increasingly become about the economics of data.

How much data are we moving?

How many copies are we maintaining?

How much context are we retrieving?

How much latency are we introducing?

How much infrastructure is sitting between the model and the data it needs?

And ultimately:

How much does every AI decision cost?

The most technically elegant architecture isn't necessarily the most sustainable one.

AI will force technology leaders to think about performance, architecture and economics together.

Maybe the biggest opportunity is simplification

There's an irony here.

We could respond to AI by adding another layer to everything.

Another database.

Another platform.

Another pipeline.

Another tool.

Another API.

Another team.

Or we could use this moment to ask:

Can AI actually help us simplify?

Can it help us understand legacy data?

Can it reduce migration complexity?

Can it discover relationships across systems?

Can it automate parts of database operations?

Can it help consolidate fragmented architectures?

Can it make infrastructure more self-managing?

Perhaps the real opportunity isn't just to make today's architecture AI-ready.

Perhaps AI gives us an opportunity to rethink the architecture itself.

My biggest takeaway

I walked away from the roundtable with more questions than answers.

And I think that's a good thing.

Because we're still early.

The architecture patterns that will support an AI-first enterprise at scale are still being figured out.

What feels clear to me is that AI readiness is much bigger than adding an AI layer to an existing data stack.

It touches the way we store data.

The way we understand it.

The way we move it.

The way we govern it.

The way machines access it.

And increasingly, the way machines act on it.

The most interesting question for me isn't:

"How do we make our existing data architecture ready for AI?"

It's:

"If we were building the enterprise data platform from scratch for an AI-first world, what would we build differently?"

I'd love to hear how others are thinking about this.

What is one thing you would fundamentally change in your data architecture if you were designing it for 2030?