I just read a LinkedIn post describing something instantly recognisable: somewhere in your organisation, there's a tab called risk_assessment_FINAL_v3_actual.xlsx, and there's also a GRC platform you pay a significant amount of money for. The two coexist in a state of polite mutual ignorance, and nobody talks about it.
The author felt it was time to rethink compliance now that AI is here. I agreed. This is my answer.
The Best We Could Do
GRC platforms weren't a mistake. They were a rational solution to a genuine constraint.
Before you could instrument a system in real time, you had to ask people what was happening and hope they told you accurately. Before you could generate a statement of applicability from actual system behaviour, you needed someone to populate a form — ideally before the audit, ideally honestly. Evidence collection existed because there was no other way to get evidence. Documentation was the best available proxy for practice when practice was invisible.
The logic held. You need to demonstrate compliance to an auditor, you can't observe what's actually happening, so you build a system for capturing what people say is happening. Add enough mandatory fields to make it feel rigorous, call it a management system, and you're done. Reasonable people made these decisions. The result is what we have now: an entire category optimised for producing evidence rather than producing security.
This is why the spreadsheet kept winning — not because people are resistant to change, but because it was a tool for doing the work. The GRC platform was a tool for proving the work had been done. Two different jobs, only one of which anyone actually wanted to do.
The constraint was real. The solution was sensible. The problem is that the constraint no longer exists — and the industry responded by making the solution faster.
What the Constraint Was Hiding
What evidence collection was always a proxy for is this: actual visibility into whether your controls are working.
Once the proxy became the thing, something quietly broke. In a large enterprise, you can afford to let the two worlds coexist — real security work happens somewhere, compliance documentation happens somewhere else, and there's enough budget and headcount to maintain both fictions simultaneously. Wasteful, but survivable. In an SME, you don't have that luxury. You get one version of compliance, and more often than not it's the performative one: a platform that looks good to auditors and tells you almost nothing about whether you're actually secure.
This is the problem evidence as byproduct solves.
The idea is straightforward. When the work itself is instrumented — when agents log incidents as they happen, when risk decisions are captured with their reasoning intact, when control testing occurs inside the tools people already use — the audit trail emerges from practice rather than running parallel to it. You don't collect evidence. You do the work, and evidence is what's left behind.
The difference sounds subtle. It isn't. When evidence is something you produce separately, compliance becomes governance theatre: documentation maintained for auditors, largely disconnected from how the organisation actually operates. When evidence is a byproduct, the management system and the real system are the same thing. One of these is genuinely useful. The other is what fills the binder on the shelf that nobody opens except in Q4.
Closing that gap is what AI makes possible for the first time. Which is exactly why it matters what you do with it.
AI-First, Not AI-Washed
When AI arrived, most GRC vendors did what you'd expect. They automated the evidence collection. Faster screenshots. Automatic control mapping. AI-generated policy documents. The underlying architecture — start from the framework, work backwards to evidence, optimise for audit readiness — remained entirely intact. The tool got faster. The problem didn't move. You can now produce the wrong thing at scale, which I suppose is progress of a kind.
AI-first thinking starts from a different question: what does compliance look like if you design from scratch, without the constraints that made evidence collection necessary in the first place?
The answer starts with risk. Not framework clauses or control categories — actual risk scenarios, quantified with the management team in language they can act on. This part is irreducibly human. AI can surface relevant context, suggest scenarios based on what's happened to comparable organisations, prepare the ground. But the reasoning has to be owned by the people accountable for the decisions. That ownership is what makes everything downstream trustworthy.
From those scenarios, the rest derives. Controls, tests, training, the audit schedule — all traceable back to the risks that justify them. The mapping to Annex A happens automatically: describe what you're doing, and AI connects it to the relevant framework requirement. The statement of applicability generates itself from the graph of what's actually in place. Policy documents become close to optional, because the agents running your controls know how they work and can simply be asked.
And the evidence? Byproduct. Incidents logged in the background. Training captured as it happens. Control testing leaving a trail in the system where it was conducted. When the auditor arrives, the question shifts from "can we produce the evidence pack?" to "what would you like to know?"
I want to be clear that we're still working this out in practice — which parts genuinely require human judgement, where the graph needs intervention, what the auditor relationship looks like when evidence is live rather than collected. There's real work still ahead.
But the direction feels right. The constraint that made evidence collection necessary no longer exists. Designing as though it still does isn't caution. It's just habit dressed up as rigour.
The compliance industry has spent thirty years getting very good at solving the collection problem. The question worth asking is whether collection was ever the point.