Most organisations wrote an AI acceptable-use policy in the last eighteen months. Very few can tell you whether it's being followed. The policy names a handful of approved tools and prohibits the rest, and enforcement is a domain blocklist on the web proxy.
Three things a blocklist cannot tell you
- Which tools are actually in use. New AI products appear weekly, and a blocklist only knows what someone added to it.
- What left in the prompt. A domain is allowed or blocked. The content that went to it is invisible, so an incident can't be scoped afterwards.
- Whether the person was behaving unusually. Volume and destination mean nothing without a baseline for that individual.
Content, not destination
The useful unit of analysis is the content of the request, not the hostname it went to. Personal data, credentials, and source code are detectable in a payload. Once you inspect content, the governance question changes from which tools are allowed to which data classes may leave, and for whom. That is a policy you can actually enforce.
A useful first step
Before writing any policy, run discovery for two weeks and look at the list of destinations. The gap between what the policy assumes and what the traffic shows is usually the whole argument for doing this properly.
Then the frameworks follow
ISO 42001, the OWASP LLM Top 10, and the EU AI Act all expect you to know what your AI usage looks like. None of them can be answered from a blocklist. Once detection is content-aware, framework mapping becomes a reporting exercise rather than a research project.
