They struggle because they’re trying to apply it to something they haven’t properly defined.
When you ask a company what their “AI system” is, the answer is almost always vague. It’s framed in terms of tools or features. A model, an assistant, a recommendation engine. Something that sounds concrete, but actually isn’t—at least not in a way that regulation can work with.
Regulation doesn’t attach itself to tools. It attaches itself to how a system behaves in context.
And that’s where things start to break.
What companies call a “use case” is usually just a description of intent. It tells you what the system is supposed to do, not how it actually operates. It doesn’t tell you where decisions are made, where risk emerges, or how outputs travel through the organization and beyond it.
But those are precisely the things regulation cares about.
So teams move too quickly. They jump to classification. They ask whether something is high-risk, whether it falls under a specific category, whether certain obligations apply.
But they’re asking those questions about something that is still conceptually blurry.
That’s why the answers never feel stable.
You see it in the documentation. It looks complete on the surface, but it doesn’t hold together under pressure. Different parts of the system are described differently depending on who wrote the document. Assumptions shift. Boundaries are inconsistent. When someone asks for evidence—real, operational evidence—it becomes difficult to produce.
Not because the team did nothing.
But because the structure underneath was never clear enough to support it.
There is a missing step in most AI governance efforts. It sits between “we built this” and “this is how it is regulated.”
That step is structural clarity.
It requires taking the system apart—not technically in the sense of code, but functionally. Understanding where decisions actually happen. What the system influences. Who interacts with it, and under what conditions. Where its effects begin and where they end.
Only then does regulation start to make sense.
Because only then do you have something stable enough to map.
At that point, classification stops being a guess. Obligations stop feeling arbitrary. Documentation starts to align. And more importantly, you can explain your system in a way that others—auditors, procurement teams, regulators—can actually follow.
Without that, compliance becomes a surface exercise. Policies exist. Statements are made. But the system underneath remains opaque.
And opaque systems don’t survive scrutiny.
AI governance doesn’t fail because teams don’t care about compliance.
It fails because they try to comply before they understand what they’re working with.
