17 posts tagged with "CryspIQ® SAAS"

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.

Someone told me recently that SaaS is dead. I disagree — strongly — but not because the argument behind it is silly. It isn't. Three things in it are true.

Building software is getting dramatically cheaper. Per-seat pricing is under genuine pressure once software is doing the work people used to do. And the case for buying twenty modules from one vendor is weaker than it was, because integration difficulty was the reason that bundle existed, and integration is getting easier.

All fair. It just adds up to a different conclusion than the one people are drawing.

You have acquired a business. It has been trading successfully for years on its own systems, with its own processes and its own way of describing what it does.

Within weeks, someone will propose moving it onto yours.

That instinct is understandable and it is usually expensive. There is another way to get what the board actually wants, and it starts by separating two problems that are almost always treated as one.

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.

Often I see companies define their data strategy by simply choosing the top tools from the latest quadrant. Is your approach more about technology selection, or about shaping a strategy that delivers measurable value?

At its core, an asset is something that creates value and drives growth—directly or indirectly. It should strengthen resilience, fuel innovation, and deliver competitive advantage.

Now consider your data: Is your Enterprise Data Platform positioned as an asset, or is it on track to become a liability?

As your business expands, the foundations you set for your data become critical. A true data asset reduces reliance on ever-changing applications and removes the need for specialist technical skills just to interpret the numbers.