§ Perspective · Founder POV · September 15, 2026

Most people who say they have
AI governance name a tool.

That gap is not a vocabulary problem. It is the reason controls get bought and protection does not arrive — and it is testable in about five minutes.

By Lindsay Hiebert · Founder · CISSP

Ask a room of security leaders whether their organization has AI governance and most will say yes. Ask what AI governance is and most will name a tool.

I do not say that to be unkind. The people answering are competent, and the tools they name are good ones they were right to buy. But the answer reveals something worth naming plainly, because it is the thing that decides whether any of that spend produces protection: a great many organizations have purchased the ability to see and the ability to block, and have concluded they bought the ability to prove. Those are three different things, and only the third is governance.

The distinction that does the most work

Your SIEM, your AI security posture platform, your SOC tooling — these see what is happening at runtime. That is observability, and it is necessary. Your DLP, CASB, SSE and endpoint controls decide what is technically allowed to happen. That is enforcement, and it is also necessary.

Neither one produces a decision. Telemetry tells you what happened; it does not tell an auditor what you decided should happen, who decided it, and how you verify compliance with that decision. A runtime block is a control action, not a policy. When the auditor says “show me your AI acceptable use policy and your risk assessment,” a screenshot of a firewall rule is not an answer to the question that was asked.

Observability observes. Enforcement enforces. Neither one governs.

Conflating the three is how an organization ends up with genuinely strong tooling and no defensible evidence — which is precisely the position a regulator inquiry or an insurance claim dispute exposes, and precisely the position that feels safe right up until someone asks for the document.

The second distinction: two halves, not one

Every governance obligation in every framework reduces to two questions, and they are not the same question asked twice.

Due care asks whether you put reasonable safeguards in place: a published acceptable use policy, a documented risk assessment of the AI actually in use, controls with named owners, board-level acknowledgment. Due diligence asks whether you are continuously verifying that it still works: re-auditing as new tools appear, refreshing the registry, updating the policy when the law moves, keeping the evidence trail across cycles.

Due care is a snapshot standard. Due diligence is a motion standard. An organization can satisfy due care on Monday and lose due diligence by Friday if its AI surface changed and nothing was re-assessed — and the surface changes constantly, which is why an annual consulting engagement now fails the standard by arithmetic rather than by neglect. Boards, regulators, plaintiffs’ attorneys and cyber-insurance underwriters all read an AI posture through exactly these two lenses. In a dispute, the record names a person.

Why this is a literacy problem, not a tooling problem

Here is the part that makes this urgent rather than merely interesting. Every control you might buy depends on someone in the building being able to make these distinctions.

If nobody can separate governance from observability, the organization buys monitoring and believes it has bought evidence. If nobody can separate due care from due diligence, it completes one assessment and believes it is finished. If nobody knows that accountability is always one name rather than a committee, the policy has no owner and the board has nothing to acknowledge. None of those failures is caused by a missing product. Each is caused by a missing distinction — and no purchase fixes a missing distinction.

That is what AI literacy actually means in this context. Not knowing how to write a prompt. Knowing what a control does and does not prove, and being able to say so to a board, an auditor or an underwriter without reaching for a vendor name.

Which is also why it is a legal duty

EU AI Act Article 4 requires providers and deployers to take measures ensuring a sufficient level of AI literacy among the people operating AI on their behalf. It has been in force since February 2, 2025. The 2026 Digital Omnibus split the Act’s timeline — the high-risk regime moved to December 2027 and August 2028 — but Article 4 was not deferred. It is a live obligation today, not a 2027 one.

ISO/IEC 42001 makes the same demand in management-system language: competence is documented and auditable, not an assumed background condition. Both ask for two things rather than one. Build the competence. Be able to show that you built it. A company that trains its people well and keeps no record has satisfied the first half and failed the half that gets examined.

So: can your team hold the distinctions?

That question is answerable, which is why I built a quiz for it. Ten questions, five minutes, and not one asks you to memorise a fact — every question is a distinction. Three of them are here; pick an answer and the evidence appears.

The three layers
1 / 3

A company runs a SIEM, an AI security posture platform, DLP and a CASB. The auditor asks to see their AI governance. What have they actually got?

Choose an answer to see the evidence

What I would actually watch is not the score. It is which questions your team disagrees on before the answer is revealed. That argument is the useful part, and it tends to surface the assumption nobody wrote down — usually about who owns the policy, or about whether last year’s assessment still counts.

What to do with the answer

If the distinctions land easily across your team, you are in a better position than most, and the next question is whether you can produce the artifacts that evidence them.

If they do not, that is not an indictment of anyone — this vocabulary is eighteen months old and most of it was written by regulators rather than practitioners. But it does mean the next purchase will not help, because the gap is upstream of the purchase. Role-based training is the fix, and the reason it has to be role-based is that what a board member needs to recognise is not what a developer needs to recognise, and neither is what the person pasting a contract into a browser tab needs to recognise.

A quiz is not a training record. The SanctumShield AI Literacy Academy is built to produce one: role-based tracks from a single field guide, a deterministic examination, and Training and Acknowledgment Records that evidence the programme exists. That record is the half of Article 4 that gets examined.

You can buy controls in a week. The judgement to know what they do and do not prove is what takes training — and that judgement is what a regulator, an underwriter and a court are actually testing.

The distinctions in this piece are drawn from the SanctumShield Academy field guide, the single source behind its role-based tracks and certification exam. Every answer in the quiz cites the Part it comes from.

Free Shadow AI Risk Audit

See what your current stack is missing — in 12 questions.

The SanctumShield free Shadow AI Risk Calculator runs in your browser. No account, no email, no credit card. Twelve questions, instant risk score, three primary findings tailored to what you submit.

Perspective · outside the 27-week sequence · see the full series →

Most People Who Say They Have AI Governance Name a Tool — SanctumShield