Why I'm still a Data & AI leader, and whether that will change

Every few months someone asks me why my title still says Data & AI. With GenAI and agents getting most of the attention and most of the budget, shouldn’t it be about AI alone?

It’s a fair question. My honest answer is that the title may well change, but the responsibility behind it shouldn’t.

I’ve seen this film before

Business intelligence, data warehouses, big data, data science, machine learning, GenAI, and now agents. Each wave brought new job titles, new tools and new conferences. Underneath, the same four questions kept coming back:

• Is the data correct, complete and current?
• Who is accountable for it, and who can say it’s wrong?
• Who may use it, for what, and how do we prove it?
• Does it change a decision, a process or a customer’s experience?

My own career followed those waves. I was a data scientist, then the lead on a data platform transformation, then the architect of an AI Factory. The tools changed every time. Those four questions never did.

Today, data feeds AI

The first direction is well known, and still underestimated. A retrieval assistant is only as good as the documents it retrieves, a classifier only as good as its labels, an evaluation suite only as good as its questions and expected answers. Fine-tuning sets, few-shot examples, guardrail rules: all of it is data.

When a GenAI project disappoints, the cause is often upstream, in the documents and data it was given. I’ve written about why that keeps happening in data maltreatment.

Tomorrow, AI produces data too

The second direction is newer, and it changes the job.

AI now produces data. Summaries end up in customer files, classifications become the official category of a document, extracted fields feed downstream systems, and drafts that a person validates become the record.

It also influences data. An agent that routes a request decides which team sees it and how fast. A suggestion accepted nine times out of ten shapes what the database will contain.

And AI has to be observable, which creates yet more data: traces, prompts, retrieved passages, tool calls, costs, expert feedback, evaluation results. To be accountable for an agent, you have to keep and govern a new class of data about the agent itself.

The most concrete case of all is AI reading text and loading the results into the data warehouse. It deserves its own article, so I wrote one: when text becomes warehouse data.

So the loop closes. Data feeds AI, AI produces and reshapes data, and that data feeds the next AI. A defect on either side ends up on the other.

Datadocuments, records, labels, history

Todayfeeds documents to retrieve, labels, golden sets, few-shot examples

Tomorrowproduces, influences, is observed summaries, classifications, extracted fields, routing decisions, traces

AIretrieval, models, agents

Responsible for both halves

That is really the core of my answer. In a loop, you can’t be responsible for only half of it.

On the data-to-AI side, the job is the classic one, made more demanding: ownership of sources, lineage, freshness, access control, and datasets curated specifically for retrieval and evaluation.

On the AI-to-data side, the job is new, and in many organisations nobody has it yet. Every record produced or changed by AI should say so: which model, which version, which prompt, validated by whom. When a generated summary is later retrieved by another assistant, you should be able to trace it back. Generated data needs the same quality rules as human-produced data, plus checks for the ways models typically fail. Traces often contain personal data, so they need retention and privacy rules like any other dataset. And golden questions, expert corrections and review results are some of the most valuable data an organisation will ever create. They deserve owners, versions and a place in the catalogue.

If one team looks after the first list and another discovers the second list during an incident, the loop is already broken.

Data & AI, or Data vs AI

Organisations are making a choice here, often without saying so.

Data vs AI separates the two. A Chief Data Officer keeps governance, platforms and quality, and a new AI organisation takes the models, assistants and agents. There are good reasons for it. AI moves fast and needs its own budget, executive visibility, and people who aren’t absorbed by data operations.

Data & AI keeps one accountability for the whole loop, with specialised teams inside it: data platform, governance, AI engineering, evaluation, product. One roadmap, one platform strategy, one set of rules.

	Data vs AI (separated)	Data & AI (unified)
Speed of AI delivery	Usually faster at the start	Often slower at the start; can speed up if shared building blocks are reused
Data quality for AI	Depends on how well the two teams cooperate	Easier to own end to end, if the data side keeps enough capacity
Ownership of AI-generated data	Has to be agreed explicitly between teams	Simpler to assign, still has to be written down
Platforms	Higher risk of two stacks	Easier to share a platform, though not guaranteed
Budget and visibility for AI	Strong	Have to be protected deliberately
Main risk	AI bypasses governance, data becomes a backlog for AI	AI absorbs all attention, fundamentals get neglected

Neither column predicts what will happen. It only shows what each model makes easier or harder. A well-run separated organisation with clear interfaces will do better than a unified one where nobody really owns anything.

Separation can make sense. In a very large group with a mature data organisation and a very different pace on the AI side, a separate AI unit may be the right way to start. And some separations aren’t optional at all: model risk validation, compliance and data protection must stay independent from the teams that build. That’s separation of duties, and it’s healthy.

What I’ve rarely seen work is splitting data and AI into two domains of accountability. The failure modes are predictable. The AI team builds its own pipelines to move faster and ends up with a second, ungoverned data platform. The data team gets a flood of urgent requests it never planned for. Quality problems turn into arguments about whose fault they are. And the data produced by AI falls into the gap between the two, owned by nobody.

So my position is simple: one accountability for the loop, specialised teams inside it, and independent validation outside it. One accountability doesn’t mean one team doing everything. Platform engineers, data owners, AI engineers and evaluators keep distinct roles and skills. What they share is a single roadmap and a single answer to the question “who is responsible for this, end to end?” Validation stays deliberately outside, with people who didn’t build the system.

If I were setting this up from scratch

I’d start from what already exists, the data platform, the catalogue and the owners, instead of building an AI stack next to them. I’d run the first AI use cases on that shared platform, adapting the governance case by case instead of bypassing it. I’d treat AI outputs, traces and evaluation results as governed data from day one. I’d name the roles explicitly, because ambiguity is where the loop breaks: data owners, AI product owners, evaluation owners, platform owners and an independent validation function. And I’d write down the operating model, unified or separated, with clear responsibilities for AI-generated data. The worst model is the one nobody chose.

Above all, I’d invest in people who can work on both sides: data engineers learning evaluation and LLM behaviour, AI engineers learning governance and data modelling, business experts learning to review AI. Those profiles make the loop work, and they are hard to hire.

So, will it change?

The title might. In a few years AI may absorb data on business cards, or data may become so embedded that nobody bothers to name it. Titles follow fashion.

The job won’t shrink back to one side, though. As long as AI learns from data and produces data, someone has to look after both with the same care. That’s why I still call myself a Data & AI leader, and why I care about the ampersand.