A friend sent me a proposal and asked what I made of it. Not my client, no stake in the outcome, just a second opinion before he took it further.

I read these the same way every time. Find the boldest claim in the document, then go looking for the paragraph that explains how it works. Nearly twenty years in, that habit has saved me more trouble than any framework.

The boldest claim was compliance. The paragraph was not there.

What I found instead was an architecture. A layer that strips personal data before it reaches the model. A layer for logging and audit. Controls for access and cost. Every box made a claim. None of them explained what the system does when the answer is not obvious.

This is not a vendor overselling. They hold the certifications you would want them to hold, ISO 27001 among them, and those are not easy to get. Even the privacy-specific standards certify a management system, not any particular use of data. A certificate says how they run their own operation. It says nothing about what happens when their system meets your business.

The claim that compliance can be bought as a feature is becoming standard, and it fails the same way everywhere.

Start with the written rules, because that is the part people assume is solved. Take an email address. Under the GDPR, jane.smith@acme.com is personal data. info@acme.com generally is not. Article 4(1) turns on whether the information relates to an identifiable person. But if that shared mailbox points to only one person, or the business behind it is one person, it is personal data again. That is a fact about the world, not a fact about the string in front of the classifier.

And the law is only the floor. Your own privacy policy almost certainly promises more than the regulation requires. Most do. Somebody wrote those sentences years ago, and they are now a commitment you are held to. The vendor has not read them. Even a perfect legal answer is not yet your answer.

I spent years inside a group that owned both Albert Heijn and bol. Broadly the same customers, in the same country, under the same law. Not remotely the same permission. People expect bol. to know what they browsed and to do something with it. The same person is cooler about Albert Heijn doing the equivalent with groceries. The Bonuskaart has been a fixture of Dutch privacy debate for over a decade, and that history sits in people's heads whether or not it appears in any policy.

Same data. Same processing. Same jurisdiction. Different answer. Put either brand next to a US retailer and the lines move again, and now the law moves too.

Two things are at work there and it helps to keep them apart. Obligations are what you must do: the law, plus the promises you wrote down yourself. Expectations are what customers assume you will do, and nobody wrote those anywhere. I studied communication before I worked in data. The central idea in Cees van Riel's Identiteit en Imago is one I still use. Identity is what an organization believes about itself. Image is what everyone else believes about it. You only control the first.

The expectations side is not the soft one. What a customer reasonably expects feeds into whether processing is fair at all, and it carries the larger commercial risk besides. You can be entirely within your rights and still lose people. A regulator gives you a finding you can respond to. Customers give you no notice at all.

So compliance is not a property of a system. It is a property of a system inside a particular organization. Some of it looks purely technical. Retention periods, encryption, access logs: a system holds those settings, not the decisions behind them. Someone chose twenty-four months over thirty-six, weighing the law, the policy, and what customers would accept. A vendor cannot hand you that. If they set the defaults, they are making those decisions for you.

None of which makes the tooling worthless. Stripping obvious personal data before it leaves your network is worth doing. So is encryption. But it is a fail safe, not a catch-all. A fail safe catches what it was built to catch. Everything else goes through, and nothing flags it.

You do not need to understand the technology to test the claim. Ask what the system does when the right answer depends on something it has no way of knowing. An architecture shows where a control would sit. Only a mechanism tells you what it does. A claim is neither.

I could end with an example of something I caught in someone else's output before it went out. I am not going to, because the catch is the failure. Compliance that depends on someone noticing by chance fails wherever nobody happens to look. Automation makes that worse: it removes the people who used to look and leaves the judgment calls unchecked.

The answer is not more checking. It is designing compliance into how the organization works, tooling and systems included, so the judgment sits where the work happens. That takes real work, which is exactly why a product that offers to skip it sells so well. Done correctly, it is also where the speed comes from, because most delay in AI work is not engineering time, it is waiting for permission, and a team that knows the boundaries is not in that queue.

There is no button for that. Only whether your organization is set up to do what it promised.

Working on this yourself? I help leadership teams turn data and AI strategy, governance and regulation into decisions that hold up in practice. Let's get a coffee. No pitch, no deck. Get in touch →