There's a lot of magical thinking in the AI market right now: the idea that if you just plug in the right model, it will sort everything out for you. It won't. And nowhere does that gap between hype and reality show up faster than in agentic AI, where systems act on your behalf without a human checking each step.
That was the starting point for the first episode of Isolio's podcast series, a conversation between Tamas Feher, founder and CEO of Isolio, and Carl Jackett, founder of the data consultancy Revello. Carl has spent nearly two decades moving between defence systems integration, facilities management, blockchain compliance and now bespoke data projects, always with data sitting at the centre of the work. His answer to "why start with data instead of the model" is disarmingly simple: the business was already responsible for its data long before AI showed up, and that responsibility hasn't gone anywhere.
The ownership question never changed
"The business' responsibility is mostly for the data," Carl explained. "In a lot of ways that hasn't changed, there's nothing new with AI in that perspective. The business is still responsible for the data that they have got hold of, the ownership of it, the rights they have to use it." Whatever model you route that data through, you still own the consequences of how it's used.
What AI changes is the speed at which you can get into trouble. Used well, it accelerates good decisions. Used carelessly, it accelerates bad ones just as fast. As Carl put it, AI is "a good way to get into trouble faster if you haven't thought about what data is going in there."
The fundamentals of data management, who owns it, what rights you have to use it, where it's stored, haven't been replaced by AI. They've just become more urgent, because mistakes now compound at machine speed rather than human speed.
Why this isn't just a compliance talking point
It's tempting to file "data ownership" under legal or compliance and move on to the interesting engineering work. That's a mistake, and not just because a regulator might disagree with you later. Carl's framing is that AI creates "new opportunities," not "new problems," but only if the underlying data discipline is already sound. A business that doesn't know what rights it has to its own customer data, what it's contractually allowed to share with a third-party model provider, or what happens to a dataset when a customer asks for it to be deleted, was already carrying that risk before AI arrived. Agentic AI doesn't create the exposure. It finds it, fast, and then acts on it repeatedly without anyone in the room to notice.
That's why the conversation kept circling back to the same handful of questions, not as compliance boilerplate but as genuine engineering inputs: who owns this data; what rights do you have to use it; was it captured under terms that allow this particular use; and can it legally be passed to a third party such as an AI vendor? Answer those before you touch a model selection screen, and the rest of the architecture becomes far more straightforward to design.
From decisions-in-the-loop to decisions-up-front
The real structural shift happens when you move from a person typing into ChatGPT or Claude to a fully agentic system running unattended. When a human is prompting a model directly, every interaction involves a small, continuous decision: should I paste this document in? Should this system have access to that information for this particular question? Each of those micro-decisions is made in real time, by a person, with context.
Agentic systems remove that person from the loop. As Carl described it, "each time one of those decisions is made, there's not that human in the loop, which just lifts up the burden, the pressure on making sure you set it up right in the first place." You still make the same decisions about what data goes in and what rights you have to use it. You just make them once, at design time, instead of continuously. That single design decision then repeats itself autonomously, 24 hours a day, at whatever scale the system runs.
This is the core reason data governance can't be an afterthought in agentic architecture. A conversational AI mistake is usually a single bad output. An agentic AI mistake, baked into the initial setup, replicates itself every time the workflow runs until someone notices and fixes it.
Nothing about this stays static
There's a second wrinkle that doesn't apply to one-off prompts: agentic systems and the models underneath keep changing after you've deployed them. "These things often don't always stay static," Carl noted. "There is a sort of an element of when do you re-review these things? When do you check that nothing's changed? Have you accidentally given it access to more data? Has the model changed?"
That's a genuinely new operational discipline for most businesses. It's not enough to design a workflow's data access correctly once. Someone needs to own the periodic review: has a permission crept outward, has an underlying model update changed how the system behaves, does the original basis for that access decision still hold? Without that review cadence, governance-by-design at launch quietly degrades into governance-by-accident six months later.
What this means in practice
None of this requires exotic new tooling. Carl's advice is closer to a supply chain audit than a technical build: understand what data is going where, what rights back that use, who owns the outputs the system generates, and how you'd unwind it if a right to use that data were withdrawn. It's the same discipline businesses already apply to financial audits or ISO 27001 certification, just pointed at a faster-moving target.
For technical and IT leaders scoping an agentic AI rollout, the practical takeaway is to resist the pull toward model selection as the first decision. Before evaluating which model or platform to use, map the data: what inputs the agent needs, what transformation it performs, what new outputs it creates, and who is accountable for reviewing that mapping over time. Get that foundation right, and swapping models later becomes a manageable engineering task rather than a governance crisis.
In practice, that means a short design document for every agentic workflow before a single line of orchestration code gets written. At minimum it should answer four questions: what data sources does this agent read from, under what rights was that data captured, what does the agent produce that didn't exist before, and who signs off when that mapping needs to be revisited. It doesn't need to be elaborate. It needs to exist, and it needs an owner who is expected to update it when the underlying model, the data source, or the regulatory picture changes.
That mapping exercise, and the specific risks that show up when you apply it to something as ordinary as an email inbox, is the subject of the next article in this series.
This article is drawn from Episode 1 of Isolio's podcast, "Data Ownership and Lifecycle Management in Agentic AI," a conversation between Tamas Feher (Isolio) and Carl Jackett (Revello).