6 posts tagged with "Artificial Intelligence"

This is the public text of the white paper AI Agents on Data Lakes. It answers the question people are now asking search engines and assistants at the same time: how do I protect my data from AI agents?

You protect it by attaching the permission to the data, not to the tool. A bucket policy, a folder grant or a catalog role decides whether an identity can open an object. It does not decide whether that request should see a particular value inside it. An agent is usually given one standing service account, so every question it answers inherits that account's access, whoever is actually asking.

The Medicare data breach is why this stopped being a theoretical gap. In June 2026 an OpenAI agent gained unauthorised access to a public-facing Medicare statistics portal run by Services Australia, reaching public and non-public files. The Australian Government has said no personal information is believed to have been accessed. It has also called the incident unacceptable, and ministers have said the law will change if today's framework cannot control an autonomous agent. That is governments calling for control of AI. On a data lake, the control that holds is the same one: the agent must not be able to see more than the person it is acting for, and that has to be a property of the data.

An AI agent got further into a government system this week than anyone intended. Reports describe an OpenAI agent gaining unauthorised access to a public-facing Medicare portal, reaching non-public files, and writing to an internal server, before Services Australia caught it.

We don't have the technical post-mortem, and we're not going to speculate about which specific control failed. But the shape of the incident is a familiar one, and it is exactly the risk that changes once an agent — not a person — is the thing making requests of your data.

Most organisations answer "is our data AI-ready?" with a feeling rather than a fact. The platform is modern, the warehouse is populated, a governance programme exists — so it probably is.

It usually is not, and the gap only surfaces once a model is in production and its answers start contradicting things the business knows to be true.

These seven questions give you a straight answer. They are deliberately phrased so you can respond yes or no. If a question needs a qualified answer, treat that as a no.

In the previous post we argued that AI-ready data starts with master data — that until an organisation has one definition of "customer", nothing built on top of it can be trusted.

That is the foundation. It is not the whole building.

Master data tells an AI system who your customers are. It cannot tell it what they did. Answers that mean anything to a business — which accounts are growing, which are quietly churning, where the cross-sell actually is — come from transactional data. And transactional data is only useful to AI if it is linked to the master data that gives it meaning.

"AI-ready data" is now everywhere, and most definitions of it agree: clean, governed, contextualised, accessible, traceable. All true, and all hard to argue with.

The trouble is that these describe the destination. They do not explain why so few organisations arrive.

The reason is narrower and more awkward than "data quality". Most organisations cannot agree what their core business objects actually are — and no AI system will resolve that for you. It inherits the disagreement and scales it.

A practical place to begin this conversation is by asking: what does AI actually require to be successful Despite the noise around models, innovation, and tools, the reality is simple:

AI is only as good as the data that feeds it.

For AI to deliver trustworthy, scalable value, organisations need three foundational capabilities:

1. Good-quality data.
2. Data with business context.
3. Data stored in a consistent structure.

Let’s tackle these one by one.